Comment puis-je suivre la cause des redémarrages aléatoires?

Vérifiez /proc/sys/kernel/panic; si sa valeur est de 1 alors le serveur redémarrera immédiatement en cas de panique. Des pilotes défectueux peuvent causer un kernel panic.

S'il ne s'agit pas d'une panique, vérifiez le dernier redémarrage, peut-être que la surchauffe est le problème.

last reboot

Commandes

1. dmesg - Peut ne pas afficher les éléments antérieurs au dernier démarrage, mais très utile si le système est toujours en marche

Fichiers

1. /var/log/syslog - Journal système global, utilisez tail /var/log/syslog ou less /var/log/syslog
2. /var/log/kern.log - Journal du noyau, même chose que ci-dessus
3. /var/log/*

TL;DR: La réponse de @insider, ainsi que les commentaires de @Antonios Hadjigeorgalis, m'ont conduit à découvrir que j'avais

Unattended-Upgrade::Automatic-Reboot "true"

dans

/etc/apt/apt.conf.d/99custom-unattended-upgrades

Je subissais des redémarrages soudains, principalement peu de temps après avoir allumé mon ordinateur portable le matin. Je suis sous Ubuntu 18.04. En exécutant la commande last reboot, j'ai remarqué que la version du noyau était généralement plus récente après les redémarrages soudains :

reboot   system boot  4.15.0-112-gener Wed Jul 22 10:07   still running
reboot   system boot  4.15.0-111-gener Wed Jul 22 10:01 - 10:06  (00:04)
...
reboot   system boot  4.15.0-111-gener Wed Jul 15 09:49 - 23:43  (13:53)
reboot   system boot  4.15.0-109-gener Wed Jul 15 09:45 - 09:48  (00:03)
...
reboot   system boot  4.15.0-109-gener Fri Jul  3 09:14 - 17:37  (08:23)
reboot   system boot  4.15.0-108-gener Fri Jul  3 09:08 - 09:13  (00:05)

En regardant dans /etc/apt/apt.conf.d/50unattended-upgrades, j'ai vu que "Unattended-Upgrade::Automatic-Reboot" était commenté, et que sa valeur par défaut est censée être fausse. J'ai alors exécuté la commande suivante :

grep Reboot /etc/apt/apt.conf.d/*
/etc/apt/apt.conf.d/50unattended-upgrades:Unattended-Upgrade::Automatic-Reboot "false";
/etc/apt/apt.conf.d/50unattended-upgrades://Unattended-Upgrade::Automatic-Reboot-Time "02:00";
/etc/apt/apt.conf.d/99custom-unattended-upgrades:// Redémarre automatiquement si nécessaire (par exemple lors d'une mise à jour du noyau), devrait être
/etc/apt/apt.conf.d/99custom-unattended-upgrades:Unattended-Upgrade::Automatic-Reboot "true";

Et là était mon problème - Unattended-Upgrade::Automatic-Reboot "true"; dans /etc/apt/apt.conf.d/99custom-unattended-upgrades.

Les plantages d'application ont des fichiers de plantage dans /var/crash/; Je explorerai également les journaux système normaux qui sont votre meilleure option. Si le matériel s'arrête, vous ne verrez rien dans les journaux système et message (un indice ÉNORME !!). Si Ubuntu était conscient de l'arrêt, vous le verrez aussi car vous verrez les raisons de l'arrêt. (Si aucun détail n'est trouvé, vous devrez vérifier les journaux de la machine; c'est-à-dire le système d'exploitation HÔTE si la machine virtuelle ou les journaux matériels si sur du métal)

Pour examiner les plantages d'application sur cette machine

guiverc@d960-ubu2:/de2900/ubuntu_64$ ls -la /var/crash
total 113484
drwxrwsrwt 2 root whoopsie 4096 27 fév 12:00 .
drwxr-xr-x 16 root root 4096 29 nov 2018 ..
-rw------- 1 root whoopsie 1214905 26 fév 08:28 irssi-scripts.0.crash
-rw------- 1 root whoopsie 1193193 25 fév 15:04 lvm2.0.crash
-rw-r----- 1 guiverc whoopsie 101162337 19 fév 13:00 _usr_bin_clementine.1000.crash
-rw-r----- 1 guiverc whoopsie 5962296 26 fév 23:31 _usr_bin_gnome-control-center.1000.crash
-rw-r----- 1 guiverc whoopsie 1519149 20 fév 08:28 _usr_bin_light-locker.1000.crash
-rw-r----- 1 guiverc whoopsie 1327084 27 fév 12:00 _usr_bin_totem-video-thumbnailer.1000.crash
-rw-r----- 1 guiverc whoopsie 96196 22 fév 13:55 _usr_games_sgt-launcher.1000.crash
-rw-r----- 1 guiverc whoopsie 3685288 22 fév 00:34 _usr_lib_ibus_ibus-ui-gtk3.1000.crash

Commencer par les plantages d'application est facile, donc je regarderais d'abord là-bas, cependant je ne peux vraiment pas penser à pourquoi un plantage d'application pourrait provoquer un redémarrage ou un arrêt; donc je ne m'attendrais pas à voir quelque chose de significatif là-bas (si c'est utile; ce sera après les journaux système).

Pour afficher les messages système (pour la session en cours) vous pouvez utiliser dmesg. Parce qu'il montrera uniquement la session en cours, vous ne verrez pas la raison du dernier arrêt (c'était la dernière session), mais après un arrêt non planifié, je m'attends à voir les résultats d'un fsck (en raison de l'arrêt non planifié).

Les meilleurs indices se trouvent cependant dans les journaux systemd, ou journalctl. C'est là que je chercherais vraiment des indices sur le dernier arrêt, c'est-à-dire c'est ici que je m'attends à voir l'absence de messages d'arrêt normal ce qui signifie un arrêt matériel (par exemple l'extinction du CPU en raison du seuil de chaleur extrême; un pin se met à la terre sans que le système d'exploitation en ait la moindre idée donc les messages s'arrêtent simplement! et le message suivant est le démarrage normal de la session suivante; de tels messages se trouveront dans les journaux matériels en supposant un serveur d'entreprise; les modèles grand public n'ont généralement pas de journaux matériels).

Parfois, vous pouvez voir des indices de surchauffe dans les journaux de toute façon; mauvais si l'alimentation a des problèmes (PWR_GOOD baisse) rien ne sera trouvé car le CPU n'était même pas au courant de l'arrêt; je suppose que les journaux matériels pourraient également manquer ce type d'arrêt (mais le manque d'entrées est toujours un indice!)

Pour affiner davantage où chercher, dépendra du type de serveur, de ce qui s'y trouve et des détails qui n'ont pas été fournis.