Why process killed with nohup

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite
3












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






share|improve this question






















  • @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














up vote
1
down vote

favorite
3












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






share|improve this question






















  • @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












up vote
1
down vote

favorite
3









up vote
1
down vote

favorite
3






3





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






share|improve this question














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








share|improve this question













share|improve this question




share|improve this question








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
















  • @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










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.






share|improve this answer




















    Your Answer







    StackExchange.ready(function()
    var channelOptions =
    tags: "".split(" "),
    id: "106"
    ;
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function()
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled)
    StackExchange.using("snippets", function()
    createEditor();
    );

    else
    createEditor();

    );

    function createEditor()
    StackExchange.prepareEditor(
    heartbeatType: 'answer',
    convertImagesToLinks: false,
    noModals: false,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    );



    );








     

    draft saved


    draft discarded


















    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






























    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.






    share|improve this answer
























      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.






      share|improve this answer






















        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.






        share|improve this answer












        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Jan 30 at 12:48









        Fox

        4,72111131




        4,72111131






















             

            draft saved


            draft discarded


























             


            draft saved


            draft discarded














            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













































































            Popular posts from this blog

            How to check contact read email or not when send email to Individual?

            Displaying single band from multi-band raster using QGIS

            How many registers does an x86_64 CPU actually have?