[bglug] ULOGD <7> ulogd.c:812 ipulog_read == -1! ipulog_errno == 6, errno = 105

Federico Iezzi federico.iezzi@gmail.com
Mer 13 Feb 2013 21:57:10 CET


Grazie per l'aiuto Federico!
Mi spiace non aver risposto prima ma per business continuity sono stato
irreperibile.
Purtroppo nessuna delle tre ipotesi sembra calzare con il mio problema.

 - L'opzione uno cos come  stata implementata non  d'aiuto a nessuno.
 - L'opzione due non la capisco (si accettano supporto)
 - L'opzione tra la escluso in quanto l'IPC socket usato da ulog  vivo.
Sarebbe sensato se, ad esempio, fosse morto il processo o non gli fosse
stato assegnato un socket, ma non  cos.

Ho provato a raddoppiare la dimensione dei buffer a cui facevo riferimento
nel messaggio di apertura ed il problema non si  pi presentato.
Mi da fastidio perch non ne capisco il motivo. Il raddoppiamento dei
buffer  un workaround ingiustificato.

Comunque nemmeno su altre mailing list sanno rispondere.

Federico





Il giorno 11 febbraio 2013 23:41, Federico Ravasio <
ravasio.federico@gmail.com> ha scritto:

> > Ciao a tutti,
> >
> > Ho un problema che sto indagando da tempo con ulogd.
> > In poche parole dopo un po' smette di "loggare" e all'interno del log di
> stato del demone trovo
> >
> > <7> ulogd.c:812 ipulog_read == -1! ipulog_errno == 6, errno = 105
> >
> > Non posso dare troppi dettagli tecnici ma la macchina  una Ubuntu
> Server 10.04.5 LTS. 16GB RAM, dischi 15K e due E5640.
> > Vi sono quattro NIC Broadcom NetXtreme II BCM5709 da 1Gbps a gruppi di
> due in bonding active-backup.
> >
> > Il resto dell'infrastruttura di rete sono oltre due migliaia di bridge e
> vlan.
> >
> > Non posso dare ulteriori dettagli n giustificare le motivazioni
> architetturali in quanto sono sotto embargo. L'unica ultima cosa che posso
> dire  che, se non si fosse capito,  un grosso GW Linux.
> >
> > Comunque leggendo altre mailinglist sembra un problema di buffer infatti
> l'errore 105 sta a: errno = 105 = ENOBUFS.
> >
> > Il punto  che nel mio caso il buffer in questione  gi impostato ad un
> quantitativo decisamente alto.
> >
> > Qualcuno ha riscontrato (e risolto) un problema simile?
> >
> > Grazie,
> > Federico
>
> Ovviamente non ho mai sentito parlare di ulogd, ma ho scavato nel codice:
> *disclaimer* tutto ci che segue va preceduto con "credo sia cos, non
> sono sicuro"
>
> ipulog_errno = 6 significa "Error during netlink receive", come si legge
> [libipulog/libipulog.c:60] e pu accadere in tre casi:
> 1. lo status ritornato da recvfrom [libipulog/libipulog.c:80]  < 0
> [libipulog/libipulog.c:82]
> Dal man di recvfrom [1]: "These calls return the number of bytes received,
> or -1 if an error occurred. The return value will be 0 when the peer has
> performed an orderly shutdown."
> Non sembra che libipulog vada a capire che tipo di errore si sia
> verificato, quindi si limita ad alzare la mani senza dire pi nello
> specifico cosa sia successo.
>
> 2. addrlen != sizeof(h->peer) [libipulog/libipulog.c:86]
> addrlen parte inizializzato con la dimensione del puntatore h->peer (4
> byte su una macchina a 32 bit e 8 su una a 64), poi h->peer viene passato
> per riferimento a recvfrom, il quale potrebbe cambiare totalmente il
> contenuto di tale puntatore. Quindi alla riga 86 che dicevo controlla che
> la dimensione sia rimasta quella di partenza. Non ho ancora una barba UNIX
> abbastanza folta per capire questa cosa, quindi sorvolo.
>
> 3. h->peer.nl_pid != 0
> Dal man di netlink [1]: "nl_pid is the unicast address of netlink socket.
> It's always 0 if the destination is in the kernel. For a userspace process,
> nl_pid is usually the PID of the process owning the destination socket.
> However, nl_pid identifies a netlink socket, not a process. If a process
> owns several netlink sockets, then nl_pid can only be equal to the process
> ID for at most one socket. There are two ways to assign nl_pid to a netlink
> socket. If the application sets nl_pid before calling bind(2), then it is
> up to the application to make sure that nl_pid is unique. If the
> application sets it to 0, the kernel takes care of assigning it. The kernel
> assigns the process ID to the first netlink socket the process opens and
> assigns a unique nl_pid to every netlink socket that the process
> subsequently creates."
>
>
> Spero quanto riportato abbia senso e sia di aiuto.
>
> [1] http://linux.die.net/man/2/recvfrom
> [2] http://linux.die.net/man/7/netlink
>
> --
> Federico Ravasio
> Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
>
>
> On Monday, February 11, 2013 at 10:03 PM, Federico Iezzi wrote:
>
> > Ciao a tutti,
> >
> > Ho un problema che sto indagando da tempo con ulogd.
> > In poche parole dopo un po' smette di "loggare" e all'interno del log di
> stato del demone trovo
> >
> > <7> ulogd.c:812 ipulog_read == -1! ipulog_errno == 6, errno = 105
> >
> > Non posso dare troppi dettagli tecnici ma la macchina  una Ubuntu
> Server 10.04.5 LTS. 16GB RAM, dischi 15K e due E5640.
> > Vi sono quattro NIC Broadcom NetXtreme II BCM5709 da 1Gbps a gruppi di
> due in bonding active-backup.
> >
> > Il resto dell'infrastruttura di rete sono oltre due migliaia di bridge e
> vlan.
> >
> > Non posso dare ulteriori dettagli n giustificare le motivazioni
> architetturali in quanto sono sotto embargo. L'unica ultima cosa che posso
> dire  che, se non si fosse capito,  un grosso GW Linux.
> >
> > Comunque leggendo altre mailinglist sembra un problema di buffer infatti
> l'errore 105 sta a: errno = 105 = ENOBUFS.
> >
> > Il punto  che nel mio caso il buffer in questione  gi impostato ad un
> quantitativo decisamente alto.
> >
> > Qualcuno ha riscontrato (e risolto) un problema simile?
> >
> > Grazie,
> > Federico
> >
> >
> >
> > --
> > Sito BgLUG: http://www.bglug.it
> > Mailing list: http://lists.linux.it/listinfo/bglug
>
>
>
>
> --
> Sito BgLUG: http://www.bglug.it
> Mailing list: http://lists.linux.it/listinfo/bglug
>
-------------- parte successiva --------------
Un allegato HTML  stato rimosso...
URL: <http://lists.linux.it/pipermail/bglug/attachments/20130213/0a31c6ae/attachment.html>


Maggiori informazioni sulla lista bglug