=== robbiew is now known as robbiew_ | ||
=== juergbi_ is now known as juergbi | ||
=== [2]sassyn is now known as sassyn | ||
=== ev1 is now known as ev | ||
=== ev1 is now known as ev | ||
=== robbiew_ is now known as robbiew | ||
=== [3]sassyn is now known as sassyn | ||
mistergibson | is this the channel for ubuntu networking stuff? | 20:30 |
---|---|---|
xopah | Hello could someone help me in a matter where I have hard to connect to a multiple SSID WLAN network? | 20:32 |
Keybuk | xopah: that has nothing to do with Upstart, sorry | 20:37 |
ion | Two persons from totally different parts thought this channel has something to do with networkingithin a couple of minutes? Interesting occurrence. | 20:45 |
ion | networking within | 20:45 |
xopah | keybuk: could you please point me in the right direction? | 20:48 |
xopah | Wher shuld I turn? | 20:48 |
sadmac | xopah: #ubuntu would be a good next stop | 20:49 |
xopah | ion: we were recommended to go here from #ubuntu ... | 20:49 |
sadmac | Keybuk: ^^WTF?!? | 20:49 |
xopah | sadmac: thanks. I'll try there again. | 20:50 |
sadmac | xopah: np | 20:50 |
sadmac | hmm. Is #ubuntu having troll problems? | 20:50 |
* sadmac imagine's Scott's "you're making absolutely no sense" face | 20:52 | |
Younder | I am having problems with programs due to a pygtk not beeing seen | 20:52 |
Younder | there are multiple python versions and it worked under gentoo | 20:53 |
sadmac | Younder: how does this relate to upstart? | 20:53 |
* sadmac begins to get a sinking feeling | 20:54 | |
Younder | sorry I'll go back to the python group.. take my chances | 20:55 |
=== robbiew is now known as robbiew-afk | ||
=== robbiew-afk is now known as robbiew_ | ||
* Keybuk wonders whether there's a channel mode flag | 20:58 | |
Keybuk | to refuse entry to people also in #ubuntu | 20:58 |
sadmac | Keybuk: wouldn't that block, say, you for example? | 20:58 |
Keybuk | no | 20:58 |
Keybuk | I'm not in #ubuntu | 20:58 |
sadmac | Keybuk: heh. maybe I don't understand #ubuntu | 20:59 |
* sadmac is in #fedora | 20:59 | |
Keybuk | Ubuntu is where users go to ask questions | 20:59 |
Keybuk | err #ubuntu | 20:59 |
sadmac | Keybuk: yeah. so is #fedora. I like to meet the people | 21:00 |
Keybuk | we have more users than you | 21:00 |
Keybuk | a LOT more users | 21:00 |
Keybuk | they whine more too | 21:00 |
sadmac | Keybuk: yeah, I don't know that I'd like to meet /your/ users. Ours troll more than yours I'd imagine though | 21:00 |
Keybuk | at least yours might know something of what they're talking about :p | 21:00 |
sadmac | Keybuk: actually I think 3/4 of the people giving help at any time in #fedora just have irssi set up to periodically say "www.justfuckinggoogleit.com" | 21:01 |
ion | sadmac: Just for fun, join #ubuntu for a minute. It’ll be an... interesting experience. :-P | 21:01 |
ion | “I visited #ubuntu shortly and survived” | 21:02 |
sadmac | Keybuk: again though, if you do have so many more users, wouldn't you also be blocking half the relevant portion of the internet? | 21:02 |
* raphael__ wonders how #ubuntu, #fedora and #debian compare | 21:02 | |
sadmac | ion: My God, its full of stars! | 21:02 |
ion | It’s full of trolls and the blind trying to lead the blind! rather. | 21:03 |
sadmac | #debian is nearly as big and not 1/10 as noisy | 21:03 |
notting | ion: that doesn't help me delineate between the three | 21:04 |
sadmac | ion: they seem to be under the impression that they're linux users of some kind | 21:04 |
sadmac | from what I've heard, #debian has all /their/ advice macro'd to "go install Ubuntu" | 21:04 |
raphael__ | sadmac: don't think so, it's usually /msg dpkg foo | 21:05 |
sadmac | raphael__: the users know what dpkg is? sounds like a nice place. | 21:07 |
Keybuk | sadmac: dpkg is a bot on #debian | 21:07 |
* raphael__ wonders how long Keybuk is going to wait before setting mode +m to stop this offtopic conversation :) | 21:07 | |
sadmac | Keybuk: oic | 21:08 |
Keybuk | raphael__: this channel rarely gets on-topic :p | 21:08 |
raphael__ | Keybuk: but from what I've seen off-topic conversations don't last this long ;) | 21:08 |
sadmac | Keybuk: fine. on topic: I'm finally edging near a workable nih_parse, which is, of course, making me want to replace nih_error while I'm at it :) | 21:08 |
Younder | Yes, it would be terrible if that actual users of upstart got a say :) | 21:09 |
sadmac | Younder: what are you talking about? | 21:10 |
Keybuk | sadmac: what were you going to change? | 21:11 |
Younder | Well at present the boot process, to me at any rate, is very confused. I can't see where sysv ends and upstart begins. | 21:11 |
sadmac | Keybuk: probably not change so much as a new mechanism, along the lines of the lisp condition/restart thing that I've poked at a few times | 21:11 |
Keybuk | Younder: depends which distro you look at | 21:12 |
Younder | ubuntu 9.10 | 21:12 |
sadmac | Keybuk: it would also make a nice replacement for nih_log while we're at it (probably with no API change there) | 21:12 |
Keybuk | most actual Linux distributions tend to have the Upstart /sbin/init daemon run the SysV-style rc scripts (/etc/init.d) | 21:12 |
Keybuk | some distributions (like Ubuntu) do far more in a Upstart native way than others (like Fedora) | 21:13 |
Keybuk | embedded Linux platforms (Chrome OS, Palm Web OS, Maemo, etc.) often use Upstart entirely natively | 21:13 |
Keybuk | Younder: read you read "man runlevel" ? | 21:13 |
Keybuk | sadmac: I know I'm going to regret this, but ... explain? :p | 21:13 |
sadmac | notting: since I'm thinking of it, when do you want 0.6 tagged into rawhide? Will you just do it yourself when initscripts is ready? | 21:14 |
Keybuk | Younder: that should be "man 7 runlevel" | 21:14 |
sadmac | Keybuk: basically there is a function/macro called nih_sig() | 21:14 |
Younder | Keybuk, sure, but gtk is not on any runlevel. Tomcat and apache, however, are. | 21:14 |
Keybuk | Younder: that's because GTK+ has nothing to do with Upstart | 21:14 |
Keybuk | and Upstart has nothing to do with GTK+ either | 21:14 |
Keybuk | my toaster is also not on any runlevel | 21:15 |
sadmac | Keybuk: if (some_error) nih_sig (TYPE_OF_ERROR, &some_info, &some_more_info); | 21:15 |
notting | sadmac: hrm. i haven't looked at the other apps. so i'll probably work on it tomorrow or thursday | 21:15 |
Keybuk | yet I can still make toasted goodness | 21:15 |
Keybuk | sadmac: that's basically how nih_error behaves, no? | 21:15 |
Younder | and ubuntu has nothing to with upstart either..? | 21:15 |
sadmac | Keybuk: well, what nih_sig does is interesting | 21:15 |
Younder | They just created it | 21:15 |
Keybuk | Younder: Ubuntu uses Upstart, yes | 21:15 |
michas | hi, I am trying to debug some ubuntu init.d scripts by adding some echo lines. Unfortunately they print nowhere. :( If I understood everything right, upstart is the one who emulates old init and executes the scripts. - Is there a way to make that echo output visible? | 21:16 |
ion | Younder is clearly a troll. Let’s not feed it anymore. :-P | 21:16 |
Younder | I guess what I wnat to know is: is there a reference manual for upstart? | 21:16 |
sadmac | Keybuk: nih_sig runs a handler for the error, which is a function pointer registered beforehand | 21:16 |
Keybuk | Younder: plenty, start at "man upstart" on your system? | 21:17 |
sadmac | Keybuk: that function runs right away, and either 1) corrects the error (notice the args passed by ref) 2) longjmps, or 3) aborts | 21:17 |
Keybuk | ah | 21:17 |
Keybuk | more like dpkg-style | 21:17 |
Younder | Keybuk, info? | 21:17 |
Keybuk | you have ohshit() | 21:17 |
raphael__ | btw, what's all the nih_foo? I saw it on ureadahead and seemed like it is being used in other places, but it's sort of strange that it doesn't seem to be a shlib | 21:17 |
sadmac | Keybuk: never seen dpkg code | 21:18 |
Keybuk | ohshit calls any registered error handlers and longjmps back up | 21:18 |
Keybuk | raphael__: it is in lucid | 21:18 |
Younder | never mind | 21:18 |
sadmac | Keybuk: the nih_log thing comes in under the "corrects the error" option. nih_log just calls nih_sig (LOG_EVENT_$LEVEL, log_text) | 21:19 |
Keybuk | oh, I see where you're going with that | 21:19 |
sadmac | Keybuk: the default handler does just what nih_log does now, but because there's a handler stack, the log line is now also a sort of tracepoint when you're debugging | 21:19 |
Keybuk | it'd be nice if you could thwart the error ;) | 21:19 |
sadmac | Keybuk: yeah, that too | 21:20 |
Keybuk | e.g. if you raise ENOFILE, an error handler could increase the rlimit, then make you try again | 21:20 |
sadmac | Keybuk: precisely the idea | 21:20 |
Keybuk | but then that requires while loops and stuff ;) | 21:20 |
Keybuk | while (some_syscall (...) < 0) | 21:20 |
ion | Yeah, the condition/restart thing is powerful. | 21:20 |
Keybuk | nih_sig (...) | 21:20 |
Keybuk | ie. assume that nih_sig solves the problem or longjmps you out | 21:20 |
Keybuk | this is basically how dpkg works | 21:21 |
sadmac | Keybuk: I'm pulling apart libunwind now to see if it has anything to make some of the uglies around longjmp | 21:21 |
ion | More powerful than plain exceptions. | 21:21 |
Keybuk | I spent a long time maintaining dpkg | 21:21 |
Keybuk | nih_error was originally written for dpkg2 ;) | 21:21 |
Keybuk | it doesn't behave the same way for a reason | 21:21 |
sadmac | ion: and, ironically, easier to do in C | 21:21 |
Keybuk | a *lot* of problems with dpkg were caused by errant error handlers | 21:21 |
sadmac | Keybuk: I think it can be made cleaner than it has been. | 21:22 |
sadmac | I'll play with it if I get to it. right now I want to get the parser standing up so I can finish the early triggers stuff and push some of it. | 21:23 |
michas | hi, I am trying to debug some ubuntu init.d scripts by adding some echo lines. Unfortunately they print nowhere. :( If I understood everything right, upstart is the one who emulates old init and executes the scripts. - Is there a way to make that echo output visible? (Any hint?) | 21:26 |
sadmac | michas: add a line to the jobs that says "console output" | 21:26 |
michas | sadmac, well, it is an old init.d script. IIRC "console output" works only in the real upstart scripts. | 21:27 |
michas | the first "log_action_begin_msg" prints, but any further echo or log doesn't print anymore. I assume it ist upstart filtering the output or something... | 21:28 |
sadmac | michas: that's going to depend on how upstart is being used to run sysv scripts in ubuntu. you'll have to ask in an ubuntu related channel | 21:29 |
ion | michas: If the script sources /lib/lsb/init-functions, try log_action_msg "foo" or something like that. | 21:29 |
Keybuk | still won't work ;) | 21:30 |
Keybuk | michas: write to a different file, e.g. echo blah blah >> /dev/my.log | 21:30 |
michas | ion, it does use init-function. the first log message works. the second does not. - that's why I suspect upstart. | 21:30 |
Keybuk | nothing to do with upstart per se | 21:31 |
Keybuk | Ubuntu has a "no messages on console during boot" policy | 21:31 |
ion | michas: Please ignore what i said and do what Keybuk said. :-) | 21:31 |
Keybuk | they get hidden with extreme prejudice | 21:31 |
michas | Keybuk, ok, that will surely do. but I'm still wordering wtf is goin on there. ;) | 21:31 |
Keybuk | michas: there are ways to make them appear | 21:34 |
Keybuk | you can add "console output" to /etc/init/rc.conf and /etc/init/rc-sysinit.conf | 21:34 |
Keybuk | and something like console=tty1 to your kernel command-lien | 21:34 |
Keybuk | making sure not to run usplash | 21:34 |
Keybuk | that brings most of them back | 21:34 |
michas | ah, thanks, that looks good. I'll try that. | 21:35 |
Keybuk | but if it doesn't work, try #ubuntu ;) | 21:35 |
ion | :-D | 21:35 |
michas | allright, I'll do. thanks. | 21:36 |
michas | one last real upstart question: ist there a way to do something like "start on *" f.e. to monitor all events? | 21:38 |
Keybuk | no | 21:39 |
ion | Why would you want that? | 21:39 |
Keybuk | such a thing would match itself, for a start | 21:39 |
Keybuk | including its own stopped event ;) | 21:39 |
Keybuk | if you instanced it, you'd end up with a fork bomb | 21:39 |
michas | I just started to read about all the upstart stuff. And then I wondered what events will happen at a startup on my system. | 21:40 |
sadmac | there used to be a way to dump them as they happened, but we removed it. | 21:41 |
sadmac | kind of a dangerous thing. People do horrible things when you give them access to that sort of thing from shell scripts. | 21:42 |
michas | :) ok, guess you are right. :) | 21:42 |
Keybuk | you can still see them with --verbose | 21:42 |
Keybuk | there's thousands in the startup of a typical ubuntu system | 21:43 |
michas | where do I have to put that --verbose? | 21:43 |
ion | keybuk: --verbose or --debug? | 21:43 |
Keybuk | michas: kernel command-line | 21:43 |
Keybuk | ion: I tend to recommend --verbose these days | 21:43 |
ion | Alright | 21:43 |
Keybuk | --debug adds things you generally don't want to see | 21:43 |
sadmac | michas: you could also systemtap them out if you have a recent enough version and a little elbow grease to apply | 21:44 |
* sadmac makes a note to add stap tracepoints to upstart for doing that sort of thing | 21:44 | |
michas | are those options documented anywhere? | 21:45 |
Keybuk | michas: no | 21:46 |
michas | ok :) | 21:46 |
Keybuk | (unless you count "init --help" :p) | 21:46 |
michas | oops. too easy. | 21:47 |
michas | ok, thanks a lot. (That current upstart/rc mix in ubuntu is quite confusing, once things don't work as expected... Hope, they switch to upstart completely soon.) | 21:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!