Dotaz: Restart služby

[Geban]

Zdravím,

potřeboval bych prosím poradit. Linux jsem vyděl jen tak z rychlíku. Potřebuji automatizovat restart jedné služby. Doposud jsem se o to pokoušel takto: upravil jsem /etc/sudoers, abych u tohoto příkazu nemusel zadávat heslo pomocí příkazu AT jsem zadal, kdy se má restart provést (sudo systemctl restart usnl-tcp-sender.service | at 13:08 oct 13)

Výsledkem bylo, že se restart neprovedl. Kde dělám chybu? Nebo mi prosím poraďte nějaká jiný způsob.

Vlastimil Škoda

Odpovědi

[X]

Dve veci. a] Proc je nutne restartovat? Mozna resis neco co lze vyresit jinak, protoze tohle se bezne nedela. b] Prikaz 'at' se davno nepouziva. Kdyz uz to bude nezbytne nutne pouzij systemd timer navazany na sluzbu.

Mimochodem asi ti nebezi sluzba 'atd' a prikaz 'at' je pouze jednorazovy a neprezije to restart.

[Jendа]

1) Minimálně echo sudo systemctl restart usnl-tcp-sender.service | at 13:08 oct 13

2) Nechceš ve skutečnosti něco jako "restartuj když služba spadne", "restartuj když služba přestane posílat keepalive" nebo "restartuj když služba přestane fungovat"?

Osobně jsem at už asi 15 let nepoužil, ale používám cron. Ten teda spouští opakovaně, např. každý den v 13:08:

crontab -e

přidat tam:

# m h  dom mon dow   command
8   13  *   *   *    sudo systemctl restart usnl-tcp-sender.service

(mimochodem můžeš to dát do crontabu roota a neřešit sudo)

případně když něco chci "jednorázově za 3 hodiny", tak pustím screen a v něm pustím "sleep 3h; sudo systemctl restart usnl-tcp-sender.service"

Kdybys chtěl dělat to "restartuj když služba přestane fungovat" tak potřebuješ nějaký skript co řekne jestli funguje a pokud ne tak to restartuje, a spouštět ho cronem třeba každou minutu.

Pokud stačí "restartuj když služba spadne" tak systemctl cat usnl-tcp-sender.service, zjistit kde je ten soubor a pokud je lokálně nainstalovaný (/etc), tak editovat a přidat

pod kapitolu [Service]

přidat 

RestartSec=10
Restart=always

systemctl daemon-reload; systemctl restart usnl-tcp-sender.service.

[Geban]

Služba usnl-tcp-sender.service zasílá data na jiný server. Pokud ten server restartuji (kvůli aktualizacím), tak ta služba ty data přestane posílat a pomáhá jen restart té služby. Chtěl jsem to řešit s dodavatelem, ale nekomunikuje se mnou. Vyzkouším crontab -e.

[X]

Pokud ten server restartuji (kvůli aktualizacím), tak ta služba ty data přestane posílat a pomáhá jen restart té služby.

Proc? Nejaka uzavrena binarka? Muzes byt konkretni co to cele je zac? Jak poznas kdy mas udelat restart?

[Jendа]

Předpokládám, že to otevře TCP spojení, sype data, a když se protistrana restartuje, tak ho to neumí znova navázat a zatuhne to(?) (čekal bych že se to spíš ukončí).

Správné řešení by bylo aby vzdálený server kontroloval, že mu data přicházejí, a pokud přestanou, tak tu službu restartoval (např. přes SSH s vynuceným "command" aby nemohl spouštět jiné příkazy). Případně by šlo to, že data tečou, nejspíš nějak odhadnout z netstatu -- ukazuje stav spojení (established, stalled, disconnected…).

[X]

To myslis vazne? Takze kvuli s prominutim dementni implementaci TCP spojeni nejake pochybne sluzby to budu nejak analyzovat a slozite restartovat? To fakt? To neni reseni problemu. To je jen pridani dalsi verstvy. Az vypadne SSH tak co, vyrobim dalsi sluzbu? Takhle ne. Ma si vyresit re-connect primo v te sluzbe, hotovo. Zadna dalsi zhovadilost navic. Ale co to je za tajnost se tradicne nedozvime..

[Jendа]

To myslis vazne? Takze kvuli s prominutim dementni implementaci TCP spojeni nejake pochybne sluzby to budu nejak analyzovat a slozite restartovat? To fakt?

Ano, fakt, když to je uzavřený software a dodavatel nereaguje.

To neni reseni problemu.

Je to řešení problému.

Az vypadne SSH tak co, vyrobim dalsi sluzbu?

SSH nevypadne, protože to není software neotestovaný na milionech počítačů bez možnosti opravy a bez podpory.

Ma si vyresit re-connect primo v te sluzbe, hotovo.

Jsou lidi, co pokrčí rukama a řeknou „to nejde, to musí udělat Franta“ a pak jsou lidi co to prostě udělají. Jasně, existuje nějaká hranice cost/benefit kdy už není vhodné lepit bastly, ale tazatelův use-case neznáme a podle dosavadního popisu mi to přijde akceptovatelné.

[X]

Ano, fakt, když to je uzavřený software a dodavatel nereaguje

Jestli je to uzavrene se nevi.

[Geban]

Ta služba posílá polohy vozidel do jiného systému. Protokol neznám. Jakmile protistrana vypadne, spojení se neobnoví. Správné řešení je oprava dodavatele. Ten bohužel nekomunikuje. Abych to nemusel restartovat ručně, hledám způsob, jak ten restart naplánovat. Snad tenhle týden se k tomu dostanu, abych to otestoval. Jinak všem moc děkuji za reakce.

[X]

Asi nechapes, ze oprava je potreba idealne primo v te sluzbe/aplikaci, ale kdyz se od tebe nedozvime co to je konkretne zasluzbu/program, jak funguje jake ma parametry a jeke jsou jeji moznosti tak tezko radit. Mysto toho se tady vymysli dalsi udelatko, ktere to cele jeste dal zkomplikuje. Jak vypada obsah souboru sluzby? Jak se software jmenuje? Ma to treba log, kde je videt co se tomu deje?

[Geban]

Chápu, že oprava je potřeba přímo v té službě. To může udělat jen dodavatel = tvůrce. Jediné co vím je, že když se dispečerům přestanou zobrazovat pozice vozidel, musím restartovat tu službu. Nevím jaké má parametry, nevím jak funguje. Jedná se víceméně o systém vyrobený na zakázku o kterém se toho moc zjistit nedá. Vyrábí to firma Mikroelektronika s. r. o. Tato firma dělá odbavovací systémy. Žádné podrobnosti jsem k tomu systému nedostal. Takže vám je ani nemůžu dát. Ta firma ten systém zpravuje vzdáleně, žádnou dokumentaci jsem k tomu nedostal. Nic víc nevím. O problému jsem je již několikrát informoval, ale bez odezvy, tak se to snažím vyřešit po svém.

[X]

Chápu, že oprava je potřeba přímo v té službě. To může udělat jen dodavatel = tvůrce.

Nesmysl. Nahore pises o /etc/sudoes takze pristup k tomu celemu ocividne mas. Co vic si muzes prat? Chapu, ze se v tom asi nechces moc "hrabat", ale asi ti syejne nic jineho nezbude. Takze to tady muzeme spolecne nejak vyresit. Je monze, ze to nebude tak horke, ale bez tve soucinosti = dodani vystupu to nepujde. Chces to jenom restsrtovat? Stejne bude lepsi kdyz ukazes o cem se tu bavime = obsah souboru usnl-tcp-sender.service. At se nekam konecne posuneme. Ok?

[Geban]

Nikdy jsem netvrdil, že k tomu přístup nemám. Linux neovládám a hrabat se v tom taky nechci, ale ať je po tvém. Jak zobrazím obsah souboru usnl-tcp-sender.service?

[Geban]

Znovu tu zdůrazňuji, jsem Windowsák jak poleno, tak podle toho ke mě přistupujte.

[Jendа]

systemctl cat usnl-tcp-sender.service

[Geban]

# /etc/systemd/system/usnl-tcp-sender.service [Unit] Description=usnl TCP listener/sender service [Service] User=dpmul

WorkingDirectory=/home/XTCBO/usnl-tcp-listener-sender

ExecStart=/home/XTCBO/usnl-tcp-listener-sender/usnl-tcp-sender.sh

SuccessExitStatus=143 TimeoutStopSec=10 Restart=on-failure RestartSec=5 [Install] WantedBy=multi-user.target

[Geban]

Nevím, jestli je úplně moudré tu něco zveřejňovat. Nerad bych se dostal do nějakých problémů. Takže asi takhle. Poraďte mi prosím jak efektivně v linuxu restartovat službu usnl-tcp-sender.service každý den v 1:10. Nic víc nic míň a tím bych to uzavřel. Díky.

[Jendа]

# crontab -e (pod rootem, např. sudo -i)

přidat tam:

# m h  dom mon dow   command
10  1  *   *   *     systemctl restart usnl-tcp-sender.service

pak se koukej do /var/log/syslog, jestli se tam v 1:10 objeví že se to spouští. Ideální je mít nainstalovaného nějakého poštovního agenta, protože cron posílá výsledky mailem. Což teda jako hodně štěstí nastavit…

Vida, tady by se hodilo řešení se systemd timerem, protože ten loguje do journalu a není tak potřeba mít funkční systémovou poštu. Andrej poradí, já s tím mám nedostatek zkušeností.

[Geban]

Díky. Vyzkouším a dám vědět, jak jsem dopadl.

[Bugsa]

Upravit systemd unit na následující. Takto se bude restartovat přesně každých 24h.

[Service]

Restart=always

RuntimeMaxSec=86400

[🇨🇽]

RuntimeMaxSec=86400

si ale přectav co se jakoby stane, když si jednou třeba v 10:00 dopoledne ze serverovny udělaj ředitel se sektretářkou šmajchlkabinet a páč nato potřebujou tmu tak vypnou pojistky v celý mistnosti páč si myslej že ty jističe v prosklený skřiňce u dveří sou ňáký normální vypinače vod lustrů :O :D :O :D Hnedka jim dojde že uďáli ňákou pitomost znova to nahoděj ale nikomu nic neřeknou a k čemu to jako povede:

....nóó další den se to taky restartuje někdy po desátý a je šance žeti to možná nezaloguje auto nebo co to všecko dělá :O ;D správný řešení by asi jako byly ty už zminěný timery hele :D ;D

[Peter Golis]

Správne by bolo nastaviť unitu tak, aby sa v prípade dočasného výpadku sama pokúsila niekoľko krát nahodiť. A ak by sa jej to nepodarlo, tak by mala vygenerovať udalosť pre monitoring dostupnosti aby sa niekto na ten výpadok pozrel.

[Bugsa]

To je fakt, to se mě nebo řediteli v serverovně stává často. :)

Máš pravdu, timer je nejlepší řešení. Ale když už nikomu nevadí, že se to zasekne v pracovní době a čekají než to tazatel restartuje ručně, tak si případného rychlého restartu v 10:00 dopoledne nikdo nevšimne. :D

[X]

Vy to nemate zaplacene? Stalo to 5,- korun? Pokud je to zaplacene je to tvoje a muzes si tim delat, co, chces. Dodavatel je problemovy a software bez dokumentace? Vase chyba, ale potom sem nechod volaat o pomoc a laskave si tu situaci nejak vyreste mezi sebou ok? Az se objevi dalsi problem co budes delat?

[Geban]

Klid, praskne ti cévka a budeš tahat nohu. Nestojí to za to.

[X]

Tak sem pak nechod brecet a zebrat ok?

[Geban]

Ano tati.

[Jendа]

Pokud je to zaplacene je to tvoje a muzes si tim delat, co, chces.

To není pravda, většinu placeného softwaru nesmíš dále šířit. (ačkoli zrovna uvedený .service soubor je tak standardní, že na něj autorskou ochranu nárokovat nelze)

[X]

Tak jasne, ale o to tady zrovna nejde.

[🇨🇽]

zkus to 'on-failure' přepsat na 'always', je šance že ten skript unsl-tcp.sender.sh končí čistým exit codem :D

schvalně koukni na status až ta služba 'chcípne' jestli je tam furt psaná jako aktivní/běžicí/running

sudo systemctl status usnl-tcp-sender

připadně koukni do logu co to tam psalo předtim:

sudo journalctl | grep usnl-tcp-sender

pokud skončila sama, tak štěstí a 'always' bude fungovat, páč restartuje službu uplně dycky, ať skončí uplně jakkoliv. Pokud ale ta usnl-tcp-sender zustala běžet tak smula a bude se to muset řešit jinak :D ;D

[Jendа]

Nahore pises o /etc/sudoes takze pristup k tomu celemu ocividne mas. Co vic si muzes prat?

Zdrojáky, pokud dostal jenom zkompilovanou binárku?

[X]

Je to lama a ma strach, zadne reverzovani nebude ;(

[k3dAR]

ja tam vidim ze ta sluzba spousti nejakej shell script ExecStart=/home/XTCBO/usnl-tcp-listener-sender/usnl-tcp-sender.sh

[🇨🇽]

v *.sh skriptu ale jakoby muže bejt skovaná binarka nějaká, hele třeba :O ;D

[🇨🇽]

....noa nebo ten skript prostě jako jednoduše muže ňákou binarku pouštět :D

[X]

SuccessExitStatus=143

Bude to Java. Aktorat nejak naprasena kdyz to musi poustet shell skriptem.

[Jendа]

To někdo vzal existující init skript a udělal z něj unitu

[Ruža Becelin]

> Správné řešení je oprava dodavatele. Ten bohužel nekomunikuje.

Jakou mate SLA?

[Geban]

To nevím, to jsem z nadřízených nedostal. Samozřejmě jsem je o nekomunikujícím dodavateli informoval, ale jestli s tím něco budou dělat nevím. Je i možný, že management podniku udělal chybu a smlouvu nemá, ale to už já nevyřeším. Víte jak to chodí.... Pokud si s tím IT nějak poradí (restartuje to třeba ručně nebo něco podobného) a chod podniku to nějak vážně neohrožuje, řešit to nebudou. Až to lehne do té míry, že to nedokážeme nahodit, začnou být aktivní. Taková je bohužel realita. Chápu, že je špatné to řešit restartem, ale hrabat se v tom systému tak, abych se to pokusil opravit nehodlám, protože Linux neovládám. Jinak crontab -e zafungoval, ale upravil jsem ho takto: 10 1 * * * sudo systemctl restart usnl-tcp-sender.service. Otestoval jsem to tak, že jsem nastavil restart na 10:00 a v 9:59 jsem službu stopnul a odhlásil se. V 10:00 služba naběhla. Moc děkuju za rady, ušetřili jste mě nočních ručních restartů.

[Andrej]

Y když jsy Lynux vyděl jenom z rychlýku, pořád můžeš použýt prvňý odkaz z onlyne vyhledáváňý.

Přýkaz at souvysý se ďyvokými 90. lety a zastaralým a nefunkčňým nesmyslem zvaným cron. Naštěsťy cron už dávno nahraďyly systemd .ťymer unyty, které navýc v takto tryvyjálňým přýpadě nejsou aňy potřeba a lze použýt přýmo nastaveňý RunťymeMaxSec.

Modyfykace unyt souboru vestavěného v dystrybucy je možná pomocý drop-yn souboru (napřýklad v /etc/systemd/system/modyfykovaná.servyce.d/dropyn.conf). Návodů je na to onlyne spousta.

[Vtipnéř]

Obdivuji Andreje, že tohle dokáže napsat (bez ironie). Mně by se při tom asi zatmělo před očima nebo by mi zdřevěněly prsty na rukou.

Jirka

[🇨🇽]

podle slovyček 'ťymer' nebo 'runťyme' kde je napsaný 'ť' ykdyž by tam nemělo bejt to spýš výc vypadá na ňákej skrypt dělanej jenom pro čéďynu :D ;D

....nadruhou stranu se ale takle jako fakt dá psát, nóó tak nevym :D

[Andrej]

Co ty vyš, jak se řekne ťymer v ostravske anglyčťyně?!

[fetka]

Ty a Gréta jste tu samej hate spíče.

[Andrej]

Smym se zeptat, jaky hate spyč kde vyďyš? Většynou jsem shovyvavost sama.

[fetka]

Ty hejtuješ EXT4 a Gréta zase našeho upocenýho premiéra a jeho skvadru.

[Andrej]

Nehejtuju Ext Čtyřy, stejně jako nejehtuju parňy stroj.

Obojy ma sve jyste a čestne mysto v hystoryjy. (Ňykolyv však v přytomnosťy.)