1) monit doesn't support systemd. If you are ready to support this
package for systemd - please do.
I just use monit on a Debian system with its default init system. I
would expect monit to work on such a system. If it does not, this should
be noted in the documentation and also probably declare appropriate
dependencies (e.g. to require certain init system or conflict systemd)
in the package meta information. Not sure whether I missed something in
this direction. I already proposed a solution that could work on all
systems in my initial email.
2) "This is not the case when used via monit." - and why it's the monit
problem, but not systemd*?
I think that this issue could be handled better on the monit side, but
feel free to forward this to the systemd maintainers.
I consider the compatibility approach for /etc/init.d (sysvinit) by
systemd very hackish and thus I would prefer a more general solution to
control services. According to
https://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/
calling init scripts directly is also discouraged by LSB.
stretch contains the essential package init-system-helpers for this.
3) I would suggest calling the "service".
- I was already suggested before. The reason for using more low-level
instruments is that this prevents from using service dependencies
from LSB headers. If you use monit - probably it does make sense
to use also it to handle dependencies. At least, by default.
See also https://bugs.debian.org/791667, where it was discussed.
I'm open to reconsider this, but please avoid using systemd
in your argumentation.
I was talking about using the /usr/sbin/service binary. In #791667 as
far as I can see only invoke-rc.d was suggested.
I agree, that maintainer script requirements may not apply to the monit
configuration, but would strongly encourage you to consider a more
general solution for controlling services.
/usr/sbin/service as well as invoke-rc.d (maybe event with --force) seem
to be alternatives worth considering.
