Newsgroup: it.comp.os.linux.iniziare
Titolo: script riconnessione

perché
# /etc/rc.d/rc.inet1 restart
in uno shell funziona mentre in uno script per cron no?
ha bisogno di avere un terminale aperto?
se tolgo il #!/bin/sh iniziale e salvo il file come .sh sarebbe lo stesso?
altra domanda, come si fa ad aggiungere una riga a un file di testo?
trovo esempi di sostituzione, ribaltamento e altre cose complicate ma 
non un esempio per la semplice aggiunta;
 
r
 
-- 
 
fumare è obsoleto, prova il Provari:
http://www.svapo.it/bigbattery/modelli/big-battery/provari.html
 
 

 altra domanda, come si fa ad aggiungere una riga a un file di testo?
 
Dipende dall'editor.

 Dipende dall'editor.
 
da inserire nello script bash, per fare una specie di log tipo
connessione persa alle ore 11
connessione persa alle ore 12:30
ecc...
gli è che ho discossioni random tra router e questa macchina, se la sto 
usando mi basta riavviare inet, ma per quando non ci sono pensavo di 
fare uno script tipo
 
#!/bin/bash
 
PING_WAIT=10
 
		ping -q -c 3 -W $PING_WAIT 192.168.0.1 > /dev/null
		PingResult=$?
		if [ $PingResult -eq 0 ]; then
# echo "Ping succeeded" & touch /home/r/PROVA
			:
		else
/etc/rc.d/rc.inet1 restart > /dev/null & touch /home/r/RICONNESSIONE
		fi
 
il > /dev/null non credo serva, l'avevo emsso nel caso non funzionasse 
perché non aveva un terminale dove scrivere;


 e altre cose complicate ma non un esempio per la semplice aggiunta;
 
"aggiungere" in fondo?
 
echo "riga" >> file
 
per tutto il resto:
 
http://www.grymoire.com/Unix/Sed.html#uh-39
 

 
http://www.grymoire.com/Unix/Sed.html#uh-39
 
 
sed mi spaventa ;-P


Io ho un problema con samba che al boot lo dovo avviare ritardato 
(altrimenti parte prima della scheda di rete e muore)
 
lo script è così...
ho messo tutti i path perchè altrimenti non trovava i programmi
NOTA il servizio di samba che ho dovuto lanciare con "sudo -i"
Forse potevo lanciare l'intero script con "sudo -i", togliendomi 
l'inconveniente dei path, è una prova che non ho mai fatto perchè 
<<quando funziona lascialo stare>>
 
#!/bin/bash
 
for((i=0;$i<=120;i=$(($i+1))));do
     #debug attivazione rete
	echo $i 2>&1>>/home/pippo.txt
	/bin/date 2>&1>>/home/pippo.txt
	/sbin/ifconfig eth0 2>&1>>/home/pippo.txt
	/bin/ps aux |/bin/grep smbd 2>&1>>/home/pippo.txt
	grep_line="$(/sbin/ifconfig eth0 | /bin/grep 192.168)"
	echo $grep_line
	echo $grep_line 2>&1>>/home/pippo.txt
	if [ -z "$grep_line" ]; then
		#se eth0 non è su aspetto
		/bin/sleep 1
		echo "PASSO $i" 2>&1>>/home/pippo.txt
		echo passo
	else
		#altrimenti aspetto altri 2 secondi per sicurezza che sia tutto ok
		#e poi faccio ripartire samba
		echo ok
		echo "VIA $i" 2>&1>>/home/pippo.txt
		/bin/sleep 2
		sudo -i /usr/sbin/service smbd restart 2>&1>>/home/pippo.txt
		break
	fi	
done
/sbin/ifconfig eth0 2>&1>>/home/pippo.txt
/bin/ps aux |grep smbd 2>&1>>/home/pippo.txt
 
#FINESCRIPT
 
A me serve al boot e dentro al crontab di root: "sudo crontab -e" ho una 
riga così:
@reboot /path/dello/script.sh &
 
Ovviamente lo script è eseguibile
 

 lo script è così...
 
c'è dentro qlc suggerimento per il mio problema?
mastico quasi niente di bash & C.;
ripeto che se lancio lo script da terminale funziona, in cron funziona 
tutto tranne
/etc/rc.d/rc.inet1 restart
e malgrado RedWiz sostenesse che avrei capito il perché con
/etc/rc.d/rc.inet1 restart 2> /tmp/tuolog
io non l'ho capito ;-P


 c'è dentro qlc suggerimento per il mio problema?
si, non è proprio la stessa configurazione, ma io proverei il 
suggerimento del "sudo -i"
non lo provo da me... perchè ho la rete sta lavorando con database aperti.
 
non so se sia la soluzione, ma sono fiducioso.
sudo -i /etc/rc.d/rc.inet1 restart

 io non l'ho capito 
 
Il file /tmp/tuolog esiste? Se sì qual è il suo contenuto?

 non so se sia la soluzione, ma sono fiducioso.
 
purtroppo lo script viene eseguito come root, non è questo il problema, 
ma che lo script, o meglio, la riga
/etc/rc.d/rc.inet1 restart
non va mentre da shell funxiona;


 Il file /tmp/tuolog esiste? Se sÃ¬ qual Ãš il suo contenuto?
 
l'avevo citato in un msg predente, le ultime righe sono:
 
dhcpcd[19527]: version 5.2.12 starting
dhcpcd[19527]: eth0: broadcasting for a lease
dhcpcd[19527]: eth0: offered 192.168.0.2 from 192.168.0.1
dhcpcd[19527]: eth0: acknowledged 192.168.0.2 from 192.168.0.1
dhcpcd[19527]: eth0: checking for 192.168.0.2
dhcpcd[19527]: received SIGHUP, releasing
dhcpcd[19527]: eth0: removing interface
 
le ultime due penso siano quelle che causano il guaio, ma il perché non 
mi è chiaro;


 andare nello script cronizzato;
 
Scusa ma allora non e' un problema di rete, ma solo di cron?
Se si' allora perche' non provi con un comando semplicissimo?
Io ci capisco poco o nulla di cron, ma so che con la deb occorre 
scrivere la crontab, in ogni caso per esempio questo:
0 20 * 6 * cat /tmp/pippo 
 
mi manda l'output di pippo in una email, per farlo normale bisogna 
dargli:
0 20 * 6 * cat /tmp/pippo > /dev/tty2
 
vabbe' magari son cose che saprai meglio di me certamente, cmq parlando 
certe volte finisce che si risolve tutto.
 
-- 
Tanti saluti
 

 certe volte finisce che si risolve tutto.
 
certo;
ma gli è che lo script cronizzato funziona, infatti nel file 
RICONNESSIONE scrive l'ora della presunta riconnessione, è inet restart 
che non va;
inoltre lo script lanciato in un terminale funziona in tutto e per tutto;


 tutto;
 
senti, soluzione veramente barbona, ma ora sonon di fretta che mi aseptta 
una cena :)
 
prova a replicare l'env di root prima di lanciare il comando
 
quindi:
 
su -
 
dopo: set > ~/env
 
 
e come prima linea in rc.inet1 ci metti un 
 
. /root/env
 
e vedi se va

 e vedi se va
 
ci pensiamo domani, bon apetit;


 purtroppo lo script viene eseguito come root, non è questo il problema,
 
Se hai provato e non funziona OK, ma il sudo non serviva semplicemente a 
diventare root, il flag "-i" gli dice di entrare come se tu avessi fatto 
un login con root, quindi settando tutte le variabili d'ambinete (per la 
roba lanciata da cron di solito l'ambiente non è settato).
 
Pensavo che così rc.inetd si sarebbe comportato alla stessa maniera di 
un lancio manuale.
 
Comunque ho guardare il log... E mi sono accorto di essere partito da 
una FALSA PREMESSA! Mi scuso, ma nelle prime risposte che ho dato, avevo 
erroneamente pensato di essere dentro i.c.o.l.ubuntu e quindi ho dato 
per scontato l'uso del "SUDO"...
Dopo ho visto che non trovavo la roba che dicevi e ho letto meglio e mi 
sono accorto che eravamo su linux generico e c che usi slack.
 
ad ogni modo SCOMMETTEREI che è un problema di ambiente, (se sudo no si 
comporta come su ubuntu) magari butta un occhio a "su", "man su"
 
potrei pensare che forse quello che io faccio con sudo sudo tu lo possa 
fare con:
 
su -l --command /etc/rc.d/rc.inet1
 
darei anche un occhio alle opzioni --shell e --preserve-enviroment
 
UNA PROVA interessante da fare è:
echo $PATH>> /tmp/tuolog
su -l --command echo $PATH>> /tmp/tuolog
 
Sarebbe interessante sapere se corrispondono fra di loro, e anche se 
corrispondono con quella che normalmente ottieni digitando al volo da 
terminale come root.
Nota $PATH è una delle variabili d'ambiente, ma non è detto che sia 
quella incriminata che fa fallire lo script, però probabilmente è diversa.
 
Comunque... per avere un log piu dettagliato
usa la doppia redirezione per appendere al file di log, anzichè 
sovrascrivere
quindi
 
#Apertura del file Con una barra sola per azzerarlo:
echo "INIZIO" 2>&1>/tmp/tuolog
 
#scrive la data (metti tutti gli output successivi di debug con la 
doppia redirezione, in questo modo appende al file /tmp/tuolog)
/bin/date 2>&1>>/tmp/tuolog
 
usa la sequenza 2>&1>> cosi metti anche i messaggi normali nel file di 
log, e non solo i messaggi di errore. puo darsi che ci sia qualche riga 
in più che fa capire dove fallisce

 rkhunter e simili per sicurezza;
 
[21:09:30]   Checking running processes for suspicious files [ Warning ]
[21:09:30] Warning: The following processes are using suspicious files:
[21:09:30]          Command: crontab
[21:09:30]            UID: 0    PID: 3308
[21:09:30]            Pathname: /usr/bin/crontab
[21:09:30]            Possible Rootkit: Unknown rootkit
 
ora provo ad eliminare crontab e reinstallarlo;


 un login con root
 
per tagliare la testa al toro, dopo aver fatto l'operazione del msg 
precedente, riavvio e lancio una sessione come root;



ok, è un problema di compilazione del kernel, con quello d'installazione 
cron funziona normalmente;



da quello che hai detto cron partiva e funzionava (salvo comportamento 
anomalo), la rete funzionava se lo lanciavi manualmente
non mi è chiaro cosa possa essere cambiato con la ricompilazione da 
risolvere il problema.
 
NON CAPISCO, MA MI ADEGUO (non è la prima volta).
 
Sono contento che hai risolto.
 

 risolvere il problema.
 
non ho ricompilato, funziona col kernel dell'installazione, non funziona 
con quello compilato da me in precedenza;
purtroppo non ho capito cosa ho tolto (presumo) di preciso per causare 
il comportamento anomalo;
cmq colgo l'occasione per metter su una Slack current ;-P


 il comportamento anomalo;
 
Scusa ma non puoi per curiosita' dare: diff config.slack config.mio?
 
-- 
Tanti saluti
 

 Scusa ma non puoi per curiosita' dare: diff config.slack config.mio?
 
e chi ci avrei capito?
cmq mi sa che tutta la faccenda era una scusa per metter su questa 
current ;-P
finora solo qlc crash sporadico delle applicazioni;


 non ho ricompilato, funziona col kernel dell'installazione
 
e invece no, solo sul momento;
ho scoperto parte dell'arcano, è kcron che pasticcia;
ho messo il comando nel file /var/spool/cron/crontabs/root e dato chattr 
+1 root per impedire a kcron di metterci mano e va;
se è un baco di KDE si trascina da un bel po' , visto che qui ho la 
versione 4.5.5 e sulla current la 4.8.2;
