Skip to content
This repository was archived by the owner on May 4, 2024. It is now read-only.

Add --pidfile option to vde_vmnet #27

Merged
merged 2 commits into from
Sep 10, 2021
Merged

Add --pidfile option to vde_vmnet #27

merged 2 commits into from
Sep 10, 2021

Conversation

jandubois
Copy link
Member

That way the pidfile will be owned by the user running the daemon, and we can safely add e.g. pkill -f /var/run/vde_vmnet.pid to the sudoers file.

Also adds a signal handler for SIGHUB, SIGINT, and SIGTERM.

That way the pidfile will be owned by the user running the daemon,
and we can safely add e.g. `pkill -f /var/run/vde_vmnet.pid` to the
sudoers file.

Signed-off-by: Jan Dubois <jan.dubois@suse.com>
If nothing else, just to be able to test the cleanup of the pidfile...

Signed-off-by: Jan Dubois <jan.dubois@suse.com>
@jandubois jandubois added the enhancement New feature or request label Sep 9, 2021
Copy link
Member

@AkihiroSuda AkihiroSuda left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks

@AkihiroSuda AkihiroSuda merged commit a76cb8c into master Sep 10, 2021
@jandubois jandubois deleted the pidfile branch September 10, 2021 06:59
@@ -215,6 +216,12 @@ static interface_ref start(VDECONN *vdeconn, struct cli_options *cliopt) {
return iface;
}

static sigjmp_buf jmpbuf;
static void signalhandler(int signal) {
printf("\nReceived signal %d\n", signal);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is, but then we would have to call _exit instead and rely on the OS to close handles and and other cleanup because we are going to call siglongjmp next.

  • If a signal handler interrupts the execution of an unsafe function, and the handler terminates via a call to longjmp(3) or siglongjmp(3) and the program subsequently calls an unsafe function, then the behavior of the program is undefined.

I don't really care strongly either way: most of the time things work correctly because the signal didn't interrupt an unsafe function, and we get the information printed, and regular cleanup called.

I haven't actually seen it fail at all, but even if it does, we would just see the process crash instead, which would then continue with OS-level cleanup the same way as if we had called _exit; but we get a different exit code instead.

Now, given that in non-debugging situations this all runs as a daemon, nobody will see either the output on stdout, nor the crash exit code, so I don't think this matters very much at all.

I'm fine with just calling _exit(0) in the signal handler and not doing anything else, if you prefer that.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants