Should I reboot after updating glibc 2.4.xx ---> 2.5 ?

[Jjeje007]

Hi,

I just run emerge --sync and emerge -uvaDN world from my web server and I got an update for glibc (2.4.xx --> 2.5)
So, should I reboot after ??

I'm on stable (mean x86)

Jjeje007

[Jjeje007]

So,

Please give me an answer ??

[nxsty]

Yes, everything uses glibc. It probably wont crash or anything if you don't reboot but the old libraries will still be loaded.

[zomps]

I don't think so, you can restart most of the services (apache, postfix etc)
what are using glibc and they will pick up new glibc libraries.
Only thing what you cannot restart is init and I dont think it uses
glibc at all.

[zomps]

One more thing you can verify what services are using old libraries
with lsof | grep "ld-2.4"

[Jjeje007]

Hi,

here is the result of the command lsof | grep "ld-2.4", after restarting every thing i could :

lsof | grep "ld-2.4"
agetty 4803 root DEL REG 8,3 341156 /var/tmp/portage/glibc-2.4-r3/image/lib/ld-2.4.so
agetty 4804 root DEL REG 8,3 341156 /var/tmp/portage/glibc-2.4-r3/image/lib/ld-2.4.so
agetty 4805 root DEL REG 8,3 341156 /var/tmp/portage/glibc-2.4-r3/image/lib/ld-2.4.so
agetty 4806 root DEL REG 8,3 341156 /var/tmp/portage/glibc-2.4-r3/image/lib/ld-2.4.so
agetty 4807 root DEL REG 8,3 341156 /var/tmp/portage/glibc-2.4-r3/image/lib/ld-2.4.so
agetty 4808 root DEL REG 8,3 341156 /var/tmp/portage/glibc-2.4-r3/image/lib/ld-2.4.so
sh 4901 root DEL REG 8,3 341156 /var/tmp/portage/glibc-2.4-r3/image/lib/ld-2.4.so
udevd 5428 root DEL REG 8,3 868920 /lib/ld-2.4.so
miniserv. 16627 root DEL REG 8,3 868920 /lib/ld-2.4.so

So ??

Jjeje007

[zomps]

i don't think the agetty is critical service, when you login/logout console it will respawn
(I think same happens when you just use regular kill command ont that process)
you can kill also udev and start it again udevd --daemon
dunno whats the miniserv, (webmin?)

[Kasumi_Ninja]

Is rebooting the only thing we need to do when upgrading glibc? Or is there some hidden emerge -e world requirement like with gcc? Thanks in advance!

[Jjeje007]

dunno whats the miniserv, (webmin?)

Yes, You was right, it was webmin

Thanks

EDIT : I kill everything else and it's ok !

Jjeje007

[Arfrever]

Only thing what you cannot restart is init

You can restart init:

Code: Select all

init U

// Or:

init u

I dont think it uses glibc at all.

I think that init uses GLibC. init is even reloaded automatically in function toolchain-glibc_pkg_postinst:

Code: Select all

$ grep -B2 "init U" /usr/portage/sys-libs/glibc/glibc-2.5.ebuild
        if ! is_crosscompile && [[ ${ROOT} == "/" ]] ; then
                # Reload init ...
                /sbin/telinit U &> /dev/null

Sveikinu
Arfrever

[phajdan.jr]

Is rebooting the only thing we need to do when upgrading glibc? Or is there some hidden emerge -e world requirement like with gcc? Thanks in advance!

No, no, no. Programs are dynamically linked with glibc, so there is no difference. There could be if some binaries were compiled statically, but it's a rare case and it still doesn't need recompiling.

BTW, more correct way to reload init is to telinit U (as you see eclass uses this instead of just init).

[Arfrever]

Is rebooting the only thing we need to do when upgrading glibc? Or is there some hidden emerge -e world requirement like with gcc? Thanks in advance!

No, no, no. Programs are dynamically linked with glibc, so there is no difference. There could be if some binaries were compiled statically, but it's a rare case

Code: Select all

# cat /usr/lib/libc.so
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED ( /lib/ld-linux.so.2 ) )
# mkdir ~/libc_nonshared
# cd ~/libc_nonshared
# cp /usr/lib/libc_nonshared.a .
`/usr/lib/libc_nonshared.a' -> `./libc_nonshared.a'
# ar x libc_nonshared.a
# rm -f libc_nonshared.a &>/dev/null
# ls
atexit.oS  elf-init.oS  fstat64.oS  fstatat64.oS  fstatat.oS  fstat.oS  lstat64.oS  lstat.oS  mknodat.oS  mknod.oS  stack_chk_fail_local.oS  stat64.oS  stat.oS  warning-nop.oS
# mv /usr/lib/libc_nonshared.a /usr/lib/libc_nonshared.a-
`/usr/lib/libc_nonshared.a' -> `/usr/lib/libc_nonshared.a-'
# echo "int main () { return 0; }" > program.c
# gcc -march=athlon64 -O2 -pipe -o program program.c
/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/bin/ld: cannot find /usr/lib/libc_nonshared.a
collect2: ld returned 1 exit status
# mv /usr/lib/libc.so /usr/lib/libc.so-
`/usr/lib/libc.so' -> `/usr/lib/libc.so-'
# cp /usr/lib/libc.so- /usr/lib/libc.so
`/usr/lib/libc.so-' -> `/usr/lib/libc.so'
# vi /usr/lib/libc.so
# cat /usr/lib/libc.so
/* GNU ld script
   Use the shared library, but some functions are only in
   the static library, so try that secondarily.  */
OUTPUT_FORMAT(elf32-i386)
GROUP ( /lib/libc.so.6 AS_NEEDED ( /lib/ld-linux.so.2 ) )
# diff -u /usr/lib/libc.so- /usr/lib/libc.so
--- /usr/lib/libc.so-   2007-02-08 19:00:52.000000000 +0100
+++ /usr/lib/libc.so    2007-02-10 15:12:51.000000000 +0100
@@ -2,4 +2,4 @@
    Use the shared library, but some functions are only in
    the static library, so try that secondarily.  */
 OUTPUT_FORMAT(elf32-i386)
-GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED ( /lib/ld-linux.so.2 ) )
+GROUP ( /lib/libc.so.6 AS_NEEDED ( /lib/ld-linux.so.2 ) )
# gcc -march=athlon64 -O2 -pipe -o program program.c
/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../crt1.o: In function `_start':
(.text+0xc): undefined reference to `__libc_csu_fini'
/usr/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../crt1.o: In function `_start':
(.text+0x11): undefined reference to `__libc_csu_init'
collect2: ld returned 1 exit status
# 

// Repairing system:
# mv /usr/lib/libc.so- /usr/lib/libc.so
`/usr/lib/libc.so-' -> `/usr/lib/libc.so'
# mv /usr/lib/libc_nonshared.a- /usr/lib/libc_nonshared.a
`/usr/lib/libc_nonshared.a-' -> `/usr/lib/libc_nonshared.a'
# gcc -march=athlon64 -O2 -pipe -o program program.c ; echo $?
0
#

So rather all binaries are partially statically linked with GLibC. But probably "__libc_csu_fini", "__libc_csu_init" and similar functions don't change too much between GLibC releases, so you don't have to run `emerge -e world`.

BTW, more correct way to reload init is to telinit U (as you see eclass uses this instead of just init).

What's the difference?

Code: Select all

# ls -aFhn `which telinit`
lrwxrwxrwx 1 0 0 4 gru 30 04:07 /sbin/telinit -> init*

Sveikinu
Arfrever

[phajdan.jr]

So rather all binaries are partially statically linked with GLibC. But probably "__libc_csu_fini", "__libc_csu_init" and similar functions don't change too much between GLibC releases, so you don't have to run `emerge -e world`.

OK, maybe it's not so simple. But to correctly answer this question one would have to know how glibc works internally (I don't know that). But you're probably right about these changes between releases etc. I don't run emerge -e world and don't reboot after glibc updates. My system is running fine, so this method is probably fine.

BTW, more correct way to reload init is to telinit U (as you see eclass uses this instead of just init).

What's the difference?

Code: Select all

# ls -aFhn `which telinit`
lrwxrwxrwx 1 0 0 4 gru 30 04:07 /sbin/telinit -> init*

I know it's a symlink. But programs may have different behavior when called using different names. Remember that name of program is passed as argv[0].