Já nevím, jak to funguje ve FreebBSD - asi dobře.
Takový typický startskript vypadá takhle:
https://github.com/freebsd/freebsd-ports/blob/master/sysutils/rsyslog8/files/rsyslogd.in- obsahuje jenom deklarace, všechny výkonné části jsou v shellové "knihovně" - společné všem službám.
Že chceš službu startovat při startu OS řekneš tím, že do /etc/rc.conf přidáš jeden řádek:
rsyslogd_enable="YES"
Pokud bys chtěl třeba umístit někam jinam pidfile, přidáš druhý:
rsyslogd_pidfile="/neco/nekde/rsyslogd.pid"
Stejným stylem si může každá služba definovat svoje vlastní optiony, takže třeba do /etc/rc.conf dáš:
slapd_sockets="/neco/nekde/slapd_socket"
Pořadí spouštění to umí (to jsou ty značky PROVIDE, REQUIRE, BEFORE). Supervidovat služby to neumí (pokud to u některé služby chci, používám supervisord).
Samozřejmě některé služby vyžadují trochu speciální zacházení, takže tam se pak nadefinují vlastní start/stop funkce:
https://github.com/freebsd/freebsd-ports/blob/master/www/nginx/files/nginx.inPokud se ta služba chová potřebným způsobem (neforkuje apod.), je to naprosto bezproblémové a rock-solid. Jediné služby, kde jsem zaznamenal větší problémy, jsou erlangové, protože ty při start a stop dělají různé psí kusy a občas funguje blbě restart. Vím to, proto místo restartu dělám start stop, problem solved
Pidfily jsou hack, protože to, že to číslo procesu v pidfilu má nějakou relevanci taky je docela náhoda.
Nevím, jaká by v tom měla být náhoda. Klasické inity prostě po službách požadují, aby se daemonizovaly a zachovaly pid. Pokud se daemonizovat neumí, použije se jako obálka ten zmíněný daemon( 8 ).
Ale vůbec nechápu, co je špatného na tom, že
- daemon je normální unixový standardní program, který normálně běží a může klidně logovat na stdout stderr
- zda je ten program živý kontroluje systémový daemon napřímo
- výstupy jsou pěkně tříděny, opatřeny časovou značkou
- konfigurace se provádí deklarativní formou
Na tom není špatného celkem nic. Však úplně to samé dělá supervisord. Ošemetné je to, že se naprosto klíčová součást systému, na které veškerá stabilita stojí a padá, nahrazuje něčím, co je pro adminy jenom rizikem a nepřináší to víceméně nic, co by se nedalo udělat i bez něj. (viz níž)
Ještě drobná poznámka k
a může klidně logovat na stdout stderr
Tobě jako programátorovi to možná přijde jako super nápad, ale je to jedna z nejhorších věcí, co se dá s logováním udělat. Std{out|err} je totiž
stream. A do logu potřebuješ dostat
záznamy. Takže musíš do toho stdxxx emitovat nějaký strukturovaný formát, který jde na záznamy rozdělit (nejstupidnější řešení je rozdělit ho pomocí \n). Jaké strukturované formáty umí systemd po stdxxx přijímat? Co když budu chtít použít jiný? Tohle já třeba nevím. A musel bych to studovat, zatímco u současných řešení už to mám nastudované a vyřešené. A tohle je přesně ono - pro adminy je
to regres - abys dosáhl funkcionality, kterou máš už teď, musíš znovu investovat práci a ladění a i tak budeš žít v nejistotě, jak se to zachová v situacích, které jsi neotestoval. A tohle všechno, aby ses dostal do stavu stejného (ne lepšího) než jsi měl předtím.Mě to nějak připadá, jako dohadovat se s vývojářem PHP, že přechod na lepší jazyk mu přinese nic než spoustu práce a nejistoty, protože s PHP špagetama už se sžil, vychytal si jejich vlastnosti a žádné úplně zásadní nevýhody nemají. [...] A na argumenty typu "tohle umím, proč bych měl přecházet na něco jiného" začínám být trochu alergický.
Admini jsou přirozeně konzervativní. Každá změna je ohrožení stability. I pokud je to změna vyloženě k lepšímu, pořád je to pro admina nepříjemné. A pokud je to změna, která nic nepřináší, ale zároveň je vysoce riziková, je to prostě enormní osina v ...
Srovnání s PHP je mimo, protože tam předpokládáš vysoký kvalitativní skok (druhý jazyk je třeba daleko produktivnější). To při téhle změně prostě neplatí. Z hlediska admina je to změna pro změnu "aby to bylo čistější".
145 Odpovědí
49138 Zhlédnutí