Sylvain Blandel a écrit 248 commentaires

Le service en question est peut-être lancé parce qu'il est une dépendance d'un autre service, qui lui est lancé régulièrement par un timer ?

Proposition : arrêter tous les timers actifs pendant une période suffisamment longue, puis regarder dans les logs si le service s'est lancé durant cette période.

(même question pour la cible emergency.target)

Le service se lance-t-il si la cible rescue.target est la seule lancée ?

Dans un tty, faire :
systemctl isolate rescue.target

Il s'agit peut-être d'un timer lié à un utilisateur (pas root) ?
- Pour avoir la liste des timers du système :
systemctl list-timers (quand on est connecté en root)
- Pour avoir la liste des timers d'un utilisateur :
systemctl --user list-timers (quand on est connecté en tant que cet utilisateur)

Lorsqu'aucun utilisateur n'est connecté au système, le service se lance-t-il périodiquement ?
Pour voir cela, tu pourrais laisser ton ordinateur sans utilisateur connecté pendant une durée suffisamment longue, puis étudier les logs à posteriori.

Et finalement, as-tu fait la mise-à-jour à distance de l'ordinateur de tes parents ? Ça s'est bien déroulé ?

Est-il possible de supprimer l'accès à tout ce qui permet aux utilisateurs de lancer d'autres logiciels : cacher tous les menus, les icônes, … et n'avoir sur le bureau qu'une seule chose : l'icône sur laquelle on clique pour lancer le logiciel de vente.

Content d'avoir pu t'aider ! 😊

# créer le nouveau /boot
cp -a /boot /boot-tmp
umount /boot
rm -rf /boot
mv /boot-tmp /boot

# modifier le fstab pour virer le mount de /boot
vi ...

# regénérer grub.cfg qui va tout détecter comme un grand
grub-mkconfig -o /boot/grub/grub.cfg

# c'est tout
reboot

Je suis d'accord, mais y'a un truc qui m'inquiète.

Le fichier /boot/grub/grub.cfg va être déplacé sur le disque dur : actuellement, il se trouve sur la partition dédiée à /boot Ensuite il se trouvera sur la partition / Autrement dit, le fichier grub.cfg se trouve actuellement sur la partition /dev/sda2 ; ensuite, il se trouvera sur la partition /dev/sda3 (je ne suis pas certain du nom de tes partitions, c'est juste pour expliquer ma pensée).

J'ai peur qu'au redémarrage de l'ordinateur, le logiciel grub te dise :

« Ouin ouin ! Je cherche le fichier grub.cfg sur la partition sda2 comme j'en ai l'habitude, mais ce fichier n'est plus là. Je suis perdu. Je ne peux pas démarrer l'ordinateur. »

En farfouillant dans la base de données d'Intel, tu dénicheras peut-être des infos ?

ma tendance à coder avachie comme une merde dans ma chaise de bureau.

Au taf, nous avons un siège de ce type. Certains apprécient.

voir la commande xset avec son argument dpms

https://www.x.org/archive/X11R7.5/doc/man/man1/xset.1.html

On peut voir l'état des variable avec la commande xset -q
La partie DPMS est à la fin.

Si tu en as la possibilité, renomme ton dossier avec un nom qui ne contiendra aucun caractère problématique (espace, tiret, point, *, #, \, $, |, `, ~, …). Ensuite, efface le dossier.

Les styles dont nous parlons ici ne sont pas proposés par la page des styles.

En revanche, tout en bas de la page des styles, il y a « Pour utiliser une feuille de style externe, veuillez saisir son URL : ». Et bien là, tu peux utiliser les URL données dans le journal :-)

Super, j'en essaie une immédiatement !

Quel test, quelle condition, permet d'affirmer que « À présent, influxdb a fini de démarrer, et les services qui dépendent d'influxdb peuvent maintenant être lancés » ?

influxdb est un service de quel Type ? Il me semble que cette option a un rôle à jouer.

Peux-tu poster le contenu du fichier influxdb.service ?

Le bug est présent chez moi (Archlinux 64 bits, noyau 4.7.5, systemd 231-1).

La boucle suivante rend mon système « instable » :
while true; do NOTIFY_SOCKET=/run/systemd/notify systemd-notify ""; done
Ce bug fonctionne même lorsque cette commande est lancée par un simple utilisateur ; et le système reste instable lorsqu'on est sorti de cette boucle avec un Ctrl+C

Pour redémarrer, la commande systemctl reboot ne fonctionnait pas, je m'en suis sorti avec systemctl reboot --force --force (attention, cela correspond à un redémarrage brutal).

Merci d'avoir compris que mon commentaire était un troll :-)
Effectivement, il ne contenait aucune argumentation pertinente. Et j'avais pris soin d'attendre vendredi pour le poster :-D

On constate avec tristesse que Slackware refuse encore systemd, en 2016 !

En s'obstinant à utiliser l'archaïque SysVinit, les développeurs de Slackware condamnent leur distribution à une fossilisation certaine. Cette décision est regrettable et incompréhensible ; tout le monde reconnaît aujourd’hui la supériorité technique et de la polyvalence de systemd.

J'espère que les développeurs de Slackware comprendront rapidement leur erreur, et qu'ils reviendront à la raison.

Et si tu démontes manuellement les systèmes de fichiers, puis que tu redémarres avec kexec ? Le message d'erreur au redémarrage persiste-t-il ?

Comment savoir que ça vient bien d'un timeout ? Je ne vois rien dans les logs avec journalctl ?

Tu peux afficher l'état de chaque unité avec systemctl :
systemctl --all

Tu peux filtrer les unités affichées selon leur état. Quelques exemples :
systemctl --all --state=failed
systemctl --all --state=not-found

---

L'outil journalctl affiche les logs. Pour n'afficher que les logs depuis le dernier démarrage :
journalctl -b

Pour filtrer les logs selon leur criticité, c'est le paramètre -p Par exemple :
journalctl -p warning

Lorsque tu as repéré l'unité déconnante, tu peux afficher uniquement les logs de cette unité, avec le paramètre -u :
journalctl -u machin.service

Toutes ces options sont cumulables.

couper le conteur

Toi, tu nous racontes des histoires :-)

Ça va être particulièrement difficile, nous ne sommes pas dans une année bissextile, et Annie Girardot a déjà photocopié du sable. Éventuellement, si Demis Roussos plume une girafe … mais tarte aux pommes.

Canonical semble ralentir le développement d'Upstart. En effet, la dernière version d'Upstart est sortie il y a 7 mois déjà (le 4 septembre 2014). Et sur la liste de discussion upstart-devel, il n'y a eu aucun mail pendant 48 jours consécutifs (entre le 19 février et le 7 avril 2015).

Cela paraît logique, vu la décision de ne plus utiliser Upstart pour les prochaines versions d'Ubuntu.

waitproctofinish(){ while pgrep -f $1 > /dev/null ; do sleep 1 ; done }

Merci, c'est bien pratique ! Je ne connaissais pas pgrep :-)

Combien de temps après le lancement de la commande shutdown est ce que des programmes peuvent effectuer des operations?

Bonjour.

Tu peux faire des tests avec la commande sleep. La commande sleep 5m attend 5 minutes avant de rendre la main. Lance cette commande, puis lance la commande shutdown. Tu verras si l'ordinateur attend 5 minutes (ou moins) pour s'arrêter.

---

Il est également possible de programmer un shutdown pour plus tard :

• Pour éteindre l'ordinateur dans 205 minutes : shutdown -h +205
• Pour redémarrer l'ordinateur à 19h23 : shutdown -r 19:23

Pour en savoir plus : man shutdown

---

Enfin, pour être certain que le shutdown s'exécute APRÈS ta commande qui prend du temps, tu peux mettre les deux commandes sur une même ligne, séparées par un point-virgule :

$ première-commande ; shutdown -h +0

La commande shutdown ne s'exécutera que lorsque la première-commande sera terminée.