Bug#761306: Bug#771101: Bug#761306: Bug#771101: wheezy - jessie dist-upgrade failure when systemd is the active PID1
On Mon, 1 Dec 2014 21:54:08 +0100 Sjoerd Simons sjo...@luon.net wrote: No pretty sure it was from v208 directly. I was just re-reading the code of upstream system again it it looks like upstream now removes the old socket file right before calling bind: f0e62e89970b8c38eb07a9beebd277ce13a5fcc2 We probably should backport that one, which should solve both issues. I did re-run the wheezy-jessie dist-upgrade test with this patch applied, and I can confirm it fixes the issue as well and is certainly nice then running rm -f in postinst. Thanks, Sjoerd for digging out this patch. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#761306: Bug#771101: Bug#761306: Bug#771101: wheezy - jessie dist-upgrade failure when systemd is the active PID1
On Thu, Nov 27, 2014 at 05:48:45PM +0100, Michael Biebl wrote: Am 27.11.2014 um 16:41 schrieb Michael Biebl: Am 27.11.2014 um 15:59 schrieb Michael Biebl: I would have expected, that the socket does *not* exist before systemd is re-execd, but apparently I had a file there: srw-rw-rw- 1 root root 0 Oct 10 10:41 /run/systemd/notify and no process listening on it. (don't worry about the date, it was run in a VM with a busted clock). *Some* process is triggering the creation of the notification socket and it also seems to have the wrong permissions (should be srwxrwxrwx). It's actually a bit simpler: v44 *did* already use /run/systemd/notify (with permissions srw-rw-rw-), then it was changed to use an abstract namespace and it was changed back and forth a couple of times. Maybe a simple chmod will do when upgrading from v44. Will test. Sjoerd, you mentioned in your bug report, that you upgraded from v208-v215 v208 uses an abstract socket though, so I'm not sure if it's actually the same issue. Did you maybe first upgrade from v44 to v208 and then did the dist-upgrade to v215? No pretty sure it was from v208 directly. I was just re-reading the code of upstream system again it it looks like upstream now removes the old socket file right before calling bind: f0e62e89970b8c38eb07a9beebd277ce13a5fcc2 We probably should backport that one, which should solve both issues. -- Fill what's empty, empty what's full, scratch where it itches. -- Alice Roosevelt Longworth -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#771101: wheezy - jessie dist-upgrade failure when systemd is the active PID1
Processing control commands: reassign -1 systemd Bug #771101 [udev] wheezy - jessie dist-upgrade failure when systemd is the active PID1 Bug reassigned from package 'udev' to 'systemd'. No longer marked as found in versions systemd/215-6. Ignoring request to alter fixed versions of bug #771101 to the same values previously set forcemerge -1 761306 Bug #771101 [systemd] wheezy - jessie dist-upgrade failure when systemd is the active PID1 Bug #761306 [systemd] v208 - v215 upgrade fails to re-open notification socket Severity set to 'serious' from 'normal' Bug #771101 [systemd] wheezy - jessie dist-upgrade failure when systemd is the active PID1 Marked as found in versions systemd/215-2. Merged 761306 771101 -- 761306: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761306 771101: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771101 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771101: wheezy - jessie dist-upgrade failure when systemd is the active PID1
control: reassign -1 systemd control: forcemerge -1 761306 Am 27.11.2014 um 02:49 schrieb Michael Biebl: control: forcemerge -1 761306 Am 26.11.2014 um 23:06 schrieb Michael Biebl: I think, that's the relevant part from the journal, specifically: Nov 26 19:36:57 debian systemd[1]: bind(@run/systemd/notify) failed: Address already in use Nov 26 19:36:57 debian systemd[1]: Failed to reload: Address already in use Running lsof /run/systemd/notify, doesn't show any process listening on the socket. systemd-udevd in v215 uses Type=notify and I suspect it get's stuck in State activating since the sd_notify call doesn't succeed. I remember Sjoerd running into this issue as well, but I don't remember anymore if he found the root cause and how to fix it. I think it's the same bug as [1] and since this affects the dist-upgrade from wheezy, I think a RC severity is justified. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761306 The notification socket changed from being in the abstract namespace to /run/systemd/notify in v209 IIRC. I made an interesting observation: I've added an ls -la /run/systemd/notify and lsof /run/systemd/notify in systemd.postinst right before systemd is re-execd. I would have expected, that the socket does *not* exist before systemd is re-execd, but apparently I had a file there: srw-rw-rw- 1 root root 0 Oct 10 10:41 /run/systemd/notify and no process listening on it. (don't worry about the date, it was run in a VM with a busted clock). *Some* process is triggering the creation of the notification socket and it also seems to have the wrong permissions (should be srwxrwxrwx). So I've tried and added a brute-force rm -f /run/systemd/notify right before the systemctl daemon-reexec and the upgrade of the systemd and udev package completed successfully. Does anyone have an idea what's going on here and how to fix it properly? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#771101: Bug#761306: Bug#771101: wheezy - jessie dist-upgrade failure when systemd is the active PID1
Am 27.11.2014 um 15:59 schrieb Michael Biebl: I would have expected, that the socket does *not* exist before systemd is re-execd, but apparently I had a file there: srw-rw-rw- 1 root root 0 Oct 10 10:41 /run/systemd/notify and no process listening on it. (don't worry about the date, it was run in a VM with a busted clock). *Some* process is triggering the creation of the notification socket and it also seems to have the wrong permissions (should be srwxrwxrwx). It's actually a bit simpler: v44 *did* already use /run/systemd/notify (with permissions srw-rw-rw-), then it was changed to use an abstract namespace and it was changed back and forth a couple of times. Maybe a simple chmod will do when upgrading from v44. Will test. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#771101: Bug#761306: Bug#771101: wheezy - jessie dist-upgrade failure when systemd is the active PID1
Am 27.11.2014 um 16:41 schrieb Michael Biebl: It's actually a bit simpler: v44 *did* already use /run/systemd/notify (with permissions srw-rw-rw-), then it was changed to use an abstract namespace and it was changed back and forth a couple of times. Maybe a simple chmod will do when upgrading from v44. Will test. Just tested, a chmod 777 is not sufficient. systemd will still fail to bind to the socket. Only removing it and letting systemd create it on daemon-reexec seems to do the trick. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#761306: Bug#771101: Bug#761306: Bug#771101: wheezy - jessie dist-upgrade failure when systemd is the active PID1
Am 27.11.2014 um 16:41 schrieb Michael Biebl: Am 27.11.2014 um 15:59 schrieb Michael Biebl: I would have expected, that the socket does *not* exist before systemd is re-execd, but apparently I had a file there: srw-rw-rw- 1 root root 0 Oct 10 10:41 /run/systemd/notify and no process listening on it. (don't worry about the date, it was run in a VM with a busted clock). *Some* process is triggering the creation of the notification socket and it also seems to have the wrong permissions (should be srwxrwxrwx). It's actually a bit simpler: v44 *did* already use /run/systemd/notify (with permissions srw-rw-rw-), then it was changed to use an abstract namespace and it was changed back and forth a couple of times. Maybe a simple chmod will do when upgrading from v44. Will test. Sjoerd, you mentioned in your bug report, that you upgraded from v208-v215 v208 uses an abstract socket though, so I'm not sure if it's actually the same issue. Did you maybe first upgrade from v44 to v208 and then did the dist-upgrade to v215? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#771101: wheezy - jessie dist-upgrade failure when systemd is the active PID1
Am 26.11.2014 um 19:54 schrieb Michael Biebl: Nov 26 19:36:57 debian systemd[1]: Reloading. Nov 26 19:36:57 debian systemd[1]: bind(@run/systemd/notify) failed: Address already in use Nov 26 19:36:57 debian systemd[1]: Failed to reload: Address already in use Nov 26 19:36:59 debian groupadd[19888]: group added to /etc/group: name=input, GID=122 Nov 26 19:36:59 debian groupadd[19888]: group added to /etc/gshadow: name=input Nov 26 19:36:59 debian groupadd[19888]: new group: name=input, GID=122 Nov 26 19:36:59 debian systemd[1]: Stopping udev.service... Nov 26 19:36:59 debian systemd[1]: Stopped udev.service. Nov 26 19:36:59 debian systemd[1]: Stopping udev Control Socket. Nov 26 19:36:59 debian systemd[1]: Closed udev Control Socket. Nov 26 19:36:59 debian systemd[1]: Stopping udev Kernel Socket. Nov 26 19:36:59 debian systemd[1]: Closed udev Kernel Socket. Nov 26 19:36:59 debian systemd[1]: Reloading. Nov 26 19:36:59 debian systemd[1]: bind(@run/systemd/notify) failed: Address already in use Nov 26 19:36:59 debian systemd[1]: Failed to reload: Address already in use Nov 26 19:36:59 debian systemd[1]: Reloading. Nov 26 19:36:59 debian systemd[1]: bind(@run/systemd/notify) failed: Address already in use Nov 26 19:36:59 debian systemd[1]: Failed to reload: Address already in use Nov 26 19:36:59 debian systemd[1]: Starting udev Kernel Socket. Nov 26 19:36:59 debian systemd[1]: Listening on udev Kernel Socket. Nov 26 19:36:59 debian systemd[1]: Starting udev Control Socket. Nov 26 19:36:59 debian systemd[1]: Listening on udev Control Socket. Nov 26 19:36:59 debian systemd[1]: Starting udev Kernel Device Manager... Nov 26 19:36:59 debian systemd-udevd[19952]: Network interface NamePolicy= disabled on kernel commandline, ignoring. Nov 26 19:37:56 debian systemd[1]: systemd-journald.service watchdog timeout (limit 1min)! Nov 26 19:37:56 debian systemd-journal[19434]: Journal stopped Nov 26 19:37:56 debian systemd[1]: Starting Trigger Flushing of Journal to Persistent Storage... Nov 26 19:37:56 debian systemd[1]: Started Trigger Flushing of Journal to Persistent Storage. Nov 26 19:38:29 debian systemd[1]: systemd-udevd.service start operation timed out. Terminating. Nov 26 19:38:29 debian systemd[1]: Failed to start udev Kernel Device Manager. I think, that's the relevant part from the journal, specifically: Nov 26 19:36:57 debian systemd[1]: bind(@run/systemd/notify) failed: Address already in use Nov 26 19:36:57 debian systemd[1]: Failed to reload: Address already in use Running lsof /run/systemd/notify, doesn't show any process listening on the socket. systemd-udevd in v215 uses Type=notify and I suspect it get's stuck in State activating since the sd_notify call doesn't succeed. I remember Sjoerd running into this issue as well, but I don't remember anymore if he found the root cause and how to fix it. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#771101: wheezy - jessie dist-upgrade failure when systemd is the active PID1
control: forcemerge -1 761306 Am 26.11.2014 um 23:06 schrieb Michael Biebl: I think, that's the relevant part from the journal, specifically: Nov 26 19:36:57 debian systemd[1]: bind(@run/systemd/notify) failed: Address already in use Nov 26 19:36:57 debian systemd[1]: Failed to reload: Address already in use Running lsof /run/systemd/notify, doesn't show any process listening on the socket. systemd-udevd in v215 uses Type=notify and I suspect it get's stuck in State activating since the sd_notify call doesn't succeed. I remember Sjoerd running into this issue as well, but I don't remember anymore if he found the root cause and how to fix it. I think it's the same bug as [1] and since this affects the dist-upgrade from wheezy, I think a RC severity is justified. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761306 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Processed (with 1 errors): Re: Bug#771101: wheezy - jessie dist-upgrade failure when systemd is the active PID1
Processing control commands: forcemerge -1 761306 Bug #771101 [udev] wheezy - jessie dist-upgrade failure when systemd is the active PID1 Unable to merge bugs because: package of #761306 is 'systemd' not 'udev' Failed to forcibly merge 771101: Did not alter merged bugs -- 761306: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=761306 771101: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=771101 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
