Newsgroup: it.comp.os.linux.sys
Titolo: Logrotate (ruota ma non scrive sul nuovo file)

Ho questo problema,
tutte le mattine, alle 04:02, viene effettuato correttamente il rotate
dei log, rinominando i vari log in .1, .2, .3 e così via.
E fino a qui tutto a posto. Il problema è che poi il log principale
viene creato (quello senza .1, .2, .3 ecc.) ma syslog-ng continua a
loggare nel file ruotato.
Se riavvio il servizio syslog-ng a mano allora il log riparte
correttamente.
Nel file di configurazione di logrotate (syslog-ng) c'è:
postrotate
        /bin/kill -HUP `cat /var/run/syslog-ng.pid 2> /dev/null` 2> /
dev/null || true
    endscript
ma perché non viene riavviato il servizio?

 Failure is not an option -- it comes bundled with Windows.
Sicurissimo. Il servizio a mano lo restarto con
service syslog-ng restart
oppure con /etc/init.d/syslog-ng restart

     endscript
Ok mi sono appena svegliato, quasi quasi ci provo....
Sicuro che il secondo backtick vada proprio lě?
Secondo me dovrebbe essere cosě
postrotate
/bin/kill -HUP `cat /var/run/syslog-ng.pid` 2> /dev/null || true
Da come hai scritto tu, il comando cat restituisce in /dev/null e quindi 
kill che cosa deve HUPpare?
Ciao
Zelo

 Zelo
In effetti non hai tutti i torti. Quella riga non l'ho mai modificata.
Il file di rotate del syslog-ng me l'ha installato direttamente syslog-
ng e quella è un'impostazione di default. Su altri server ho la stessa
riga che ti ho copiato io ma ciò nonostante il rotate funziona e kill
HUPpa correttamente!!!

 kill che cosa deve HUPpare?
Confermo.


Confermo che
/bin/kill -HUP `cat /var/run/syslog-ng.pid 2> /dev/null` 2> /dev/null
|| true
è un'impostazione di default e sugli altri server il rotate va, ho
appena ricontrollato per l'ennesima volta!!!


Restituisce *lo STDERR* in /dev/null. Lo STDOUT esce come di consueto.
-- 
Skull & Bones (ER6n Silver)
Neo:  I know Sendmail!
Morpheus:  Show me.

 Morpheus:  Show me.
Ehm, scusa la mia ignoranza ma non ho capito!!

 Restituisce *lo STDERR* in /dev/null. Lo STDOUT esce come di consueto.
Mannaggia al 2.... Mi era sfuggito.

lan...@gmail.com
 ha scritto:

echo "CIAO" 2>/dev/null
restituisce eventuali errori generati dal comando in /dev/null
Questo perchè c'è il 2 che indica STDERR, 1 (o niente numero) 
indicherebbe STDOUT (ovvero output normale)
Quando fai un 'cat ciripicchio' l'output normale (STDOUT o 1) esce 
normale su schermo, STDERR (o 2) viene inviato a /dev/null questo spiega 
come mai la riga tecnicamente funziona. Il cat restituisce il pid su STDOUT


ehm.....aiuto!!!!!!

 
lant...@gmail.com
 ha scritto:

aaaaaah, ho capito....quindi tecnicamente dovrebbe funzionare!!!!!

 Restituisce *lo STDERR* in /dev/null. Lo STDOUT esce come di consueto.
Ok la prossima volta prendo prima un caffè :-)

 Linux: The choice of a GNU generation
Momentaneamente ho risolto così. Il rotate lo fa alle 04:02 di ogni
mattina, nel crontab alle 04:05 ho messo un /etc/init.d/syslog-ng
restart
Non è il metodo consueto però dovrebbe risolvermi il problema...che
comunque rimane un MISTERO!!!!!
Grazie comunque del supporto

 Grazie comunque del supporto
Pessima idea. E se il rotate si protrae per più di 3 minuti? Cosa
molto probabile in caso di log di apache o aggiornamento
statistiche...
Molto meglio fare uno script in bash
#!/bin/bash
--comando-logrotate-che-era-nel-cron--
service syslog-ng restart
In questo modo quando il rotate termina, il syslog viene fatto
ripartire.
Così anche se il rotate ti duratte 353 ore non avresti problemi.
(oppure monoriga nel crontab: "--comando-log-rotate && service syslog-
ng restart")

Alessandro ha scritto:


Si meglio, ho aggiunto nel file logwatch situato in /etc/cron.daily
questo:
/usr/sbin/logrotate /etc/logrotate.conf && service syslog-ng restart
Domani vi faccio sapere :-D

 appena ricontrollato per l'ennesima volta!!!
Prova con:
/bin/kill -HUP `/bin/cat /var/run/syslog-ng.pid 2>/dev/null` \
	2>/dev/null || true
cioè mettendo il path completo di cat.
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   Registered Linux user #337974  < 
http://giovanni.homelinux.net/
 >

 appena ricontrollato per l'ennesima volta!!!
infatti la riga può andare, se non funziona evidentemente il file .pid
NON contiene il pid giusto...
bye!


Già risposto a quest'affermazione. Il pid è giustissimo!!!!

 Già risposto a quest'affermazione. Il pid è giustissimo!!!!
chiedo venia, non ci avevo fatto caso. Allora l'unica cosa che mi
viene in mente è che su quella piattaforma il binario di syslog sia
stato compilato in modo da non onorare i SIGHUP (ma mi pare
improbabile, IMHO c'e' qualcosa di più semplice ma non ovvio...)
bye!


Hai provato a modificare il comando rimuovendo *tutti* i 
"2>/dev/null"?  In questo modo cron dovrebbe generare il messaggio di 
errore inviando una mail.
