Runing Multiple Daemons With Systemctl

Home » CentOS » Runing Multiple Daemons With Systemctl
CentOS 5 Comments

Hi all,

I am doing some tests with a CentOS7 vm image before to enter in our production environment. I need to migrate some sysvinit scripts to systemctl.

In all of them I need to launch some daemons in the same init script. For example:

a) start daemon1
b) if daemon1 returns no startup errors, launch daemon2
c) if daemon1 returns any startup error, doesn’t start daemon2 and exit.

Is it possible to do this with systemctl??


5 thoughts on - Runing Multiple Daemons With Systemctl

  • In this specific example I’d probably do it as two service units with daemon2 wanted by and requiring the daemon1 service…

    That was daemon2 will want to be started by default and dependencies mean that will start daemon1 in the process of doing so… But since 2 requires
    1 if 1 fails to start for some reason then 2 won’t be stated.

  • Thanks james. That was my first idea … But some of these daemons can conflict with some system packages. For example I need to startup two rsyslog daemons, and this can be a problem … or not??

  • So long as they don’t conflict in ports or sockets I don’t see how this would be a problem… Or at the least it’s a simpler problem to solve than in the sysvinit world …

    cp /usr/lib/systemd/system/rsyslogd.service

    Amend the rsyslog-foo.service file to use a different config and any specific dependencies it needs then:

    systemctl enable rsyslog-foo systemctl start rsyslog-foo

    This is a very basic initial YMMV example but should get you started on some ideas at least…

  • Could this help?

    ExecStartPre=, ExecStartPost
    Additional commands that are executed before or after the command in ExecStart=, respectively. Syntax is the same as for ExecStart=, except that multiple command lines are allowed and the commands are executed one after the other, serially.

    If any of those commands (not prefixed with “-“) fail, the rest are not executed and the unit is considered failed.

  • Given his criteria I really would not go down this route …

    The Pre/Post stuff is meant to be one shot commands that exit cleanly and is for config testing or creation of SSH keys (for an example of one instance).

    They are not really designed for this as the process that is backgrounded for the first daemon would not be tracked as a service in systemd.

    It’s far more useful from a maintenance/diagnostic/simplicity perspective to do two separate service unit files with appropriate dependencies.