Hi again,
Peter Gyongyosi wrote:
> But I do not understand your other remark: I am indeeed using TRACEME,
> all other ptrace calls are just to limit the tracing to only forks and
> to get the PID we need.
Sorry, that was just my sloppiness. Perhaps renaming the function,
along the lines of s/start_trace/set_trace_options/, would help sloppy
readers like me?
[...]
> For me, however, while being extremely far from being an expert
> of the ptrace interface, it seems like this thing is inherently race-y
I have no experience writing ptrace-heavy code myself, but the manual
says the following:
The value of request determines the action to be performed:
PTRACE_TRACEME
Indicates that this process is to be traced by its parent.
Any signal (except SIGKILL) delivered to this process will
cause it to stop and its parent to be notified via
wait(2). Also, all subsequent calls to execve(2) by this
process will cause a SIGTRAP to be sent to it, giving the
parent a chance to gain control before the new program
begins execution.
Doesn't that mean that a wait() in the parent is the right way to
start tracing?
[...]
| Note that the trace is removed as soon as we've seen the two (or one)
| forks, so it's only there for a very short amount of time.
That addresses my concern about ptrace, yes.
> But I also agree that it's better if the daemons themselves can create
> their own pidfiles or stay in foreground: if it's added, maybe a WARNING
> should be included for this option just as there is one for
> --background, telling the user to only use this as a last resort in
> special cases.
I suspect that cgroups are a better last resort (think: closed-source
code that so far seems to have used fork() but could change behavior
any second ;-)). But sure, that's the proper place for this.
>> For your particular application: is it possible to run each service in
>> a separate cgroup (like systemd does), maybe?
[...]
> Hmm, it seems like a viable option, I'll play around with it when I'll
> have the time.
Yep, was just musing. (Plus if that approach ends up easy and
flexible enough, it could replace this code.)
> But since then, upstart seems to start to get the
> functionality we needed (that is, working properly in chroots), so maybe
> that'll be the way to go.
Very good to hear.
> What services use expect = fork/daemon? Quite a lot of them, for
> example, on my workstation:
>
> gyp@chuck:/etc/init$ egrep "expect (fork|daemon)" *
> acpid.conf:expect fork
> anacron.conf:expect fork
[... 14 other core packages ...]
Wow. Thanks for checking.
[...]
> In general, what do you think, is there a point in adding this feature
> to upstream start-stop-daemon? We needed this, I wrote this, it's been
> tested and seem working fine in our setup, so I thought I'd send it in.
Guillem would probably be the one to say whether this belongs in
start-stop-daemon. (Based on "git log", it looks like he has been
maintaining it for the last while. Incidentally, looks like Scott
James Remnant was taking care of s-s-d for around a year before that.)
> I can see its value outside our specific situation, but I admit these
> are very special cases when this might be needed. If yes, what changes
> would it need to be accepted? I'm willing to fix some things up and test
> the changes, though my resources are quite limited, so it might take a
> while...
We can wait. ;-) And any interested others are welcome to help.
Thanks again.
Jonathan
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
