âProperâ way to run shell script as a daemon
Clash Royale CLAN TAG#URR8PPP
up vote
13
down vote
favorite
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.
linux shell-script debian daemon
add a comment |Â
up vote
13
down vote
favorite
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.
linux shell-script debian daemon
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 likedaemon
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
add a comment |Â
up vote
13
down vote
favorite
up vote
13
down vote
favorite
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.
linux shell-script debian daemon
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.
linux shell-script debian daemon
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 likedaemon
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
add a comment |Â
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 likedaemon
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
add a comment |Â
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.
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" thanbash
.
â Alexander
Apr 10 at 12:10
add a comment |Â
up vote
3
down vote
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
(orsystemd
)
I have a strong feeling I'm missing the obvious. Downvote, but please tell me what it is :-)
2
I was about to suggest something very similar. I usenohup
with&
and I/O redirection to launch several non -C
daemon utilities with perhaps the added security of wrapping yournohup
command inside of asu -c "nohup ... &" -s /bin/bash systemUser
to run the daemon as a non-privileged user.
â datUser
Apr 4 at 18:31
add a comment |Â
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
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
add a comment |Â
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.
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" thanbash
.
â Alexander
Apr 10 at 12:10
add a comment |Â
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.
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" thanbash
.
â Alexander
Apr 10 at 12:10
add a comment |Â
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.
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.
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" thanbash
.
â Alexander
Apr 10 at 12:10
add a comment |Â
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" thanbash
.
â 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
add a comment |Â
up vote
3
down vote
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
(orsystemd
)
I have a strong feeling I'm missing the obvious. Downvote, but please tell me what it is :-)
2
I was about to suggest something very similar. I usenohup
with&
and I/O redirection to launch several non -C
daemon utilities with perhaps the added security of wrapping yournohup
command inside of asu -c "nohup ... &" -s /bin/bash systemUser
to run the daemon as a non-privileged user.
â datUser
Apr 4 at 18:31
add a comment |Â
up vote
3
down vote
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
(orsystemd
)
I have a strong feeling I'm missing the obvious. Downvote, but please tell me what it is :-)
2
I was about to suggest something very similar. I usenohup
with&
and I/O redirection to launch several non -C
daemon utilities with perhaps the added security of wrapping yournohup
command inside of asu -c "nohup ... &" -s /bin/bash systemUser
to run the daemon as a non-privileged user.
â datUser
Apr 4 at 18:31
add a comment |Â
up vote
3
down vote
up vote
3
down vote
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
(orsystemd
)
I have a strong feeling I'm missing the obvious. Downvote, but please tell me what it is :-)
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
(orsystemd
)
I have a strong feeling I'm missing the obvious. Downvote, but please tell me what it is :-)
answered Apr 4 at 18:17
LSerni
2,326615
2,326615
2
I was about to suggest something very similar. I usenohup
with&
and I/O redirection to launch several non -C
daemon utilities with perhaps the added security of wrapping yournohup
command inside of asu -c "nohup ... &" -s /bin/bash systemUser
to run the daemon as a non-privileged user.
â datUser
Apr 4 at 18:31
add a comment |Â
2
I was about to suggest something very similar. I usenohup
with&
and I/O redirection to launch several non -C
daemon utilities with perhaps the added security of wrapping yournohup
command inside of asu -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
add a comment |Â
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
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
add a comment |Â
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
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
add a comment |Â
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
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
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
add a comment |Â
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
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%2f426862%2fproper-way-to-run-shell-script-as-a-daemon%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
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