Bonjour,
Je reviens sur ce thread parce que :
Le 04/03/22 Í 17:21, Olivier a écrit :Mon objectif est d'éviter d'endommager un disque (toujours de type SSD ou NVMe) Í cause d'une
coupure brutale de courant.
m'étonne un peu.
Un disque ssd est vraiment sensible Í une coupure brutale ?
Je me souviens™ du devoir de parquer les disques avant d'éteindre un PC, mais c’était au siècle
dernier !
Bonjour,
Je reviens sur ce thread parce que :
Le 04/03/22 Í 17:21, Olivier <oza.4h07@gmail.com> a écrit :
> Mon objectif est d'éviter d'endommager un disque (toujours de type SSD ou NVMe) Í cause d'une
> coupure brutale de courant.
m'étonne un peu.
Un disque ssd est vraiment sensible Í une coupure brutale ?
Je me souviens™ du devoir de parquer les disques avant d'éteindre un PC, mais c’était au siècle
dernier !
Bonjour,
Je reviens sur ce thread parce que :
Le 04/03/22 Í 17:21, Olivier a écrit :Mon objectif est d'éviter d'endommager un disque (toujours de type SSD ou NVMe) Í cause d'une
coupure brutale de courant.
m'étonne un peu.
Un disque ssd est vraiment sensible Í une coupure brutale ?
Je me souviens™ du devoir de parquer les disques avant d'éteindre un PC, mais c’était au siècle
dernier !
Je suis par contre assez surpris de lire que tu as besoin de fsck
régulièrement vu que (selon moi, c'est pas une vérité gravée dans le marbre
; ) le problème est forcément lié Í l'écriture et que les systèmes
n'écrivent pas grand chose hormis leurs logs
Je suis par contre assez surpris de lire que tu as besoin de fsck
régulièrement vu que (selon moi, c'est pas une vérité gravée dans le marbre
; ) le problème est forcément lié Í l'écriture et que les systèmes
n'écrivent pas grand chose hormis leurs logs
Je suis par contre assez surpris de lire que tu as besoin de fsck
régulièrement vu que (selon moi, c'est pas une vérité gravée dans le marbre
; ) le problème est forcément lié Í l'écriture et que les systèmes
n'écrivent pas grand chose hormis leurs logs
Le 15/03/22 ̓ 10:33, Mathias Dufresne a
̓©crit :Je suis par contre assez surpris de lire que tu as besoin de fsckmarbre
r̓©guli̓¨rement vu que (selon moi, c'est pas une v̓©rit̓© grav̓©e dans le; ) le probl̓¨me est forc̓©ment li̓© ̓ l'̓©criture et que les syst̓¨mes
n'̓©crivent pas grand chose hormis leurs logs
Je sais pas si c'est fsck, mais il scanne pas le FS (̓§a prend qq ms lors
du boot), je pensais
que c'̓©tait juste le journal du FS qui avait encore dans son buffer des
donn̓©es non ̓©crites, et
qu'il commen̓§ait par les ̓©crire ̓ leur place avant de monter le
filesystem, d'o̓¹ les messages
"recovered inode Í¢€¦".
--
Daniel
L'id̓©e d'une arm̓©e europ̓©enne est vraiment int̓©ressante,
mais pourquoi ne pas aller plus loin en cr̓©ant une arm̓©e
mondiale dont le principal int̓©r̓ªt serait qu'elle n'aurait
pas d'ennemis.
Philippe Geluck, Le chat
Le 15/03/22 ̓ 10:33, Mathias Dufresne <mathias.dufresne@gmail.com> a
̓©crit :
> Je suis par contre assez surpris de lire que tu as besoin de fsck
> r̓©guli̓¨rement vu que (selon moi, c'est pas une v̓©rit̓© grav̓©e dans le
marbre
> ; ) le probl̓¨me est forc̓©ment li̓© ̓ l'̓©criture et que les syst̓¨mes
> n'̓©crivent pas grand chose hormis leurs logs
Je sais pas si c'est fsck, mais il scanne pas le FS (̓§a prend qq ms lors
du boot), je pensais
que c'̓©tait juste le journal du FS qui avait encore dans son buffer des
donn̓©es non ̓©crites, et
qu'il commen̓§ait par les ̓©crire ̓ leur place avant de monter le
filesystem, d'o̓¹ les messages
"recovered inode Í¢€¦".
--
Daniel
L'id̓©e d'une arm̓©e europ̓©enne est vraiment int̓©ressante,
mais pourquoi ne pas aller plus loin en cr̓©ant une arm̓©e
mondiale dont le principal int̓©r̓ªt serait qu'elle n'aurait
pas d'ennemis.
Philippe Geluck, Le chat
Le 15/03/22 ̓ 10:33, Mathias Dufresne a
̓©crit :Je suis par contre assez surpris de lire que tu as besoin de fsckmarbre
r̓©guli̓¨rement vu que (selon moi, c'est pas une v̓©rit̓© grav̓©e dans le; ) le probl̓¨me est forc̓©ment li̓© ̓ l'̓©criture et que les syst̓¨mes
n'̓©crivent pas grand chose hormis leurs logs
Je sais pas si c'est fsck, mais il scanne pas le FS (̓§a prend qq ms lors
du boot), je pensais
que c'̓©tait juste le journal du FS qui avait encore dans son buffer des
donn̓©es non ̓©crites, et
qu'il commen̓§ait par les ̓©crire ̓ leur place avant de monter le
filesystem, d'o̓¹ les messages
"recovered inode Í¢€¦".
--
Daniel
L'id̓©e d'une arm̓©e europ̓©enne est vraiment int̓©ressante,
mais pourquoi ne pas aller plus loin en cr̓©ant une arm̓©e
mondiale dont le principal int̓©r̓ªt serait qu'elle n'aurait
pas d'ennemis.
Philippe Geluck, Le chat
Le 2022-03-15 10:16, Mathias Dufresne a écrit :Une option peut être le wake-on-lan si le problème du redémarrage
automatique ne fonctionne pas. Malheureusement ça nécessite une machine
allumée donc soit par un démarrage manuelle, soit une machine qui
arrive a se réveiller toute seule après retour de l'électricité.
P't'être même qu'un vieux PC qui s'allume quand le courant revient pour
lancer des paquets wake-on-lan et qui s'éteigne une fois sa tÍ¢che
terminée pourrait faire l'affaire : Í la fin de la prochaine coupure,
cette machine devrait se réveiller et lancer les paquets...
Sur mon onduleur, j'ai :
* des prises secourues et qui offrent une protection contre la foudre ;
* des prises *non* secourues, qui offrent une protection contre la
foudre.
Je pense qu'en branchant sur une prise *non* secourue une carte
minimaliste, du genre Raspberry Pi Zero W :
https://www.kubii.fr/cartes-raspberry-pi/1851-raspberry-pi-zero-w-kubii-3272496006997.html
On peut aisément – et Í moindre cout – fournir le service attendu.
Si le wifi n'est pas disponible, il faudra opter pour un modèle plus «
luxueux » (au regard de l'usage qui en est fait), disposant d'une
interface Ethernet, du genre Raspberry Pi 3 :
https://www.kubii.fr/home/1628-raspberry-pi-3-modele-b-1-gb-kubii-5060214370264.html
Il semblerait que l'on puisse même faire cela avec un simple ESP32 :
https://github.com/mkttanabe/ESP32_WakeOnLan
Sébastien
--
Sébastien Dinot
Ne goͻtez pas au logiciel libre, vous ne pourriez plus vous en passer !
https://www.palabritudes.net/
Le 2022-03-15 10:16, Mathias Dufresne a écrit :
> Une option peut être le wake-on-lan si le problème du redémarrage
> automatique ne fonctionne pas. Malheureusement ça nécessite une machine
> allumée donc soit par un démarrage manuelle, soit une machine qui
> arrive a se réveiller toute seule après retour de l'électricité.
> P't'être même qu'un vieux PC qui s'allume quand le courant revient pour
> lancer des paquets wake-on-lan et qui s'éteigne une fois sa tÍ¢che
> terminée pourrait faire l'affaire : Í la fin de la prochaine coupure,
> cette machine devrait se réveiller et lancer les paquets...
Sur mon onduleur, j'ai :
* des prises secourues et qui offrent une protection contre la foudre ;
* des prises *non* secourues, qui offrent une protection contre la
foudre.
Je pense qu'en branchant sur une prise *non* secourue une carte
minimaliste, du genre Raspberry Pi Zero W :
https://www.kubii.fr/cartes-raspberry-pi/1851-raspberry-pi-zero-w-kubii-3272496006997.html
On peut aisément – et Í moindre cout – fournir le service attendu.
Si le wifi n'est pas disponible, il faudra opter pour un modèle plus «
luxueux » (au regard de l'usage qui en est fait), disposant d'une
interface Ethernet, du genre Raspberry Pi 3 :
https://www.kubii.fr/home/1628-raspberry-pi-3-modele-b-1-gb-kubii-5060214370264.html
Il semblerait que l'on puisse même faire cela avec un simple ESP32 :
https://github.com/mkttanabe/ESP32_WakeOnLan
Sébastien
--
Sébastien Dinot
Ne goͻtez pas au logiciel libre, vous ne pourriez plus vous en passer !
https://www.palabritudes.net/
Le 2022-03-15 10:16, Mathias Dufresne a écrit :Une option peut être le wake-on-lan si le problème du redémarrage
automatique ne fonctionne pas. Malheureusement ça nécessite une machine
allumée donc soit par un démarrage manuelle, soit une machine qui
arrive a se réveiller toute seule après retour de l'électricité.
P't'être même qu'un vieux PC qui s'allume quand le courant revient pour
lancer des paquets wake-on-lan et qui s'éteigne une fois sa tÍ¢che
terminée pourrait faire l'affaire : Í la fin de la prochaine coupure,
cette machine devrait se réveiller et lancer les paquets...
Sur mon onduleur, j'ai :
* des prises secourues et qui offrent une protection contre la foudre ;
* des prises *non* secourues, qui offrent une protection contre la
foudre.
Je pense qu'en branchant sur une prise *non* secourue une carte
minimaliste, du genre Raspberry Pi Zero W :
https://www.kubii.fr/cartes-raspberry-pi/1851-raspberry-pi-zero-w-kubii-3272496006997.html
On peut aisément – et Í moindre cout – fournir le service attendu.
Si le wifi n'est pas disponible, il faudra opter pour un modèle plus «
luxueux » (au regard de l'usage qui en est fait), disposant d'une
interface Ethernet, du genre Raspberry Pi 3 :
https://www.kubii.fr/home/1628-raspberry-pi-3-modele-b-1-gb-kubii-5060214370264.html
Il semblerait que l'on puisse même faire cela avec un simple ESP32 :
https://github.com/mkttanabe/ESP32_WakeOnLan
Sébastien
--
Sébastien Dinot
Ne goͻtez pas au logiciel libre, vous ne pourriez plus vous en passer !
https://www.palabritudes.net/
Suite Í une nouvelle sollicitation, je déterre ce vieux fil de discussion.
J'ai expérimenté avec un NUC, dont l'option After Power Failure du
BIOS était valorisée Í Last Stateroot
1. J'exécute echo freeze > /sys/power/state
La machine s'arrête (brutalement, semble-t-il)
Je débranche puis rebranche l'alimentation (comme si un onduleur l'avait fait)
Le serveur démarre avec un boot quasi normal car il affiche
"Recovering journal".
2. Idem avec echo standby > /sys/power/state
3. L'option After Power Failure est changée Í StayOn et l'hibernation
est déclenché par poweroff.
La machine est dans un état inabituel: le bouton power reste allumé
mais l'écran est quasi-vide (un simple tiret en haut Í gauche).
Je débranche puis rebranche l'alimentation (comme si un onduleur l'avait fait)
Le serveur démarre avec un boot normal (il n'affiche pas "Recovering journal").
A. Existe-t-il une commande ou option de configuration sous Linux pour
que le passage Í l'état freeze évite le "Recovering journal" ? Qu'en
pensez-vous ?
B. Comme l'a pointé Sébastien, un point important dans mon scenario
est que dans tous les cas, l'onduleur coupe le courant en aval une
fois qu'il a avertit d'une coupure puis respecte une temporisation
avant de le rétablir en avant, même si le courant en amont est revenu
la coupure en aval.
Suite Í une nouvelle sollicitation, je déterre ce vieux fil de discussion.
J'ai expérimenté avec un NUC, dont l'option After Power Failure du
BIOS était valorisée Í Last Stateroot
1. J'exécute echo freeze > /sys/power/state
La machine s'arrête (brutalement, semble-t-il)
Je débranche puis rebranche l'alimentation (comme si un onduleur l'avait fait)
Le serveur démarre avec un boot quasi normal car il affiche
"Recovering journal".
2. Idem avec echo standby > /sys/power/state
3. L'option After Power Failure est changée Í StayOn et l'hibernation
est déclenché par poweroff.
La machine est dans un état inabituel: le bouton power reste allumé
mais l'écran est quasi-vide (un simple tiret en haut Í gauche).
Je débranche puis rebranche l'alimentation (comme si un onduleur l'avait fait)
Le serveur démarre avec un boot normal (il n'affiche pas "Recovering journal").
A. Existe-t-il une commande ou option de configuration sous Linux pour
que le passage Í l'état freeze évite le "Recovering journal" ? Qu'en
pensez-vous ?
B. Comme l'a pointé Sébastien, un point important dans mon scenario
est que dans tous les cas, l'onduleur coupe le courant en aval une
fois qu'il a avertit d'une coupure puis respecte une temporisation
avant de le rétablir en avant, même si le courant en amont est revenu
la coupure en aval.
Suite Í une nouvelle sollicitation, je déterre ce vieux fil de discussion.
J'ai expérimenté avec un NUC, dont l'option After Power Failure du
BIOS était valorisée Í Last Stateroot
1. J'exécute echo freeze > /sys/power/state
La machine s'arrête (brutalement, semble-t-il)
Je débranche puis rebranche l'alimentation (comme si un onduleur l'avait fait)
Le serveur démarre avec un boot quasi normal car il affiche
"Recovering journal".
2. Idem avec echo standby > /sys/power/state
3. L'option After Power Failure est changée Í StayOn et l'hibernation
est déclenché par poweroff.
La machine est dans un état inabituel: le bouton power reste allumé
mais l'écran est quasi-vide (un simple tiret en haut Í gauche).
Je débranche puis rebranche l'alimentation (comme si un onduleur l'avait fait)
Le serveur démarre avec un boot normal (il n'affiche pas "Recovering journal").
A. Existe-t-il une commande ou option de configuration sous Linux pour
que le passage Í l'état freeze évite le "Recovering journal" ? Qu'en
pensez-vous ?
B. Comme l'a pointé Sébastien, un point important dans mon scenario
est que dans tous les cas, l'onduleur coupe le courant en aval une
fois qu'il a avertit d'une coupure puis respecte une temporisation
avant de le rétablir en avant, même si le courant en amont est revenu
la coupure en aval.
Si tu peux exécuter une commande avant, un 'sync' devrait déja
améliorer la situation.
Il est peut-être possible de forcer le système Í vider ses caches très
régulièrement, mais ce n'est clairement pas propre.
Si tu peux exécuter une commande avant, un 'sync' devrait déja
améliorer la situation.
Il est peut-être possible de forcer le système Í vider ses caches très
régulièrement, mais ce n'est clairement pas propre.
Si tu peux exécuter une commande avant, un 'sync' devrait déja
améliorer la situation.
Il est peut-être possible de forcer le système Í vider ses caches très
régulièrement, mais ce n'est clairement pas propre.
On 20/10/2022 21:08, Th.A.C wrote:Si tu peux exécuter une commande avant, un 'sync' devrait déja
améliorer la situation.
Il est peut-être possible de forcer le système Í vider ses caches très
régulièrement, mais ce n'est clairement pas propre.
Pourquoi ne serait-ce pas propre?
Pour ceux que ça intéresse, j'ai codé en C un petit utilitaire (sous
licence GPLv3+) qui appelle sync périodiquement:
https://github.com/bstarynk/misc-basile/blob/master/sync-periodically.c
(et je cherche des partenaires intéressés par un consortium
HorizonEurope ou ANR finançant et utilisant le logiciel d'IA symbolique
RefPerSys en http://refpersys.org/ - qu'ils me contactent par courriel
aussi au bureau, CEA LIST, en ....)
--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
On 20/10/2022 21:08, Th.A.C wrote:
>
>
> Si tu peux exécuter une commande avant, un 'sync' devrait déja
> améliorer la situation.
> Il est peut-être possible de forcer le système Í vider ses caches très
> régulièrement, mais ce n'est clairement pas propre.
Pourquoi ne serait-ce pas propre?
Pour ceux que ça intéresse, j'ai codé en C un petit utilitaire (sous
licence GPLv3+) qui appelle sync périodiquement:
https://github.com/bstarynk/misc-basile/blob/master/sync-periodically.c
(et je cherche des partenaires intéressés par un consortium
HorizonEurope ou ANR finançant et utilisant le logiciel d'IA symbolique
RefPerSys en http://refpersys.org/ - qu'ils me contactent par courriel
aussi au bureau, CEA LIST, en basile.starynkevitch@cea.fr ....)
--
Basile Starynkevitch <basile@starynkevitch.net>
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
On 20/10/2022 21:08, Th.A.C wrote:Si tu peux exécuter une commande avant, un 'sync' devrait déja
améliorer la situation.
Il est peut-être possible de forcer le système Í vider ses caches très
régulièrement, mais ce n'est clairement pas propre.
Pourquoi ne serait-ce pas propre?
Pour ceux que ça intéresse, j'ai codé en C un petit utilitaire (sous
licence GPLv3+) qui appelle sync périodiquement:
https://github.com/bstarynk/misc-basile/blob/master/sync-periodically.c
(et je cherche des partenaires intéressés par un consortium
HorizonEurope ou ANR finançant et utilisant le logiciel d'IA symbolique
RefPerSys en http://refpersys.org/ - qu'ils me contactent par courriel
aussi au bureau, CEA LIST, en ....)
--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
CÍ´té serveur, je pense utiliser la combinaison "After Power Failure
valorisée Í StayOn /arrêt par Poweroff".
Pour éteindre mon serveur, il faut lui demander de s'arrêter puis
quelques secondes après lui couper sa prise de courant.
Pour le remettre en service, il faut et il suffit "d'allumer" sa prise
de courant.
CÍ´té onduleur, il me faudrait un onduleur, outre ses qualités propres
(puissance, facilité d'entretien des batteries, ...):
A- qui sache immédiatement notifier un arrêt du courant en amont
B- qui sache notifier avec un certain retard un rétablissement du
courant en amont (*)
C- qui sache alerter un serveur quand son niveau de batterie passe
sous un certain seuil et sache arrêter des prises de courant en aval,
un certain temps après l'envoi d'alerte (tant pis si l'alerte n'a pas
été reçue ou si courant en amont est revenu entre temps)
D- qui sache rétablir des prises de courant en aval quand le courant
en amont est revenu et quand la batterie est au dessus d'un certain
seuil.
Avec une interface Ethernet sur l'onduleur, les notifications
pourraient s'opérer par courriel et les alertes par SNMP ou autre
(HTTP ?). Il resterai Í vérifier que les exigences ci dessus soient
satisfaites.
La A me parait facile Í satisfaire.
La B n'est pas si importante que cela.
La C et la D me paraissent difficile Í lire sur une datasheet.
Peut-être qu'en consultant un manuel ?
(*) Si je n'ai pas de réseau hors bande, il est probable que les
moyens de transmissions des notifications ne soient pas encore
rétablis quand le courant en amont vient juste de se rétablir
Le jeu. 20 oct. 2022 Í 21:16, Basile Starynkevitch
a écrit :On 20/10/2022 21:08, Th.A.C wrote:
>
>
> Si tu peux exécuter une commande avant, un 'sync' devrait déja
> améliorer la situation.
> Il est peut-être possible de forcer le système Í vider ses caches très
> régulièrement, mais ce n'est clairement pas propre.
Pourquoi ne serait-ce pas propre?
Pour ceux que ça intéresse, j'ai codé en C un petit utilitaire (sous
licence GPLv3+) qui appelle sync périodiquement:
https://github.com/bstarynk/misc-basile/blob/master/sync-periodically.c
(et je cherche des partenaires intéressés par un consortium
HorizonEurope ou ANR finançant et utilisant le logiciel d'IA symbolique
RefPerSys en http://refpersys.org/ - qu'ils me contactent par courriel
aussi au bureau, CEA LIST, en ....)
--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
CÍ´té serveur, je pense utiliser la combinaison "After Power Failure
valorisée Í StayOn /arrêt par Poweroff".
Pour éteindre mon serveur, il faut lui demander de s'arrêter puis
quelques secondes après lui couper sa prise de courant.
Pour le remettre en service, il faut et il suffit "d'allumer" sa prise
de courant.
CÍ´té onduleur, il me faudrait un onduleur, outre ses qualités propres
(puissance, facilité d'entretien des batteries, ...):
A- qui sache immédiatement notifier un arrêt du courant en amont
B- qui sache notifier avec un certain retard un rétablissement du
courant en amont (*)
C- qui sache alerter un serveur quand son niveau de batterie passe
sous un certain seuil et sache arrêter des prises de courant en aval,
un certain temps après l'envoi d'alerte (tant pis si l'alerte n'a pas
été reçue ou si courant en amont est revenu entre temps)
D- qui sache rétablir des prises de courant en aval quand le courant
en amont est revenu et quand la batterie est au dessus d'un certain
seuil.
Avec une interface Ethernet sur l'onduleur, les notifications
pourraient s'opérer par courriel et les alertes par SNMP ou autre
(HTTP ?). Il resterai Í vérifier que les exigences ci dessus soient
satisfaites.
La A me parait facile Í satisfaire.
La B n'est pas si importante que cela.
La C et la D me paraissent difficile Í lire sur une datasheet.
Peut-être qu'en consultant un manuel ?
(*) Si je n'ai pas de réseau hors bande, il est probable que les
moyens de transmissions des notifications ne soient pas encore
rétablis quand le courant en amont vient juste de se rétablir
Le jeu. 20 oct. 2022 Í 21:16, Basile Starynkevitch
<basile@starynkevitch.net> a écrit :
>
>
> On 20/10/2022 21:08, Th.A.C wrote:
> >
> >
> > Si tu peux exécuter une commande avant, un 'sync' devrait déja
> > améliorer la situation.
> > Il est peut-être possible de forcer le système Í vider ses caches très
> > régulièrement, mais ce n'est clairement pas propre.
>
>
>
> Pourquoi ne serait-ce pas propre?
>
>
> Pour ceux que ça intéresse, j'ai codé en C un petit utilitaire (sous
> licence GPLv3+) qui appelle sync périodiquement:
>
> https://github.com/bstarynk/misc-basile/blob/master/sync-periodically.c
>
>
> (et je cherche des partenaires intéressés par un consortium
> HorizonEurope ou ANR finançant et utilisant le logiciel d'IA symbolique
> RefPerSys en http://refpersys.org/ - qu'ils me contactent par courriel
> aussi au bureau, CEA LIST, en basile.starynkevitch@cea.fr ....)
>
>
> --
> Basile Starynkevitch <basile@starynkevitch.net>
> (only mine opinions / les opinions sont miennes uniquement)
> 92340 Bourg-la-Reine, France
> web page: starynkevitch.net/Basile/
>
CÍ´té serveur, je pense utiliser la combinaison "After Power Failure
valorisée Í StayOn /arrêt par Poweroff".
Pour éteindre mon serveur, il faut lui demander de s'arrêter puis
quelques secondes après lui couper sa prise de courant.
Pour le remettre en service, il faut et il suffit "d'allumer" sa prise
de courant.
CÍ´té onduleur, il me faudrait un onduleur, outre ses qualités propres
(puissance, facilité d'entretien des batteries, ...):
A- qui sache immédiatement notifier un arrêt du courant en amont
B- qui sache notifier avec un certain retard un rétablissement du
courant en amont (*)
C- qui sache alerter un serveur quand son niveau de batterie passe
sous un certain seuil et sache arrêter des prises de courant en aval,
un certain temps après l'envoi d'alerte (tant pis si l'alerte n'a pas
été reçue ou si courant en amont est revenu entre temps)
D- qui sache rétablir des prises de courant en aval quand le courant
en amont est revenu et quand la batterie est au dessus d'un certain
seuil.
Avec une interface Ethernet sur l'onduleur, les notifications
pourraient s'opérer par courriel et les alertes par SNMP ou autre
(HTTP ?). Il resterai Í vérifier que les exigences ci dessus soient
satisfaites.
La A me parait facile Í satisfaire.
La B n'est pas si importante que cela.
La C et la D me paraissent difficile Í lire sur une datasheet.
Peut-être qu'en consultant un manuel ?
(*) Si je n'ai pas de réseau hors bande, il est probable que les
moyens de transmissions des notifications ne soient pas encore
rétablis quand le courant en amont vient juste de se rétablir
Le jeu. 20 oct. 2022 Í 21:16, Basile Starynkevitch
a écrit :On 20/10/2022 21:08, Th.A.C wrote:
>
>
> Si tu peux exécuter une commande avant, un 'sync' devrait déja
> améliorer la situation.
> Il est peut-être possible de forcer le système Í vider ses caches très
> régulièrement, mais ce n'est clairement pas propre.
Pourquoi ne serait-ce pas propre?
Pour ceux que ça intéresse, j'ai codé en C un petit utilitaire (sous
licence GPLv3+) qui appelle sync périodiquement:
https://github.com/bstarynk/misc-basile/blob/master/sync-periodically.c
(et je cherche des partenaires intéressés par un consortium
HorizonEurope ou ANR finançant et utilisant le logiciel d'IA symbolique
RefPerSys en http://refpersys.org/ - qu'ils me contactent par courriel
aussi au bureau, CEA LIST, en ....)
--
Basile Starynkevitch
(only mine opinions / les opinions sont miennes uniquement)
92340 Bourg-la-Reine, France
web page: starynkevitch.net/Basile/
Dans la documentation Eaton, je découvre le paramètre Redémarrage
forcé, qui activé, me semble bien correspondre Í l'exigence C
Dans la documentation Eaton, je découvre le paramètre Redémarrage
forcé, qui activé, me semble bien correspondre Í l'exigence C
Dans la documentation Eaton, je découvre le paramètre Redémarrage
forcé, qui activé, me semble bien correspondre Í l'exigence C
Olivier a écrit :Dans la documentation Eaton, je découvre le paramètre Redémarrage
forcé, qui activé, me semble bien correspondre Í l'exigence C
Ça m'intéresse. O͹ as-tu trouvé cette information ? Pour ma part, je
n'ai jamais trouvé mieux qu'un succinct manuel en 9 pages.
Sébastien
--
Sébastien Dinot,
http://www.palabritudes.net/
Ne goͻtez pas au logiciel libre, vous ne pourriez plus vous en passer !
Olivier a écrit :
> Dans la documentation Eaton, je découvre le paramètre Redémarrage
> forcé, qui activé, me semble bien correspondre Í l'exigence C
Ça m'intéresse. O͹ as-tu trouvé cette information ? Pour ma part, je
n'ai jamais trouvé mieux qu'un succinct manuel en 9 pages.
Sébastien
--
Sébastien Dinot, sebastien.dinot@free.fr
http://www.palabritudes.net/
Ne goͻtez pas au logiciel libre, vous ne pourriez plus vous en passer !
Olivier a écrit :Dans la documentation Eaton, je découvre le paramètre Redémarrage
forcé, qui activé, me semble bien correspondre Í l'exigence C
Ça m'intéresse. O͹ as-tu trouvé cette information ? Pour ma part, je
n'ai jamais trouvé mieux qu'un succinct manuel en 9 pages.
Sébastien
--
Sébastien Dinot,
http://www.palabritudes.net/
Ne goͻtez pas au logiciel libre, vous ne pourriez plus vous en passer !