mencoder command line tool incompatible with nohup

[anton@…]

When mencoder is run from under nohup it still gets killed when the terminal session is closed.

One just can't mess with SIGHUP in a command line tool like mencoder apparently does.

[reimar]

Works just fine for me, using ssh to localhost, "nohup mencoder ... &", logging out.
If it is not a system you are administrator for, keep in mind that some systems run "killall" on logout.

[anton@…]

(In reply to comment #1)

Works just fine for me, using ssh to localhost, "nohup mencoder ... &", logging
out.
If it is not a system you are administrator for, keep in mind that some systems
run "killall" on logout.

(In reply to comment #1)

Works just fine for me, using ssh to localhost, "nohup mencoder ... &", logging
out.
If it is not a system you are administrator for, keep in mind that some systems
run "killall" on logout.

No, it *does not* work. Because of this:

===
signal(SIGHUP,exit_sighandler); broken terminal line
===

in mencoder.c, line 1012 (I have mplayer-export-2008-12-22 snapshot)

nohup (not sure which one you got, but I am looking at GNU coreutils 6.12) does this (line 200 in nohup.c):

===

signal (SIGHUP, SIG_IGN);

===

to prevent children from being affected by SIGHUP. Mencoder, by setting SIGHUP handler, is screwing it up.

[reimar]

A patch for it is under discussion on mplayer-dev-eng, but one of the first comments was that it may not be worth it because nohup is a ugly, broken tool.
Better tools seem to be setsid (the function is part of POSIX, no idea about the binary, but in contrast to nohup it works with shell redirection), and for those using bash, disown -h is available, too.

[anton@…]

(In reply to comment #3)

A patch for it is under discussion on mplayer-dev-eng, but one of the first
comments was that it may not be worth it because nohup is a ugly, broken tool.
Better tools seem to be setsid (the function is part of POSIX, no idea about
the binary, but in contrast to nohup it works with shell redirection), and for
those using bash, disown -h is available, too.

Is there any other utility that has issues with nohup? I guess I can see that you (by "you" I mean mencoder authors) may want to take some cleanup actions on receiving a signal, but the way it stands now you are going to prevent even a proper core from being taken (by intercepting SIGQUIT). And then why not intercept SIGUSR1/2? So, I am not sure where this road is going.

Perhaps a command-line tool should just not mess with signal handling at all? If you are a daemon/server fine, but not a simle command-line tool.

[reimar]

Core dumps still happen on SIGSEGV, SIGILL etc.
mencoder trying to properly close and finish the currently processed file seems much more important (e.g. when recording from TV) than allowing to get a core dump.
Behaviour may be quite inconsistent, but not catching signals does not seem like a user-friendly option at all.
Whether it works usually or not, nohup has some fundamental issues: It requires an actual binary file, it has an unavoidable race condition (there is no way to find out if SIGHUP has already been set to SIG_IGN or not), and its own return values may collide with that of the called program.

[anton@…]

(In reply to comment #5)

Core dumps still happen on SIGSEGV, SIGILL etc.
mencoder trying to properly close and finish the currently processed file seems
much more important (e.g. when recording from TV) than allowing to get a core
dump.
Behaviour may be quite inconsistent, but not catching signals does not seem
like a user-friendly option at all.
Whether it works usually or not, nohup has some fundamental issues: It requires
an actual binary file, it has an unavoidable race condition (there is no way to
find out if SIGHUP has already been set to SIG_IGN or not), and its own return
values may collide with that of the called program.

Well, nohup (I think) is POSIX. I am unaware of any other commnand-line tools that have issues with nohup. Besides, GNU nohup should not be taken as a gospel: Solaris has it's own implementatio, etc. I am pretty sure it does not need any binaries or anything, at least as long as shell bang is used, etc.

Basically, IMO this just must work. This is *nix, so things just have to work the *nix way, however difficult or inconsistent this may be.