Bug#761306: Bug#771101: Bug#761306: Bug#771101: wheezy - jessie dist-upgrade failure when systemd is the active PID1

2014-12-03 Thread Michael Biebl
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

2014-12-01 Thread Sjoerd Simons
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



Bug#761306: Bug#771101: Bug#761306: Bug#771101: wheezy - jessie dist-upgrade failure when systemd is the active PID1

2014-11-27 Thread Michael Biebl
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