"Házi szerverem" megérett a szoftver frissítésre Debian 6.x -> Debian 10
Feltelepítettem a nut -ot (az volt a régi rendszerben is) az UPS kezelésére.
Azt mondanám egész könnyű volt, de azzal szembesültem, hogy a leggenerikusabb driver a genericups alacsony akkumulátort jelez. A Debian 6 -nak nincs ilyen gondja.
# upsc APC600
device.mfr: APC
device.model: Back-UPS
device.type: ups
driver.name: genericups
driver.parameter.pollinterval: 2
driver.parameter.port: /dev/ttyS0
driver.parameter.upstype: 2
driver.version: 2.4.3
driver.version.internal: 1.36
ups.mfr: APC
ups.model: Back-UPS
ups.status: OL
Ugyanez a Debian 10 -ben így fest:
# upsc APC600
device.mfr: APC
device.model: Back-UPS
device.type: ups
driver.name: genericups
driver.parameter.LB: DCD
driver.parameter.pollinterval: 2
driver.parameter.port: /dev/ttyS0
driver.parameter.synchronous: no
driver.parameter.upstype: 2
driver.version: 2.7.4
driver.version.internal: 1.36
ups.mfr: APC
ups.model: Back-UPS
ups.status: LB OL
Ráadásul, a "driver.version.internal: 1.36" verzió azonos!
Íme a syslog kivonat:
Aug 27 16:52:52 nusi upsdrvctl[501]: UPS type: APC Back-UPS (940-0020B/C cable)
Aug 27 16:52:52 nusi upsdrvctl[501]: parse_input_signals: input overrides specified, but no effective difference - check for typos?
Aug 27 16:52:52 nusi upsdrvctl[501]: Network UPS Tools - UPS driver controller 2.7.4
Aug 27 16:52:53 nusi upsd[506]: fopen /var/run/nut/upsd.pid: No such file or directory
Aug 27 16:52:53 nusi upsd[506]: listening on 127.0.0.1 port 3493
Aug 27 16:52:53 nusi upsd[506]: listening on 127.0.0.1 port 3493
Aug 27 16:52:53 nusi upsd[571]: Startup successful
Aug 27 16:52:53 nusi upsmon[776]: fopen /var/run/nut/upsmon.pid: No such file or directory
Aug 27 16:52:53 nusi upsmon[776]: UPS: APC600@localhost (master) (power value 1)
Aug 27 16:52:53 nusi upsmon[776]: Using power down flag file /etc/killpower
Aug 27 16:52:53 nusi upsmon[780]: Startup successful
Aug 27 16:52:53 nusi systemd[1]: nut-monitor.service: Can't open PID file /run/nut/upsmon.pid (yet?) after start: No such file or directory
Aug 27 16:52:53 nusi upsmon[781]: Init SSL without certificate database
Aug 27 16:52:54 nusi upsd[571]: User monmaster@127.0.0.1 logged into UPS [APC600]
Aug 27 16:52:54 nusi upsmon[781]: UPS APC600@localhost battery is low
A dokumentációban nem látok olyan újdonságot ami ezt okozhatja. Szétkaptam az UPS -t (hátha mégis hiba van) de nem találtam ilyet, az akku 13,6V állt (furcsa is lenne, márciusban cseréltem YUASA 12V10Ah 5 évig bírta).
Még azt is kipróbáltam, hogy a régi (debian 6) konfigurációs fájljait töltöttem be, de semmi változás.
Googliztam, többször átfutottam a dokumentáció idevágó részeit, de nem találtam semmi idevágót (persze ez megint egy régiség, nem igen használ ilyet senki).
Van valami ötlet?
OFF: A nálam lévő 4 darab alapvetően diszkrét, analóg áramkörökből épül fel, szinte mindene javítható, van kapcsolási rajz, sőt alap bemérési utasítás.
Saját gyártmányú kábellel működik, sok éve megbízhatóan.
SZERK: Az összes kínomat a systemd scriptek időzítése okozta. Reanimáltam a /etc/rc.local -t mint systemd service -t és ott indítom a systemd startup scripteket. Így most jól működik.
Hozzászólások
Amíg nem jön valaki megoldani, csak annyit kérdeznék, hogy miért ragaszkodsz a NUT-hoz?
Én a NUT helyett NIS-t használok. (Egy olyan szerveren, amit deb5 óta frissítgetek.)
10-es debiánnál már futottam bele olyan problémába, ami 5->9 ig nem jelentkezett.
És volt olyan is (talán a 8-nál), hogy az egyik szerveren az mrtg lehalt, aztán a szenvedések közepedte eljött az a pillanat, amikor bandwidthd lett helyette, sok időt megspórolva.
A NIS mint olyan nem épp az UPS kezelésre lett kitalálva, a Debian csomagban az UPS kezelést meg sem említik. Nem látom milyen UPS -t támogat. Az mrtg ha jól emlékszem valami bitmap kezelő, webes megjelenítő. Nem kell ilyen nekem.
A nut deklaráltan támogatja a Back UPS -t ahol "dumb" vagy "simple" soros kábellel kapcsolódik az UPS a géphez - csak szinteket figyel (on cabel, on battery, low battery).
Szóval ha elmegy az áram és alacsony az akku - shutdown.
* Én egy indián vagyok. Minden indián hazudik.
Bocs, én fogalmaztam rosszul, a NIS Az apcupsd egy szolgáltatása (több gép 1 ups-hez), szóval apcupsd kell Neked. Az biztos jól megy deb10-zel (tapasztalatból írom)
Az mrtg-t csak azért írtam, hogy belefutottam már rejtélyes hibába upgrade-nél, nincs köze az ups-hez :)
Köszönöm!
Így már jobban hangzik! Anno kokettáltam ezzel a csomaggal - nem tudom már miért maradtam a nut -nál. Talán mert működött, bár a konfigurálása eléggé nyögve nyelős.
Belekukkantottam a dokumentációba:
1. Nem stimmel a 940-0020B kábel leírása a nut -hoz képest?
(Ezekhez a régi UPS -hez brutális áron adják a kábelt, én magamnak csináltam. Talán emiatt maradtam a nut -nál)
2. Itt is kicsit elnagyolták, hogy is tudom ellenőrizni, hogy jó e a konfiguráció, hogy tudom ellenőrizni amikor áramkimaradás van időben lekapcsol.
Mivel nem látok jobb lehetőséget kifogom próbálni, de előbb mentek :)
* Én egy indián vagyok. Minden indián hazudik.
Próbáld ki, ahogy lentebb is írták az apcaccess megmondja, hogy látja-e.
Ellenőrzésre meg egy nagyon profeszionális, nehezen elsajátítható expert módszerem van: kirántom a 230-ból :)
Ha csipog a beeper és megjelenik a monitoron egy warning, akkor minden ok. A teljes lemerülést is lehetne így tesztelni, de én meg szoktam várni, amikor az áramszolgáltató kifüggeszti azt a ronda sárga papírt az éves hálózatfejlesztés/karbantartásról, olyankor megpróbálok a szerverek mellett maradni és figyelem mi történik, meddig bírja stb.
A teljes lesülést nekem könnyebb tesztelnem, szétszedem az UPS -t és rábiggyesztek egy 4Ah -aksit, egy-két százas izzó percek alatt lemerítheti.
* Én egy indián vagyok. Minden indián hazudik.
Az így nem jó.
Nem az akkut kell tesztelni, hanem az UPS-t!
Időben el tudja-e kezdeni körbeszórni a shutdown üzeneteket, azaz le tud-e minden gép időben állni.
Meg aztán mikor kapcsolja vissza az áramot, megvárja-e, hogy legyen az akkuba annyi töltés, hogy ha töltődés közben megint elmegy az áram, akkor be tudja fejezni minden gép a boot és a halt folyamatot.
Volt már szerencsém olyan APC UPS-hez, amiben az akku jó volt, csak az elektronika kakált be.
Ha nincs redundáns tápod redundáns ups-el vagy olyan HW raid vezérlőd, amin van külön akku, akkor érdemes rendesen letesztelni azt az 1 szem UPS-t.
Igazad van.
Azonban a "szerveren" kívül nálam csak a switch és a modem jár az UPS -ről, a 600VA -ből sokkal többre nem is fussa.
Az APC Back UPS 600i igen régi cucc, amint visszajön az áram kapcsol, nincs benne semmi intelligencia (már gondolkodtam hogy teszek ellene, de amire nálam van arra ez is jó). Az előnye, hogy így abszolút javítható kivéve talán a trafót, ha az megy tönkre nem éri meg vele küzdeni.
* Én egy indián vagyok. Minden indián hazudik.
Van ugye egy ojan üzenetem, hogy
systemd[1]: nut-monitor.service: Can't open PID file /run/nut/upsmon.pid (yet?) after start: No such file or directory
Gondoltam lehet ez a hiba oka, hogy valójában nincs kommunikáció a driver-monitor-szerver között. A gépet direkt rádugtam a hálózatra és az UPS -el játszottam - kihúztam ls figyeltem a "# watch upsc APC600" kimenetét. Van kommunikáció (az upsc már a kilens) mivel megjelent az OB (on battery státusz) majd kisvártatva ahogy kell le shutdownolta a gépet. (Így talán együtt lehet vele élni amíg kiderül mi a nyűgje.)
Viszont volt egy ijesztő jelenség, miközben ki/be kapcsolgattam, teszeltem egyszer csak beugrott a helyes állapot (nem volt low battery). Az ijesztő az hogy ezt az állapotot többé nem sikerült előállítanom.
A Linux -ban nem sűrűn talákoztam hazárddal, vagy ha mégei akkor mindig valami hw hiba volt a forrás.
* Én egy indián vagyok. Minden indián hazudik.
apcaccess illetve apctest talán amit keresel
--
"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."
Kösz! Tényleg van ilyen a csomagban, majd megnézem mit tud.
* Én egy indián vagyok. Minden indián hazudik.
Csak adalék. A nut nem érzékeli ha nincs kapcsolat az UPS -el vagy ki van kapcsolva (mondjuk az utóbbinak nincs sok értelme).
* Én egy indián vagyok. Minden indián hazudik.
Gond nélkül feltelepítettem egy teszt gépre az apcupsd -t. Tesztek.
Nem érzékel (jó akku mellett) "low battery" állapotot - eddig jó.
Nem érzékeli ha lehúzom a kábelt (a nut sem tudta).
Nem tudja lekapcsolni az UPS -t!?
Ráadásul, ha a vezérlő kábelt bedugom és a teszt gombbal "lekapcsolom" a hálózatot, rögtön leáll az UPS?
A kábelt anno magam gyártottam, ez alapján HUP. Előkaptam az anno készült deszka modellt, azzal sem jobb, ha rákötöm csak az UPS -re máris lekapcsol ha nincs hálózat áram (teszt gomb).
Ez egyre zűrösebb. (Ránéztem az árakra, egy eredeti 940-0020B kábel 8 eFt alatt nincs ilyen - ki az ördög vesz ennyiért kábelt egy ilyen ócskavashoz?
Újra kell az egészet vizsgálni :(
Itt valami hardware hiba (is) van.
* Én egy indián vagyok. Minden indián hazudik.
Még nem vadásztam le a hardwer hibámat, viszont azt most már tudom, hogy sem a nut sem a apcupsd nem ismeri fel he lehúzzák a 940-0020B kábelt.
Mind a két sw boldogan OL/ONLINE.
* Én egy indián vagyok. Minden indián hazudik.
driver.parameter.LB: DCD
Ez nem azt jelenti, hogy a soros port melyik lábán jelzi, hogy alacsony az akku? Lehet, hogy a kábeled nem ilyen, nézd meg a Deb6-nál mit figyel.
Ráadásul ez:
parse_input_signals: input overrides specified, but no effective difference - check for typos?
Lehet, hogy valami be volt állítva a konfigban, de ez most nem érvényesül.
A Deb6 -nál sem érzékeli ha a kábelt lehúzod. Annyira hogy OL - vagyis online a státusz.
A dokumentáció szerint:
2 = APC Back-UPS/Back-UPS Pro/Smart-UPS with 940-0020B cable
[CP=RTS] [OL=-CTS] [LB=DCD] [SD=DTR+RTS]
Ahol szerintem a CP lenne a kapcsolat hiánya:
CP Cable power (must be present for cable to have valid reading)
Viszont a 940-0020B kábel kapcsolásánál ezt írja:
Presence of the cable can be sensed by signaling on TXD while monitoring DCD.
Zavaros :(
* Én egy indián vagyok. Minden indián hazudik.
Én ezt nézem:
https://pinouts.ru/UPS/apc_back_cable_pinout.shtml
RX/TX be sincs kötve. Az UPS-ből az LB meg egy tranzisztort nyit az RTC és DCD közt.
Én pedig ezt valósítottam meg:
https://fossies.org/linux/nut/docs/cables/apc.txt
Második rajz
"Gray APC 940-0020B Simple Signalling UPS Cable Wiring Diagram"
"This information is verified and tested to be 100% correct."
Ami biztos, ha lehúzod a kábelt nincs jelzés. Megnézem a forrás csomagot.
Gyanús, hogy a nut honlapján ennek a kábelnek már nincs leírása.
https://networkupstools.org/
* Én egy indián vagyok. Minden indián hazudik.
Ezen is ott a tranyó. A CP (cable power) az meg inkább az, hogy azt muszáj felhúznia a PC-nek ahhoz, hogy működjön a low battery jelzés.
Szóval a kapcsolás úgy működik, hogy RTS +V, TXD -V, és így a battery low az UPS-ből fel vagy lehúzza a tranzisztor segítségével a DCD-t.
Az, hogy lehúzod a kábelt, és nem csinál semmit, az OK, nincs ilyen funkciója, illetve valóban, a TXD kapcsolgatásával a DCD is kapcsolgatni fog elvileg, de gondolom ez nincs benne egy generic driverben.
Köszönöm!
Én is erre jutottam. A "CP" -nek semmi köze a kapcsolathoz és hacsak nem akarok új szoftvert írni, kábelt módosítani marad az, hogy nem tudja :(
Most már csak azt kell kitalálnom miért nem működik az új verzióval.
* Én egy indián vagyok. Minden indián hazudik.
Még nem volt időm újra leellenőrizni mindent, de
Lecseréltem az "új" nut (2.7.4-8) verzióban található /lib/nut/genericups drivert régi, nut 2.4.3-1.1squeeze2 (Debian 6.x) állományra (mindkét fájlé ott van de a symlink a régi verzióra mutat). Gond nélkül elindult.
Láss csodát már nincs "LB" = Low Battery
Mint mondtam, még tesztelni kell, de az már látszik, ha szimplán lehúzom a 230 -as kábelt a rendszer látja (OB) és persze nem jelez low battery -t hiszen az akku csurig van.
Ha minden rendben megy (kisülés/lekapcsolás teszt) akkor így marad.
Milyen más teendőm lehet? Jelezzem a fejlesztőknek? A Debian -nak? Vagy örüljek mert működik?
Keressem meg hol a hiba a kódban, írjak egy patch -et és attól fogva folyton pötchölhetek?
OFF: Kár hogy nem bízom magamban eléggé - a kábelem még windows XP alatt is kifogástalanul működött, az egyszerű APC driverrel amit gyárilag az XŐP -hez adtak. Sok bosszúságot és időt megspórolhattam volna :(
* Én egy indián vagyok. Minden indián hazudik.
Vagy: leszeded githubról a forrást, visszamész benne egy működő verzióig, lefordítod, és onnan bisecttel megkeresed a patchet, ami elrontotta (egyébként nem lehet, hogy simán fordítva érzékeli a DCD-t, azaz ha valójában lemerült az akku, akkor meg eltűnik az LB jelzés?)
Ez meg még mindig gyanús:
parse_input_signals: input overrides specified, but no effective difference - check for typos?
arse_input_signals: input overrides specified, but no effective difference - check for typos?
Én raktam be egy próbát, de nem módosított semmit, azaz az eredeti leírásnak megfelelt. A "-" előjelet nem próbáltam.
Sajnos nem tudom mi a "bisect" - majd utánanézek.
Ill. ha megtalálom azt a pontot/verziót ahol elromlott a driver akkor mi lesz?
Most le sem kell fordítanom. Ráadásul szerintem ez a driver nem sok vizet kavar, a fejlesztések zömében a biztonságos kapcsolódásról és a syystemd -re való áttérésről szól. (Ez utóbbi eléggé fura, mivel ahhoz, hogy a nut működjön 3 service kell, hogy fusson de egyik sem indítja automatikusan a másikat)
* Én egy indián vagyok. Minden indián hazudik.
Ill. ha megtalálom azt a pontot/verziót ahol elromlott a driver akkor mi lesz?
Pl. szólsz a fejlesztőnek, és meglesz az a kellemes érzésed, hogy te is hozzájárultál az opensource mozgalomhoz :)
Mondjuk ahogy nézem, ez a driver 5 éve nem változott, és addig se túl sokat, szóval 2-3 commit közül lehet az egyik, ha tényleg nem elkonfigurálás.
No, most meglepődtem. Ránéztem a gui -ból a két genericups állományra és más az ikonja ...
Kisült a régi az egy elf "executable" míg az új "shared object". Most akkor melyik működik?
* Én egy indián vagyok. Minden indián hazudik.
Akkor ez most mi?
Rájöttem, hogy teljesen mindegy melyik "genericups" fájlt használom (a "legfrissebbel" is működik), de csak akkor ha kézzel leállítom a "részeit":
# systemctl stop nut-server.service
# systemctl stop nut-monitor.service
# systemctl stop nut-driver.service
Majd újra indítom:
# systemctl start nut-driver.service
# systemctl start nut-monitor.service
# systemctl start nut-server.service
(a sorrend nem mindegy)
Így jól működik.
Gyanús is volt, hogy a driver alig változott (nincsenek speciális fordítási opciók).
Viszont akkor most a systemctl scriptekkel van valami baj?
Lövésem nincs mit kezdjek ezzel, valahol olvastam, ha létrehozok egy /etc/rc.local fájlt azt is kezeli, de ez is a systemd -n keresztül megy.
Van ilyesmire valami ötlet?
Azt sem tudom mit keressek a google -n :(
SZERKESZTVE:
Lemaradt egy negyedik nut-client.service.
Nem kell mindent újra indítani, hogy helyre álljon a működés, elég a nut-driver.service -t újraindítani (közvetlenül újraindítás után).
SZERKESZTVE:
Az /etc/rc.local nem működik :( Az "Network UPS Tools" utána indul, vagyis még nincs elindítva.
* Én egy indián vagyok. Minden indián hazudik.
Úgy látszik a probléma a systemd scriptekkel van, gondolom a sorrend.
A megoldás egyelőre az lesz, hogy letiltottam minden nut-[valami].service -t és az /etc/rc.local ban indtom a nut -ot:
systemctl start nut-monitor.service
systemctl start nut-server.service
A systemd is ezeket indítaná, csak más ponton.
Sajnos ebből azért lehetnek problémák update -ek esetén :(
* Én egy indián vagyok. Minden indián hazudik.