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
    Commented Jan 30, 2018 at 7:09
  • Is there a reason why you don't want to run this as a service?
    – ErikF
    Commented Jan 30, 2018 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
    Commented Jan 30, 2018 at 9:38
  • @Fox it's wired, I resolve this issue by using disown but It's not normal.
    – Yuseferi
    Commented Jan 30, 2018 at 9:39
  • @Fox it seems as a good idea, but I've remembered It'd worked before.
    – Yuseferi
    Commented Jan 30, 2018 at 10:54

1 Answer 1


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.

  • 1
    I met the same problem. But your solution to use disown doesn't work for me. Do you have any suggestions?
    – mathsyouth
    Commented Nov 12, 2019 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
    Commented Nov 12, 2019 at 15:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .