Debian Bug report logs - #619244
systemd: unowned files after purge (policy 6.8, 10.8): /etc/machine-id

version graph

Package: systemd; Maintainer for systemd is Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>; Source for systemd is src:systemd.

Reported by: Holger Levsen <holger@layer-acht.org>

Date: Tue, 22 Mar 2011 12:51:05 UTC

Severity: important

Found in versions systemd/37-1, systemd/37-1.1, systemd/43-1, systemd/204-6, systemd/44-12, systemd/204-7, systemd/44-1, systemd/44-7, 44-4, systemd/44-11, systemd/204-3, systemd/44-3, systemd/44-6, systemd/204-5, systemd/44-2, systemd/44-8, systemd/44-5, systemd/44-10, systemd/20-1, systemd/204-8

Reply or subscribe to this bug.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Tollef Fog Heen <tfheen@debian.org>:
Bug#619244; Package systemd. (Tue, 22 Mar 2011 12:51:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Holger Levsen <holger@layer-acht.org>:
New Bug report received and forwarded. Copy sent to Tollef Fog Heen <tfheen@debian.org>. (Tue, 22 Mar 2011 12:51:08 GMT) Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Holger Levsen <holger@layer-acht.org>
To: submit@bugs.debian.org
Subject: systemd: unowned files after purge (policy 6.8, 10.8)
Date: Tue, 22 Mar 2011 13:50:04 +0100
[Message part 1 (text/plain, inline)]
Package: systemd
Version: 20-1
Severity: important
User: debian-qa@lists.debian.org
Usertags: piuparts piuparts.d.o

Hi Tollef, 

during a test with piuparts I noticed your package left unowned files on the 
system after purge, which is a violation of policy 6.8 (or 10.8):

http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-removedetails

Filing this as important as having a piuparts clean archive is a release goal 
since lenny.

From the attached log (scroll to the bottom...):

0m42.7s ERROR: FAIL: Package purging left files on system:
  /etc/machine-id        not owned


cheers,
	Holger
[systemd_20-1.log (text/x-log, attachment)]
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Tollef Fog Heen <tfheen@debian.org>:
Bug#619244; Package systemd. (Tue, 13 Sep 2011 17:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Josh Triplett <josh@joshtriplett.org>:
Extra info received and forwarded to list. Copy sent to Tollef Fog Heen <tfheen@debian.org>. (Tue, 13 Sep 2011 17:45:03 GMT) Full text and rfc822 format available.

Message #10 received at 619244@bugs.debian.org (full text, mbox):

From: Josh Triplett <josh@joshtriplett.org>
To: 619244@bugs.debian.org
Subject: /etc/machine-id
Date: Tue, 13 Sep 2011 10:41:19 -0700
systemd does this quite intentionally, to set up a system's permanent
ID, which should exist unchanged for the life of the system.  (This used
to live in /var/lib/dbus/machine-id.)  It will only create that file if
it does not already exist, so one possible solution involves following
the recommendation of systemd upstream and generating /etc/machine-id
during the system installation.

On the other hand, I'm somewhat curious what upstream actually *uses*
the machine-id for, and why a machine needs a unique identifier.

- Josh Triplett




Bug Marked as found in versions systemd/37-1. Request was from Andreas Beckmann <debian@abeckmann.de> to control@bugs.debian.org. (Thu, 17 Nov 2011 02:33:04 GMT) Full text and rfc822 format available.

Bug Marked as found in versions systemd/37-1.1. Request was from Andreas Beckmann <debian@abeckmann.de> to control@bugs.debian.org. (Tue, 06 Mar 2012 08:33:10 GMT) Full text and rfc822 format available.

Bug Marked as found in versions systemd/43-1. Request was from Andreas Beckmann <debian@abeckmann.de> to control@bugs.debian.org. (Sat, 10 Mar 2012 16:42:04 GMT) Full text and rfc822 format available.

Marked as found in versions systemd/44-1. Request was from Andreas Beckmann <debian@abeckmann.de> to control@bugs.debian.org. (Wed, 11 Apr 2012 16:42:25 GMT) Full text and rfc822 format available.

Marked as found in versions systemd/44-2. Request was from Andreas Beckmann <debian@abeckmann.de> to control@bugs.debian.org. (Thu, 07 Jun 2012 05:33:10 GMT) Full text and rfc822 format available.

Marked as found in versions systemd/44-3. Request was from Andreas Beckmann <debian@abeckmann.de> to control@bugs.debian.org. (Sun, 01 Jul 2012 14:09:05 GMT) Full text and rfc822 format available.

Marked as found in versions 44-4. Request was from Andreas Beckmann <debian@abeckmann.de> to control@bugs.debian.org. (Sun, 22 Jul 2012 21:57:04 GMT) Full text and rfc822 format available.

Marked as found in versions systemd/44-5. Request was from Andreas Beckmann <debian@abeckmann.de> to control@bugs.debian.org. (Mon, 29 Oct 2012 10:33:09 GMT) Full text and rfc822 format available.

Changed Bug title to 'systemd: unowned files after purge (policy 6.8, 10.8): /etc/machine-id' from 'systemd: unowned files after purge (policy 6.8, 10.8)' Request was from Andreas Beckmann <debian@abeckmann.de> to control@bugs.debian.org. (Mon, 29 Oct 2012 10:33:09 GMT) Full text and rfc822 format available.

Marked as found in versions systemd/44-6. Request was from Andreas Beckmann <debian@abeckmann.de> to control@bugs.debian.org. (Mon, 17 Dec 2012 18:09:05 GMT) Full text and rfc822 format available.

Marked as found in versions systemd/44-7. Request was from Andreas Beckmann <debian@abeckmann.de> to control@bugs.debian.org. (Sat, 29 Dec 2012 23:45:07 GMT) Full text and rfc822 format available.

Marked as found in versions systemd/44-8. Request was from Andreas Beckmann <debian@abeckmann.de> to control@bugs.debian.org. (Sun, 20 Jan 2013 17:30:05 GMT) Full text and rfc822 format available.

Marked as found in versions systemd/44-10. Request was from Andreas Beckmann <anbe@debian.org> to control@bugs.debian.org. (Sat, 16 Feb 2013 17:15:04 GMT) Full text and rfc822 format available.

Marked as found in versions systemd/44-11. Request was from Andreas Beckmann <anbe@debian.org> to control@bugs.debian.org. (Fri, 15 Mar 2013 19:01:24 GMT) Full text and rfc822 format available.

Marked as found in versions systemd/44-12. Request was from Andreas Beckmann <anbe@debian.org> to control@bugs.debian.org. (Tue, 09 Jul 2013 11:57:09 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#619244; Package systemd. (Sun, 21 Jul 2013 11:27:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Stapelberg <stapelberg@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Sun, 21 Jul 2013 11:27:09 GMT) Full text and rfc822 format available.

Message #45 received at 619244@bugs.debian.org (full text, mbox):

From: Michael Stapelberg <stapelberg@debian.org>
To: Josh Triplett <josh@joshtriplett.org>, <619244@bugs.debian.org>
Subject: Re: /etc/machine-id
Date: Sun, 21 Jul 2013 13:23:48 +0200
Hi Josh,

Josh Triplett <josh@joshtriplett.org> writes:
> On the other hand, I'm somewhat curious what upstream actually *uses*
> the machine-id for, and why a machine needs a unique identifier.
The only use of the machine-id in Debian that I could find is within the
journal:

http://sources.debian.net/src/systemd/44-12/src/journal/journal-file.c?hl=130#L130

Given that the file replaces the old DBus machine-id, if you consider
that, we have a few more calls in the archive:

http://sources.debian.net/src/consolekit/0.4.5-3.1/src/ck-manager.c?hl=306#L306
http://sources.debian.net/src/kaa-base/0.6.0+svn4596-1/src/utils.py?hl=291#L291

Also, http://www.freedesktop.org/software/systemd/man/machine-id.html
explains:

  Programs may use this ID to identify the host with a globally unique
  ID in the network, which does not change even if the local network
  configuration changes. Due to this and its greater length, it is a
  more useful replacement for the gethostid(3) call that POSIX
  specifies.

While this is not a totally satisfactory answer, I hope it clarifies the
intention of this ID.

-- 
Best regards,
Michael



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#619244; Package systemd. (Sun, 21 Jul 2013 15:33:11 GMT) Full text and rfc822 format available.

Acknowledgement sent to Josh Triplett <josh@joshtriplett.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Sun, 21 Jul 2013 15:33:11 GMT) Full text and rfc822 format available.

Message #50 received at 619244@bugs.debian.org (full text, mbox):

From: Josh Triplett <josh@joshtriplett.org>
To: Michael Stapelberg <stapelberg@debian.org>
Cc: 619244@bugs.debian.org
Subject: Re: /etc/machine-id
Date: Sun, 21 Jul 2013 08:32:46 -0700
On Sun, Jul 21, 2013 at 01:23:48PM +0200, Michael Stapelberg wrote:
> Josh Triplett <josh@joshtriplett.org> writes:
> > On the other hand, I'm somewhat curious what upstream actually *uses*
> > the machine-id for, and why a machine needs a unique identifier.
> The only use of the machine-id in Debian that I could find is within the
> journal:
[...]
> Given that the file replaces the old DBus machine-id, if you consider
> that, we have a few more calls in the archive:
[...]
> Also, http://www.freedesktop.org/software/systemd/man/machine-id.html
> explains:

Thanks for the explanation.  That mail from me is quite old, and I'd
since found out a lot more about systemd and why it wants machine-id. :)

- Josh Triplett



Marked as found in versions systemd/204-3. Request was from Andreas Beckmann <anbe@debian.org> to control@bugs.debian.org. (Thu, 12 Sep 2013 21:33:12 GMT) Full text and rfc822 format available.

Marked as found in versions systemd/204-5. Request was from Andreas Beckmann <anbe@debian.org> to control@bugs.debian.org. (Wed, 16 Oct 2013 14:00:22 GMT) Full text and rfc822 format available.

Marked as found in versions systemd/204-6. Request was from Andreas Beckmann <anbe@debian.org> to control@bugs.debian.org. (Mon, 13 Jan 2014 21:51:12 GMT) Full text and rfc822 format available.

Marked as found in versions systemd/204-7. Request was from Andreas Beckmann <anbe@debian.org> to control@bugs.debian.org. (Thu, 20 Feb 2014 01:12:13 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#619244; Package systemd. (Fri, 21 Feb 2014 10:06:19 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon McVittie <smcv@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Fri, 21 Feb 2014 10:06:19 GMT) Full text and rfc822 format available.

Message #63 received at 619244@bugs.debian.org (full text, mbox):

From: Simon McVittie <smcv@debian.org>
To: Michael Stapelberg <stapelberg@debian.org>, 619244@bugs.debian.org
Cc: Josh Triplett <josh@joshtriplett.org>
Subject: Re: Bug#619244: /etc/machine-id
Date: Fri, 21 Feb 2014 10:05:52 +0000
On Sun, 21 Jul 2013 at 13:23:48 +0200, Michael Stapelberg wrote:
>   Programs may use this ID to identify the host with a globally unique
>   ID in the network, which does not change even if the local network
>   configuration changes. Due to this and its greater length, it is a
>   more useful replacement for the gethostid(3) call that POSIX
>   specifies.

I've wondered whether to ask base-files or some similarly core package
to provide /etc/machine-id so that it exists even on non-systemd systems;
it would be easy to populate from something like
"sed s/-// /proc/sys/kernel/random/uuid" on Linux, and perhaps
/dev/[u]random on non-Linux. Do you think that's a good idea?
It would have the side-effect of resolving this bug.

    S



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#619244; Package systemd. (Fri, 21 Feb 2014 14:09:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Martin Pitt <mpitt@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Fri, 21 Feb 2014 14:09:04 GMT) Full text and rfc822 format available.

Message #68 received at 619244@bugs.debian.org (full text, mbox):

From: Martin Pitt <mpitt@debian.org>
To: Simon McVittie <smcv@debian.org>, 619244@bugs.debian.org
Cc: Michael Stapelberg <stapelberg@debian.org>, Josh Triplett <josh@joshtriplett.org>
Subject: Re: [Pkg-systemd-maintainers] Bug#619244: /etc/machine-id
Date: Fri, 21 Feb 2014 06:04:42 -0800
Hello all,

Simon McVittie [2014-02-21 10:05 +0000]:
> I've wondered whether to ask base-files or some similarly core package
> to provide /etc/machine-id so that it exists even on non-systemd systems;
> it would be easy to populate from something like
> "sed s/-// /proc/sys/kernel/random/uuid" on Linux, and perhaps
> /dev/[u]random on non-Linux. Do you think that's a good idea?

I don't think it's a bad idea. But are non-systemd systems going to
care about this file at all? I've never quite liked this file as it
isn't really configuration but state; it should be in /var/lib
somewhere IMHO. But aside from that: if we don't get it in base-files,
we could at least do either of:

 * change systemd to read /var/lib/dbus/machine-id if /etc/machine-id
   does not exist (my preferred solution), or

 * change dbus-1 to create a symlink of /var/lib/dbus/machine-id to
   /etc/machine-id, if /etc/machine-id does not already exist.

With upcoming kdbus we might be able to drop dbus-1 in a few releases,
and then need to revisit this.

Thanks,

Martin

-- 
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#619244; Package systemd. (Fri, 21 Feb 2014 15:00:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Josh Triplett <josh@joshtriplett.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Fri, 21 Feb 2014 15:00:04 GMT) Full text and rfc822 format available.

Message #73 received at 619244@bugs.debian.org (full text, mbox):

From: Josh Triplett <josh@joshtriplett.org>
To: Simon McVittie <smcv@debian.org>
Cc: Michael Stapelberg <stapelberg@debian.org>, 619244@bugs.debian.org
Subject: Re: Bug#619244: /etc/machine-id
Date: Fri, 21 Feb 2014 06:57:15 -0800
On Fri, Feb 21, 2014 at 10:05:52AM +0000, Simon McVittie wrote:
> On Sun, 21 Jul 2013 at 13:23:48 +0200, Michael Stapelberg wrote:
> >   Programs may use this ID to identify the host with a globally unique
> >   ID in the network, which does not change even if the local network
> >   configuration changes. Due to this and its greater length, it is a
> >   more useful replacement for the gethostid(3) call that POSIX
> >   specifies.
> 
> I've wondered whether to ask base-files or some similarly core package
> to provide /etc/machine-id so that it exists even on non-systemd systems;
> it would be easy to populate from something like
> "sed s/-// /proc/sys/kernel/random/uuid" on Linux, and perhaps
> /dev/[u]random on non-Linux. Do you think that's a good idea?
> It would have the side-effect of resolving this bug.

That seems like a great idea.

- Josh Triplett



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#619244; Package systemd. (Fri, 21 Feb 2014 15:03:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Josh Triplett <josh@joshtriplett.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Fri, 21 Feb 2014 15:03:05 GMT) Full text and rfc822 format available.

Message #78 received at 619244@bugs.debian.org (full text, mbox):

From: Josh Triplett <josh@joshtriplett.org>
To: Martin Pitt <mpitt@debian.org>
Cc: Simon McVittie <smcv@debian.org>, 619244@bugs.debian.org, Michael Stapelberg <stapelberg@debian.org>
Subject: Re: [Pkg-systemd-maintainers] Bug#619244: /etc/machine-id
Date: Fri, 21 Feb 2014 07:01:35 -0800
On Fri, Feb 21, 2014 at 06:04:42AM -0800, Martin Pitt wrote:
> Simon McVittie [2014-02-21 10:05 +0000]:
> > I've wondered whether to ask base-files or some similarly core package
> > to provide /etc/machine-id so that it exists even on non-systemd systems;
> > it would be easy to populate from something like
> > "sed s/-// /proc/sys/kernel/random/uuid" on Linux, and perhaps
> > /dev/[u]random on non-Linux. Do you think that's a good idea?
> 
> I don't think it's a bad idea. But are non-systemd systems going to
> care about this file at all? I've never quite liked this file as it
> isn't really configuration but state; it should be in /var/lib
> somewhere IMHO.

I agree that it it provides state rather than configuration, but
/var/lib won't work, for much the same reason that led to making /run to
replace /var/run: /var can legitimately be a separately mounted
filesystem, and machine-id may well be needed early.  Unfortunately,
there's no /var-like persistent guaranteed-to-be-on-/ filesystem to use
here.  You could put machine-id in lib (/lib/machine-id), though that
doesn't really fit, but in any case you'll need a symlink from /etc.  At
which point you might as well just put it in /etc.

> But aside from that: if we don't get it in base-files,
> we could at least do either of:
> 
>  * change systemd to read /var/lib/dbus/machine-id if /etc/machine-id
>    does not exist (my preferred solution), or

See above: /var is too late.

>  * change dbus-1 to create a symlink of /var/lib/dbus/machine-id to
>    /etc/machine-id, if /etc/machine-id does not already exist.

Likewise.

- Josh Triplett



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#619244; Package systemd. (Sat, 22 Mar 2014 15:15:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to coldtobi <tobi@coldtobi.de>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Sat, 22 Mar 2014 15:15:05 GMT) Full text and rfc822 format available.

Message #83 received at 619244@bugs.debian.org (full text, mbox):

From: coldtobi <tobi@coldtobi.de>
To: Debian Bug Tracking System <619244@bugs.debian.org>
Subject: Re: systemd: unowned files after purge (policy 6.8, 10.8): /etc/machine-id
Date: Sat, 22 Mar 2014 16:12:55 +0100
Package: systemd
Version: 204-8
Followup-For: Bug #619244

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Maybe new imput:
On drizzle I had the same issue with database files.
My solution was to ask the user (debconf) if the files should be removed on
purge, and defaulted that to yes. This is compliant with the policy and you can
still explain why this file is needed and why systemd suggests to keep the
file. 

BTW, *why* does systemd needs this file to be constant? Google did not have an
answer for me... Do you have a pointer? I only found a reference that it can be
regenerated on stateless systems, so out of this I assume things will not break
if someone purges systemd and later reinstall it.

(Please note that this bug has a huge impact on piuparts testing, as all
packages directly and indirectly depending on systemd will not be tested until
this is fixed policy-like)

- -- Package-specific info:

- -- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages systemd depends on:
ii  acl                  2.2.52-1
ii  adduser              3.113+nmu3
ii  initscripts          2.88dsf-51
ii  libacl1              2.2.52-1
ii  libaudit1            1:2.3.4-1
ii  libc6                2.18-4
ii  libcap2              1:2.22-1.2
ii  libcap2-bin          1:2.22-1.2
ii  libcryptsetup4       2:1.6.4-4
ii  libdbus-1-3          1.8.0-2
ii  libgcrypt11          1.5.3-4
ii  libkmod2             16-2
ii  liblzma5             5.1.1alpha+20120614-2
ii  libpam0g             1.1.8-2
ii  libselinux1          2.2.2-1
ii  libsystemd-daemon0   204-8
ii  libsystemd-journal0  204-8
ii  libsystemd-login0    204-8
ii  libudev1             204-8
ii  libwrap0             7.6.q-25
ii  sysv-rc              2.88dsf-51
ii  udev                 204-8
ii  util-linux           2.20.1-5.6

Versions of packages systemd recommends:
ii  libpam-systemd  204-8

Versions of packages systemd suggests:
pn  systemd-ui  <none>

- -- no debconf information

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJTLah0AAoJEJFk+h0XvV02nIkQAKBkKd4e6Pf1OgZczo7cPPMq
Tgv0zDd2SWowHnkapR/bl+0qTK2z2HDTwm01nBRg0jD2FQ2mzTWWMjcuP+PVEN2C
rA+bNDQIJKVFUov3D5QkDjKdmfpOTkvwHcwaSIlJir0hQNLY940MC3blU1mRE57z
eQyX8/W0HovWDTH9EHRKc/2WL9gn+n3KtP0OzF6F/XQY8NrzggjQsE3tdeXsWj78
xhAYP9laDhvResevl1jIaeMCuyhcJH9an0HQD7BhW99eJwDWn2+6hc94k6Llh9nh
UlCnYiQN4JdcfeUN1/CSiQ+fCUEN35xiNYpsuu0Do/3y1qd2aFB0jvBbg/bV7spn
0Pfq8HVQRgLaKUq3CCkb2vxnFqAfryjoZ619sNX84gCPZUapMgS5oUG5cCxNdAu/
yaYIYM6SicUu8sjL274vFBzG5/YJGMsXMV93nvX9/Pd/B2QrDPMhde+eVSoEOhNg
6dVB4wF0ci96Ijypz5bI7DGKH63KXyTYpG7k507ltgo4DFK0SuxHRooVPOAzA7Qx
VqaEYV5RZcDhgKhcBFKeoPPR+W8q3k5kZkdosaB89a4tuf5egkHUHptK3piAHCU6
jZEG0LIwBbMuCjT9nvnCpc6wmlhatIK/4js0zpWfM6O3JRDziSEzRpMG5/cqwd7Q
5tX1FAm4h0IQPRk9SZqx
=zrK5
-----END PGP SIGNATURE-----



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#619244; Package systemd. (Mon, 14 Apr 2014 12:24:13 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Stapelberg <stapelberg@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Mon, 14 Apr 2014 12:24:13 GMT) Full text and rfc822 format available.

Message #88 received at 619244@bugs.debian.org (full text, mbox):

From: Michael Stapelberg <stapelberg@debian.org>
To: coldtobi <tobi@coldtobi.de>, Debian Bug Tracking System <619244@bugs.debian.org>
Subject: Re: [Pkg-systemd-maintainers] Bug#619244: systemd: unowned files after purge (policy 6.8, 10.8): /etc/machine-id
Date: Mon, 14 Apr 2014 14:22:40 +0200
Hi coldtobi,

coldtobi <tobi@coldtobi.de> writes:
> Maybe new imput:
> On drizzle I had the same issue with database files.
> My solution was to ask the user (debconf) if the files should be removed on
> purge, and defaulted that to yes. This is compliant with the policy and you can
> still explain why this file is needed and why systemd suggests to keep the
> file. 
I don’t think this is a good idea. Users should not be bothered with
technical details such as this just for following the policy to the word.

> BTW, *why* does systemd needs this file to be constant? Google did not have an
> answer for me... Do you have a pointer? I only found a reference that it can be
> regenerated on stateless systems, so out of this I assume things will not break
> if someone purges systemd and later reinstall it.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619244#45

> (Please note that this bug has a huge impact on piuparts testing, as all
> packages directly and indirectly depending on systemd will not be tested until
> this is fixed policy-like)
Then please work on fixing it…? :)

I think the best option (as discussed in this bug already) is to move
the file to a more central package like base-files.

-- 
Best regards,
Michael



Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#619244; Package systemd. (Mon, 14 Apr 2014 19:09:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tobias Frost <tobi@coldtobi.de>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Mon, 14 Apr 2014 19:09:04 GMT) Full text and rfc822 format available.

Message #93 received at 619244@bugs.debian.org (full text, mbox):

From: Tobias Frost <tobi@coldtobi.de>
To: Michael Stapelberg <stapelberg@debian.org>
Cc: Debian Bug Tracking System <619244@bugs.debian.org>
Subject: Re: [Pkg-systemd-maintainers] Bug#619244: systemd: unowned files after purge (policy 6.8, 10.8): /etc/machine-id
Date: Mon, 14 Apr 2014 21:05:44 +0200
[Message part 1 (text/plain, inline)]
Am Montag, den 14.04.2014, 14:22 +0200 schrieb Michael Stapelberg:
> Hi coldtobi,
> 
> coldtobi <tobi@coldtobi.de> writes:
> > Maybe new imput:
> > On drizzle I had the same issue with database files.
> > My solution was to ask the user (debconf) if the files should be removed on
> > purge, and defaulted that to yes. This is compliant with the policy and you can
> > still explain why this file is needed and why systemd suggests to keep the
> > file. 
> I don’t think this is a good idea. Users should not be bothered with
> technical details such as this just for following the policy to the word.

Well, I disagree... (Obviously otherwise I wouldn't have proposed it in
the first place). 
First, IMHO purging systemd will not be a task non-techies person will
do often, and the techie person how chooses to switch her init system to
something else will be indeed not be bugged by an debconf question and
be able to judge that technical detail.
Also, as the systemd folks writes [1] that there is no harm if the
system id is gone, because it allows for the exception of stateless
machines. 
So I see no backside, except that some people how know what they are
doing will see that debconf dialog and there they can be still eductated
why it is a bad idea(tm) to remove the machine-id. I actually still
think that would be quite elegant and almost no visibilty to user which
do not care about how systemd ticks.

[1] http://www.freedesktop.org/software/systemd/man/machine-id.html

(Additionally, I do not like the idea of another persitent tracking id
on my machine, and after searching the New I'm know that others share my
feelings; but that's off-topic now.) 

Earlier in this bugreport the idea to have this file also when the user
has no systemd installed was brought up: This theorectically forces
people how do not want to have this id on also to have it.
Somehow also a expectation one could have on Debian is if you purge a
package, everything is removed, leaving no traces. (Beside technical
limitations of course; but this id is no such technical limitation,
IMHO)    

My opinion on the policy is that the text makes sense, has a lots of
experience in it and was written on purpose that way it is. Frankly I
don't see why any package should be  excluded from the rules the policy
set up. (And there is always debian-policy to discuss in case its needed
to be changed/interprated/exceptions needed)


> > BTW, *why* does systemd needs this file to be constant? Google did not have an
> > answer for me... Do you have a pointer? I only found a reference that it can be
> > regenerated on stateless systems, so out of this I assume things will not break
> > if someone purges systemd and later reinstall it.
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619244#45

Maybe my question was poorly formulated: 
While this file describes the machine-id, I cannot read the purpose out
of your link: What are the benefits I (as user) would have from it and
why it would be bad to remove that file on purge ( which is already
quite unlikely, as layed out above). 

> > (Please note that this bug has a huge impact on piuparts testing, as all
> > packages directly and indirectly depending on systemd will not be tested until
> > this is fixed policy-like)
> Then please work on fixing it…? :)

That's why I proposed this solution in the first place. 
I don't see that this is a bug in piuparts, do you?

> I think the best option (as discussed in this bug already) is to move
> the file to a more central package like base-files.

I personally don't like that idea, because it moves files to a package
which has no business with the file: And that somehow feels wrong, not
warranted and not really intuitively  enough to me. Also this somehow
entangles people not wanting systemd-stuff on their system.

-- 
Tobi

[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#619244; Package systemd. (Mon, 14 Apr 2014 21:15:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Michael Biebl <biebl@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Mon, 14 Apr 2014 21:15:04 GMT) Full text and rfc822 format available.

Message #98 received at 619244@bugs.debian.org (full text, mbox):

From: Michael Biebl <biebl@debian.org>
To: Michael Stapelberg <stapelberg@debian.org>, 619244@bugs.debian.org, coldtobi <tobi@coldtobi.de>, Simon McVittie <smcv@debian.org>
Subject: Re: [Pkg-systemd-maintainers] Bug#619244: Bug#619244: systemd: unowned files after purge (policy 6.8, 10.8): /etc/machine-id
Date: Mon, 14 Apr 2014 23:12:39 +0200
[Message part 1 (text/plain, inline)]
Am 14.04.2014 14:22, schrieb Michael Stapelberg:
> Hi coldtobi,
> 
> coldtobi <tobi@coldtobi.de> writes:
>> Maybe new imput:
>> On drizzle I had the same issue with database files.
>> My solution was to ask the user (debconf) if the files should be removed on
>> purge, and defaulted that to yes. This is compliant with the policy and you can
>> still explain why this file is needed and why systemd suggests to keep the
>> file. 
> I don’t think this is a good idea. Users should not be bothered with
> technical details such as this just for following the policy to the word.

I agree. I don't want to add a debconf prompt for this. Aside from the
overhead, this just shifts the problem to the user.

>> BTW, *why* does systemd needs this file to be constant? Google did not have an
>> answer for me... Do you have a pointer? I only found a reference that it can be
>> regenerated on stateless systems, so out of this I assume things will not break
>> if someone purges systemd and later reinstall it.
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=619244#45
> 
>> (Please note that this bug has a huge impact on piuparts testing, as all
>> packages directly and indirectly depending on systemd will not be tested until
>> this is fixed policy-like)
> Then please work on fixing it…? :)
> 
> I think the best option (as discussed in this bug already) is to move
> the file to a more central package like base-files.

Fwiw, I wouldn't mind to unconditionally rm the file on purge in postrm
(we do the same for dbus wrt /var/lib/dbus/machine-id) given that no
other package relies on the file.

That said, I don't know if any other package relies on /etc/machine-id.
I do know that dbus makes use of it but I dunno all the details
regarding the /var/lib/dbus/machine-id fallback

Say we first install systemd, which generates /etc/machine-id, then
later dbus. Will in this case a /var/lib/dbus/machine-id file be created
or will dbus use /etc/machine-id?
In this case we can't remove /etc/machine-id again, as it would break
dbus, unless dbus would on-the-fly generate a /var/lib/dbus/machine-id
if no /etc/machine-id is available.

Maybe Simon knows more.

Regards,
Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[signature.asc (application/pgp-signature, attachment)]

Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#619244; Package systemd. (Tue, 15 Apr 2014 11:27:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon McVittie <smcv@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Tue, 15 Apr 2014 11:27:05 GMT) Full text and rfc822 format available.

Message #103 received at 619244@bugs.debian.org (full text, mbox):

From: Simon McVittie <smcv@debian.org>
To: Michael Biebl <biebl@debian.org>, Michael Stapelberg <stapelberg@debian.org>, 619244@bugs.debian.org, coldtobi <tobi@coldtobi.de>
Subject: Re: [Pkg-systemd-maintainers] Bug#619244: Bug#619244: systemd: unowned files after purge (policy 6.8, 10.8): /etc/machine-id
Date: Tue, 15 Apr 2014 12:25:26 +0100
On 14/04/14 22:12, Michael Biebl wrote:
> That said, I don't know if any other package relies on
> /etc/machine-id. I do know that dbus makes use of it but I dunno
> all the details regarding the /var/lib/dbus/machine-id fallback

libdbus, and other D-Bus implementations, read
/var/lib/dbus/machine-id or /etc/machine-id (in that order), taking
the contents of the first one that looks sane; except that systemd-bus
might do it the other way round, because Lennart.

> Say we first install systemd, which generates /etc/machine-id,
> then later dbus. Will in this case a /var/lib/dbus/machine-id file
> be created or will dbus use /etc/machine-id?

dbus.postinst runs dbus-uuidgen, which creates
/var/lib/dbus/machine-id, unless it already exists and has suitable
contents; if /var/lib/dbus/machine-id does not exist but
/etc/machine-id does, it does *not* copy /etc/machine-id to
/var/lib/dbus/machine-id, but instead creates an entirely new machine
ID in /var/lib/dbus/machine-id (which libdbus and GDBus will use in
preference to /etc/machine-id). I consider that to be a bug, tbh - it
should prefer to take the ID from /etc/machine-id and copy it into
/var/lib/dbus. I'd be happy to review patches upstream.

When it happens the other way round, I think systemd-machine-id-setup
*does* copy /var/lib/dbus/machine-id to /etc/machine-id rather than
creating its own.

> In this case we can't remove /etc/machine-id again, as it would
> break dbus, unless dbus would on-the-fly generate a
> /var/lib/dbus/machine-id if no /etc/machine-id is available.

/var/lib/dbus/machine-id is used by both root and unprivileged users,
but can only be set up by root, so creating it on-demand is not possible.

Ideally, I would like this to be done in base-files, but if that isn't
feasible, the next best thing would be for each of systemd and dbus to
copy the other's idea of the machine ID in preference to creating its own.

    S




Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#619244; Package systemd. (Tue, 15 Apr 2014 12:15:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Tobias Frost" <tobi@frost.de>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Tue, 15 Apr 2014 12:15:05 GMT) Full text and rfc822 format available.

Message #108 received at 619244@bugs.debian.org (full text, mbox):

From: "Tobias Frost" <tobi@frost.de>
To: "Simon McVittie" <smcv@debian.org>
Cc: "Michael Biebl" <biebl@debian.org>, "Michael Stapelberg" <stapelberg@debian.org>, 619244@bugs.debian.org, "coldtobi" <tobi@coldtobi.de>
Subject: Re: [Pkg-systemd-maintainers] Bug#619244: Bug#619244: systemd: unowned files after purge (policy 6.8, 10.8): /etc/machine-id
Date: Tue, 15 Apr 2014 14:10:58 +0200
Hi Simon,

Just finished my analysis of dbus but well, you answered faster...

For the curious, the code is here
http://sources.debian.net/src/dbus/1.8.0-3/dbus/dbus-sysdeps-unix.c?hl=3589#L3573

Maybe it is sufficient to agree on a load order, like switch the order dbus
tries to read the uuid? So first try /etc/machine-id and then its own...
(Of course systemd could first tries to read from dbus before trying
/etc/machine-id? But as systemd is supposed to start earlier, I guess, it is
probably better to have dbus read it first to avoid races)

I was just about to send the same th> On 14/04/14 22:12, Michael Biebl wrote:
>> That said, I don't know if any other package relies on
>> /etc/machine-id. I do know that dbus makes use of it but I dunno
>> all the details regarding the /var/lib/dbus/machine-id fallback
>
> libdbus, and other D-Bus implementations, read
> /var/lib/dbus/machine-id or /etc/machine-id (in that order), taking
> the contents of the first one that looks sane; except that systemd-bus
> might do it the other way round, because Lennart.
>
>> Say we first install systemd, which generates /etc/machine-id,
>> then later dbus. Will in this case a /var/lib/dbus/machine-id file
>> be created or will dbus use /etc/machine-id?
>
> dbus.postinst runs dbus-uuidgen, which creates
> /var/lib/dbus/machine-id, unless it already exists and has suitable
> contents; if /var/lib/dbus/machine-id does not exist but
> /etc/machine-id does, it does *not* copy /etc/machine-id to
> /var/lib/dbus/machine-id, but instead creates an entirely new machine
> ID in /var/lib/dbus/machine-id (which libdbus and GDBus will use in
> preference to /etc/machine-id). I consider that to be a bug, tbh - it
> should prefer to take the ID from /etc/machine-id and copy it into
> /var/lib/dbus. I'd be happy to review patches upstream.
>
> When it happens the other way round, I think systemd-machine-id-setup
> *does* copy /var/lib/dbus/machine-id to /etc/machine-id rather than
> creating its own.
>
>> In this case we can't remove /etc/machine-id again, as it would
>> break dbus, unless dbus would on-the-fly generate a
>> /var/lib/dbus/machine-id if no /etc/machine-id is available.
>
> /var/lib/dbus/machine-id is used by both root and unprivileged users,
> but can only be set up by root, so creating it on-demand is not possible.
>
> Ideally, I would like this to be done in base-files, but if that isn't
> feasible, the next best thing would be for each of systemd and dbus to
> copy the other's idea of the machine ID in preference to creating its own.
>
>     S
>

Tobi






Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#619244; Package systemd. (Tue, 15 Apr 2014 12:27:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Simon McVittie <smcv@debian.org>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Tue, 15 Apr 2014 12:27:04 GMT) Full text and rfc822 format available.

Message #113 received at 619244@bugs.debian.org (full text, mbox):

From: Simon McVittie <smcv@debian.org>
To: Tobias Frost <tobi@frost.de>
Cc: Michael Biebl <biebl@debian.org>, Michael Stapelberg <stapelberg@debian.org>, 619244@bugs.debian.org, coldtobi <tobi@coldtobi.de>
Subject: Re: [Pkg-systemd-maintainers] Bug#619244: Bug#619244: systemd: unowned files after purge (policy 6.8, 10.8): /etc/machine-id
Date: Tue, 15 Apr 2014 13:25:44 +0100
On 15/04/14 13:10, Tobias Frost wrote:
> Maybe it is sufficient to agree on a load order, like switch the order dbus
> tries to read the uuid?

If there is a conflict, I consider consistency with dbus-from-the-past
to be a higher priority than with systemd. Of course, if all goes well,
there shouldn't be a conflict - if both files exist then they should
have the same contents.

The failure mode, if different components see different machine IDs, is
that a component might think another component is running remotely.
That's not *so* bad.

> But as systemd is supposed to start earlier, I guess, it is
> probably better to have dbus read it first to avoid races)

What matters is the order in which their postinsts created the machine
IDs. I believe d-i still installs sysvinit as pid 1, and wheezy d-i
certainly does, so it seems reasonably likely that the sort of systems
where this question is relevant will install dbus (as a dependency for
task-desktop, for instance) before systemd. In that case, everything is
fine, because systemd copies dbus' idea of the machine ID.

The failing case is when dbus is installed second, and generates an
entirely new machine ID instead of copying systemd's. As I said, I'd be
happy to review a patch.

    S




Information forwarded to debian-bugs-dist@lists.debian.org, Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>:
Bug#619244; Package systemd. (Wed, 16 Apr 2014 05:45:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tobias Frost <tobi@frost.de>:
Extra info received and forwarded to list. Copy sent to Debian systemd Maintainers <pkg-systemd-maintainers@lists.alioth.debian.org>. (Wed, 16 Apr 2014 05:45:10 GMT) Full text and rfc822 format available.

Message #118 received at 619244@bugs.debian.org (full text, mbox):

From: Tobias Frost <tobi@frost.de>
To: Simon McVittie <smcv@debian.org>
Cc: Michael Biebl <biebl@debian.org>, Michael Stapelberg <stapelberg@debian.org>, 619244@bugs.debian.org
Subject: Re: [Pkg-systemd-maintainers] Bug#619244: Bug#619244: systemd: unowned files after purge (policy 6.8, 10.8): /etc/machine-id
Date: Wed, 16 Apr 2014 07:41:43 +0200
[Message part 1 (text/plain, inline)]
Hallo Simon

Am Dienstag, den 15.04.2014, 13:25 +0100 schrieb Simon McVittie:
> On 15/04/14 13:10, Tobias Frost wrote:
> > Maybe it is sufficient to agree on a load order, like switch the order dbus
> > tries to read the uuid?
> 
> If there is a conflict, I consider consistency with dbus-from-the-past
> to be a higher priority than with systemd. Of course, if all goes well,
> there shouldn't be a conflict - if both files exist then they should
> have the same contents.
> 
> The failure mode, if different components see different machine IDs, is
> that a component might think another component is running remotely.
> That's not *so* bad.
> 
> > But as systemd is supposed to start earlier, I guess, it is
> > probably better to have dbus read it first to avoid races)
> 
> What matters is the order in which their postinsts created the machine
> IDs. I believe d-i still installs sysvinit as pid 1, and wheezy d-i
> certainly does, so it seems reasonably likely that the sort of systems
> where this question is relevant will install dbus (as a dependency for
> task-desktop, for instance) before systemd. In that case, everything is
> fine, because systemd copies dbus' idea of the machine ID.

> The failing case is when dbus is installed second, and generates an
> entirely new machine ID instead of copying systemd's. As I said, I'd be
> happy to review a patch.

I hacked something together for discussion: 
In postinst, lets check for /etc/machine-id validity, and if it is valid
copy it to /var/lib/dbus/machine-id. (I prefered cp instead over links
to avoid dangling links if e.g systemd is purged; Just deleting won't
work either as there are some programs with hard-coded paths to dbus' id
without fallback to systemd's)  

However, I'm unsure if this needs to be handled: If dbus is updated and
the both machine-ids are different, dbus's machine-id-file will change
at runtime, which could cause problems according dbus-uuidgen(1). 
Is this really a problem, as the user will be prompted for a reboot
anyway? 
In this case the only option would be to fix this when dbus starts or
live with the different ids until the admin fixed it manually.

-- 
Tobi
[dbus.postinst.patch (text/x-patch, attachment)]

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Apr 16 16:37:02 2014; Machine Name: buxtehude.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.