[Unix] Zijn pidfiles niet onhandig?

[FooBarWidget]

Unix server software maken doorgaans gebruik van een pidfile om hun PID op te slaan, zodat scripts later de server kunnen afsluiten door die PID een signal te sturen. Zo'n beetje alle Unix servers doen dit, en veel Unix tools bieden ondersteuning voor pidfiles. Bijvoorbeeld GOD, een tool voor Ruby om server software te beheren (de admin kan de pidfile specificeren, en specificeren wat er moet gebeuren als een server plotseling dood gaat).

Maar is dat niet ontzettend onhandig? Als de server opeens dood gaat, bijvoorbeeld door stroomstoring of een segmentation fault, dan krijg je een stale pidfile. Bij veel server software, zoals Mongrel, moet je die pidfile handmatig verwijderen, anders start hij niet eens op. Dit lijkt me niet echt ideaal.
Wat ik in mijn server software doe is gebruik maken van zowel een pidfile als een lockfile. Met de lockfile controleer ik of de server wel daadwerkelijk draait (dus of de pidfile eigenlijk wel geldig is). Dit verwijst wat werk maar is robuuster. Aan de andere kant, lock files werken niet op o.a. NFS shares.

Dus waarom gebruiken Unix servers nog primitieve pid files? Is er wel een beter alternatief die overal werkt? Wat ik eigenlijk zoek is een tijdelijke resource waarin de PID staat, en die gebonden is aan een proces en benaderd kan worden via een naam - als de proces dood gaat dan zal de kernel ervoor zorgen dat de resource gegarandeerd vrijgegeven wordt. Bestaat wel zoiets?

[Gerco]

FooBarWidget schreef op donderdag 02 augustus 2007 @ 19:06:
Wat ik in mijn server software doe is gebruik maken van zowel een pidfile als een lockfile. Met de lockfile controleer ik of de server wel daadwerkelijk draait (dus of de pidfile eigenlijk wel geldig is).

Hiermee heb je toch hetzelfde probleem als met pidfiles? Wie gaat die lockfile opruimen als je proces spontaan crasht?

Wat ik eigenlijk zoek is een tijdelijke resource waarin de PID staat, en die gebonden is aan een proces en benaderd kan worden via een naam - als de proces dood gaat dan zal de kernel ervoor zorgen dat de resource gegarandeerd vrijgegeven wordt.

Kun je niets met een POSIX semafoor of misschien met shared memory? Die kun je beiden op naam aanspreken en tussen processen delen. Of ze ook automatisch weer opgeruimd worden door het OS durf ik niet te zeggen.

[XTerm]

Je zou de pidfiles in ramdrive (ergens in /proc...) kunnen zetten waardoor ze verdwijnen bij reboot.

[moto-moi]

Meeste distro's wissen ook automatisch /var/run waar meestal dat soort zooi komt te staan

[Gerco]

XTerm schreef op donderdag 02 augustus 2007 @ 19:36:
Je zou de pidfiles in ramdrive (ergens in /proc...) kunnen zetten waardoor ze verdwijnen bij reboot.

Reboot?

19:42:36 up 944 days, 20:01, 1 user, load average: 0.08, 0.02, 0.01

Niet iedereen reboot zijn server elke week en bovendien heb je hier meestal alleen last van als het proces crasht en dan wil je het vaak meteen opnieuw starten, niet eerst ff rebooten

[ACM]

FooBarWidget schreef op donderdag 02 augustus 2007 @ 19:06:
Dus waarom gebruiken Unix servers nog primitieve pid files? Is er wel een beter alternatief die overal werkt? Wat ik eigenlijk zoek is een tijdelijke resource waarin de PID staat, en die gebonden is aan een proces en benaderd kan worden via een naam - als de proces dood gaat dan zal de kernel ervoor zorgen dat de resource gegarandeerd vrijgegeven wordt. Bestaat wel zoiets?

Ik ben me niet bewust van zo'n omgeving die echt door de kernel aangeboden wordt - iig niet in Linux, misschien dat duurdere unices het wel hebben. Maar je kan natuurlijk sowieso nadat je de file hebt ontdekt kijken of het process uberhaupt nog actief is (een kill met een loos signaal erop afvuren bijv) nadat je eerst de pidfile gelocked had natuurlijk. Als het process niet meer leeft, dan kan je je server laten starten en zich de pidfile toe laten eigenen.

En er zijn vast wel andere oplossingen voor, maar vergeet niet dat veel van die daemons al lang bestaan en dat er op daardoor vaak het wiel opnieuw is uitgevonden of er in al die tijd niet voldoende reden is geweest om er wat voor aan te passen. Als het goed is krijg je tenslotte geen segfaults en in de normale praktijk crashen/reboten servers niet zo vaak onverwachts. En bovendien loop je grote kans dat je dan niet geautomatiseerd de boel live wilt krijgen, maar eerst de reden van de crash wilt weten.

XTerm schreef op donderdag 02 augustus 2007 @ 19:36:
Je zou de pidfiles in ramdrive (ergens in /proc...) kunnen zetten waardoor ze verdwijnen bij reboot.

Kan je serieus willekeurige files in /proc wegschrijven? Dat lijkt me niet bepaald de bedoeling, tegenwoordig is het wel gebruikelijk dat je distro een /dev/shm oid aanmaakt met het tmpfs-filesystem.

[ Voor 12% gewijzigd door ACM op 02-08-2007 19:53 ]

[XTerm]

ACM schreef op donderdag 02 augustus 2007 @ 19:51:
[...]
Kan je serieus willekeurige files in /proc wegschrijven? Dat lijkt me niet bepaald de bedoeling, tegenwoordig is het wel gebruikelijk dat je distro een /dev/shm oid aanmaakt met het tmpfs-filesystem.

Het kan niet, maar het zou zo gemaakt kunnen worden. /dev/shm is ook een goeie kandidaat

[Confusion]

FooBarWidget schreef op donderdag 02 augustus 2007 @ 19:06:
Wat ik eigenlijk zoek is een tijdelijke resource waarin de PID staat, en die gebonden is aan een proces en benaderd kan worden via een naam - als de proces dood gaat dan zal de kernel ervoor zorgen dat de resource gegarandeerd vrijgegeven wordt.

Volgens mij detecteren veruit de meeste programma's stale PID files in hun opstartscripts en verwijderen die. Wel een file, geen bijbehorend proces -> delete. Wat win je met een ingewikkeldere methode?

[FooBarWidget]

Hiermee heb je toch hetzelfde probleem als met pidfiles? Wie gaat die lockfile opruimen als je proces spontaan crasht?

Die worden (helaas) ook niet opgeruimd. Maar dan weet mijn server iig dat die pidfile niet geldig is, ondanks dat ie bestaat. Zo hoeft ie niet te weigeren om op te starten.

Kun je niets met een POSIX semafoor of misschien met shared memory?

Als ik me goed herinner (tis een tijdje geleden dat ik met die dingen heb gewerkt) moet je een semaphore en shared memory handmatig verwijderen (sem_destroy en shm_detach ofzo). Als je dat niet doet dan blijven ze rondhangen tot je reboot.

Je zou de pidfiles in ramdrive (ergens in /proc...) kunnen zetten waardoor ze verdwijnen bij reboot.

Dat help niet bij een segfault of een andere abnormale shutdown van het programma.

Maar je kan natuurlijk sowieso nadat je de file hebt ontdekt kijken of het process uberhaupt nog actief is (een kill met een loos signaal erop afvuren bijv) nadat je eerst de pidfile gelocked had natuurlijk.

Dat klopt, maar:
1. Dit lijkt systeem-afhankelijk te zijn. Voor zover ik weet is er hier geen portable API voor. Op Linux controleer ik of /proc/$PID bestaat, op FreeBSD heb je dat niet tenzij je expliciet een compatibility layer installeert.
2. Het *kan* gebeuren dat er wel een proces is met die PID, maar dat het een ander proces is. Het is niet 100% betrouwbaar.

Confusion: dit is tevens een reply op jouw post. Ik vrees dus de corner cases. In theorie kan het gebeuren, hoe klein de kans ook is. En we kennen allemaal Murphy's law wel.

[Gerco]

FooBarWidget schreef op donderdag 02 augustus 2007 @ 20:09:
Die worden (helaas) ook niet opgeruimd. Maar dan weet mijn server iig dat die pidfile niet geldig is, ondanks dat ie bestaat. Zo hoeft ie niet te weigeren om op te starten.

Kun je niet iets met file locking doen dan? flock() je pidfile voor write tijdens het draaien van je proces. Wanneer je proces crasht is de file niet meer locked. Voor het opstarten lock je de pidfile voor write (je moet wel, want anders kun je er niet in schrijven) en als dat mislukt, draait je proces nog. Als dat locken wel lukt, had je een stale file en kun je die rustig overschrijven.

C:

if(!flock(fd, LOCK_EX | LOCK_NB)) {
  // Proces draait nog, niet opstarten
}

Wanneer je al je file descriptors afsluit (tijdens een crash doet het OS dat hopelijk voor je), ben je ook gelijk de lock kwijt. De pidfile staat er dan nog wel, maar de bovenstaande flock() zal dan slagen. Geen idee of dit portable is naar iets anders dan Linux overigens.

[ Voor 20% gewijzigd door Gerco op 02-08-2007 20:23 ]

[Confusion]

FooBarWidget schreef op donderdag 02 augustus 2007 @ 20:09:
Confusion: dit is tevens een reply op jouw post. Ik vrees dus de corner cases. In theorie kan het gebeuren, hoe klein de kans ook is. En we kennen allemaal Murphy's law wel.

Tjah, in dat geval een mailtje, SMS'sje of ander alarm naar de dienstdoende systeembeheerder en die in laten grijpen. Als je die downtime niet kan hebben, dan zal je al een failover hebben. En als die failover faalt, dan houdt het gewoon op. That's life .

[FooBarWidget]

Gerco: dat is dus wat ik bij mijn eigen software doet. Maar zoals gezegd werkt dat niet op NFS, die ondersteunt geen lock files.

[Gerco]

FooBarWidget schreef op donderdag 02 augustus 2007 @ 20:29:
Gerco: dat is dus wat ik bij mijn eigen software doet. Maar zoals gezegd werkt dat niet op NFS, die ondersteunt geen lock files.

Er is een erg groot verschil tussen lockfiles en file locks. Ik dacht dat je die eerste bedoelde

Anyhow:

quote: man flock

NOTES
flock(2) does not lock files over NFS. Use fcntl(2) instead: that does
work over NFS, given a sufficiently recent version of Linux and a
server which supports locking.

Niet heel erg portable, maar werkt wel. Alleen heb ik zo mijn twijfels over het automatisch opruimen daarvan.

[ Voor 8% gewijzigd door Gerco op 02-08-2007 20:39 ]

[whoami]

Dit heeft niet echt iets met PRG te maken; eerder NOS
-> NOS

[deadinspace]

FooBarWidget schreef op donderdag 02 augustus 2007 @ 19:06:
Wat ik in mijn server software doe is gebruik maken van zowel een pidfile als een lockfile. Met de lockfile controleer ik of de server wel daadwerkelijk draait (dus of de pidfile eigenlijk wel geldig is). Dit verwijst wat werk maar is robuuster. Aan de andere kant, lock files werken niet op o.a. NFS shares.

Een pid- en lockfile gebruiken is de juiste aanpak, dat is (mits juist gebruikt) 100% veilig, aangenomen dat locking werkt. Wat ik zelf trouwens doe is de pidfile locken, op die manier heb je maar één file.

Dat het niet op NFS werkt acht ik een gebrek van NFS(-implementaties). Ik zie ook geen reden waarom locking niet zou moeten werken over NFS. Gelukkig is het niet al te gebruikelijk om /var/run (de juiste plaats voor systemwide lockfiles) op NFS te hebben staan.

FooBarWidget schreef op donderdag 02 augustus 2007 @ 20:09:
Dat klopt, maar:
1. Dit lijkt systeem-afhankelijk te zijn. Voor zover ik weet is er hier geen portable API voor.

En wat ACM voorstelde ("een kill met een loos signaal erop afvuren") dan? kill() met signal 0 levert geen signal af, maar checkt wel of het process bestaat. En dat gedrag is gespecificeerd in POSIX voor zover ik weet.

Op Linux controleer ik of /proc/$PID bestaat, op FreeBSD heb je dat niet tenzij je expliciet een compatibility layer installeert.

Je hoeft geen compatibility layer te installeren hoor, alleen maar /proc te mounten

[zeroxcool]

Misschien wel interessant om te kijken naar daemontools. Deze regelt alles voor je...