66

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
mlissner
  • 990
  • 3
  • 8
  • 17
  • 1
    "I don't want to do the right thing" is going to get you a lot of negative feedback. Hope you donned your hazmat suit. Anyway, the path of least resistance is _nothing_; just use your init script. – Michael Hampton May 06 '15 at 23:00
  • 6
    One day, surely, I'll do the right thing. But we live in a world of limited resources. I've added more detail about what's not working, since apparently this is supposed to work already. – mlissner May 06 '15 at 23:02
  • Are you trying to do this on Ubuntu? God help you, why? – Michael Hampton May 07 '15 at 00:54
  • 1
    I am. Is that worse than anywhere else? – mlissner May 07 '15 at 01:13
  • 1
    Among all of Ubuntu's other failings, the relevant one here is that Upstart was a godawful nightmare. It's good that they're finally getting rid of it, but your init script _as is_ isn't really compatible with it. How it worked before is most likely through (ancient) SysV compatibility, and while systemd can handle this, Ubuntu has apparently done something to break it. I won't recommend trying to make this work, especially since it would have taken you far less time to write the systemd unit file than you've already spent on this. – Michael Hampton May 07 '15 at 01:30

7 Answers7

35

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.

mlissner
  • 990
  • 3
  • 8
  • 17
Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • 7
    Well, this took me more or less all day to get tweaked and configured and everything. `systemd` has some oddities, like this script won't have persistent logs unless you turn that on. In the end, it's working though and your push was what I needed, thanks. – mlissner May 08 '15 at 01:55
28

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.

eadmaster
  • 757
  • 8
  • 6
  • 4
    You have a typo in your code which happens to be the same I had and was preventing my script to work (thus getting the infamous `"contains no runlevels, aborting"` error) until I realized it: **a missing third # in your second line** (it should be `### BEGIN INIT INFO`). I bet that would also explain why you have so little votes, too. – Pere Mar 29 '17 at 11:19
  • 1
    oops, you're right, probably it was removed in the copy-paste process! (fixed now) – eadmaster Mar 29 '17 at 11:46
  • 2
    I found out the hard way that if the file in /etc/init.d is a symlink, the systemd generator "systemd-sysv-generator" that scans for legacy init.d scripts will skip it. My gerrit file in init.d was a symlink to /home/gerrit2/gerrit/bin/gerrit.sh, I fixed it with: cd /etc/init.d; sudo unlink gerrit; sudo cp /home/gerrit2/gerrit/bin/gerrit.sh gerrit – Integrator Apr 13 '20 at 05:56
  • I just had another symlink issue with this technique: On my system (CentOS 7.8) I installed a classic init.d script uder /etc/init.d but I was not able to enable it using "systemctl enable servicename". The issue was, that on CentOS the directory used for init-script should be /etc/rc.d/init.d . Therefor /etc/init.d is not a directory but rather a symlink to /etc/rc.d/init.d and the init script should be inside this directory. – Oliver R. Feb 26 '21 at 07:43
  • I'll add something for posterity: if your init.d script happens to not be executable, systemd will ignore it but not tell you. It will just act as if it's not there. Maybe it logs an error somewhere, but I've yet to find it. Make sure the installed init script is 755 permissions. – Chris Cleeland Jul 02 '21 at 05:15
12

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

systemctl daemon-reload  
systemctl enable solr  
systemctl start solr
grégory eve
  • 137
  • 1
  • 2
8

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.

Jiří Kozlovský
  • 181
  • 1
  • 2
  • This is fine today. At the time the question was originally written, there was not a provided systemd unit for Solr. – Michael Hampton Dec 25 '17 at 03:49
  • 1
    Note that I wasn't suggesting to use provided `systemd unit` (I simply haven't found any), but suggesting to use the `solr` executable which handles `start/stop` arguments within a custom `systemd unit` definition. – Jiří Kozlovský Nov 02 '20 at 09:52
1

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.

Oly Dungey
  • 111
  • 2
1

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 :).

Guy Egozy
  • 11
  • 1
1

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.

gatopeich
  • 111
  • 2