Discussion:
Running “telinit u” on glibc update
Add Reply
Reindl Harald
2018-05-16 13:19:07 UTC
Reply
Permalink
Raw Message
In Fedora, for historic reasons, we run “/sbin/telinit u” after
installing a new glibc RPM package version.
Does this still make sense?  Should we remove the code which invokes
telinit from the glibc package?
how do you come to that conclusion given it's part of systemd and
repsonsible to trigger "systemctl daemon-reexec" after said updates?

[***@buildserver:~]$ which telinit
/usr/sbin/telinit

[***@buildserver:~]$ rpm -q --file /usr/sbin/telinit
systemd-234-11.git5f8984e.fc27.x86_6
Michael Biebl
2018-05-16 13:42:44 UTC
Reply
Permalink
Raw Message
Hi Florian
In Fedora, for historic reasons, we run “/sbin/telinit u” after installing a
new glibc RPM package version.
Does this still make sense? Should we remove the code which invokes telinit
from the glibc package?
We had something similar in the Debian glibc package
The background is in this bug report
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753725

Afaiu, the telinit u was originally added so sysvinit can shutdown
cleanly and there were no open fds:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=25444

But this is not an issue with systemd/systemd-shutdown.
As the daemon-reexec was causing issues in Debian, we decided to
remove it from the glibc postinst.

Regards,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Lennart Poettering
2018-05-16 21:52:47 UTC
Reply
Permalink
Raw Message
In Fedora, for historic reasons, we run “/sbin/telinit u” after installing a
new glibc RPM package version.
Does this still make sense? Should we remove the code which invokes telinit
from the glibc package?
So I am pretty sure this is about not keeping the old .so images maps
pinned for good, i.e. so that they can be removed from disk and don't
keep the file system busy. This isn't really necessary in systemd
though, as we will always execve() from PID1 into a new process during
shutdown, which should drop all pinned pages anyway, unconditionally
and always.

Hence, no I don't think this needs to be there. I mean, I would see
value if we could unpin the old mapped .so images system-wide,
comprehensively, right away, but such a concept doesn't exist, we only
can can do this for some services, and it's racy and hence nothing we
should attempt. Doing this just for PID 1 hence doesn't really help
much, it's a drop of water on a hot stone.

Hence, please go aahead and drop it from the rpm scripts.

Lennart
--
Lennart Poettering, Red Hat
Florian Weimer
2018-05-17 09:59:42 UTC
Reply
Permalink
Raw Message
Post by Lennart Poettering
Hence, please go aahead and drop it from the rpm scripts.
Thanks for the clear advice. I filed

https://bugzilla.redhat.com/show_bug.cgi?id=1579225

to track the removal.

Florian

Loading...