<div dir="ltr">Grazie per l'aiuto Federico!<div>Mi spiace non aver risposto prima ma per business continuity sono stato irreperibile.<br><div style>Purtroppo nessuna delle tre ipotesi sembra calzare con il mio problema.</div>

<div style><br></div><div style> - L'opzione uno così come è stata implementata non è d'aiuto a nessuno.</div><div style> - L'opzione due non la capisco (si accettano supporto)<br></div><div style> - 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ì.</div>

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

<div style><br></div><div style>Comunque nemmeno su altre mailing list sanno rispondere.</div><div style><br></div><div style>Federico</div><div style><br></div><div style><br></div><div style><br></div></div></div><div class="gmail_extra">

<br><br><div class="gmail_quote">Il giorno 11 febbraio 2013 23:41, Federico Ravasio <span dir="ltr"><<a href="mailto:ravasio.federico@gmail.com" target="_blank">ravasio.federico@gmail.com</a>></span> ha scritto:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">> Ciao a tutti,<br>
><br>
> Ho un problema che sto indagando da tempo con ulogd.<br>
> In poche parole dopo un po' smette di "loggare" e all'interno del log di stato del demone trovo<br>
><br>
> <7> ulogd.c:812 ipulog_read == -1! ipulog_errno == 6, errno = 105<br>
><br>
> Non posso dare troppi dettagli tecnici ma la macchina è una Ubuntu Server 10.04.5 LTS. 16GB RAM, dischi 15K e due E5640.<br>
> Vi sono quattro NIC Broadcom NetXtreme II BCM5709 da 1Gbps a gruppi di due in bonding active-backup.<br>
><br>
> Il resto dell'infrastruttura di rete sono oltre due migliaia di bridge e vlan.<br>
><br>
> 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.<br>
><br>
> Comunque leggendo altre mailinglist sembra un problema di buffer infatti l'errore 105 sta a: errno = 105 = ENOBUFS.<br>
><br>
> Il punto è che nel mio caso il buffer in questione è già impostato ad un quantitativo decisamente alto.<br>
><br>
> Qualcuno ha riscontrato (e risolto) un problema simile?<br>
><br>
> Grazie,<br>
> Federico<br>
<br>
</div></div>Ovviamente non ho mai sentito parlare di ulogd, ma ho scavato nel codice:<br>
*disclaimer* tutto ciò che segue va preceduto con "credo sia così, non sono sicuro"<br>
<br>
ipulog_errno = 6 significa "Error during netlink receive", come si legge [libipulog/libipulog.c:60] e può accadere in tre casi:<br>
1. lo status ritornato da recvfrom [libipulog/libipulog.c:80] è < 0 [libipulog/libipulog.c:82]<br>
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."<br>
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.<br>
<br>
2. addrlen != sizeof(h->peer) [libipulog/libipulog.c:86]<br>
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.<br>


<br>
3. h->peer.nl_pid != 0<br>
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."<br>


<br>
<br>
Spero quanto riportato abbia senso e sia di aiuto.<br>
<br>
[1] <a href="http://linux.die.net/man/2/recvfrom" target="_blank">http://linux.die.net/man/2/recvfrom</a><br>
[2] <a href="http://linux.die.net/man/7/netlink" target="_blank">http://linux.die.net/man/7/netlink</a><br>
<br>
--<br>
Federico Ravasio<br>
Sent with Sparrow (<a href="http://www.sparrowmailapp.com/?sig" target="_blank">http://www.sparrowmailapp.com/?sig</a>)<br>
<div><div class="h5"><br>
<br>
On Monday, February 11, 2013 at 10:03 PM, Federico Iezzi wrote:<br>
<br>
> Ciao a tutti,<br>
><br>
> Ho un problema che sto indagando da tempo con ulogd.<br>
> In poche parole dopo un po' smette di "loggare" e all'interno del log di stato del demone trovo<br>
><br>
> <7> ulogd.c:812 ipulog_read == -1! ipulog_errno == 6, errno = 105<br>
><br>
> Non posso dare troppi dettagli tecnici ma la macchina è una Ubuntu Server 10.04.5 LTS. 16GB RAM, dischi 15K e due E5640.<br>
> Vi sono quattro NIC Broadcom NetXtreme II BCM5709 da 1Gbps a gruppi di due in bonding active-backup.<br>
><br>
> Il resto dell'infrastruttura di rete sono oltre due migliaia di bridge e vlan.<br>
><br>
> 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.<br>
><br>
> Comunque leggendo altre mailinglist sembra un problema di buffer infatti l'errore 105 sta a: errno = 105 = ENOBUFS.<br>
><br>
> Il punto è che nel mio caso il buffer in questione è già impostato ad un quantitativo decisamente alto.<br>
><br>
> Qualcuno ha riscontrato (e risolto) un problema simile?<br>
><br>
> Grazie,<br>
> Federico<br>
><br>
><br>
><br>
</div></div>> --<br>
> Sito BgLUG: <a href="http://www.bglug.it" target="_blank">http://www.bglug.it</a><br>
> Mailing list: <a href="http://lists.linux.it/listinfo/bglug" target="_blank">http://lists.linux.it/listinfo/bglug</a><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
<br>
--<br>
Sito BgLUG: <a href="http://www.bglug.it" target="_blank">http://www.bglug.it</a><br>
Mailing list: <a href="http://lists.linux.it/listinfo/bglug" target="_blank">http://lists.linux.it/listinfo/bglug</a><br>
</font></span></blockquote></div><br></div>