Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[VPP-463] SIGALRM handler causes program termination even if client connect succeeds #1815

Open
vvalderrv opened this issue Jan 31, 2025 · 0 comments

Comments

@vvalderrv
Copy link
Contributor

Description

The python API wrapper function for client connect has a SIGALRM handler which goes off after 3s.

{{def handler(signum, frame):

print('Signal handler called with signal', signum)

raise IOError("Couldn't connect to VPP!")</p>

def connect(name, chroot_prefix = None):

  1. Set the signal handler
    signal.signal(signal.SIGALRM, handler)</li>
    
signal.alarm(3) # 3 second}}

There are two issues with this:

    - Even though the alarm fires after 3s have elapsed, the connect call itself continues to wait for the normal TCP connect timeout period (around 75s). The signal handler code executes after the connect call returns. This is due to the way signal handling happens in python.
    - In a scenario where user restarts/starts VPP and subsequently tries a vpp_papi.connect(), the connect may or may not succeed depending on how long VPP takes to start. Assuming VPP takes more than 3s but but less than the TCP connect timeout interval, then the connect() would have succeeded but since the signal handler executes (3s have elapsed), it terminates the process.

I think the signal handler does not server the purpose it was intended for - to abort the connect() if it takes longer than 3s.

Assignee

Unassigned

Reporter

Onong Tayeng

Comments

No comments.

Original issue: https://jira.fd.io/browse/VPP-463

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant