https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212829
p...@rootwyrm.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |p...@rootwyrm.com
--- Comment #1 from p...@rootwyrm.com ---
To elaborate on my general thoughts;
The issue with just passing signals through daemon is: what if we want to
signal daemon? Whoops. The other possibility is to use uncommonly used signals
but then all you've got is SIGUSR1 and SIGUSR2 without violating sanity.
Obviously, that is not an acceptable solution either.
So my thought is that a user who wishes for daemon(8) to pass signals to the
child needs to provide two explicit arguments at runtime. First, the existing
child pid argument -p. Second, the flag -s 'signal passing.' This would tell
daemon to simply pass through all signals verbatim to the PID contained within
-p. (-s would conflict with -r as well.) This means it's an explicit
user-initiated behavior change, rather than function change.
Obviously, this then presents the problem: how to signal daemon itself. That I
do not have an elegant solution for. My initial thought was to have a socket
equivalent to -P where the user could simply echo the desired signal number to.
e.g. "echo '9' > /var/run/daemon/234.pid" - which isn't exactly optimal either.
However, this might be a more workable solution for child signalling perhaps?
Thoughts and feedback definitely appreciated.
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
