On Mon, Nov 07, 2005 at 10:50:51AM +0100, Marco d'Itri wrote: > Are you using prelink or something else which could cause /sbin/udevd to > change? I do not understand why s-s-d is failing to find the process.
This appears to be the same problem as bug #256790. If the running daemon's on disk binary has changed, the /proc/<pid>/exe will look something like: lrwxrwxrwx 1 root root 0 2005-11-07 13:22 exe -> /sbin/udevd (deleted) instead of lrwxrwxrwx 1 root root 0 2005-11-07 13:22 exe -> /sbin/udevd Could this be the source of the problem? I believe s-s-d is using /proc/pid/exe to see if the argument given is actually a running program. Would it be sensible to get s-s-d to match on the strings postfixed with " (deleted)" in order to avoid this problem? I don't know how kernel dependant that postfix string is though... It does make s-s-d completely unreliable in the presence of things like prelink at the moment. Perhaps prelink should be leaving the old binaries around (dotted-versions in the same directory perhaps?). Then /proc/<pid>/exe could look something like lrwxrwxrwx 1 root root 0 2005-11-07 13:22 exe -> /sbin/.udevd.original and perhaps s-s-d, prelink and anything else that likes to alter binaries could agree on a renaming scheme to match on. Then programs like prelink could simply check for running instances by rootling through /proc/<pid>/exe and leave a renamed binary around if they find one. s-s-d and co would then check for this renaming if they fail to find the requested running binary. cheers, Phil -- http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
