I am moving a script over from sysvinit startup commands to systemd and I am struggling with the “condrestart” function which is giving different behaviours between the methods when all the docs I can find says they should be the same. I have a unit file, /usr/lib/systemd/system/kopano-search.service:
If the service is stopped a systemctl condrestart kopano-search does not start it but a service kopano-search condrestart does start it. According to the docs, neither command should start it if it is stopped. Is there any reason for this?
FWIW a condrestart of httpd works as documented with sysvinit and systemd in that neither way starts httpd with a condrestart. The /usr/lib/systemd/system/httpd.service contains:
[Unit]
Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target
Documentation=man:httpd(8)
Documentation=man:apachectl(8)
[Service]
Type=notify
EnvironmentFile=/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
ExecStop=/bin/kill -WINCH ${MAINPID}
# We want systemd to give httpd some time to finish gracefully, but still want
# it to kill httpd after TimeoutStopSec if something went wrong during the
# graceful stop. Normally, Systemd sends SIGTERM signal right after the
# ExecStop, which would kill httpd. We are sending useless SIGCONT here to give
# httpd time to finish.
KillSignal=SIGCONT
PrivateTmp=true
[Install]
WantedBy=multi-user.target
Hi @nickh! Welcome to the community! Please have a look at the introductory posts in the #start-here category if you haven’t had a chance to do so.
I’d like to say that on current Fedora systems /usr/sbin/service is just a shell script that quite often (maybe not always, I haven’t dug into it) just translates calls to it into appropriate systemd’s /usr/bin/systemctl calls. So you actually don’t deal with SysVinit here.
As such it may be redundant to debug your issue – unless you know for sure someone or something will use service kopano-search condrestart calls on this machine.
You can also look at the script itself (it’s not that long) and try to understand what happens exactly, how exactly one command gets transformed into another – maybe you’ll understand what’s the reason behind the difference you observe.
The different behavior of your systemd service/unit and httpd service/unit is indeed interesting, though. I’m afraid I can’t provide any insight into it ((( Let’s hope someone else can
The current shell script uses service kopano-search condrestart (plus others) which I was about to translate into systemctl condrestart kopano-search when I noticed the difference in behaviour. The behaviour of the service condrestart is more like a systemctl restart without the ‘cond’.
I had noticed this sort of difference earlier this year with the auditctl daemon. systemctl restart auditd fails, or at least is blocked by the auditd daemon itself and the only way to stop or restart it should be by rebooting. However I noticed that a “service auditd restart” does not get blocked. It was handy for testing but probably not as desired.
I’ll see if I can read the service script. I’m not brilliant at it.
Me neither. We can try to interpret it together. They say two heads are better than one )
Maybe changing this shell script to correct systemctl calls is a more straightforward and reasonable approach?
As far as I understand, /usr/sbin/service is provided for backward compatibility and is not a recommended way of doing things on current Fedora systems.
I am not actually using Fedora, I’m a little downstream from it on ClearOS (FC ->RHEL-Centos->ClearOS) but FC is the upstream source as I understand it.
I am trying to update the shell script (actually a whole lot more as kopano went through a number of config changes which broke our GUI) and I wanted to use the systemd commands as there are other problems with the shell script. It was then that I noticed the difference in behaviour. It behave more like a systemd restart.
I’m with you there, which is why I am trying to update the script, but I’m not getting the expected results.
… playing about some more, this may be a red herring. One system I was testing on had both the init files and unit files hence the bad results. The older version of kopano appears to provide both. Going to a system with the later version of kopano which I am trying to update to only provides unit files and it looks like it works as expected.
Sorry to have wasted your time and thanks for the responses.