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:44 |
---|---|---|
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. | 04:46 |
=== ion__ is now known as ion | ||
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:05 |
pmjdebruijn | though I'm wondering if upstart ignores the ulimit I have in there... and/or the security/limits.conf | 13:10 |
jodh | pmjdebruijn: upstart doesn't have pam support so limits.conf is not used. | 13:29 |
pmjdebruijn | ah ok | 13:29 |
pmjdebruijn | but settings ulimit -n in the pre-start script doesn't seem to help either | 13:30 |
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:32 |
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:34 |
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:37 |
pmjdebruijn | jodh: I haven't verified this is a problem in squid | 13:38 |
pmjdebruijn | I just used it as a (bad) example | 13:39 |
pmjdebruijn | well let me file the issue | 13:51 |
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:52 |
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:53 |
jodh | tmike: what shell are you using for /bin/sh? | 13:54 |
tmike | bash | 13:54 |
jodh | tmike: oh. | 13:54 |
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:55 |
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:56 |
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:57 |
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 | 13:59 |
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:00 |
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:01 |
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:02 |
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:03 |
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:04 |
tmike | By default, I mean it's going through my sysv init scripts and running those | 14:05 |
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:07 |
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:08 |
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:09 |
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:10 |
tmike | ;) | 14:11 |
tmike | Too much effort to start building initramfs's and trying to configure all that garbage | 14:11 |
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:12 |
tmike | The 'start on' and 'stop on' directives, do they actually call the executables {start,stop} or are they interpreted? | 14:16 |
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:18 |
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:19 |
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:20 |
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:21 |
tmike | for the exec commands and such | 14:22 |
tmike | My oh my these errors are colorful ;D | 14:34 |
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. | 14:35 |
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:15 |
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:16 |
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:19 |
tmike | Fortunately, it starts SSH for me, so I can still SSH into it :D | 15:20 |
tmike | Once I solve that problem, it will have worked virtually out of the box. | 15:21 |
tmike | Well, I guess not really. Still a mess of errors in the logs. | 15:22 |
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:24 |
tmike | initctl list lists all the tasks in /etc/init as in 'stop/waiting' though | 15:35 |
tmike | Is that correct? | 15:36 |
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:39 |
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:40 |
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:41 |
tmike | Thanks for your help | 15:43 |
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? | 16:07 |
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:25 |
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:26 |
tmike | Seems everything is groovy there | 17:55 |
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:06 |
jdiggy | any way to reimport my configuration without restarting? like if I screw it up and just want to reload it. | 20:31 |
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:32 |
ion | Some implementations of init might do something unexpected with --version, though. | 20:33 |
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. | 20:34 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!