Code: Select all
[ebuild U ] sys-libs/glibc-2.34-r10 [2.33-r13]Code: Select all
# cat sys-libs:glibc-2.34-r10:20220327-162043.log
WARN: postinst
After upgrading glibc, please restart all running processes.
Be sure to include init (telinit u) or systemd (systemctl daemon-reexec).
Alternatively, reboot your system.https://github.com/gentoo/gentoo/pull/22960#issuecomment-971305885 wrote:Outside of this bug/PR, we should explicitly formulate whatever policy there is/isn't on touching system daemons within ebuilds. And in any case, a news item is probably warranted for this cycle then?
I was wondering if that was so. Yes, I had been running glibc-2.33-r7 from November 1st.Hu wrote:As I read this, the warning can only trigger if changing the upstream glibc version. If on March 7 you had an earlier iteration of glibc-2.33, such as glibc-2.33-r7, and then upgraded to glibc-2.33-r13, no warning would be issued.
Summary is something like:Hu wrote:It looks like 2.33-r13 has the same warning. Any processes you leave running will continue to use the old glibc. That may or may not work. I assume someone must have reported a significant failure that would have been avoided by this, though I don't see a reference in the ebuild, and the web GUI for the Gentoo Portage tree fails (first byte timeout) when trying to use git log on a subdirectory. The Github mirror fails differently, and blames this on a revision bump, which seems unlikely.
The only Gentoo bug report I can readily find references a problem with systemd in glibc-2.34, but the git commit for that bug is not what added this warning.
Further digging leads to a commit by sam_: https://github.com/gentoo/gentoo/commit ... ea291189f4, which does not cite a bug number nor explain the purpose. I note that it replaces an active restart of systemd with this warning advising to restart systemd or sysvinit. Perhaps the active restart caused problems.
Digging even further reveals https://github.com/gentoo/gentoo/commit ... ed5da614cc, which made that change in some versions of glibc. sam_'s change merely backports that warning into other versions. This commit cites https://github.com/gentoo/gentoo/pull/22960. Incidentally, a comment in that pull request suggests a news item:https://github.com/gentoo/gentoo/pull/22960#issuecomment-971305885 wrote:Outside of this bug/PR, we should explicitly formulate whatever policy there is/isn't on touching system daemons within ebuilds. And in any case, a news item is probably warranted for this cycle then?
One could argue that way, but in the end this would be quite a lot of effort for a single special case. And special cases are the source of all evil ...Goverp wrote:Bit of a necropost, but just wondering if glibc requires a reboot or restarting all processes, was it sensible of emerge to upgrade it first and then smoothly continue to upgrade another 40 or so packages on my system today!
In theory (and I say that because I've never noticed a problem from not rebooting immediately in umpteen years running Gentoo) shouldn't it at least restart itself, and maybe optionally something worse. (Worse would be to emulate Windows, and schedule a reboot at some maximally-inconvenient moment such as during a PowerPoint presentation or a Zoom call with the boss in the audience.)
Code: Select all
$ cat /var/log/portage/elog/sys-libs:glibc-2.36-r5:20221117-172841.log
WARN: postinst
After upgrading glibc, please restart all running processes.
Be sure to include init (telinit u) or systemd (systemctl daemon-reexec).
Alternatively, reboot your system.
(See bug #660556, bug #741116, bug #823756, etc)
Code: Select all
$ cat /var/log/portage/elog/sys-libs:pam-1.5.2-r2:20220905-014818.log
WARN: postinst
Some software with pre-loaded PAM libraries might experience
warnings or failures related to missing symbols and/or versions
after any update. While unfortunate this is a limit of the
implementation of PAM and the software, and it requires you to
restart the software manually after the update.
You can get a list of such software running a command like
lsof / | grep -E -i 'del.*libpam\.so'
Alternatively, simply reboot your system.
I thought of this as well. I had intended to delay the upgrade, but apparently forgot about the warning.figueroa wrote:Pam, on the other hand, spells it out for the user, and I find it easy to do the "lsof / grep ..." routine
So basically most anything that runs a daemon and anything you've left running for a while (tmux, vi, terminals, etc.).agetty
bash
crond
dhcpcd
init
lvmetad
ntpd
sshd
syslogd
systemd-u
tmux
vi
Not quite sure what your point is: The pam message just tells you how to identify processes using pam. In case of glibc, that's simply "all processes" as almost everything uses libc. In both cases you still need to figure out how to restart those processes (reboot being the easy option).figueroa wrote: That's not so helpful when the user isn't told how to go about restarting all processes. I don't know how to restart ALL processes, so I chickened out and rebooted later in the afternoon after pondering the mysteries.
Pam, on the other hand, spells it out for the user, and I find it easy to do the "lsof / grep ..." routine suggested in pam''s elog.
Seems like there are some other special cases, see some previous posts. Perhaps emerge could have an option to stop after such a package to allow for restarting - though in reality the extra pain means probably nobody would actually select it!Genone wrote:One could argue that way, but in the end this would be quite a lot of effort for a single special case. And special cases are the source of all evil ...Goverp wrote:... if glibc requires a reboot or restarting all processes, was it sensible of emerge to upgrade it first and then smoothly continue to upgrade another 40 or so packages on my system today!
In theory ... shouldn't it at least restart itself ...
Yes, esp. as it doesn't matter in 99% of all cases wether you're still using a replaced library. The messages are mainly a reminder to restart long-running processes that would otherwise continue to run for days, weeks or months still using the old version, and as a result could over time cause issues that are hard to trace. It's basically just a variation of the ancient debate if portage should restart services when their packages are updated.Goverp wrote:Seems like there are some other special cases, see some previous posts. Perhaps emerge could have an option to stop after such a package to allow for restarting - though in reality the extra pain means probably nobody would actually select it!
