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 useRestart
andRestartSec
, maybeTimeoutStartSec
insystemd
to restart the service on failure. A more sophisticated way could be the use ofExecStartPre
to 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 useRestart
andRestartSec
, maybeTimeoutStartSec
insystemd
to restart the service on failure. A more sophisticated way could be the use ofExecStartPre
to 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 useRestart
andRestartSec
, maybeTimeoutStartSec
insystemd
to restart the service on failure. A more sophisticated way could be the use ofExecStartPre
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
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/$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'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/$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'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/$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'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/$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'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/$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'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 useRestart
andRestartSec
, maybeTimeoutStartSec
insystemd
to restart the service on failure. A more sophisticated way could be the use ofExecStartPre
to check for the connection.â Thomas
Mar 23 at 18:51