Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 642784 - sys-libs/glibc calls telinit from pkg_postinst
Summary: sys-libs/glibc calls telinit from pkg_postinst
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
Depends on: 642858
Blocks:
  Show dependency tree
 
Reported: 2017-12-31 00:48 UTC by Mike Gilbert
Modified: 2019-08-21 22:37 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Gilbert gentoo-dev 2017-12-31 00:48:03 UTC
The glibc package calls "telinit U" from pkg_postinst to tell init to re-exec itself.

This seems very strange to me. We certainly don't restart any other daemons that may be using libc. What makes init so special?

I propose that we remove this call.
Comment 2 Anthony Basile gentoo-dev 2017-12-31 10:46:45 UTC
(In reply to Mike Gilbert from comment #0)

> This seems very strange to me. We certainly don't restart any other daemons
> that may be using libc. What makes init so special?
> 
> I propose that we remove this call.


I wouldn't say its *very* strange.  Running `lsof / | grep DEL` after an upgrade to glibc shows that practically every process running is still linked against the older version which not only stays resident in memory but even of the drive until no consumers are left.

Having said that, I'm okay with removing the line.  Also I hate messages in ebuilds, but if possible a reboot should be recommended (or an individual restart of any daemons still linked against the older versions).

Final point, Debian actually automatically restarts processes after installing the .deb.  I don't like this at all, but maybe I could write a bash script which just list processes that are still linked to the older version and prompt the user to restart them if they choose.
Comment 3 Anthony Basile gentoo-dev 2017-12-31 10:49:07 UTC
(In reply to Alexander Tsoy from comment #1)
> https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/LjkLwkeDiLc

Just read this after my post.  I didn't realize about the possibility of the file system corruption too.
Comment 4 Sergei Trofimovich gentoo-dev 2017-12-31 11:04:04 UTC
> This seems very strange to me. We certainly don't restart any other daemons that may be using libc. What makes init so special?

Two points here:

- I think we don't restart all daemon only because gentoo has no robust facility to do it. Debian does restart daemons after libc upgrade.
- /sbin/init is special because it is a last long-running binary that can refer to already deleted libc.so.6 upon shutdown.

The code was added (as 'init U') in 2003:
    https://github.com/gentoo/gentoo-gitmig-20150809-draft/commit/b541c482b6c7f5989101166fda3f8a4cbbf61b7e
with a changelog entry "Reload init to fix fsck on reboot ..."

and updated to 'telinit U':
    https://bugs.gentoo.org/145717

I suspect its due to the same reason as in https://bugzilla.redhat.com/show_bug.cgi?id=444978#c5, namely:

"""
The reason why glibc %post does telinit u is to avoid unclean shutdown - if the
old init is still running, it will still reference already unlinked libc.so.6,
ld.so etc. and won't umount cleanly.
"""

It is good-enough for openrc as libc is the only library used by /sbin/init.

Does it make sense?

I can update comment in glibc/toolchain to be more explicit about the intent.
Comment 5 Mike Gilbert gentoo-dev 2017-12-31 14:08:51 UTC
Thanks for the feedback.

Lennart's blog mentions that Red Hat actually executed telinit U during system shutdown, which sounds like exactly the right time to do it if you are trying to avoid the open file problem.

Maybe we should add something to OpenRC's shutdown runlevel.
Comment 6 Anthony Basile gentoo-dev 2017-12-31 15:43:38 UTC
(In reply to Mike Gilbert from comment #5)
> Thanks for the feedback.
> 
> Lennart's blog mentions that Red Hat actually executed telinit U during
> system shutdown, which sounds like exactly the right time to do it if you
> are trying to avoid the open file problem.
> 
> Maybe we should add something to OpenRC's shutdown runlevel.

That's actually a good idea.  Remove it from the ebuild and add it to openrc.
Comment 7 Jeroen Roovers gentoo-dev 2017-12-31 17:30:39 UTC
(In reply to Anthony Basile from comment #6)

> Remove it from the ebuild and add it to openrc.

Or, leave it in the ebuild for a good while (in integer years?) but only execute when we know OpenRC will not.
Comment 8 Mike Gilbert gentoo-dev 2017-12-31 17:54:36 UTC
I would say we should probably leave it for one year after a stable version of OpenRC includes the necessary replacement.

That would match up nicely with the council decision mandating a one year upgrade path for stable systems.
Comment 9 Sergei Trofimovich gentoo-dev 2017-12-31 19:54:40 UTC
I guess it's obvious but will state it explicitly anyways.
glibc is not the only to trigger init re-exec when we are to remove it:

sys-libs/glibc/glibc-9999.ebuild:               /sbin/telinit U 2>/dev/null
sys-libs/musl/musl-9999.ebuild: /sbin/telinit U 2>/dev/null
sys-libs/uclibc-ng/uclibc-ng-9999.ebuild:       /sbin/telinit U 2>/dev/null
sys-libs/uclibc/uclibc-9999.ebuild:     /sbin/telinit U 2>/dev/null
Comment 10 Andreas K. Hüttel gentoo-dev 2018-01-01 17:23:53 UTC
William, what do you think?
Comment 11 Andreas K. Hüttel gentoo-dev 2018-05-25 18:15:33 UTC
(In reply to Andreas K. Hüttel from comment #10)
> William, what do you think?

ping?
Comment 12 Andreas K. Hüttel gentoo-dev 2018-09-11 15:22:28 UTC
(In reply to Andreas K. Hüttel from comment #11)
> (In reply to Andreas K. Hüttel from comment #10)
> > William, what do you think?
> 
> ping?

ping, William, what do you think?
Comment 13 Andreas K. Hüttel gentoo-dev 2018-10-26 19:55:00 UTC
(In reply to Andreas K. Hüttel from comment #10)
> William, what do you think?

ping?
Comment 14 Mike Gilbert gentoo-dev 2018-10-31 14:16:50 UTC
Per bug 642858, we added a re-exec command to inittab in sysvinit-2.91-r1. Once that goes stable, we can start the countdown to remove it from pkg_postinst in the libc packages.
Comment 15 William Hubbs gentoo-dev 2018-11-07 15:07:57 UTC
Sorry about the lack of response on this bug.

As Mike said, we added the telinit call to inittab in
sysvinit-2.91-r1.
Comment 16 Andreas K. Hüttel gentoo-dev 2018-12-30 09:27:08 UTC
(In reply to William Hubbs from comment #15)
> Sorry about the lack of response on this bug.
> 
> As Mike said, we added the telinit call to inittab in
> sysvinit-2.91-r1.

OK let's target that for glibc-2.30. 

(2.29 is too close, and stabilization of sysvinit-2.91-r1 is not finished yet.)
Comment 17 Larry the Git Cow gentoo-dev 2019-08-21 22:35:27 UTC
The bug has been referenced in the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=00b7def5a8a7581858059ef4710d26542f3eee47

commit 00b7def5a8a7581858059ef4710d26542f3eee47
Author:     Sergei Trofimovich <slyfox@gentoo.org>
AuthorDate: 2019-08-21 22:34:28 +0000
Commit:     Sergei Trofimovich <slyfox@gentoo.org>
CommitDate: 2019-08-21 22:35:21 +0000

    sys-libs/glibc: drop telinit call from pkg_*(), bug #642784
    
    Rely on sysvinit re-execution on shutdown (bug #642858)
    instead of relying on glibc's pkg_*() phases.
    
    Reported-by: Mike Gilbert
    Bug: https://bugs.gentoo.org/642784
    Package-Manager: Portage-2.3.72, Repoman-2.3.17
    Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>

 sys-libs/glibc/glibc-2.30.ebuild | 4 ----
 sys-libs/glibc/glibc-9999.ebuild | 4 ----
 2 files changed, 8 deletions(-)
Comment 18 Sergei Trofimovich gentoo-dev 2019-08-21 22:37:36 UTC
musl and uclibc-ng ebuilds will need an update as well:

sys-libs/musl/musl-1.1.20-r1.ebuild:    /sbin/telinit U 2>/dev/null
sys-libs/musl/musl-1.1.21.ebuild:       /sbin/telinit U 2>/dev/null
sys-libs/musl/musl-1.1.22.ebuild:       /sbin/telinit U 2>/dev/null
sys-libs/musl/musl-1.1.23.ebuild:       /sbin/telinit U 2>/dev/null
sys-libs/musl/musl-9999.ebuild: /sbin/telinit U 2>/dev/null
sys-libs/uclibc-ng/uclibc-ng-1.0.26.ebuild:     /sbin/telinit U 2>/dev/null
sys-libs/uclibc-ng/uclibc-ng-1.0.30-r1.ebuild:  /sbin/telinit U 2>/dev/null
sys-libs/uclibc-ng/uclibc-ng-1.0.31.ebuild:     /sbin/telinit U 2>/dev/null
sys-libs/uclibc-ng/uclibc-ng-9999.ebuild:       /sbin/telinit U 2>/dev/null