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

[Federico Iezzi]

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>