Opened 11 years ago

Last modified 11 years ago

#1365 reopened defect

mencoder command line tool incompatible with nohup

Reported by: anton@… Owned by: reimar
Priority: important Component: core
Version: HEAD Severity: major
Keywords: Cc:
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:

Description

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.

Change History (6)

comment:1 Changed 11 years ago by reimar

  • Resolution set to worksforme
  • Status changed from new to closed

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.

comment:2 Changed 11 years ago by anton@…

  • Resolution worksforme deleted
  • Status changed from closed to reopened

(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.

comment:3 Changed 11 years ago by 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.

comment:4 Changed 11 years ago by 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.

comment:5 Changed 11 years ago by 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.

comment:6 Changed 11 years ago by 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.

Note: See TracTickets for help on using tickets.