Hi,
First of all, thanks for sending this.
Peter Gyongyosi wrote:
> --- a/utils/start-stop-daemon.c
> +++ b/utils/start-stop-daemon.c
[...]
> @@ -361,6 +369,152 @@ pid_list_free(struct pid_list **list)
[...]
> +static void
> +start_trace(pid_t pid)
> +{
> + wait(NULL);
> +
> + int retries;
> + const int max_retries = 10;
> +
> + for (retries = 0; retries < max_retries; ++retries) {
> + if (ptrace (PTRACE_SETOPTIONS, pid, NULL,
> + PTRACE_O_TRACEFORK) >= 0) {
> + ptrace(PTRACE_CONT, pid, NULL, 0);
> + return;
Yikes. upstart allows something similar (though it uses the simpler
TRACEME and only tries once). For reference, this is imitating the
EXPECT_DAEMON and EXPECT_FORK cases in init/job_process.c.
I guess start-stop-daemon is the right place to implement this kind of
hack, but I'd much rather see daemons providing either a --no-detach
or a --pidfile option. A serious problem with the ptrace approach is
making it impossible to debug the daemon with "gdb -p" (and that
downside ought to be mentioned in the documentation if this is
adopted).
For your particular application: is it possible to run each service in
a separate cgroup (like systemd does), maybe? (See
http://0pointer.de/blog/projects/systemd-for-admins-4.html for what
that looks like from the enduser pov.) What services use "expect =
fork/daemon"? Maybe they can be fixed (so strace and gdb -p can use
if for no other reason)?
> + // NOTE: we don't treat it as a fatal error as it could happen in some
> race-y situations
> + warning("Error detaching from process: %s (pid: %d)\n",
> strerror(errno), pid);
Hmm...
> +static void
> +trace_pid(char *startas, char **argv)
> +{
> + pid_t pid, child_pid;
> + int num_of_forks = 0;
> +
> + pid = fork();
> + if (pid < 0) {
> + fatal("Unable to fork!\n");
> + }
> + if(pid == 0) {
> + ptrace(PTRACE_TRACEME, 0, NULL, NULL);
> + execvp(startas, argv);
> + }
> + else {
The nested ifs here are hard to read. It should be safe to drop the
else after handling execvp failure.
Hope that helps,
Jonathan
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
