Worst case, it should play DVDs and maybe handle some amateur radio stuff in my work room; that's where it is now.
I don't have the real hardware any more, but thought it would be fun to torture myself with this:
Think 8086 or 8088.
Semi active. They seem to loose the repo now and then. Someone makes floppy images every now and then.
Maddog is digitizing his ye olde VHS-Tapes:
Linus talk at dec.
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.
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.
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.
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.