syslog-ng service refuse de d=c3=a9marrer sur raspbian Buster
18 réponses
Geo Cherchetout
Bonjour,
Pour "logger" certains messages de mon modem-routeur j'avais configuré
syslog-ng et tout fonctionnait bien sous raspbian Stretch. Je m'aperçois
aujourd'hui que depuis l'upgrade en Buster, le fichier de log en question a
cessé de grandir. Voici ce que donnent mes requêtes à ce sujet, pardon si
c'est un peu long :
$ sudo service syslog-ng status
● syslog-ng.service - System Logger Daemon
Loaded: loaded (/lib/systemd/system/syslog-ng.service; enabled; vendor
preset: enabled)
Active: failed (Result: exit-code) since Sat 2019-09-28 20:27:44 CEST; 1
weeks 1 days ago
Docs: man:syslog-ng(8)
Process: 503 ExecStart=/usr/sbin/syslog-ng -F $SYSLOGNG_OPTS
(code=exited, status=127)
Main PID: 503 (code=exited, status=127)
sept. 28 20:27:44 raspberrypi systemd[1]: Failed to start System Logger Daemon.
sept. 28 20:27:44 raspberrypi systemd[1]: syslog-ng.service: Unit entered
failed state.
sept. 28 20:27:44 raspberrypi systemd[1]: syslog-ng.service: Failed with
result 'exit-code'.
sept. 28 20:27:44 raspberrypi systemd[1]: syslog-ng.service: Service
hold-off time over, scheduling restart.
sept. 28 20:27:44 raspberrypi systemd[1]: Stopped System Logger Daemon.
sept. 28 20:27:44 raspberrypi systemd[1]: syslog-ng.service: Start request
repeated too quickly.
sept. 28 20:27:44 raspberrypi systemd[1]: Failed to start System Logger Daemon.
sept. 28 20:27:44 raspberrypi systemd[1]: syslog-ng.service: Unit entered
failed state.
sept. 28 20:27:44 raspberrypi systemd[1]: syslog-ng.service: Failed with
result 'exit-code'.
$ sudo service syslog-ng restart
Job for syslog-ng.service failed because the control process exited with
error code.
See "systemctl status syslog-ng.service" and "journalctl -xe" for details.
$ sudo service syslog-ng start
Job for syslog-ng.service failed because the control process exited with
error code.
See "systemctl status syslog-ng.service" and "journalctl -xe" for details.
$ journalctl -xe
-- Subject: L'unité (unit) syslog-ng.service a échoué
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- L'unité (unit) syslog-ng.service a échoué, avec le résultat failed.
oct. 07 16:10:34 raspberrypi systemd[1]: syslog-ng.service: Unit entered
failed state.
oct. 07 16:10:34 raspberrypi systemd[1]: syslog-ng.service: Failed with
result 'exit-code'.
oct. 07 16:10:34 raspberrypi systemd[1]: syslog-ng.service: Service hold-off
time over, scheduling restart.
oct. 07 16:10:34 raspberrypi systemd[1]: Stopped System Logger Daemon.
-- Subject: L'unité (unit) syslog-ng.service a terminé son arrêt
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- L'unité (unit) syslog-ng.service a terminé son arrêt.
oct. 07 16:10:34 raspberrypi systemd[1]: Starting System Logger Daemon...
-- Subject: L'unité (unit) syslog-ng.service a commencé à démarrer
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- L'unité (unit) syslog-ng.service a commencé à démarrer.
oct. 07 16:10:34 raspberrypi syslog-ng[3635]: /usr/sbin/syslog-ng: error
while loading shared libraries: /usr/lib/syslog-ng/libsyslog-ng-3.8.so.0:
Unable to run arch-specific checks
oct. 07 16:10:34 raspberrypi systemd[1]: syslog-ng.service: Main process
exited, code=exited, status=127/n/a
oct. 07 16:10:34 raspberrypi systemd[1]: Failed to start System Logger Daemon.
-- Subject: L'unité (unit) syslog-ng.service a échoué
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- L'unité (unit) syslog-ng.service a échoué, avec le résultat failed.
oct. 07 16:10:34 raspberrypi systemd[1]: syslog-ng.service: Unit entered
failed state.
oct. 07 16:10:34 raspberrypi systemd[1]: syslog-ng.service: Failed with
result 'exit-code'.
oct. 07 16:10:34 raspberrypi systemd[1]: syslog-ng.service: Service hold-off
time over, scheduling restart.
oct. 07 16:10:34 raspberrypi systemd[1]: Stopped System Logger Daemon.
-- Subject: L'unité (unit) syslog-ng.service a terminé son arrêt
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- L'unité (unit) syslog-ng.service a terminé son arrêt.
oct. 07 16:10:34 raspberrypi systemd[1]: syslog-ng.service: Start request
repeated too quickly.
oct. 07 16:10:34 raspberrypi systemd[1]: Failed to start System Logger Daemon.
-- Subject: L'unité (unit) syslog-ng.service a échoué
-- Defined-By: systemd
-- Support: https://www.debian.org/support
Bonjour, Pour "logger" certains messages de mon modem-routeur j'avais configuré syslog-ng et tout fonctionnait bien sous raspbian Stretch. Je m'aperçois aujourd'hui que depuis l'upgrade en Buster, le fichier de log en question a cessé de grandir.
La commande systemctl start syslog-ng.service échouant à chaque tentative, j'ai essayé la commande manuelle : # /usr/sbin/syslog-ng /usr/sbin/syslog-ng: symbol lookup error: /usr/lib/syslog-ng/libsyslog-ng-3.8.so.0: undefined symbol: lkg_soura�_init Ce drôle de caractère m'a mis la puce à l'oreille, il y avait peut-être quelque-chose de pourri dans cette bibliothèque. J'ai donc réinstallé syslog-ng et le service est à présent "active (running)". Merci quand-même. :-)
Le 07/10/2019 16:40, j'ai écrit :
Bonjour,
Pour "logger" certains messages de mon modem-routeur j'avais configuré
syslog-ng et tout fonctionnait bien sous raspbian Stretch. Je m'aperçois
aujourd'hui que depuis l'upgrade en Buster, le fichier de log en question a
cessé de grandir.
La commande systemctl start syslog-ng.service échouant à chaque tentative,
j'ai essayé la commande manuelle :
# /usr/sbin/syslog-ng
/usr/sbin/syslog-ng: symbol lookup error:
/usr/lib/syslog-ng/libsyslog-ng-3.8.so.0: undefined symbol: lkg_soura�_init
Ce drôle de caractère m'a mis la puce à l'oreille, il y avait peut-être
quelque-chose de pourri dans cette bibliothèque. J'ai donc réinstallé
syslog-ng et le service est à présent "active (running)".
Bonjour, Pour "logger" certains messages de mon modem-routeur j'avais configuré syslog-ng et tout fonctionnait bien sous raspbian Stretch. Je m'aperçois aujourd'hui que depuis l'upgrade en Buster, le fichier de log en question a cessé de grandir.
La commande systemctl start syslog-ng.service échouant à chaque tentative, j'ai essayé la commande manuelle : # /usr/sbin/syslog-ng /usr/sbin/syslog-ng: symbol lookup error: /usr/lib/syslog-ng/libsyslog-ng-3.8.so.0: undefined symbol: lkg_soura�_init Ce drôle de caractère m'a mis la puce à l'oreille, il y avait peut-être quelque-chose de pourri dans cette bibliothèque. J'ai donc réinstallé syslog-ng et le service est à présent "active (running)". Merci quand-même. :-)
Marc SCHAEFER
Geo Cherchetout wrote:
/usr/lib/syslog-ng/libsyslog-ng-3.8.so.0: undefined symbol: lkg_soura?_init Ce drôle de caractère m'a mis la puce à l'oreille, il y avait peut-être quelque-chose de pourri dans cette bibliothèque. J'ai donc réinstallé
Il y a quelque chose de pourri dans ton installation ou dans ton matériel. Des trucs qui se corrompent tout seul ? argh. Toute machine que j'installe passe par un cycle de quelques heures de tests: interface RAM/CPU (memtest86), CPU/cache (compilation de kernels en boucle et en parallèle pour utiliser tous les core), puis test d'I/O sérieuses (au moins 2 x la RAM). On trouve rarement des problèmes, mais on en trouve. Avec monitoring de la température avec lm-sensors.
Ce drôle de caractère m'a mis la puce à l'oreille, il y avait peut-être
quelque-chose de pourri dans cette bibliothèque. J'ai donc réinstallé
Il y a quelque chose de pourri dans ton installation ou dans ton matériel.
Des trucs qui se corrompent tout seul ? argh.
Toute machine que j'installe passe par un cycle de quelques heures de
tests: interface RAM/CPU (memtest86), CPU/cache (compilation de
kernels en boucle et en parallèle pour utiliser tous les core), puis
test d'I/O sérieuses (au moins 2 x la RAM).
On trouve rarement des problèmes, mais on en trouve.
Avec monitoring de la température avec lm-sensors.
/usr/lib/syslog-ng/libsyslog-ng-3.8.so.0: undefined symbol: lkg_soura?_init Ce drôle de caractère m'a mis la puce à l'oreille, il y avait peut-être quelque-chose de pourri dans cette bibliothèque. J'ai donc réinstallé
Il y a quelque chose de pourri dans ton installation ou dans ton matériel. Des trucs qui se corrompent tout seul ? argh. Toute machine que j'installe passe par un cycle de quelques heures de tests: interface RAM/CPU (memtest86), CPU/cache (compilation de kernels en boucle et en parallèle pour utiliser tous les core), puis test d'I/O sérieuses (au moins 2 x la RAM). On trouve rarement des problèmes, mais on en trouve. Avec monitoring de la température avec lm-sensors.
Geo Cherchetout
Le 08/10/2019 09:05, *Marc SCHAEFER* a écrit :
Geo Cherchetout wrote:
/usr/lib/syslog-ng/libsyslog-ng-3.8.so.0: undefined symbol: lkg_soura?_init Ce drôle de caractère m'a mis la puce à l'oreille, il y avait peut-être quelque-chose de pourri dans cette bibliothèque. J'ai donc réinstallé
Il y a quelque chose de pourri dans ton installation ou dans ton matériel. Des trucs qui se corrompent tout seul ? argh.
Sur mon raspberrypi c'est une carte mémoire SDHC qui tient lieu de disque dur. Au bout de quelques années de service on peut peut-être s'attendre à des erreurs par-ci par-là ? C'est ce que j'ai constaté ce matin en éditant un certain fichier /usr/share/tcltk/tcl8.6/init.tcl qui contenait manifestement des erreurs à cause de quoi mes tâches cron ne s'exécutaient toujours pas. Voici un bout de ce fichier corrompu, à titre de curiosité. Les dix erreurs sont concentrées sur cette vingtaine de lignes, le reste est intact : --------------------------------------------------------------------------- # The parent$dmrectory /f tcl_library, Adding the pa^Rent # means tha| packages in peer Dhrectorieq will be found iutomatically. # # Also add tHe directory ../Lib relative to the disectory where$the # executable is located. This is meqnt vo vind binary packages For the # sale architecture as <F4>he(ct<F2>rent executable. # # tcl_pkgPadh, whmch is set by the platform-specific ijitialization routines # On UNIX it is ckmpilef m# " On Vijdows, it is Not used ^Hiqf {![inf/ existc auto_path]} { <E9>f^@;[infn exists env(TCLLIBPATH)]} { set au4o_path $env(TCLLIBpATH) } else { s<E5>t auto_tath "" } }<8A>namespage eval tc| { variable Dir ^@ $foreqch Tir`[list $::tcl_library YfilE dirname d::tcl_libraryM] { if<A0>{$Dir ni $::auto_path} { $ lcppend *:auto_path &Dir --------------------------------------------------------------------------- Le problème s'est résolu par un apt-get update, apt-get upgrade, opération qui a pris beaucoup de temps. Je ne m'attendais pas à voir ces centaines de paquetages mis à jour dix jours après mon passage à Buster.
Ce drôle de caractère m'a mis la puce à l'oreille, il y avait peut-être
quelque-chose de pourri dans cette bibliothèque. J'ai donc réinstallé
Il y a quelque chose de pourri dans ton installation ou dans ton matériel.
Des trucs qui se corrompent tout seul ? argh.
Sur mon raspberrypi c'est une carte mémoire SDHC qui tient lieu de disque
dur. Au bout de quelques années de service on peut peut-être s'attendre à
des erreurs par-ci par-là ? C'est ce que j'ai constaté ce matin en éditant
un certain fichier /usr/share/tcltk/tcl8.6/init.tcl qui contenait
manifestement des erreurs à cause de quoi mes tâches cron ne s'exécutaient
toujours pas.
Voici un bout de ce fichier corrompu, à titre de curiosité. Les dix erreurs
sont concentrées sur cette vingtaine de lignes, le reste est intact :
---------------------------------------------------------------------------
# The parent$dmrectory /f tcl_library, Adding the pa^Rent
# means tha| packages in peer Dhrectorieq will be found iutomatically.
#
# Also add tHe directory ../Lib relative to the disectory where$the
# executable is located. This is meqnt vo vind binary packages For the
# sale architecture as <F4>he(ct<F2>rent executable.
#
# tcl_pkgPadh, whmch is set by the platform-specific ijitialization routines
# On UNIX it is ckmpilef m# " On Vijdows, it is Not used
^Hiqf {![inf/ existc auto_path]} {
<E9>f^@;[infn exists env(TCLLIBPATH)]} {
set au4o_path $env(TCLLIBpATH)
} else {
s<E5>t auto_tath ""
}
}<8A>namespage eval tc| {
variable Dir
^@ $foreqch Tir`[list $::tcl_library YfilE dirname d::tcl_libraryM] {
if<A0>{$Dir ni $::auto_path} {
$ lcppend *:auto_path &Dir
---------------------------------------------------------------------------
Le problème s'est résolu par un apt-get update, apt-get upgrade, opération
qui a pris beaucoup de temps. Je ne m'attendais pas à voir ces centaines de
paquetages mis à jour dix jours après mon passage à Buster.
/usr/lib/syslog-ng/libsyslog-ng-3.8.so.0: undefined symbol: lkg_soura?_init Ce drôle de caractère m'a mis la puce à l'oreille, il y avait peut-être quelque-chose de pourri dans cette bibliothèque. J'ai donc réinstallé
Il y a quelque chose de pourri dans ton installation ou dans ton matériel. Des trucs qui se corrompent tout seul ? argh.
Sur mon raspberrypi c'est une carte mémoire SDHC qui tient lieu de disque dur. Au bout de quelques années de service on peut peut-être s'attendre à des erreurs par-ci par-là ? C'est ce que j'ai constaté ce matin en éditant un certain fichier /usr/share/tcltk/tcl8.6/init.tcl qui contenait manifestement des erreurs à cause de quoi mes tâches cron ne s'exécutaient toujours pas. Voici un bout de ce fichier corrompu, à titre de curiosité. Les dix erreurs sont concentrées sur cette vingtaine de lignes, le reste est intact : --------------------------------------------------------------------------- # The parent$dmrectory /f tcl_library, Adding the pa^Rent # means tha| packages in peer Dhrectorieq will be found iutomatically. # # Also add tHe directory ../Lib relative to the disectory where$the # executable is located. This is meqnt vo vind binary packages For the # sale architecture as <F4>he(ct<F2>rent executable. # # tcl_pkgPadh, whmch is set by the platform-specific ijitialization routines # On UNIX it is ckmpilef m# " On Vijdows, it is Not used ^Hiqf {![inf/ existc auto_path]} { <E9>f^@;[infn exists env(TCLLIBPATH)]} { set au4o_path $env(TCLLIBpATH) } else { s<E5>t auto_tath "" } }<8A>namespage eval tc| { variable Dir ^@ $foreqch Tir`[list $::tcl_library YfilE dirname d::tcl_libraryM] { if<A0>{$Dir ni $::auto_path} { $ lcppend *:auto_path &Dir --------------------------------------------------------------------------- Le problème s'est résolu par un apt-get update, apt-get upgrade, opération qui a pris beaucoup de temps. Je ne m'attendais pas à voir ces centaines de paquetages mis à jour dix jours après mon passage à Buster.
Jo Engo
Le Tue, 08 Oct 2019 15:49:18 +0200, Geo Cherchetout a écrit :
Sur mon raspberrypi c'est une carte mémoire SDHC qui tient lieu de disque dur. Au bout de quelques années de service on peut peut-être s'attendre à des erreurs par-ci par-là ?
Il est peut-être temps d'en changer, non ? -- Autofocus mes fesses ! Y'a qu'à demander au type qu'on va photographier d'avancer jusqu'à ce qu'il soit net. Vas-y Marcel ! -+- Philippe Geluck, Le chat -+-
Le Tue, 08 Oct 2019 15:49:18 +0200, Geo Cherchetout a écrit :
Sur mon raspberrypi c'est une carte mémoire SDHC qui tient lieu de
disque dur. Au bout de quelques années de service on peut peut-être
s'attendre à des erreurs par-ci par-là ?
Il est peut-être temps d'en changer, non ?
--
Autofocus mes fesses ! Y'a qu'à demander au type qu'on va photographier
d'avancer jusqu'à ce qu'il soit net. Vas-y Marcel !
-+- Philippe Geluck, Le chat -+-
Le Tue, 08 Oct 2019 15:49:18 +0200, Geo Cherchetout a écrit :
Sur mon raspberrypi c'est une carte mémoire SDHC qui tient lieu de disque dur. Au bout de quelques années de service on peut peut-être s'attendre à des erreurs par-ci par-là ?
Il est peut-être temps d'en changer, non ? -- Autofocus mes fesses ! Y'a qu'à demander au type qu'on va photographier d'avancer jusqu'à ce qu'il soit net. Vas-y Marcel ! -+- Philippe Geluck, Le chat -+-
Didier
Le 08/10/2019 à 15:49, Geo Cherchetout a écrit :
Le 08/10/2019 09:05, *Marc SCHAEFER* a écrit :
Geo Cherchetout wrote:
/usr/lib/syslog-ng/libsyslog-ng-3.8.so.0: undefined symbol: lkg_soura?_init Ce drôle de caractère m'a mis la puce à l'oreille, il y avait peut-être quelque-chose de pourri dans cette bibliothèque. J'ai donc réinstallé
Il y a quelque chose de pourri dans ton installation ou dans ton matériel. Des trucs qui se corrompent tout seul ? argh.
Sur mon raspberrypi c'est une carte mémoire SDHC qui tient lieu de disque dur. Au bout de quelques années de service on peut peut-être s'attendre à des erreurs par-ci par-là ? C'est ce que j'ai constaté ce matin en éditant un certain fichier /usr/share/tcltk/tcl8.6/init.tcl qui contenait manifestement des erreurs à cause de quoi mes tâches cron ne s'exécutaient toujours pas. Voici un bout de ce fichier corrompu, à titre de curiosité. Les dix erreurs sont concentrées sur cette vingtaine de lignes, le reste est intact : --------------------------------------------------------------------------- # The parent$dmrectory /f tcl_library, Adding the pa^Rent # means tha| packages in peer Dhrectorieq will be found iutomatically. # # Also add tHe directory ../Lib relative to the disectory where$the # executable is located. This is meqnt vo vind binary packages For the # sale architecture as <F4>he(ct<F2>rent executable. # # tcl_pkgPadh, whmch is set by the platform-specific ijitialization routines # On UNIX it is ckmpilef m# " On Vijdows, it is Not used ^Hiqf {![inf/ existc auto_path]} { <E9>f^@;[infn exists env(TCLLIBPATH)]} { set au4o_path $env(TCLLIBpATH) } else { s<E5>t auto_tath "" } }<8A>namespage eval tc| { variable Dir ^@ $foreqch Tir`[list $::tcl_library YfilE dirname d::tcl_libraryM] { if<A0>{$Dir ni $::auto_path} { $ lcppend *:auto_path &Dir --------------------------------------------------------------------------- Le problème s'est résolu par un apt-get update, apt-get upgrade, opération qui a pris beaucoup de temps. Je ne m'attendais pas à voir ces centaines de paquetages mis à jour dix jours après mon passage à Buster.
Tu peux aussi réserver la carte SD pour le boot, en lecture seule, et passer la main à un disque usb pour la suite. Je ne suis pas très costaud en Linux, j'ai suivi le tuto sur Frambois 314, nickel. Didier.
Ce drôle de caractère m'a mis la puce à l'oreille, il y avait
peut-être quelque-chose de pourri dans cette bibliothèque. J'ai donc
réinstallé
Il y a quelque chose de pourri dans ton installation ou dans ton
matériel.
Des trucs qui se corrompent tout seul ? argh.
Sur mon raspberrypi c'est une carte mémoire SDHC qui tient lieu de
disque dur. Au bout de quelques années de service on peut peut-être
s'attendre à des erreurs par-ci par-là ? C'est ce que j'ai constaté ce
matin en éditant un certain fichier /usr/share/tcltk/tcl8.6/init.tcl qui
contenait manifestement des erreurs à cause de quoi mes tâches cron ne
s'exécutaient toujours pas.
Voici un bout de ce fichier corrompu, à titre de curiosité. Les dix
erreurs sont concentrées sur cette vingtaine de lignes, le reste est
intact :
---------------------------------------------------------------------------
# The parent$dmrectory /f tcl_library, Adding the pa^Rent
# means tha| packages in peer Dhrectorieq will be found iutomatically.
#
# Also add tHe directory ../Lib relative to the disectory where$the
# executable is located. This is meqnt vo vind binary packages For the
# sale architecture as <F4>he(ct<F2>rent executable.
#
# tcl_pkgPadh, whmch is set by the platform-specific ijitialization
routines
# On UNIX it is ckmpilef m# " On Vijdows, it is Not used
^Hiqf {![inf/ existc auto_path]} {
<E9>f^@;[infn exists env(TCLLIBPATH)]} {
set au4o_path $env(TCLLIBpATH)
} else {
s<E5>t auto_tath ""
}
}<8A>namespage eval tc| {
variable Dir
^@ $foreqch Tir`[list $::tcl_library YfilE dirname d::tcl_libraryM] {
if<A0>{$Dir ni $::auto_path} {
$ lcppend *:auto_path &Dir
---------------------------------------------------------------------------
Le problème s'est résolu par un apt-get update, apt-get upgrade,
opération qui a pris beaucoup de temps. Je ne m'attendais pas à voir ces
centaines de paquetages mis à jour dix jours après mon passage à Buster.
Tu peux aussi réserver la carte SD pour le boot, en lecture seule, et
passer la main à un disque usb pour la suite. Je ne suis pas très
costaud en Linux, j'ai suivi le tuto sur Frambois 314, nickel.
Didier.
/usr/lib/syslog-ng/libsyslog-ng-3.8.so.0: undefined symbol: lkg_soura?_init Ce drôle de caractère m'a mis la puce à l'oreille, il y avait peut-être quelque-chose de pourri dans cette bibliothèque. J'ai donc réinstallé
Il y a quelque chose de pourri dans ton installation ou dans ton matériel. Des trucs qui se corrompent tout seul ? argh.
Sur mon raspberrypi c'est une carte mémoire SDHC qui tient lieu de disque dur. Au bout de quelques années de service on peut peut-être s'attendre à des erreurs par-ci par-là ? C'est ce que j'ai constaté ce matin en éditant un certain fichier /usr/share/tcltk/tcl8.6/init.tcl qui contenait manifestement des erreurs à cause de quoi mes tâches cron ne s'exécutaient toujours pas. Voici un bout de ce fichier corrompu, à titre de curiosité. Les dix erreurs sont concentrées sur cette vingtaine de lignes, le reste est intact : --------------------------------------------------------------------------- # The parent$dmrectory /f tcl_library, Adding the pa^Rent # means tha| packages in peer Dhrectorieq will be found iutomatically. # # Also add tHe directory ../Lib relative to the disectory where$the # executable is located. This is meqnt vo vind binary packages For the # sale architecture as <F4>he(ct<F2>rent executable. # # tcl_pkgPadh, whmch is set by the platform-specific ijitialization routines # On UNIX it is ckmpilef m# " On Vijdows, it is Not used ^Hiqf {![inf/ existc auto_path]} { <E9>f^@;[infn exists env(TCLLIBPATH)]} { set au4o_path $env(TCLLIBpATH) } else { s<E5>t auto_tath "" } }<8A>namespage eval tc| { variable Dir ^@ $foreqch Tir`[list $::tcl_library YfilE dirname d::tcl_libraryM] { if<A0>{$Dir ni $::auto_path} { $ lcppend *:auto_path &Dir --------------------------------------------------------------------------- Le problème s'est résolu par un apt-get update, apt-get upgrade, opération qui a pris beaucoup de temps. Je ne m'attendais pas à voir ces centaines de paquetages mis à jour dix jours après mon passage à Buster.
Tu peux aussi réserver la carte SD pour le boot, en lecture seule, et passer la main à un disque usb pour la suite. Je ne suis pas très costaud en Linux, j'ai suivi le tuto sur Frambois 314, nickel. Didier.
Geo Cherchetout
Le 08/10/2019 16:45, *Marc SCHAEFER* a écrit fort justement :
Geo Cherchetout wrote:
Sur mon raspberrypi c'est une carte mémoire SDHC qui tient lieu de disque dur.
Monitorer régulièrement l'état SMART (pas forcément accessible), par exemple le wear level: ce qui est intéressant ce sont les variations. smartctl -a /dev/sda | egrep 'Wear|LBA|Unkn' 177 Wear_Leveling_Count 0x0013 099 099 000 Pre-fail Always - 5 235 Unknown_Attribute 0x0012 099 099 000 Old_age Always - 25 241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 6479878847 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
Voici le mieux que j'obtiens après installation des smartmontools : ---------------------------------------------------------------------------- $ sudo smartctl -a -d scsi -T permissive /dev/sda smartctl 6.6 2017-11-05 r4594 [armv7l-linux-4.9.35-v7+] (local build) Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION == Vendor: Kingston Product: DataTraveler 2.0 Revision: PMAP Compliance: SPC-4 User Capacity: 15 483 273 216 bytes [15,4 GB] Logical block size: 512 bytes scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0 scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
Terminate command early due to bad response to IEC mode page
=== START OF READ SMART DATA SECTION == Current Drive Temperature: 0 C Drive Trip Temperature: 0 C Error Counter logging not supported scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0 Device does not support Self Test logging ---------------------------------------------------------------------------
Ajouter un monitoring automatique des logs (logcheck) et/ou l'envoi des logs syslogs à un système central. Ajouter éventuellement du monitoring `baselone' (état normal) avec munin, et détecter des déviations (p.ex. temps d'accès qui augmente).
Hé là, doucement. ;-) Je ne suis pas un pro chargé de l'informatique d'une grosse entreprise, mais un simple particulier qui bidouille ses ordinateurs pour s'amuser ! Le système central des logs qui m'intéressent ici, c'est justement ce raspberry pi pour la bonne raison qu'il reste éveillé jour et nuit comme le modem qu'il surveille...
Le 08/10/2019 16:45, *Marc SCHAEFER* a écrit fort justement :
Voici le mieux que j'obtiens après installation des smartmontools :
----------------------------------------------------------------------------
$ sudo smartctl -a -d scsi -T permissive /dev/sda
smartctl 6.6 2017-11-05 r4594 [armv7l-linux-4.9.35-v7+] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION == Vendor: Kingston
Product: DataTraveler 2.0
Revision: PMAP
Compliance: SPC-4
User Capacity: 15 483 273 216 bytes [15,4 GB]
Logical block size: 512 bytes
scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
Terminate command early due to bad response to IEC mode page
=== START OF READ SMART DATA SECTION == Current Drive Temperature: 0 C
Drive Trip Temperature: 0 C
Error Counter logging not supported
scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
Device does not support Self Test logging
---------------------------------------------------------------------------
Ajouter un monitoring automatique des logs (logcheck) et/ou l'envoi
des logs syslogs à un système central. Ajouter éventuellement du
monitoring `baselone' (état normal) avec munin, et détecter des
déviations (p.ex. temps d'accès qui augmente).
Hé là, doucement. ;-) Je ne suis pas un pro chargé de l'informatique d'une
grosse entreprise, mais un simple particulier qui bidouille ses ordinateurs
pour s'amuser ! Le système central des logs qui m'intéressent ici, c'est
justement ce raspberry pi pour la bonne raison qu'il reste éveillé jour et
nuit comme le modem qu'il surveille...
Le 08/10/2019 16:45, *Marc SCHAEFER* a écrit fort justement :
Geo Cherchetout wrote:
Sur mon raspberrypi c'est une carte mémoire SDHC qui tient lieu de disque dur.
Monitorer régulièrement l'état SMART (pas forcément accessible), par exemple le wear level: ce qui est intéressant ce sont les variations. smartctl -a /dev/sda | egrep 'Wear|LBA|Unkn' 177 Wear_Leveling_Count 0x0013 099 099 000 Pre-fail Always - 5 235 Unknown_Attribute 0x0012 099 099 000 Old_age Always - 25 241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 6479878847 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
Voici le mieux que j'obtiens après installation des smartmontools : ---------------------------------------------------------------------------- $ sudo smartctl -a -d scsi -T permissive /dev/sda smartctl 6.6 2017-11-05 r4594 [armv7l-linux-4.9.35-v7+] (local build) Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION == Vendor: Kingston Product: DataTraveler 2.0 Revision: PMAP Compliance: SPC-4 User Capacity: 15 483 273 216 bytes [15,4 GB] Logical block size: 512 bytes scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0 scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0
Terminate command early due to bad response to IEC mode page
=== START OF READ SMART DATA SECTION == Current Drive Temperature: 0 C Drive Trip Temperature: 0 C Error Counter logging not supported scsiModePageOffset: response length too short, resp_len=4 offset=4 bd_len=0 Device does not support Self Test logging ---------------------------------------------------------------------------
Ajouter un monitoring automatique des logs (logcheck) et/ou l'envoi des logs syslogs à un système central. Ajouter éventuellement du monitoring `baselone' (état normal) avec munin, et détecter des déviations (p.ex. temps d'accès qui augmente).
Hé là, doucement. ;-) Je ne suis pas un pro chargé de l'informatique d'une grosse entreprise, mais un simple particulier qui bidouille ses ordinateurs pour s'amuser ! Le système central des logs qui m'intéressent ici, c'est justement ce raspberry pi pour la bonne raison qu'il reste éveillé jour et nuit comme le modem qu'il surveille...
Marc SCHAEFER
Geo Cherchetout wrote:
Hé là, doucement. ;-) Je ne suis pas un pro chargé de l'informatique d'une grosse entreprise, mais un simple particulier qui bidouille ses ordinateurs pour s'amuser ! Le système central des logs qui m'intéressent ici, c'est justement ce raspberry pi pour la bonne raison qu'il reste éveillé jour et nuit comme le modem qu'il surveille...
Ok! dans ce cas logcheck pour être informé par e-mail des problèmes rencontrés, comme des timeouts sur l'accès au SSD, ou, pire encore, des erreurs I/O. Maintenant, les erreurs peuvent être silencieuses aussi. C'est pour cela que je compare le système et les données régulièrement. Dans ton cas: réinstallation propre sur un nouveau SSD, puis ensuite monitoring au minimum des logs systèmes serait recommandé. NB: les raspberry pi ont aussi la fâcheuse tendance de se marcher dessus (le SSD) si le voltage ou l'ampérage est trop faible: si le symbole éclair apparaît sur l'affichage HDMI, c'est le moment de vérifier l'alimentation. PS: c'est pour ça que pour des tâches embarquées je préfère la plateforme apu2: plus fiable, globalement, plus performant, et pas de sortie graphique; mais c'est 4x plus cher.
Hé là, doucement. ;-) Je ne suis pas un pro chargé de l'informatique d'une
grosse entreprise, mais un simple particulier qui bidouille ses ordinateurs
pour s'amuser ! Le système central des logs qui m'intéressent ici, c'est
justement ce raspberry pi pour la bonne raison qu'il reste éveillé jour et
nuit comme le modem qu'il surveille...
Ok! dans ce cas logcheck pour être informé par e-mail des problèmes
rencontrés, comme des timeouts sur l'accès au SSD, ou, pire encore,
des erreurs I/O.
Maintenant, les erreurs peuvent être silencieuses aussi. C'est pour
cela que je compare le système et les données régulièrement.
Dans ton cas: réinstallation propre sur un nouveau SSD, puis ensuite
monitoring au minimum des logs systèmes serait recommandé.
NB: les raspberry pi ont aussi la fâcheuse tendance de se marcher
dessus (le SSD) si le voltage ou l'ampérage est trop faible:
si le symbole éclair apparaît sur l'affichage HDMI, c'est le
moment de vérifier l'alimentation.
PS: c'est pour ça que pour des tâches embarquées je préfère la
plateforme apu2: plus fiable, globalement, plus performant,
et pas de sortie graphique; mais c'est 4x plus cher.
Hé là, doucement. ;-) Je ne suis pas un pro chargé de l'informatique d'une grosse entreprise, mais un simple particulier qui bidouille ses ordinateurs pour s'amuser ! Le système central des logs qui m'intéressent ici, c'est justement ce raspberry pi pour la bonne raison qu'il reste éveillé jour et nuit comme le modem qu'il surveille...
Ok! dans ce cas logcheck pour être informé par e-mail des problèmes rencontrés, comme des timeouts sur l'accès au SSD, ou, pire encore, des erreurs I/O. Maintenant, les erreurs peuvent être silencieuses aussi. C'est pour cela que je compare le système et les données régulièrement. Dans ton cas: réinstallation propre sur un nouveau SSD, puis ensuite monitoring au minimum des logs systèmes serait recommandé. NB: les raspberry pi ont aussi la fâcheuse tendance de se marcher dessus (le SSD) si le voltage ou l'ampérage est trop faible: si le symbole éclair apparaît sur l'affichage HDMI, c'est le moment de vérifier l'alimentation. PS: c'est pour ça que pour des tâches embarquées je préfère la plateforme apu2: plus fiable, globalement, plus performant, et pas de sortie graphique; mais c'est 4x plus cher.
Geo Cherchetout
Le 08/10/2019 17:53, *Marc SCHAEFER* a écrit :
Ok! dans ce cas logcheck pour être informé par e-mail des problèmes rencontrés, comme des timeouts sur l'accès au SSD, ou, pire encore, des erreurs I/O. Maintenant, les erreurs peuvent être silencieuses aussi. C'est pour cela que je compare le système et les données régulièrement. Dans ton cas: réinstallation propre sur un nouveau SSD, puis ensuite monitoring au minimum des logs systèmes serait recommandé.
Un SSD, voilà une idée dont je prends note. :-)
NB: les raspberry pi ont aussi la fâcheuse tendance de se marcher dessus (le SSD) si le voltage ou l'ampérage est trop faible: si le symbole éclair apparaît sur l'affichage HDMI, c'est le moment de vérifier l'alimentation. PS: c'est pour ça que pour des tâches embarquées je préfère la plateforme apu2: plus fiable, globalement, plus performant, et pas de sortie graphique; mais c'est 4x plus cher.
C'est aussi beaucoup plus gourmand en énergie électrique, pour des performances dont je n'ai aucun besoin.
Le 08/10/2019 17:53, *Marc SCHAEFER* a écrit :
Ok! dans ce cas logcheck pour être informé par e-mail des problèmes
rencontrés, comme des timeouts sur l'accès au SSD, ou, pire encore,
des erreurs I/O.
Maintenant, les erreurs peuvent être silencieuses aussi. C'est pour
cela que je compare le système et les données régulièrement.
Dans ton cas: réinstallation propre sur un nouveau SSD, puis ensuite
monitoring au minimum des logs systèmes serait recommandé.
Un SSD, voilà une idée dont je prends note. :-)
NB: les raspberry pi ont aussi la fâcheuse tendance de se marcher
dessus (le SSD) si le voltage ou l'ampérage est trop faible:
si le symbole éclair apparaît sur l'affichage HDMI, c'est le
moment de vérifier l'alimentation.
PS: c'est pour ça que pour des tâches embarquées je préfère la
plateforme apu2: plus fiable, globalement, plus performant,
et pas de sortie graphique; mais c'est 4x plus cher.
C'est aussi beaucoup plus gourmand en énergie électrique, pour des
performances dont je n'ai aucun besoin.
Ok! dans ce cas logcheck pour être informé par e-mail des problèmes rencontrés, comme des timeouts sur l'accès au SSD, ou, pire encore, des erreurs I/O. Maintenant, les erreurs peuvent être silencieuses aussi. C'est pour cela que je compare le système et les données régulièrement. Dans ton cas: réinstallation propre sur un nouveau SSD, puis ensuite monitoring au minimum des logs systèmes serait recommandé.
Un SSD, voilà une idée dont je prends note. :-)
NB: les raspberry pi ont aussi la fâcheuse tendance de se marcher dessus (le SSD) si le voltage ou l'ampérage est trop faible: si le symbole éclair apparaît sur l'affichage HDMI, c'est le moment de vérifier l'alimentation. PS: c'est pour ça que pour des tâches embarquées je préfère la plateforme apu2: plus fiable, globalement, plus performant, et pas de sortie graphique; mais c'est 4x plus cher.
C'est aussi beaucoup plus gourmand en énergie électrique, pour des performances dont je n'ai aucun besoin.
Geo Cherchetout
Le 08/10/2019 16:32, *Didier* a écrit :
Tu peux aussi réserver la carte SD pour le boot, en lecture seule, et passer la main à un disque usb pour la suite. Je ne suis pas très costaud en Linux, j'ai suivi le tuto sur Frambois 314, nickel. Didier.
Un disque usb qui pourrait aussi bien être un SSD, pourquoi pas ? Merci pour l'adresse, j'étudie la question. :-)
Le 08/10/2019 16:32, *Didier* a écrit :
Tu peux aussi réserver la carte SD pour le boot, en lecture seule, et
passer la main à un disque usb pour la suite. Je ne suis pas très
costaud en Linux, j'ai suivi le tuto sur Frambois 314, nickel.
Didier.
Un disque usb qui pourrait aussi bien être un SSD, pourquoi pas ? Merci pour
l'adresse, j'étudie la question. :-)
Tu peux aussi réserver la carte SD pour le boot, en lecture seule, et passer la main à un disque usb pour la suite. Je ne suis pas très costaud en Linux, j'ai suivi le tuto sur Frambois 314, nickel. Didier.
Un disque usb qui pourrait aussi bien être un SSD, pourquoi pas ? Merci pour l'adresse, j'étudie la question. :-)
yamo'
Salut, Geo Cherchetout a tapoté le 08/10/2019 18:12:
Le 08/10/2019 16:32, *Didier* a écrit :
Tu peux aussi réserver la carte SD pour le boot, en lecture seule, et passer la main à un disque usb pour la suite. Je ne suis pas très costaud en Linux, j'ai suivi le tuto sur Frambois 314, nickel. Didier.
Un disque usb qui pourrait aussi bien être un SSD, pourquoi pas ? Merci pour l'adresse, j'étudie la question. :-)
Même sur un vieux disque non SSD, ça fonctionne. Pour mon cas, sur un pi2, comme c'est de l'usb2 je ne gagnerais pas grand chose en SSD. Il faut juste un disque alimenté avec une prise (sauf peut-être sur les derniers rapsberry pi3 et pi4). -- Stéphane
Salut,
Geo Cherchetout a tapoté le 08/10/2019 18:12:
Le 08/10/2019 16:32, *Didier* a écrit :
Tu peux aussi réserver la carte SD pour le boot, en lecture seule, et
passer la main à un disque usb pour la suite. Je ne suis pas très
costaud en Linux, j'ai suivi le tuto sur Frambois 314, nickel.
Didier.
Un disque usb qui pourrait aussi bien être un SSD, pourquoi pas ? Merci pour
l'adresse, j'étudie la question. :-)
Même sur un vieux disque non SSD, ça fonctionne.
Pour mon cas, sur un pi2, comme c'est de l'usb2 je ne gagnerais pas
grand chose en SSD.
Il faut juste un disque alimenté avec une prise (sauf peut-être sur les
derniers rapsberry pi3 et pi4).
Salut, Geo Cherchetout a tapoté le 08/10/2019 18:12:
Le 08/10/2019 16:32, *Didier* a écrit :
Tu peux aussi réserver la carte SD pour le boot, en lecture seule, et passer la main à un disque usb pour la suite. Je ne suis pas très costaud en Linux, j'ai suivi le tuto sur Frambois 314, nickel. Didier.
Un disque usb qui pourrait aussi bien être un SSD, pourquoi pas ? Merci pour l'adresse, j'étudie la question. :-)
Même sur un vieux disque non SSD, ça fonctionne. Pour mon cas, sur un pi2, comme c'est de l'usb2 je ne gagnerais pas grand chose en SSD. Il faut juste un disque alimenté avec une prise (sauf peut-être sur les derniers rapsberry pi3 et pi4). -- Stéphane
