I may be out of my league here, but we had a similar problem. This is what
we discovered with an explanation from our IT gurus:
In Debian there is a system wide cron that rotates all log files that are
controlled by syslog and also meet certain criteria (file size, modify time,
etc.). Under some circumstances these criteria will all be met, and when the
logs are rotated they get owned by root.
One simple workaround is to simply rotate your logs via the ldm's cron right
before the system cron runs. The system cron gets run at 6:24 everyday, so you
can just rotate around 6:15 and usually that will work.
Another solution is to use the 'skip' exception (-s option) to keep the system
log rotations from happening.
DETAILS:
The simple description of what's going on is that the Debian package sysklogd,
which includes the syslog daemon, also includes some support utilities. One of
these utilities, syslogd-listfiles, is used to "ease" log rotation chores by
generating lists of logfiles syslogd writes to. It parses syslog.conf, applies
various tests to the logfiles found therein, and generates a list of logfiles
"needing" rotation. Because ldmd logs via syslog and so has its logfile listed
in syslog.conf, the ldmd log file will sometimes be included in lists generated
by syslogd-listfiles.
syslogd-listfiles is used in this way in a couple of the default system cron
files, /etc/cron.daily/sysklogd and /etc/cron.weekly/sysklogd. The utility
supports a "skip" option, -s. If you edit the two files above and add "-s
ldmd.log" in the appropriate places, ldmd.log will not be included in
automatically generated logfile lists. Here's an example, of the one line
change, with a comment to explain what's being done:
# Skip rotation of LDM log: /home/ldm/logs/ldmd.log
for LOG in `syslogd-listfiles -s ldmd.log`
You don't need to edit any syslogd-listfiles lines using the --auth flag, as
they won't include ldmd.log anyway; so there's one line to be changed in each
file.
-Paul
----- Forwarded message from Matt Foster <Matthew.Foster@xxxxxxxx> -----
X-SMTP-Auth: no
From: Matt Foster <Matthew.Foster@xxxxxxxx>
To: ldm-users@xxxxxxxxxxxxxxxx
Subject: Re: [ldm-users] 20090109: root owns ldmd.log
X-BeenThere: ldm-users@xxxxxxxxxxxxxxxx
X-Mailman-Version: 2.1.9
List-Id: A list for users of the LDM and Unidata's IDD system
<ldm-users.unidata.ucar.edu>
List-Unsubscribe: <http://mailman.unidata.ucar.edu/mailman/listinfo/ldm-users>,
<mailto:ldm-users-request@xxxxxxxxxxxxxxxx?subject=unsubscribe>
List-Archive: <http://mailman.unidata.ucar.edu/mailing_lists/archives/ldm-users>
List-Post: <mailto:ldm-users@xxxxxxxxxxxxxxxx>
List-Help: <mailto:ldm-users-request@xxxxxxxxxxxxxxxx?subject=help>
List-Subscribe: <http://mailman.unidata.ucar.edu/mailman/listinfo/ldm-users>,
<mailto:ldm-users-request@xxxxxxxxxxxxxxxx?subject=subscribe>
X-Virus-Scanned: amavisd-new at ucar.edu
Thanks for the replies. The problem has been corrected, but I'm not
sure why. I had been ssh'ing into the LDM box as root, and then su'ing
to ldm, as I have frequently done on other machines. I ssh'd into the
box in question as ldm (w/o going through root), started LDM, and the
log file was then owned by ldm. Maybe I had previously forgotten to su
to ldm before starting the LDM. I don't think that's the case, but it's
possible.
Matt
--
Do not go where the path may lead; go instead where there is no path and
leave a trail.
-- Ralph Waldo Emerson
begin:vcard
fn:Matt Foster - N0EYE
n:Foster;Matt
org:;NWS Forecast Office - Norman OK
email;internet:matthew.foster@xxxxxxxx
title:Information Technology Officer
tel;work:(405) 325-3406
x-mozilla-html:TRUE
version:2.1
end:vcard
_______________________________________________
ldm-users mailing list
ldm-users@xxxxxxxxxxxxxxxx
For list information or to unsubscribe, visit:
http://www.unidata.ucar.edu/mailing_lists/
----- End forwarded message -----