Re: Jamais vu ça...
Le 2022-10-15 16:17, l0f...@tuta.io a écrit : 15 oct. 2022, 15:25 de b...@taranig.net: Le 2022-10-15 09:33, l0f...@tuta.io a écrit : Pour ceux qui ont des soucis, que donne : utmpdump /run/utmp ? l0f4r0 Utmp dump of /run/utmp [8] [00233] [si ] [] [] [] [0.0.0.0] [2022-10-14T14:18:56,899429+00:00] [2] [0] [~~ ] [reboot ] [~ ] [] [0.0.0.0] [2022-10-14T14:18:56,937117+00:00] [1] [20019] [~~ ] [runlevel] [~ ] [] [0.0.0.0] [2022-10-14T14:18:56,938127+00:00] [8] [01371] [l3 ] [] [] [] [0.0.0.0] [2022-10-14T14:19:48,233144+00:00] [6] [02371] [8 ] [LOGIN ] [tty8] [] [0.0.0.0] [2022-10-14T14:19:48,240587+00:00] [5] [02372] [9 ] [] [] [] [0.0.0.0] [2022-10-14T14:19:48,241550+00:00] [6] [02370] [7 ] [LOGIN ] [tty7] [] [0.0.0.0] [2022-10-14T14:19:48,242438+00:00] [6] [02369] [6 ] [LOGIN ] [tty6] [] [0.0.0.0] [2022-10-14T14:19:48,243424+00:00] [6] [02368] [5 ] [LOGIN ] [tty5] [] [0.0.0.0] [2022-10-14T14:19:48,243960+00:00] [6] [02367] [4 ] [LOGIN ] [tty4] [] [0.0.0.0] [2022-10-14T14:19:48,245313+00:00] [6] [02366] [3 ] [LOGIN ] [tty3] [] [0.0.0.0] [2022-10-14T14:19:48,246487+00:00] [6] [02504] [2 ] [LOGIN ] [tty2] [] [0.0.0.0] [2022-10-14T14:22:53,553918+00:00] [7] [31047] [ts/1] [root] [pts/1 ] [ ] [] [2022-10-15T13:20:54,474857+00:00] Ça semble tout à fait normal, non ? Oui l'entrée [reboot] semble cohérente. Mais du coup que donne "who -b" sur bookworm désormais ? NB : si nouveau reboot il y a eu encore depuis, merci de redonner le résultat des 2 commandes "who -b" et "utmpdump /run/utmp" histoire qu'on compare la même chose. l0f4r0 # who -b system boot 127545610-04-02 03:32 !!
Re: Jamais vu ça...
15 oct. 2022, 15:25 de b...@taranig.net: > Le 2022-10-15 09:33, l0f...@tuta.io a écrit : > >> Pour ceux qui ont des soucis, que donne : >> >> utmpdump /run/utmp >> >> ? >> >> l0f4r0 >> > Utmp dump of /run/utmp > [8] [00233] [si ] [] [] [] [0.0.0.0 > ] [2022-10-14T14:18:56,899429+00:00] > [2] [0] [~~ ] [reboot ] [~ ] [] [0.0.0.0 > ] [2022-10-14T14:18:56,937117+00:00] > [1] [20019] [~~ ] [runlevel] [~ ] [] [0.0.0.0 > ] [2022-10-14T14:18:56,938127+00:00] > [8] [01371] [l3 ] [] [] [] [0.0.0.0 > ] [2022-10-14T14:19:48,233144+00:00] > [6] [02371] [8 ] [LOGIN ] [tty8] [] [0.0.0.0 > ] [2022-10-14T14:19:48,240587+00:00] > [5] [02372] [9 ] [] [] [] [0.0.0.0 > ] [2022-10-14T14:19:48,241550+00:00] > [6] [02370] [7 ] [LOGIN ] [tty7] [] [0.0.0.0 > ] [2022-10-14T14:19:48,242438+00:00] > [6] [02369] [6 ] [LOGIN ] [tty6] [] [0.0.0.0 > ] [2022-10-14T14:19:48,243424+00:00] > [6] [02368] [5 ] [LOGIN ] [tty5] [] [0.0.0.0 > ] [2022-10-14T14:19:48,243960+00:00] > [6] [02367] [4 ] [LOGIN ] [tty4] [] [0.0.0.0 > ] [2022-10-14T14:19:48,245313+00:00] > [6] [02366] [3 ] [LOGIN ] [tty3] [] [0.0.0.0 > ] [2022-10-14T14:19:48,246487+00:00] > [6] [02504] [2 ] [LOGIN ] [tty2] [] [0.0.0.0 > ] [2022-10-14T14:22:53,553918+00:00] > [7] [31047] [ts/1] [root] [pts/1 ] [ ] [] > [2022-10-15T13:20:54,474857+00:00] > > Ça semble tout à fait normal, non ? > Oui l'entrée [reboot] semble cohérente. Mais du coup que donne "who -b" sur bookworm désormais ? NB : si nouveau reboot il y a eu encore depuis, merci de redonner le résultat des 2 commandes "who -b" et "utmpdump /run/utmp" histoire qu'on compare la même chose. l0f4r0
Re: Jamais vu ça...
Le 2022-10-15 09:33, l0f...@tuta.io a écrit : Pour ceux qui ont des soucis, que donne : utmpdump /run/utmp ? l0f4r0 Utmp dump of /run/utmp [8] [00233] [si ] [] [] [] [0.0.0.0] [2022-10-14T14:18:56,899429+00:00] [2] [0] [~~ ] [reboot ] [~ ] [] [0.0.0.0] [2022-10-14T14:18:56,937117+00:00] [1] [20019] [~~ ] [runlevel] [~ ] [] [0.0.0.0] [2022-10-14T14:18:56,938127+00:00] [8] [01371] [l3 ] [] [] [] [0.0.0.0] [2022-10-14T14:19:48,233144+00:00] [6] [02371] [8 ] [LOGIN ] [tty8] [] [0.0.0.0] [2022-10-14T14:19:48,240587+00:00] [5] [02372] [9 ] [] [] [] [0.0.0.0] [2022-10-14T14:19:48,241550+00:00] [6] [02370] [7 ] [LOGIN ] [tty7] [] [0.0.0.0] [2022-10-14T14:19:48,242438+00:00] [6] [02369] [6 ] [LOGIN ] [tty6] [] [0.0.0.0] [2022-10-14T14:19:48,243424+00:00] [6] [02368] [5 ] [LOGIN ] [tty5] [] [0.0.0.0] [2022-10-14T14:19:48,243960+00:00] [6] [02367] [4 ] [LOGIN ] [tty4] [] [0.0.0.0] [2022-10-14T14:19:48,245313+00:00] [6] [02366] [3 ] [LOGIN ] [tty3] [] [0.0.0.0] [2022-10-14T14:19:48,246487+00:00] [6] [02504] [2 ] [LOGIN ] [tty2] [] [0.0.0.0] [2022-10-14T14:22:53,553918+00:00] [7] [31047] [ts/1] [root] [pts/1 ] [ ] [] [2022-10-15T13:20:54,474857+00:00] Ça semble tout à fait normal, non ? En tout cas, merci de vous intéresser au problème. (je ne connaissais utmpdump)
Re: Jamais vu ça...
Pour ceux qui ont des soucis, que donne : utmpdump /run/utmp ? l0f4r0
Re: Jamais vu ça...
Le 2022-10-14 09:25, bern a écrit : J'ai rebooté la machine hier : le problème est toujours là. J'ai d'autres machines matériellement très proches avec la même version du système et sur lesquelles le "who -b" est bon. J'ai écrit trop vite : je n'avais pas d'autre machine avec strictement la même configuration. Essais de ce matin : uname -a Linux debian 5.10.0-18-686-pae #1 SMP Debian 5.10.140-1 (2022-09-02) i686 GNU/Linux debian bullseye : tout est ok. dist-upgrade --> bookworm : who -b est mauvais.
Re: Jamais vu ça...
Bonjour. Ne serait ce pas un problème i386 vs amd64 ? Le 14/10/2022 à 09:25, bern a écrit : Le 2022-10-13 19:45, l0f...@tuta.io a écrit : Bernard et Nicolas, Que donne la commande suivante : $ apt policy coreutils l0f4r0 # locale | grep LC_TIME LC_TIME="en_US.UTF-8" # apt policy coreutils coreutils: Installed: 9.1-1 Candidate: 9.1-1 Version table: *** 9.1-1 500 500 http://deb.devuan.org/merged daedalus/main i386 Packages 100 /var/lib/dpkg/status J'avoue, c'est une machine en devuan. Mais c'est bien le paquet debian inchangé. daedalus = bookworm. J'ai rebooté la machine hier : le problème est toujours là. J'ai d'autres machines matériellement très proches avec la même version du système et sur lesquelles le "who -b" est bon. Je commençais à croire à un problème matériel. Mais si Nicolas a le même symptôme, il peut y avoir un bug quelque part.
Re: Jamais vu ça...
Le 2022-10-13 19:45, l0f...@tuta.io a écrit : Bernard et Nicolas, Que donne la commande suivante : $ apt policy coreutils l0f4r0 # locale | grep LC_TIME LC_TIME="en_US.UTF-8" # apt policy coreutils coreutils: Installed: 9.1-1 Candidate: 9.1-1 Version table: *** 9.1-1 500 500 http://deb.devuan.org/merged daedalus/main i386 Packages 100 /var/lib/dpkg/status J'avoue, c'est une machine en devuan. Mais c'est bien le paquet debian inchangé. daedalus = bookworm. J'ai rebooté la machine hier : le problème est toujours là. J'ai d'autres machines matériellement très proches avec la même version du système et sur lesquelles le "who -b" est bon. Je commençais à croire à un problème matériel. Mais si Nicolas a le même symptôme, il peut y avoir un bug quelque part.
Re : Jamais vu ça...
Le 13/10/2022 19:45:42, l0f...@tuta.io a écrit : > Que donne la commande suivante : > $ apt policy coreutils > apt policy coreutils coreutils: Installé : 9.1-1 Candidat : 9.1-1 Table de version : *** 9.1-1 500 500 http://ftp.fr.debian.org/debian unstable/main i386 Packages 100 /var/lib/dpkg/status nicolas patrois : pts noir asocial -- RÉALISME M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ? P : Non... Une carte bleue suffirait...
Re: Jamais vu ça...
Bernard et Nicolas, Que donne la commande suivante : $ apt policy coreutils l0f4r0
Re : Jamais vu ça...
Le 13/10/2022 16:37:00, l0f...@tuta.io a écrit : > Que donne la commande suivante ? > locale | grep LC_TIME J’ai la même blague chez moi : > who -b démarrage système 54840279-01-04 16:06 > locale | grep LC_TIME LC_TIME="fr_FR.UTF-8" nicolas patrois : pts noir asocial -- RÉALISME M : Qu'est-ce qu'il nous faudrait pour qu'on nous considère comme des humains ? Un cerveau plus gros ? P : Non... Une carte bleue suffirait...
Re: Jamais vu ça...
Bonjour, 12 oct. 2022, 11:10 de b...@taranig.net: > Ce matin, j'ai voulu voir depuis combien de jours tourne une de mes machines : > > $ who -b > system boot 119807117-04-11 12:38 > > Comment est-il possible d'obtenir ce résultat ? > Que donne la commande suivante ? locale | grep LC_TIME l0f4r0
Re: Jamais vu ça...
hello, Le 12/10/2022 à 15:05, Haricophile a écrit : Le mercredi 12 octobre 2022 à 12:32 +0200, Bernard Isambert a écrit : Il y a quelques années, j'avais eu droit au bug des 497 jours (2^32 x 1/100°s = 497,.. jours, débordement du compteur de temps et affichage de "top" délirant), mais les fournisseurs d'électricité d'aujourd'hui ne permettent pas de garder une machine aussi longtemps sans coupure... ah ça fait longtemps qu'il n'y avait pas eut un concours d'uptime :) fabricer@sd-113994:~$ uptime -p up 5 years, 12 weeks, 2 hours, 59 minutes en vrai, osef nan, juste pour rigoler. f.
Re: Jamais vu ça...
Le mercredi 12 octobre 2022 à 12:32 +0200, Bernard Isambert a écrit : > Il y a quelques années, j'avais eu droit au bug des 497 jours (2^32 x > 1/100°s = 497,.. jours, débordement du compteur de temps et affichage > de > "top" délirant), mais les fournisseurs d'électricité d'aujourd'hui ne > permettent pas de garder une machine aussi longtemps sans coupure... D'où l'intérêt des alimentations de secours... (ou d'un système autonome genre photovoltaïque), en tout cas sur un serveur.
Re: Jamais vu ça...
Le 12/10/2022 à 12:06, Jean-Pierre Giraud a écrit : Bonjour, et que disent uptime et date ? Amicalement, jipege uptime et date donnent les bons résultats (uptime c'est ce qu'affiche "top" en première ligne). Ça a quand même l'air d'être lié à "who". --- Il y a quelques années, j'avais eu droit au bug des 497 jours (2^32 x 1/100°s = 497,.. jours, débordement du compteur de temps et affichage de "top" délirant), mais les fournisseurs d'électricité d'aujourd'hui ne permettent pas de garder une machine aussi longtemps sans coupure... -- Bernard. 25 ans d'utilisation de Debian. Comme le temps passe...
Re: Jamais vu ça...
Bonjour, Le 12/10/2022 à 11:10, Bernard Isambert a écrit : Ce matin, j'ai voulu voir depuis combien de jours tourne une de mes machines : $ who -b system boot 119807117-04-11 12:38 Comment est-il possible d'obtenir ce résultat ? D'après le kern.log, le dernier boot date du 4 octobre 2022 à 15h51. La première ligne de "top" est d'accord : top - 10:28:49 up 7 days, 18:38, 1 user, load average: 0.00, 0.00, 0.00 Je précise que c'est une machine 32 bits. Ça pourrait être lié. Si quelqu'un a une idée de quelque chose à vérifier avant que je fasse un rapport de bug ? et que disent uptime et date ? Amicalement, jipege
Jamais vu ça...
Ce matin, j'ai voulu voir depuis combien de jours tourne une de mes machines : $ who -b system boot 119807117-04-11 12:38 Comment est-il possible d'obtenir ce résultat ? D'après le kern.log, le dernier boot date du 4 octobre 2022 à 15h51. La première ligne de "top" est d'accord : top - 10:28:49 up 7 days, 18:38, 1 user, load average: 0.00, 0.00, 0.00 Je précise que c'est une machine 32 bits. Ça pourrait être lié. Si quelqu'un a une idée de quelque chose à vérifier avant que je fasse un rapport de bug ? -- Bernard. 25 ans d'utilisation de Debian. Comme le temps passe...
