Miroslaw Baran <miroslaw+c+debb...@makabra.org> writes: > You wrote:
>> One non-feature of upstart which I happen to care strongly about is its >> use of ptrace(2) to figure out what a job is doing. This destroys any >> attempt to just use "strace foo" as the job, if one really needs to >> figure out what a piece of software is doing wrong. Thanks but no >> thanks. > Let me allow to quote the upstart's position statement: That statement talks about attaching gdb later in the lifetime of the process. It doesn't address Matthias's point about running the daemon itself under strace. The issues discussed with valgrind here: >> For valgrind, it's true that this would be less straightforward to do >> as part of an upstart job. If there were widespread demand for solving >> this, it wouldn't be difficult; but this doesn't seem like something >> that has much practical impact. It's unlikely that someone using >> valgrind for debugging will need to debug via an upstart job or systemd >> unit, as opposed to running the service directly. are, I believe, the same as the issues with strace, so I think this position statement concedes that Matthias is correct and the use of ptrace does prevent that particular use case. I don't personally consider this a major issue, but it is a minor one. I have personally done exactly that (replaced the daemon invocation with one run under strace -o /root/tmp/trace) to debug problems in the past. You can attach strace later, just like you can attach gdb later, but that doesn't help if the problem you're trying to get a system call trace for is during the daemon startup. -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
