[04:44] 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] 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. === ion__ is now known as ion [13:05] hi [13:05] are there known issues with upstart and lots of file descriptors? [13:05] I'm running dansguardian -N (=foreground) from an upstart job [13:05] with 4000 file descriptors [13:05] seems to work fine from the init script [13:10] though I'm wondering if upstart ignores the ulimit I have in there... and/or the security/limits.conf [13:29] pmjdebruijn: upstart doesn't have pam support so limits.conf is not used. [13:29] ah ok [13:30] but settings ulimit -n in the pre-start script doesn't seem to help either [13:32] 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] pmjdebruijn: You need the limit stanza - http://upstart.ubuntu.com/cookbook/#limit [13:32] pmjdebruijn: init(5) for full details. [13:34] jodh: that makes sense, but the squid package in maverick has ulimit set in pre-start [13:34] pmjdebruijn: sounds like you found a bug then ;-) [13:37] heh [13:37] 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] jodh: I haven't verified this is a problem in squid [13:39] I just used it as a (bad) example [13:51] well let me file the issue [13:52] 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] https://bugs.launchpad.net/ubuntu/+source/squid/+bug/580590 [13:52] though that contains a verification [13:52] odd [13:53] Would anyone happen to know if this error in the build logs is a serious issue?: http://pastebin.com/9UCnd4gg [13:53] check log* [13:54] tmike: what shell are you using for /bin/sh? [13:54] bash [13:54] tmike: oh. [13:55] 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] What is /bin/sh supposed to be, then? [13:56] dash probably [13:56] tmike: correct. [13:56] pmjdebruijn: correct even :) [13:56] I could see that. All right. Building dash it is then. [13:56] This is on a linux from scratch build. [13:56] Well, before I do that, is it a problem that I use bash instead of dash? [13:57] tmike: interesting! [13:57] Lots of fun. It boots with sysv init right now, but I'm experimenting with upstart. [13:57] 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] 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] very interesting [13:59] thank you for your advice [14:00] tmike: See also http://upstart.ubuntu.com/cookbook/#debugging-a-script-which-appears-to-be-behaving-oddly [14:00] That's a very useful bit of information. As it is, I'm having trouble even using the provide sulogin [14:01] tmike: to be clear, I'm not implying bash is actually insecure, but it's overkill for upstarts needs. [14:01] check-bashims is quite handy :D [14:01] check-bashisms even [14:01] 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] 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] 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] Which may very well be related to the link you posted above, hodh [14:03] jodh* [14:04] 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] By default, I mean it's going through my sysv init scripts and running those [14:07] 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] 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] tmike: I'd suggest reading the cookbook. In particular http://upstart.ubuntu.com/cookbook/#startup [14:08] 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] 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] 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] 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] ;) [14:11] Too much effort to start building initramfs's and trying to configure all that garbage [14:12] 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] The 'start on' and 'stop on' directives, do they actually call the executables {start,stop} or are they interpreted? [14:18] 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] 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] an upstart job description isn't a script ;) [14:20] 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] 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] for the exec commands and such [14:34] My oh my these errors are colorful ;D [14:35] http://imgur.com/2HQI5 [14:35] That's all script-funkiness though. Will need to discover why that stuff's not getting mounted. [15:15] Awesome, got one step further. [15:15] rc-sysinit.conf tries to execute /etc/init.d/rcS, which my system doesn't have [15:16] However, /etc/init.d/rc S (note that S is a parameter) replaces that functionality. [15:16] As dictated by my inittab. [15:16] Now it crashes mounting my virtual filesystems [15:19] 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] Fortunately, it starts SSH for me, so I can still SSH into it :D [15:21] Once I solve that problem, it will have worked virtually out of the box. [15:22] Well, I guess not really. Still a mess of errors in the logs. [15:24] 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] initctl list lists all the tasks in /etc/init as in 'stop/waiting' though [15:36] Is that correct? [15:39] 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] That's what I thought. [15:40] 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] And it never releases from the rc jobs [15:41] My host is ubuntu, so it'll be easy to dig in there to see [15:41] tmike: look at this for some hints: http://upstart.ubuntu.com/cookbook/#debugging. have to afk... [15:43] Thanks for your help [16:07] 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] 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] Okay, that's good then [17:26] 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] Seems everything is groovy there [20:06] 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] any way to reimport my configuration without restarting? like if I screw it up and just want to reload it. [20:32] My bad. wrong channel. [20:32] 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] Some implementations of init might do something unexpected with --version, though. [20:34] Agreed. That's why I'm looking for something more reliable. The existence of some file or other. [20:34] Upstart's configuration directory is called /etc/init. The bins are called init, start, stop, restart.