Bug 722096 – sys-apps/gentoo-systemd-integration gentoo-run.conf, sys-apps/systemd legacy.conf conflicting /run/lock groups

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Duncan 2020-05-10 10:51:43 UTC]

Conflicting tmpfiles.d group setting for /run/lock:

sys-apps/gentoo-systemd-integration: 
/usr/lib/tmpfiles.d/gentoo-run.conf:
d /run/lock 0775 root uucp -

sys-apps/systemd:
/usr/lib/tmpfiles.d/legacy.conf:
d /run/lock 0755 root root -

/usr/lib/tmpfiles.d doesn't appear to be in CONFIG_PROTECT so local changes in either file would be overwritten on package upgrade.

The actual on-tmpfs group on my system at least is uucp so it appears the gentoo-systemd-integration/gentoo-run.conf setting is taking precedence.  But journald has a duplicate-path-entry complaint (showing up in red), thus triggering my discovery of the conflict and ultimately this bug filing:

systemd-tmpfiles[18866]: /lib/tmpfiles.d/legacy.conf:13] Duplicate line for path "/run/lock", ignoring.


Being on systemd w/o openrc installed I'm not sure if it, or indeed any other package, has other tmpfiles.d settings for the /run/lock dir itself.

There's related history in bug #576968 (gentoo-systemd-integration) which in turn references the ancient (long pre-systemd) bug #17738.

(I thought about downgrading severity to minor as I'm unaware of any real problems this triggers, tho OTOH it could in theory have security implications which could justify raising it, so left deciding that to others.)

[Comment 1 Mike Gilbert 2020-05-13 00:43:10 UTC]

https://gitweb.gentoo.org/proj/gentoo-systemd-integration.git/commit/?id=042e5b8d0e84bfa2ba592a04a1dc9d529a206b7b

[Comment 2 Duncan 2020-12-13 14:16:38 UTC]

(In reply to Mike Gilbert from comment #1)
> https://gitweb.gentoo.org/proj/gentoo-systemd-integration.git/commit/
> ?id=042e5b8d0e84bfa2ba592a04a1dc9d529a206b7b

[checking the status of still-open old bugs I filed]

@ floppym and gentoo-systemd team: Gentle bump.

That commit to gentoo-systemd-integration.git was back in May (2020) and the apparent then-and-still-current gentoo-systemd-integration-0.8 was in-tree over a year ago in December of 2019 (based on the date of my binpkg).  Is a release with that commit included and close of associated bugs appropriate?

[Comment 3 Larry the Git Cow 2020-12-14 23:10:10 UTC]

The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8ec73ff87f5e8a160372f0b7369a0cc246f76c3d

commit 8ec73ff87f5e8a160372f0b7369a0cc246f76c3d
Author:     Mike Gilbert <[e-mail]>
AuthorDate: 2020-12-14 23:08:03 +0000
Commit:     Mike Gilbert <[e-mail]>
CommitDate: 2020-12-14 23:09:45 +0000

    sys-apps/gentoo-systemd-integration: bump to v9
    
    Closes: https://bugs.gentoo.org/722096
    Signed-off-by: Mike Gilbert <[e-mail]>

 sys-apps/gentoo-systemd-integration/Manifest       |  1 +
 .../gentoo-systemd-integration-9.ebuild            | 30 ++++++++++++++++++++++
 .../gentoo-systemd-integration-9999.ebuild         | 12 ++++-----
 3 files changed, 36 insertions(+), 7 deletions(-)