=== rberger_ is now known as rberger [09:53] I've tried to manage my upstart services with both "rcconf" and "bum" to make some services start (or not start) automatically. However, it simply does not work. If I disable "mysql" it shows up as disables in both rcconf and bum, but it still starts up when I boot [09:54] any idea what the problem could be [13:12] bottiger: that's more of a debian/ubuntu question [15:41] hi there. [15:41] is this the correct group for upstart in ubuntu? [15:41] or is this group rather general? [15:42] this is the general group for the different distribution maintainers developing upstart [15:42] if you're having ubuntu problems, you should ask in #ubuntu [15:47] if got an upstart problem in ubuntu 10.04 alpha... ok, i'll try at #ubuntu [15:47] s/if/i've === elpargo_ is now known as elpargo [20:03] so process supervision :) [20:03] is there any way for upstart to indicate that something has been respawned other than its syslog entries? [20:04] (I'm thinking that as a sysadmin I'd want realtime alerts that $IMPORTANTDAEMON has died and been restarted, ideally not by having to do realtime syslog analysis) [20:09] Ng: you could detect the starting event from another job and have that fire off whatever [20:10] oh interesting [20:17] oh the starting event, not a specific respawning event? [20:18] actually what I'd care about is the *dying* of a process, but that's implied by it having been restarted ;) [20:19] Ng: I think you get a stopping event too [20:19] there's no respawning event though [20:19] you definitely don't get a stopped event when respawning. it doesn't make it all the way down. [20:20] it might be a little annoying if booting a machine triggered a bunch of alerts ;) === elpargo_ is now known as elpargo === elpargo_ is now known as elpargo [21:45] `script` stanza could use an extension: [21:46] script /bin/bash [21:46] \tfoo [21:46] end script [21:46] but then we don't know whether what you give supports /proc/self/fd [21:46] and we don't know whether it supports "-e" [21:46] True. [21:47] we don't know whether it supports being able to give single commands with "-c" [21:47] I'd probably just say: yeah. if it support -e, you have to add it [21:47] I like the fact that script -es by default [21:47] script sh [21:47] ... [21:47] end script [21:47] would bypass that [21:47] and be remarkably inconsistent [21:47] that is true. [21:48] well, you see where I'm going. [21:48] script python [21:48] blah [21:48] I'd probably just say adopt the same semantics any +x file has [21:54] Keybuk: what if we allowed you to pipe part of the job definition to the exec stanza's argument? [21:54] exec python << import foo [21:54] main() [21:54] END [21:54] That looks weird. [21:55] It might be an argument for not using 'script', but instead extending 'exec' into a block stanza./ [21:55] with script being locked to sh -e [21:55] s [21:55] wasabi: it does, but it skirts most of Keybuk's arguments semantically. I'm in the habit of doing this. Eventually it results in Really Cool Things. [21:55] exec python [21:55] import foo [21:55] main() [21:55] end exec [21:56] Since exec is already defined as not passing any arguments. [21:56] I think it might be more appropiate too [21:56] that makes the grammar ambiguous if you keep the one-liner exec [21:56] as 'script' might not always even be the right name for it. [21:56] sadmac: I'm just wondering to myself what that exec line would do now ;-) [21:56] since technically exec is just a shortcut for [21:56] script [21:56] exec ... [21:56] end script [21:56] ;-) [21:56] Heh [21:57] what about a utility that reads from stdin to process commands... that you want executed every now and then [21:57] but it's clearly not a scripting language [21:57] Keybuk: it would do the same as always, but make stdin a pipe first, then it'd write the python script into it [21:57] shit, nc [21:57] exec nc host [21:57] \tstuff [21:57] end exec [21:57] right [21:57] there's three different types of program [21:58] 1) those that take commands on command-line, e.g. sh -c "foo;bar;baz" [21:58] wasabi: I spent a week in my security class trying to find ways to trick users into doing that. Making it easier to do voluntarily seems wrong [21:58] 2) those that take a script filename on command-line, e.g. sh /foo/bar.sh [21:58] heh [21:58] sendmail then. :) [21:58] 3) those that take commands on standard input [21:58] exec sendmail admin@isillc.com [21:58] shit's busted [21:58] end exec [21:58] Keybuk: shock moment, what if we just supported shebang lines [21:58] script [21:58] #! /bin/python [21:58] etc [21:58] end script [21:58] heh. [21:59] sadmac: no way to execute that ;-) [21:59] chmod +x /proc/self/fd/4 [21:59] doesn't quite work [21:59] What about symbols in front of the cmd name to specify how the body is passed to it? [21:59] symbols would be ick [21:59] what does the command have to do to supprt /proc/self/fd? [21:59] but I like the idea that you should be able to run things with stdin [21:59] maybe. but there's um [21:59] what's the word for it [21:59] I already want to be able to run things and capture stdout after all [21:59] crap. brain dead. [22:00] sadmac: to do #! you need a filename [22:00] exec - sendmail jhaltom@isillc.com [22:00] foo [22:00] end exec [22:00] that gets passed to stdin [22:00] (making stuff up) [22:00] why not perlish? [22:00] because i don't know perl. [22:00] exec |sendmail jhaltom@isillc.com [22:00] heh [22:00] That's sort ofe stablished elsewhere too [22:00] /etc/aliases [22:00] Keybuk: same reason we couldn't do [22:01] script /bin/python [22:01] end script [22:01] then [22:01] one sec, changing machines [22:02] ah, wing-commander. I missed that box [22:02] exec >sendmail jhaltom@isillc.com [22:02] or | I guess [22:02] Got me [22:02] sadmac: lol, "missed it" ? [22:02] I don't like symbols like that. [22:02] Keybuk: there's a lot you don't know that happened between me and your computer. [22:03] Keybuk: don't judge us. we were young. we did what felt right. [22:03] should I dunk my laptop in bleach? [22:04] Keybuk: yes. and you might want to get a new refridgerator. [22:04] syntax aside for a moment [22:04] what magic input/output/commandline things should we support here? [22:05] stdin makes sense [22:05] whatever the most standard syntax is, it should work by the same mechanism as #!, that is if an interpreter works in a #! line it should work in a job definition with minimal effort [22:06] right #! is "append filename to the #! line" [22:06] which should mean we can append /proc/self/fd/N [22:06] really. thought it was pipe-through [22:06] no, cause you can do [22:06] echo "#!/usr/bin/sendmail" > casey.dahlin@redhat.com [22:06] chmod +x !$ [22:06] yeah, you're right [22:06] ./casey.dahlin@redhat.com [22:06] Subject: foo [22:06] etc. [22:06] stdin and last argument make sense to me. [22:07] anything else can be done by hand [22:07] exec /proc/fd/0 [22:07] exec foo --name=/proc/fd/0 anyways [22:07] I also want to support capture-standard-output [22:07] same. [22:07] for programs that write FOO=bar as standard output [22:07] Where would you send it, though? :) [22:07] it'd be part of the job's environment [22:07] Keybuk: that's always felt a bit special to me [22:07] Hmm. [22:08] sadmac: it's used by just about everything "agent-esque" [22:08] dbus downards [22:08] Yeah. That would be much nicer. [22:08] Simply scrape the env exported by dbus when launching a dbus service [22:08] no work done. [22:08] except to export it in dbus [22:08] and make sure your job somehow fires with that env. [22:08] right, dbus-daemon writes its session address and stuff to stdout [22:08] Keybuk: I like a more general solution [22:09] so any job with "while dbus-daemon" would have that in its environment [22:09] Yeah. That's rad. [22:09] exec dbus-session-bus | xargs upstart-set [22:09] xargs? :) [22:09] I guess [22:10] then I have to care about process groups [22:10] yeah, the forking is a bit funny around that [22:12] we do need some kind of initctl to set environment though [22:12] I'm fine with parsing name=value pairs. [22:12] that's super standard. [22:13] It would be better in some way if you could have dbus communicate in another way that didn't involve any parsing [22:13] lots of people seem to try and parse things in pre-start then punt to exec [22:13] but I think that's partly because exec sucks and you can't use cat if you're using fork-following [22:14] Keybuk: look at augeas any? speaking of parsing. [22:14] sadmac: no, not yet [22:14] but I have now sent all my patches to halfline, so I suck less, so can look at that in a bit [22:14] cool [22:15] the good news is we found a major bug with pre-stop in upstart ;) [22:15] (as a result of plymouth issues) [22:15] I'm figuring this JSON stuff we've been discussing will need a parser anyway, so I'm going to complete nih-parse either way [22:15] not crasher - as in "clearly this approach is insane" [22:15] ah, cool [22:15] and pre-stop was the only thing stopping me from getting rid of all four scripts [22:15] so now I can get rid of all four scripts and be happy [22:16] Keybuk: so we have just one job now? [22:16] JSON stuff [22:16] So, JSON parsing will be in upstart. [22:16] So it's hardly surprising that name=value parsing is [22:16] wasabi: yeah, talking about using it for cross-upgrade stuff [22:16] just one process per job [22:16] so job and process become the same thing [22:16] name=value is hardly even parsing. Its regular for chrissake. [22:17] Yeah [22:17] but multiple jobs/processes defined in one conf file [22:17] given what we talked about the other day: [22:17] on foo [22:17] exec ... [22:17] it doesn't seem unreasonable to have a kinda "on self" [22:17] on self starting [22:17] exec ... [22:17] that's a task as we chatted about [22:17] so that's basically identical to the current pre-start script [22:17] Keybuk: where do names come from then? [22:17] sadmac: names? [22:18] Keybuk: yes, names for jobs [22:18] right, so then i got thinking well [22:18] Keybuk: they come from file names now [22:18] pre-start exec ... [22:18] that's a named process called "pre-start" [22:18] reload exec ... [22:18] Oh. Odd. [22:18] those would fire automatically [22:18] it's not "there" yet [22:18] (syntaxwise) [22:18] but I think it works process-wise [22:18] so with the hierarchy thing we get all of it [22:19] foo exec whatever in a file called stuff.conf creates a stuff foo job [22:19] which is a silly name, but real world examples would make sense [22:19] right exactly [22:20] we can parse it, to be sure. [22:21] * sadmac needs to finish up the parse tool [22:22] my code quality has been wildly inconsistent. I'm going to throw away what I'm writing, but then maybe I'll copy paste some of it. I can't decide if I give a shit whether it leaks memory or not. [22:22] the joys of writing a program who's first and only task is to rewrite itself :) [22:22] ll [22:22] lol [22:23] memory's cheap these days [22:23] they can buy more [22:23] the good news is it won't need many tests. It tests itself just by being compiled :) [22:23] Keybuk: that's not funny. Java people still say that with a straight face [22:24] no wonder 2/3 the core dumps I get in during $dayjob report more memory than my hard disk. [22:27] heh [22:27] trying to do this: which is failing. not sure why. [22:27] script [22:27] \t /bin/bash << EOF [22:28] bunch of crap. blah blah. [22:28] EOF [22:28] end script [22:28] Seems to break when I add my first complicated line of script: l=( backup users profiles ) [22:28] Can't imagine why any of it would need to be escaped for any reason [22:29] two shells? [22:29] you need to escape it from the first shell for the sceond to see it [22:29] script [22:29] sh is reading from a file in proc, right? [22:29] FOO=bar [22:29] /bin/bash << EOF [22:29] FOO=baz [22:29] echo $FOO [22:29] EOF [22:29] end script [22:29] will echo bar not baz [22:29] wasabi: yes [22:30] I see. [22:30] the outer shell applies full expansion to everything [22:30] even the bits between << EOF and EOF [22:30] still no worky though [22:30] /bin/bash << EOF [22:30] FOO=bar [22:30] EOF [22:30] fails. returns 2 [22:31] << isn't like, not sh compatible, is it? [22:31] it is afaik [22:31] Ahh. [22:31] Comments in the script body [22:31] even unindented ones [22:31] not sure why they're breaking it, but they are. [22:32] oh. [22:32] can't have comments in strings maybe? [22:32] they're probably being expanded when they shouldn't? [22:32] right [22:32] would have thought upstart would have removed them [22:32] guess not [22:32] why? [22:32] upstart passes everything between script and end script [22:32] including leading indents? k [22:32] actually [22:32] no ;) [22:32] heh. [22:32] see. [22:32] it kinda de-dents everything [22:32] i knew it didn't do that [22:33] so I assumed it realized that a non-indented line was an upstart command [22:33] but that's actually good for you [22:33] cause [22:33] exec sendmail [22:33] blah [22:33] blah [22:33] and upstart would fail if it wasn't # or end script [22:33] Keybuk: could be a slight problem if we allow different interpreters, including python [22:33] end exec [22:33] gets de-dented [22:33] and [22:33] exec python [22:33] blah [22:33] blah [22:33] blah [22:33] end exec [22:33] gets de-dented too [22:33] sadmac: it only removes the initial whitespace common to *all* lines [22:33] so that comes out as [22:33] I'd adopt python rules. Each line must be indeneted with the same amount and type of whitespace. :) [22:33] blah [22:33] blah [22:33] blah [22:33] And that is auto removed by one level. [22:34] wasabi: that's what it does [22:34] So why is # being passed to the script [22:34] context sensitive lexical languages make me cry [22:34] wasabi: because it doesn't remove comments [22:34] But the comment is not indented. [22:34] So it should be invalid. [22:34] And refuse to run the task [22:35] why? [22:35] OR it should remove it. :) [22:35] neither [22:35] I'd adopt python rules. Each line must be indeneted with the same amount and type of whitespace. :) [22:35] wasabi: that's what it does [22:35] the comment means your block is simply not de-dented [22:35] oh. [22:35] hah. [22:35] it doesn't throw out your entire script because you used a space instead of a tab [22:35] that's just un-necessarily pedantic [22:35] it just doesn't de-dent [22:36] it finds the common prefix from each line that consists entirely of whitespace characters [22:36] and removes that [22:36] if all lines begin \t\t then that is removed [22:36] if all lines begin " \t " then that is removed [22:36] if, as you've done there, one line isn't indented - then nothing is removed [22:36] it probably doesn't need to screw with it at all ;-) [22:36] gotcha [22:36] but it does [22:36] it makes debugging perttier [22:37] Trying to remember what i have to escape in this script to script then [22:37] is that french? [22:37] $ becomes $$... [22:37] no that's something else [22:37] $ becomes \$ in shell ;-) [22:37] $ -> $$ is make [22:37] ahh [22:37] duh [22:38] * sadmac remembers windows programming [22:38] C:\\Windows\\System.... [22:38] or \\\\Shared\\Folder [22:38] windows programming is all I do [22:38] @"C:\Windows\System" [22:39] wasabi: I'm sorry :) [22:39] Fine with me. [22:39] anyway, time to go eat.\ [22:39] I enjoy getting things done. :0 [22:39] wasabi: didn't you end up at Google? [22:39] wasabi: I don't have time to flame you. please pick this fight again later that we might finish it :) [22:40] No. Didn't take it. [22:40] ahh [22:40] They keep asking though. [22:40] they do that [22:40] Mountain View seems like such a long time ago! [22:40] yeah, it does. [22:40] I think about how much fun I had talking with people who knew what the hell I was talking about [22:41] often [22:42] heh [22:42] UDS again in not-so-long [22:42] I'm not remotely involved enough to get travel paid for, work is super busy (and has been for 2 years). [22:42] I'd love to go though. [22:43] Can't afford the out of the states trips though. [22:44] yeah [22:44] this one's in the middle of NOWHERE [22:44] I didn't make it to the Dallas one. [22:44] Because of work. [22:44] I LIVE IN DALLAS [22:45] heh, fail [22:45] Total. [22:45] I saw desrt though. Made him come out and drink. [22:45] Which he did little of. [22:45] And then left early. [22:45] Oh well. [22:46] double escaping this is becoming hard to think about [22:46] was he at Dallas? [22:46] Yeah [22:46] UDS has got so big now [22:46] Dallas can be a great city too. I wanted to come and be the local guy showing everybody where to party. [22:46] I don't think I went into the desktop room once [22:46] Because it's completely non-obvious where to go. [22:47] \${n//-/--} [22:47] Hmmm [22:47] Hah. Got it. [22:47] \${n//\\-/\\-\\-} === Keybuk_ is now known as Keybuk === solj_ is now known as solj