Topic: [risolto] Watchdog su linux rig, consigli? (Read 2968 times)
Nel mio caso perché a volte occorre riavviare anche gli fga e il router che hanno alimentazione esterna.
Ragazzi discussione interessante, se io metto il codice per il relè e la LAN di un Arduino, qualcuno ha voglia di mettere insieme uno script che esegue shutdown + stacco del relè per fare il reboot?
Posso scrivere tranquillamente una guida per gestire la parte hardware (saldature, ponticelli, cose da comprare ecc)
Domanda da lettore incuriosito senza essere minatore: perché volete aggiungere dell'hardware (e quindi un consumo di materia e di energia, oltre che di denaro per l'acquisto e di tempo per l'assemblaggio) quando un watchdog hardware (che è ciò che volete ottenere) è già integrato nel Raspberry Pi? (vedansi risposte di bersani)Posso scrivere tranquillamente una guida per gestire la parte hardware (saldature, ponticelli, cose da comprare ecc)
Ciao!
Ho letto di qualcuno che lo lascia acceso 24/7 anche per un mese... cosa che mi sconvolge assai.
Yo !
Il mio Raspberry pi se non fosse per la corrente che ognitanto va via con i temporali tira da più di due mesi i miei Lancelot senza il minimo problema, basta metterlo in verticale per raffreddare anche "il lato b".
Anche il mio rig con le 5850 girava h24 (tutto il mese di aprile) poi per tenere bassa la botta l'ho programmato per minare solo dalle 19 alle 7. Comunque ho speso altri 100 euro solo di dissipatori "da overclock", in modo da tenere le ventole basse (ne beneficia anche il deposito di polvere)
Ho letto di qualcuno che lo lascia acceso 24/7 anche per un mese... cosa che mi sconvolge assai.
Yo !
Ragazzi discussione interessante, se io metto il codice per il relè e la LAN di un Arduino, qualcuno ha voglia di mettere insieme uno script che esegue shutdown + stacco del relè per fare il reboot?
Posso scrivere tranquillamente una guida per gestire la parte hardware (saldature, ponticelli, cose da comprare ecc)
Posso scrivere tranquillamente una guida per gestire la parte hardware (saldature, ponticelli, cose da comprare ecc)
Vedo già un possibile progetto su kickstarter.
"bitcoin hardware watchdog"
Un piccolo hardware specializzato solo per il mining, script più arduino.
Secondo me avresti tanti acquirenti quanti minatori GPU
Piuttosto, domanda en passant.
Su linux c'è un watchdog software che riavvia il pc quando una scheda è sick?
In alternativa, ogni quando impostate un reboot automatico per ovviare a problemi tipo crash dei driver che su linux sto notando sono un po' instabili?
Io pensavo "per sicurezza" ogni sei ore, così da far riposare anche le schede per qualche secondo (cgminer nn prevede pause programmate sfortunatamente).
Ma forse 6 ore sono pochine, 12? 24? una sett?
Ho letto di qualcuno che lo lascia acceso 24/7 anche per un mese... cosa che mi sconvolge assai.
Ragazzi discussione interessante, se io metto il codice per il relè e la LAN di un Arduino, qualcuno ha voglia di mettere insieme uno script che esegue shutdown + stacco del relè per fare il reboot?
Posso scrivere tranquillamente una guida per gestire la parte hardware (saldature, ponticelli, cose da comprare ecc)
Posso scrivere tranquillamente una guida per gestire la parte hardware (saldature, ponticelli, cose da comprare ecc)
Risolto
Svolgo tutti i passaggi così torna utile anche a qualcun altro in futuro.
Allora:
Avvio al boot, nessun ping visto che il watchdog fa casino quando si tratta di controllare la connessione internet.
Poi, scopiazzando un po' qua e la e imparando ad usare crontab:
salvare, uscire, rendere eseguibile
Salvare e uscire.
Ogni 3 minuti controlla l'ip del dns di google e se non è pingabile, riavvia.
usando eth0 funziona per qualsiasi connessione, sia wlan0 che la chiavetta internet 3g.
Ho messo ogni tre minuti perché il riavvio avviene in un possibile arco di tempo x2.
Se la connessione cade proprio dopo il primo controllo, devono passare 3 minuti prima che controlli di nuovo e poi altri tre minuti perché confermi il down e inizializzi il riavvio.
Nel mio caso volevo proprio il riavvio perché, quando muore la chiavetta, hamachi anche se ritorna la connessione non torna UP.
Grazie a tutti!
Svolgo tutti i passaggi così torna utile anche a qualcun altro in futuro.
Allora:
Code:
sudo apt-get install watchdog
E così sono a posto nel caso di eventuali crash del sistema.Avvio al boot, nessun ping visto che il watchdog fa casino quando si tratta di controllare la connessione internet.
Poi, scopiazzando un po' qua e la e imparando ad usare crontab:
Code:
sudo mkdir /opt/check_lan
sudo nano /opt/check_lan.sh
sudo nano /opt/check_lan.sh
Code:
#!/bin/sh
# cron script for checking wlan connectivity
# change 8.8.8.8 to whatever IP you want to check.
IP_FOR_TEST="8.8.8.8"
PING_COUNT=1
PING="/bin/ping"
IFUP="/sbin/ifup"
IFDOWN="/sbin/ifdown --force"
INTERFACE="eth0"
FFLAG="/opt/check_lan/stuck.fflg"
# ping test
$PING -c $PING_COUNT $IP_FOR_TEST > /dev/null 2> /dev/null
if [ $? -ge 1 ]
then
logger "$INTERFACE seems to be down, trying to bring it up..."
if [ -e $FFLAG ]
then
logger "$INTERFACE is still down, REBOOT to recover ..."
rm -f $FFLAG 2>/dev/null
sudo reboot
else
touch $FFLAG
logger $(sudo $IFDOWN $INTERFACE)
sleep 10
logger $(sudo $IFUP $INTERFACE)
fi
else
# logger "$INTERFACE is up"
rm -f $FFLAG 2>/dev/null
fi
# cron script for checking wlan connectivity
# change 8.8.8.8 to whatever IP you want to check.
IP_FOR_TEST="8.8.8.8"
PING_COUNT=1
PING="/bin/ping"
IFUP="/sbin/ifup"
IFDOWN="/sbin/ifdown --force"
INTERFACE="eth0"
FFLAG="/opt/check_lan/stuck.fflg"
# ping test
$PING -c $PING_COUNT $IP_FOR_TEST > /dev/null 2> /dev/null
if [ $? -ge 1 ]
then
logger "$INTERFACE seems to be down, trying to bring it up..."
if [ -e $FFLAG ]
then
logger "$INTERFACE is still down, REBOOT to recover ..."
rm -f $FFLAG 2>/dev/null
sudo reboot
else
touch $FFLAG
logger $(sudo $IFDOWN $INTERFACE)
sleep 10
logger $(sudo $IFUP $INTERFACE)
fi
else
# logger "$INTERFACE is up"
rm -f $FFLAG 2>/dev/null
fi
salvare, uscire, rendere eseguibile
Code:
sudo nano /etc/crontab
*/3 * * * * root /opt/check_lan.sh >/dev/null
*/3 * * * * root /opt/check_lan.sh >/dev/null
Salvare e uscire.
Ogni 3 minuti controlla l'ip del dns di google e se non è pingabile, riavvia.
usando eth0 funziona per qualsiasi connessione, sia wlan0 che la chiavetta internet 3g.
Ho messo ogni tre minuti perché il riavvio avviene in un possibile arco di tempo x2.
Se la connessione cade proprio dopo il primo controllo, devono passare 3 minuti prima che controlli di nuovo e poi altri tre minuti perché confermi il down e inizializzi il riavvio.
Nel mio caso volevo proprio il riavvio perché, quando muore la chiavetta, hamachi anche se ritorna la connessione non torna UP.
Grazie a tutti!
Lancialo prima a mano prima di configurarlo in crontab. Anzi lo farei controllare ogni 5 minuti invece di ogni minuto, perchè il crontab parte sicuramente prima della tua connessione eheh
FaSan
FaSan
Allora... non testato ma dovrebbe andare...
prima di tutto lanci un "ifconfig" con la connessione attiva, e vedi il nome dell' interfaccia 3G creata (per esempio 3G-PPP), poi lanci un lsusb per identificare il device della chiavetta (ipotizziamo 1.3.5), configura lo script :
#!/bin/bash
t1=$(ifconfig | grep -o 3G-PPP)
t2='3G-PPP'
if [ "$t1" = "$t2" ]; then
exit
else
echo suspend > /sys/bus/usb/devices/1-3.5/power/level
sleep 2
echo on > /sys/bus/usb/devices/1-3.5/power/level
sleep 2
ifup 3G-PPP
fi
exit
salva in /root/check3g.sh, poi in crontab così :
*/1 * * * * root /root/check3g.sh
Facci sapere ;-)
FaSan
prima di tutto lanci un "ifconfig" con la connessione attiva, e vedi il nome dell' interfaccia 3G creata (per esempio 3G-PPP), poi lanci un lsusb per identificare il device della chiavetta (ipotizziamo 1.3.5), configura lo script :
#!/bin/bash
t1=$(ifconfig | grep -o 3G-PPP)
t2='3G-PPP'
if [ "$t1" = "$t2" ]; then
exit
else
echo suspend > /sys/bus/usb/devices/1-3.5/power/level
sleep 2
echo on > /sys/bus/usb/devices/1-3.5/power/level
sleep 2
ifup 3G-PPP
fi
exit
salva in /root/check3g.sh, poi in crontab così :
*/1 * * * * root /root/check3g.sh
Facci sapere ;-)
FaSan
Mah direi che non serve. RC.LOCAL è l' ultimo ad essere eseguito. Quindi anche con RC3.d non risolvi.
Lo sospettavo.
Per quanto riguarda il blocco del modem anche a me capitava (modem 3g) che si disconnettesse (e non sembrava esserci modo di riconnetterlo senza riavviare)
Si, stessa cosa capita anche a me. Forse le chiavette non sono fatte per continuare a funzionare interrottamente. Poi ogni tanto l'operatore 3 riavvia la rete (di solito a notte fonda) e li salta la connessione.
Linux non è affatto complicato, anzi è molto semplice.. questo non significa che sia facile
Aspé, vuoi ridere?
Ho cercato di settare in modo permanente la time zone e il cambio d'ora... e ho fallito più e più volte.
Prima di scoprire che non basta settarla, bisogna anche dare il comando per scriverla nel cmos...
Non mi pare proprio semplice
FaSan, se condividi anche tu i dettagli dello script, magari mixandoli risolvo
In ogni caso ringrazio entrambi
Un giorno qualcuno dovrà spiegarmi perché con linux è sempre tutto così complicato
Linux non è affatto complicato, anzi è molto semplice.. questo non significa che sia facile
Certo è che tutte le cose che in Linux ti sembrano difficili, su altri OS nemmeno le puoi fare o comunque non con lo stesso livello di personalizzazione+sicurezza.
Per quanto riguarda il blocco del modem anche a me capitava (modem 3g) che si disconnettesse (e non sembrava esserci modo di riconnetterlo senza riavviare), ho risolto con uno script che ogni minuto controllava se c'era internet o meno e in caso negativo, tramite uno script che faceva delle apposite chiamate al kernel, emulava la disconnessione/riconnessione fisica del modem che tornava poi ad essere funzionale (e quindi poi lo riconnetteva a internet).
In effetti è più semplice. Piccolo script lanciato da crontab, con verifica ogni minuto.
Dovrei avere da qualche parte... muble muble.. un piccolo applicativo che spegne fisicamente la porta USB e la riaccende. Te lo trovo e te lo mando.
FaSan
Un giorno qualcuno dovrà spiegarmi perché con linux è sempre tutto così complicato
Linux non è affatto complicato, anzi è molto semplice.. questo non significa che sia facile
Certo è che tutte le cose che in Linux ti sembrano difficili, su altri OS nemmeno le puoi fare o comunque non con lo stesso livello di personalizzazione+sicurezza.
Per quanto riguarda il blocco del modem anche a me capitava (modem 3g) che si disconnettesse (e non sembrava esserci modo di riconnetterlo senza riavviare), ho risolto con uno script che ogni minuto controllava se c'era internet o meno e in caso negativo, tramite uno script che faceva delle apposite chiamate al kernel, emulava la disconnessione/riconnessione fisica del modem che tornava poi ad essere funzionale (e quindi poi lo riconnetteva a internet).
Sarebbe utile a questo punto sapere come lanci la connessione. Hai parlato di una chiavetta 3G quindi dovrebbe esserci un demone PPPd
A boh.
Ho configurato la chiavetta, inserito i parametri di connessione, settato disponibile per tutti gli utenti e "connetti automaticamente".
Impostazione di base di network manager.
All'avvio, appena compare il desktop dopo qualche secondo la chiavetta si logga e la connessione diventa disponibile.
Il reboot con il watchdog avviene "ore prima" che si presenti il desktop.
Non ci arrivo nemmeno a vederlo il desktop
Ho idea che anche rc3.d lavori troppo d'anticipo ma ora provo cmq.
Mah direi che non serve. RC.LOCAL è l' ultimo ad essere eseguito. Quindi anche con RC3.d non risolvi.
Non c'è un parametro di delay direttamente dentro la configurazione watchdog ?
Sarebbe utile a questo punto sapere come lanci la connessione. Hai parlato di una chiavetta 3G quindi dovrebbe esserci un demone PPPd
A boh.
Ho configurato la chiavetta, inserito i parametri di connessione, settato disponibile per tutti gli utenti e "connetti automaticamente".
Impostazione di base di network manager.
All'avvio, appena compare il desktop dopo qualche secondo la chiavetta si logga e la connessione diventa disponibile.
Il reboot con il watchdog avviene "ore prima" che si presenti il desktop.
Non ci arrivo nemmeno a vederlo il desktop
Ho idea che anche rc3.d lavori troppo d'anticipo ma ora provo cmq.
Sarebbe utile a questo punto sapere come lanci la connessione. Hai parlato di una chiavetta 3G quindi dovrebbe esserci un demone PPPd
Per rc.local ti basta mettere, prima del "touch" il comando da lanciare (per esempio) :
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.
/etc/init.d/watchdog start
touch /var/lock/subsys/local
FaSan
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.
/etc/init.d/watchdog start
touch /var/lock/subsys/local
FaSan
Ok, questo non funziona (sto provando su debian)
Disabilitato il watchdog al boot.
Aggiunto il watchdog al rc.local secondo la tua linea ma non succede nulla (nel mio file cmq non era presente touch, ma exit 0 e basta).
Se avvio il watchdog a mano dal terminale e la connessione non è attiva, il reboot avviene correttamente
Proviamo un po' quella cosa dei link rc3.d
EDIT:
cambiando la linea in rc.local da
Code:
/etc/init.d/watchdog start
a Code:
watchdog start
Il pc torna in un loop di reboot infinito.
Suppongo che quindi il watchdog parta, ma anche stavolta troppo presto rispetto allo stabilirsi della connessione internet.
Per rc.local ti basta mettere, prima del "touch" il comando da lanciare (per esempio) :
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.
/etc/init.d/watchdog start
touch /var/lock/subsys/local
FaSan
#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.
/etc/init.d/watchdog start
touch /var/lock/subsys/local
FaSan
Hai due strade:
- Modifichi manualmente i link in rc3.d impostando un numero più alto di startup e facendolo eseguire dopo il network
- Non lo fai partire in automatico al boot ma lo lanci da rc.local (che è l' ultimo ad essere eseguito a macchina avviata)
Senza dilungarmi troppo, i demoni vengono eseguiti nell' ordine che trovi nel link simbolico, dal numero 1 al numero 99, quindi ti basta vedere a che livello (numero) parte il network per farlo poi partire dopo.
- Modifichi manualmente i link in rc3.d impostando un numero più alto di startup e facendolo eseguire dopo il network
- Non lo fai partire in automatico al boot ma lo lanci da rc.local (che è l' ultimo ad essere eseguito a macchina avviata)
Senza dilungarmi troppo, i demoni vengono eseguiti nell' ordine che trovi nel link simbolico, dal numero 1 al numero 99, quindi ti basta vedere a che livello (numero) parte il network per farlo poi partire dopo.
Un giorno qualcuno dovrà spiegarmi perché con linux è sempre tutto così complicato
Cmq vado a spulciare i link rc3.d
Nel frattempo puoi darmi qualche info in più su come lanciarlo da rc.local?
Anche un link va benissimo
Mi tengo una possibilità aperta prima di fare casino con rc3.d
Altra cosa importante da dire è che non vengono eseguiti in background ma in ordine. Mettendo quindi un delay nello script non risolvi nulla se non rallentare la macchina nella fase di startup.
Teamviewer "devo" lanciarlo con 120 secondi di ritardo rispetto all'avvio del sistema, perché altrimenti tutte le connessioni in entrata si freezzano.
Pensavo di cavarmela aggiungendo lo watchdog allo stesso script, ma era pia illusione
Altra cosa importante da dire è che non vengono eseguiti in background ma in ordine. Mettendo quindi un delay nello script non risolvi nulla se non rallentare la macchina nella fase di startup.
FaSan
FaSan
esempio di link simbolici in rc3.d :
lrwxrwxrwx 1 root root 16 Mar 8 12:16 K01smartd -> ../init.d/smartd
lrwxrwxrwx 1 root root 16 Mar 8 12:16 K10psacct -> ../init.d/psacct
lrwxrwxrwx 1 root root 19 Mar 8 12:16 K10saslauthd -> ../init.d/saslauthd
lrwxrwxrwx 1 root root 22 Jun 26 11:55 K15htcacheclean -> ../init.d/htcacheclean
lrwxrwxrwx 1 root root 20 Mar 8 12:16 K50netconsole -> ../init.d/netconsole
lrwxrwxrwx 1 root root 15 Jun 26 11:48 K75netfs -> ../init.d/netfs
lrwxrwxrwx 1 root root 17 Mar 8 12:16 K75ntpdate -> ../init.d/ntpdate
lrwxrwxrwx 1 root root 19 Mar 8 12:16 K75quota_nld -> ../init.d/quota_nld
lrwxrwxrwx 1 root root 15 Jul 4 23:52 K86cgred -> ../init.d/cgred
lrwxrwxrwx 1 root root 21 Mar 8 12:16 K87restorecond -> ../init.d/restorecond
lrwxrwxrwx 1 root root 15 Jun 26 11:39 K89rdisc -> ../init.d/rdisc
lrwxrwxrwx 1 root root 19 Jul 8 01:30 K92ip6tables -> ../init.d/ip6tables
lrwxrwxrwx 1 root root 18 Jul 4 23:52 K95cgconfig -> ../init.d/cgconfig
lrwxrwxrwx 1 root root 22 Mar 8 12:16 S02lvm2-monitor -> ../init.d/lvm2-monitor
lrwxrwxrwx 1 root root 18 Jun 26 12:10 S08iptables -> ../init.d/iptables
lrwxrwxrwx 1 root root 17 Jun 26 11:39 S10network -> ../init.d/network
lrwxrwxrwx 1 root root 16 Mar 8 12:16 S11auditd -> ../init.d/auditd
lrwxrwxrwx 1 root root 21 Mar 8 12:16 S11portreserve -> ../init.d/portreserve
lrwxrwxrwx 1 root root 17 Mar 8 12:16 S12rsyslog -> ../init.d/rsyslog
lrwxrwxrwx 1 root root 20 Mar 8 12:16 S13irqbalance -> ../init.d/irqbalance
lrwxrwxrwx 1 root root 19 Mar 8 12:16 S15mdmonitor -> ../init.d/mdmonitor
lrwxrwxrwx 1 root root 20 Mar 8 12:16 S22messagebus -> ../init.d/messagebus
lrwxrwxrwx 1 root root 26 Mar 11 11:11 S25blk-availability -> ../init.d/blk-availability
lrwxrwxrwx 1 root root 19 Mar 8 12:16 S26udev-post -> ../init.d/udev-post
lrwxrwxrwx 1 root root 14 Mar 8 12:16 S55sshd -> ../init.d/sshd
lrwxrwxrwx 1 root root 16 Jun 26 12:10 S64mysqld -> ../init.d/mysqld
lrwxrwxrwx 1 root root 17 Jul 7 22:42 S79bitcoin -> ../init.d/bitcoin
lrwxrwxrwx 1 root root 17 Jul 10 00:00 S80postfix -> ../init.d/postfix
lrwxrwxrwx 1 root root 17 Jun 26 12:10 S80proftpd -> ../init.d/proftpd
lrwxrwxrwx 1 root root 15 Jun 26 12:10 S85httpd -> ../init.d/httpd
lrwxrwxrwx 1 root root 15 Mar 8 12:16 S90crond -> ../init.d/crond
lrwxrwxrwx 1 root root 13 Mar 8 12:16 S95atd -> ../init.d/atd
lrwxrwxrwx 1 root root 11 Jun 26 11:39 S99local -> ../rc.local
I "K" sono i demoni disabilitati, la "S" quelli abilitati, nel mio caso il Network è a S10, e per esempio SSHD a S55. Se fosse stato a S09 per esempio sarebbe partito prima del network, con conseguente errore.
Come vedi a S99 c'è rc.local
FaSan
lrwxrwxrwx 1 root root 16 Mar 8 12:16 K01smartd -> ../init.d/smartd
lrwxrwxrwx 1 root root 16 Mar 8 12:16 K10psacct -> ../init.d/psacct
lrwxrwxrwx 1 root root 19 Mar 8 12:16 K10saslauthd -> ../init.d/saslauthd
lrwxrwxrwx 1 root root 22 Jun 26 11:55 K15htcacheclean -> ../init.d/htcacheclean
lrwxrwxrwx 1 root root 20 Mar 8 12:16 K50netconsole -> ../init.d/netconsole
lrwxrwxrwx 1 root root 15 Jun 26 11:48 K75netfs -> ../init.d/netfs
lrwxrwxrwx 1 root root 17 Mar 8 12:16 K75ntpdate -> ../init.d/ntpdate
lrwxrwxrwx 1 root root 19 Mar 8 12:16 K75quota_nld -> ../init.d/quota_nld
lrwxrwxrwx 1 root root 15 Jul 4 23:52 K86cgred -> ../init.d/cgred
lrwxrwxrwx 1 root root 21 Mar 8 12:16 K87restorecond -> ../init.d/restorecond
lrwxrwxrwx 1 root root 15 Jun 26 11:39 K89rdisc -> ../init.d/rdisc
lrwxrwxrwx 1 root root 19 Jul 8 01:30 K92ip6tables -> ../init.d/ip6tables
lrwxrwxrwx 1 root root 18 Jul 4 23:52 K95cgconfig -> ../init.d/cgconfig
lrwxrwxrwx 1 root root 22 Mar 8 12:16 S02lvm2-monitor -> ../init.d/lvm2-monitor
lrwxrwxrwx 1 root root 18 Jun 26 12:10 S08iptables -> ../init.d/iptables
lrwxrwxrwx 1 root root 17 Jun 26 11:39 S10network -> ../init.d/network
lrwxrwxrwx 1 root root 16 Mar 8 12:16 S11auditd -> ../init.d/auditd
lrwxrwxrwx 1 root root 21 Mar 8 12:16 S11portreserve -> ../init.d/portreserve
lrwxrwxrwx 1 root root 17 Mar 8 12:16 S12rsyslog -> ../init.d/rsyslog
lrwxrwxrwx 1 root root 20 Mar 8 12:16 S13irqbalance -> ../init.d/irqbalance
lrwxrwxrwx 1 root root 19 Mar 8 12:16 S15mdmonitor -> ../init.d/mdmonitor
lrwxrwxrwx 1 root root 20 Mar 8 12:16 S22messagebus -> ../init.d/messagebus
lrwxrwxrwx 1 root root 26 Mar 11 11:11 S25blk-availability -> ../init.d/blk-availability
lrwxrwxrwx 1 root root 19 Mar 8 12:16 S26udev-post -> ../init.d/udev-post
lrwxrwxrwx 1 root root 14 Mar 8 12:16 S55sshd -> ../init.d/sshd
lrwxrwxrwx 1 root root 16 Jun 26 12:10 S64mysqld -> ../init.d/mysqld
lrwxrwxrwx 1 root root 17 Jul 7 22:42 S79bitcoin -> ../init.d/bitcoin
lrwxrwxrwx 1 root root 17 Jul 10 00:00 S80postfix -> ../init.d/postfix
lrwxrwxrwx 1 root root 17 Jun 26 12:10 S80proftpd -> ../init.d/proftpd
lrwxrwxrwx 1 root root 15 Jun 26 12:10 S85httpd -> ../init.d/httpd
lrwxrwxrwx 1 root root 15 Mar 8 12:16 S90crond -> ../init.d/crond
lrwxrwxrwx 1 root root 13 Mar 8 12:16 S95atd -> ../init.d/atd
lrwxrwxrwx 1 root root 11 Jun 26 11:39 S99local -> ../rc.local
I "K" sono i demoni disabilitati, la "S" quelli abilitati, nel mio caso il Network è a S10, e per esempio SSHD a S55. Se fosse stato a S09 per esempio sarebbe partito prima del network, con conseguente errore.
Come vedi a S99 c'è rc.local
FaSan
Jump to: