Date: Sat, 15 Apr 2023 00:22:21 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 212829] daemon(8) using -P swallows signals such as SIGHUP instead of propagating them Message-ID: <bug-212829-227-wEGg8xo6Dm@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-212829-227@https.bugs.freebsd.org/bugzilla/> References: <bug-212829-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212829 --- Comment #8 from Ihor Antonov <ihor@antonovs.family> --- After reading all comments I take the side of Phillip R. Jaenke (prj) Different services expect different signals, so creating a mechanism to pass signals to a child leaves a question "how to signal daemon" open. It is obviously a bad design. The ideal solution would be to have a socket that daemon listens for various commands. I need to run this idea by kevans to make sure he has no objections for this work. This might or might not be considered a scope creep. And if it is - I am go= ing to spin off a new supervisor daemon. With sockets, config files, blackjack = and hookers :) In the meanwhile It is possible make `service` to send signal to the child. There are 2 ways: 1) In your rc script pidfile=3D/path/to/child/pid command=3D"/usr/sbin/daemon" command_args=3D"--child-pidfile $pidfile .... rc framework on `service foo reload` should send SIGHUP to the process identified by $pidfile 2) There is a way to add custom commands to the rc script: extra_commands=3D"foobarnate" pidfile=3D/path/to/child/pid command=3D"/usr/sbin/daemon" command_args=3D"--child-pidfile $pidfile .... myservice_foobarnate() { kill -SIGUSR1 $pidfile } So you can run `service myservice foobarnate` to execute completely custom logic. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-212829-227-wEGg8xo6Dm>