Fwd: Archived bug #1002993 seems to be related to unprivileged containers

[Michael Biebl]

 Weitergeleitete Nachricht 
Betreff: Archived bug #1002993 seems to be related to unprivileged 
containers

Datum: Tue, 3 Sep 2024 21:24:25 +0200
Von: Dr. Lars Hanke 
An: bi...@debian.org

Dear Michael,

well, I know the bug has been archived, but  I just saw exactly the same
behavior updating Debian11 to systemd 247.3-7+deb11u6 on amd64. Updates
on privileged containers produced no issues. It happens with
libudev1:amd64. This is from the apt upgrade log:


Vorbereitung zum Entpacken von .../5-libudev1_247.3-7+deb11u6_amd64.deb ...
Entpacken von libudev1:amd64 (247.3-7+deb11u6) über (247.3-7+deb11u5)...
libudev1:amd64 (247.3-7+deb11u6) wird eingerichtet ...
systemd (247.3-7+deb11u6) wird eingerichtet ...
Setting access ACL
"u::rwx,g::r-x,g:adm:r-x,g:4294967295:r-x,m::r-x,o::r-x" on
/var/log/journal failed: Invalid argument
Setting access ACL
"u::rwx,g::r-x,g:adm:r-x,g:4294967295:r-x,m::r-x,o::r-x" on
/var/log/journal/50c8cff5a8de4c2fa08f91b6525115a5 failed: Invalid argument
Setting access ACL
"u::rw-,g::r-x,g:adm:r--,g:4294967295:r-x,m::r--,o::---" on
/var/log/journal/50c8cff5a8de4c2fa08f91b6525115a5/system.journal failed:
Invalid argument
(Lese Datenbank ... 23418 Dateien und Verzeichnisse sind derzeit
installiert.)

Entering the container I can display the ACL and actually set the
requested ACL, which adds the ACL for group "adm":

root@saraswati:/var/log/journal# getfacl .
# file: .
# owner: root
# group: systemd-journal
# flags: -s-
user::rwx
group::r-x
group:4294967295:r-x
mask::r-x
other::r-x
default:user::rwx
default:group::r-x
default:group:4294967295:r-x
default:mask::r-x
default:other::r-x

root@saraswati:/var/log/journal# setfacl --set
"u::rwx,g::r-x,g:adm:r-x,g:4294967295:r-x,m::r-x,o::r-x" .
root@saraswati:/var/log/journal# getfacl .
# file: .
# owner: root
# group: systemd-journal
# flags: -s-
user::rwx
group::r-x
group:adm:r-x
mask::r-x
other::r-x
default:user::rwx
default:group::r-x
default:group:4294967295:r-x
default:mask::r-x
default:other::r-x

So, there seems to be something wierd in the setup scripts, which does
not work in unprivileged containers.

A sidenote: At first I tried to use "-m" instead of "--set", which
failed with "double entry in entry 4" (translated from German). I don't
know if this is the expected behavior or a quirk of the container.




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1074789: daemon-rexec no longer reopens /run/systemd/userdb/io.systemd.DynamicUser

[Michael Biebl]

Am 20.07.24 um 17:44 schrieb Michael Biebl:

Am 20.07.24 um 17:40 schrieb Michael Biebl:

Am 20.07.24 um 17:36 schrieb Michael Biebl:
Btw, I vaguely remember successfully testing dist-upgrades of a GNOME 
installation from bullseye to bookworm. So I suspect this was broken 
by one of the latest stable updates


Just tested this by upgrading
247.3-7+deb11u4 → 252.6-1 (snapshots.d.o) → systemd listens on the 
socket after the upgrade


247.3-7+deb11u4 → 252.26-1~deb12u2 (bookworm) → systemd *does not* 
listen on the socket after the upgrade


Given that these bug reports started popping up only recently, my guess 
is that it's one of the more recent systemd stable updates like 
252.26-1~deb12u2 which regressed.


git bisect shows 
https://github.com/systemd/systemd-stable/commit/a5fd23650dc as the 
first faulty commit:



core/varlink: make sure we setup non-serialized varlink sockets

Before this PR, if m->varlink_server is not yet set up during
deserialization, we call manager_setup_varlink_server rather than
manager_varlink_init, the former of which doesn't setup varlink
addresses, but only binds to methods. This results in that
newly-added varlink addresses not getting created if deserialization
takes place.

Therefore, let's switch to manager_varlink_init, and add some
sanity checks to it in order to prevent listening on the same
address twice.


Reverting that fixes daemon-reexec on upgrades.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1074789: daemon-rexec no longer reopens /run/systemd/userdb/io.systemd.DynamicUser

[Michael Biebl]

Am 20.07.24 um 17:40 schrieb Michael Biebl:

Am 20.07.24 um 17:36 schrieb Michael Biebl:
Btw, I vaguely remember successfully testing dist-upgrades of a GNOME 
installation from bullseye to bookworm. So I suspect this was broken 
by one of the latest stable updates


Just tested this by upgrading
247.3-7+deb11u4 → 252.6-1 (snapshots.d.o) → systemd listens on the 
socket after the upgrade


247.3-7+deb11u4 → 252.26-1~deb12u2 (bookworm) → systemd *does not* 
listen on the socket after the upgrade


Given that these bug reports started popping up only recently, my guess 
is that it's one of the more recent systemd stable updates like 
252.26-1~deb12u2 which regressed.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1074789: daemon-rexec no longer reopens /run/systemd/userdb/io.systemd.DynamicUser

[Michael Biebl]

Am 20.07.24 um 17:36 schrieb Michael Biebl:
Btw, I vaguely remember successfully testing dist-upgrades of a GNOME 
installation from bullseye to bookworm. So I suspect this was broken by 
one of the latest stable updates


Just tested this by upgrading
247.3-7+deb11u4 → 252.6-1 (snapshots.d.o) → systemd listens on the 
socket after the upgrade


247.3-7+deb11u4 → 252.26-1~deb12u2 (bookworm) → systemd *does not* 
listen on the socket after the upgrade


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1074789: Use SYSTEMD_NSS_DYNAMIC_BYPASS=1 ?

[Michael Biebl]

Am 20.07.24 um 17:24 schrieb Michael Biebl:

Control: severity -1 serious

I can reproduce the "Failed to check if group polkitd already exists: 
Connection refused" error in a bullseye VM that is dist-upgraded to 
bookworm.


systemd v247 before the upgrade listens on 
/run/systemd/userdb/io.systemd.DynamicUser


once systemd has been upgraded to v252 and reexecd in postinst, systemd 
no longer listens on this socket.



...


Afterwards, PID 1 no longer listens on the socket.
I assume that something goes wrong during the daemon-reexec causing systemd to 
reopen the socket.
Any subsequent call to systemd-sysusers then fails.





Btw, I vaguely remember successfully testing dist-upgrades of a GNOME 
installation from bullseye to bookworm. So I suspect this was broken by 
one of the latest stable updates


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1074789: Use SYSTEMD_NSS_DYNAMIC_BYPASS=1 ?

[Michael Biebl]

Control: severity -1 serious

I can reproduce the "Failed to check if group polkitd already exists: 
Connection refused" error in a bullseye VM that is dist-upgraded to 
bookworm.


systemd v247 before the upgrade listens on 
/run/systemd/userdb/io.systemd.DynamicUser


once systemd has been upgraded to v252 and reexecd in postinst, systemd 
no longer listens on this socket.


So, the minimal reproducer is to install a bullseye VM, enable bookworm 
in /etc/apt/sources.list and run "apt install systemd"


Afterwards, PID 1 no longer listens on the socket.
I assume that something goes wrong during the daemon-reexec causing 
systemd to reopen the socket.

Any subsequent call to systemd-sysusers then fails.

As shown by #1076506 and the duplicates in the debian forum, I'd say 
this should be fixed via a stable update.

I'm also bumping this to RC.


A typescript of the minimal reproducer is attached.


Michael




typescript
Description: Binary data


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [Pkg-utopia-maintainers] Bug#1076506: Bug#1076506: polkitd: Strange polkit related error upgrading to bookworm

[Michael Biebl]

Control: reassign -1 systemd

I am going to reassign this to systemd, which ships systemd-sysusers

The forum discussion you referenced mentioned two failures from 
systemd-sysusers https://forums.debian.net/viewtopic.php?t=156286:



1/
Creating group 'polkitd' with GID 997.
Creating user 'polkitd' (polkit) with UID 997 and GID 997.
Failed to add existing group "adm" to temporary group file: Invalid argument


2/
Failed to check if group polkitd already exists: Connection refused
id: ‘polkitd’: no such user
chown: invalid user: ‘polkitd:root’

2/ is https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1074789


You haven't supplied any error message from polkitd postinst so far, so 
my educated guess was that it was 2/ for you as well.


But since we don't have this information, we can't be certain. The only 
thing I can say for sure is that polkitd failed because systemd-sysusers 
failed to create the polkitd user which makes this a systemd issue. Thus 
reassigning.


Michael


Am 20.07.24 um 14:58 schrieb Andreas Tille:

Control: tags -1 - moreinfo

Hi again,

Am Wed, Jul 17, 2024 at 06:15:06PM +0200 schrieb Michael Biebl:

Can you attach the output of
SYSTEMD_LOG_LEVEL=debug systemd-sysusers /usr/lib/sysusers.d/polkit.conf
for the system where you get this failure.


# SYSTEMD_LOG_LEVEL=debug systemd-sysusers
/usr/lib/sysusers.d/polkit.conf
SELinux enabled state cached to: disabled
Failed to open '/usr/lib/sysusers.d/polkit.conf', ignoring: No such
file or directory


SYSTEMD_LOG_LEVEL=debug systemd-sysusers /usr/lib/sysusers.d/polkitd.conf

please (note the 'd')


# SYSTEMD_LOG_LEVEL=debug systemd-sysusers /usr/lib/sysusers.d/polkitd.conf
SELinux enabled state cached to: disabled
Group polkitd already exists.
User polkitd already exists.

  

Ideally also include the output of "dpkg-reconfigure" with
/var/lib/dpkg/info/polkitd.postinst having a  "set -x" added right at the
top.


See end of this mail.
  

The usual spiel.


Hope this helps now.

Please note: I will not have any access to this laptop for the next two
weeks.

Kind regards
 Andreas.


# dpkg-reconfigure polkitd 2>&1 | tee > output
# cat output
+ set -e
+ getent passwd polkitd
+ user_changed=
+ command -v systemd-sysusers
+ systemd-sysusers polkitd.conf
+ dpkg --compare-versions 122-3 lt 122-3~
+ id -g polkitd
+ [ 134 = 65534 ]
+ set_perms polkitd root 700 /etc/polkit-1/rules.d
+ USER=polkitd
+ GROUP=root
+ MODE=700
+ FILE=/etc/polkit-1/rules.d
+ dpkg-statoverride --list /etc/polkit-1/rules.d
+ chown polkitd:root /etc/polkit-1/rules.d
+ chmod 700 /etc/polkit-1/rules.d
+ set_perms polkitd root 700 /usr/share/polkit-1/rules.d
+ USER=polkitd
+ GROUP=root
+ MODE=700
+ FILE=/usr/share/polkit-1/rules.d
+ dpkg-statoverride --list /usr/share/polkit-1/rules.d
+ chown polkitd:root /usr/share/polkit-1/rules.d
+ chmod 700 /usr/share/polkit-1/rules.d
+ set_perms polkitd root 700 /var/lib/polkit-1
+ USER=polkitd
+ GROUP=root
+ MODE=700
+ FILE=/var/lib/polkit-1
+ dpkg-statoverride --list /var/lib/polkit-1
+ chown polkitd:root /var/lib/polkit-1
+ chmod 700 /var/lib/polkit-1
+ set_perms root root 4755 /usr/lib/polkit-1/polkit-agent-helper-1
+ USER=root
+ GROUP=root
+ MODE=4755
+ FILE=/usr/lib/polkit-1/polkit-agent-helper-1
+ dpkg-statoverride --list /usr/lib/polkit-1/polkit-agent-helper-1
+ chown root:root /usr/lib/polkit-1/polkit-agent-helper-1
+ chmod 4755 /usr/lib/polkit-1/polkit-agent-helper-1
+ [ -z  ]
+ [ -n  ]
+ [ configure = configure ]
+ update-xmlcatalog --sort --add --type public --id -//freedesktop//DTD 
PolicyKit Policy Configuration 1.0//EN --package polkitd --local 
/usr/share/xml/polkit-1/catalog.xml
+ update-xmlcatalog --sort --add --type system --id 
http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd --package 
polkitd --local /usr/share/xml/polkit-1/catalog.xml
+ update-xmlcatalog --sort --add --type public --id -//freedesktop//DTD 
PolicyKit Policy Configuration 1.0//EN --package polkitd --root
+ update-xmlcatalog --sort --add --type system --id 
http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd --package 
polkitd --root
+ [ configure = configure ]
+ command -v systemd-tmpfiles
+ [ -x /usr/bin/systemd-tmpfiles ]
+ systemd-tmpfiles --create polkitd.conf
+ dpkg-maintscript-helper rm_conffile /etc/pam.d/polkit-1 122-2~ -- configure 
122-3
+ dpkg-maintscript-helper rm_conffile 
/etc/polkit-1/localauthority.conf.d/50-localauthority.conf 121+compat0.1-1~ -- 
configure 122-3
+ dpkg-maintscript-helper rm_conffile 
/etc/polkit-1/localauthority.conf.d/51-debian-sudo.conf 121+compat0.1-1~ -- 
configure 122-3
+ dpkg-maintscript-helper rm_conffile 
/etc/polkit-1/localauthority.conf.d/51-ubuntu-admin.conf 121+compat0.1-1~ -- 
configure 122-3
+ dpkg-maintscript-helper rm_conffile 
/etc/polkit-1/rules.d/40-debian-sudo.rules 121~ polkitd-javascript -- configure 
122-3
+ dpkg-maintscript-helper rm_conffile 
/etc/polkit

Bug#1076190: Installs dangling symlink /etc/sysctl.d/99-sysctl.conf

[Michael Biebl]

Package: systemd
Version: 256.2-1
Severity: normal

Given the latest changes in procps, /etc/sysctl.d/99-sysctl.conf has
now become a dangling symlink on fresh installations:

procps (2:4.0.4-5) unstable; urgency=medium

...
  * Remove /etc/sysctl.conf as using /etc/sysctl.d/*.conf is better
...

 -- Craig Small   Thu, 11 Jul 2024 18:41:23 +1000

Upgraded systems will continue to have an obsolete conffile named
/etc/sysctl.conf

Bug#1074789: [Pkg-utopia-maintainers] Bug#1074789: polkitd: setup uses non-failsafe manner of checking whether user/group exists

[Michael Biebl]

Am 03.07.24 um 21:00 schrieb Lionel Élie Mamane:

On Wed, Jul 03, 2024 at 07:25:15PM +0200, Michael Biebl wrote:


connect(5, {sa_family=AF_UNIX, 
sun_path="/run/systemd/userdb/io.systemd.DynamicUser"}, 45) = -1 ECONNREFUSED 
(Connection refused)



systemd should be listening on this socket


Well, on no less than four different Debian machines, it does not.


$ sudo lsof /run/systemd/userdb/io.systemd.DynamicUser
COMMAND PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
systemd   1 root   28u  unix 0x73ac41e2  0t0 8696
/run/systemd/userdb/io.systemd.DynamicUser type=STREAM (LISTEN)


Isn't that on a machine where systemd-userdb is installed maybe? The
installation of that package triggers the systemd binary to listen?


No, systemd-userdb is not installed and as you can see from the above 
output it's actually systemd which listens on that socket.




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1072105: /usr/lib/tmpfiles.d/legacy.conf:13: Duplicate line for path "/run/lock", ignoring.

[Michael Biebl]

Control: reopen -1

On Tue, 28 May 2024 17:15:02 +0100 Luca Boccassi  wrote:

Control: tags -1 wontfix
Control: close -1

On Tue, 28 May 2024 17:44:54 +0200 Michael Biebl 
wrote:
> Package: systemd
> Version: 256~rc3-4
> Severity: normal
> 
> 
> Please do not not ship conflicting configuration for /run/lock
> 
> /usr/lib/tmpfiles.d/debian.conf:d /run/lock    1777 root root -   -

> /usr/lib/tmpfiles.d/legacy.conf:d /run/lock 0755 root root -
> 
> triggering unnecessary warnings.


This is needed to apply debian-specific changes, just ignore it, it's
harmless


Besides the obvious warning message, shipping conflicting tmpfiles 
configuration snippets also has the problem, that depending on which 
file you override, one or the other becomes active.


Say you create a /etc/tmpfiles.d/debian.conf, then the configuration in 
legacy.conf becomes active and vise versa.

This is highly confusing.

tmpfiles entries are not easily overridable, as the mechanism is per 
file and not per entry.


So, either legacy.conf gets split up so individual entries can be 
overridden or your patch legacy.conf.


The current approach is not sufficient.


Btw, please don't close bug reports without CCing the bug submitter. 
That's rude.


Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1072105: (no subject)

[Michael Biebl]

please do find a proper solution.

wontfix is it not.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1072105: /usr/lib/tmpfiles.d/legacy.conf:13: Duplicate line for path "/run/lock", ignoring.

[Michael Biebl]

Package: systemd
Version: 256~rc3-4
Severity: normal


Please do not not ship conflicting configuration for /run/lock

/usr/lib/tmpfiles.d/debian.conf:d /run/lock1777 root root -   -
/usr/lib/tmpfiles.d/legacy.conf:d /run/lock 0755 root root -

triggering unnecessary warnings.

Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Michael Biebl]

Am 06.05.24 um 12:18 schrieb Luca Boccassi:

Defaults are defaults, they are trivially and fully overridable where
needed if needed. Especially container and VM managers these days can
super trivially override them via SMBIOS Type11 strings or
Credentials, ephemerally and without changing the guest image at all.



Aligning defaults across distros does have value.
That said, a distro like Debian has a larger scope than say a desktop 
oriented one like Fedora.
Debian is used on a broad spectrum of systems: from embedded to server 
to cloud to desktop.
So I think it is valuable to gather feedback from all affected parties 
to make an informed decision.


What upstream is doing should not be the only driving factor.


Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Michael Biebl]

Am 05.05.24 um 22:04 schrieb Luca Boccassi:

This will be mentioned in NEWS (and I guess in the release notes when
the time comes), together with the instructions to override for anybody
wanting to keep the old behaviour, which is as trivial as:



..


touch /etc/tmpfiles.d/tmp.conf


This doesn't restore the old/current behaviour, which is to cleanup /tmp 
on boot. For that you would need something like


echo "D /tmp 1777 root root -" > /etc/tmpfiles.d/tmp.conf


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Michael Biebl]

We have two separate issues here:

a/ /tmp-on-tmpfs
b/ time based clean-up of /tmp and /var/tmp

I think it makes sense to discuss/handle those separately.

Regarding a/:
tmp.mount as shipped by systemd uses the following mount options:
"mode=1777,strictatime,nosuid,nodev,size=50%"

In the past there were concerns that those 50% of available RAM wasn't a 
one-size-fits-all solution, especially for (LXC) containers and VMs


One also needs to keep in mind that debian-installer still offers a 
partitioning setup with /tmp on a separate partition. This will be 
created via an entry in /etc/fstab. Such a /tmp entry in /etc/fstab will 
override tmp.mount.


If we go with a/, then I think d-i should be updated to no longer create 
/tmp as a separate partition.



Regarding b/:
The current setup as used in Debian is to only clean /tmp on boot (which 
is pointless with /tmp-on-tmpfs) and never clean up /var/tmp


The tmpfiles rule tmp.conf as shipped by systemd upstream contains:

q /tmp 1777 root root 10d
q /var/tmp 1777 root root 30d

Files that are older then 10 days or 30 days are automatically cleaned 
up. The age of the files are determined as such:


"The age of a file system entry is determined from its last modification 
timestamp (mtime), its last access timestamp (atime), and (except for 
directories) its last status change timestamp (ctime). By default, any 
of these three (or two) values will prevent cleanup if it is more recent 
than the current time minus the age field."


I'm not sure if we have software on long running servers which place 
files in /tmp and /var/tmp and expect files to not be deleted during 
runtime, even if not accessed for a long time. This is certainly an 
issue to be aware of and keep an eye on.



Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Stepping down as systemd maintainer

[Michael Biebl]

Hi,

after 13 years, I decided to step down as systemd maintainer and I've 
removed myself as Uploader from all systemd related packages at 
https://salsa.debian.org/systemd-team/, turned off gitlab notifications 
and unsubscribed from pkg-systemd-maintainers@l.a.d.n

I think it's time to move on and pass on the responsibility.

It was a fun ride, despite all the controversies and the energy that it 
took at times. I'm proud of what we achieved.


I granted Luca admin privs for the pkg-systemd-maintainers mailing list 
and there are enough DDs for the systemd-team salsa team with owner 
privileges.


Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068591: systemd-container: doesn't list a default package for default-dbus-system-bus dependency

[Michael Biebl]

Am 07.04.24 um 18:19 schrieb Raphaël Halimi:

Note 1: one could think that it's debootstrap's fault for not resolving 
dependencies on virtual packages; indeed, it has already been reported 
several times (#878961, merged with #827602 and #931760; as well as 
Launchpad #86536) unfortunately never fixed yet; but, IMHO, since 
systemd-container is usually needed in systemd-nspawn containers, and 
(except for the host) is usually installed via debootstrap, it makes it 
kind of a special case, in the sense that systemd (as a whole) should 
take care that systemd-nspawn containers can be built and started easily.


As you correctly noticed, this is a bug/fault in debootstrap.
I don't think individual packages should work around that, so I'm 
included to close this as wontfix (or reassign/merge to debootstrap).


Fwiw, you might use an alternative debootstrap tool like mmdebstrap 
which works properly in that regard.






OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1068443: systemd: "systemctl --user ..." results in Connection refused

[Michael Biebl]

Am 05.04.24 um 11:38 schrieb Fabian Greffrath:

Package: systemd
Version: 255.4-1
Severity: normal

Hi,

sorry if this is a trivial question, but I am somehow new to this
systemd/systemctl stuff - or at least until now everything worked as
expected. ;)

Whenever I try to load a user service, systemctl immediately quits my
attempt with the following error:

$ systemctl --user enable fluidsynth.service
Failed to connect to bus: Connection refused

Even merely calling "systemctl --user" without any further arguments
leads to the same result, so I am sure it's not a syntax error on the
command line.

What am I doing wrong?

Thanks for your help!


What's the output of `ps ux | grep systemd`? I.e. do you actually have a 
`systemd --user` instance running as well as a dbus user bus.

systemd-cgls output and loginctl for your user might be helpful as well.

Is the problem reproducible after a reboot?
Is the problem reproducible for a freshly created user?

Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065638: systemd-journald: systemd-journald restart misses SyslogFacility

[Michael Biebl]

Control: tags -1 + upstream

Am 07.03.24 um 20:25 schrieb Kai Palomaki:

Package: systemd
Version: 247.3-7+deb11u4
Severity: normal
X-Debbugs-Cc: armando.va...@gmail.com

Dear Maintainer,

* What led up to the situation?
A systemd service unit "test" has SyslogFacility=local0 set. Service is 
running and logging lines.
Log lines have SYSLOG_FACILITY=16 when observed with journalctl -o verbose.
Restart journald. After restart of journald, log lines have no more 
SYSLOG_FACILITY=16.
To restore SYSLOG_FACILITY=16 in journal logs, one has to restart service unit 
"test".

* What exactly did you do (or not do) that was effective (or
  ineffective)?
systemctl restart systemd-journald.service

* What was the outcome of this action?
journald did not record the SyslogFacility set in the service unit file.

* What outcome did you expect instead?
journald should continue recording SyslogFacility set in the service unit 
file without needing to restart the service having the SyslogFacility set.



The Debian package doesn't ship any patches in that regard, thus this 
issue should be raised upstream.


For that, please try to reproduce the issue first with a recent version 
of systemd (say v254 or v255) and if it's reproducible, report it at

https://github.com/systemd/systemd/issues
and then report back with the issue number.

Thanks,
Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065624: resolved not working after installation, race with dbus and user creation

[Michael Biebl]

Am 07.03.24 um 16:22 schrieb Michael Biebl:

The chain of events afaics is this:

1/ postinst creates systemd-resolve
2/ systemd-resolved.service is started in postinst
3/ dbus trigger is activated after postinst and the dbus config is reloaded

Because the dbus daemon reload happens after the systemd-resolved user 
has been created, systemd-resolved could not successfully claim the 
org.freedesktop.resolve1 D-Bus name.


What we would need to be able to do is to trigger a dbus daemon-reload 
after the system user has been created and before the service is started.


Both is autogenerated code (via dh_installsysusers and 
dh_installsystemd), and there is no way to inject maintscript code 
manually unfortunately.


One way to maybe address this is to make dh_installsysusers generate 
maintscript code to reload dbus.
This could either be done unconditionally, via a dh_installsysusers 
option, or automatically when it finds a D-Bus config file shipped by 
the package (and referencing that user).


dh_installsysusers is part of debhelper, so would need to be addressed 
there.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065624: resolved not working after installation, race with dbus and user creation

[Michael Biebl]

Am 07.03.24 um 15:12 schrieb Timo Weingärtner:

Package: systemd-resolved
Version: 252.22-1~deb12u1
Severity: important
X-Debbugs-Cc: timo.weingaert...@quantumsimulations.de

After installing systemd-resolved name resolution does not work anymore:
8<8<
# apt-get --no-install-recommends install systemd-resolved
[…]
# host debian.org
Host debian.org not found: 2(SERVFAIL)
# resolvectl
Failed to get global data: Connection timed out
# systemctl restart systemd-resolved.service
# host debian.org
debian.org has address […]
[…]
8<8<

The relevant error message from dbus-daemon appears before postinst creates
the user and starts the service.

Maybe creating the user in preinst already, before it is referenced in
dbus config, would be better.

This is the log, including my workaround:


The chain of events afaics is this:

1/ postinst creates systemd-resolve
2/ systemd-resolved.service is started in postinst
3/ dbus trigger is activated after postinst and the dbus config is reloaded

Because the dbus daemon reload happens after the systemd-resolved user 
has been created, systemd-resolved could not successfully claim the 
org.freedesktop.resolve1 D-Bus name.


What we would need to be able to do is to trigger a dbus daemon-reload 
after the system user has been created and before the service is started.


Both is autogenerated code (via dh_installsysusers and 
dh_installsystemd), and there is no way to inject maintscript code 
manually unfortunately.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065567: timedatectl does not recognize ntpsec

[Michael Biebl]

Control: reassign -1 ntpsec

Actually, I think it's better to just reassign the bug report and let 
Richard decide whether he closes it as wontfix or ships such an 
integration snippet.


Richard, if you are interested in shipping such a ntp-units.d snippet 
and you have further questions, please ask.


Michael

Am 06.03.24 um 19:22 schrieb Michael Biebl:
On Wed, 6 Mar 2024 12:53:47 -0500 Jeffrey Walton  
wrote:

Package: systemd
Version:  255.4-1
Tags: sid

It looks like Systemd's timedatectl does not recognize ntpsec. Using
it results in 'NTP service: n/a':

$ timedatectl
   Local time: Wed 2024-03-06 12:35:32 EST
   Universal time: Wed 2024-03-06 17:35:32 UTC
 RTC time: Wed 2024-03-06 17:35:32
    Time zone: America/New_York (EST, -0500)
System clock synchronized: yes
  NTP service: n/a
  RTC in local TZ: no

According to <https://wiki.debian.org/DateTime#Installing_NTP>, ntpsec
is an option for Debian 11 and below; and default for Debian 12 and
above.

I searched for an upstream bug at <https://github.com/systemd/systemd>
(is that the right place?), but there were no relevant hits. See
<https://github.com/systemd/systemd/issues?q=is%3Aissue+ntpsec>.

Also see <https://lists.debian.org/debian-user/2024/03/msg00145.html>.
That's the debian-users mailing list discussion with GW's comment.


If an NTP service want's to be recognized by timedated, it needs to ship 
a config snippet in /usr/lib/systemd/ntp-units.d/

See man systemd-timedated



LIST OF NETWORK TIME SYNCHRONIZATION SERVICES
   systemd-timesyncd will look for files with a ".list" extension 
in ntp-units.d/ directories. Each file is parsed as a list of unit 
names, one per

  ^
   this is a typo, should be systemd-timedated [1]
   line. Empty lines and lines with comments ("#") are ignored. 
Files are read from /usr/lib/systemd/ntp-units.d/ and the 
corresponding directories
   under /etc/, /run/, /usr/local/lib/. Files in /etc/ override 
files with the same name in /run/, /usr/local/lib/, and /usr/lib/. 
Files in /run/
   override files with the same name under /usr/. Packages should 
install their configuration files in /usr/lib/ (distribution packages) or

   /usr/local/lib/ (local installs).

   Example 1. ntp-units.d/ entry for systemd-timesyncd

   # /usr/lib/systemd/ntp-units.d/80-systemd-timesync.list
   systemd-timesyncd.service

   If the environment variable $SYSTEMD_TIMEDATED_NTP_SERVICES is 
set, systemd-timesyncd will parse the contents of that variable as a
   colon-separated list of unit names. When set, this variable 
overrides the file-based list described above.



systemd-timesyncd and chrony do this properly.

# apt-file search /usr/lib/systemd/ntp-units.d/
chrony: /usr/lib/systemd/ntp-units.d/50-chrony.list
systemd-timesyncd: /usr/lib/systemd/ntp-units.d/80-systemd-timesync.list


I've CCed the ntpsec maintainers.
If they have interest in shipping such an integration, then we can 
reassign the bug report. Otherwise I'll just close it, as there is 
nothing we can do on the systemd side


Regards,
Michael

[1] https://github.com/systemd/systemd/pull/31658




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065567: timedatectl does not recognize ntpsec

[Michael Biebl]

On Wed, 6 Mar 2024 12:53:47 -0500 Jeffrey Walton  wrote:

Package: systemd
Version:  255.4-1
Tags: sid

It looks like Systemd's timedatectl does not recognize ntpsec. Using
it results in 'NTP service: n/a':

$ timedatectl
   Local time: Wed 2024-03-06 12:35:32 EST
   Universal time: Wed 2024-03-06 17:35:32 UTC
 RTC time: Wed 2024-03-06 17:35:32
Time zone: America/New_York (EST, -0500)
System clock synchronized: yes
  NTP service: n/a
  RTC in local TZ: no

According to , ntpsec
is an option for Debian 11 and below; and default for Debian 12 and
above.

I searched for an upstream bug at 
(is that the right place?), but there were no relevant hits. See
.

Also see .
That's the debian-users mailing list discussion with GW's comment.


If an NTP service want's to be recognized by timedated, it needs to ship 
a config snippet in /usr/lib/systemd/ntp-units.d/

See man systemd-timedated



LIST OF NETWORK TIME SYNCHRONIZATION SERVICES
   systemd-timesyncd will look for files with a ".list" extension in 
ntp-units.d/ directories. Each file is parsed as a list of unit names, one per

 ^
  this is a typo, should be systemd-timedated [1]

   line. Empty lines and lines with comments ("#") are ignored. Files are 
read from /usr/lib/systemd/ntp-units.d/ and the corresponding directories
   under /etc/, /run/, /usr/local/lib/. Files in /etc/ override files with 
the same name in /run/, /usr/local/lib/, and /usr/lib/. Files in /run/
   override files with the same name under /usr/. Packages should install 
their configuration files in /usr/lib/ (distribution packages) or
   /usr/local/lib/ (local installs).

   Example 1. ntp-units.d/ entry for systemd-timesyncd

   # /usr/lib/systemd/ntp-units.d/80-systemd-timesync.list
   systemd-timesyncd.service

   If the environment variable $SYSTEMD_TIMEDATED_NTP_SERVICES is set, 
systemd-timesyncd will parse the contents of that variable as a
   colon-separated list of unit names. When set, this variable overrides 
the file-based list described above.



systemd-timesyncd and chrony do this properly.

# apt-file search /usr/lib/systemd/ntp-units.d/
chrony: /usr/lib/systemd/ntp-units.d/50-chrony.list
systemd-timesyncd: /usr/lib/systemd/ntp-units.d/80-systemd-timesync.list


I've CCed the ntpsec maintainers.
If they have interest in shipping such an integration, then we can 
reassign the bug report. Otherwise I'll just close it, as there is 
nothing we can do on the systemd side


Regards,
Michael

[1] https://github.com/systemd/systemd/pull/31658


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [Pkg-utopia-maintainers] Bug#1058590: getent in polkitd.postinst is broken

[Michael Biebl]

Am 29.02.24 um 15:10 schrieb Harald Dunkel:

I would suggest to simply create polkitd user and group using useradd
instead of systemd, ignore the error message indicating the user exists
or whatever might happen, and then try to use the polkitd user. If this
last step fails, then the postinst script can exit with an error.

I don't know of any other package (except for systemd) using 
systemd-sysusers


apt-file search /usr/lib/sysusers.d will tell you which packages use 
sd-syusers.



$ apt-file search /usr/lib/sysusers.d/ | wc -l
43

So yeah, if there is a problem with sd-sysusers, it should be addressed, 
as this interface is becoming more ubiquitous.


So if you have a good reproducer and a debug log, please let us know and 
we will reopen this bug report.


Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1065074: systemd-journal-remote: Version missmatch between bundled service and systemd version

[Michael Biebl]

Control: severity -1 important

Am 29.02.24 um 13:49 schrieb Simen Rostvik:

Package: systemd-journal-remote
Version: 252.22-1~deb12u1
Severity: normal
X-Debbugs-Cc: reoport...@roxedus.dev

Dear Maintainer,

The version of this package (252) should include a service compatible with 
Systemd of the same version.
This is not the case as the bundled service includes 'RestartSteps' and 
'RestartMaxDelaySec' which are options introduced in Systemd 254.
The introduction is mentioned in the man page for Systemd 
https://www.freedesktop.org/software/systemd/man/254/systemd.service.html#RestartSteps=

This leads to the service failing upon enabling it, with the status pointing 
out that the mentioned options are unkown.



Thanks for this bug report. This is caused by
https://github.com/systemd/systemd-stable/commit/c56b3f7d36f58e4d9f9948a3b50812178c461a26
i.e. was already part of v252.19

I guess the safest approach will be to revert this commit.
Backporting support "RestartSteps" looks like a change not suitable for 
-stable.


Other -stable branches (like v253-stable) are affected too, it seems.


@Luca: Will you take care of this upstream?


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056137: systemd: downgrading systemd packages kills off the desktop environment

[Michael Biebl]

Am 28.02.24 um 22:22 schrieb Richard Lewis:

On Wed, 28 Feb 2024 18:37:41 +0100 Michael Biebl  wrote:


On Fri, 17 Nov 2023 14:40:05 +0100 Christoph Anton Mitterer
 wrote:

Package: systemd
Version: 255~rc2-1



Because of #1056135 I was downgradin systemd/udev packages to 254.5-1.
While apt was still running, this causes the whole desktop environment
(I use cinnamon) to be killed (and all processes in it ;-) ).




My guess is, that the failures you encountered are due to the following
change in v255:

"""
  Service Manager:

  * The way services are spawned has been overhauled.


I couldnt follow the bit i deleted, and this maybe jumping to
conclusions: are there any implications for upgrading to/after 255
within a desktop environment?
should something be said in the release-notes?



No, upgrades should work fine.
That said, the usual recommendations for dist-upgrades apply
https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#upgrade-preparations

I.e. it is generally not recommended to dist-upgrade from within a 
desktop session although usually it works.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055830: systemd in a container fails to set up mount namespacing

[Michael Biebl]

Control: tags -1 + moreinfo help


On Sun, 12 Nov 2023 11:15:45 +0100 Christian Horn  
wrote:

Package: systemd
Version: 252.17-1~deb12u1
Severity: important

Dear Maintainer,

* What led up to the situation?

Fedora39 running as host, Debian Bookworm container is started via podman.
Packages systemd and redis get installed in the container, then trying to
start redis via 'systemctl start redis fails'.
'journalctl -xeu redis-server.service' says:
(s-server)[66]: Failed to mount /run/systemd/inaccessible/reg to 
/run/systemd/unit-root/proc/kallsyms: Permission denied
(s-server)[66]: redis-server.service: Failed to set up mount namespacing: 
/run/systemd/unit-root/proc/kallsyms: Permission denied
(s-server)[66]: redis-server.service: Failed at step NAMESPACE spawning 
/usr/bin/redis-server: Permission denied

* What exactly did you do (or not do) that was effective (or
  ineffective)?

Using a Debian trixie container, the issue does not appear.
I see this on both amd64 and aarch64 architecture.
I think everybody trying to run redis in a Bookworm 
container will hit this issue.




From the provided information it is not obvious that this is actually a 
systemd issue. It could be the kernel or any of the dependencies systemd 
relies on or even redis itself.


In any case, if you think this is a systemd issue, we would need further 
information how to fix this.


So any help is welcome.

Michael




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056137: systemd: downgrading systemd packages kills off the desktop environment

[Michael Biebl]

Control: severity -1 wishlist
Control: tags -1 + help

Hi Christoph

On Fri, 17 Nov 2023 14:40:05 +0100 Christoph Anton Mitterer 
 wrote:

Package: systemd
Version: 255~rc2-1
Severity: important

Hey.

Because of #1056135 I was downgradin systemd/udev packages to 254.5-1.
While apt was still running, this causes the whole desktop environment
(I use cinnamon) to be killed (and all processes in it ;-) ).

Tried it twice, happened twice.


I acknowledge that not being able to downgrade is a nuisance.
systemd is not special in that regard though. Quite a few packages that 
I now need to convert their on-disk-files on upgrades to a new format 
which is not easily reversible.
None of those packages have explicit maintainer scripts code though, 
which would prevent a downgrade.

So we do not plan to add maintainer scripts code in systemd either.

My guess is, that the failures you encountered are due to the following 
change in v255:


"""
Service Manager:

* The way services are spawned has been overhauled. Previously, a
  process was forked that shared all of the manager's memory (via
  copy-on-write) while doing all the required setup (e.g.: mount
  namespaces, CGroup configuration, etc.) before exec'ing the 
target
  executable. This was problematic for various reasons: several 
glibc
  APIs were called that are not supposed to be used after a 
fork but

  before an exec, copy-on-write meant that if either process (the
  manager or the child) touched a memory page a copy was 
triggered, and

  also the memory footprint of the child process was that of the
  manager, but with the memory limits of the service. From this 
version

  onward, the new process is spawned using CLONE_VM and CLONE_VFORK
  semantics via posix_spawn(3), and it immediately execs a new 
internal
  binary, systemd-executor, that receives the configuration to 
apply

  via memfd, and sets up the process before exec'ing the target
  executable. The systemd-executor binary is pinned by file 
descriptor

  by each manager instance (system and users), and the reference is
  updated on daemon-reexec - it is thus important to reexec all 
running

  manager instances when the systemd-executor and/or libsystemd*
  libraries are updated on the filesystem.
"""

This is just a guess though.
There is only so much we can do as Debian systemd team. If that issue is 
important to you, please consider investigating this further and 
providing patches, ideally via a MR on salsa.


Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064133: systemd-resolved: Using systemd-resolved as drop-in replacements breaks in conjunction with ifupdown

[Michael Biebl]

On Sat, 17 Feb 2024 16:00:08 +0100 Felix Jacobi  wrote:


In background, this executes `resolvconf -a IFACE.PROTOCOL` and supplies
the nameservers to resolvconf, e.g.

echo 'nameserver 192.0.0.1' | resolvconf -a ens3.inet

However, the systemd-resolved resolvconf implementation removes the
protocol indentifier:

echo "nameserver 192.0.0.1" | resolvconf -a ens3.inet
Dropped protocol specifier '.inet' from 'ens3.inet'. Using 'ens3' (ifindex=2).

This leads to the fact, that only ens3 is used internally. For the
configuration above, this means the previous configured IPv4 nameserver
is completely overriddden with the latter one in the IPv6 stanza.

This also causes several other problems for tools relying on resolvconf
not dropping the protocol identifier and I would consider this a
breaking change compared to the original resolvconf implementation.


The Debian package does not ship any patches in that regard.
It would thus be best if you raise this upstream at
https://github.com/systemd/systemd/issues

I did not immediately find, why resolvectl/resolved does strip away the 
protocol identifier.
At the very least, this incompatibility could be documented in the 
resolvctl man page.


Regards,
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064879: systemd: User sessions started from system scope have no journal.

[Michael Biebl]

Am 27.02.24 um 12:11 schrieb Michael Biebl:
On Tue, 27 Feb 2024 09:18:02 +0100 Timon de Groot 

   * What led up to the situation?
 Upstream systemd bugs: #23679, #26742. Can be reproduced when 


..


I'm not able to reproduce the problem given the above instructions.
With an up-to-date test VM, I enabled linger for the user "michael", 
rebooted, then logged in as "michael" and restarted a couple of user 
services like systemctl --user restart dbus.service


As you can see from the screenshot, they do show up in journalctl --user


The upstream bugs you quoted talk about "system users", i.e. their uid 
is < 1000.


Can you post the output of "id myuser"


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Possible bug in systemd (systemd 252 (252.22-1~deb12u1)) - systemd-pcrphase is not available

[Michael Biebl]

Am 21.02.24 um 21:23 schrieb Kay Jeschonneck:

Hi Ansgar,


yes, you are right, with "/lib/systemd/system*d*-pcrphase" it is working.


It looks like the d is missing in the docu: 
https://manpages.debian.org/bookworm/systemd/systemd-pcrphase.8.en.html


Could you add it there?


It's already fixed in trixie:
https://manpages.debian.org/testing/systemd/systemd-pcrphase.8.en.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064879: systemd: User sessions started from system scope have no journal.

[Michael Biebl]

Control: tags -1 + moreinfo unreproducible

On Tue, 27 Feb 2024 09:18:02 +0100 Timon de Groot 
 wrote:

Package: systemd
Version: 252.22-1~deb12u1
Severity: normal
X-Debbugs-Cc: timon.degr...@hypernode.com

Dear Maintainer,

   * What led up to the situation?
 Upstream systemd bugs: #23679, #26742. Can be reproduced when enabling 
linger for user, rebooting and running journalctl --user.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   Create a bookworm VM with a normal user. Enable linger for that user
   (loginctl enable-linger myuser). Reboot the server. Login as that
   user. Run journalctl --user, no new log output from the current
   systemd user session.
   * What was the outcome of this action?
   New output after enabling lingering does seem to get logged into the
   user's journal. Either you only see the old log entries
   that exist from an older systemd user session or you get to see the
   error "No journal files were found, for journalctl"
   * What outcome did you expect instead?
   Running journalctl --user gives proper output.



I'm not able to reproduce the problem given the above instructions.
With an up-to-date test VM, I enabled linger for the user "michael", 
rebooted, then logged in as "michael" and restarted a couple of user 
services like systemctl --user restart dbus.service


As you can see from the screenshot, they do show up in journalctl --user



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: [Pkg-utopia-maintainers] Bug#1058590: getent in polkitd.postinst is broken

[Michael Biebl]

Am 22.01.24 um 15:54 schrieb Harald Dunkel:

On 2024-01-22 12:41:04, Simon McVittie wrote:

On Thu, 14 Dec 2023 at 11:38:16 +0100, Harald Dunkel wrote:

getent queries all databases, as listed in /etc/nsswitch.conf, AFAIU.
I would suggest to use

getent -s files passwd polkitd

to query /etc/passwd only and to ignore remote databases based on LDAP
or NIS or similar. polkitd is supposed to be a local system user.


Wouldn't this break systems where polkitd is a local system user stored
in some backend other than the standard flat files, like libnss-db or
libnss-extrausers?



I can't help it. The getent was just a suggestion. Maybe it would be wise
to ignore all local and remote databases for creating system accounts,
except for the traditional files in /etc?



How is this particular system set up? Is it using a remote user database?



It would be using a remote database (FreeIPA, i.e LDAP), but this is a
chroot. I am updating a clone of the root partition from Debian 11 to
12 to reduce the downtime. /usr/sbin/policy-rc.d is set accordingly.

There is no polkitd account in the remote database, anyway. I checked.


This seems to be consistent with how
/usr/share/debhelper/autoscripts/postinst-sysusers handles sysusers, so
if there is a bug here, it would affect any package that relies on
sysusers.d, not just polkit.


I have updated quite a number of hosts already, but only polkitd postinst
in Debian 12 ran into this problem. The fix is to manually add polkitd
to the local database on the command line (copy and paste from the
postinst script:

     adduser --group --system --gecos 'polkit' \
     --no-create-home --home /nonexistent polkitd

) and to try again.

Looking at the code

     if command -v systemd-sysusers >/dev/null; then
     systemd-sysusers ${DPKG_ROOT:+--root="$DPKG_ROOT"} 
polkitd.conf

     else
     adduser --group --system --gecos 'polkit' \
     --no-create-home --home /nonexistent polkitd
     addgroup --system polkitd
     fi

I wonder if the systemd case would be executed in a chroot?


systemd-sysusers is executed in a chroot. It's a standalone tool that 
doesn't require a running systemd.


It would be interesting to get the output of
SYSTEMD_LOG_LEVEL=debug systemd-sysusers polkitd.conf

But you wrote later, that you can no longer reproduce the issue 
yourself. So I guess we should close this issue at this point as we 
don't have enough information to further investigate this.


I do remember https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1059216
where polkitd.postinst also failed.
It turned out though, that the users had a broken/malformatted 
/etc/gshadow file and systemd-sysusers is apparently a bit more picky in 
that regard then adduser.


Regards,
Michael




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064826: Fan noise after systemctl poweroff

[Michael Biebl]

Control: tags -1 + moreinfo

Am 26.02.24 um 11:27 schrieb franchi@modula.network:

Package: systemd
Version: 252.22-1~deb12u1

Debian 12.5 fresh installation.

When  when the commands "shutdown -h" or "systemctl poweroff" reach 
their target, the fans of my server ML350 G11 increase speed and noise 
and remain like this for an indefinite time.

This doens'n happen if I shutdown the server by mean  of the iLO power-off.


Does this also happen if you run
"systemctl poweroff --force"
or
"systemctl poweroff --force --force"


"--force" will omit the shutdown of services, so this should typically 
not be used.

My guess is, that you have a service that does not terminate.

Can you also boot with systemd.log_level=debug (on the kernel command 
line) and then snap a picture of the system during shutdown when it hangs.


Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064539: systemd: DHCPPrefixDelegation does not allow zero value in Token=

[Michael Biebl]

Control: tags -1 + upstream

Am 23.02.24 um 23:00 schrieb Fabian Müller:

Package: systemd
Version: 252.19-1~deb12u1
Severity: normal
Tags: ipv6
X-Debbugs-Cc: fmu+deb...@never-afk.de

Dear Maintainer,


* What led up to the situation?

I wanted systemd-networkd to select the first address (zero) from the ipv6
prefix that was delegated to me. My provider (Vodafone Kabel / Germany) offers
me a /56 prefix via prefix delegation.

My .network file looks like this:

[Match]
Name=enp1s0

[Network]
IPv6AcceptRA=yes
DHCP=yes
DHCPPrefixDelegation=yes

[DHCPv6]
PrefixDelegationHint=::/56
UseDNS=no
UseAddress=no

[DHCPPrefixDelegation]
Token=static:::


* What exactly did you do (or not do) that was effective (or
  ineffective)?

I tried to set the "Token=" option in the [DHCPPrefixDelegation] section of my
.network file as follows:

[DHCPPrefixDelegation]
Token=static:::

* What was the outcome of this action?

The resulting ipv6 address is selects via eui64 instead of static.
So i get a address like this 2001:db8::a60:6eff:feda:858a/64

* What outcome did you expect instead?

I expected the address to be zero. More like this: 2001:db8::/64 (which is a
valid ipv6 address).

I also tried the following values:
Token=static:::0 # does not work
Token=:: # does not work
Token=static::: # does not work
Token=static:::1 # works as expected, but is not what i want, address would be
2001:db8::1/64



The Debian package does not ship any patches in that regard.
It would thus be best if you raise this issue directly upstream at
https://github.com/systemd/systemd/issues if you can reproduce it with 
v254 or v255 (you can pull v254 from bookworm-backports).


Regards,
Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1064043: closed by Michael Biebl (Re: Bug#1064043: systemd: /etc/fstab x-systemd.automount mount points, x-systemd.idle-timeout changes not effective)

[Michael Biebl]

Am 16.02.24 um 12:51 schrieb David Sauvage - AdaLabs Ltd:


the changes are not applied even after restarting the mount unit 
mnt-resource.mount. (when already mounted or not)




Have you restarted the corresponding mnt-resource.automount unit as well?





OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063151: igb: unpredictable interface names for four port nic

[Michael Biebl]

On Tue, 06 Feb 2024 17:27:24 +0100 Valentin  wrote:

>   eth0: Policy *slot* yields "ens6f0".
>   eth0: Could not set AlternativeName= or apply AlternativeNamesPolicy=,
> ignoring: File exists eth0:
> /usr/lib/udev/rules.d/80-net-setup-link.rules:11 NAME 'ens6f0' eth0:
> /usr/lib/udev/rules.d/99-systemd.rules:68 RUN '/lib/systemd/systemd-sysctl
> --prefix=/net/ipv4/conf/$name --prefix=/net/ipv4/neigh/$name
> --prefix=/net/ipv6/conf/$name --prefix=/net/ipv6/neigh/$name' eth0:
> sd-device: Created db file '/run/udev/data/n69' for
> '/devices/pci:00/:00:1c.0/:01:00.0/net/eth0' ens6f0: Failed to
> rename network interface 69 from 'eth0' to 'ens6f0': File exists

It looks like your BIOS is reporting the same PCIe Slot for both your igb and 
Broadcom network cards.

I assume one of your Broadcom network interfaces is already named ens6f0.

In fact., this might be a BIOS issue...
whats the output of `sudo dmidecode -t9`?

Best solution for you is probably to set all or some network interface names 
manually, see https://wiki.debian.org/

NetworkInterfaceNames#CUSTOM_SCHEMES_USING_.LINK_FILES


Yes, I think Valentin is correct in his analysis.
This looks like a BIOS issue which you might want to report to your vendor.

I would follow Valentin's advice and use cutom link files that e.g. 
determine the names based on the MAC address.


Afaics, there is nothing actionable on the udev side here, which is why 
I'm inclined to close the bug report.


Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1063147: 'telinit u' infinitely re-exec's itself inside containers

[Michael Biebl]

Control: forwarded -1 https://github.com/systemd/systemd/issues/31220

Am 05.02.2024 um 12:45 schrieb Daniel P. Berrangé:

The simple solution appears to be to just remove the '-Dtelinit-path'
option from debian/rules, and leave it on systemd's built-in defaults.
The binary at this default path won't exist, and thus on a non-systemd
execution environment 'telinit u' will simply exit with an error:

   # telinit u
   Couldn't find an alternative telinit implementation to spawn.

which is a sensible behaviour and what has happened in containers with
Debian until recent Sid.  Other distros (eg Fedora) leave the telinit
binary on systemd's default (non-existant) path too.

Possibly the upstream systemctl.c code should be made to protect itself
against such a mis-configuration by setting an env variable it can look
at to detect re-exec of itself.



I've forwarded this upstream since I think systemd should behave better 
in this case. E.g. it could check if /sbin/telinit is a symlink on 
itself and in this case do not re-exec unless sd_booted is true.




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1061960: systemd-binfmt.service should get started when something gets added into a previously empty /usr/lib/binfmt.d

[Michael Biebl]

Am 30.01.24 um 14:49 schrieb Johannes Schauer Marin Rodrigues:


Starting or restarting makes it work as tested by Jochen Sprickerhof


The current file trigger uses try-restart:
https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/systemd.postinst?ref_type=heads#L16

I think replacing that with restart should be the most straight forward fix.

systemd-binfmt is not a long running service which might have been 
stopped by the administrator and where we need to respect that and not 
accidentally start it.


Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1052365: systemd: DHCP client fails if multiple DHCP servers on network

[Michael Biebl]

On Mon, 25 Sep 2023 06:53:59 -0500 Alexandre Ferreira 
 wrote:

Thank you, I added a PR and it was merged yesterday.
sd-dhcp-client: reject NAKs from servers that we did not send an offer 
to (#29290) (https://github.com/systemd/systemd/pull/29290)
This change will only be valid for 255. How can we backport it to 252 up 
to 254?.


See bluca's reply at 
https://github.com/systemd/systemd/pull/29290#issuecomment-1873329561


If you want to see this fixed for v252-stable, please backport the 
commit to the v252-stable branch [1], test it and then submit a PR [2]



Regards,
Michael

[1] https://github.com/systemd/systemd-stable/tree/v252-stable
[2] https://github.com/systemd/systemd-stable/pulls


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059899: systemd-resolved: systemd-resolved takes up all memory on certain PTR queries and is then oom-killed

[Michael Biebl]

Hi Corin


On Wed, 03 Jan 2024 12:50:13 +0100 Luca Boccassi  wrote:

Control: severity -1 normal
Control: tags -1 moreinfo

On Wed, 03 Jan 2024 12:02:40 +0100 Corin Langosch 
wrote:
> Package: systemd
> Version: 247.3-7+deb11u4
> Severity: critical
> File: systemd-resolved
> Justification: breaks the whole system

Your logs show that it restarts just fine after the oom kill, so it is
most definitely not "grave". Also, you did not attach your local
resolved.conf.

Also, oldstable is old. Try with backports or with upgrading to stable.


Any updates here? Did you have the chance to reproduce this with at 
least stable, i.e. v252. Even better would be, if you can try with v254 
from bookworm-backports.


So far I failed to reproduce the issue with the given information.

$ host 54.49.125.74.in-addr.arpa
Host 54.49.125.74.in-addr.arpa not found: 3(NXDOMAIN)

That is all I get.


Regards,
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060018: systemd: broken kernel log messages on virtual console

[Michael Biebl]

Control: tags -1 + moreinfo unreproducible

On Thu, 04 Jan 2024 22:32:42 +0200 dweller  wrote:

I am including images that show the corruption (related to numbers in brackets).
What other information can I provide to help you in identifying the problem?


Ideally you can provide a minimal reproducer.
Say start from minimal Debian stable installation (in a VM) and then 
provide the necessary steps how we can trigger this issue.


My guess is, that this is an issue specific to your local configuration 
(fonts, locale, keyboard etc).


I've never seen an issue like this and haven't found anything in the bug 
stream bug tracker at https://github.com/systemd/systemd/issues that 
looks related.


What you can also try is to install the systemd v254 version from 
bookworm-backports.

https://backports.debian.org/Instructions/


Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056350: systemd: network int is stuck in "configuring" state if IPv6 RA msg deprecates a short-lived prefix

[Michael Biebl]

Control: tags -1 + fixed-upstream help

Hi Martin

Am 21.11.23 um 15:10 schrieb Martin Tonusoo:


The issue seems to be fixed in version 254.5-1~bpo12+2 from
bookworm-backports.



Since you mentioned the bpo version, I assume you want to see this fixed 
via a stable upload?


In this case, it would be great if you can find the relevant PR/commit 
between 252.17 and 254.5 via git bisect and then ask for a backport into 
the v252-stable branch upstream at 
https://github.com/systemd/systemd-stable.


Unfortunately I lack the required setup to run this git bisect myself so 
the fix for this issue will rely on your help.


Thanks,
Michael





OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Looking for a Google Summer of Code Mentor

[Michael Biebl]

Hi Alex,

thanks for your interest in Debian and systemd!

Reading through your proposal, I somehow miss the connection to Debian 
i.e. why this is best sponsored as a Debian specific project.


Maybe I'm missing something, but to me, this looks more like a project 
that should be sponsored by the systemd upstream project.

In the past, systemd upstream has participated in Outreachy.
Maybe they'd be willing to join GsoC as s well.

Regards,
Michael


Am 18.01.24 um 17:31 schrieb Alex Lieflander:

Hello,

I haven’t contributed to Debian before, but I recently read about Google Summer 
of Code and I’d love to participate. I’m trying to create a Debian-specific 
package which heavily relies on systemd and integrates with existing features. 
It seems that in order to submit my proposal for consideration I need a Debian 
developer to agree to mentor that project, and I’m wondering whether anyone on 
this mailing list would be interested. I haven’t written a proposal yet, but 
here’s a brief description of the project:

It’s called “Simple Slices”, and the goal is to make prioritized resource distribution 
more accessible to regular users by providing a small number of pre-configured systemd 
slices with different priorities; instead of a user specifying “nice” and “ionice" 
or CPUWeight and IOWeight values (and knowing what those mean), they specify a 
human-readable priority class like “medium-high".

By doing this via slices, systemd services and scopes can be given that 
priority class across reboots just by specifying the Slice directive via a 
drop-in config file. That could easily be done by a user-friendly application 
or as an overridable default specified by Debian, and because many DEs (at 
least KDE) launch graphical applications in systemd scopes, graphical 
applications could also be given a persistent priority level. There are several 
other really cool things about this project, and I’d be happy to provide 
additional information or answer any questions.

If anyone would be interested in mentoring this project or just contributing, 
please let me know.

Thanks,
Alex Lieflander




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060389: systemd: logind: HandlePowerKeyLongPress doesn't appear to work

[Michael Biebl]

Am 10.01.24 um 16:10 schrieb наб:

On Wed, Jan 10, 2024 at 03:40:27PM +0100, Michael Biebl wrote:

Am 10.01.24 um 15:26 schrieb наб:

As you can see in my logind.conf,
I have re-mapped the power key to suspend,
and long-pressing the power key to hibernate.

When I click the power key the machine suspends instantly
(and under X I see XF86PowerOff).
But this actually happens no matter how long I hold the button for,
and hibernation never occurs.

Maybe your desktop environment intercepts/interprets those keys?

It doesn't:
   $ grep XF86 .config/i3/config
   bindsym XF86AudioRaiseVolume exec --no-startup-id pactl set-sink-volume 
@DEFAULT_SINK@ +10% && $refresh_i3status
   bindsym XF86AudioLowerVolume exec --no-startup-id pactl set-sink-volume 
@DEFAULT_SINK@ -10% && $refresh_i3status
   bindsym XF86AudioMute exec --no-startup-id pactl set-sink-mute @DEFAULT_SINK@ toggle 
&& $refresh_i3status
   bindsym XF86AudioMicMute exec --no-startup-id pactl set-source-mute @DEFAULT_SOURCE@ 
toggle && $refresh_i3status

And, well, the xev seeing them means i3 didn't eat them.


Can you confirm the issue when being logged into the kernel console only
(i.e. no desktop environment running)?

I guess I forgot to note this explicitly:
yes this happens both under X and at a getty.

Best,


I'd say you best raise this upstream then at
https://github.com/systemd/systemd/issues

we do not ship any downstream patches in that regard.

Please report back with the upstream issue number so we can mark it 
accordingly.


Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1060389: systemd: logind: HandlePowerKeyLongPress doesn't appear to work

[Michael Biebl]

Am 10.01.24 um 15:26 schrieb наб:

Package: systemd
Version: 255.2-4
Severity: normal

Dear Maintainer,

As you can see in my logind.conf,
I have re-mapped the power key to suspend,
and long-pressing the power key to hibernate.

When I click the power key the machine suspends instantly
(and under X I see XF86PowerOff).
But this actually happens no matter how long I hold the button for,
and hibernation never occurs.


Maybe your desktop environment intercepts/interprets those keys?

Can you confirm the issue when being logged into the kernel console only 
(i.e. no desktop environment running)?





OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: serial-getty@ttyS0.service does not start

[Michael Biebl]

Am 07.01.24 um 14:45 schrieb Rainer Dorsch:

Hello,

I tried to start a serial console on ttyS0, but when I try to start the
serial-getty service, it does not return:


Looks like the service is waiting for the device to appear.
Do you have a /dev/ttyS0 device?
Can you show the output of

ls -la /dev/ttyS0
systemctl status dev-ttyS0.device
udevadm info /dev/ttyS0


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059857: discrepancy between upstream and downstream .service files

[Michael Biebl]

Source: open-iscsi
Version: 2.1.9-3
Severity: normal
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org

Hi,

today I wanted to enable the iSCSI test in systemd:
https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/test/TEST-64-UDEV-STORAGE/test.sh?ref_type=heads#L29-34

For that I added test dependency on open-iscsi and tgt.
Unfortunately, this failed:
```
W: Failed to install '/usr/lib/systemd/system/iscsi-init.service'
I: Skipping program /usr/lib/systemd/system/iscsi-init.service as it cannot be 
found and is flagged to be optional
W: Failed to install '/usr/lib/systemd/system/iscsi-onboot.service'
I: Skipping program /usr/lib/systemd/system/iscsi-onboot.service as it cannot 
be found and is flagged to be optional
W: Failed to install '/usr/lib/systemd/system/iscsi-shutdown.service'
I: Skipping program /usr/lib/systemd/system/iscsi-shutdown.service as it cannot 
be found and is flagged to be optional
W: Failed to install '/usr/lib/systemd/system/iscsi.service'
F: Failed to install /usr/lib/systemd/system/iscsi.service
make: Leaving directory 
'/tmp/autopkgtest.yvEXDQ/build.n6X/real-tree/test/TEST-64-UDEV-STORAGE'
[13:12:37] --x-- Result of TEST-64-UDEV-STORAGE: 2 --x--
```

I notice that the Debian open-iscsi package ships custom service files
with a custom naming:

./etc/systemd/iscsi-init.service.template
./etc/systemd/iscsi.service.template
./etc/systemd/iscsid.service.template
./etc/systemd/iscsiuio.service.template
./debian/iscsid.service
./debian/iscsiuio.service
./debian/open-iscsi.service

Would it be possible to use the upstream service files or at least align
the names?

Regards,
Michael

Bug#1059840: please bump --ram-size for qemu

[Michael Biebl]

Package: debci
Version: 3.9
Severity: wishlist
X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org, j...@debian.org, 
hel...@subdivi.de

Hi,

we are currently trying to get the systemd upstream autopkgtest suite pass
in Debian sid/trixie with qemu and I'm thrilled to see that qemu support
for debci is currently evaluated.

There is one failing test remaining, specifically TEST-13-NSPAWN [1],
which requires more then the default 1024M of ram size.
E.g. running it with --ram-size=2048 makes the tests pass successfully.

We thus would like to see the RAM limits be bumped globally to say 2048M
for debci or have a way how individual packages can set the qemu
--ram-size parameter.

The discussion on #debian-devel showed, that systemd is not the only
package currently affected by this ram limitation.
It was mentioned that apt also fails when run with virt-qemu.

Regards,
Michael


[1] https://github.com/systemd/systemd/issues/30488

Bug#1058880: systemd-binfmt.service: unit fails to start when /proc/sys/fs/binfmt_misc is not mounted

[Michael Biebl]

Am 31.12.23 um 17:43 schrieb Michael Biebl:

This was cherry-picked into v252-stable and is part of v252.21 which is 
very likely to be uploaded for the next Debian stable release.


s/uploaded/accepted/ , see

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1057861


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059216: Problem configuring polkitd after upgrade

[Michael Biebl]

Adamo,

can you send me the output of

ls -al /etc/group* /etc/gshadow*

and also attach the files /etc/group and /etc/gshadow

(feel free to send them to me only and not to the public bug tracker if 
you have any confidentiality concerns)



Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1058880: systemd-binfmt.service: unit fails to start when /proc/sys/fs/binfmt_misc is not mounted

[Michael Biebl]

On Mon, 18 Dec 2023 01:47:51 +0100 Michael Biebl  wrote:

Am 17.12.23 um 13:44 schrieb Aurelien Jarno:
> commit f74a7cb45c2458f90de6d37c70fa3afc1a3be279
> Author: Yu Watanabe 
> Date:   Sat Dec 10 11:46:45 2022 +0900
> 
>  unit: check more specific path to be written by systemd-binfmt
> 
>  Follow-up for 41807efb1594ae8e71e0255e154ea7d17be2251a.

>  Replaces #25690.
> 
> Would it be possible to backport this commit to bookworm?


Seems reasonable.
@Luca: can you include that in your next 252-stable batch? Should we 
file this as an issue in systemd/systemd-stable as a reminder?


This was cherry-picked into v252-stable and is part of v252.21 which is 
very likely to be uploaded for the next Debian stable release.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1059216: Problem configuring polkitd after upgrade

[Michael Biebl]

Please provide the output of (running as root)

SYSTEMD_LOG_LEVEL=debug systemd-sysusers polkitd.conf

Bug#1058880: systemd-binfmt.service: unit fails to start when /proc/sys/fs/binfmt_misc is not mounted

[Michael Biebl]

Am 17.12.23 um 13:44 schrieb Aurelien Jarno:

commit f74a7cb45c2458f90de6d37c70fa3afc1a3be279
Author: Yu Watanabe 
Date:   Sat Dec 10 11:46:45 2022 +0900

 unit: check more specific path to be written by systemd-binfmt

 Follow-up for 41807efb1594ae8e71e0255e154ea7d17be2251a.
 Replaces #25690.

Would it be possible to backport this commit to bookworm?


Seems reasonable.
@Luca: can you include that in your next 252-stable batch? Should we 
file this as an issue in systemd/systemd-stable as a reminder?


Regards,
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1058046: systemd: unable to run fsck at boot

[Michael Biebl]

Am 11.12.23 um 21:52 schrieb Alessandro Ogier:



On 12/11/23 20:20, Michael Biebl wrote:

Is expecting a clean "fsck -n -f XXX" run wrong?



Have you tried "fsck.mode=force fsck.repair=yes" as well?


while not suspecting a defect in the manual pages, I tried all 
combinations of yes/auto yes/preen. I have also tried rebooting now with 
these parameters, and I see the same output in the journal.


Tomorrow I'll try to replicate this on some other machine which I have, 
and maybe on a vm if I can figure out how to fake some filesystem error.





Please attach the output of "cat /proc/cmdline" of such a boot with 
forced fsck and the files /run/initramfs/fsck.log and 
/run/initramfs/fsck-root





OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1058046: systemd: unable to run fsck at boot

[Michael Biebl]

[please always CC the bug report on replies]

Am 11.12.23 um 19:47 schrieb Alessandro Ogier:

Ciao,

 thanks for your reply.

I see there is something more complex than I'm able to figure out, but I 
must report that upon reboot some trivial problems with the filesystem 
persist so it doesn't seem like anything has really done.


Is expecting a clean "fsck -n -f XXX" run wrong?



Have you tried "fsck.mode=force fsck.repair=yes" as well?
Afaics, the initrd does not understand "auto".

https://salsa.debian.org/kernel-team/initramfs-tools/-/blob/master/init#L182-192


fastboot|fsck.mode=skip)
fastboot=y
;;
forcefsck|fsck.mode=force)
forcefsck=y
;;
fsckfix|fsck.repair=yes)
fsckfix=y
;;
fsck.repair=no)
fsckfix=n
;;


regards,
Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1058046: systemd: unable to run fsck at boot

[Michael Biebl]

Am 11.12.23 um 18:30 schrieb Alessandro -oggei- Ogier:

Package: systemd
Version: 255-1
Severity: normal

Dear Maintainer,

 while doing some checks for the recent kernel ext4 problem, I've
noticed fsck does not seem to be able to run at boot, the command

journalctl -u systemd-fsck-root

reports:

-- Boot 2bb7b10680a74ab4854998cb33154999 --
dic 11 18:17:16 orso systemd[1]: systemd-fsck-root.service - File System
Check on Root Device was skipped because of an unmet condition check
(ConditionPathExists=!/run/initramfs/fsck-root).



this flag file means, that the / fs has already been checked by the initrd.




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057953: nss-myhostname: different IP address between man page and package description

[Michael Biebl]

Daniele Forsi schrieb am 10.12.2023 22:32 (GMT +01:00):

> Package: libnss-myhostname
> Version: 254.5-1
> Severity: minor
> X-Debbugs-Cc: dfo...@gmail.com
> 
> Dear maintainer,
> 
> the package description says:
>> It returns all locally configured public IP addresses or -- if
>> none are configured, the IPv4 address 127.0.1.1
> 
> the man page says:
>> The local, configured hostname is resolved to [...] the IPv4 address 
>> 127.0.0.2
> and the example shows 127.0.0.2 
> 
> Do they refer to different things?

Most likely the package description is simply out-of-date.

Bug#1057799: systemd: fails to configure

[Michael Biebl]

Am 09.12.23 um 00:53 schrieb JP Pozzi:

Hello,

Here the result :

grep users /etc/group /etc/gshadow
/etc/group:users:x:100:
/etc/gshadow:users:*::suricata


You appear to have a mismatch between /etc/group and /etc/gshadow.
Either your user "suricata" is listed in both or none.

Not sure how you ended up in this situation, but this looks like a local 
misconfiguration.


Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057799: systemd: fails to configure

[Michael Biebl]

Am 08.12.23 um 18:48 schrieb Michael Biebl:

On Fri, 08 Dec 2023 17:30:23 +0100 JPP  wrote:

Package: systemd
Version: 252.19-1~deb12u1
Severity: serious
Tags: d-i
Justification: normal

Dear Maintainer,

I get a problem upgrading the system, systemd fails to configure :

sudo dpkg --configure systemd
Setting up systemd (252.19-1~deb12u1) ...
Creating group 'users' with GID 100.
/etc/gshadow: Group "users" already exists.


Can you attach the output of

sudo grep users /etc/group /etc/gshadow



The output of

sudo SYSTEMD_LOG_LEVEL=debug systemd-sysusers /usr/lib/sysusers.d/basic.conf

as well, please


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057799: systemd: fails to configure

[Michael Biebl]

On Fri, 08 Dec 2023 17:30:23 +0100 JPP  wrote:

Package: systemd
Version: 252.19-1~deb12u1
Severity: serious
Tags: d-i
Justification: normal

Dear Maintainer,

I get a problem upgrading the system, systemd fails to configure :

sudo dpkg --configure systemd
Setting up systemd (252.19-1~deb12u1) ...
Creating group 'users' with GID 100.
/etc/gshadow: Group "users" already exists.


Can you attach the output of

sudo grep users /etc/group /etc/gshadow



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057417: systemd tmpfiles seems to delete lost+found again

[Michael Biebl]

Am 04.12.23 um 23:09 schrieb Michael Biebl:

The code to exclude lost+found appears to be still there:
https://github.com/systemd/systemd/blob/main/src/tmpfiles/tmpfiles.c#L720

Can you create a lost+found directory and then run
SYSTEMD_LOG_LEVEL=debug systemd-tmpfiles --prefix /tmp

?


I haven't really debugged this fully, but from a cursory glance it 
appears that systemd-tmpfiles-setup.service is responsible for nuking 
/tmp/lost+found


systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev
doesn't preserve /tmp/lost+found which looks like a regression.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057417: systemd tmpfiles seems to delete lost+found again

[Michael Biebl]

The code to exclude lost+found appears to be still there:
https://github.com/systemd/systemd/blob/main/src/tmpfiles/tmpfiles.c#L720

Can you create a lost+found directory and then run
SYSTEMD_LOG_LEVEL=debug systemd-tmpfiles --prefix /tmp

?


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1057417: systemd tmpfiles seems to delete lost+found again

[Michael Biebl]

On Mon, 4 Dec 2023 20:39:21 +0100 Axel Scheepers 
 wrote:

On Mon, Dec 4, 2023 at 8:27 PM Luca Boccassi  wrote:
> But the main point is, it's fine if you do a custom local setup with
> the appropriate local configuration, but then you also need to add the
> appropriate config for tmpfiles.d. You can either mask or replace
> tmp.conf, simply add your own file as /etc/tmpfiles.d/tmp.conf and it
> will have priority, and do what you need for your custom local setup.

Oh, ok. I admit I have a traditional unix background where it's common
practice to have these a separate real partitions instead. I'll just keep
the exception I already made then. I have some users on the system
which sometimes store larger things in there.


debian-installer offers a partition setup with separate /home, /var and 
/tmp very prominently (see attached screenshot).


Whether this is still a good idea nowadays is debatable.
As Luca said, if we offer /tmp as a separate partition, it should 
probably be tmpfs now and not an (ext4/xfs/...) partition.


For reference, I also include the legacy cleanup routine for SysV:
https://salsa.debian.org/debian/sysvinit/-/blob/master/debian/src/initscripts/lib/init/bootclean.sh#L119-128

So if there should be an exclusion for lost+found (for ext4), there 
should probably also be exclusion for quota related files.


Whether those exclusions should be shipped directly by systemd or 
created by d-i (as suggested by Luca on IRC), is something I don't have 
a strong opinion about. The downside of letting d-i create such a 
tmpfiles snippet is that we wouldn't cover existing systems.


As for d-i itself, my preferred solution for this would be to change it 
to uses tmpfs for /tmp.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245465
(that's an old bug report)


Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1002993: Also seen on chromebook

[Michael Biebl]

Am 23.11.23 um 03:56 schrieb Dan Jacobson:

Seen on Chromebook 120 Linux systemd 255~rc2-3

Setting access ACL "u::rwx,g::r-x,g:adm:r-x,g:4294967295:r-x,m::r-x,o::r-x" on 
/var/log/journal failed: Invalid argument
Setting access ACL "u::rwx,g::r-x,g:adm:r-x,g:4294967295:r-x,m::r-x,o::r-x" on 
/var/log/journal/f7d2e0290918427294865abb94e8fa09 failed: Invalid argument
Setting access ACL "u::rw-,g::r-x,g:adm:r--,g:4294967295:r-x,m::r--,o::---" on 
/var/log/journal/f7d2e0290918427294865abb94e8fa09/system.journal failed: Invalid argument

All I know is I use chromebook with Linux on chromeOS beta.


Are you running chromeOS or Debian?
Are you running chromeOS and Debian inside a container?
How is this container set up?

Something is messed up with your /var/log/journal folder. Is that bind 
mounted from a different user name space?




3. 4294967295, aka "32-bit `(uid_t) -1`" → This UID is not a valid user ID, as
   `setresuid()`, `chown()` and friends treat -1 as a special request to not
   change the UID of the process/file. This UID is hence not available for
   assignment to users in the user database.






OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053741: systemd-journal-remote: systemd-joural-uploading killed by watchdog every 3 minutes

[Michael Biebl]

Control: tags -1 moreinfo
On Tue, 31 Oct 2023 10:36:36 +0100 Michael Biebl  wrote:

Am 10.10.23 um 04:22 schrieb Tom Cameron:

> I have also looked at the systemd issue tracker on github, and while
> there has historically be several issues with journal-upload, none of
> them seem to have been reported recently.

Could you please raise this upstream and report back with the issue number?



Any updates here?
Without further information, this issue is not really actionable.


Regards,
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056166: systemd-homed: `passwd` fails

[Michael Biebl]

Control: found -1 254.5-1

This is not a regression of v255, as v254 shows the same behaviour.

Marking accordingly.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056166: systemd-homed: `passwd` fails

[Michael Biebl]

Am 18.11.23 um 03:25 schrieb Jack Pearson:

$ apt install systemd-homed
$ passwd
passwd: Authentication token manipulation error


Installing systemd-homed changes the PAM configuration of common-passwd:


 # here are the per-package modules (the "Primary" block)
-password   [success=1 default=ignore]  pam_unix.so obscure yescrypt
+password   [success=2 default=ignore]  pam_systemd_home.so 
+password   [success=1 default=ignore]  pam_unix.so obscure use_authtok try_first_pass yescrypt



Enabling some debug flags yields


Nov 18 05:39:03 debian passwd[6463]: pam_systemd_home(passwd:chauthtok): 
pam-systemd-homed account management
Nov 18 05:39:03 debian passwd[6463]: pam_systemd_home(passwd:chauthtok): Not a 
user managed by systemd-homed: No home for user michael known
Nov 18 05:39:03 debian passwd[6463]: pam_unix(passwd:chauthtok): username 
[michael] obtained
Nov 18 05:39:06 debian passwd[6463]: pam_systemd_home(passwd:chauthtok): 
pam-systemd-homed account management
Nov 18 05:39:06 debian passwd[6463]: pam_unix(passwd:chauthtok): username 
[michael] obtained
Nov 18 05:39:06 debian passwd[6463]: pam_unix(passwd:chauthtok): password - new 
password not obtained


I'm not really familiar with PAM though, so no idea how to fix this.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056137: systemd: downgrading systemd packages kills off the desktop environment

[Michael Biebl]

Am 17.11.23 um 15:31 schrieb Christoph Anton Mitterer:

Control: tags -1 - moreinfo

Hey Luca.


On Fri, 2023-11-17 at 14:03 +, Luca Boccassi wrote:

Please attach the journal from around the time where the installation
was happening


Please see the attached file.

Also I just remembered, that with 255~rc2-1, and after it happened that
downgrading killed my DE session... I logged into Cinnamon again, and
when *then* pressing the power button, it wasn't even like in #1056135,
that *only* the Hibernation button was missing, but *no* pop-up dialog
(with at least Suspend, Cancel, Restart, Shutdown) showed up, and it
went straight without any further confirmation into shutdown.


Just a word of warning: downgrades are not officially supported by Debian.
They might just work most of the time for more trivial packages, but 
often they don't (e.g. because data structures have changed that are 
converted on upgrades but not on downgrades).



Regards,
Michael





OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056108: Bug#1056059: dracut: systemd 255: dracut fails to boot due to lack of systemd-executor

[Michael Biebl]

Hi Thomas

Am 17.11.23 um 10:12 schrieb Thomas Lange:

I've already included the upstream patch to the git master branch of
dracut on salsa. The next dracut release in Debian will include the
fix.



Great, thanks. I assume this version will be 059-5 ?




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056066: systemd: rsyslog fails to start if /dev/xconsole exists

[Michael Biebl]

Control: reassign -1 rsyslog
Control: found -1 8.2310.0-2

Am 16.11.23 um 19:53 schrieb Sven Joachim:

On 2023-11-16 18:12 +0100, Michael Biebl wrote:


Am 16.11.23 um 17:17 schrieb Sven Joachim:
It appears, that PrivateTmp=yes was locked down further and is now
remounted read-only (thanks bluca for the reference):
https://github.com/systemd/systemd/commit/4a9e03aa6bb2cbd23dac00f2b2a7642cc79eaade


Thanks, I had suspected something along these lines.



It's unlikely that systemd upstream is going to revert this behaviour 
change, so I'm going to reassign this issue to rsyslog to handle it there.



We basically have two options as I see it:

a/ Drop PrivateDevices=yes from rsyslog.service

b/ Move /dev/xconsole to run and turn /dev/xconsole into a symlink


The latter b/ will require updates to the local copies in
/etc/tmpfiles.d/ and /etc/rsyslog.d/

They would look like this now:

$ cat /etc/rsyslog.d/xconsole.conf
daemon.*;mail.*;\
news.err;\
*.=debug;*.=info;\
*.=notice;*.=warn   |/run/xconsole

$ cat /etc/tmpfiles.d/xconsole.conf
# Type Path Mode UID  GID  Age Argument
p /run/xconsole 0640 root adm
L /dev/xconsole ----   /run/xconsole

Conceptually, moving the named pipe out of /dev and into /run is the
cleaner solution I think. The /dev/xconsole symlink should make it
reasonably backwards compatible.

Thoughts?


I think b/ and an appropriate debian/NEWS entry in rsyslog are
preferable to softening security, even if it means some disruption for
the minority of users who still monitor logs via xconsole.  But there
may be more complaints once the changes arrive in testing.



Since b/ is my favorite as well, let's go with this.


Personally I have made your proposed changes, and after restarting
rsyslog and xconsole everything works fine again.


Thanks for testing.

Will poke you, once I have a MR ready. Maybe you want to proof read the 
NEWS entry.


Regards,
Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056108: v255 breaks boot with dracut

[Michael Biebl]

Package: systemd
Version: 255~rc2-1
Severity: serious

The addition of systemd-executor breaks dracut in a bad way.
It generates an unbootable initrd.

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056059

Filing with RC severity to notify users and to prevent testing
migration.

We should add a (versioned) Breaks against dracut to ensure that dracut
users do not end up with an unbootable system.


Michael

Bug#1056066: systemd: rsyslog fails to start if /dev/xconsole exists

[Michael Biebl]

Am 16.11.23 um 18:12 schrieb Michael Biebl:

b/ Move /dev/xconsole to run and turn /dev/xconsole into a symlink


The latter b/ will require updates to the local copies in 
/etc/tmpfiles.d/ and /etc/rsyslog.d/


They would look like this now:

$ cat /etc/rsyslog.d/xconsole.conf
daemon.*;mail.*;\
 news.err;\
 *.=debug;*.=info;\
 *.=notice;*.=warn    |/run/xconsole

$ cat /etc/tmpfiles.d/xconsole.conf
# Type Path Mode UID  GID  Age Argument
p /run/xconsole 0640 root adm
L /dev/xconsole -    -    -    -   /run/xconsole


And you need to drop BindPaths=-/dev/xconsole from rsyslog.service again.







OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1056066: systemd: rsyslog fails to start if /dev/xconsole exists

[Michael Biebl]

Am 16.11.23 um 17:17 schrieb Sven Joachim:

Package: systemd
Version: 255~rc2-1
Severity: important

After upgrading systemd from 254.5-1 and rebooting, rsyslog failed to
start on my system.  These messages appear in the journal:

,
| Nov 16 16:58:10 localhost systemd[1]: Starting rsyslog.service - System 
Logging Service...
| Nov 16 16:58:10 localhost (rsyslogd)[674]: Failed to create destination mount 
point node '/run/systemd/mount-rootfs/dev/xconsole', ignoring: Read-only file 
system
| Nov 16 16:58:10 localhost (rsyslogd)[674]: Failed to mount /dev/xconsole to 
/run/systemd/mount-rootfs/dev/xconsole: No such file or directory
| Nov 16 16:58:10 localhost (rsyslogd)[674]: rsyslog.service: Failed to set up 
mount namespacing: /dev/xconsole: No such file or directory
| Nov 16 16:58:10 localhost systemd[1]: rsyslog.service: Main process exited, 
code=exited, status=226/NAMESPACE
| Nov 16 16:58:10 localhost systemd[1]: rsyslog.service: Failed with result 
'exit-code'.
| Nov 16 16:58:10 localhost systemd[1]: Failed to start rsyslog.service - 
System Logging Service.
| Nov 16 16:58:10 localhost systemd[1]: rsyslog.service: Scheduled restart job, 
restart counter is at 1.
`

This gets repeated a few times, and after five restart attempts systemd
gives up.

It should be noted that I have enabled forwarding messages to xconsole
according to the the "Logging to xconsole" section in
/usr/share/doc/rsyslog/README.Debian, and the problem is obviously in
the bind mount for /dev/xconsole.  Removing /dev/xconsole so that the
"BindPaths=-/dev/xconsole" statement in rsyslog.service has no effect
lets rsyslog start, but recreates the problem of #1053913.


It appears, that PrivateTmp=yes was locked down further and is now 
remounted read-only (thanks bluca for the reference):

https://github.com/systemd/systemd/commit/4a9e03aa6bb2cbd23dac00f2b2a7642cc79eaade

We basically have two options as I see it:

a/ Drop PrivateDevices=yes from rsyslog.service

b/ Move /dev/xconsole to run and turn /dev/xconsole into a symlink


The latter b/ will require updates to the local copies in 
/etc/tmpfiles.d/ and /etc/rsyslog.d/


They would look like this now:

$ cat /etc/rsyslog.d/xconsole.conf
daemon.*;mail.*;\
news.err;\
*.=debug;*.=info;\
*.=notice;*.=warn   |/run/xconsole

$ cat /etc/tmpfiles.d/xconsole.conf
# Type Path Mode UID  GID  Age Argument
p /run/xconsole 0640 root adm
L /dev/xconsole ----   /run/xconsole

Conceptually, moving the named pipe out of /dev and into /run is the 
cleaner solution I think. The /dev/xconsole symlink should make it 
reasonably backwards compatible.


Thoughts?


Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055415: Wrong order for the `resolve' option in nsswitch.conf

[Michael Biebl]

On Sun, 5 Nov 2023 20:41:44 +0100 Sylvain Garrigues 
 wrote:

Le dimanche 5 novembre 2023, Michael Biebl  a écrit :

>
> See https://salsa.debian.org/systemd-team/systemd/-/merge_requests/162
>
>
This is indeed related. Yet the changes (as of today) do not seem to fix
the order for `resolve'. This merge request seems to be waiting for a
consensus before it can make progress.


Indeed, we don't have a consensus yet what the correct ordering is, if 
there is such a thing.

As for myself, I don't have a strong opinion.

Aspects to consider:
- systemd upstream recommendations
- seeing how other distros are doing it
- our status quo (which sort of works in the absence of bug reports)

Given all involved packages, another problem is the order in which 
packages are installed. I fear, we can't solve this with the current 
setup/infrastructure, where every package on its own mangles 
/etc/resolv.conf


We'd need something like Gioele's idea for dh-nss v2, where 
/etc/resolv.conf is compiled from a list of config files that are 
provided by packages shipping NSS modules.


Gioele has a much more intimate grasp on this matter, so I've CCed him.

Regards,
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055415: Wrong order for the `resolve' option in nsswitch.conf

[Michael Biebl]

Am 05.11.23 um 16:12 schrieb Sylvain Garrigues:

Package: libnss-resolve
Version: 252.17-1~deb12u1
X-Debbugs-CC: pkg-systemd-maintain...@lists.alioth.debian.org

The debian postinstall script for libnss-resolve inserts `resolve' in
the `hosts:' line of /etc/nsswitch.conf before `dns', therefore after
`files'. This does not seem optimal, as per `man nss-resolve', which
reads:
Specifically, it is recommended to place "resolve" early in
/etc/nsswitch.conf's "hosts:" line. It should be before the "files"
entry, since systemd-resolved supports /etc/hosts internally, but with
caching.



See https://salsa.debian.org/systemd-team/systemd/-/merge_requests/162



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053741: systemd-journal-remote: systemd-joural-uploading killed by watchdog every 3 minutes

[Michael Biebl]

Am 10.10.23 um 04:22 schrieb Tom Cameron:


I have also looked at the systemd issue tracker on github, and while
there has historically be several issues with journal-upload, none of
them seem to have been reported recently.


Could you please raise this upstream and report back with the issue number?

Thanks,
Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1033548: 02:00 timers dont run in DST transition night

[Michael Biebl]

Control: forwarded -1 https://github.com/systemd/systemd/issues/5595

I think the above upstream issue pretty much describes what you are 
seeing, so marking as forwarded accordingly.


Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054425: udev

[Michael Biebl]

Am 25.10.23 um 00:00 schrieb Michael Biebl:

Control: tags -1 + moreinfo

Please attach all files from /etc/udev/rules.d verbatim


Also make sure, to not have any outdated udev rules in your initramfs.

A verbose debug log of udev, showing the problem, would also be helpful.
See man kernel-command-line → udev.log_level


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054425: udev

[Michael Biebl]

Control: tags -1 + moreinfo

Please attach all files from /etc/udev/rules.d verbatim


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054394: Postinst installs unsigned (unbootable) efi on secure boot systems

[Michael Biebl]

Am 23.10.23 um 11:32 schrieb sympathischerwal:

Package: systemd-boot
Version: 252.12-1~deb12u1

When updating systemd-boot on a system with secure-boot
enabled, the postinst calls `bootctl update --graceful` which
installs an unsigned efi. This will overwrite an existing efi
with correct signature and cause the system to not boot
anymore, because of a security violation.

The postinst should either read a config file, so users can disable
this behavior or only update the efi when it has the correct
signature.


Introducing a config variable for this is something I'm not keen on.
Not running an update of the EFI binaries is problematic as well.

Is there a programmatic, defined way to find out if the sd-boot efi 
binaries have been signed? If so, we could at least add a warning to 
postinst if we detect such a situation.



Aside from the dpkg/apt hook I mentioned earlier, what you might do is 
to dpkg-divert bootctl and replace it with a wrapper script that does 
the update + signing for your setup.


Regards,
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054394: Postinst installs unsigned (unbootable) efi on secure boot systems

[Michael Biebl]

Am 23.10.23 um 12:17 schrieb sympathischerwal:

Hi,

I am running secure boot with my own keys.
I signed the efi binary myself with my own keys and put it
to the efi partition. On a systemd-boot upgrade, the postinst
overwrites these files, which made my bootable system unbootable.


You could install a dpkg and/or apt hook which does the signing 
automatically after a package update.


See e.g. the needrestart package for how to use such a hook.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054391: systemd-journal-remote aborts when getting remote messages complaining about field size

[Michael Biebl]

Hello,

thanks for your bug report.
The Debian package does not ship any specific patches in that regard.
It would thus be best if you raise this upstream at 
https://github.com/systemd/systemd/issues/


Regards,
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1031721: closed by Michael Biebl (Re: Bug#1031721: udev fails to autoload kernel modules (wifi, sound, video, bluetooth, thermals))

[Michael Biebl]

Am 21.10.23 um 23:33 schrieb Sohum Banerjea:

Hi there. Apologies — I just missed your previous email.

I can confirm the problem still reproduces on 254.5-1. To be clear: my 
symptoms are that I have at this point collected the list of modules my 
system needs to run, and listed them in /etc/modules. If I remove, say, 
iwlwifi from them, I boot into a system that does not have iwlwifi 
loaded, and thus no wifi functionality, until I manually modprobe iwlwifi.


It was merely a guess that it couldn't find hwdb, based on those log 
lines — if they are not unusual, then that guess falls apart. I'm 
willing to do any further log collection or investigation required, but 
I would need instructions on how to do so.


What exactly is responsible for autoloading kernel modules based on 
hardware? Maybe it would help if I gained familiarity with that code file?


https://wiki.archlinux.org/title/Modalias
https://documentation.suse.com/sles/12-SP5/html/SLES-all/cha-udev.html#sec-udev-drivers
https://www.linuxfromscratch.org/lfs/view/development/chapter09/udev.html



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1050098: systemd: Using systemd-networkd as DHCP server static leases are ignored

[Michael Biebl]

On Sat, 19 Aug 2023 18:34:00 + Jan Dorniak  wrote:

Package: systemd
Version: 252.12-1~deb12u1
Severity: normal
X-Debbugs-Cc: j...@dorniak.me

Dear Maintainer,

Using two Bookworm systems, one as a DHCP server, one as a DHCP client.

The server does not respect static leases. The issue has been fixed in
systemd 254.

For description, see: https://github.com/systemd/systemd/issues/21368
For the patch, see: https://github.com/systemd/systemd/pull/27313


If you want to see this fixed for v252, please ask for a v252-stable 
backport upstream.


https://github.com/systemd/systemd-stable/issues




OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: RFS: systemd-cron / bookworm-backports

[Michael Biebl]

Am 21.10.23 um 10:57 schrieb Alexandre Detiste:

Hi,

Can you please publish a backport of systemd-cron to bookworm-backports ?

It looks like these commands are enough but I don't have the ACL for
the backport:


gbp clone g...@salsa.debian.org:detiste-guest/systemd-cron.git
dch --bpo ''
debuild -S
cd ..
dput ftp-master systemd-cron_2.3.0-1~bpo12+2_source.changes



Can you send me a ready to be uploaded dsc (don't want to mess up your git).

Michael




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053872: systemd with high load after 19-01-2038

[Michael Biebl]

Control: tags -1 + unreproducible

On 10/13/23 13:00, Tony de Goede wrote:

Package: systemd
Version: 252.12-1~deb12u1
Severity: serious
Justification: linux system unstable

Dear Maintainer,

    When setting the time to 19 Jan 2038 3:14 GMT using "date 
011903142038" the systemd gets high load.

    At 7 seconds after 3:14 the date is correct in the kernel but systemd
    get high load.


I'm not able to reproduce the problem.
So I'm not going to forward this issue to upstream.

If you can reliably reproduce the issue, please file this directly at
https://github.com/systemd/systemd/issues

Thanks
Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1054211: systemd: ystemd-networkd-wait-online.service reports a timeout error while network is activated

[Michael Biebl]

On 10/19/23 10:47, eric wrote:

Package: systemd
Version: 254.5-1
Severity: normal

I think this is related to the new version of package network manager

systemd-analyze blame
2min 117ms systemd-networkd-wait-online.service


Do you have any network interfaces managed by systemd-networkd?
If not, why is systemd-networkd-wait-online.service enabled?





OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051981: systemd-boot kernel postinst script calls ukify which requires python3

[Michael Biebl]

On Wed, 20 Sep 2023 21:41:59 +0200 Michael Biebl  wrote:

FYI: https://salsa.debian.org/systemd-team/systemd/-/merge_requests/216



To mitigate this issue for the time being, I suggest we simply remove 
/usr/lib/kernel/install.d/60-ukify.install from the systemd package (or 
ship in /usr/share/doc/systemd/examples, so users could copy it to 
/etc/kernel/install.d/)


Splitting off systemd-ukify turns out to be a larger change and with the 
/usr merge change going on, maybe something we want to avoid/postpone.


Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053482: systemd-resolved: resolved can intermittingly fail AF_UNSPEC queries to CNAMEd domains

[Michael Biebl]

Am 05.10.23 um 02:18 schrieb benja...@locrian.net:

Package: systemd-resolved
Version: 252.12-1~deb12u1
Severity: important

Dear Maintainer,

When systemd-resolved simultaneously does A and  queries, it fails if one 
of the queries returns a CNAME with a zero ttl and the other query returns a 
CNAME with a nonzero ttl. This happens in practice with several DNS providers. 
A fix for the problem was recently merged upstream at 
https://github.com/systemd/systemd/commit/8ec951e8d5cdd3ad632b1cbd8bcbe21d68b17512.
 See that commit for further details about the issue.

Please consider backporting this fix to bookworm.


Please ask for a backport to the v252-stable branch upstream.

Regards,
Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053443: automount should not act if filesystem is already mounted

[Michael Biebl]

Do you both /efi *and* /boot/efi

The automount unit is for efi.automount


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1053443: automount should not act if filesystem is already mounted

[Michael Biebl]

Am 04.10.23 um 08:38 schrieb Marc Haber:

Package: systemd
Version: 254.5-1
Severity: minor
File: /usr/share/man/man8/systemd-gpt-auto-generator.8.gz

Hi,

on my systems, /boot/efi is mounted via /etc/fstab. I am not sure
whether this is wrong, but I'd like it to be mounted all the time and
stay mounted. When aide runs, a generated efi.automount is invoked and
mounts /boot/efi again over the already mounted filesystem.

Since the EFI partition is a vfat filesystem which doesn't have inodes,
the inode values are synthesized differently for every aide run, which
triggers a security mechanism in aide since aide now thinks that
somebody is trying to move a different file in place between file
enumeration and checksum building.

Could the generated automounter please grow a condition to not act if
the filesystem in question is already mounted?


hm, that sounds like a bug. Reading man systemd-gpt-auto-generator
'''

   The ESP is mounted to /boot/ if that directory exists and is not 
used for XBOOTLDR, and otherwise to /efi/. Same as for /boot/, an 
automount unit is used. The mount point will be created if necessary.


   No configuration is created for mount points that are configured 
in fstab(5) or when the target directory contains files.


'''

You can disable systemd-gpt-auto-generator via the systemd.gpt_auto=0 
kernel command line parameter until this is addressed.


Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1052365: systemd: DHCP client fails if multiple DHCP servers on network

[Michael Biebl]

Hi Alexandre

Am 21.09.23 um 01:59 schrieb Alexandre Ferreira:
DHCP client on systemd-networkd sends requests as broadcast so if there 
is more than one DHCP server on the network
all but one will answer NAK: wrong server-ID. DHCP client stops at the 
first NAK and ignores the ACK that will be sent.
THe attached patch included a test refusing any NAK that does not come 
from the same IP that the request was sent.



Patches like this one, should be submitted upstream and reviewed there.

Can you please create a PR at
https://github.com/systemd/systemd/pulls

Thanks,
Michael



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051981: systemd-boot kernel postinst script calls ukify which requires python3

[Michael Biebl]

FYI: https://salsa.debian.org/systemd-team/systemd/-/merge_requests/216



OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051874: closed by Michael Biebl (Re: Bug#1051874: systemd: XDG_RUNTIME_DIR is not set in X11 login session (MATE/slim))

[Michael Biebl]

Am 15.09.23 um 03:57 schrieb Linas Vepstas:

Hi,

On Thu, Sep 14, 2023 at 12:51 PM Debian Bug Tracking System 
mailto:ow...@bugs.debian.org>> wrote:


I installed a test VM with bookworm and task-mate-desktop and slim.

Everything is working fine.
So I must conclude this is a local (mis)configuration.


The problem manifested after an upgrade from bullseye, and not in a 
fresh bookworm install. I did not perform any local configuration. No 
change from `apt reinstall slim`.


The test VM had a basic bullseye installation (only task "standard")
I upgraded it to bookworm via
apt full-upgrade
then installed MATE via
apt install task-mate-desktop slim
and selected slim as login manager.

You need to provide more specific instructions how this issue can be 
reproduced. Ideally by starting from a fresh, minimal installation.


Michael





OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051981: systemd-boot kernel postinst script calls ukify which requires python3

[Michael Biebl]

Am 15.09.23 um 11:06 schrieb Christopher Obbard:

To workaround this, I have deleted /usr/lib/kernel/install.d/60-ukify.install


If installing python3-minimal is not an option, a better alternative is 
to run

touch /etc/kernel/install.d/60-ukify.install

This will disable the script shipped in the systemd package and will 
survive a package update.


Michael


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051981: R:e systemd-boot kernel postinst script calls ukify which requires python3

[Michael Biebl]

Am 15.09.23 um 12:54 schrieb Alexandre Detiste:

A possible middle way could be to implement
/usr/lib/kernel/install.d/60-ukify.install in shell, the script seems
the script seems simple enough.


The little script load & call a much bigger one:
   https://github.com/systemd/systemd/blob/main/src/ukify/ukify.py


Sure, but 60-ukify.install could print a proper diagnostic warning 
message if python3 is missing without failing all of update-initramfs.





OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051981: systemd-boot kernel postinst script calls ukify which requires python3

[Michael Biebl]

Am 15.09.23 um 11:06 schrieb Christopher Obbard:

Package: src:systemd
Version: 254.1-3
Severity: important
X-Debbugs-Cc: chris.obb...@collabora.com

Dear Maintainer,

Installing a new kernel on a system which uses systemd-boot as the
bootloader fails if python3 is not installed. Here's the snippet from apt
upgrade:

 /etc/kernel/postinst.d/zz-systemd-boot:
 Installing kernel version 6.4.0-4-amd64 in systemd-boot...
 /usr/bin/env: ‘python3’: No such file or directory
 /usr/lib/kernel/install.d/60-ukify.install failed with exit status 127.

This renders the new kernel unusable as it never actually gets installed
in the right place for systemd-boot.

/etc/kernel/postinst.d/zz-systemd-boot calls kernel-install, which in turn
calls /usr/lib/kernel/install.d/60-ukify.install which calls /lib/systemd/ukify
to attempt to create a unified kernel image. These are both python3 scripts.

To workaround this, I have deleted /usr/lib/kernel/install.d/60-ukify.install
as we don't (yet!) create uki images with the ukify utility anyway. When
the ukify postinst script _does_ run, it currently just detects the
environment variable KERNEL_INSTALL_LAYOUT != "uki" (set from some config
files) and exits early, not even creating the uki. So this is opt-in.

/lib/systemd/ukify is shipped in the systemd package along with
/usr/lib/kernel/install.d/60-ukify.install, which I think is wrong as
systemd package does not have the right dependencies for this script.


Perhaps we should split the ukify bits into its own package (systemd-ukify)
which depends on python3 and should be manually installed? Also this package
can then depend on e.g. sbsigntool and other packages to actually manage
the signing (but that can be a separate bug!).



Having a separate package feels a bit like overkill for 68K

52K /lib/systemd/ukify
8,0K/usr/lib/kernel/install.d/60-ukify.install
8,0K/usr/share/man/man1/ukify.1.gz


While systemd has a suggests python3, we certainly don't want a hard 
python3 dependency though.


A possible middle way could be to implement 
/usr/lib/kernel/install.d/60-ukify.install in shell, the script seems 
simple enough.


Michael




OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051938: systemd: "Assertion 'path_is_absolute(p)' failed" on upgrade

[Michael Biebl]

Am 14.09.23 um 19:52 schrieb Michael Biebl:

Am 14.09.23 um 15:43 schrieb Michel Meyers:
Assertion 'path_is_absolute(p)' failed at src/basic/chase.c:628, 
function chase( ). Aborting.


Sounds like
https://github.com/systemd/systemd/issues/28458


Do you use any virtualization like OpenVZ ?


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1051938: systemd: "Assertion 'path_is_absolute(p)' failed" on upgrade

[Michael Biebl]

Am 14.09.23 um 15:43 schrieb Michel Meyers:
Assertion 'path_is_absolute(p)' failed at src/basic/chase.c:628, 
function chase( ). Aborting.


Sounds like
https://github.com/systemd/systemd/issues/28458


OpenPGP_signature.asc
Description: OpenPGP digital signature