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
lui – mê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.
systemctl
. pages de manuel systemd. freedesktop.org. Systemd prend en charge le message d'état personnalisé, mais voici quelques préalables à respecter:
notify
/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