This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
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