[#] Mon Jul 07 2014 07:51:09 EDT from dothebart @ Uncensored
Maddog is digitizing his ye olde VHS-Tapes:
Linus talk at dec.
[#] Mon Jul 07 2014 17:40:50 EDT from IGnatius T Foobar @ Uncensored
That isn't RMS in the front left, is it? Looks like him from the back (sloppy, fat, long greasy hair) but I can't imagine the real RMS would wear a shirt that says "LINUX" nor would he allow anyone to speak the words "Linux operating system" without blurting out "TEH GNU!!! TEH GNUUUYUUUYUYYYYUUUUUUUUUUUUU!!1111"
[#] Mon Jul 07 2014 17:48:04 EDT from roue @ Dog Pound BBS II
I'm pretty sure that's Maddog Hall.
I would like to use strace to see what happens beyond daemonization, but at least on this machine, it 'finishes' with the first call to clone, despite the daemonized process continuing to run thereafter.
Not as helpful a tool for me as I wish.
While I can still use it to trace system calls on the running process, if I wanted to see wha tit was doing for the few milliseconds it was between pids, I am SOL.
[#] Wed Jul 16 2014 17:53:12 EDT from dothebart @ Uncensored
[#] Wed Jul 16 2014 19:22:11 EDT from LoanShark @ Uncensored
Yep, -f (follow-fork mode) has also been following clone() for a few years now.
Yeah, that's what the man page indicates, what the google search tells me to do, and what it suggests when you type strace --help, but it won't do it on this machine.
I wonder about the latest Ubuntu. Hm.
In any event, I was only looking into this because this machine's upstart doesn't seem to work very well with the service I wrote. My service doesn't look like it's doing anything amazingly different than any other service when it comes to daemonizing, but upstart's 'start' hangs and 'stop' doesn't stop it.
In the end, I expect I'll give up and do the SysV thing, since that works everywhere anyway. I just sorta hoped to do things The Right Way (tm) for various distributions.
(And, yeah, I'll be research serviced soon).
Gads, but I should slow down on my typing.
[#] Thu Jul 17 2014 11:20:31 EDT from LoanShark @ Uncensored
You must have a quite significantly older distribution if strace -f doesn't follow clone. Well anyway, strace itself is pretty portable code. Try compiling its latest version on your older libc/kernel.
Yeah, I thought that was the expectation as well, except this is ubuntu 14.04 LTS. It's the very latest version. I can still smell the corinthian leather.
At the end of the day, I don't really care what strace tells me, I already know that I am calling 'fork' twice before getting to the good stuff in the process of daemonizing my service. All my googling suggests that's the bes t practice for most posix services.
This means when configuring the service for upstart, I'm supposed to indicate 'expect daemon' so it know that it forks twice.
I'm supposed to do that so it not only can track the service's pid properly, but it can also not hang when you 'sudo start [service]'. And so it can be stopped with 'sudo stop [service]' without hanging.
Except on this machine, it hangs. It does track the pid, but it hangs. Someone had a nifty table that tells you things like 'if you specify expect daemonize but the service only forks once this is the behavior to expect', but none of this matches his chart.
So, I'm thinking about punting and just doing this the sysv way... which is kind of a shame, really, as I'd love to take advantage of whatever upstart does for you (parallel starting of types of services, etc), but I can't seem to make it work on this machine, and I've devoted kind of a stupid amount of time researching the issue.
[#] Thu Jul 17 2014 13:35:35 EDT from LoanShark @ Uncensored
yeah, we sysv everything... but then, all our stuff is pretty much stock. and good luck running a JVM under upstart.
OK, we are stll on ubuntu 12.04 until RightScale picks up support for 14.04. so maybe your problem is that you're too much on the bleeding edge, and somebody broke strace in 14.
or, if you're trying to strace something that is being watched by upstart, upstart may also be ptracing your process and there is a conflict.
hack suggestion: add a debug flag to your process, so that at the point you're having trouble following, the process kills itself with SIGSTOP. That will suspend it, until you kill it with SIGCONT.
While it's suspended, you may be able to attach to it with strace (or gdb) closer to the point of interest.
[#] Thu Jul 17 2014 13:37:59 EDT from LoanShark @ Uncensored
but yeah... I wouldn't spend too much time on upstart integration... it's not exactly your highest-priority feature, most likely.
[#] Thu Jul 17 2014 13:44:07 EDT from LoanShark @ Uncensored
[#] Thu Jul 17 2014 13:48:59 EDT from LoanShark @ Uncensored
Does upstart's design seem like a good idea to you?
Is the use of ptrace() for job status tracking inherently heuristic and therefore inherently error-prone?
Is upstart integratation, although useful for machine boot performance, really of interest to anyone other than Canonical's own development team?
1. I was performing strace on a process that it started, not on one that upstart started.
2. I noticed that strace failed to trace beyone the first fork of cron, too.
So it isn't something weird I'm doing.
3. I'm accustomed to doing the kind of debugging that requires careful attention to log files. I very rarely run into the weird kind of race conditions that require using something like strace... but I sorta wished it worked correctly on this system in case I run into a posix-ism that involves a race condition or something of the sort I rarely experience. Heh.
4. Just, fucking, ugh: https://bugs.launchpad.net/upstart/+bug/406397
5. strace would have helped me figure out if that bug was appropriate to this situation. Heh.
6. Yeah, maybe I'm on the bleeding edge of OSes. I could try something earlier to see how well that works.
Regarding upstart's design, in light of the url I sent, and the number of people bit by this, no, I think they should seriously rethink this, or deitch ... (deitch? really?) ditch this for the other hot thing that seems to be making the rounds in systemd.
This said, from the discussions I'm reading, there's a desire to use something other than ptrace for upstart. I just don't know why they woudl bother at this point, if there's something else that people seem to like better.
Oh, hm. According to this:
it seems Ubuntu plans to use it by default eventually. Certainly, a lot of other distributions seem to be using systemd now.
[#] Thu Jul 17 2014 17:26:41 EDT from dothebart @ Uncensored
it was quiet a discussion in the debian team, whether to use systemd or upstart.
you most probably did freopen stind/stdout/stderr to /dev/zero after the first fork?
[#] Thu Jul 17 2014 17:30:52 EDT from roue @ Dog Pound BBS II
I've been using Debian for 15 years and I'm not pleased with the systemd migration. Too monolithic. I'm hoping there's a simple way to retain init scripts after everything else moves over. My systems hardly run anything complicated, and for those things I can write my own init scripts.
Go to page: ...  ...