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
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
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.
For me it was easier to just add the init info block in the header as suggested here:
Then, execute
sudo systemctl enable solr
.Another solution to use the solr legacy init script with systemd:
It's more convenient to run Solr using provided start script.
The systemd unit file looks like this:
Note that you may also make use of your environment variables by adding
EnvironmentFile
to the[Service]
section. The scriptbin/solr
respects environment variables, just take a look in it.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 :).
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.
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.