message d'état personnalisé systemd?

J'essaie d'écrire un service systemd qui devrait exposer les options start|stop|status|restart .

C'est le script actuel:

 [Unit] Description=Daemon to start ark server After=network.target [Service] ExecStart=/etc/init.d/arkdaemon start ExecStop=/etc/init.d/arkdaemon stop Type=forking [Install] WantedBy=multi-user.target 

Je ne trouve aucun moyen de spécifier une command de statut personnalisé.
Y a-t-il un moyen que je pense, mais comment?

J'essaie d'écrire un service systemd qui devrait exposer les options start|stop|status|restart .

Ta première erreur Les unités de service ne sont pas des scripts. Ils n'ont pas d' options. Les options sont à la command systemctl , et elles sont uniforms dans toutes les unités.

Je me rends count que l'utilisation de centos semble être non standard,

Votre deuxième erreur, liée à votre troisième erreur:

Je vais merge un PR pour résoudre le problème de Debian / Ubuntu. alors nous devrons écrire un démon alternatif pour les centos, car il utilise une méthode init différente.

CentOS n'est pas l'intrus. Ubuntu version 15, Debian 8 et CentOS 7 utilisent systemd et ont tous besoin d'une unité de service systemd appropriée.

  ExecStart = / etc / init.d / arkdaemon start
 ExecStop = / etc / init.d / arrêt arkdaemon 

Ta quasortingème erreur. Vous n'écrivez pas d'unités de service en renvoyant tout à un script rc System 5. Mis à part le fait que cela ne fonctionnera pas sur Debian et Ubuntu, parce qu'ils essaient de tout récupérer dans l'unité de service; c'est une horreur d'un concept, digne d'une input dans la maison d'horreur systemd. En regardant le script System 5 rc , il remet en cause toutes les absurdités erronées: grepping de la sortie de ps , utilisation erronée de sudo pour supprimer des privilèges (plutôt que de les acquérir ).

Ne vous emballez pas au hasard. Comprenez comment votre dæmon est réellement exécuté , puis écrivez une unité de service qui décrit cela.

Votre script System 5 rc appelle un programme nommé arkmanager avec des arkmanager de start et de stop . Donc, à première vue, on pourrait penser qu'une unité de service systemd devrait aussi. Mais il s'avère arkmanager luimême est encore un autre superviseur Dæmon de Poor Man écrit (mal, comme ils le sont toujours) dans un script shell, qui fait tous les mêmes absurdités et beaucoup plus – grepping la sortie de ps , en utilisant screen (sic!) comme un moyen de bifurquer un process et de lui envoyer plus tard un SIGINT , en conservant son propre file journal (sans rotation) et en utilisant des séquences CSI câblées (sic!) dans un programme qui, lors de la gestion d'un dæmon, n'est pas connecté à un terminal en premier lieu.

Vous construisez activement une autre horreur. Arrêtez.

Dépouillant l'horrible édifice chancelant qui supervise un superviseur Dæmon d'un pauvre, qui à son tour abuse de l' screen tant que troisième superviseur ad hoc, on constate que la gestion sous-jacente du service ressemble en réalité à quelque chose comme ceci:

  [Unité]
 Description = server ARK
 Documentation = https: //unix.stackexchange.com/questions/212059/
 Après = network.target

 [Un service]
 Utilisateur = vapeur
 Environnement = SESSION = YourLinuxSessionName
 Environnement = QUERYPORT = 27016
 Environnement = PASS = mot de passe
 Environnement = ADMINPASS = mot de passe administrateur
 QueryPort = $ {QUERYPORT}? ServerPassword = $ {PASS}? ServerAdminPassword = $ {ADMINPASS}? Ecoute = / home / steam / ARK / ShooterGame / Binaires / Linux / ShooterGameServer L'Island? SessionName = $ {SESSION}?
 LimitNOFILE = 100000
 Restart = toujours

 [Installer]
 WantedBy = multi-user.target 

Et quelle est la première règle de migration vers systemd? C'est vrai. C'est maintenant 2015, et quelqu'un l'a probablement déjà fait. Et en effet ici, quelqu'un a déjà, me battre de 4 jours. Ils n'ont pas construit une horreur non plus.

Plus de lecture

Systemd prend en charge le message d'état personnalisé, mais voici quelques préalables à respecter:

  • type de service devrait être notify
  • votre service doit mettre à jour systemd avec votre état de service actuel via /run/systemd/notify socket ou en appelant systemd-notify

Comme reference, vous pouvez vérifier Apache HTTPD sur Fedora (peut-être même dans les autres dissortingbutions, je ne sais pas):

 systemctl status httpd.service ● httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled) Active: active (running) since Fri 2017-10-06 15:21:07 CEST; 18h ago Docs: man:httpd.service(8) Process: 14424 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful (code=exited, status=0/SUCCESS) Main PID: 4105 (httpd) Status: "Total requests: 8; Idle/Busy workers 100/0;Requests/sec: 0.000118; Bytes served/sec: 0 B/sec" 

Vous pouvez voir qu'Apache affiche le statut Total des requêtes: 8; Travailleurs inactifs / occupés 100/0

Donc, quand je strace sur pid 4105, nous pouvons voir qu'il envoie périodiquement des mises à jour de statut à systemd :

 sudo strace -f -p 4105 wait4(-1, 0x7ffcfab4a25c, WNOHANG|WSTOPPED, NULL) = 0 select(0, NULL, NULL, NULL, {tv_sec=1, tv_usec=0}) = 0 (Timeout) socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 8 getsockopt(8, SOL_SOCKET, SO_SNDBUF, [212992], [4]) = 0 setsockopt(8, SOL_SOCKET, SO_SNDBUFFORCE, [8388608], 4) = 0 sendmsg(8, {msg_name={sa_family=AF_UNIX, sun_path="/run/systemd/notify"}, msg_namelen=21, msg_iov=[{iov_base="READY=1\nSTATUS=Total requests: 8"..., iov_len=110}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 110 close(8) = 0 wait4(-1, 0x7ffcfab4a25c, WNOHANG|WSTOPPED, NULL) = 0 

Vous pouvez voir qu'il envoie READY = 1 \ nSTATUS = Nombre total de requêtes: 8 … dans socket /run/systemd/notify

Lecture recommandée

man systemd-notify

ou la documentation officielle .

Exemple: Démarrage du service dans Systemd