Fórum Root.cz
Hlavní témata => Software => Téma založeno: Vrták 24. 03. 2013, 11:03:04
-
Nemůžu nic nají, ale možná jsem jen kousek vedle a nevidím. Mám starou binárku 32 bit, která mě z řádku jede, ale ze skriptu se nespustí. Nejsem guru, takže jsem ve skriptu vyzkoušel akorát /usr/local/bin/binarka && echo prikaz prosel a ejhle, on skutečně projde, ale ps -ax jej neukáže a skutečně ani neběží.
Je nějaký rozdíl ve spuštění z řádku a ze skriptu?
Díky za nakopnutí
-
/usr/local/bin/binarka && echo prikaz prosel a ejhle, on skutečně projde, ale ps -ax jej neukáže a skutečně ani neběží.
Konstrukce "a && b" znamená "spusť b v případě, že a skončil bez chyby". Tudíž příkaz skončil a v ps ho vidět nemůžeš.
-
Tak to jsem byl asi vedle tady, ale to nevysvětluje, proč příkaz skončil, když má běžet dál, a pokud naklepu /usr/local/bin/binarka a odentruju, tak i běží.
-
Asi těžko ti někdo poradí, proč ti neběží příkaz, když nenapíšeš jaký.
-
su programy, ktore, aj ked nevyuzivaju vacsinou nevyuzivaju terminal, tak si predsa len skontroluju, ci stdout je terminal, alebo nieco v tom zmysle...
v kazdom pripade, moj navrh je: skus presmerovat vystup (stdout) aj chybovy vystup a budes mudrejsi...
/usr/local/bin/prikaz > log.txt 2>&1 &&
a pozri sa potom do toho suboru
pripadne si pozrit man stranku
mozno ma nejaky prepinac typu: "daemonize", ci "run in background"
-
a ked ani to nepomoze, tak si spusti:
strace /usr/local/bin/prikaz > log.txt 2>&1
a uvidis, ake robi syscall-y, a aky zlyha - niekde blizko konca...
(porovnaj si tie log subory, ked to spustis z konzoly, a zo skriptu, a budes mudrejsi :-)
-
v obou případech je log.txt prázdný
Tohle mě dává jako přepínače
usage: redemptic [-d] [-C <configfile>]
-d run in the foreground (implies -v and -q)
-v be verbose
-q don't use syslog (use on old systems)
-C <configfile> use <configfile> instead of default (/var/etc/redemptic.cfg)
-f filter on specific demux data (saves some CPU,
but some platforms might not handle this very well)
-n show network packets
-s disable server
-t show timing
-l disable self-learning capabilities
-
Mě to přijde, jako by nenašel config, když je spuštěn ze skriptu, protože se chová přesně tak, jako když jej spustím bez parametru -C
-
Mě to přijde, jako by nenašel config, když je spuštěn ze skriptu, protože se chová přesně tak, jako když jej spustím bez parametru -C
A zkoušel jsi to teda pustit přes ten strace?
Kdyby to něco nemohlo najít, viděl bys to tam ...
-
A co vyzkoušet tu -d volbu?
-
Tak jsem to vyzkoušel a oči mě bolej z toho porovnávání logů. Bohužel, se strace mi binarka nenaběhla jak ze skriptu, tak z řádku. A ty logy se krom pidů a ještě pár nepodstatných čísel nelišili v ničem. Nechápu, co tomu může být, v předošlé instalaci debianu to šlo normálně, ale po reinstalaci to takhle zblblo. Debian jsem instaloval ze stejného zdroje, tady chyba nebude. Navíc na podobném stroji - záložném - to běží v pohodě. Já ten prográmek spouštím z rc.local, nemůže být někde chyba v prioritách procesů? - tomu ještě moc nerozumím.
-
Já ten prográmek spouštím z rc.local, nemůže být někde chyba v prioritách procesů? - tomu ještě moc nerozumím.
Jo takhle! No ale to je nová informace, kterou jsi nám nedal. Startovací skripty se spouští v jiném prostředí než jaké máš, když jsi přihlášený. Nejčastější problém je, že startovací skript má jinak nastavenou proměnnou PATH. Zkus do toho skriptu dát název i s celou cestou: "/usr/local/bin/redemptic ..."
Pokud to nepomůže, bude muset poradit někdo, kdo zná konkrétně Debian, co by tam ještě mohlo hrát roli.
-
Při startu terminálu se provede source /etc/profile, tím se přenastaví prostředí. Při startu z cronu, rc scriptu a podobně nastavené není. Často pomůže dát scriptu ono source /etc/profile.
-
Já ten prográmek spouštím z rc.local, nemůže být někde chyba v prioritách procesů? - tomu ještě moc nerozumím.
Jo takhle! No ale to je nová informace, kterou jsi nám nedal. Startovací skripty se spouští v jiném prostředí než jaké máš, když jsi přihlášený. Nejčastější problém je, že startovací skript má jinak nastavenou proměnnou PATH. Zkus do toho skriptu dát název i s celou cestou: "/usr/local/bin/redemptic ..."
+1, nejčastější problém v rc je s PATH ;]
-
v rc.local mám zápis ve tvaru:
/usr/local/bin/redemptic -C /usr/local/etc/redemptic.cfg
parametr -C určuje path ke konfiguračnímu souboru
dále spouštím i jiné procesy, které jsou na sebe vázány, pořadí je žádoucí, ale není nutné, koneckonců můžu redemptic spuštět i ručně, ale z hlediska problému jako takového mi to hlava nebere.
-
Takže změna.
Z rc.local ta binárka spustit jde. Já to doteď zkoušel ze skriptu, který mám jako start pro ruční nahození. Tedy problém se mění na:
Proč jde program spustit z rc.local a z jiného skriptu, vytvořeného rootem nikoliv? Je nějaký rozdíl mezi nima?
-
Kdyz chcete, aby nekdo hledal deset rozdilu, tak sem snad, proboha, dejte posledni verzi tech skriptu!
-
Principialni rozdil mezi spoustenim ze scriptu a primo z radky neni. Oboje vola jednu dalsi funkci, ktera ve skutecnosti rika jadru, jak to spustit (man exec).
Podle toho co popisujes muze za problemy asi nastaveni promennych prostredi. Ty maji ruzni uzivatele/ucty.processy vetsinou jine. Nektery programy (treba ty co pouzivaji home nebo terminal) je casto pouzivaji a pokud nenajdou nebo najdou nejakou nesmyslnou hodnotu, tak muzou spatnout.
-
Nerozčilovat se prosím, nejsem tak znalý, abych vůbec věděl která informace je pro rádce důležitá. Problém je tímto prakticky vyřešen, nicméně se jen snažím přijít tomu na kloub v rámci vlastního posunu ve znalostech. Rozdíl mezi rc.local skriptem není žádný, můj skript jsem psal tak, že jsem si rc.local překopíroval do /usr/local/bin a přejmenoval na start.sh.
Podíval jsem se na oprávnění obou skriptů, jsou stejná, rozdíl je jen v oprávněních adresářů, ve kterých jsou umístěna
root@server:/etc# ls -ld /etc
drwxr-xr-x 70 root root 4096 25. bře 10.20 /etc
root@server:/etc# ls -ld /usr/local/bin
drwxrwsr-x 2 root staff 4096 25. bře 10.41 /usr/local/bin
V docel adobrém článku, který studuju, není nic o rozdílu, který tady vidím- číslo za drwxr-xr-x
Předpokládám, že tady někde bude čokl zahrabán a myslím, že pokud chci koncipovat nějaká svá použitelná skripta, budu muset detailně prostudovat nekonečně složitou problematiku práv a prozatím asi umísťovat skripta v adresáři /etc
-
Ješté doplním, zapoměl jsem na rozdíl root root a root staff v právech adresářů, samozřejmě jsem ho viděl.
-
Ješté doplním, zapoměl jsem na rozdíl root root a root staff v právech adresářů, samozřejmě jsem ho viděl.
Oroboha, skripta zadna radsi nekoncipujte. Uz tak je stav skolstvi v CR tragicky.
A problematika pristupovych prav v *nixech je naopak velice jednoducha (ponechame-li stranou ACL). Pokud chcete neco sloziteho, poridte si Widle. Tam se da nadelat v pravech takovy bordel, ze se v tom ani Ballmer nevyzna.
-
Ďekuji za názor, ale i tak bych přivítal jednoduché vysvětlení, zda-li může mít uvedený rozdíl na svědomí takovéto chování.
Linuxu se budu učit i navzdory jednoduchosti práv v linuxu a bordelu ve widlích.
-
Ďekuji za názor, ale i tak bych přivítal jednoduché vysvětlení, zda-li může mít uvedený rozdíl na svědomí takovéto chování.
Linuxu se budu učit i navzdory jednoduchosti práv v linuxu a bordelu ve widlích.
Jednoduchou odpověď jste dostal. Ano, rozdíly být můžou. Může být použitý jiný shell a před voláním může být jiný environment.. Na konkrétnější odpověď jste poskytl málo informací. Doporučoval bych do skriptů přidat nějaké debugovací výpisy...