How to tell systemctl that service has started already

0

I have a service Unit-File mediation.service like this:

[Unit]
Description=Mobile-IP Log dumper

[Service]
Type=forking
ExecStart=/opt/mediation/mediation start
ExecStopPost=/opt/mediation/mediation stop
ExecReload=/opt/mediation/mediation reload
PIDFile=/var/lib/mediation/syslog-ng.pid

Now, assume somebody starts the service directly with /opt/mediation/mediation start instead of using systemctl start mediation

In this case systemctl status mediation will show:

● mediation.service - Mobile-IP Log dumper
   Loaded: loaded (/etc/systemd/system/mediation.service; enabled; vendor preset: disabled)
   Active: inactive (dead) since Mon 2016-07-11 11:24:11 CEST; 8s ago
  Process: 14088 ExecStopPost=/opt/mediation/mediation stop (code=exited, status=0/SUCCESS)
  Process: 13482 ExecStart=/opt/mediation/mediation start (code=exited, status=0/SUCCESS)
 Main PID: 13746

Is it possible that systemctl status mediation shows the correct status (i.e. running) of the service? Looks like systemctl does not reload the PIDFile when it checks the status, because in this case all information would be available and proper status is known.

Wernfried Domscheit

Posted 2016-07-11T09:31:53.557

Reputation: 507

Mobile-IP? Does that still work nowadays, and how can I make it work – user1686 – 2016-07-11T10:08:16.353

Mobile-IP is just our internal name of the application. It is not related to the Mobile-IP protocol - maybe the name is not very smart but now it is too late to change it. – Wernfried Domscheit – 2016-07-11T10:33:14.067

Answers

3

No, you cannot do that.

systemd's service tracking is mainly based on cgroups, so the process cannot be considered part of mediation.service unless it's within the apropriate cgroup. (E.g. that's how user logins are broken away from sshd.service: by moving to another cgroup.) It doesn't care much about PID files, even though it does use them for additional verification.

But even if the process is manually moved to the correct cgroup (via /sys/fs/cgroup/systemd), the whole service still won't be considered 'active' unless it was started via systemd.


In Debian and other distributions which still have a mix of /etc/init.d scripts, this is solved by editing the common "LSB functions" scriptlet to automagically re-run the initscript via systemctl if invoked manually.

But as for starting daemons directly… well, don't do that I guess? Or, make a similar wrapper script that also redirects manual startups to systemctl.

user1686

Posted 2016-07-11T09:31:53.557

Reputation: 283 655

0

As there is no direct solution a workaround could be something to add such lines to the script.

if [[ ! `ps --no-headers -o args -p $PPID | grep systemd` ]] ; then 
   echo "You must start the application with 'systemctl start mediation'"
   exit 1
fi

This prevents that the service is started outside systemctl.

Wernfried Domscheit

Posted 2016-07-11T09:31:53.557

Reputation: 507