user app crash keeps zc interface locked

[AntonyNow19]

Hello @cardigliano @lucaderi

I have the following issue while using zbalance_ipc -m 1 -n 2 -c 1 When I run an application that listens to traffic from zc:1@0 (i.e zeek or suricata) and if for some reason the user app is killed, then the virtual interface of zc:1@0 is locked. The error is that no such device exists.

An ugly fix would be to restart the zbalance_ipc process.

Is there a more elegant way of disconnecting and unlocking zc:1@0 so that another user space app could read from it ? Any signal that needs to be sent for example ?

Thank you Anton

[cardigliano]

@AntonyNow19 unfortunately this is expected, as zero-copy technologies are based on shared memory to avoid any synchronization overhead, with the drawback that applications should not crash nor misbehave as otherwise they leave this shared data structures in an "unknown" state and it is not possible to recover the queue. Please also read https://www.ntop.org/pf_ring/best-practices-for-using-bro_ids-with-pf_ring-zc-reliably/

[AntonyNow19]

I understand the constraints,

But if I am willing to take the risk of corrupted memory, is there a way to disconnect it from zbalance_ipc ? Any signal I can send or EOF for example ?

In addition to it, using the dummy interfaces method you have suggested, implies that I will relay the traffic back to the kernel and to the network stack. In such a case, there is no meaning to zero copy mode when using zeek. Please correct me if I am wrong

Thank you

On Wed, Sep 28, 2022 at 12:42 PM Alfredo Cardigliano < @.***> wrote:

@AntonyNow19 https://github.com/AntonyNow19 unfortunately this is expected, as zero-copy technologies are based on shared memory to avoid any synchronization overhead, with the drawback that applications should not crash nor misbehave as otherwise they leave this shared data structures in an "unknown" state and it is not possible to recover the queue. Please also read https://www.ntop.org/pf_ring/best-practices-for-using-bro_ids-with-pf_ring-zc-reliably/

— Reply to this email directly, view it on GitHub https://github.com/ntop/PF_RING/issues/836#issuecomment-1260654186, or unsubscribe https://github.com/notifications/unsubscribe-auth/A3KD7SCRTGPU6QA7TU32BNDWAQHHLANCNFSM6AAAAAAQXSLHCU . You are receiving this because you were mentioned.Message ID: @.***>

[cardigliano]

I understand the constraints, But if I am willing to take the risk of corrupted memory, is there a way to disconnect it from zbalance_ipc ? Any signal I can send or EOF for example ?

No way, as zbalance_ipc needs to rebuild the cluster, which is the same as restarting zbalance_ipc (you need to disconnect all the consumers anyway), thus it is better to rely on systemd for this, restarting the whole hierarchy (zbalance and consumers)

In addition to it, using the dummy interfaces method you have suggested, implies that I will relay the traffic back to the kernel and to the network stack. In such a case, there is no meaning to zero copy mode when using zeek. Please correct me if I am wrong Thank you

Correct, unless you need the balancer to send to boh many suricata consumers (using the dummy interfaces) and other applications using zero-copy queues. In your case I would restart the whole cluster in case of crash, which should be an exceptional situation.

[AntonyNow19]

And is there a way to redirect zc output to anything other than the dummy interface ? any named pipe or local socket ?

Thank you

[cardigliano]

Only network interfaces are supported atm, but you can extend zbalance_ipc to push packets to other kind sockets. However I am not sure what performance boost you get as you go through the kernel anyway.