“Proper” way to run shell script as a daemon

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











up vote
13
down vote

favorite
3












I am writing a shell script that I would like to run as a daemon on startup without using external tools like daemontools or daemonize.




Linux Daemon Writing HOWTO



According to the Linux Daemon Writing HOWTO, a proper daemon has the following characteristics:




  • forks from the parent process


  • closes all file descriptors (i.e., stdin, stdout, stderr)

  • opens logs for writing (if configured)

  • changes the working directory to one that is persistent (usually /)

  • resets the file mode mask (umask)

  • creates an unique Session ID (SID)



daemonize Introduction



The daemonize Introduction goes further, stating that a typical daemon also:



  • disassociates from its control terminal (if there is one) and ignores all terminal signals

  • disassociates from its process group

  • handles SIGCLD


How would I do all this in a sh, dash, or bash script with common Linux tools only?



The script should be able to run on as many distros as possible without additional software, although Debian is our primary focus.




NOTE: I know there are plenty of answers on the StackExchange network recommending the use of nohup or setsid, but neither of these methods tackles all of the requirements above.




EDIT: The daemon(7) manpage also gives some pointers, although there seem to be some differences between older-style SysV daemons and newer systemd ones. Since compatibility with a variety of distros is important, please ensure the answer makes clear any differences.









share|improve this question






















  • The "proper" way to craft your own shell script is to make it do its own logging, provide a method for launching it as a daemon, etc. Things like daemon and those other things are for running arbitrary shell scripts with no provision for running as a daemon. Since you're the author, fully in control of how that script is written, make it so it can just be launched from a systemd unitfile or rc.d script. You did specify "Proper"!
    – Rich
    Apr 11 at 1:06














up vote
13
down vote

favorite
3












I am writing a shell script that I would like to run as a daemon on startup without using external tools like daemontools or daemonize.




Linux Daemon Writing HOWTO



According to the Linux Daemon Writing HOWTO, a proper daemon has the following characteristics:




  • forks from the parent process


  • closes all file descriptors (i.e., stdin, stdout, stderr)

  • opens logs for writing (if configured)

  • changes the working directory to one that is persistent (usually /)

  • resets the file mode mask (umask)

  • creates an unique Session ID (SID)



daemonize Introduction



The daemonize Introduction goes further, stating that a typical daemon also:



  • disassociates from its control terminal (if there is one) and ignores all terminal signals

  • disassociates from its process group

  • handles SIGCLD


How would I do all this in a sh, dash, or bash script with common Linux tools only?



The script should be able to run on as many distros as possible without additional software, although Debian is our primary focus.




NOTE: I know there are plenty of answers on the StackExchange network recommending the use of nohup or setsid, but neither of these methods tackles all of the requirements above.




EDIT: The daemon(7) manpage also gives some pointers, although there seem to be some differences between older-style SysV daemons and newer systemd ones. Since compatibility with a variety of distros is important, please ensure the answer makes clear any differences.









share|improve this question






















  • The "proper" way to craft your own shell script is to make it do its own logging, provide a method for launching it as a daemon, etc. Things like daemon and those other things are for running arbitrary shell scripts with no provision for running as a daemon. Since you're the author, fully in control of how that script is written, make it so it can just be launched from a systemd unitfile or rc.d script. You did specify "Proper"!
    – Rich
    Apr 11 at 1:06












up vote
13
down vote

favorite
3









up vote
13
down vote

favorite
3






3





I am writing a shell script that I would like to run as a daemon on startup without using external tools like daemontools or daemonize.




Linux Daemon Writing HOWTO



According to the Linux Daemon Writing HOWTO, a proper daemon has the following characteristics:




  • forks from the parent process


  • closes all file descriptors (i.e., stdin, stdout, stderr)

  • opens logs for writing (if configured)

  • changes the working directory to one that is persistent (usually /)

  • resets the file mode mask (umask)

  • creates an unique Session ID (SID)



daemonize Introduction



The daemonize Introduction goes further, stating that a typical daemon also:



  • disassociates from its control terminal (if there is one) and ignores all terminal signals

  • disassociates from its process group

  • handles SIGCLD


How would I do all this in a sh, dash, or bash script with common Linux tools only?



The script should be able to run on as many distros as possible without additional software, although Debian is our primary focus.




NOTE: I know there are plenty of answers on the StackExchange network recommending the use of nohup or setsid, but neither of these methods tackles all of the requirements above.




EDIT: The daemon(7) manpage also gives some pointers, although there seem to be some differences between older-style SysV daemons and newer systemd ones. Since compatibility with a variety of distros is important, please ensure the answer makes clear any differences.









share|improve this question














I am writing a shell script that I would like to run as a daemon on startup without using external tools like daemontools or daemonize.




Linux Daemon Writing HOWTO



According to the Linux Daemon Writing HOWTO, a proper daemon has the following characteristics:




  • forks from the parent process


  • closes all file descriptors (i.e., stdin, stdout, stderr)

  • opens logs for writing (if configured)

  • changes the working directory to one that is persistent (usually /)

  • resets the file mode mask (umask)

  • creates an unique Session ID (SID)



daemonize Introduction



The daemonize Introduction goes further, stating that a typical daemon also:



  • disassociates from its control terminal (if there is one) and ignores all terminal signals

  • disassociates from its process group

  • handles SIGCLD


How would I do all this in a sh, dash, or bash script with common Linux tools only?



The script should be able to run on as many distros as possible without additional software, although Debian is our primary focus.




NOTE: I know there are plenty of answers on the StackExchange network recommending the use of nohup or setsid, but neither of these methods tackles all of the requirements above.




EDIT: The daemon(7) manpage also gives some pointers, although there seem to be some differences between older-style SysV daemons and newer systemd ones. Since compatibility with a variety of distros is important, please ensure the answer makes clear any differences.











share|improve this question













share|improve this question




share|improve this question








edited Apr 4 at 21:02









steve

12.3k22048




12.3k22048










asked Feb 27 at 6:55









user339676

302210




302210











  • The "proper" way to craft your own shell script is to make it do its own logging, provide a method for launching it as a daemon, etc. Things like daemon and those other things are for running arbitrary shell scripts with no provision for running as a daemon. Since you're the author, fully in control of how that script is written, make it so it can just be launched from a systemd unitfile or rc.d script. You did specify "Proper"!
    – Rich
    Apr 11 at 1:06
















  • The "proper" way to craft your own shell script is to make it do its own logging, provide a method for launching it as a daemon, etc. Things like daemon and those other things are for running arbitrary shell scripts with no provision for running as a daemon. Since you're the author, fully in control of how that script is written, make it so it can just be launched from a systemd unitfile or rc.d script. You did specify "Proper"!
    – Rich
    Apr 11 at 1:06















The "proper" way to craft your own shell script is to make it do its own logging, provide a method for launching it as a daemon, etc. Things like daemon and those other things are for running arbitrary shell scripts with no provision for running as a daemon. Since you're the author, fully in control of how that script is written, make it so it can just be launched from a systemd unitfile or rc.d script. You did specify "Proper"!
– Rich
Apr 11 at 1:06




The "proper" way to craft your own shell script is to make it do its own logging, provide a method for launching it as a daemon, etc. Things like daemon and those other things are for running arbitrary shell scripts with no provision for running as a daemon. Since you're the author, fully in control of how that script is written, make it so it can just be launched from a systemd unitfile or rc.d script. You did specify "Proper"!
– Rich
Apr 11 at 1:06










3 Answers
3






active

oldest

votes

















up vote
5
down vote













Using systemd you should be able to run a script as a daemon by creating a simple unit.
There are a lot of different options you can add but this is about as simple as you can get.



Say you have a script /usr/bin/mydaemon.



#!/bin/sh

while true; do
date;
sleep 60;
done


You create a unit /etc/systemd/system/mydaemon.service.



[Unit]
Description=My daemon

[Service]
ExecStart=/usr/bin/mydaemon
Restart=on-failure

[Install]
WantedBy=multi-user.target


To start the demon you run



systemctl start mydaemon.service 


To start at boot you enable it



systemctl enable mydaemon.service


If on a systemd based system, which a majority of Linux distributions are today, this isn't really an external tool. The negative would be that it won't work everywhere though.






share|improve this answer


















  • 2




    While I like the systemd approach, the OP said "no external tools". There are Linux distributions which don't have systemd yet, or let you use choose between systemd and something else, e.g. OpenRC.
    – Cristian Ciupitu
    Apr 4 at 3:05











  • For distros that use systemd, systemd is no more of an "external tool" than bash.
    – Alexander
    Apr 10 at 12:10

















up vote
3
down vote



+500










I am probably missing something here; why exactly wouldn't nohup be appropriate? Of course it's not enough alone, but supplementing it seems straightforward.



#!/bin/bash

if [ "$1" = "DAEMON" ]; then
# is this necessary? Add other signals at will (TTIN TTOU INT STOP TSTP)
trap '' INT
cd /tmp
shift
### daemonized section ######
for i in $( seq 1 10 ); do
date
sleep 5
done
#### end of daemonized section ####
exit 0
fi

export PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin
umask 022
# You can add nice and ionice before nohup but they might not be installed
nohup setsid $0 DAEMON $* 2>/var/log/mydaemon.err >/var/log/mydaemon.log &


As far as I can see:



  • the output is appropriately redirected (use /dev/null if necessary)

  • the umask is inherited


  • stdin dies at the end of the parent script however

  • the daemon.sh script is reparented to init (or systemd)

I have a strong feeling I'm missing the obvious. Downvote, but please tell me what it is :-)






share|improve this answer
















  • 2




    I was about to suggest something very similar. I use nohup with & and I/O redirection to launch several non - C daemon utilities with perhaps the added security of wrapping your nohup command inside of a su -c "nohup ... &" -s /bin/bash systemUser to run the daemon as a non-privileged user.
    – datUser
    Apr 4 at 18:31


















up vote
3
down vote













The Linux screen command contained in most distros can daemonize a shell script. I use it often. Here's a quick example to start, list, and quit a detached screen session...



# screen -dmS Session_Name bash -c "while true; do date; sleep 60; done"

# screen -ls
There are screens on:
8534.Session_Name (04/04/2018 08:46:27 PM) (Detached)

# screen -S Session_Name -X quit





share|improve this answer


















  • 2




    screen doesn't deamonize shell script. It just run they in distinguished terminal and can detach from this terminal (like unplug keyboard from PC) without closing session. So, the program running in detached terminal is running in background. Therefore - detach pass program in background.
    – Yurij Goncharuk
    Apr 4 at 21:17










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%2f426862%2fproper-way-to-run-shell-script-as-a-daemon%23new-answer', 'question_page');

);

Post as a guest






























3 Answers
3






active

oldest

votes








3 Answers
3






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
5
down vote













Using systemd you should be able to run a script as a daemon by creating a simple unit.
There are a lot of different options you can add but this is about as simple as you can get.



Say you have a script /usr/bin/mydaemon.



#!/bin/sh

while true; do
date;
sleep 60;
done


You create a unit /etc/systemd/system/mydaemon.service.



[Unit]
Description=My daemon

[Service]
ExecStart=/usr/bin/mydaemon
Restart=on-failure

[Install]
WantedBy=multi-user.target


To start the demon you run



systemctl start mydaemon.service 


To start at boot you enable it



systemctl enable mydaemon.service


If on a systemd based system, which a majority of Linux distributions are today, this isn't really an external tool. The negative would be that it won't work everywhere though.






share|improve this answer


















  • 2




    While I like the systemd approach, the OP said "no external tools". There are Linux distributions which don't have systemd yet, or let you use choose between systemd and something else, e.g. OpenRC.
    – Cristian Ciupitu
    Apr 4 at 3:05











  • For distros that use systemd, systemd is no more of an "external tool" than bash.
    – Alexander
    Apr 10 at 12:10














up vote
5
down vote













Using systemd you should be able to run a script as a daemon by creating a simple unit.
There are a lot of different options you can add but this is about as simple as you can get.



Say you have a script /usr/bin/mydaemon.



#!/bin/sh

while true; do
date;
sleep 60;
done


You create a unit /etc/systemd/system/mydaemon.service.



[Unit]
Description=My daemon

[Service]
ExecStart=/usr/bin/mydaemon
Restart=on-failure

[Install]
WantedBy=multi-user.target


To start the demon you run



systemctl start mydaemon.service 


To start at boot you enable it



systemctl enable mydaemon.service


If on a systemd based system, which a majority of Linux distributions are today, this isn't really an external tool. The negative would be that it won't work everywhere though.






share|improve this answer


















  • 2




    While I like the systemd approach, the OP said "no external tools". There are Linux distributions which don't have systemd yet, or let you use choose between systemd and something else, e.g. OpenRC.
    – Cristian Ciupitu
    Apr 4 at 3:05











  • For distros that use systemd, systemd is no more of an "external tool" than bash.
    – Alexander
    Apr 10 at 12:10












up vote
5
down vote










up vote
5
down vote









Using systemd you should be able to run a script as a daemon by creating a simple unit.
There are a lot of different options you can add but this is about as simple as you can get.



Say you have a script /usr/bin/mydaemon.



#!/bin/sh

while true; do
date;
sleep 60;
done


You create a unit /etc/systemd/system/mydaemon.service.



[Unit]
Description=My daemon

[Service]
ExecStart=/usr/bin/mydaemon
Restart=on-failure

[Install]
WantedBy=multi-user.target


To start the demon you run



systemctl start mydaemon.service 


To start at boot you enable it



systemctl enable mydaemon.service


If on a systemd based system, which a majority of Linux distributions are today, this isn't really an external tool. The negative would be that it won't work everywhere though.






share|improve this answer














Using systemd you should be able to run a script as a daemon by creating a simple unit.
There are a lot of different options you can add but this is about as simple as you can get.



Say you have a script /usr/bin/mydaemon.



#!/bin/sh

while true; do
date;
sleep 60;
done


You create a unit /etc/systemd/system/mydaemon.service.



[Unit]
Description=My daemon

[Service]
ExecStart=/usr/bin/mydaemon
Restart=on-failure

[Install]
WantedBy=multi-user.target


To start the demon you run



systemctl start mydaemon.service 


To start at boot you enable it



systemctl enable mydaemon.service


If on a systemd based system, which a majority of Linux distributions are today, this isn't really an external tool. The negative would be that it won't work everywhere though.







share|improve this answer














share|improve this answer



share|improve this answer








edited Jul 9 at 21:56

























answered Apr 4 at 2:14









johnramsden

988




988







  • 2




    While I like the systemd approach, the OP said "no external tools". There are Linux distributions which don't have systemd yet, or let you use choose between systemd and something else, e.g. OpenRC.
    – Cristian Ciupitu
    Apr 4 at 3:05











  • For distros that use systemd, systemd is no more of an "external tool" than bash.
    – Alexander
    Apr 10 at 12:10












  • 2




    While I like the systemd approach, the OP said "no external tools". There are Linux distributions which don't have systemd yet, or let you use choose between systemd and something else, e.g. OpenRC.
    – Cristian Ciupitu
    Apr 4 at 3:05











  • For distros that use systemd, systemd is no more of an "external tool" than bash.
    – Alexander
    Apr 10 at 12:10







2




2




While I like the systemd approach, the OP said "no external tools". There are Linux distributions which don't have systemd yet, or let you use choose between systemd and something else, e.g. OpenRC.
– Cristian Ciupitu
Apr 4 at 3:05





While I like the systemd approach, the OP said "no external tools". There are Linux distributions which don't have systemd yet, or let you use choose between systemd and something else, e.g. OpenRC.
– Cristian Ciupitu
Apr 4 at 3:05













For distros that use systemd, systemd is no more of an "external tool" than bash.
– Alexander
Apr 10 at 12:10




For distros that use systemd, systemd is no more of an "external tool" than bash.
– Alexander
Apr 10 at 12:10












up vote
3
down vote



+500










I am probably missing something here; why exactly wouldn't nohup be appropriate? Of course it's not enough alone, but supplementing it seems straightforward.



#!/bin/bash

if [ "$1" = "DAEMON" ]; then
# is this necessary? Add other signals at will (TTIN TTOU INT STOP TSTP)
trap '' INT
cd /tmp
shift
### daemonized section ######
for i in $( seq 1 10 ); do
date
sleep 5
done
#### end of daemonized section ####
exit 0
fi

export PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin
umask 022
# You can add nice and ionice before nohup but they might not be installed
nohup setsid $0 DAEMON $* 2>/var/log/mydaemon.err >/var/log/mydaemon.log &


As far as I can see:



  • the output is appropriately redirected (use /dev/null if necessary)

  • the umask is inherited


  • stdin dies at the end of the parent script however

  • the daemon.sh script is reparented to init (or systemd)

I have a strong feeling I'm missing the obvious. Downvote, but please tell me what it is :-)






share|improve this answer
















  • 2




    I was about to suggest something very similar. I use nohup with & and I/O redirection to launch several non - C daemon utilities with perhaps the added security of wrapping your nohup command inside of a su -c "nohup ... &" -s /bin/bash systemUser to run the daemon as a non-privileged user.
    – datUser
    Apr 4 at 18:31















up vote
3
down vote



+500










I am probably missing something here; why exactly wouldn't nohup be appropriate? Of course it's not enough alone, but supplementing it seems straightforward.



#!/bin/bash

if [ "$1" = "DAEMON" ]; then
# is this necessary? Add other signals at will (TTIN TTOU INT STOP TSTP)
trap '' INT
cd /tmp
shift
### daemonized section ######
for i in $( seq 1 10 ); do
date
sleep 5
done
#### end of daemonized section ####
exit 0
fi

export PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin
umask 022
# You can add nice and ionice before nohup but they might not be installed
nohup setsid $0 DAEMON $* 2>/var/log/mydaemon.err >/var/log/mydaemon.log &


As far as I can see:



  • the output is appropriately redirected (use /dev/null if necessary)

  • the umask is inherited


  • stdin dies at the end of the parent script however

  • the daemon.sh script is reparented to init (or systemd)

I have a strong feeling I'm missing the obvious. Downvote, but please tell me what it is :-)






share|improve this answer
















  • 2




    I was about to suggest something very similar. I use nohup with & and I/O redirection to launch several non - C daemon utilities with perhaps the added security of wrapping your nohup command inside of a su -c "nohup ... &" -s /bin/bash systemUser to run the daemon as a non-privileged user.
    – datUser
    Apr 4 at 18:31













up vote
3
down vote



+500







up vote
3
down vote



+500




+500




I am probably missing something here; why exactly wouldn't nohup be appropriate? Of course it's not enough alone, but supplementing it seems straightforward.



#!/bin/bash

if [ "$1" = "DAEMON" ]; then
# is this necessary? Add other signals at will (TTIN TTOU INT STOP TSTP)
trap '' INT
cd /tmp
shift
### daemonized section ######
for i in $( seq 1 10 ); do
date
sleep 5
done
#### end of daemonized section ####
exit 0
fi

export PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin
umask 022
# You can add nice and ionice before nohup but they might not be installed
nohup setsid $0 DAEMON $* 2>/var/log/mydaemon.err >/var/log/mydaemon.log &


As far as I can see:



  • the output is appropriately redirected (use /dev/null if necessary)

  • the umask is inherited


  • stdin dies at the end of the parent script however

  • the daemon.sh script is reparented to init (or systemd)

I have a strong feeling I'm missing the obvious. Downvote, but please tell me what it is :-)






share|improve this answer












I am probably missing something here; why exactly wouldn't nohup be appropriate? Of course it's not enough alone, but supplementing it seems straightforward.



#!/bin/bash

if [ "$1" = "DAEMON" ]; then
# is this necessary? Add other signals at will (TTIN TTOU INT STOP TSTP)
trap '' INT
cd /tmp
shift
### daemonized section ######
for i in $( seq 1 10 ); do
date
sleep 5
done
#### end of daemonized section ####
exit 0
fi

export PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin
umask 022
# You can add nice and ionice before nohup but they might not be installed
nohup setsid $0 DAEMON $* 2>/var/log/mydaemon.err >/var/log/mydaemon.log &


As far as I can see:



  • the output is appropriately redirected (use /dev/null if necessary)

  • the umask is inherited


  • stdin dies at the end of the parent script however

  • the daemon.sh script is reparented to init (or systemd)

I have a strong feeling I'm missing the obvious. Downvote, but please tell me what it is :-)







share|improve this answer












share|improve this answer



share|improve this answer










answered Apr 4 at 18:17









LSerni

2,326615




2,326615







  • 2




    I was about to suggest something very similar. I use nohup with & and I/O redirection to launch several non - C daemon utilities with perhaps the added security of wrapping your nohup command inside of a su -c "nohup ... &" -s /bin/bash systemUser to run the daemon as a non-privileged user.
    – datUser
    Apr 4 at 18:31













  • 2




    I was about to suggest something very similar. I use nohup with & and I/O redirection to launch several non - C daemon utilities with perhaps the added security of wrapping your nohup command inside of a su -c "nohup ... &" -s /bin/bash systemUser to run the daemon as a non-privileged user.
    – datUser
    Apr 4 at 18:31








2




2




I was about to suggest something very similar. I use nohup with & and I/O redirection to launch several non - C daemon utilities with perhaps the added security of wrapping your nohup command inside of a su -c "nohup ... &" -s /bin/bash systemUser to run the daemon as a non-privileged user.
– datUser
Apr 4 at 18:31





I was about to suggest something very similar. I use nohup with & and I/O redirection to launch several non - C daemon utilities with perhaps the added security of wrapping your nohup command inside of a su -c "nohup ... &" -s /bin/bash systemUser to run the daemon as a non-privileged user.
– datUser
Apr 4 at 18:31











up vote
3
down vote













The Linux screen command contained in most distros can daemonize a shell script. I use it often. Here's a quick example to start, list, and quit a detached screen session...



# screen -dmS Session_Name bash -c "while true; do date; sleep 60; done"

# screen -ls
There are screens on:
8534.Session_Name (04/04/2018 08:46:27 PM) (Detached)

# screen -S Session_Name -X quit





share|improve this answer


















  • 2




    screen doesn't deamonize shell script. It just run they in distinguished terminal and can detach from this terminal (like unplug keyboard from PC) without closing session. So, the program running in detached terminal is running in background. Therefore - detach pass program in background.
    – Yurij Goncharuk
    Apr 4 at 21:17














up vote
3
down vote













The Linux screen command contained in most distros can daemonize a shell script. I use it often. Here's a quick example to start, list, and quit a detached screen session...



# screen -dmS Session_Name bash -c "while true; do date; sleep 60; done"

# screen -ls
There are screens on:
8534.Session_Name (04/04/2018 08:46:27 PM) (Detached)

# screen -S Session_Name -X quit





share|improve this answer


















  • 2




    screen doesn't deamonize shell script. It just run they in distinguished terminal and can detach from this terminal (like unplug keyboard from PC) without closing session. So, the program running in detached terminal is running in background. Therefore - detach pass program in background.
    – Yurij Goncharuk
    Apr 4 at 21:17












up vote
3
down vote










up vote
3
down vote









The Linux screen command contained in most distros can daemonize a shell script. I use it often. Here's a quick example to start, list, and quit a detached screen session...



# screen -dmS Session_Name bash -c "while true; do date; sleep 60; done"

# screen -ls
There are screens on:
8534.Session_Name (04/04/2018 08:46:27 PM) (Detached)

# screen -S Session_Name -X quit





share|improve this answer














The Linux screen command contained in most distros can daemonize a shell script. I use it often. Here's a quick example to start, list, and quit a detached screen session...



# screen -dmS Session_Name bash -c "while true; do date; sleep 60; done"

# screen -ls
There are screens on:
8534.Session_Name (04/04/2018 08:46:27 PM) (Detached)

# screen -S Session_Name -X quit






share|improve this answer














share|improve this answer



share|improve this answer








edited Apr 4 at 22:03









roaima

39.5k545107




39.5k545107










answered Apr 4 at 21:00









S.Haran

314




314







  • 2




    screen doesn't deamonize shell script. It just run they in distinguished terminal and can detach from this terminal (like unplug keyboard from PC) without closing session. So, the program running in detached terminal is running in background. Therefore - detach pass program in background.
    – Yurij Goncharuk
    Apr 4 at 21:17












  • 2




    screen doesn't deamonize shell script. It just run they in distinguished terminal and can detach from this terminal (like unplug keyboard from PC) without closing session. So, the program running in detached terminal is running in background. Therefore - detach pass program in background.
    – Yurij Goncharuk
    Apr 4 at 21:17







2




2




screen doesn't deamonize shell script. It just run they in distinguished terminal and can detach from this terminal (like unplug keyboard from PC) without closing session. So, the program running in detached terminal is running in background. Therefore - detach pass program in background.
– Yurij Goncharuk
Apr 4 at 21:17




screen doesn't deamonize shell script. It just run they in distinguished terminal and can detach from this terminal (like unplug keyboard from PC) without closing session. So, the program running in detached terminal is running in background. Therefore - detach pass program in background.
– Yurij Goncharuk
Apr 4 at 21:17












 

draft saved


draft discarded


























 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f426862%2fproper-way-to-run-shell-script-as-a-daemon%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?