[04:44] <SpamapS> tmike: the test suite is not meant to be run as root, in fact I believe it is meant to fail as root
[04:46] <SpamapS> tmike: there's one fail that is no big deal, just a different error message. The one where len is expected to be 13 and is 0 looks more serious.
[13:05] <pmjdebruijn> hi
[13:05] <pmjdebruijn> are there known issues with upstart and lots of file descriptors?
[13:05] <pmjdebruijn> I'm running dansguardian -N (=foreground) from an upstart job
[13:05] <pmjdebruijn> with 4000 file descriptors
[13:05] <pmjdebruijn> seems to work fine from the init script
[13:10] <pmjdebruijn> though I'm wondering if upstart ignores the ulimit I have in there... and/or the security/limits.conf
[13:29] <jodh> pmjdebruijn: upstart doesn't have pam support so limits.conf is not used.
[13:29] <pmjdebruijn> ah ok
[13:30] <pmjdebruijn> but settings ulimit -n in the pre-start script doesn't seem to help either
[13:32] <jodh> pmjdebruijn: that's because the pre-start is run as a process so any other process spawned from that job won't be affected by what you do in pre-start.
[13:32] <jodh> pmjdebruijn: You need the limit stanza - http://upstart.ubuntu.com/cookbook/#limit
[13:32] <jodh> pmjdebruijn: init(5) for full details.
[13:34] <pmjdebruijn> jodh: that makes sense, but the squid package in maverick has ulimit set in pre-start
[13:34] <jodh> pmjdebruijn: sounds like you found a bug then ;-)
[13:37] <pmjdebruijn> heh
[13:37] <jodh> pmjdebruijn: still seems to be a problem in precise: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/squid/precise/view/head:/debian/squid.upstart Could you raise a bug on this? (so you get the kudos :) - https://bugs.launchpad.net/ubuntu/precise/+source/squid/+filebug
[13:38] <pmjdebruijn> jodh: I haven't verified this is a problem in squid
[13:39] <pmjdebruijn> I just used it as a (bad) example
[13:51] <pmjdebruijn> well let me file the issue
[13:52] <jodh> pmjdebruijn: thanks. either that "ulimit -n" needs to be moved to the script section, or "limit nofile $var $var" syntax needs to be used.
[13:52] <pmjdebruijn> https://bugs.launchpad.net/ubuntu/+source/squid/+bug/580590
[13:52] <pmjdebruijn> though that contains a verification
[13:52] <pmjdebruijn> odd
[13:53] <tmike> Would anyone happen to know if this error in the build logs is a serious issue?: http://pastebin.com/9UCnd4gg
[13:53] <tmike> check log*
[13:54] <jodh> tmike: what shell are you using for /bin/sh?
[13:54] <tmike> bash
[13:54] <jodh> tmike: oh.
[13:55] <jodh> tmike: that explains it. /bin/sh is not supposed to be bash. However, please raise a bug on upstart so we can tweak the test case for this: https://bugs.launchpad.net/upstart/+filebug
[13:56] <tmike> What is /bin/sh supposed to be, then?
[13:56] <pmjdebruijn> dash probably
[13:56] <jodh> tmike: correct.
[13:56] <jodh> pmjdebruijn: correct even :)
[13:56] <tmike> I could see that.  All right.  Building dash it is then.
[13:56] <tmike> This is on a linux from scratch build.
[13:56] <tmike> Well, before I do that, is it a problem that I use bash instead of dash?
[13:57] <jodh> tmike: interesting!
[13:57] <tmike> Lots of fun.  It boots with sysv init right now, but I'm experimenting with upstart.
[13:57] <jodh> tmike: the recommendation is not to use bash for /bin/sh for performance but primarily security reasons. bash syntax is too expressive and dash is "just a posix shell"
[13:59] <jodh> tmike: since upstart is going to be using /bin/sh to run most of your jobs, it really is best to use a very basic shell.
[13:59] <tmike> very interesting
[13:59] <tmike> thank you for your advice
[14:00] <jodh> tmike: See also http://upstart.ubuntu.com/cookbook/#debugging-a-script-which-appears-to-be-behaving-oddly
[14:00] <tmike> That's a very useful bit of information.  As it is, I'm having trouble even using the provide sulogin
[14:01] <jodh> tmike: to be clear, I'm not implying bash is actually insecure, but it's overkill for upstarts needs.
[14:01] <pmjdebruijn> check-bashims is quite handy :D
[14:01] <pmjdebruijn> check-bashisms even
[14:01] <tmike> linux /vmlinuz-3.1.blah root=(hd0,3) init=/opt/sbin/sulogin behaves just like a regular init.  Starts up my daemons and dumps me at a login prompt
[14:02] <jodh> tmike: I'd be very interested to hear on your progress with linux from scratch. It might even merit a section in the cookbook.
[14:03] <tmike> the upstart init itself gets to the point where it tries to mount my drives; I'm not sure whether it succeeds.  Then it prints some USB information and just stops
[14:03] <tmike> Which may very well be related to the link you posted above, hodh
[14:03] <tmike> jodh*
[14:04] <tmike> It's using the default init scripts at the moment as I haven't written any real upstart jobs for it, and I'm almost certain something in there needs to be modified to point back to a correct executable for upstart.
[14:05] <tmike> By default, I mean it's going through my sysv init scripts and running those
[14:07] <tmike> I thought it would be worth a shot, because LFS is about as untainted an OS as you can get.  Most distros have a great deal of customization done where LFS is almost entirely vanilla source for all its packages.
[14:07] <jodh> tmike: well, you'll need to ensure the system boots with init=/sbin/init where that is the upstart binary. You'll also need to "SysV compat" jobs (rc.conf and rc-sysinit.conf) - http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/upstart/precise/files/head:/conf/
[14:08] <jodh> tmike: I'd suggest reading the cookbook. In particular http://upstart.ubuntu.com/cookbook/#startup
[14:08] <jodh> tmike: udevd, upstart-udev-bridge and mountall are also going to be important. Maybe you could post to the upstart-devel ML with progress?
[14:09] <tmike> Correct, I've been in that cookbook for a while.  It seems I'll be handling a lot of that stuff manually; mountall looks a lot like it wants *ubuntu specific setups
[14:10] <jodh> tmike: Ubuntu does use mountall for mounting yes. It's "ubuntu-specific" in the sense that only Ubuntu uses it. Note that rhel 6 / centos 6 don't use mountall. They only use upstart minimally at this stage so it might be worth seeing what they've done to get you going.
[14:10] <tmike> I may very well.  Mountall also doesn't seem like it wants to build without plymouth.  No offense to plymouth, but NO THANK YOU.
[14:11] <tmike> ;)
[14:11] <tmike> Too much effort to start building initramfs's and trying to configure all that garbage
[14:12] <tmike> A shame actually.  Plymouth seems pretty nice, and if I had luks on this VM, I'd love to have a lovely interface for my password entries.
[14:16] <tmike> The 'start on' and 'stop on' directives, do they actually call the executables {start,stop} or are they interpreted?
[14:18] <jodh> tmike: they tell upstart when to start the overall job. See http://upstart.ubuntu.com/cookbook/#really-understanding-start-on-and-stop-on
[14:19] <tmike> Okay.  Just wanted to make sure I didn't need to do anything ridiculous like change all "start on" to "/opt/sbin/start on"
[14:19] <JanC> an upstart job description isn't a script  ;)
[14:20] <tmike> That's exactly what I figured, but I thought it easier to ask rather than go down that road later when debugging, only to have to walk all the way back ;)
[14:21] <tmike> Maybe this afternoon I'll set about building *.in files for these .confs for the make job, such as to prepend the $PREFIX/bindir to the commands.
[14:22] <tmike> for the exec commands and such
[14:34] <tmike> My oh my these errors are colorful ;D
[14:35] <tmike> http://imgur.com/2HQI5
[14:35] <tmike> That's all script-funkiness though.  Will need to discover why that stuff's not getting mounted.
[15:15] <tmike> Awesome, got one step further.
[15:15] <tmike> rc-sysinit.conf tries to execute /etc/init.d/rcS, which my system doesn't have
[15:16] <tmike> However, /etc/init.d/rc S (note that S is a parameter) replaces that functionality.
[15:16] <tmike> As dictated by my inittab.
[15:16] <tmike> Now it crashes mounting my virtual filesystems
[15:19] <tmike> And actually it only sort of dies.  I can let it continue past that point, where it runs up to just before giving me a login prompt, where it just stops
[15:20] <tmike> Fortunately, it starts SSH for me, so I can still SSH into it :D
[15:21] <tmike> Once I solve that problem, it will have worked virtually out of the box.
[15:22] <tmike> Well, I guess not really.  Still a mess of errors in the logs.
[15:24] <tmike> It seems to repeat the whole process, which means I'm probably calling rc S twice, or further rc steps call rc S
[15:35] <tmike> initctl list lists all the tasks in /etc/init as in 'stop/waiting' though
[15:36] <tmike> Is that correct?
[15:39] <jodh> tmike: you'd expect rc jobs to be stopped once the system has booted, yes. might be worth grabbing an Ubuntu image so you can compare your results with a normal upstart system.
[15:39] <tmike> That's what I thought.
[15:40] <tmike> I expect that's the reason why the system manages to get to the end of the rc stuff, but never places me at a login.  There's either something that's missing or it's in a race condition.
[15:40] <tmike> And it never releases from the rc jobs
[15:41] <tmike> My host is ubuntu, so it'll be easy to dig in there to see
[15:41] <jodh> tmike: look at this for some hints: http://upstart.ubuntu.com/cookbook/#debugging. have to afk...
[15:43] <tmike> Thanks for your help
[16:07] <tmike> So, when you get back, or to anyone else who's around, does 'stop/waiting' mean it's not yet started, that it's stuck waiting TO stop, or that it has stopped?
[17:25] <jodh> tmike: that's the "rest" state - it has either never started, or has now stopped. See http://upstart.ubuntu.com/cookbook/#initctl-status
[17:26] <tmike> Okay, that's good then
[17:26] <jodh> tmike: Try booting with --debug/--verbose to see what events are being emitted and which jobs are starting, etc: http://upstart.ubuntu.com/cookbook/#add-verbose-or-debug-to-the-kernel-command-line
[17:55] <tmike> Seems everything is groovy there
[20:06] <jdiggy> Hi! I'd like to check for the existence of Upstart in a script. The best idea that I've had so far has been to check the output of `init --version`.
[20:31] <jdiggy> any way to reimport my configuration without restarting? like if I screw it up and just want to reload it.
[20:32] <jdiggy> My bad. wrong channel.
[20:32] <jdiggy> Here, I want to ask if anybody knows how to check whether Upstart is installed in, say, a Bash script? My current best idea is `init --version`.
[20:33] <ion> Some implementations of init might do something unexpected with --version, though.
[20:34] <jdiggy> Agreed. That's why I'm looking for something more reliable. The existence of some file or other. 
[20:34] <jdiggy> Upstart's configuration directory is called /etc/init. The bins are called init, start, stop, restart.