[bglug] ULOGD <7> ulogd.c:812 ipulog_read =?utf-8?Q?=3D=3D_?=-1! ipulog_errno =?utf-8?Q?=3D=3D_?=6, errno =?utf-8?Q?=3D_?=105

[Federico Ravasio]

> 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