CentOS - Jun 2005 - Re: Reboots -- lsof and SIGHUP, a combination to know ...

From: Simon Perreault <nomis80 at lqt.ca>
> Sure, theoretically it would be possible, but how would you restart this
one?
> [nomis80 at poste10-153 ~]$ sudo lsof | grep libc | grep init
> init          1    root  mem       REG      253,0  1521500     999437
/lib/tls/libc-2.3.5.so
I need to verify the post-install script for the glibc RPM, but
I believe it SIGHUPs the process -- and SIGHUP tells GLibC to
reload itself for all new calls from any new process, while
leaving the old code available for running processes.

Building a tree of service calls and dependencies is the way to
figure out what is using what -- even if indirectly.  lsof does a
fantastic job of this with the right option combinations (I need
to look at my command history).

Remember, UNIX experience is everything, and that means if I don't
know, I get out a test system and throw something like a SIGHUP at
it and see what happens.  ;->

The lack of using UNIX-like signals in NT is what really makes me dislike
NT.  Sure, there are lots of UNIX libraries/services that don't always
handle every signal -- and many just use SIGHUP as a hard restart.  But
many of the critical ones do.  The majority of even Microsoft's own core
libraries are completely ignorant of NT, as they were written for
"Chicago."

Get to know your UNIX/Linux platform.  It's the best way to document
procedures that you may need to have in a situation.  One I regularly
document is how SIGHUP affects different libraries/services.


--
Bryan J. Smith   mailto:b.j.smith at ieee.org

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, Jun 02, 2005 at 12:50:21PM -0500, Bryan J. Smith <b.j.smith at
ieee.org> wrote:
> From: Simon Perreault <nomis80 at lqt.ca>
> > Sure, theoretically it would be possible, but how would you restart
this one?
> > [nomis80 at poste10-153 ~]$ sudo lsof | grep libc | grep init
> > init          1    root  mem       REG      253,0  1521500     999437
/lib/tls/libc-2.3.5.so
> 
> I need to verify the post-install script for the glibc RPM, but
> I believe it SIGHUPs the process -- and SIGHUP tells GLibC to
> reload itself for all new calls from any new process, while
> leaving the old code available for running processes.
Hummm, it should not work. SIGHUP, I mean. Not sure if it does, tho.

[]s

- -- 
Rodrigo Barbosa <rodrigob at suespammers.org>
"Quid quid Latine dictum sit, altum viditur"
"Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)

iD8DBQFCn0g/pdyWzQ5b5ckRAvKbAJ0cX6k+QDElJsnaohmBa4yi0HzvqwCgg5l8
s25TZfGY4MrhHY7aOkb0adc=wARd
-----END PGP SIGNATURE-----

Bryan J. Smith <b.j.smith at ieee.org> wrote:
> From: Simon Perreault <nomis80 at lqt.ca>
> > Sure, theoretically it would be possible, but how would you restart
this one?
> > [nomis80 at poste10-153 ~]$ sudo lsof | grep libc | grep init
> > init          1    root  mem       REG      253,0  1521500     999437
/lib/tls/libc-2.3.5.so
> 
> I need to verify the post-install script for the glibc RPM, but
> I believe it SIGHUPs the process -- and SIGHUP tells GLibC to
> reload itself for all new calls from any new process, while
> leaving the old code available for running processes.
If you can read binary :)

The script section of the glibc RPM is a very simple one:

[angenenr at shutdown dict]$rpm -q --scripts glibc
postinstall program: /usr/sbin/glibc_post_upgrade.i686
postuninstall program: /sbin/ldconfig

And I cannot find Documentation for glibc_post_upgrade at the moment, a
"strings" on that binary doesn't really help either.

Ralph
-- 
Ralph Angenendt......ra at br-online.de | .."Text processing has made it
possible
Bayerischer Rundfunk...HA-Multimedia | ....to right-justify any idea, even one
Rundfunkplatz 1........80300 M?nchen | .which cannot be justified on any other
Tl:089.5900.16023..Fx:089.5900.16240 | ..........grounds." -- J. Finnegan,
USC
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL:
<http://lists.centos.org/pipermail/centos/attachments/20050603/128864e9/attachment-0004.sig>