Language:

en_US

switch to room list switch to menu My folders
Go to page: First ... 6 7 8 9 [10] 11 12 13 14 ... Last
[#] Wed Jul 16 2014 23:22:11 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


Yep, -f (follow-fork mode) has also been following clone() for a few years now.

[#] Thu Jul 17 2014 12:21:29 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


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.

[#] Thu Jul 17 2014 12:26:43 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


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.

[#] Thu Jul 17 2014 12:27:03 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


(And, yeah, I'll be research serviced soon).

[#] Thu Jul 17 2014 12:27:24 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


s/research/researching

Gads, but I should slow down on my typing.

[#] Thu Jul 17 2014 15:20:31 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


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.

[#] Thu Jul 17 2014 15:43:13 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


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 17:35:35 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


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 17:37:59 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


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 17:44:07 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-upstart-overcome-ptrace-limitations

[#] Thu Jul 17 2014 17:48:59 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


discussion:

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?

[#] Thu Jul 17 2014 17:58:24 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


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.

[#] Thu Jul 17 2014 18:12:55 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


Oh, hm. According to this:

http://en.wikipedia.org/wiki/Systemd

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 21:26:41 UTC from dothebart

[Reply] [ReplyQuoted] [Headers] [Print]

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 21:30:52 UTC from roue <roue@bbs.bubbanfriends.org>

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Fri Jul 18 2014 12:29:28 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


After the first fork, I setsid for a new process group. After the second fork, I open to /dev/null, dup2( fd, STD*_FILENO), then close(fd). I then do the umask(027), set up my signals, create a pid file, etc.

Should I do that earler?

I'm seriously thinking about modifying this code to make it so it starts according to command line parameters... no parameters, no forks, --fork makes it fork once, --daemon makes it fork twice, and --emitstop makes it signal SIGSTOP when it's properly running (after two forks). But something in me finds it irritating to think I might have a need to alter the code in such a way, when you'd think just daemonizing it like any other daemonizing service should do the trick.

I've also considered another way that involves using the pre-start command to actually start the executable, pre-stop to actually stop it, and create a script that monitors that the pid file I create actually refers to a running process to ensure that it's running, since apparently upstart is too broken in this distribution to handle a daemon (unless my daemon is fubared, but the code looks like any other daemonization code I've seen elsewhere, so.. I dunno).

[#] Fri Jul 18 2014 13:34:23 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


Argh!

I wrote a dirt-simple daemon.c that just does the minimum amount of work to daemonize (eventually going to while(1){sleep(1);}), and upstart has no problems with it.

So this means I need to figure out what's wrong with my own attempt to daemonize... something isn't quite working correctly.

strace is still borked with even the simple daemon.c, though, so, plegh.

[#] Fri Jul 18 2014 14:50:55 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


Aaand, now I've figured it all out.

Firstly, I made some incredibly stupid coding errors. I thought I was daemonizing correctly (and at one time I was), but I failed to consider some changes I had made... or more to the point, I forgot to test that I was actually daemonizing after making those changes.

The 'dup2' thing that I learned somewhere else was utter crap... one of the problems of reading a lot of different bits of code from different places is that not everyone who seems like they know what they're doing actually know what they're doing. I read up on the command, thought carefully about what it was actually doing, then threw it away and did something simpler and smarter (a straightforward 'close(STD*_FILENO)').

I'm gratified to know that 'sudo stop [service]' in upstart executes a kill -TERM instead of just a wanton killing of the process, so I have the opportunity to clean up properly.

Heh... so, there you have it. A Windows developer's stumbling, bumbling learning how to upstart.

Hrm... now, if I could figure out a way to get it to start *when* it should start (instead of crashing and being restarted by upstart), I'd have something that provides less impact to the initialization of the machine.

[#] Fri Jul 18 2014 16:20:45 UTC from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


are you running with ulimit -c unlimited?

[#] Fri Jul 18 2014 16:28:17 UTC from fleeb

[Reply] [ReplyQuoted] [Headers] [Print]


ulimit -c returns '0'.

I found the answer to my question.

start on (local-filesystems and net-device-up IFACE!=lo)

That line within the .conf file you put in /etc/init (not /etc/init.d) fixes the issue. Now, it starts when the interface I need is running.

I could maybe get away without the local-filesystems, but I realize that I need to look at configuration files, so it makes sense to keep that as a dependency as well. Not that a network tends to run before the filesystem, but I guess when you're massively parralleling the startup, it's always a possibility.

Go to page: First ... 6 7 8 9 [10] 11 12 13 14 ... Last