What's the easiest way to make my old init script work in systemd?

Question

I don't want to do the right thing by creating a new systemd script, I just want my old init script to work again now that I've upgraded my system to an OS that's using systemd.

I've briefly researched how to convert init scripts and how to write systemd scripts, but I'm sure learning it properly and doing it right would take me several hours.

The current situation is:

systemctl start solr
Failed to start solr.service: Unit solr.service failed to load: No such file or directory.

And:

sudo service solr start
Failed to start solr.service: Unit solr.service failed to load: No such file or directory.

Right now, I just want to get back to work. What's the path of least resistance to getting this working again?

Updates

I didn't want to figure this all out – I really didn't – but I have to and I've unearthed my first clue:

sudo systemctl enable solr
Synchronizing state for solr.service with sysvinit using update-rc.d...
Executing /usr/sbin/update-rc.d solr defaults
insserv: warning: script 'K01solr' missing LSB tags and overrides
insserv: warning: script 'solr' missing LSB tags and overrides
Executing /usr/sbin/update-rc.d solr enable
update-rc.d: error: solr Default-Start contains no runlevels, aborting.

The incompatibilities page for systemd says that:

LSB header dependency information matters. The SysV implementations on many distributions did not use the dependency information encoded in LSB init script headers, or used them only in very limited ways. Due to that they are often incorrect or incomplete. systemd however fully interprets these headers and follows them closely at runtime

I think that means my script won't work until that's fixed.

The script in question:

#!/bin/sh

# Prerequisites:
# 1. Solr needs to be installed at /usr/local/solr/example
# 2. daemon needs to be installed
# 3. Script needs to be executed by root
# 4. $INSTALL_ROOT must be set

# This script will launch Solr in a mode that will automatically respawn if it
# crashes. Output will be sent to /var/log/solr/solr.log. A pid file will be
# created in the standard location.

start () {
    echo -n "Starting solr..."

    # Reset ulimit or else get issues with too many open files (https://issues.apache.org/jira/browse/SOLR-4)
    ulimit -n 10000

    # start daemon
    daemon --chdir='/usr/local/solr/example' --command "java -jar -server start.jar -DINSTALL_ROOT=$INSTALL_ROOT" --respawn --output=/var/log/solr/solr.log --name=solr --verbose

    RETVAL=$?
    if [ $RETVAL = 0 ]
    then
        echo "done."
    else
        echo "failed. See error code for more information."
    fi
    return $RETVAL
}

stop () {
    # stop daemon
    echo -n "Stopping solr..."

    daemon --stop --name=solr  --verbose
    RETVAL=$?

    if [ $RETVAL = 0 ]
    then
        echo "done."
    else
        echo "failed. See error code for more information."
    fi
    return $RETVAL
}


restart () {
    daemon --restart --name=solr  --verbose
}


status () {
    # report on the status of the daemon
    daemon --running --verbose --name=solr
    return $?
}


case "$1" in
    start)
        start
    ;;
    status)
        status
    ;;
    stop)
        stop
    ;;
    restart)
        stop
        sleep 15
        start
    ;;
    *)
        echo $"Usage: solr {start|status|stop|restart}"
        exit 3
    ;;
esac

exit $RETVAL

Answer 1

Seriously, a systemd unit file is trivial to write for a service like this...or for most services.

This ought to get you about 95% of the way there. Put this in, for example, /etc/systemd/system/solr.service

[Unit]
Description=Apache Solr
After=syslog.target network.target remote-fs.target nss-lookup.target

[Service]
Type=simple
EnvironmentFile=/etc/courtlistener
WorkingDirectory=/usr/local/solr/example
ExecStart=/usr/bin/java -jar -server -Xmx${CL_SOLR_XMX} start.jar -DINSTALL_ROOT=${INSTALL_ROOT}
Restart=on-failure
LimitNOFILE=10000

[Install]
WantedBy=multi-user.target

Note the stuff that isn't here, like the log file and such; systemd will automatically capture and log the service output under the service's name.

Answer 2

For me it was easier to just add the init info block in the header as suggested here:

#!/bin/sh
### BEGIN INIT INFO
# Provides:          solr
# Required-Start:    
# Required-Stop:     
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: solr
# Description:       solr
### END INIT INFO

Then, execute sudo systemctl enable solr.

Answer 3

Another solution to use the solr legacy init script with systemd:

systemctl daemon-reload  
systemctl enable solr  
systemctl start solr  

Answer 4

It's more convenient to run Solr using provided start script.

The systemd unit file looks like this:

[Unit]
Description=Apache Solr for Nextcloud's nextant app fulltext indexing
After=syslog.target network.target remote-fs.target nss-lookup.target systemd-journald-dev-log.socket
Before=nginx.service

[Service]
Type=forking
User=solr
WorkingDirectory=/path/to/solr/server
ExecStart=/path/to/solr/bin/solr start
ExecStop=/path/to/solr/bin/solr stop
Restart=on-failure

[Install]
WantedBy=multi-user.target

Note that you may also make use of your environment variables by adding EnvironmentFile to the [Service] section. The script bin/solr respects environment variables, just take a look in it.

Answer 5

I had the same error while trying to use a LSB init script on CentOS 7. Root cause turned out to be that the script was a symbolic link. Once replaced with a copy of the original, everything worked fine.

Answer 6

Tested on Debian: Add '_SYSTEMCTL_SKIP_REDIRECT=OHYES' at the start of the script.

Systemd fanboys might not like it but hey, I don't like systemd, so there :).

Answer 7

The simplest answer to the OP's question is:

chkconfig {{service-name}} on - this will enable the existing SysV service without anything else to do. I guess it's not entirely the original question is it's running in a kind of legacy mode but it's allowing me to run old CentOS 6 services on version 7 with no extra work.

Once you've run this command you can control the service via standard systemctl commands as it creates the unit wrapper-thingmyjigwhatsit.