2

I have a service installed on an old server and it is started using;

service load-simulator start medium

The value medium acts as a profile of sorts. It can have values like low, medium, high, and extreme. I need to make it run on a new updated Linux server.

It has a script in init.d which takes the argument at the end and sets a USED_PROFILE environment variable. I have installed this service in the new server, but the same service command mentioned before gets me an error No Profile Specified and it fails to start.

As it is using systemctl to start now, in what order do I need to provide the argument to make it work?

The script has something like;

case "$1" in
start)
    if [ $# -eq 2 ]; then
        export USED_PROFILE=$2
    else
        printNoProfileSpecified
        exit 1
    fi
    $1
    ;;

Sorry if this is a newbie question. I am quite new to this. Tried different ordering with service and systemctl command but nothing worked. Any help or tip is much appreciated. Many thanks in advance.

0

1 Answer 1

2

Part of systemd's design is that services started from a terminal are subject to exactly the same rules and environment as during system startup (and vice versa) – they can't be directly passed any one-off commands or arguments because there would be no way to express them in terms of startup dependencies.

So the only way to provide custom arguments to a "pre-defined" systemd service is to turn it into a template unit, which can receive one argument as part of the instance name:

  1. Rename your unit to <name>@.service to indicate that it's a template.

    mv load-simulator.service [email protected]
    
  2. Make the unit use %i or %I to fill in the instance argument (%i does no processing while %I applies some un-escaping rules). For example:

    ExecStart=/etc/init.d/loadsim start %i
    

    or, to avoid the redundant init.d script (which are generally not recommended to be used with systemd as they tend to make its monitoring features ineffective):

    Environment=USED_PROFILE=%i
    ExecStart=/usr/bin/loadsim --profile=${USED_PROFILE}
    

    or:

    ExecStart=/usr/bin/loadsim --profile=%i
    
  3. Start it using systemctl:

    systemctl start load-simulator@low
    

Note that because the argument becomes part of the unit's name, systemd will allow multiple copies of the same template to be started with different arguments – e.g. it will allow one [email protected] and one [email protected] to be started at the same time, and both of them are likewise separate from the original non-templated sim.service. If you don't want to allow multiple instances, the service program needs to have its own locking (using flock or some other kind of lock file); e.g. flock /run/loadsim.lock /bin/loadsim ...


If the "service" isn't so much a service as it is a one-off command that only relies on some other systemd feature (e.g. memory limits), systemd-run can be used to start arbitrary commands with such parameters.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .