| View previous topic :: View next topic |
| Author |
Message |
figueroa
Advocate
Joined: 14 Aug 2005
Posts: 3007
Location: Edge of marsh USA
|
 Posted: Sun Mar 27, 2022 4:55 pm Post subject: Upgrade glibc needs reboot? |
 |
|
Today, the following update:
| Code: | | [ebuild U ] sys-libs/glibc-2.34-r10 [2.33-r13] |
After upgrade, /var/log/portage/elog for the new glibc reads:
| Code: | # 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. |
Really, really? This is new. Shouldn't it have at least been a NEWS item? ALL running processes is a whole lot. Is there a practical way to do that without crashing everything? I'm standing pat for now; busy with other work.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
| Back to top |
|
 |
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22915
|
| Posted: Sun Mar 27, 2022 5:31 pm Post subject: |
|
|
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/1aa54cb91cfc6da9f151abaa49f045ea291189f4, 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/30fe8b89aef9f0701f6dcd935421b8ed5da614cc, 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: |
|
| Back to top |
|
|
figueroa
Advocate
Joined: 14 Aug 2005
Posts: 3007
Location: Edge of marsh USA
|
| Posted: Sun Mar 27, 2022 5:41 pm Post subject: |
|
|
Thank, Hu. Very interesting. When I upgraded to sys-libs/glibc-2.33-r13 on March 7, no elog message was created.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 22915
|
| Posted: Sun Mar 27, 2022 6:05 pm Post subject: |
|
|
| 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. |
|
| Back to top |
|
|
figueroa
Advocate
Joined: 14 Aug 2005
Posts: 3007
Location: Edge of marsh USA
|
| Posted: Sun Mar 27, 2022 6:11 pm Post subject: |
|
|
| 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. |
I was wondering if that was so. Yes, I had been running glibc-2.33-r7 from November 1st.
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
| Back to top |
|
|
figueroa
Advocate
Joined: 14 Aug 2005
Posts: 3007
Location: Edge of marsh USA
|
| Posted: Sun Mar 27, 2022 7:07 pm Post subject: |
|
|
I yield to "best practices." A lot of reboot-required guidance formalized by Red Hat at the following link: https://access.redhat.com/solutions/27943
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 2063
|
| Posted: Sun Mar 27, 2022 9:06 pm Post subject: |
|
|
| 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/1aa54cb91cfc6da9f151abaa49f045ea291189f4, 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/30fe8b89aef9f0701f6dcd935421b8ed5da614cc, 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: |
Summary is something like:
- We have bugs like bug 823756 ("systemd needs restart/reload") after glibc upgrades
- ... and same for stuff like cronie, rsync (bug 741116, and more simply bug 660556)
- The systemd bug came to attention after someone pointed out we shouldn't really be inconsistent and run systemctl daemon-reexec in the ebuild, given we don't do this for other stuff, and it's possibly "risky" (in that it's interfering with init).
- For now, we ended up deciding to solve the situation for both systemd & non-systemd by giving a warning explaining the situation.
I think a lot of people assumed it was common sense but I'm not sure everyone was really aware of the need to act on glibc upgrades.
I'm going to add bug references to the bugs I've just mentioned to the warning so that it's easier to understand why. And I'll also make sure that policy comment I made is definitely on a TODO list. |
|
| Back to top |
|
|
sam_
Developer
Joined: 14 Aug 2020
Posts: 2063
|
| Posted: Sun Mar 27, 2022 11:26 pm Post subject: |
|
|
| Done. |
|
| Back to top |
|
|
Goverp
Advocate
Joined: 07 Mar 2007
Posts: 2191
|
| Posted: Mon Nov 21, 2022 9:14 am Post subject: |
|
|
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.)
_________________
Greybeard |
|
| Back to top |
|
|
Genone
Retired Dev
Joined: 14 Mar 2003
Posts: 9618
Location: beyond the rim
|
| Posted: Mon Nov 21, 2022 3:33 pm Post subject: |
|
|
| 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.) |
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 ... |
|
| Back to top |
|
|
figueroa
Advocate
Joined: 14 Aug 2005
Posts: 3007
Location: Edge of marsh USA
|
| Posted: Mon Nov 21, 2022 5:00 pm Post subject: |
|
|
The current elog from last week's glibc stable update reads:
| Code: |
$ 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)
|
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.
| Code: |
$ 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. |
_________________
Andy Figueroa
hp pavilion hpe h8-1260t/2AB5; spinning rust x3
i7-2600 @ 3.40GHz; 16 gb; Radeon HD 7570
amd64/23.0/split-usr/desktop (stable), OpenRC, -systemd -pulseaudio -uefi |
|
| Back to top |
|
|
Christian99
Veteran
Joined: 28 May 2009
Posts: 1715
|
| Posted: Mon Nov 21, 2022 5:17 pm Post subject: |
|
|
| I find app-admin/needrestart quite helpful. it works with systemd services, don't know if it supports init scripts, though. |
|
| Back to top |
|
|
GDH-gentoo
Veteran
Joined: 20 Jul 2019
Posts: 1778
Location: South America
|
| Posted: Mon Nov 21, 2022 5:58 pm Post subject: |
|
|
Here's what the FAQ in the official website says about this.
_________________
| NeddySeagoon wrote: | I'm not a witch, I'm a retired electronics engineer  |
| Ionen wrote: | | As a packager I just don't want things to get messier with weird build systems and multiple toolchains requirements though |
|
|
| Back to top |
|
|
pjp
Administrator
Joined: 16 Apr 2002
Posts: 20552
|
| Posted: Tue Nov 22, 2022 3:37 am Post subject: |
|
|
| figueroa wrote: | | Pam, on the other hand, spells it out for the user, and I find it easy to do the "lsof / grep ..." routine |
I thought of this as well. I had intended to delay the upgrade, but apparently forgot about the warning.
I don't know if it is complete, but referencing the pam method, this suggests some obvious stuff and a few things I didn't think about: | with root privilege": | | lsof /|grep -E -i 'del.*libc*\.so' |awk '{ print $1 }' |sort -u |
A partial ilst: | Quote: | agetty
bash
crond
dhcpcd
init
lvmetad
ntpd
sshd
syslogd
systemd-u
tmux
vi |
So basically most anything that runs a daemon and anything you've left running for a while (tmux, vi, terminals, etc.).
I'll have to try to get into the habit of delaying finicky package upgrades until I feel like rebooting.
_________________
Quis separabit? Quo animo? |
|
| Back to top |
|
|
Genone
Retired Dev
Joined: 14 Mar 2003
Posts: 9618
Location: beyond the rim
|
| Posted: Tue Nov 22, 2022 9:48 am Post subject: |
|
|
| 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. |
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). |
|
| Back to top |
|
|
Goverp
Advocate
Joined: 07 Mar 2007
Posts: 2191
|
| Posted: Tue Nov 22, 2022 10:44 am Post subject: |
|
|
| Genone wrote: | | 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 ... |
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 ... |
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!
_________________
Greybeard |
|
| Back to top |
|
|
Genone
Retired Dev
Joined: 14 Mar 2003
Posts: 9618
Location: beyond the rim
|
| Posted: Tue Nov 22, 2022 12:22 pm Post subject: |
|
|
| 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! |
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. |
|
| Back to top |
|
|
|
Portage & Programming
