How do you use systemd to ensure remote database is available

Clash Royale CLAN TAG#URR8PPP
up vote
2
down vote
favorite
In SysV I can use a condition to ensure an application does not try to start before the database is up and running. I give the init script some time to wait, then finally give up after a period of time if the database service is still unavailable.
start() {
local exec=/path/to/exec
local tries=1
[ -x $exec ] || exit 5
echo -n $"Starting $prog: "
#check communication to database
if ! [ 2>/dev/null : < /dev/tcp/$dbHost/$dbPort ]
then
while ! [ 2>/dev/null : < /dev/tcp/$dbHost/$dbPort ] && [ ! $tries -ge 5 ]
do
>&2 echo -e "Could not connect to the database on $dbHostnWaiting 10 seconds to check database status, attempt $tries"
sleep 10
((tries++))
done
sleep 10
if ! (: < /dev/tcp/$dbHost/$dbPort ) 2>/dev/null
then
>&2 echo -e "Could not connect to the database on $dbHost aborting startup of $exec"
exit 1
fi
fi
I've been searching for a similar scenario in documentation and google, but have not found anything that is not referencing local services.
systemd sysvinit
add a comment |Â
up vote
2
down vote
favorite
In SysV I can use a condition to ensure an application does not try to start before the database is up and running. I give the init script some time to wait, then finally give up after a period of time if the database service is still unavailable.
start() {
local exec=/path/to/exec
local tries=1
[ -x $exec ] || exit 5
echo -n $"Starting $prog: "
#check communication to database
if ! [ 2>/dev/null : < /dev/tcp/$dbHost/$dbPort ]
then
while ! [ 2>/dev/null : < /dev/tcp/$dbHost/$dbPort ] && [ ! $tries -ge 5 ]
do
>&2 echo -e "Could not connect to the database on $dbHostnWaiting 10 seconds to check database status, attempt $tries"
sleep 10
((tries++))
done
sleep 10
if ! (: < /dev/tcp/$dbHost/$dbPort ) 2>/dev/null
then
>&2 echo -e "Could not connect to the database on $dbHost aborting startup of $exec"
exit 1
fi
fi
I've been searching for a similar scenario in documentation and google, but have not found anything that is not referencing local services.
systemd sysvinit
Hm...maybe one option would be to put that into a regular shell script and kick that off throughsystemd. Or useRestartandRestartSec, maybeTimeoutStartSecinsystemdto restart the service on failure. A more sophisticated way could be the use ofExecStartPreto check for the connection.
â Thomas
Mar 23 at 18:51
add a comment |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
In SysV I can use a condition to ensure an application does not try to start before the database is up and running. I give the init script some time to wait, then finally give up after a period of time if the database service is still unavailable.
start() {
local exec=/path/to/exec
local tries=1
[ -x $exec ] || exit 5
echo -n $"Starting $prog: "
#check communication to database
if ! [ 2>/dev/null : < /dev/tcp/$dbHost/$dbPort ]
then
while ! [ 2>/dev/null : < /dev/tcp/$dbHost/$dbPort ] && [ ! $tries -ge 5 ]
do
>&2 echo -e "Could not connect to the database on $dbHostnWaiting 10 seconds to check database status, attempt $tries"
sleep 10
((tries++))
done
sleep 10
if ! (: < /dev/tcp/$dbHost/$dbPort ) 2>/dev/null
then
>&2 echo -e "Could not connect to the database on $dbHost aborting startup of $exec"
exit 1
fi
fi
I've been searching for a similar scenario in documentation and google, but have not found anything that is not referencing local services.
systemd sysvinit
In SysV I can use a condition to ensure an application does not try to start before the database is up and running. I give the init script some time to wait, then finally give up after a period of time if the database service is still unavailable.
start() {
local exec=/path/to/exec
local tries=1
[ -x $exec ] || exit 5
echo -n $"Starting $prog: "
#check communication to database
if ! [ 2>/dev/null : < /dev/tcp/$dbHost/$dbPort ]
then
while ! [ 2>/dev/null : < /dev/tcp/$dbHost/$dbPort ] && [ ! $tries -ge 5 ]
do
>&2 echo -e "Could not connect to the database on $dbHostnWaiting 10 seconds to check database status, attempt $tries"
sleep 10
((tries++))
done
sleep 10
if ! (: < /dev/tcp/$dbHost/$dbPort ) 2>/dev/null
then
>&2 echo -e "Could not connect to the database on $dbHost aborting startup of $exec"
exit 1
fi
fi
I've been searching for a similar scenario in documentation and google, but have not found anything that is not referencing local services.
systemd sysvinit
edited Mar 23 at 18:04
asked Mar 23 at 17:37
Michael Kelly
134
134
Hm...maybe one option would be to put that into a regular shell script and kick that off throughsystemd. Or useRestartandRestartSec, maybeTimeoutStartSecinsystemdto restart the service on failure. A more sophisticated way could be the use ofExecStartPreto check for the connection.
â Thomas
Mar 23 at 18:51
add a comment |Â
Hm...maybe one option would be to put that into a regular shell script and kick that off throughsystemd. Or useRestartandRestartSec, maybeTimeoutStartSecinsystemdto restart the service on failure. A more sophisticated way could be the use ofExecStartPreto check for the connection.
â Thomas
Mar 23 at 18:51
Hm...maybe one option would be to put that into a regular shell script and kick that off through
systemd. Or use Restart and RestartSec, maybe TimeoutStartSec in systemd to restart the service on failure. A more sophisticated way could be the use of ExecStartPre to check for the connection.â Thomas
Mar 23 at 18:51
Hm...maybe one option would be to put that into a regular shell script and kick that off through
systemd. Or use Restart and RestartSec, maybe TimeoutStartSec in systemd to restart the service on failure. A more sophisticated way could be the use of ExecStartPre to check for the connection.â Thomas
Mar 23 at 18:51
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
1
down vote
accepted
Have you looked at ExecStartPre in the systemd service documentation?
I would suggest putting your database test in a script, have it use exit 0 on success and exit 1 on failure and then run it with ExecStartPre. You would then start your application using ExecStart.
I thought about that, but then thought, why not just leave it all in this one SysV script.
â Michael Kelly
Mar 23 at 19:17
Then why use systemd?
â GracefulRestart
Mar 23 at 20:29
I feel that resistance is futile, but would like to write elegant systemd init scripts as I have done with SysV for a couple of decades. :)
â Michael Kelly
Mar 23 at 20:59
there are no init scripts in systemd, there are only service units which can easily execute init scripts. The writeup from @ErikF is a great example of a good one with the bonus that it is reusable for other services.
â GracefulRestart
Mar 23 at 21:22
add a comment |Â
up vote
2
down vote
@GracefulRestart's answer is the best if you only have one service depending on the availability of the database. However, if you have multiple services that have this requirement, make a oneshot service that all of the services can then have a Requires= dependency to:
/etc/systemd/system/portopen@.service
[Unit]
Description=Checks database availability on %I
After=network.target
Requires=network.target
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/path/to/portopen.sh %I
[Install]
WantedBy=default.target
/path/to/portopen.sh
#!/bin/bash
dbhost=$1:-localhost
dbport=$2:-5678
maxtries=$3:-5
wait=$4:-10
tries=1
# Check communication to database
while ! [ 2>/dev/null : < /dev/tcp/$dbhost/$dbport ]; do
echo "Unable to connect to database on $dbhost TCP/$dbport (attempt $tries): retrying in $wait seconds" >&2
(( tries++ ))
if [[ $tries -le $maxtries ]]; then
sleep $wait
else
echo "Unable to connect to database on $dbhost TCP/$dbport: aborting"
exit 1
fi
done
I made the script a bit more flexible in case you change or add database servers, or the port changes, or you want to change the number of retries on a per-service level. If you don't need that, just call the service portopen.service and remove the %I parts.
Let's say your database server is on foobar and your database application runs on foobarapp.service. Make the following changes to foobarapp.service:
# systemctl edit foobarapp.service
[in editor]
[Unit]
After=portopen@foobar.service
Requires=portopen@foobar.service
Then reload systemd and start and enable the check:
# systemctl daemon-reload
# systemctl enable portopen@foobar.service
You can then restart foobarapp.service whenever you want. It should only start if portopen@foobar.service returns successfully.
If it doesn't already exist, the database application service foobarapp.service would then look like this:
/etc/systemd/system/foobarapp.service
[Unit]
Description=Foobar database application
# Add any other dependencies here
After=portopen@foobar.service
Requires=portopen@foobar.service
[Service]
# If it is a daemon, use "forking" instead
Type=simple
ExecStart=/path/to/exec
[Install]
WantedBy=default.target
In reading through the documentation I had come to the conclusion that this would require an external script. So there is no way to have a condition within the single systemd service that says "only continue if2>/dev/null : < /dev/tcp/$dbHost/$dbPortreturns 0" and try x number of times, that you are aware of? I mean without it calling an external script to do so.
â Michael Kelly
Mar 23 at 20:56
systemdhas restart directives, but they only apply to services that aren'toneshot(like this one is); they're more designed to restart failed services that are long-running. An external script is going to be needed for what you are wanting to do.
â ErikF
Mar 24 at 6:19
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
accepted
Have you looked at ExecStartPre in the systemd service documentation?
I would suggest putting your database test in a script, have it use exit 0 on success and exit 1 on failure and then run it with ExecStartPre. You would then start your application using ExecStart.
I thought about that, but then thought, why not just leave it all in this one SysV script.
â Michael Kelly
Mar 23 at 19:17
Then why use systemd?
â GracefulRestart
Mar 23 at 20:29
I feel that resistance is futile, but would like to write elegant systemd init scripts as I have done with SysV for a couple of decades. :)
â Michael Kelly
Mar 23 at 20:59
there are no init scripts in systemd, there are only service units which can easily execute init scripts. The writeup from @ErikF is a great example of a good one with the bonus that it is reusable for other services.
â GracefulRestart
Mar 23 at 21:22
add a comment |Â
up vote
1
down vote
accepted
Have you looked at ExecStartPre in the systemd service documentation?
I would suggest putting your database test in a script, have it use exit 0 on success and exit 1 on failure and then run it with ExecStartPre. You would then start your application using ExecStart.
I thought about that, but then thought, why not just leave it all in this one SysV script.
â Michael Kelly
Mar 23 at 19:17
Then why use systemd?
â GracefulRestart
Mar 23 at 20:29
I feel that resistance is futile, but would like to write elegant systemd init scripts as I have done with SysV for a couple of decades. :)
â Michael Kelly
Mar 23 at 20:59
there are no init scripts in systemd, there are only service units which can easily execute init scripts. The writeup from @ErikF is a great example of a good one with the bonus that it is reusable for other services.
â GracefulRestart
Mar 23 at 21:22
add a comment |Â
up vote
1
down vote
accepted
up vote
1
down vote
accepted
Have you looked at ExecStartPre in the systemd service documentation?
I would suggest putting your database test in a script, have it use exit 0 on success and exit 1 on failure and then run it with ExecStartPre. You would then start your application using ExecStart.
Have you looked at ExecStartPre in the systemd service documentation?
I would suggest putting your database test in a script, have it use exit 0 on success and exit 1 on failure and then run it with ExecStartPre. You would then start your application using ExecStart.
answered Mar 23 at 18:53
GracefulRestart
74917
74917
I thought about that, but then thought, why not just leave it all in this one SysV script.
â Michael Kelly
Mar 23 at 19:17
Then why use systemd?
â GracefulRestart
Mar 23 at 20:29
I feel that resistance is futile, but would like to write elegant systemd init scripts as I have done with SysV for a couple of decades. :)
â Michael Kelly
Mar 23 at 20:59
there are no init scripts in systemd, there are only service units which can easily execute init scripts. The writeup from @ErikF is a great example of a good one with the bonus that it is reusable for other services.
â GracefulRestart
Mar 23 at 21:22
add a comment |Â
I thought about that, but then thought, why not just leave it all in this one SysV script.
â Michael Kelly
Mar 23 at 19:17
Then why use systemd?
â GracefulRestart
Mar 23 at 20:29
I feel that resistance is futile, but would like to write elegant systemd init scripts as I have done with SysV for a couple of decades. :)
â Michael Kelly
Mar 23 at 20:59
there are no init scripts in systemd, there are only service units which can easily execute init scripts. The writeup from @ErikF is a great example of a good one with the bonus that it is reusable for other services.
â GracefulRestart
Mar 23 at 21:22
I thought about that, but then thought, why not just leave it all in this one SysV script.
â Michael Kelly
Mar 23 at 19:17
I thought about that, but then thought, why not just leave it all in this one SysV script.
â Michael Kelly
Mar 23 at 19:17
Then why use systemd?
â GracefulRestart
Mar 23 at 20:29
Then why use systemd?
â GracefulRestart
Mar 23 at 20:29
I feel that resistance is futile, but would like to write elegant systemd init scripts as I have done with SysV for a couple of decades. :)
â Michael Kelly
Mar 23 at 20:59
I feel that resistance is futile, but would like to write elegant systemd init scripts as I have done with SysV for a couple of decades. :)
â Michael Kelly
Mar 23 at 20:59
there are no init scripts in systemd, there are only service units which can easily execute init scripts. The writeup from @ErikF is a great example of a good one with the bonus that it is reusable for other services.
â GracefulRestart
Mar 23 at 21:22
there are no init scripts in systemd, there are only service units which can easily execute init scripts. The writeup from @ErikF is a great example of a good one with the bonus that it is reusable for other services.
â GracefulRestart
Mar 23 at 21:22
add a comment |Â
up vote
2
down vote
@GracefulRestart's answer is the best if you only have one service depending on the availability of the database. However, if you have multiple services that have this requirement, make a oneshot service that all of the services can then have a Requires= dependency to:
/etc/systemd/system/portopen@.service
[Unit]
Description=Checks database availability on %I
After=network.target
Requires=network.target
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/path/to/portopen.sh %I
[Install]
WantedBy=default.target
/path/to/portopen.sh
#!/bin/bash
dbhost=$1:-localhost
dbport=$2:-5678
maxtries=$3:-5
wait=$4:-10
tries=1
# Check communication to database
while ! [ 2>/dev/null : < /dev/tcp/$dbhost/$dbport ]; do
echo "Unable to connect to database on $dbhost TCP/$dbport (attempt $tries): retrying in $wait seconds" >&2
(( tries++ ))
if [[ $tries -le $maxtries ]]; then
sleep $wait
else
echo "Unable to connect to database on $dbhost TCP/$dbport: aborting"
exit 1
fi
done
I made the script a bit more flexible in case you change or add database servers, or the port changes, or you want to change the number of retries on a per-service level. If you don't need that, just call the service portopen.service and remove the %I parts.
Let's say your database server is on foobar and your database application runs on foobarapp.service. Make the following changes to foobarapp.service:
# systemctl edit foobarapp.service
[in editor]
[Unit]
After=portopen@foobar.service
Requires=portopen@foobar.service
Then reload systemd and start and enable the check:
# systemctl daemon-reload
# systemctl enable portopen@foobar.service
You can then restart foobarapp.service whenever you want. It should only start if portopen@foobar.service returns successfully.
If it doesn't already exist, the database application service foobarapp.service would then look like this:
/etc/systemd/system/foobarapp.service
[Unit]
Description=Foobar database application
# Add any other dependencies here
After=portopen@foobar.service
Requires=portopen@foobar.service
[Service]
# If it is a daemon, use "forking" instead
Type=simple
ExecStart=/path/to/exec
[Install]
WantedBy=default.target
In reading through the documentation I had come to the conclusion that this would require an external script. So there is no way to have a condition within the single systemd service that says "only continue if2>/dev/null : < /dev/tcp/$dbHost/$dbPortreturns 0" and try x number of times, that you are aware of? I mean without it calling an external script to do so.
â Michael Kelly
Mar 23 at 20:56
systemdhas restart directives, but they only apply to services that aren'toneshot(like this one is); they're more designed to restart failed services that are long-running. An external script is going to be needed for what you are wanting to do.
â ErikF
Mar 24 at 6:19
add a comment |Â
up vote
2
down vote
@GracefulRestart's answer is the best if you only have one service depending on the availability of the database. However, if you have multiple services that have this requirement, make a oneshot service that all of the services can then have a Requires= dependency to:
/etc/systemd/system/portopen@.service
[Unit]
Description=Checks database availability on %I
After=network.target
Requires=network.target
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/path/to/portopen.sh %I
[Install]
WantedBy=default.target
/path/to/portopen.sh
#!/bin/bash
dbhost=$1:-localhost
dbport=$2:-5678
maxtries=$3:-5
wait=$4:-10
tries=1
# Check communication to database
while ! [ 2>/dev/null : < /dev/tcp/$dbhost/$dbport ]; do
echo "Unable to connect to database on $dbhost TCP/$dbport (attempt $tries): retrying in $wait seconds" >&2
(( tries++ ))
if [[ $tries -le $maxtries ]]; then
sleep $wait
else
echo "Unable to connect to database on $dbhost TCP/$dbport: aborting"
exit 1
fi
done
I made the script a bit more flexible in case you change or add database servers, or the port changes, or you want to change the number of retries on a per-service level. If you don't need that, just call the service portopen.service and remove the %I parts.
Let's say your database server is on foobar and your database application runs on foobarapp.service. Make the following changes to foobarapp.service:
# systemctl edit foobarapp.service
[in editor]
[Unit]
After=portopen@foobar.service
Requires=portopen@foobar.service
Then reload systemd and start and enable the check:
# systemctl daemon-reload
# systemctl enable portopen@foobar.service
You can then restart foobarapp.service whenever you want. It should only start if portopen@foobar.service returns successfully.
If it doesn't already exist, the database application service foobarapp.service would then look like this:
/etc/systemd/system/foobarapp.service
[Unit]
Description=Foobar database application
# Add any other dependencies here
After=portopen@foobar.service
Requires=portopen@foobar.service
[Service]
# If it is a daemon, use "forking" instead
Type=simple
ExecStart=/path/to/exec
[Install]
WantedBy=default.target
In reading through the documentation I had come to the conclusion that this would require an external script. So there is no way to have a condition within the single systemd service that says "only continue if2>/dev/null : < /dev/tcp/$dbHost/$dbPortreturns 0" and try x number of times, that you are aware of? I mean without it calling an external script to do so.
â Michael Kelly
Mar 23 at 20:56
systemdhas restart directives, but they only apply to services that aren'toneshot(like this one is); they're more designed to restart failed services that are long-running. An external script is going to be needed for what you are wanting to do.
â ErikF
Mar 24 at 6:19
add a comment |Â
up vote
2
down vote
up vote
2
down vote
@GracefulRestart's answer is the best if you only have one service depending on the availability of the database. However, if you have multiple services that have this requirement, make a oneshot service that all of the services can then have a Requires= dependency to:
/etc/systemd/system/portopen@.service
[Unit]
Description=Checks database availability on %I
After=network.target
Requires=network.target
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/path/to/portopen.sh %I
[Install]
WantedBy=default.target
/path/to/portopen.sh
#!/bin/bash
dbhost=$1:-localhost
dbport=$2:-5678
maxtries=$3:-5
wait=$4:-10
tries=1
# Check communication to database
while ! [ 2>/dev/null : < /dev/tcp/$dbhost/$dbport ]; do
echo "Unable to connect to database on $dbhost TCP/$dbport (attempt $tries): retrying in $wait seconds" >&2
(( tries++ ))
if [[ $tries -le $maxtries ]]; then
sleep $wait
else
echo "Unable to connect to database on $dbhost TCP/$dbport: aborting"
exit 1
fi
done
I made the script a bit more flexible in case you change or add database servers, or the port changes, or you want to change the number of retries on a per-service level. If you don't need that, just call the service portopen.service and remove the %I parts.
Let's say your database server is on foobar and your database application runs on foobarapp.service. Make the following changes to foobarapp.service:
# systemctl edit foobarapp.service
[in editor]
[Unit]
After=portopen@foobar.service
Requires=portopen@foobar.service
Then reload systemd and start and enable the check:
# systemctl daemon-reload
# systemctl enable portopen@foobar.service
You can then restart foobarapp.service whenever you want. It should only start if portopen@foobar.service returns successfully.
If it doesn't already exist, the database application service foobarapp.service would then look like this:
/etc/systemd/system/foobarapp.service
[Unit]
Description=Foobar database application
# Add any other dependencies here
After=portopen@foobar.service
Requires=portopen@foobar.service
[Service]
# If it is a daemon, use "forking" instead
Type=simple
ExecStart=/path/to/exec
[Install]
WantedBy=default.target
@GracefulRestart's answer is the best if you only have one service depending on the availability of the database. However, if you have multiple services that have this requirement, make a oneshot service that all of the services can then have a Requires= dependency to:
/etc/systemd/system/portopen@.service
[Unit]
Description=Checks database availability on %I
After=network.target
Requires=network.target
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/path/to/portopen.sh %I
[Install]
WantedBy=default.target
/path/to/portopen.sh
#!/bin/bash
dbhost=$1:-localhost
dbport=$2:-5678
maxtries=$3:-5
wait=$4:-10
tries=1
# Check communication to database
while ! [ 2>/dev/null : < /dev/tcp/$dbhost/$dbport ]; do
echo "Unable to connect to database on $dbhost TCP/$dbport (attempt $tries): retrying in $wait seconds" >&2
(( tries++ ))
if [[ $tries -le $maxtries ]]; then
sleep $wait
else
echo "Unable to connect to database on $dbhost TCP/$dbport: aborting"
exit 1
fi
done
I made the script a bit more flexible in case you change or add database servers, or the port changes, or you want to change the number of retries on a per-service level. If you don't need that, just call the service portopen.service and remove the %I parts.
Let's say your database server is on foobar and your database application runs on foobarapp.service. Make the following changes to foobarapp.service:
# systemctl edit foobarapp.service
[in editor]
[Unit]
After=portopen@foobar.service
Requires=portopen@foobar.service
Then reload systemd and start and enable the check:
# systemctl daemon-reload
# systemctl enable portopen@foobar.service
You can then restart foobarapp.service whenever you want. It should only start if portopen@foobar.service returns successfully.
If it doesn't already exist, the database application service foobarapp.service would then look like this:
/etc/systemd/system/foobarapp.service
[Unit]
Description=Foobar database application
# Add any other dependencies here
After=portopen@foobar.service
Requires=portopen@foobar.service
[Service]
# If it is a daemon, use "forking" instead
Type=simple
ExecStart=/path/to/exec
[Install]
WantedBy=default.target
edited Mar 23 at 19:43
answered Mar 23 at 19:37
ErikF
2,7111413
2,7111413
In reading through the documentation I had come to the conclusion that this would require an external script. So there is no way to have a condition within the single systemd service that says "only continue if2>/dev/null : < /dev/tcp/$dbHost/$dbPortreturns 0" and try x number of times, that you are aware of? I mean without it calling an external script to do so.
â Michael Kelly
Mar 23 at 20:56
systemdhas restart directives, but they only apply to services that aren'toneshot(like this one is); they're more designed to restart failed services that are long-running. An external script is going to be needed for what you are wanting to do.
â ErikF
Mar 24 at 6:19
add a comment |Â
In reading through the documentation I had come to the conclusion that this would require an external script. So there is no way to have a condition within the single systemd service that says "only continue if2>/dev/null : < /dev/tcp/$dbHost/$dbPortreturns 0" and try x number of times, that you are aware of? I mean without it calling an external script to do so.
â Michael Kelly
Mar 23 at 20:56
systemdhas restart directives, but they only apply to services that aren'toneshot(like this one is); they're more designed to restart failed services that are long-running. An external script is going to be needed for what you are wanting to do.
â ErikF
Mar 24 at 6:19
In reading through the documentation I had come to the conclusion that this would require an external script. So there is no way to have a condition within the single systemd service that says "only continue if
2>/dev/null : < /dev/tcp/$dbHost/$dbPort returns 0" and try x number of times, that you are aware of? I mean without it calling an external script to do so.â Michael Kelly
Mar 23 at 20:56
In reading through the documentation I had come to the conclusion that this would require an external script. So there is no way to have a condition within the single systemd service that says "only continue if
2>/dev/null : < /dev/tcp/$dbHost/$dbPort returns 0" and try x number of times, that you are aware of? I mean without it calling an external script to do so.â Michael Kelly
Mar 23 at 20:56
systemd has restart directives, but they only apply to services that aren't oneshot (like this one is); they're more designed to restart failed services that are long-running. An external script is going to be needed for what you are wanting to do.â ErikF
Mar 24 at 6:19
systemd has restart directives, but they only apply to services that aren't oneshot (like this one is); they're more designed to restart failed services that are long-running. An external script is going to be needed for what you are wanting to do.â ErikF
Mar 24 at 6:19
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%2f433113%2fhow-do-you-use-systemd-to-ensure-remote-database-is-available%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
Hm...maybe one option would be to put that into a regular shell script and kick that off through
systemd. Or useRestartandRestartSec, maybeTimeoutStartSecinsystemdto restart the service on failure. A more sophisticated way could be the use ofExecStartPreto check for the connection.â Thomas
Mar 23 at 18:51