72 votes

Quel est le moyen le plus simple de faire fonctionner mon ancien init script dans systemd ?

Je ne veux pas faire la bonne chose en créant un nouveau script de systemd, je veux juste que mon ancien script d'init fonctionne à nouveau maintenant que j'ai mis à niveau mon système vers un OS qui utilise systemd.

J'ai brièvement recherché comment convertir init scripts et comment écrire systemd scripts, mais je suis sûr que l'apprendre correctement et le faire correctement me prendrait plusieurs heures.

La situation actuelle est la suivante :

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

Et :

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

Pour l'instant, je veux juste me remettre au travail. Quel est le chemin de moins résistance pour le faire fonctionner à nouveau ?

Mises à jour

Je ne voulais pas comprendre tout ça - vraiment pas - mais je dois le faire et j'ai trouvé mon premier indice :

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.

En Page des incompatibilités pour systemd dit cela :

L'information sur la dépendance de l'en-tête LSB est importante. Les implémentations de SysV sur de nombreuses distributions n'ont pas utilisé les informations de dépendance encodées dans les en-têtes LSB init script, ou ne les ont utilisées que de manière très limitée. De ce fait, elles sont souvent incorrectes ou incomplètes. systemd interprète cependant pleinement ces en-têtes et les suit de près au moment de l'exécution

Je pense que cela signifie que mon script ne fonctionnera pas jusqu'à ce que cela soit corrigé.

Le script en 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

2voto

user228229 Points 109

J'ai eu la même erreur en essayant d'utiliser un LSB init script sur CentOS 7. La cause fondamentale s'est avérée être que le script était un lien symbolique. Une fois remplacé par une copie de l'original, tout a fonctionné correctement.

1voto

Oly Dungey Points 111

La réponse la plus simple à la question de l'OP est :

chkconfig {{service-name}} on - cela activera le service SysV existant sans rien d'autre à faire. Je suppose que ce n'est pas tout à fait la question initiale, car il fonctionne dans une sorte de mode hérité, mais il me permet d'exécuter les anciens services CentOS 6 sur la version 7 sans travail supplémentaire.

Une fois que vous avez exécuté cette commande, vous pouvez contrôler le service par l'intermédiaire de la commande standard systemctl car il crée l'unité wrapper-thingmyjigwhatsit.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X