Re: Sometimes multilog rotates the logfile when receiving a sigterm

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

Rodrigo Campos wrote:

>> If you mean the first process, no.

...

> Yes, you are right. Sorry

You don't have to apologise - if you're learning anything from this,
then it's good.  :-)

>> Personally, if I were to write something to work around this behaviour
>> I would write a nohup-style wrapper that blocks SIGHUP or performs a

> Yes, perhaps running "<program> | (trap ...; multilog...)" makes the
> trick

That should do it, provided that using a subshell doesn't introduce
any other issues (i.e. it's not preferred under if daemontools because
supervise would send the signal to the shell, and not the multilog
process under it).  If you're not running multilog under daemontools
then it should be fine.

> (nohup if that is the signal, but trap if its other signal).

That takes me back - "in the old days" nohup was just a shell script
that did exactly that - trapped SIGUP, exec'd the remainder of its
arguments.

Actually, this shows the problem nicely ...

$ (trap "echo bing >&2" SIGINT; sleep 20; echo hi) | (trap "echo bong" SIGINT; read x)
^C
bong
bing
$ 

Both processes either end of the pipe received SIGINT.

> Or perhaps I can always send a SIGTERM to multilog first and then
> SIGTERM to the program.

Probably not - if the first process writes any terminating message
then it will be lost as a) multilog is no longer running, and b)
the first process will get SIGPIPE'd because the pipe no longer has
a reader (multilog) (which may, depending on how it handles SIGPIPE
cause its termination to take a different direction).  The preferred
order is to terminate the first process only, and when it exits the
pipe will be closed down causing multilog to exit cleanly.

> Although avoiding the signals to arrive to
> multilog seems to be what I really want (if that is what is causing it
> to generate the .u files I'm seeing).

Remember that this is behaviour is most likely caused by your 
*interactive* shell.  A shell spawned out of crontab or start
script is very unlikely to send a signal to a process *group*
(or see ^C from a controlling tty).  If your final environment
is running multilog non-interactively then you're unlikely to
see any of the behaviour you're trying to avoid here.

> An other option perhaps is running it through a fifo (mkfifo).

Potentially, but it shouldn't be necessary.  It depends on when
you start multilog if your shell will put it into it's own
process group separate from the pipe writer (I think it should,
otherwise issuing ^C would cause all the processes you've
started to get SIGINT, which doesn't sound like a fun plan.
But I've not tested this).

-- 
Regards,
  Daryl Tester

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