Respawning syslogd - HP UX

This is a discussion on Respawning syslogd - HP UX ; Does anybody know why the default HP-UX install starts up the syslogd using the /sbin/init.d/syslogd script rather than as a respawning process from the /etc/inittab file? It would seem like this is the one process you want to have stay ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Respawning syslogd

  1. Respawning syslogd

    Does anybody know why the default HP-UX install starts up the syslogd
    using the /sbin/init.d/syslogd script rather than as a respawning
    process from the /etc/inittab file? It would seem like this is the one
    process you want to have stay up when your system is getting whacked
    with a problem.

    Thanks.

    --
    Bob


  2. Re: Respawning syslogd

    anchor0057@yahoo.com wrote:
    > Does anybody know why the default HP-UX install starts up the syslogd
    > using the /sbin/init.d/syslogd script rather than as a respawning
    > process from the /etc/inittab file? It would seem like this is the one
    > process you want to have stay up when your system is getting whacked
    > with a problem.


    The respawn thingy in inittab is a feature which pre-dates the System
    V Release 4 startup scripts. It was/is only used for spawning getty's,
    etc.. Respawning things (like syslogd) which shouldn't terminate, is a
    hack, not a fix.

  3. Re: Respawning syslogd

    I see. But, unfortunately, if it ever does fail it will probably do so
    right at the moment when I most need to see the log messages. I'd be
    happier if there were some other process making sure it was respawned.
    (Similar to the way cimserverd will respawn cimserver.

    --
    Bob


  4. Re: Respawning syslogd

    In article <1138981374.415160.284680@g47g2000cwa.googlegroups. com>,
    anchor0057@yahoo.com wrote:
    > I see. But, unfortunately, if it ever does fail it will probably do so
    > right at the moment when I most need to see the log messages. I'd be
    > happier if there were some other process making sure it was respawned.
    > (Similar to the way cimserverd will respawn cimserver.


    But what happens if cimserverd dies? Also, why would expect syslogd to die when
    you have a problem? If that were the case, why would you expect it to start
    normally when re-spawned?

    Kevin

    --
    Unix Guy Consulting, LLC
    Unix and Linux Automation, Shell, Perl and CGI scripting
    http://www.unix-guy.com

  5. Re: Respawning syslogd

    > But what happens if cimserverd dies?

    Then I'd expect that cimserver wouldn't be respawned if it died. But
    that would take two unlikely events to occur, rather than one.
    Hopefully the event will get logged and eventually noticed by the
    SysAdmin, who could restart cimserved. Meanwhile cimserver would
    probably stay up...

    > Also, why would expect syslogd to die when you have a problem?


    Past experience and karma. Processes sometimes die hard; make due to a
    bug, or whatever, and usually right when you least need it. *shrug*
    Just a tendency toward caution, I guess.

    > If that were the case, why would you expect it to start normally when re-spawned?


    Why wouldn't I? Whatever killed the daemon could be a solitary event.

    --
    Bob


  6. Re: Respawning syslogd

    > Also, why would expect syslogd to die when you have a problem?

    Or, in another instance, the syslogd could go down on a system and
    nobody would notice for a while. Then, when a real problem hits,
    nothing gets logged.

    --
    Bob


  7. Re: Respawning syslogd

    In article <1139001700.475628.263710@g14g2000cwa.googlegroups. com>,
    anchor0057@yahoo.com wrote:
    >> Also, why would expect syslogd to die when you have a problem?

    >
    > Or, in another instance, the syslogd could go down on a system and
    > nobody would notice for a while. Then, when a real problem hits,
    > nothing gets logged.


    Then get a monitoring tool like ITO, Tivoli, Nagios, etc and monitor your
    systems for that. That's what most people do...

    Kevin
    --
    Unix Guy Consulting, LLC
    Unix and Linux Automation, Shell, Perl and CGI scripting
    http://www.unix-guy.com

+ Reply to Thread