main: fork into worker and supervisor; perform clean up. #930
Conversation
| local signals, err = S.util.signalfd_read(signalfd) | ||
| assert(signals, tostring(err)) | ||
| if not signals[1].chld then S.kill(worker_pid, "kill") end | ||
| shutdown(S.getpid()) |
There was a problem hiding this comment.
It is a mystery to me why this works. E.g. I had assumed I needed to pass worker_pid to shutdown since the worker goes on to create the /var/run directory based on S.getpid(), but apparently when the worker calls S.getpid() it returns the parent pid? confused
|
I am excited about managing processes directly with Snabb. There are a lot of nice convenience / safety / error-recovery / administrative features we could implement. I also really want to be able to store more information in Thoughts:
Generally I would find this change easier to digest with more explanation. Maybe some commentary in the source code explaining the overall intention and how that is achieved with these particular system calls? |
|
Good points!
Yes, this PR makes snabb remove its own runtime directory. This makes sense because as of now the lab servers are littered with stale runtime directories. Ideally there would be a way to pass a
If you What is currently not covered is handling of SIGCONT to the child, e.g. it is not supported to stop (SIGSTOP) and continue the child. I felt this was not something we want to do, but it might be sensible to have a good default behavior for this case. |
Actually not true, the child will be killed by SIGHUP ( |
Also wrong, SIGSTOP/SIGCONT were handled just fine... Don't really know how though? |
Conflicts: - src/core/main.lua
An option to keep the data directory around upon termination would be valuable. |
|
Added support for the worker to be stopped/continued, so that caveat is gone.
I have made |
Great, thank you. Are env vars documented anywhere? |
|
@teknico Good point, currently no. I think this should be documented along with the sub-program mechanism in place of this outdated section. |
|
Is it safe to say that we would benefit from having well-defined configuration options and convenient methods of supplying them e.g. config files and command line? and further that such config items would best be described with a YANG schema for the Snabb engine and parameters like busy-wait, developer-debug, etc? |
|
I'd like to retain |
|
@kbara |
|
Snabb gc wasn't ideal for those reasons, true. After talking to my team, I'm ok with removing it. Thanks. |
Fix followers iteration
This forks in
main, leaving a “worker“ and a “supervisor” process. The worker sets a flag that causes it to be killed when the supervisor quits, and resumes as the regular snabb process. The supervisor sets up asignalfd(2)to be notified when the worker quits, and cleans up afterwards. See #509.