Bug#352554: 2/3
Can you reproduce this bug with the latest udev version or should I close it? -- ciao, Marco signature.asc Description: Digital signature
Bug#352554: 2/3
tag 352554 unreproducible thanks On Thu, Mar 02, 2006 at 01:35:46PM +0100, Marco d'Itri wrote: Can you reproduce this bug with the latest udev version or should I close it? Please let's keep it opened, since terminating random processes as root is quite bad, doesn't seem to be just a hypothetical thing, and did happen twice on independent systems. I don't have any insights as to how it can happen, though. Perhaps .. two udev upgrades? Perhaps rebooting (or not) between the previous udev update and the current one? That there is no pidfile pretty much stumps me.. I don't know. dpkg people, is there an explanation for this? s-s-d apparently tried tried to send a signal to a PID which wasn't running; this happened twice on two independent machines, so I don't think it can be a simple race between stating /proc/$pid/stat and calling kill(). Thanks Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352554: 2/3
On Thu, Mar 02, 2006 at 09:59:18AM -0500, pryzbyj wrote: tag 352554 unreproducible thanks On Thu, Mar 02, 2006 at 01:35:46PM +0100, Marco d'Itri wrote: Can you reproduce this bug with the latest udev version or should I close it? Please let's keep it opened, since terminating random processes as root is quite bad, doesn't seem to be just a hypothetical thing, and did happen twice on independent systems. What do you think about using s-s-d --exec /sbin/udevd instead of --name? This seems more safe (although the problem is still not understood). Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352554: 2/3
On Mar 02, Justin Pryzby [EMAIL PROTECTED] wrote: What do you think about using s-s-d --exec /sbin/udevd instead of --name? This seems more safe (although the problem is still not --exec is bad and nobody should use it, ever. I stopped long ago because it caused too many problems. -- ciao, Marco signature.asc Description: Digital signature
Bug#352554: 2/3
I had this problem on 2/3 machines I upgraded today. The upgrade that worked was from 0.076-6; the other two were from 0.081-1. I donno if thats relevant. The latest upgrade was also from a held state after dist-upgrading everything else (except firefox), and the already-running udev on that system had a PID of 2460, not 700-800. I don't know what the PID of the first 2 udevs were, though, and I don't know that the failed to kill message wasn't for a PID that udev used to have. I wonder if perhaps the udev daemon was killed by something other than s-s-d, or by some earlier part of s-s-d? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352554: 2/3
On Feb 13, [EMAIL PROTECTED] wrote: I had this problem on 2/3 machines I upgraded today. The upgrade that worked was from 0.076-6; the other two were from 0.081-1. I donno if thats relevant. I doubt it, both versions use s-d-d --name. I wonder if perhaps the udev daemon was killed by something other than s-s-d, The error message you reported had the s-s-d prefix. or by some earlier part of s-s-d? I do not know what this means. -- ciao, Marco signature.asc Description: Digital signature
Bug#352554: 2/3
On Feb 13, Justin Pryzby [EMAIL PROTECTED] wrote: I meant if udev got killed either before s-s-d was even started, or if s-s-d somehow tried to kill it twice, and failed on the second attempt. I only checked 0.081-1, but the upgrade path uses start-stop-daemon --oknodo. Maybe s-s-d complains if --retry is used and udevd exits between the first and second signals sent? -- ciao, Marco signature.asc Description: Digital signature
Bug#352554: 2/3
On Mon, Feb 13, 2006 at 03:02:04PM +0100, Marco d'Itri wrote: On Feb 13, [EMAIL PROTECTED] wrote: I had this problem on 2/3 machines I upgraded today. The upgrade that worked was from 0.076-6; the other two were from 0.081-1. I donno if thats relevant. I doubt it, both versions use s-d-d --name. I wonder if perhaps the udev daemon was killed by something other than s-s-d, The error message you reported had the s-s-d prefix. or by some earlier part of s-s-d? I do not know what this means. I meant if udev got killed either before s-s-d was even started, or if s-s-d somehow tried to kill it twice, and failed on the second attempt. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#352554: 2/3
On Mon, Feb 13, 2006 at 03:09:03PM +0100, Marco d'Itri wrote: On Feb 13, Justin Pryzby [EMAIL PROTECTED] wrote: I meant if udev got killed either before s-s-d was even started, or if s-s-d somehow tried to kill it twice, and failed on the second attempt. I only checked 0.081-1, but the upgrade path uses start-stop-daemon --oknodo. Maybe s-s-d complains if --retry is used and udevd exits between the first and second signals sent? Yes, this is kind of what I was thinking, but I can't confirm it with a test process. Also, 2/3 seems way too often for a simple race: char buf[15]; snprintf(buf, sizeof(buf), /proc/%d/stat, pid) if (fp=fopen(buf, r)) kill(pid, sig); fclose(fp); } Which is essentially what s-s-d does. Unless something is broken in the algorithm which could of course explain it. Justin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
