Language:
switch to room list switch to menu My folders
Go to page: First ... 5 6 7 8 [9] 10 11 12 13 ... Last
[#] Thu Jul 17 2014 13:35:35 EDT from LoanShark @ Uncensored

[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 13:37:59 EDT from LoanShark @ Uncensored

[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 13:44:07 EDT from LoanShark @ Uncensored

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


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

[#] Thu Jul 17 2014 13:48:59 EDT from LoanShark @ Uncensored

[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 13:58:24 EDT from fleeb @ Uncensored

[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 14:12:55 EDT from fleeb @ Uncensored

[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 17:26:41 EDT from dothebart @ Uncensored

[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 17:30:52 EDT from roue @ Dog Pound BBS II

[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 08:29:28 EDT from fleeb @ Uncensored

[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 09:34:23 EDT from fleeb @ Uncensored

[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 10:50:55 EDT from fleeb @ Uncensored

[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 12:20:45 EDT from LoanShark @ Uncensored

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


are you running with ulimit -c unlimited?

[#] Fri Jul 18 2014 12:28:17 EDT from fleeb @ Uncensored

[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.

[#] Fri Jul 18 2014 16:15:23 EDT from IGnatius T Foobar @ Uncensored

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


Don't bother optimizing for upstart; it's going away in favor of systemd, even in Ubuntu.

systemd can be told to run stuff in the foreground, as if it were called directly from /etc/inittab under old init. I don't know how kosher that is (probably not very) but it does work.

[#] Fri Jul 18 2014 17:44:28 EDT from LoanShark @ Uncensored

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

called directly from /etc/inittab under old init. I don't know how
kosher that is (probably not very) but it does work.

Not very kosher under old init, because you had to change runlevels just to enable/disable a specific service.

Might not be considered such a bad thing under a fancier init.

[#] Fri Jul 18 2014 22:20:13 EDT from fleeb @ Uncensored

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


I'm intending to write configurations for the three styles of startup.

I have a couple of sysv scripts made, and (now) the upstart. Next, I'll want to create one for systemd.

At the very least, supporting these more recent inits allow me to take advantage of parrallelization, which strikes me as a good thing.

[#] Sat Jul 19 2014 12:53:58 EDT from IGnatius T Foobar @ Uncensored

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

Hmm, I just thought of something:

Some programs use -d (debug) to force them to stay in the foreground (and spew debug info)

Some programs use -d (daemon) to force them to go into the background

This is an atrocity. I blame the previous owner of my old house, whose last name begins with the letter D, for this atrocity.

[#] Sat Jul 19 2014 14:34:00 EDT from zooer @ Uncensored

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

Stupid standards.

[#] Sat Jul 19 2014 14:34:08 EDT from zooer @ Uncensored

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

I would call Linus.

[#] Sat Jul 19 2014 14:54:14 EDT from fleeb @ Uncensored

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


I am not sure, but -v seems to be more popular for debugging info (e.g. 'verbose').
But, again, I kinda feel like I'm dipping my toe into all of this.

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