I have logrotate-3.7-5 installed and it gives errors when run

Example:

-bash-3.00# logrotate -f /etc/logrotate.conf
error: error running postrotate script

Here is logrotate.conf

# Begin /etc/logrotate.conf

create

/var/log/lastlog /var/log/wtmp
{
monthly
create 0644 root root
rotate 1
}

/var/log/servicelog
{
weekly
rotate 6
missingok
postrotate
/bin/killall -s HUP ntpd
endscript
}

# End /etc/logrotate.conf

Has anyone seen this?
If so how to fix?

If I run from the command line /bin/killall -s HUP ntpd gives no errors

Thanks

--
Dancin' in the ruins tonight
mail: echo onub-hgbg@pbyhzohf.ee.pbz | perl -pe 'y/a-z/n-za-m/'
Tayo'y Mga Pinoy

Baho Utot <onub-hgbg@pbyhzohf.ee.pbz> wrote:
> If I run from the command line /bin/killall -s HUP ntpd gives no errors

What makes you think so?

Peter

On Fri, 02 Dec 2005 02:11:06 +0100, Peter T. Breuer shouted Hoy......

>
>
> Baho Utot <onub-hgbg@pbyhzohf.ee.pbz> wrote:
>> If I run from the command line /bin/killall -s HUP ntpd gives no errors
>
> What makes you think so?
>
> Peter

I doesn't complain and the servicelog then start to use the "new" file and
not continue using the servicelog.1 file.

--
Dancin' in the ruins tonight
mail: echo onub-hgbg@pbyhzohf.ee.pbz | perl -pe 'y/a-z/n-za-m/'
Tayo'y Mga Pinoy

Baho Utot <onub-hgbg@pbyhzohf.ee.pbz> wrote:
> On Fri, 02 Dec 2005 02:11:06 +0100, Peter T. Breuer shouted Hoy......
>> Baho Utot <onub-hgbg@pbyhzohf.ee.pbz> wrote:
>>> If I run from the command line /bin/killall -s HUP ntpd gives no errors
>>
>> What makes you think so?

> I doesn't complain

But "not complaining" is not the same thing as "giving no errors".

Check the condition that logrotate tells you about, not whether it
complians or not!

> and the servicelog then start to use the "new" file and
> not continue using the servicelog.1 file.

Peter

On Fri, 02 Dec 2005 11:17:26 +0100, Peter T. Breuer <ptb@oboe.it.uc3m.es> wrote:

> Baho Utot <onub-hgbg@pbyhzohf.ee.pbz> wrote:
>> On Fri, 02 Dec 2005 02:11:06 +0100, Peter T. Breuer shouted Hoy......
>>> Baho Utot <onub-hgbg@pbyhzohf.ee.pbz> wrote:
>>>> If I run from the command line /bin/killall -s HUP ntpd gives no errors
>>>
>>> What makes you think so?
>
>> I doesn't complain
>
> But "not complaining" is not the same thing as "giving no errors".
>
> Check the condition that logrotate tells you about, not whether it
> complians or not!

I would guess logrotate depends on the exit status from the command.
You (Baho Utot) would come closer by doing "killall -s HUP ntpd; echo $?".

Another obvious thing to look for is to see if ntpd outputs something
when it receives the hangup signal. you would find it in the servicelog
files, I guess.


>> and the servicelog then start to use the "new" file and
>> not continue using the servicelog.1 file.

But who writes to the servicelog* files? Isn't that syslog? You are
observing the behaviour of the syslog daemon, aren't you? Or is your
ntpd set up to write directly to the files?

You say the "the servicelog starts..." but who exactly is that? (the
servicelog)

On my system, ntpd sends its output to the syslog daemon, and the syslog
daemon writes it to a file. If logrotate restarts the syslog daemon, it
is concievable that its clients have to reopen the connection with it.

(But I am not sure of that; I just tried "lsof" to see if there are clients
holding /dev/log open, but only syslogd does. The clients seem to reopen
that file for each message. In that case it should not really be necessary
to kill -HUP nptd. But again, if that's the case, there is even less reason
to draw inferences from "its using the new file" to "killall had no errors".)

There are no "servicelog" files on my system so obviously something is
different. My guess is that your syslog.conf is different. Read about
syslogd and syslog.conf; the "man" command is your friend.

-Enrique

On Fri, 02 Dec 2005 15:58:35 +0100, Enrique Perez-Terron shouted Hoy......


>
> On Fri, 02 Dec 2005 11:17:26 +0100, Peter T. Breuer
> <ptb@oboe.it.uc3m.es> wrote:
>
>> Baho Utot <onub-hgbg@pbyhzohf.ee.pbz> wrote:
>>> On Fri, 02 Dec 2005 02:11:06 +0100, Peter T. Breuer shouted Hoy......
>>>> Baho Utot <onub-hgbg@pbyhzohf.ee.pbz> wrote:
>>>>> If I run from the command line /bin/killall -s HUP ntpd gives no
>>>>> errors
>>>>
>>>> What makes you think so?
>>
>>> I doesn't complain
>>
>> But "not complaining" is not the same thing as "giving no errors".
>>
>> Check the condition that logrotate tells you about, not whether it
>> complians or not!
>
> I would guess logrotate depends on the exit status from the command. You
> (Baho Utot) would come closer by doing "killall -s HUP ntpd; echo $?".

killall -s HUP ntpd; echo $? from the cmd line gives 0 from running
logrotate
-bash-3.00# logrotate -f logrotate.conf error: error running postrotate
script

-bash-3.00# logrotate -f -d logrotate.conf reading config file
logrotate.conf
reading config info for /var/log/lastlog /var/log/wtmp

reading config info for /var/log/servicelog

Handling 2 logs

rotating pattern: /var/log/lastlog /var/log/wtmp
forced from command line (1 rotations)
empty log files are rotated, old logs are removed considering log
/var/log/lastlog
log needs rotating
considering log /var/log/wtmp
log needs rotating
rotating log /var/log/lastlog, log->rotateCount is 1 renaming
/var/log/lastlog.1 to /var/log/lastlog.2 (rotatecount 1, logstart 1, i 1),
renaming /var/log/lastlog.0 to /var/log/lastlog.1 (rotatecount 1, logstart
1, i 0), renaming /var/log/lastlog to /var/log/lastlog.1 creating new log
mode = 0644 uid = 0 gid = 0 removing old log /var/log/lastlog.2
rotating log /var/log/wtmp, log->rotateCount is 1 renaming /var/log/wtmp.1
to /var/log/wtmp.2 (rotatecount 1, logstart 1, i 1), renaming
/var/log/wtmp.0 to /var/log/wtmp.1 (rotatecount 1, logstart 1, i 0),
renaming /var/log/wtmp to /var/log/wtmp.1 creating new log mode = 0644 uid
= 0 gid = 0 removing old log /var/log/wtmp.2

rotating pattern: /var/log/servicelog
forced from command line (6 rotations)
empty log files are rotated, old logs are removed considering log
/var/log/servicelog
log needs rotating
rotating log /var/log/servicelog, log->rotateCount is 6 renaming
/var/log/servicelog.6 to /var/log/servicelog.7 (rotatecount 6, logstart 1,
i 6), renaming /var/log/servicelog.5 to /var/log/servicelog.6 (rotatecount
6, logstart 1, i 5), renaming /var/log/servicelog.4 to
/var/log/servicelog.5 (rotatecount 6, logstart 1, i 4), renaming
/var/log/servicelog.3 to /var/log/servicelog.4 (rotatecount 6, logstart 1,
i 3), renaming /var/log/servicelog.2 to /var/log/servicelog.3 (rotatecount
6, logstart 1, i 2), renaming /var/log/servicelog.1 to
/var/log/servicelog.2 (rotatecount 6, logstart 1, i 1), renaming
/var/log/servicelog.0 to /var/log/servicelog.1 (rotatecount 6, logstart 1,
i 0), renaming /var/log/servicelog to /var/log/servicelog.1 creating new
log mode = 0644 uid = 0 gid = 0 running postrotate script
running script with arg /var/log/servicelog: "
/bin/killall -s HUP ntpd; echo $?
"
removing old log /var/log/servicelog.7 -bash-3.00#
>
> Another obvious thing to look for is to see if ntpd outputs something
> when it receives the hangup signal. you would find it in the servicelog
> files, I guess.
>
>
No nothing in the system log nor servicelog. Looked at all the logs and
there isn't a single entry.
I think it's time to log the debug logs from syslogd


>>> and the servicelog then start to use the "new" file and not continue
>>> using the servicelog.1 file.
>
> But who writes to the servicelog* files? Isn't that syslog? You are
> observing the behaviour of the syslog daemon, aren't you? Or is your
> ntpd set up to write directly to the files?
>
> You say the "the servicelog starts..." but who exactly is that? (the
> servicelog)
>
>
ntpd writes to it directly, I have nothing in the syslog.conf file
referencing servicelog.


> On my system, ntpd sends its output to the syslog daemon, and the syslog
> daemon writes it to a file. If logrotate restarts the syslog daemon, it
> is concievable that its clients have to reopen the connection with it.
>
> (But I am not sure of that; I just tried "lsof" to see if there are
> clients holding /dev/log open, but only syslogd does. The clients seem
> to reopen that file for each message. In that case it should not really
> be necessary to kill -HUP nptd. But again, if that's the case, there is
> even less reason to draw inferences from "its using the new file" to
> "killall had no errors".)
>
> There are no "servicelog" files on my system so obviously something is
> different. My guess is that your syslog.conf is different. Read about
> syslogd and syslog.conf; the "man" command is your friend.
>
> -Enrique

What is different is ntpd write servicelog directly. My system is very
different from yours as it is a scratch built system, not a distribution.

Salamat po


--
Dancin' in the ruins tonight
mail: echo onub-hgbg@pbyhzohf.ee.pbz | perl -pe 'y/a-z/n-za-m/'
Tayo'y Mga Pinoy

On Sat, 03 Dec 2005 00:00:02 +0100, Baho Utot <onub-hgbg@pbyhzohf.ee.pbz> wrote:

> killall -s HUP ntpd; echo $? from the cmd line gives 0 from running
> logrotate
> -bash-3.00# logrotate -f logrotate.conf error: error running postrotate
> script
>
> -bash-3.00# logrotate -f -d logrotate.conf reading config file
> logrotate.conf
[...]
> log mode = 0644 uid = 0 gid = 0 running postrotate script
> running script with arg /var/log/servicelog: "
> /bin/killall -s HUP ntpd; echo $?
> "
> removing old log /var/log/servicelog.7 -bash-3.00#

Was there no error message when running in debug mode?

>> Another obvious thing to look for is to see if ntpd outputs something
>> when it receives the hangup signal. you would find it in the servicelog
>> files, I guess.
>>
>>
> No nothing in the system log nor servicelog. Looked at all the logs and
> there isn't a single entry.
> I think it's time to log the debug logs from syslogd

On my system,

$ ps -ef | grep ntpd
ntp 9113 1 0 Dec02 ? 00:00:00 ntpd -u ntp:ntp -p /var/run/ntpd.pid -t 1 -g

$ sudo kill -HUP 9113

$ grep ntpd /var/log/messages | tail -2
Dec 2 16:29:50 apeiron ntpd[9113]: synchronized to 62.220.226.1, stratum 2
Dec 3 10:42:49 apeiron ntpd[9113]: ntpd exiting on signal 1

$ sudo killall -s HUP ntpd
ntpd: no process killed

[..]

>> You say the "the servicelog starts..." but who exactly is that? (the
>> servicelog)
>>
>>
> ntpd writes to it directly, I have nothing in the syslog.conf file
> referencing servicelog.
[..]
> What is different is ntpd write servicelog directly. My system is very
> different from yours as it is a scratch built system, not a distribution.

Ah... so I cannot use as much of my experience to base my reasoning on.

Could I suggest you use strace to find out what goes wrong in the case where
logrotate complains? Use something like

strace -o /tmp/lr.strace -f logrotate -f logrotate.conf

If you have not used strace before, its output is voluminous enouhg to bring
one to despair... but in cases like this you only need to scan quickly through
the file starting from the end. Vim (the editor) has a colorizing mode that
helps a lot. The typical line will be like these

fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7faf000
write(1, "Trying 64.233.161.104...\r\n", 26) = 26
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
setsockopt(3, SOL_IP, IP_TOS, [16], 4) = 0

When there is an error return,

connect(3, {sa_family=AF_INET, sin_port=htons(23), sin_addr=inet_addr("64.233.161.104")}, 16) = ? ERESTARTSYS (To be restarted)

(This particular example was interrupted by a signal, normal
errors have a number to the right of the = sign.)

Using your editor's search facilities, search backwards using a
regular expression like =.*E (since error codes begin with E).
You can also search for the error message, which will appear in a
"write" statement - unless the program writes a character at a time.
The clue is often within 20 lines above that.

Oh, the example output given here is from a single-process strace,
without the -f option. With -f, it "follows" child processes, and the
output lines are prefixed with a PID.

When debugging scripts, there are lots of fork and execs, and everything
tends to drown in a vast see of searching for dynamic libraries and
mmapping them when found. I often search for "fork" throughout, noting
the return values on a paper to get the process hierarchy, then search
for "execve" and annnotate my paper with what program(s) each pid runs.

When you know what to look for, there are options to strace that selects
classes of system calls, that helps a lot too, but here you don't know
what goes wrong, so you have to start in voluminous mode.

It is even possible to attach strace to running processes like ntpd,
to see what they do when (and if) they receive signals. Signal reception
is reported separately.

-Enrique

On Sat, 03 Dec 2005 11:22:43 +0100, Enrique Perez-Terron shouted Hoy......

>
>
> On Sat, 03 Dec 2005 00:00:02 +0100, Baho Utot <onub-hgbg@pbyhzohf.ee.pbz> wrote:
>
>> killall -s HUP ntpd; echo $? from the cmd line gives 0 from running
>> logrotate
>> -bash-3.00# logrotate -f logrotate.conf error: error running postrotate
>> script
>>
>> -bash-3.00# logrotate -f -d logrotate.conf reading config file
>> logrotate.conf
> [...]
>> log mode = 0644 uid = 0 gid = 0 running postrotate script
>> running script with arg /var/log/servicelog: "
>> /bin/killall -s HUP ntpd; echo $?
>> "
>> removing old log /var/log/servicelog.7 -bash-3.00#
>
> Was there no error message when running in debug mode?
>
>>> Another obvious thing to look for is to see if ntpd outputs something
>>> when it receives the hangup signal. you would find it in the servicelog
>>> files, I guess.
>>>
>>>
>> No nothing in the system log nor servicelog. Looked at all the logs and
>> there isn't a single entry.
>> I think it's time to log the debug logs from syslogd
>
> On my system,
>
> $ ps -ef | grep ntpd
> ntp 9113 1 0 Dec02 ? 00:00:00 ntpd -u ntp:ntp -p /var/run/ntpd.pid -t 1 -g
>
> $ sudo kill -HUP 9113
>
> $ grep ntpd /var/log/messages | tail -2
> Dec 2 16:29:50 apeiron ntpd[9113]: synchronized to 62.220.226.1, stratum 2
> Dec 3 10:42:49 apeiron ntpd[9113]: ntpd exiting on signal 1
>
> $ sudo killall -s HUP ntpd
> ntpd: no process killed
>
> [..]
>
>>> You say the "the servicelog starts..." but who exactly is that? (the
>>> servicelog)
>>>
>>>
>> ntpd writes to it directly, I have nothing in the syslog.conf file
>> referencing servicelog.
> [..]
>> What is different is ntpd write servicelog directly. My system is very
>> different from yours as it is a scratch built system, not a distribution.
>
> Ah... so I cannot use as much of my experience to base my reasoning on.
>
> Could I suggest you use strace to find out what goes wrong in the case where
> logrotate complains? Use something like
>
> strace -o /tmp/lr.strace -f logrotate -f logrotate.conf
>
> If you have not used strace before, its output is voluminous enouhg to bring
> one to despair... but in cases like this you only need to scan quickly through
> the file starting from the end. Vim (the editor) has a colorizing mode that
> helps a lot. The typical line will be like these
>
> fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7faf000
> write(1, "Trying 64.233.161.104...\r\n", 26) = 26
> socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
> setsockopt(3, SOL_IP, IP_TOS, [16], 4) = 0
>
> When there is an error return,
>
> connect(3, {sa_family=AF_INET, sin_port=htons(23), sin_addr=inet_addr("64.233.161.104")}, 16) = ? ERESTARTSYS (To be restarted)
>
> (This particular example was interrupted by a signal, normal
> errors have a number to the right of the = sign.)
>
> Using your editor's search facilities, search backwards using a
> regular expression like =.*E (since error codes begin with E).
> You can also search for the error message, which will appear in a
> "write" statement - unless the program writes a character at a time.
> The clue is often within 20 lines above that.
>
> Oh, the example output given here is from a single-process strace,
> without the -f option. With -f, it "follows" child processes, and the
> output lines are prefixed with a PID.
>
> When debugging scripts, there are lots of fork and execs, and everything
> tends to drown in a vast see of searching for dynamic libraries and
> mmapping them when found. I often search for "fork" throughout, noting
> the return values on a paper to get the process hierarchy, then search
> for "execve" and annnotate my paper with what program(s) each pid runs.
>
> When you know what to look for, there are options to strace that selects
> classes of system calls, that helps a lot too, but here you don't know
> what goes wrong, so you have to start in voluminous mode.
>
> It is even possible to attach strace to running processes like ntpd,
> to see what they do when (and if) they receive signals. Signal reception
> is reported separately.
>
> -Enrique

Ok I will try the above.

Thankyou

--
Dancin' in the ruins tonight
mail: echo onub-hgbg@pbyhzohf.ee.pbz | perl -pe 'y/a-z/n-za-m/'
Tayo'y Mga Pinoy

On Sat, 03 Dec 2005 11:22:43 +0100, Enrique Perez-Terron shouted Hoy......

[putulin]

> Could I suggest you use strace to find out what goes wrong in the case
> where logrotate complains? Use something like
>
> strace -o /tmp/lr.strace -f logrotate -f logrotate.conf

[putulin]

>
> It is even possible to attach strace to running processes like ntpd, to
> see what they do when (and if) they receive signals. Signal reception is
> reported separately.
>
> -Enrique

Thanks you for helping me figure this one out.

The problem didn't reside with logrotate as such. After I d/l strace and
compiled it and then ran logrotate using strace I found the problem.
Logrotate uses the /tmp directory to build a script containing pre and
post rotate commands, then it will execute the script. My /tmp directory
was mounted from fstab with: rw,auto,nodev,noexec,nosuid,nouser.
So no executables were allowed in /tmp so the script barfed and returned
an error to logrotate.

--
Dancin' in the ruins tonight
mail: echo onub-hgbg@pbyhzohf.ee.pbz | perl -pe 'y/a-z/n-za-m/'
Tayo'y Mga Pinoy

Baho Utot wrote:

>
> The problem didn't reside with logrotate as such. After I d/l strace and
> compiled it and then ran logrotate using strace I found the problem.
> Logrotate uses the /tmp directory to build a script containing pre and
> post rotate commands, then it will execute the script. My /tmp directory
> was mounted from fstab with: rw,auto,nodev,noexec,nosuid,nouser.

Strange. I have never seen that in /etc/fstab files. On my Red Hat
Enterprise Linux 3 system, it says:

/dev/hda6 /tmp ext3 defaults,usrquota 1 2

(I stuck the ",usrquota" in there, but that is another story) and on my
CentOS 4.2 system it says:

LABEL=/tmp1 /tmp ext3 defaults 1 2

> So no executables were allowed in /tmp so the script barfed and returned
> an error to logrotate.
>


--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 03:25:00 up 7 days, 13:55, 3 users, load average: 4.42, 4.26, 4.12