Re: 20000915: ROUTE PostProcessing setup at Oregon State (cont.)

Wayne,

This seems strange to me since "ldmadmin start" makes the same new_log call
as if "ldmadmin newlog" were called directly.  One way or the other, the
syslog process should get the HUP.  Tom thought you might be using a
Solaris system -- there are patches to syslog for several recent versions
to correct some nasty problems.  Can you tell me what version of Solaris
you're using (uname -a)?

mike

Subject: 20000915: ROUTE PostProcessing setup at Oregon State (cont.)
>From: Wayne Gibson <address@hidden>
>Organization: Oregon State University
>Keywords: 200009142249.e8EMnCb02002 LDM ldm-mcidas batch.k
>
> Wayne,
>
> re: stopping and restarting the LDM to rotate log files
>
> >I hope I remembering this correctly as it's been a while since I set this
up.
> >
> >The reason we stop and start ldm for log file rotation is due to the way our
> >college administrator has configured the syslogd system.  As a resuly, a
> >call to "newlog" and subsequent call to "hupsyslog" did not make a proper
> >connection to the new log file.  To get logging to work properly, I was
> >forced to stop ldm and restart.
> >
> >Does that make sense to you?
>
> I am unfamiliar with the concept that one can setup syslogd to ignore
> HUP signals, but that doesn't mean that it isn't true.  The typical
> LDM setup is for hupsyslogd (and rpc.ldmd) to have setuid root privilege
> (will run as root).  An invocation of hupsyslogd then sends a HUP to
> syslogd as root, and a HUP signal tells the LDM to reread its configuration
> file, /etc/syslog.conf.
>
> I will ask our system administrator if one can setup syslogd so that
> a HUP won't work to see if perhaps you are doing a lot more work than
> you need to.
>
> Tom