Why process killed with nohup
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
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?
Update:
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
:
[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
Controllers=blkio cpu cpuacct cpuset devices freezer hugetlb memory perf_event net_cls net_prio
ResetControllers=
#InhibitDelayMaxSec=5
#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
#HandleLidSwitch=suspend
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#IdleAction=ignore
#IdleActionSec=30min
background-process nohup uwsgi
add a comment |Â
up vote
1
down vote
favorite
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?
Update:
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
:
[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
Controllers=blkio cpu cpuacct cpuset devices freezer hugetlb memory perf_event net_cls net_prio
ResetControllers=
#InhibitDelayMaxSec=5
#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
#HandleLidSwitch=suspend
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#IdleAction=ignore
#IdleActionSec=30min
background-process nohup uwsgi
@Fox Ubuntu 16.04
â zhilevan
Jan 30 at 7:09
Is there a reason why you don't want to run this as a service?
â ErikF
Jan 30 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.
â zhilevan
Jan 30 at 9:38
@Fox it's wired, I resolve this issue by using disown but It's not normal.
â zhilevan
Jan 30 at 9:39
@Fox it seems as a good idea, but I've remembered It'd worked before.
â zhilevan
Jan 30 at 10:54
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
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?
Update:
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
:
[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
Controllers=blkio cpu cpuacct cpuset devices freezer hugetlb memory perf_event net_cls net_prio
ResetControllers=
#InhibitDelayMaxSec=5
#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
#HandleLidSwitch=suspend
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#IdleAction=ignore
#IdleActionSec=30min
background-process nohup uwsgi
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?
Update:
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
:
[Login]
#NAutoVTs=6
#ReserveVT=6
#KillUserProcesses=no
#KillOnlyUsers=
#KillExcludeUsers=root
Controllers=blkio cpu cpuacct cpuset devices freezer hugetlb memory perf_event net_cls net_prio
ResetControllers=
#InhibitDelayMaxSec=5
#HandlePowerKey=poweroff
#HandleSuspendKey=suspend
#HandleHibernateKey=hibernate
#HandleLidSwitch=suspend
#PowerKeyIgnoreInhibited=no
#SuspendKeyIgnoreInhibited=no
#HibernateKeyIgnoreInhibited=no
#LidSwitchIgnoreInhibited=yes
#IdleAction=ignore
#IdleActionSec=30min
background-process nohup uwsgi
edited May 29 at 7:46
Mostwanted Mani
1456
1456
asked Jan 30 at 6:34
zhilevan
160214
160214
@Fox Ubuntu 16.04
â zhilevan
Jan 30 at 7:09
Is there a reason why you don't want to run this as a service?
â ErikF
Jan 30 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.
â zhilevan
Jan 30 at 9:38
@Fox it's wired, I resolve this issue by using disown but It's not normal.
â zhilevan
Jan 30 at 9:39
@Fox it seems as a good idea, but I've remembered It'd worked before.
â zhilevan
Jan 30 at 10:54
add a comment |Â
@Fox Ubuntu 16.04
â zhilevan
Jan 30 at 7:09
Is there a reason why you don't want to run this as a service?
â ErikF
Jan 30 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.
â zhilevan
Jan 30 at 9:38
@Fox it's wired, I resolve this issue by using disown but It's not normal.
â zhilevan
Jan 30 at 9:39
@Fox it seems as a good idea, but I've remembered It'd worked before.
â zhilevan
Jan 30 at 10:54
@Fox Ubuntu 16.04
â zhilevan
Jan 30 at 7:09
@Fox Ubuntu 16.04
â zhilevan
Jan 30 at 7:09
Is there a reason why you don't want to run this as a service?
â ErikF
Jan 30 at 8:52
Is there a reason why you don't want to run this as a service?
â ErikF
Jan 30 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.
â zhilevan
Jan 30 at 9:38
@ErikF do you better plan? I want my django project stay running when I leave the shell. I combine uwsgi with nginx and django.
â zhilevan
Jan 30 at 9:38
@Fox it's wired, I resolve this issue by using disown but It's not normal.
â zhilevan
Jan 30 at 9:39
@Fox it's wired, I resolve this issue by using disown but It's not normal.
â zhilevan
Jan 30 at 9:39
@Fox it seems as a good idea, but I've remembered It'd worked before.
â zhilevan
Jan 30 at 10:54
@Fox it seems as a good idea, but I've remembered It'd worked before.
â zhilevan
Jan 30 at 10:54
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
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.
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
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.
add a comment |Â
up vote
1
down vote
accepted
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.
add a comment |Â
up vote
1
down vote
accepted
up vote
1
down vote
accepted
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.
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.
answered Jan 30 at 12:48
Fox
4,72111131
4,72111131
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f420594%2fwhy-process-killed-with-nohup%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
@Fox Ubuntu 16.04
â zhilevan
Jan 30 at 7:09
Is there a reason why you don't want to run this as a service?
â ErikF
Jan 30 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.
â zhilevan
Jan 30 at 9:38
@Fox it's wired, I resolve this issue by using disown but It's not normal.
â zhilevan
Jan 30 at 9:39
@Fox it seems as a good idea, but I've remembered It'd worked before.
â zhilevan
Jan 30 at 10:54