[journalctl] « -b -1 » ne fonctionne pas (RÉSOLU)

bobo · Message par **bobo** » ven. 11 juil. 2014, 18:28

Lorsque je demande le log du boot précédent (où ma session X a crashé après startx => autre sujet, je collecte les preuves), journalctl me parle d'un boot au 3 mai !! J'ai pourtant fait pas mal de reboots ces derniers temps, preuve en est la dernière colonne.

Code : Tout sélectionner

# journalctl --no-pager -b -1 | head
-- Logs begin at sam. 2014-04-05 14:47:41 CEST, end at ven. 2014-07-11 18:12:50 CEST. --
mai 03 08:00:18 sharu systemd-journal[152]: Runtime journal is using 8.0M (max allowed 298.6M, trying to leave 447.9M free of 2.9G available → current limit 298.6M).
mai 03 08:00:18 sharu systemd-journal[152]: Runtime journal is using 8.0M (max allowed 298.6M, trying to leave 447.9M free of 2.9G available → current limit 298.6M).
mai 03 08:00:18 sharu kernel: Initializing cgroup subsys cpuset
mai 03 08:00:18 sharu kernel: Initializing cgroup subsys cpu
mai 03 08:00:18 sharu kernel: Initializing cgroup subsys cpuacct
mai 03 08:00:18 sharu kernel: Linux version 3.14.2-1-ARCH (nobody@var-lib-archbuild-testing-x86_64-tobias) (gcc version 4.9.0 (GCC) ) #1 SMP PREEMPT Sun Apr 27 11:28:44 CEST 2014
mai 03 08:00:18 sharu kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=e9fd178d-6cef-4848-a288-255c37433476 rw quiet
mai 03 08:00:18 sharu kernel: e820: BIOS-provided physical RAM map:
mai 03 08:00:18 sharu kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable

Code : Tout sélectionner

# journalctl --no-pager -r | grep "Linux version" | head
juil. 11 18:05:32 sharu kernel: Linux version 3.14.12-1-lts (nobody@home-andyrtr-arch64-chroots-testing-x86_64-andyrtr) (gcc version 4.9.0 20140604 (prerelease) (GCC) ) #1 SMP Wed Jul 9 20:54:12 CEST 2014
juil. 11 18:03:19 sharu kernel: Linux version 3.15.5-1-ARCH (nobody@var-lib-archbuild-testing-x86_64-tobias) (gcc version 4.9.0 20140604 (prerelease) (GCC) ) #1 SMP PREEMPT Thu Jul 10 07:08:50 CEST 2014
juil. 06 19:17:46 sharu kernel: Linux version 3.15.3-1-ARCH (nobody@var-lib-archbuild-testing-x86_64-tobias) (gcc version 4.9.0 20140604 (prerelease) (GCC) ) #1 SMP PREEMPT Tue Jul 1 07:32:45 CEST 2014
juil. 06 15:54:53 sharu kernel: Linux version 3.15.3-1-ARCH (nobody@var-lib-archbuild-testing-x86_64-tobias) (gcc version 4.9.0 20140604 (prerelease) (GCC) ) #1 SMP PREEMPT Tue Jul 1 07:32:45 CEST 2014
juil. 06 15:23:40 sharu kernel: Linux version 3.15.3-1-ARCH (nobody@var-lib-archbuild-testing-x86_64-tobias) (gcc version 4.9.0 20140604 (prerelease) (GCC) ) #1 SMP PREEMPT Tue Jul 1 07:32:45 CEST 2014
juil. 06 15:14:00 sharu kernel: Linux version 3.15.3-1-ARCH (nobody@var-lib-archbuild-testing-x86_64-tobias) (gcc version 4.9.0 20140604 (prerelease) (GCC) ) #1 SMP PREEMPT Tue Jul 1 07:32:45 CEST 2014
juil. 06 14:45:04 sharu kernel: Linux version 3.15.3-1-ARCH (nobody@var-lib-archbuild-testing-x86_64-tobias) (gcc version 4.9.0 20140604 (prerelease) (GCC) ) #1 SMP PREEMPT Tue Jul 1 07:32:45 CEST 2014
juil. 06 14:25:31 sharu kernel: Linux version 3.15.3-1-ARCH (nobody@var-lib-archbuild-testing-x86_64-tobias) (gcc version 4.9.0 20140604 (prerelease) (GCC) ) #1 SMP PREEMPT Tue Jul 1 07:32:45 CEST 2014
juil. 06 13:42:09 sharu kernel: Linux version 3.15.3-1-ARCH (nobody@var-lib-archbuild-testing-x86_64-tobias) (gcc version 4.9.0 20140604 (prerelease) (GCC) ) #1 SMP PREEMPT Tue Jul 1 07:32:45 CEST 2014
juil. 03 00:27:55 sharu kernel: Linux version 3.15.2-1-ARCH (nobody@var-lib-archbuild-testing-x86_64-tobias) (gcc version 4.9.0 20140604 (prerelease) (GCC) ) #1 SMP PREEMPT Fri Jun 27 07:41:19 CEST 2014

journalctl me renverrait-il le dernier boot en noyau 3-14 (parce que le noyau de la session en cours est un 3.14-lts ?

bobo · Message par **bobo** » ven. 11 juil. 2014, 18:36

Le pompon, lorsque la liste des boots est demandée :

Code : Tout sélectionner

# journalctl --list-boots | tail
 -9 7e7e610d070941f6b6cfcab76a25ae45 jeu. 2014-07-03 00:27:55 CEST—dim. 2014-07-06 13:41:43 CEST
 -8 01bf9a0682e7423d90def813b69fe6b2 dim. 2014-07-06 13:42:09 CEST—dim. 2014-07-06 14:22:43 CEST
 -7 d0f2e5a81e084418875417a7e5cea9d1 dim. 2014-07-06 14:25:31 CEST—dim. 2014-07-06 14:44:20 CEST
 -6 5510889b7d764296a49c08748dcd3ab5 dim. 2014-07-06 14:45:04 CEST—dim. 2014-07-06 15:13:22 CEST
 -5 2191355762e84695b62c105c7e15fa28 dim. 2014-07-06 15:14:00 CEST—dim. 2014-07-06 15:22:59 CEST
 -4 1b35083785fe4bdf903dd5c8d43f2675 dim. 2014-07-06 15:23:40 CEST—dim. 2014-07-06 15:54:11 CEST
 -3 2ef584e1ef2942919f841c715b8fb5ac dim. 2014-07-06 15:54:53 CEST—dim. 2014-07-06 16:29:34 CEST
 -2 3731e33f606541938637487954d5ef04 dim. 2014-07-06 19:17:46 CEST—ven. 2014-07-11 18:02:51 CEST
 -1 6acb62ca7ae24a89ad5fd245b57a1cea ven. 2014-07-11 18:03:19 CEST—ven. 2014-07-11 18:04:38 CEST
  0 11280510157b48278831a5849a35d21e ven. 2014-07-11 18:05:32 CEST—ven. 2014-07-11 18:31:37 CEST

Code : Tout sélectionner

# journalctl --list-boots | grep 2014-05-03
-37 c9dc7e2eb1a84258a5e9dcc0597b536f ven. 2014-05-02 18:47:21 CEST—sam. 2014-05-03 07:50:51 CEST
-36 b835e48a2c3d49fd9d8ddea96c29dd55 sam. 2014-05-03 08:00:18 CEST—sam. 2014-05-03 11:13:27 CEST
-35 531d7341935f44c4a51a5feed1a60e94 sam. 2014-05-03 12:24:37 CEST—dim. 2014-05-04 13:26:26 CEST

Est-ce un bug de journalctl ou dois-je lire le manuel ?

Moviuro · Message par **Moviuro** » ven. 11 juil. 2014, 18:40

bobo a écrit :Lorsque je demande le log du boot précédent (où ma session X a crashé après startx => autre sujet, je collecte les preuves), journalctl me parle d'un boot au 3 mai !! J'ai pourtant fait pas mal de reboots ces derniers temps, preuve en est la dernière colonne.

journalctl -b

bobo · Message par **bobo** » ven. 11 juil. 2014, 18:45

Reboot en 3-15-5-1, ce coup-ci X n'a pas crashé au startx… (ouf)

Sortie de "journalctl -b" en deuxième ligne. journalctl n'en démord pas, pour l'option "-b" le boot "-1" a eu lieu le 3 mai à 8h et des brouettes ! Notez qu'il n'y a pas eu d'incrémentation depuis tout à l'heure.

Code : Tout sélectionner

18:38 root@ bobo% journalctl -b -1 | head
-- Logs begin at sam. 2014-04-05 14:47:41 CEST, end at ven. 2014-07-11 18:38:36 CEST. --
mai 03 08:00:18 sharu systemd-journal[152]: Runtime journal is using 8.0M (max allowed 298.6M, trying to leave 447.9M free of 2.9G available → current limit 298.6M).
mai 03 08:00:18 sharu systemd-journal[152]: Runtime journal is using 8.0M (max allowed 298.6M, trying to leave 447.9M free of 2.9G available → current limit 298.6M).
mai 03 08:00:18 sharu kernel: Initializing cgroup subsys cpuset
mai 03 08:00:18 sharu kernel: Initializing cgroup subsys cpu
mai 03 08:00:18 sharu kernel: Initializing cgroup subsys cpuacct
mai 03 08:00:18 sharu kernel: Linux version 3.14.2-1-ARCH (nobody@var-lib-archbuild-testing-x86_64-tobias) (gcc version 4.9.0 (GCC) ) #1 SMP PREEMPT Sun Apr 27 11:28:44 CEST 2014
mai 03 08:00:18 sharu kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=e9fd178d-6cef-4848-a288-255c37433476 rw quiet
mai 03 08:00:18 sharu kernel: e820: BIOS-provided physical RAM map:
mai 03 08:00:18 sharu kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable

Code : Tout sélectionner

18:38 root@ bobo% journalctl -b | head
-- Logs begin at sam. 2014-04-05 14:47:41 CEST, end at ven. 2014-07-11 18:38:36 CEST. --
juil. 11 18:37:48 sharu systemd-journal[151]: Runtime journal is using 8.0M (max allowed 298.6M, trying to leave 447.9M free of 2.9G available → current limit 298.6M).
juil. 11 18:37:48 sharu systemd-journal[151]: Runtime journal is using 8.0M (max allowed 298.6M, trying to leave 447.9M free of 2.9G available → current limit 298.6M).
juil. 11 18:37:48 sharu kernel: Initializing cgroup subsys cpuset
juil. 11 18:37:48 sharu kernel: Initializing cgroup subsys cpu
juil. 11 18:37:48 sharu kernel: Initializing cgroup subsys cpuacct
juil. 11 18:37:48 sharu kernel: Linux version 3.15.5-1-ARCH (nobody@var-lib-archbuild-testing-x86_64-tobias) (gcc version 4.9.0 20140604 (prerelease) (GCC) ) #1 SMP PREEMPT Thu Jul 10 07:08:50 CEST 2014
juil. 11 18:37:48 sharu kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=e9fd178d-6cef-4848-a288-255c37433476 rw quiet
juil. 11 18:37:48 sharu kernel: e820: BIOS-provided physical RAM map:
juil. 11 18:37:48 sharu kernel: BIOS-e820: [mem 0x0000000000000000-0x000000000009f7ff] usable

Code : Tout sélectionner

18:38 root@ bobo% journalctl -r | grep "Linux version" | head
juil. 11 18:37:48 sharu kernel: Linux version 3.15.5-1-ARCH (nobody@var-lib-archbuild-testing-x86_64-tobias) (gcc version 4.9.0 20140604 (prerelease) (GCC) ) #1 SMP PREEMPT Thu Jul 10 07:08:50 CEST 2014
juil. 11 18:05:32 sharu kernel: Linux version 3.14.12-1-lts (nobody@home-andyrtr-arch64-chroots-testing-x86_64-andyrtr) (gcc version 4.9.0 20140604 (prerelease) (GCC) ) #1 SMP Wed Jul 9 20:54:12 CEST 2014
juil. 11 18:03:19 sharu kernel: Linux version 3.15.5-1-ARCH (nobody@var-lib-archbuild-testing-x86_64-tobias) (gcc version 4.9.0 20140604 (prerelease) (GCC) ) #1 SMP PREEMPT Thu Jul 10 07:08:50 CEST 2014
juil. 06 19:17:46 sharu kernel: Linux version 3.15.3-1-ARCH (nobody@var-lib-archbuild-testing-x86_64-tobias) (gcc version 4.9.0 20140604 (prerelease) (GCC) ) #1 SMP PREEMPT Tue Jul 1 07:32:45 CEST 2014
juil. 06 15:54:53 sharu kernel: Linux version 3.15.3-1-ARCH (nobody@var-lib-archbuild-testing-x86_64-tobias) (gcc version 4.9.0 20140604 (prerelease) (GCC) ) #1 SMP PREEMPT Tue Jul 1 07:32:45 CEST 2014
juil. 06 15:23:40 sharu kernel: Linux version 3.15.3-1-ARCH (nobody@var-lib-archbuild-testing-x86_64-tobias) (gcc version 4.9.0 20140604 (prerelease) (GCC) ) #1 SMP PREEMPT Tue Jul 1 07:32:45 CEST 2014
juil. 06 15:14:00 sharu kernel: Linux version 3.15.3-1-ARCH (nobody@var-lib-archbuild-testing-x86_64-tobias) (gcc version 4.9.0 20140604 (prerelease) (GCC) ) #1 SMP PREEMPT Tue Jul 1 07:32:45 CEST 2014
juil. 06 14:45:04 sharu kernel: Linux version 3.15.3-1-ARCH (nobody@var-lib-archbuild-testing-x86_64-tobias) (gcc version 4.9.0 20140604 (prerelease) (GCC) ) #1 SMP PREEMPT Tue Jul 1 07:32:45 CEST 2014
juil. 06 14:25:31 sharu kernel: Linux version 3.15.3-1-ARCH (nobody@var-lib-archbuild-testing-x86_64-tobias) (gcc version 4.9.0 20140604 (prerelease) (GCC) ) #1 SMP PREEMPT Tue Jul 1 07:32:45 CEST 2014
juil. 06 13:42:09 sharu kernel: Linux version 3.15.3-1-ARCH (nobody@var-lib-archbuild-testing-x86_64-tobias) (gcc version 4.9.0 20140604 (prerelease) (GCC) ) #1 SMP PREEMPT Tue Jul 1 07:32:45 CEST 2014

Message par **benjarobin** » ven. 11 juil. 2014, 19:17

Je me suis permit d'éditer tes messages pour les rendre plus lisibles, car on ne vois pas forcément qu'il y a plusieurs sorties...

Sinon je n'ai rien compris à ton souci... Je ne vois rien d'anormal dans les sorties que tu as donné.
Ou tu vois qu'il parle de "boot au 3 mai" ?

Le pompon, lorsque la liste des boots est demandée :

Quel est le souci ?

bobo · Message par **bobo** » ven. 11 juil. 2014, 19:38

benjarobin a écrit :Sinon je n'ai rien compris à ton souci... Je ne vois rien d'anormal dans les sorties que tu as donné.
Ou tu vois qu'il parle de "boot au 3 mai" ?

Dans mon dernier message il y a en effet 3 commandes (que tu as séparées), dans l'ordre :
— "journalctl -b -1 | head" : l'option « -b -1 » est sensée donner le dernier journal du boot précédent => ce message renvoie une date de log au 3 mai (pour moi là ça déconne)
— "journalctl -b | head" : l'option « -b » est sensée donner le journal du boot en cours, la sortie de cette commande n'est pas anormale
— "journalctl -r | grep "Linux version" | head" : l'option « -r » parcourt le journal en retournant dans le passé, je chope les 10 premières lignes (en « Linux version » qui ont lieu au début de chaque boot) qui donnent les dates des 10 boots précédents

Code : Tout sélectionner

# journalctl --list-boots | tail -n 45
-44 8d50f666ee664c6f81886f83104d772b mar. 2014-04-29 23:09:41 CEST—mar. 2014-04-29 23:18:56 CEST
-43 3aa8a4987f714c7393c3e718c7bceb57 mar. 2014-04-29 23:20:54 CEST—mer. 2014-04-30 10:16:49 CEST
-42 4f3b44f3fd08456fbcf8d69f161e38a1 mer. 2014-04-30 10:47:54 CEST—mer. 2014-04-30 10:52:17 CEST
-41 d3b39ffa16d7486e8405bb68b6b60315 jeu. 2014-05-01 08:13:09 CEST—jeu. 2014-05-01 13:05:47 CEST
-40 8ce9bda090064f289ea72613a80803ac jeu. 2014-05-01 13:06:14 CEST—jeu. 2014-05-01 18:15:26 CEST
-39 0e2fa4b8a6ab417894fcc8525e00e8c4 jeu. 2014-05-01 18:15:51 CEST—ven. 2014-05-02 18:46:56 CEST
-38 c9dc7e2eb1a84258a5e9dcc0597b536f ven. 2014-05-02 18:47:21 CEST—sam. 2014-05-03 07:50:51 CEST
-37 b835e48a2c3d49fd9d8ddea96c29dd55 sam. 2014-05-03 08:00:18 CEST—sam. 2014-05-03 11:13:27 CEST   <===============
-36 531d7341935f44c4a51a5feed1a60e94 sam. 2014-05-03 12:24:37 CEST—dim. 2014-05-04 13:26:26 CEST
-35 de1c425d08b643fab998773ebc642857 dim. 2014-05-04 13:27:25 CEST—dim. 2014-05-04 13:42:29 CEST
-34 be1aa06ecdaa4254a5f2f103aec279f1 dim. 2014-05-04 14:19:22 CEST—mer. 2014-05-07 23:18:59 CEST
-33 6af01f9758d745ce80a28b966adf1795 jeu. 2014-05-08 18:11:24 CEST—sam. 2014-05-10 12:11:33 CEST
-32 4d61ad418bbe478ab8e15a44f2dbc82a sam. 2014-05-10 12:11:57 CEST—dim. 2014-05-11 12:30:55 CEST
-31 008bf7ae356747eb9fe481381d3a4fc3 dim. 2014-05-11 12:31:18 CEST—lun. 2014-05-12 19:04:21 CEST
-30 8fe76327ba3647a085095f9d1d38f182 lun. 2014-05-12 19:05:06 CEST—mar. 2014-05-13 21:48:30 CEST
-29 125b572b16c0498a83d50f53366247a0 mar. 2014-05-13 21:48:52 CEST—jeu. 2014-05-15 23:19:20 CEST
-28 fa7363aa654d430fa93262441619327f jeu. 2014-05-15 23:19:44 CEST—ven. 2014-05-16 22:01:25 CEST
-27 2a23715f1e7949df97d6144db82523da sam. 2014-05-17 05:26:55 CEST—sam. 2014-05-17 23:12:15 CEST
-26 906283dffee543f6b96dabeed426736d dim. 2014-05-18 09:13:44 CEST—dim. 2014-05-18 22:31:57 CEST
-25 895335c9c0654782bcb67d4105e82e2a lun. 2014-05-19 19:45:31 CEST—lun. 2014-05-19 22:04:51 CEST
-24 6bc192a5956543ab934a76aebcee8018 mar. 2014-05-20 18:30:35 CEST—jeu. 2014-05-22 22:42:27 CEST
-23 b28bcf86e08d4ec09131f9bda8f59fac ven. 2014-05-23 18:47:26 CEST—sam. 2014-05-24 23:15:59 CEST
-22 f9c5128a8eab42b3b6246882a6e151f7 sam. 2014-05-24 23:16:22 CEST—sam. 2014-05-31 23:22:12 CEST
-21 5b4cb4225d4d4f4984ad2477a27504ed dim. 2014-06-01 09:11:19 CEST—mer. 2014-06-04 00:29:53 CEST
-20 244c877aae7f48009598afaa257604d4 mer. 2014-06-04 01:03:16 CEST—mer. 2014-06-04 19:33:27 CEST
-19 06b5163311c040d4a9b1108971e32621 mer. 2014-06-04 19:34:59 CEST—lun. 2014-06-09 14:51:50 CEST
-18 f7e8e8d6443e47fbaf9e3e550f1d0f45 lun. 2014-06-09 14:52:45 CEST—mer. 2014-06-11 19:59:18 CEST
-17 a3f4a04aba2349feab634b403b3cf5bf mer. 2014-06-11 20:00:26 CEST—sam. 2014-06-14 20:38:23 CEST
-16 166b892736ae448aabe30390559c0a02 sam. 2014-06-14 20:39:39 CEST—lun. 2014-06-16 20:40:39 CEST
-15 d356dbe38fd941f5999d517702ebf314 lun. 2014-06-16 20:42:51 CEST—mer. 2014-06-18 23:22:14 CEST
-14 a1d30a377b1642768cceefb742019bf8 mer. 2014-06-18 23:45:21 CEST—jeu. 2014-06-19 00:08:41 CEST
-13 5e6f70b87ab74454ace0519fb0f2d641 jeu. 2014-06-19 20:06:17 CEST—jeu. 2014-06-19 23:42:47 CEST
-12 e2003b8230324cabaed2af6d24ed29a9 ven. 2014-06-20 19:05:51 CEST—lun. 2014-06-23 19:26:50 CEST
-11 a87d287ede6d4a5599bc778c942f174c lun. 2014-06-23 19:27:38 CEST—jeu. 2014-07-03 00:27:30 CEST
-10 7e7e610d070941f6b6cfcab76a25ae45 jeu. 2014-07-03 00:28:20 CEST—dim. 2014-07-06 13:41:42 CEST
 -9 01bf9a0682e7423d90def813b69fe6b2 dim. 2014-07-06 13:42:28 CEST—dim. 2014-07-06 14:22:42 CEST
 -8 d0f2e5a81e084418875417a7e5cea9d1 dim. 2014-07-06 14:25:52 CEST—dim. 2014-07-06 14:44:19 CEST
 -7 5510889b7d764296a49c08748dcd3ab5 dim. 2014-07-06 14:45:25 CEST—dim. 2014-07-06 15:13:21 CEST
 -6 2191355762e84695b62c105c7e15fa28 dim. 2014-07-06 15:14:22 CEST—dim. 2014-07-06 15:22:57 CEST
 -5 1b35083785fe4bdf903dd5c8d43f2675 dim. 2014-07-06 15:24:02 CEST—dim. 2014-07-06 15:54:03 CEST
 -4 2ef584e1ef2942919f841c715b8fb5ac dim. 2014-07-06 16:05:54 CEST—dim. 2014-07-06 16:29:27 CEST
 -3 3731e33f606541938637487954d5ef04 dim. 2014-07-06 19:23:44 CEST—ven. 2014-07-11 18:02:15 CEST
 -2 6acb62ca7ae24a89ad5fd245b57a1cea ven. 2014-07-11 18:04:04 CEST—ven. 2014-07-11 18:04:22 CEST
 -1 11280510157b48278831a5849a35d21e ven. 2014-07-11 18:08:08 CEST—ven. 2014-07-11 18:36:55 CEST   <===============
  0 dd601ac217734c2fad7ebd984711c58d ven. 2014-07-11 18:38:12 CEST—ven. 2014-07-11 18:52:44 CEST

Une autre approche résidant dans l'option « --list-boots » (commande ci-dessus), on voit que le boot « -1 » est sensé avoir eu lieu aujourd'hui à 18h08, pas le 3 mai à 8h00

J'espère que c'est plus clair ainsi.

Message par **benjarobin** » ven. 11 juil. 2014, 19:43

Non, c'est très clair, c'est moi qui était vraiment pas réveillé... On va dire que c'est la fatigue de fin de semaine. De plus je reproduit le souci...

C'est même pire chez moi (Le PC est démarré/arrêté tous les jours ou presque) :

Code : Tout sélectionner

# journalctl --list-boots | tail -3
  -2 643f8b55afc046ba9eb66282eb1ef2c1 jeu. 2014-06-26 18:57:57 CEST—ven. 2014-06-27 01:43:50 CEST
  -1 66d84ee98e4c48bf814b5b70ecf2885a ven. 2014-06-27 10:54:32 CEST—ven. 2014-06-27 15:39:22 CEST
   0 87ecbfc038df4d7086022e3311b28349 ven. 2014-06-27 15:39:50 CEST—ven. 2014-06-27 15:58:03 CEST

Code : Tout sélectionner

# journalctl -b | head -4
-- Logs begin at mar. 2014-02-11 01:32:41 CET, end at ven. 2014-07-11 19:44:00 CEST. --
juil. 11 19:09:49 benjarobin-fixe systemd-journal[202]: Runtime journal is using 8.0M (max allowed 151.2M, trying to leave 226.8M free of 1.4G available → current limit 151.2M).
juil. 11 19:09:49 benjarobin-fixe systemd-journal[202]: Runtime journal is using 8.0M (max allowed 151.2M, trying to leave 226.8M free of 1.4G available → current limit 151.2M).
juil. 11 19:09:49 benjarobin-fixe kernel: Initializing cgroup subsys cpuset

Code : Tout sélectionner

# journalctl -b 87ecbfc038df4d7086022e3311b28349 | head -4
-- Logs begin at mar. 2014-02-11 01:32:41 CET, end at ven. 2014-07-11 19:44:00 CEST. --
juin 27 15:39:50 benjarobin-fixe systemd-journal[201]: Runtime journal is using 8.0M (max allowed 151.2M, trying to leave 226.8M free of 1.4G available → current limit 151.2M).
juin 27 15:39:50 benjarobin-fixe systemd-journal[201]: Runtime journal is using 8.0M (max allowed 151.2M, trying to leave 226.8M free of 1.4G available → current limit 151.2M).
juin 27 15:39:50 benjarobin-fixe kernel: Initializing cgroup subsys cpuset

Code : Tout sélectionner

# journalctl -b -1 | head -4
-- Logs begin at mar. 2014-02-11 01:32:41 CET, end at ven. 2014-07-11 19:44:00 CEST. --
juin 27 10:54:32 benjarobin-fixe systemd-journal[203]: Runtime journal is using 8.0M (max allowed 151.2M, trying to leave 226.8M free of 1.4G available → current limit 151.2M).
juin 27 10:54:32 benjarobin-fixe systemd-journal[203]: Runtime journal is using 8.0M (max allowed 151.2M, trying to leave 226.8M free of 1.4G available → current limit 151.2M).
juin 27 10:54:32 benjarobin-fixe kernel: Initializing cgroup subsys cpuset

Code : Tout sélectionner

# journalctl -b -2 | head -4
-- Logs begin at mar. 2014-02-11 01:32:41 CET, end at ven. 2014-07-11 19:44:00 CEST. --
juin 26 18:57:57 benjarobin-fixe systemd-journal[201]: Runtime journal is using 8.0M (max allowed 151.2M, trying to leave 226.8M free of 1.4G available → current limit 151.2M).
juin 26 18:57:57 benjarobin-fixe systemd-journal[201]: Runtime journal is using 8.0M (max allowed 151.2M, trying to leave 226.8M free of 1.4G available → current limit 151.2M).
juin 26 18:57:57 benjarobin-fixe kernel: Initializing cgroup subsys cpuset

Les lignes ont été volontairement tronquées dans la sortie suivante car n'apportant aucune information utile

Code : Tout sélectionner

# journalctl -r | grep "Linux version" | head -40
juil. 11 19:09:49 benjarobin-fixe kernel: Linux version 3.15.1-1-ARCH
juil. 10 19:21:48 benjarobin-fixe kernel: Linux version 3.15.1-1-ARCH
juil. 09 22:26:18 benjarobin-fixe kernel: Linux version 3.15.1-1-ARCH
juil. 08 19:17:48 benjarobin-fixe kernel: Linux version 3.15.1-1-ARCH
juil. 07 19:12:04 benjarobin-fixe kernel: Linux version 3.15.1-1-ARCH
juil. 06 19:27:12 benjarobin-fixe kernel: Linux version 3.15.1-1-ARCH
juil. 03 21:07:56 benjarobin-fixe kernel: Linux version 3.15.1-1-ARCH
juil. 03 20:12:56 benjarobin-fixe kernel: Linux version 3.15.1-1-ARCH
juil. 02 13:25:07 benjarobin-fixe kernel: Linux version 3.15.1-1-ARCH
juin 29 12:27:07 benjarobin-fixe kernel: Linux version 3.15.1-1-ARCH
juin 28 18:51:04 benjarobin-fixe kernel: Linux version 3.15.1-1-ARCH
juin 28 13:31:18 benjarobin-fixe kernel: Linux version 3.15.1-1-ARCH
juin 27 15:58:31 benjarobin-fixe kernel: Linux version 3.15.1-1-ARCH
juin 27 15:39:50 benjarobin-fixe kernel: Linux version 3.15.1-1-ARCH
juin 27 10:54:32 benjarobin-fixe kernel: Linux version 3.15.1-1-ARCH
juin 26 18:57:57 benjarobin-fixe kernel: Linux version 3.15.1-1-ARCH
juin 26 18:50:03 benjarobin-fixe kernel: Linux version 3.15.1-1-ARCH
juin 26 11:58:36 benjarobin-fixe kernel: Linux version 3.15.1-1-ARCH
juin 25 10:54:50 benjarobin-fixe kernel: Linux version 3.15.1-1-ARCH
juin 24 17:51:33 benjarobin-fixe kernel: Linux version 3.15.1-1-ARCH
juin 24 10:45:19 benjarobin-fixe kernel: Linux version 3.15.1-1-ARCH

De plus aucune erreur en sortie de :

Code : Tout sélectionner

journalctl --verify

Mise à jour de systemd le 24 juin :

Code : Tout sélectionner

grep systemd /var/log/pacman.log| tail
[2014-06-09 23:16] [PACMAN] upgraded systemd (213-5 -> 213-6)
[2014-06-09 23:16] [PACMAN] upgraded systemd-sysvcompat (213-5 -> 213-6)
[2014-06-10 22:14] [ALPM-SCRIPTLET] => copy the service to '/etc/systemd/system/', 
[2014-06-11 22:43] [PACMAN] upgraded libsystemd (213-6 -> 213-9)
[2014-06-11 22:44] [PACMAN] upgraded systemd (213-6 -> 213-9)
[2014-06-11 22:44] [PACMAN] upgraded systemd-sysvcompat (213-6 -> 213-9)
[2014-06-24 00:16] [PACMAN] upgraded libsystemd (213-9 -> 214-2)
[2014-06-24 00:16] [ALPM-SCRIPTLET]        "kernel.core_pattern=|/usr/lib/systemd/systemd-coredump %p %u %g %s %t %e"
[2014-06-24 00:16] [PACMAN] upgraded systemd (213-9 -> 214-2)
[2014-06-24 00:16] [PACMAN] upgraded systemd-sysvcompat (213-9 -> 214-2)

bobo · Message par **bobo** » ven. 11 juil. 2014, 20:17

Donc le soucis a l'air plus grave chez toi

Moi, j'ai seulement « journalctl -b -1 » qui déraille.

Toi, tu as « journalctl -b -1 » qui déraille
+ « journalctl --list-boots » qui a perdu le fil de tes boots depuis fin juin
(alors que les logs sont là : la preuve par "journalctl -r | grep 'Linux version'")

Édit :
celà dit,
ton « journalctl -b -1 » correspond cependant à ton entrée « -1 » de « journalctl --list-boots »
alors que
mon « journalctl -b -1 » correspond correspond à mon entrée « -37 » de « journalctl --list-boots » ( « -36 » du boot précédent — il n'y a pas d'incrémentation au reboot)

Je ne sais pas qui a la situation la plus bizarre, mais nous avons bien des symptômes semblables, mais différents.

bobo · Message par **bobo** » ven. 11 juil. 2014, 21:31

Je viens de jouer un peu avec l'option --headers de journalctl

Code : Tout sélectionner

journalctl -h | grep header
     --header              Show journal header information

Une piste potentielle

Je pense avoir trouvé une piste qui correspond à mon incohérence entre « -b -1 » et « --list-boots ». Regardons les dates des fichiers headers :

Code : Tout sélectionner

journalctl --header  | grep -e "File" -e "Realtime" | grep -B 3 "Tail.*2014-05"
File Path: /var/log/journal/79b720b9fadd4cb4aeb16676e31ee9f2/system@0004f8914dad8fcf-bda1cfbb28a6b9fc.journal~
File ID: 97137a9a3eb0405dad5830ddca106ee5
Head Realtime Timestamp: lun. 2014-04-21 18:56:01 CEST
Tail Realtime Timestamp: dim. 2014-05-04 13:26:26 CEST
--
File Path: /var/log/journal/79b720b9fadd4cb4aeb16676e31ee9f2/user-1000@0004f8914e54064f-492a38988cbea04c.journal~
File ID: 4e94ea0d004f42f5b5bb872df54a687a
Head Realtime Timestamp: lun. 2014-04-21 18:56:04 CEST
Tail Realtime Timestamp: dim. 2014-05-04 13:26:04 CEST

Code : Tout sélectionner

journalctl --header  | grep -e "File" -e "Realtime" | grep -B 2 -A 1 "Head.*2014-05"
File Path: /var/log/journal/79b720b9fadd4cb4aeb16676e31ee9f2/system@41347f83484a4ee480e66881c86d947f-0000000000000001-0004f8914c939aef.journal
File ID: 41347f83484a4ee480e66881c86d947f
Head Realtime Timestamp: dim. 2014-05-04 13:27:25 CEST
Tail Realtime Timestamp: lun. 2014-06-02 18:25:22 CEST
--
File Path: /var/log/journal/79b720b9fadd4cb4aeb16676e31ee9f2/user-1000@faedbb0b87334b0e91bcec48468dc0dc-00000000000003e7-0004f8914e551f4b.journal
File ID: faedbb0b87334b0e91bcec48468dc0dc
Head Realtime Timestamp: dim. 2014-05-04 13:27:54 CEST
Tail Realtime Timestamp: lun. 2014-06-02 18:19:16 CEST

Un jeu de fichiers system&user qui va du 2014-04-21 au 2014-05-04, un autre qui va du 2014-05-04 au 2014-06-02. Replongeons nous dans les boots listés par « --list-boots » (voir ci-dessous). Le changement de couple de fichier system&user se produit le 2014-05-04 entre 13h26:26 et 13h27:25. Le boot « -35 » a lieu à 13h27:25 écrivant vraisemblablement les premières lignes du nouveau couple de fichier system&user.

Code : Tout sélectionner

# journalctl --list-boots | grep -B 3 "2014-05-04"
-39 0e2fa4b8a6ab417894fcc8525e00e8c4 jeu. 2014-05-01 18:15:51 CEST—ven. 2014-05-02 18:46:56 CEST
-38 c9dc7e2eb1a84258a5e9dcc0597b536f ven. 2014-05-02 18:47:21 CEST—sam. 2014-05-03 07:50:51 CEST
-37 b835e48a2c3d49fd9d8ddea96c29dd55 sam. 2014-05-03 08:00:18 CEST—sam. 2014-05-03 11:13:27 CEST
-36 531d7341935f44c4a51a5feed1a60e94 sam. 2014-05-03 12:24:37 CEST—dim. 2014-05-04 13:26:26 CEST
-35 de1c425d08b643fab998773ebc642857 dim. 2014-05-04 13:27:25 CEST—dim. 2014-05-04 13:42:29 CEST
-34 be1aa06ecdaa4254a5f2f103aec279f1 dim. 2014-05-04 14:19:22 CEST—mer. 2014-05-07 23:18:59 CEST

Analyse déductive

Si les observations ci-dessus sont fondées, s'en suit une série de déductions logiques :
— boot « -36 » est donc le dernier boot de jeu de fichiers précédent
— si journalctl est coincé pour une raison ou une autre sur ce jeu de fichiers, boot « -36 » est le dernier boot en cours…
— si journalctl est paumé de la sorte, le boot « -37 » du 3 mai à 8h est considéré boot « -1 »

Ça colle avec le fait que ça n'incrémente pas ! Observation faite suite à un reboot entre le début et la fin de ce fil.

Message par **benjarobin** » ven. 11 juil. 2014, 21:34

Voir le bug ici : https://bugs.freedesktop.org/show_bug.cgi?id=79380

bobo · Message par **bobo** » ven. 11 juil. 2014, 21:47

Belle trouvaille !

Code : Tout sélectionner

# journalctl -F _BOOT_ID | wc -l
84

Code : Tout sélectionner

# journalctl --list-boots | wc -l
84

Je ne reproduis pas les observations du rapporteur de bug…

oui! mon « --list-boots » est à jour : normal que j'ai le même nombre de boots

En revanche de ton côté, tu dois reproduire le comportement déjà rapporté.

Code : Tout sélectionner

# journalctl --list-boots | tail -n 4
 -3 3731e33f606541938637487954d5ef04 dim. 2014-07-06 19:17:46 CEST—ven. 2014-07-11 18:02:51 CEST
 -2 6acb62ca7ae24a89ad5fd245b57a1cea ven. 2014-07-11 18:03:19 CEST—ven. 2014-07-11 18:04:38 CEST
 -1 11280510157b48278831a5849a35d21e ven. 2014-07-11 18:05:32 CEST—ven. 2014-07-11 18:36:56 CEST
  0 dd601ac217734c2fad7ebd984711c58d ven. 2014-07-11 18:37:48 CEST—ven. 2014-07-11 21:39:54 CEST

Message par **benjarobin** » ven. 11 juil. 2014, 21:56

Oui, de mon coté "journalctl -F _BOOT_ID" et "journalctl --list-boots" diffèrent en nombre de ligne. J'ai ajouté les informations au bug (les même qu'ici ou presque)

bobo · Message par **bobo** » ven. 11 juil. 2014, 22:03

Je me crée un compte bugzilla. Je viens de réaliser avec tes données de rapport de bug, qu'il faut que je regarde --verify. Chez moi la vérification de journalctl renvoie des trucs louches. S'il faut, il y a moyen de réparer et du coup ce serait boulet de soumettre un bug.

Code : Tout sélectionner

# journalctl --verify
38f960: unused data (entry_offset==0)░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░   0%
38f9f8: unused data (entry_offset==0)
38fa88: unused data (entry_offset==0)
38fb18: unused data (entry_offset==0)
38fba0: unused data (entry_offset==0)
38fc30: unused data (entry_offset==0)
38fcc0: unused data (entry_offset==0)
38fd50: unused data (entry_offset==0)
38fde8: unused data (entry_offset==0)
38fe78: unused data (entry_offset==0)
38ff20: unused data (entry_offset==0)
38ffc8: unused data (entry_offset==0)
390048: unused data (entry_offset==0)
e77ec8: unused data (entry_offset==0)██░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  45%
e77f20: unused data (entry_offset==0)
e77f78: unused data (entry_offset==0)
e77fd8: unused data (entry_offset==0)
e78040: unused data (entry_offset==0)
e780a8: unused data (entry_offset==0)
e78110: unused data (entry_offset==0)
38f960: unused data (entry_offset==0)░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░   0%
38f9f8: unused data (entry_offset==0)
38fa88: unused data (entry_offset==0)
38fb18: unused data (entry_offset==0)
38fba0: unused data (entry_offset==0)
38fc30: unused data (entry_offset==0)
38fcc8: unused data (entry_offset==0)
38fd58: unused data (entry_offset==0)
38fdf8: unused data (entry_offset==0)
38fe98: unused data (entry_offset==0)
38ff40: unused data (entry_offset==0)
390068: unused data (entry_offset==0)
f8dc68: unused data (entry_offset==0)░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  41%
f8dd00: unused data (entry_offset==0)
f8dd90: unused data (entry_offset==0)
f8de20: unused data (entry_offset==0)
f8dea8: unused data (entry_offset==0)
f8df38: unused data (entry_offset==0)
f8dfc8: unused data (entry_offset==0)
f8e058: unused data (entry_offset==0)
f8e0f0: unused data (entry_offset==0)
f8e180: unused data (entry_offset==0)
f8e228: unused data (entry_offset==0)
f8e298: unused data (entry_offset==0)
f8e2e8: unused data (entry_offset==0)
1b85b98: unused data (entry_offset==0)████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  48%
1b85bf0: unused data (entry_offset==0)
1b85c58: unused data (entry_offset==0)
38f9f8: unused data (entry_offset==0)░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░   0%
38fe98: unused data (entry_offset==0)
390068: unused data (entry_offset==0)

Édit :
Marrant tes sorties de « journalctl --headers », il y a une rupture le ven. 2014-06-27 15:40. Il y a donc bien un truc moisi de ce côté

Ce qui est étrange c'est que moi j'ai une paire de fichiers system.journal et user-1000.journal, alors que tu n'as que system.journal de ton côté

Édit 2 (quant aux interrogations ci-dessus) :

sans doute parce que je me loggue en tty avant de lancer startx, utilises-tu un gestionnaire de connection ? kdm ? (qui lance le serveur X en root)

bobo · Message par **bobo** » ven. 11 juil. 2014, 22:41

Suite à la lecture de ce lien http://unix.stackexchange.com/questions ... corruption, il apparaît qu'il n'y a pas de moyen de réparer journalctl en cas de « --verify » moisi.

finding the corrupt journal file and removing it is the only cure

J'ai donc une piste de réparation :

Code : Tout sélectionner

# cd /var/log/journal/79b720b9fadd4cb4aeb16676e31ee9f2/
# mkdir toto
# mv *@* toto
# systemctl restart systemd-journald

Suite à cette manip, « -b -1 » pointe le bon boot, cohérent avec le « -1 » de « --list-boots » ! En prime « journalctl --verify » ne rapporte plus de “unused data”

Code : Tout sélectionner

# journalctl -b -1 | head -4
-- Logs begin at lun. 2014-06-02 18:51:09 CEST, end at ven. 2014-07-11 22:32:20 CEST. --
juil. 11 18:05:32 sharu systemd-journal[160]: Runtime journal is using 8.0M (max allowed 298.6M, trying to leave 447.9M free of 2.9G available → current limit 298.6M).
juil. 11 18:05:32 sharu systemd-journal[160]: Runtime journal is using 8.0M (max allowed 298.6M, trying to leave 447.9M free of 2.9G available → current limit 298.6M).
juil. 11 18:05:32 sharu kernel: Initializing cgroup subsys cpuset

Code : Tout sélectionner

# journalctl --list-boots
-21 5b4cb4225d4d4f4984ad2477a27504ed lun. 2014-06-02 18:51:09 CEST—mer. 2014-06-04 00:29:53 CEST
-20 244c877aae7f48009598afaa257604d4 mer. 2014-06-04 01:03:33 CEST—mer. 2014-06-04 19:07:49 CEST
-19 06b5163311c040d4a9b1108971e32621 mer. 2014-06-04 19:34:35 CEST—lun. 2014-06-09 14:51:52 CEST
-18 f7e8e8d6443e47fbaf9e3e550f1d0f45 lun. 2014-06-09 14:52:30 CEST—mer. 2014-06-11 19:59:19 CEST
-17 a3f4a04aba2349feab634b403b3cf5bf mer. 2014-06-11 20:00:07 CEST—sam. 2014-06-14 20:38:24 CEST
-16 166b892736ae448aabe30390559c0a02 sam. 2014-06-14 20:39:17 CEST—lun. 2014-06-16 20:40:40 CEST
-15 d356dbe38fd941f5999d517702ebf314 lun. 2014-06-16 20:42:34 CEST—mer. 2014-06-18 23:22:15 CEST
-14 a1d30a377b1642768cceefb742019bf8 mer. 2014-06-18 23:45:02 CEST—jeu. 2014-06-19 00:08:42 CEST
-13 5e6f70b87ab74454ace0519fb0f2d641 jeu. 2014-06-19 20:05:38 CEST—jeu. 2014-06-19 23:42:48 CEST
-12 e2003b8230324cabaed2af6d24ed29a9 ven. 2014-06-20 19:05:36 CEST—lun. 2014-06-23 19:26:51 CEST
-11 a87d287ede6d4a5599bc778c942f174c lun. 2014-06-23 19:27:16 CEST—jeu. 2014-07-03 00:27:32 CEST
-10 7e7e610d070941f6b6cfcab76a25ae45 jeu. 2014-07-03 00:27:55 CEST—dim. 2014-07-06 13:41:43 CEST
 -9 01bf9a0682e7423d90def813b69fe6b2 dim. 2014-07-06 13:42:09 CEST—dim. 2014-07-06 14:22:43 CEST
 -8 d0f2e5a81e084418875417a7e5cea9d1 dim. 2014-07-06 14:25:31 CEST—dim. 2014-07-06 14:44:20 CEST
 -7 5510889b7d764296a49c08748dcd3ab5 dim. 2014-07-06 14:45:04 CEST—dim. 2014-07-06 15:13:22 CEST
 -6 2191355762e84695b62c105c7e15fa28 dim. 2014-07-06 15:14:00 CEST—dim. 2014-07-06 15:22:59 CEST
 -5 1b35083785fe4bdf903dd5c8d43f2675 dim. 2014-07-06 15:23:40 CEST—dim. 2014-07-06 15:54:11 CEST
 -4 2ef584e1ef2942919f841c715b8fb5ac dim. 2014-07-06 15:54:53 CEST—dim. 2014-07-06 16:29:34 CEST
 -3 3731e33f606541938637487954d5ef04 dim. 2014-07-06 19:17:46 CEST—ven. 2014-07-11 18:02:51 CEST
 -2 6acb62ca7ae24a89ad5fd245b57a1cea ven. 2014-07-11 18:03:19 CEST—ven. 2014-07-11 18:04:38 CEST
 -1 11280510157b48278831a5849a35d21e ven. 2014-07-11 18:05:32 CEST—ven. 2014-07-11 18:36:56 CEST
  0 dd601ac217734c2fad7ebd984711c58d ven. 2014-07-11 18:37:48 CEST—ven. 2014-07-11 22:32:20 CEST

J'ai quand même perdu mes vieux logs cassés. OK, je m'en fous un peu sur mon PC de bureau personnel. Jouons à essayer de les remettre...

Édit :
En remettant les fichiers corrompus, et en relançant le service systemd-journald, la vérification rapporte de nouveau des “unused data” et “journalctl -b 1” repointe sur le 3 mai à 8h. Ça m'a donc l'air réversible, et lié au contenu des logs corrompus. Il faudrait donc peut-être mettre les logs moisis dans les rapports de bug.

Arch Linux

Archlinux.fr [Forums]

[journalctl] « -b -1 » ne fonctionne pas (RÉSOLU)

[journalctl] « -b -1 » ne fonctionne pas (RÉSOLU)

Re: [journalctl] option « -b -1 » n'a pas l'air de fonctionn

Re: [journalctl] option « -b -1 » n'a pas l'air de fonctionn

Re: [journalctl] option « -b -1 » n'a pas l'air de fonctionn

Re: [journalctl] option « -b -1 » n'a pas l'air de fonctionn

Re: [journalctl] option « -b -1 » n'a pas l'air de fonctionn

Re: [journalctl] option « -b -1 » n'a pas l'air de fonctionn

Re: [journalctl] option « -b -1 » n'a pas l'air de fonctionn

Re: [journalctl] option « -b -1 » n'a pas l'air de fonctionn

Re: [journalctl] option « -b -1 » n'a pas l'air de fonctionn

Re: [journalctl] option « -b -1 » ne fonctionne pas (bug tro

Re: [journalctl] option « -b -1 » ne fonctionne pas (bug tro

Re: [journalctl] option « -b -1 » ne fonctionne pas (bug tro

Re: [journalctl] option « -b -1 » ne fonctionne pas (bug tro