I want to run a process in background without killing it on shell exit, according to Nohup concept the following command should work until I kill it manually:

nohup uwsgi --http :8008  --module crawled_data_center.wsgi > /dev/null &

I'm logged in with root user to shell, but after exit the shell, the process got terminated. It seems weird because I've used nohup several times in several projects and works correctly but in this case I've sucked, what is the problem and how can I run it in background without killing it on shell exit?


I handled it with:

$ nohup uwsgi --http :8008  --module crawled_data_center.wsgi > /dev/null &
$ disown -l
$ disown -h JOBID

But my question is about how could it be possible SIGHUP could kill nohup and & ?

Here is the content of /etc/systemd/logind.conf:

Controllers=blkio cpu cpuacct cpuset devices freezer hugetlb memory perf_event net_cls net_prio
  • @Fox Ubuntu 16.04 – Yuseferi Jan 30 '18 at 7:09
  • Is there a reason why you don't want to run this as a service? – ErikF Jan 30 '18 at 8:52
  • @ErikF do you better plan? I want my django project stay running when I leave the shell. I combine uwsgi with nginx and django. – Yuseferi Jan 30 '18 at 9:38
  • @Fox it's wired, I resolve this issue by using disown but It's not normal. – Yuseferi Jan 30 '18 at 9:39
  • @Fox it seems as a good idea, but I've remembered It'd worked before. – Yuseferi Jan 30 '18 at 10:54

As far as I know, there are two situations that can cause a process to be killed after being protected by nohup, and each situation has a different workaround.

One possibility, which does not appear to be the case here, is that the system uses systemd where logind.conf is configured with KillUserProcesses=yes. In this case, closing the terminal will not cause problems, but logging out of the system will. The workaround in this case is to use

$ systemd-run --scope --user [command]

This basically just tells systemd that it should not kill the process.

The other possibility is that the spawned process implements its own handler for SIGHUP which overrides the protection of nohup. In this case, problems will occur as soon as the shell is closed, even if you remain logged in. You can check for this with:

$ nohup [command] &
$ grep Sig /proc/$!/status

You should see a line

SigIgn: 0000000000000001

(or some other string of hexadecimal digits). SIGHUP is signal number 1, so if this big-endian hexadecimal number has its first (least-significant) bit set (that is, the final digit is one of 1, 3, 5, 7, 9, B, D, or F), then SIGHUP is ignored. Otherwise, the program has installed its own handler overriding the protection of nohup.

In this case, the solution is to use disown:

nohup [command] & disown

This removes the process from the shell's job list, preventing SIGHUP from being sent in the first place.

  • I met the same problem. But your solution to use disown doesn't work for me. Do you have any suggestions? – mathsyouth Nov 12 '19 at 2:26
  • If the program you are using still dies on shell-exit with disown, it is a different problem. You could try running in screen (or similar) in detached mode – Fox Nov 12 '19 at 15:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.