Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1055290 - nohup gets hup'ed
Summary: nohup gets hup'ed
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: coreutils
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Ondrej Vasik
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-19 23:32 UTC by Tom Horsley
Modified: 2016-05-12 09:59 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-05-12 09:59:28 UTC


Attachments (Terms of Use)

Description Tom Horsley 2014-01-19 23:32:12 UTC
Description of problem:

In fedora 19 the udev scripts described here work perfectly:

http://home.comcast.net/~tomhorsley/hardware/solidoodle/solidoodle-udev.html

Part of what happens in those scripts is starting background tasks using nohup to avoid the udev tendency to kill things that take "too long".

In fedora 20, the ~/scripts/solidoodle-on script described in the web page above always dies in the "sleep 5" as something apparently kills it because it is taking too long (I guess). If I remove the sleep 5, the RepetierHost splash screen comes up, but then is killed almost immediately.

So nohup doesn't seem to be preventing the killing of the background job any longer.


Version-Release number of selected component (if applicable):
coreutils-8.21-20.fc20.x86_64

How reproducible:
every time

Steps to Reproduce:
1.install udev scripts in above web page
2.plug in solidoodle to USB port
3.

Actual results:
background job killed

Expected results:
background job protected from death by nohup

Additional info:

I tried taking out the sleep 5 and logging stdout and stderr to a log file and even running RepetierHost under strace to see if any indication of what signal was killing it showed up, but the log and the strace output all just get suddenly truncated as the processes are killed by whatever mysterious force is at work in fedora 20.

Comment 1 Tom Horsley 2014-01-20 02:39:21 UTC
Well, of course, it is totally obvious! I just need to add this line to the script that gets run in the background:

echo $$ > /sys/fs/cgroup/systemd/user.slice/tasks

Everyone knows that!

Perhaps nohup should arrange to make the nohup'ed job a "normal user" cgroup? (Especially since I read that the systemd fungus is soon about to grow over and engluph the cgroup filesystem interface and require you to manipulate cgroups using some obscure dbus interface instead).

Comment 2 Kamil Dudka 2016-05-12 09:59:28 UTC
The nohup utility just sets the SIGHUP signal to be ignored.  It cannot protect the process from death in general.  The process can still be killed by another signal, or it can even restore (or otherwise handle) the SIGHUP handler on its own.  Doing anything else than disabling the default SIGHUP handler is certainly beyond the scope of the sighup utility.


Note You need to log in before you can comment on or make changes to this bug.