a megszokas

emberunk megcsinalta...
/etc/init.d/httpd tartalma :

#!/bin/bash
systemctl $1 httpd.service

( KoGa v | 2016. 04. 27., sze – 09:47 )

Rohadjak meg, én is az /etc/init.d-t használom mai napig. Működik, átszokni meg nehéz.

Nekem pl. totál ismeretlen, ha szeretnék valamit mindig utána kell néznem. Ok, én csak makogom a témát, viszonylag kevésszer kell foglalkoznom vele. Vannak olyan esetek, amikor még csak azt sem tudom hogyan kellene rákeresnem. Korlátozni szeretném a wrappert, mert néha nagyon elszáll a memóriával, korábban rákerestem akár toppal mi lenne az meg hol van, most ez esélytelen. Persze ha valamiről találok dokut akkor OK, de nincs mindenről, a nagymenők akik vágják meg úgy is viselkednek. (SailfishOs)

☆☼♫♪♫♪☼☆
AGA@
Fork portal és az egyik logóm :)

Viszont a sysvinithez van csillió folyóméternyi doksi, meg hozzá hasonló nagyságrendű emberévben mérhető tapasztalat - a systemd nevű monolitikus baszhoz viszont...
Az, hogy a Linux-on nagyon nem tudták/akarták jól használni, annak szerintem részben a lustaság/ismeretek hiánya is az alapja - meg persze az, hogy "csináljunk mindenből mást/újat..." De akkor miért C-ben írják? Várom, hogy valaki kijöjjön mondjuk Java-ban implementált systemd-helyettesítővel :-P

Szerintem nem volt korrekt módon és egyszerűen megoldva a függőség kezelés, amit végre a systemd rendezett. Ennek egy mellékhatása a párhuzamosíthatóság. Ugyanakkor hasznosak a diagnosztikai eszközök is, mint például a systemd-analyze.

Igazából nem értem a prüszkölés okát. Írod, nem tudják, akarják a sysvinit-et jól használni. Ezek szerint a gyakorlatban nem használható jól, mert nem kényszeríti ki a jól használást, igénytelen munkára csábít, vagy bonyolult a megértése, vagy bármi. Tehát nem jó.

Ugyan valóban nem ismerem mélyebben a sysvinit-et, de nem tudom, ott a timeout hogyan van megoldva. Az, hogy minden egyes funkciót minden daemon indításánál, leállításánál egy scriptben egyedileg implementálunk, szerintem nagyon nem korrekt megoldás. A függőségek kezelése is úgy tudom, egyedi gányolások összessége volt korábban.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A függőségek automatikus kezelése by design nem volt cél - viszont faék egyszerűen megoldható: hamarabb indítod, amitől másik szolgáltatás függ. A párhuzamosíthatóság sem volt anno cél - és manapság is csak egy bazi nagy buzzword, pláne szervereknél - egy boot folyamat idejét bőven az határozza meg, hogy a hardver mennyi idő alatt szedi össze magát, az egész folyamatból az OS indulása szinte elhanyagolhatóan kevés idő.

Gyakorlatban jól használható - ha megismered, és tudod, mit, hogyan találtak ki, és miért, mire valók, mire használhatók a futási szintek (van ilyesmi systemd-s környezetben? Pl. tudok úgy indulni, hogy hálózat van, de egyetlen produktív szolgáltatás (db, appszerver, webszerver, és sallangjaik) nem indulnak el, és _egy_ parancs kiadásával (anélkül, hogy tudnom kéne, minek kell indulni) el lehet ezeket indítani?)
Szerintem igényes scriptek írására sarkallja az ésszel élő, gondolkodni, tanulni akaró embert (pedig anno volt olyan mondás, hogy ha saját szolgáltatást akarsz csinálni, akkor fogd az lpd initscriptjét, másold le, szerkeszd át és kész) - megérteni persze meg kell, hogy hogyan működik, de attól még nem rossz.

A timeout kezelése valóban nem definiált - lásd anno a sendmail indulása DNS nélkül - ezt az adott szolgáltatásnak kell megtennie - azaz itt is a jól átgondolt kód elkövetését igényelte az init folyamat.

Lehet(ett) korábban is közös elemket közös, mindenhova behúzott scriptben/konfigban implementálni - senki és semmi nem tiltotta, és éltek is vele nagyon sok esetben - viszont ez picit szembe ment azzal, hogy az initscript lehetőleg legyen önállóan is életképes valami.

Értem én, hogy mindez nem volt cél, valljuk be, a Z80-as CPU esetében sem volt cél 7 bitnél hosszabb sorcímmel memóriát frissíteni, meg 64 kiB-nál több memóriát címezni. Aztán ezen túlnőttek az igények. Szóval azt akarom mondani, hogy ma már nem csak szervereken vannak Linuxok, hanem desktopon, telefonon, beágyazott környezetben, így nem mindegy a boot time. Meg az sem túl nagy baj, ha lehet a függőségeket kezelni, timeout-ot definiálni, timer-t indítani, s ennek egységes felülete van, viszonylag egyszerű konfigurációs file-okkal.

Ami a futási szinteket illeti, szerintem systemd esetén van graphical.target, multi-user.target, rescue.target, reboot.target és poweroff.target.

Ha cinikus lennék, azt mondanám, csinálj egyetlen daemon-t, amely szépen indítgatja a hagyományos scriptjeidet. Csak minek.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

hat nemtom. kezd telilenni ezzel a valamivel a ...

Attoltam mysql to mariadb mintegy 600 adatbazist, erre lerohad es a logban azt kozli velem a centos7-en futo mariacucc, hogy nem tud eleg filet megnyitni.
Neztem nagyot, hogy mivan ? Mindenhol megemeltem.
Marmint ahol eddig kellett.

hat a systemd/system/mariadb.service -ben is meg kell.
http://unix.stackexchange.com/questions/152186/mysql-max-open-files-mor…

szerintem ujabb csuklasrohamot kapott, aki ezt a systemmicsodat kitorpolte.

A cgroups a kernelben van implementálva. Jó, érzékelem, hogy a sok változás, a hagyományok borogatása érint rosszul. Sok esetben én is konzervatív álláspontot képviselek, bár ezúttal ezt - a systemd-t - fejlődésnek tartom.

off

Mellesleg nekem jobban fáj az, hogy az egykori RS-232 soros interface helyett kitalált USB a maga 600 oldalas doksijával olyan bonyolult lett, hogy ha hirtelen kell egy perifériát a géphez illeszteni, azt nem lehet egy délután alatt megtenni, mint az RS-232 esetében. Egyszer szükségem lett volna saját fejlesztésű eszközbe adatot tolni egyszerűen PC-ről, inkább generáltam az átküldendő adatból egy hangfile-t, amely FSK formában tartalmazta az adatot, a mikrokontrolleres oldalon pedig a PC-n lejátszott hangot dekódoltam, és tettem memóriába a megérkezett adathalmazt.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

szerintem igen.
igaz eloszor a /usr/lib/systemd/system alatt levo fileba nyultam bele, de kesobb megcsinaltam a /etc/systemd/system ala is amit javallanak.
viszont ugytunik ez utobbi nem hatasos, a /usr/lib/systemd/system alol meg elfelejtettem kivenni; legalabbis utobbit irta felul a yum, es a frissitesig ment az apache jol.

asszem kell neki egy daemon-reload, meg lehet előtte egy reenable is. Meg lehet érdemesebb inkébb /etc/systemd/system/mariakarmi.d/valami.conf és oda csaka deltát tenni, mert úgy a többi fix, amit hoz egy csomag update a rendes unit fileba (amit a yum jogosan vágott felül) az megmarad.

( tgerczei | 2016. 04. 27., sze – 09:48 )

Nézd, tulajdonképpen ha systemd-alapú a distro és ez csak egy legacy segítség azoknak, akiknek ez szorult az ujjába, nem biztos, hogy érdemel ennél többet. Más kérdés, hogy nem tudom, van-e ennél elegánsabb módja ugyanennek, de sanszos, hogy illene legyen.
------------------------
{0} ok boto
boto ?

( Zahy v | 2016. 04. 27., sze – 11:36 )

Teljesen egyet tudok veled érteni a felháborodásban.

a) először is ha a systemctl elé írna egy exec-et, spórolna egy processzt
b) másodszor nem $1, hanem "$1"
c) harmadszor nem kell kiírni a .service részt
d) negyedszer pedig ha (az immár csökkentett) httpd helyére azt írná, hogy "{0##*/}", akkor máris előállna egy mindegyik szolgáltatáshoz tökéletesen passzoló verzió: 


#!/bin/bash
exec systemctl "$1" "{0##*/}"

és ezt lehetne használni httpd-hez is meg májeskúelhez vagy akár eldaphoz is, és mennyivel olvashatóbb lenne

Az előtted levő hozzászólással együtt, helyesen: 


"${0##*/}"

jelentése: a $0 (azaz amilyen néven hívva volt, pl /etc/init.d/httpd ), és ebből eldobjuk a sztring elejéről (#) a lehető leghosszabb (##) glob sztringet, amit a */ ír le. Azaz az utolsó törtvonalig minden szart kihajítunk, így lesz fentiből simán httpd.

( wladek1 | 2016. 04. 27., sze – 19:32 )

Mondjuk kicsit hajmeregető:
szerettem, mert /etc/init.d/$whatever $act
szerettem, mert service $whaterver $act es mert RH/CentOS alatt is ez az "ajanlott"
erre bejon a csereljunk parametereket tortenet: systemctl $act $whatever
Azt a reszet meg hagyjuk, ahogy ezt Debianek implementaltak.

Illetve ne hagyjuk:
memcached, bind, sorolhatnam nem ugyanugy mukodik init scripttel, mint systemd scripttel (memcached pl nem tud multiple instanceokat kezelni...)
Igy persze en is utalnam a systemd -t (sajnos mar utalom is), pedig igeretesnek tunik, ha nincs osszeganyolva a package maintainerek altal az init

persze, meg hurcibáljam mindenhova, ahol szembejön. nagyon régen leszoktam már arról, hogy ne a default cuccokkal dolgozzak mindenféle szervereken.

nyilván előbb utóbb majd megszokom, vagy nem, most sincs semmi, eltolok egy enervált bémeget, aztán lefuttatom jól. igazából pl az ip a hányás kimenete sokkal jobban zavar.