Re: Sometimes multilog rotates the logfile when receiving a sigterm

(* Reply to /dev/null'd *)

Rodrigo Campos wrote:

>> Are the logs rotated to *.s files with 744 permissions, or *.u files with
>> 644 permissions?

> .u files with 644

This indicates that multilog had been abnormally terminated.

>>  What are the permissions on ./test/current when multilog
>> has "terminated"?

> On the directory ? drwx------

./test/current is a file.  It should be 744 when multilog has cleanly
exited, or 644 while multilog is running or has been abnormally
terminated.

From <http://cr.yp.to/daemontools/multilog.html>:

While multilog is running, current has mode 644. If multilog sees the
end of stdin, it writes current safely to disk, and sets the mode of
current to 744. When it restarts, it sets the mode of current back to
644 and continues writing new lines. 

And:

* .s: This file is completely processed and safely written to disk.
* .u: This file was being created at the moment of an outage. It may
have been truncated. It has not been processed. 

> I see the file rotated without running it a next time.

Rotate to *.s, or *.u.  There is a race here - if the first program
terminates quickly enough and closes the pipe, multilog may get
the chance to clean up before receiving the signal.

> Could this be caused be something else ?

Perhaps, but you're going to need to observe the state of the files
prior to running multilog again.  I'd wager that what you're seeing
is lot of multilog cleaning up the previous run.

> But if I do "kill <pid>" where pid is the pid of the program, it
> should not affect multilog, shouldn't it ?

Yes, it might.  As I wrote previously:

>> I don't know about your "kill", except that if
>> multilog terminated abnormally previously (denoted by the permissions on
>> current) it will rotate current to a *.u filename when multilog runs the
>> next time.


-- 
Regards,
  Daryl Tester

"Crush! Kill! Deploy!"  -- Lost In Space I.T. Dept.