[02:52] <bradleyayerswork> hi
[02:53] <bradleyayerswork> I'd like to know the difference between "user jobs" and "system jobs"
[02:54] <bradleyayerswork> is it just having a .init in home directory?
[03:08] <bradleyayerswork> also, is it possible upgrade upstart on ubuntu 10.04?
[03:32] <vaxerdec> you could always pull trunk and build it.  or the release version, 1.3
[03:43] <bradleyayerswork> and is there any documentation around user jobs?
[03:47] <vaxerdec> i dont know if the cookbook contains it.  but it seems to be shaping up quite nicely
[03:48] <vaxerdec> i would not be surprised if they had documented it there
[03:49] <vaxerdec> based on the sounds of it, just allowed users to make event triggers over dbus.  i don't know how they write the files to /etc/init
[03:50] <vaxerdec> perhaps, they just write them in memory somehow into the dbus and it handles that on their behalf? this is just wild speculation.
[03:51] <vaxerdec> i know dbus has some security models which allow it to broker access to privileged stuff.  no idea how they are using it... i am strong advocate of ripping out anything with the word "dbus" in it and throwing it in the garbage :)
[03:55] <vaxerdec> i'm trying to figure out a way to get all /etc/init/*.conf from whatever serves as ubuntu trunk.  if you have a suggestion, please let me know...
[04:03] <bradleyayerswork> i want to use upstart to manage web app processes, and user jobs "sound" like what i want, but it isn't documented :(
[04:04] <bradleyayerswork> the only mention is "As such, all system job configuration files must live in or below /etc/init (although user jobs can live in other locations)." 
[04:05] <bradleyayerswork> vaxerdec: as in, you just want to download the job files?
[04:06] <bradleyayerswork> ah the man page has some stuff 
[04:07] <bradleyayerswork> " Any user can create user jobs, but that user can control only jobs they create."
[04:08] <bradleyayerswork> but what if i made something that just hooked the 'starting' event and blocked, causing it to never start
[04:08] <vaxerdec> yes.  
[04:08] <bradleyayerswork> that is concerning
[04:09] <bradleyayerswork> i suppose that's just a messy problem to get around
[04:10] <vaxerdec> i am using fedora and their upstarts are just a half-aborted attempt before they switched to systemd (yuck), they never ported to native upstart.  ubuntu apparently claims they have ported the majority of their init scripts to native upstart.  so, i want to use those as a conversion base for my own efforts (I am using upstat with Fedora, because I hate systemd)
[04:11] <vaxerdec> yeah, well, even though they can schedule, i don't think they wil be escalating their privilges
[04:12] <vaxerdec> it probably lets you specify a filename or directory then somehow.  and/or forces you to use your home dir
[04:15] <bradleyayerswork> i just meant having "start on starting shutdown; script while 1 end script" etc
[04:17] <vaxerdec> right but where do you put those? in a file. where do you put that?
[04:18] <bradleyayerswork> in ~/.init/
[04:18] <bradleyayerswork> http://manpages.ubuntu.com/manpages/oneiric/man5/init.5.html
[04:18] <vaxerdec> clearly they don't set the sticky bit on /etc/init and call it a day :) although they may as well since it sounds from the "any user can..." that it's already DoS prone... but perhaps they rate limit.
[04:18] <bradleyayerswork> search "User jobs"
[04:18] <bradleyayerswork> there's a section
[04:18] <vaxerdec> ah.  yes, the home dir then.  but, it might just take an arbitrary path.
[04:19] <vaxerdec> i don't have the manual page.  i don't access to any ubuntu systems.
[04:19] <vaxerdec> i will be sure to grab that though when i get those others from the scm repo
[04:19] <vaxerdec> along with that other one that lists those pseudo-events
[04:19] <vaxerdec> what is it? i forget.  something.7
[04:20] <vaxerdec> something-else.7
[04:20] <vaxerdec> it's just a table with all those virtual events like network-started
[04:21] <vaxerdec> oh, you gave me a URL :)
[04:22] <vaxerdec> ah yes, upstart-events.7
[04:25] <vaxerdec> wait... there is no longer a "console syslog" ? only "owner" and "output?"
[04:25] <bradleyayerswork> i don't know much about console
[04:26] <vaxerdec> ahhh they have a udev bridge now
[04:27] <bradleyayerswork> you seem to know more about this than me :P
[04:28] <vaxerdec> i'm not sure i like it though... threatens to mix purposes.  i am wary that it will come out looking like systemd, please no :)
[04:29] <vaxerdec> it's always tempting to roll other stuff in to your project.  just look what happened to that poor lennart fellow... he sold himself to the devil, clearly.
[04:29] <vaxerdec> at least it's "only" a bridge.  but that encourages more use of dbus which i think is just all bad in this layer.
[04:30] <bradleyayerswork> i'm not even familiar with d-bus, so i can't really comment :/
[04:31] <vaxerdec> it's just an ipc bus designed for the desktop/gui/crap layer that some people (like redhat and systemd fools) will try to move lower in the stack and have everyone relying on their superfluous crap.
[04:32] <vaxerdec> i mean, not as a business tactic... just some arrogant developers who think they understand the One True Way but clearly haven't been using unix very long or, if so, learned about its philosophy...
[04:36] <vaxerdec> wait... does udev repeat the events over dbus? or are they getting them over netlink or something?
[04:39] <vaxerdec> wow, just reading over some of these changes since 0.6... this has come a long way.  these guys are doing wonderful job with this.
[04:40] <vaxerdec> documentation is getting fleshed out nicely too.
[04:41] <bradleyayerswork> upstart >0.6 changes you mean?
[04:41] <vaxerdec> eh? yeah.  i mean since version 0.6.  they are at 1.3 now for the release track.
[04:41] <bradleyayerswork> yeah
[04:42] <bradleyayerswork> ubuntu 10.04 has 0.6 :(
[04:42] <vaxerdec> go to 10.10
[04:42] <vaxerdec> not sure what version they have, probably 1.2
[04:42] <vaxerdec> even my fedora system has 1.2 :)
[04:42] <vaxerdec> and they abandoned upstart.
[04:42] <vaxerdec> the fools.
[04:42] <vaxerdec> well, i take that back.  it's still in RHEL
[04:42] <bradleyayerswork> really? in favour of what?
[04:42] <vaxerdec> systemd!
[04:43] <bradleyayerswork> :O
[04:43] <vaxerdec> the thing i have been talking about
[04:43] <bradleyayerswork> yup
[04:43] <bradleyayerswork> i made a bunch of changes to the upstart cookbook that i need to submit
[04:43] <vaxerdec> it's WAY overscoped
[04:43] <vaxerdec> what's the source language?
[04:44] <bradleyayerswork> restructuredtext
[04:44] <vaxerdec> oh sweet
[04:44] <vaxerdec> i love it
[04:44] <vaxerdec> i use it for everything
[04:45] <vaxerdec> i just start started making trees and building it all with sphinx
[04:45] <vaxerdec> for all my docs at work
[04:45] <bradleyayerswork> ah yeah
[04:45] <bradleyayerswork> i use it for my projects too
[04:45] <bradleyayerswork> i wish it was more like markdown
[04:45] <vaxerdec> it's so nice and terminal friendly :)
[04:45] <vaxerdec> eh
[04:45] <vaxerdec> serious?
[04:45] <bradleyayerswork> in some ways, sure
[04:46] <bradleyayerswork> like single ` rather than double
[04:46] <vaxerdec> like what? what's the top hting you miss from markdown
[04:46] <vaxerdec> yeah that gets tiresome
[04:46] <vaxerdec> i just use editor macros
[04:46] <bradleyayerswork> and remembering how to make URLs
[04:46] <vaxerdec> oh right
[04:46] <vaxerdec> everyone has issues with that
[04:46] <vaxerdec> i usually just have the quickref up
[04:46] <bradleyayerswork> i basically have to look at reference every time
[04:46] <vaxerdec> :)
[04:47] <bradleyayerswork> i also don't like having to have a new line before a list
[04:47] <vaxerdec> gets even harder with sphinx you have to do stuff for cross references and likewise... they have like a hundred of their own '.. ' directives
[04:48] <bradleyayerswork> :ref: is good though
[04:48] <vaxerdec> oh yes, that is my biggest complaint with it
[04:48] <vaxerdec> any change in indentation and you need to put a space
[04:48] <bradleyayerswork> yeah :/
[04:48] <vaxerdec> and you know what... it handles it with #. just fine
[04:48] <bradleyayerswork> the whole infrastructure/design of it is good
[04:49] <bradleyayerswork> but the syntax is annoying 
[04:49] <bradleyayerswork> which is a shame
[04:49] <vaxerdec> yeah that part is dumb.  i read a discussion on it and they said like they'd have to rewrite the entire parser or something to make that work
[04:49] <vaxerdec> what part of the syntax is annoying?
[04:49] <bradleyayerswork> just the things we've been talking about
[04:49] <vaxerdec> mmm
[04:50] <bradleyayerswork> hyperlinks, ``awef``, lists
[04:50] <vaxerdec> tables can be irritating
[04:50] <bradleyayerswork> yeah
[04:50] <vaxerdec> if they're not just simple.  everything has to line up
[04:50] <bradleyayerswork> yep
[04:50] <vaxerdec> i'm using some package from drchip to do it automatically though, or just started to anyways.  looks promising.
[04:50] <vaxerdec> yeah they are at 0.81 now i think
[04:51] <bradleyayerswork> i just find stack overflow's language memorable
[04:51] <vaxerdec> i keep reading the release notes to see if they fixed those
[04:51] <vaxerdec> nobody seems to care about those issues and i am definitely no python guru
[04:52] <bradleyayerswork> i am quite the python guru
[04:52] <vaxerdec> oh really
[04:52] <vaxerdec> fix it!
[04:52] <vaxerdec> i took a look once...
[04:52] <vaxerdec> it's all mixed up with block quoting (the list issue)
[04:52] <vaxerdec> but you know... 
[04:52] <bradleyayerswork> it seems like it'd be difficult to get accepted for political/backwards compatible reasons
[04:52] <vaxerdec> if your output is html you can just give a list style
[04:53] <vaxerdec> nah you just make it a command line switch.  they have so many already.
[04:53] <bradleyayerswork> true
[04:53] <vaxerdec> but then the code would have to work both ways, which is even more challenging :)
[04:53] <bradleyayerswork> yeah :(
[04:54] <vaxerdec> i mean it's just such an obvious thing though.  i am always dismayed that their core team doesn't mind that.
[04:54] <vaxerdec> i think they just set style on their output.  i think the default style is totally ugly actually
[04:54] <vaxerdec> for both latex and html
[04:55] <vaxerdec> it actually makes pretty good man pages though
[04:55] <bradleyayerswork> yeah
[04:55] <bradleyayerswork> oh yeah? i haven't seen man page output
[04:56] <vaxerdec> oh it's nice.  at least it looks nice in my colorized pinfo terminal :)
[04:56] <vaxerdec> rst2man
[04:57] <vaxerdec> actually the simple tables aren't so bad
[04:57] <vaxerdec> just look at your man page for the upstart stuff... it's probably made by that if you say the web page is
[05:00] <vaxerdec> i wonder if they figured out what to do with init.conf yet
[05:01] <vaxerdec> do you know where the name 'upstart' came from?
[05:03] <bradleyayerswork> nope
[05:03] <vaxerdec> oh boy looks like i gotta figure out bzr to do this
[05:06] <bradleyayerswork> good luck :)
[05:06] <bradleyayerswork> i'm off
[05:07] <vaxerdec> later
[08:21] <TJ__> im a bit lost in all upstart versions at the moment; i have a job that is depending on some IFACE br0 to come alive. According to docs, upstart needs the upstart-udev-bridge to make this work. On the development ubuntu 11.04 system i have this bridge binary. On the system im building we use debian packages instead of ubuntu packages, and this debian package does not have the bridge, so the job isnt started....
[08:21] <TJ__> does anyone have any idea how to fix this ?
[08:22] <TJ__> btw the start condition for the job is : start on net-device-up IFACE=br0
[08:25] <jhunt> bridge interfaces are handled by ifup on Ubuntu. See file /etc/network/if-up.d/upstart which runs, "initctl emit -n net-device-up IFACE=br0..."
[08:25] <jhunt> the upstart-events man page explains this, although I appreciate it is pretty terse :)
[08:27] <TJ__> ah.
[08:27] <TJ__> i see
[08:28] <TJ__> on the embedded system we have, we do have the /etc/network/if-up.d directory, but in there, there is no upstart file...
[08:28] <TJ__> so if i create this file we should be done
[08:37] <TJ__> working ! thanks jhunt 
[08:45] <jhunt> TJ__: great! :)
[08:47] <TJ__> how does it work on a debian system then ? the package we install does not have a upstart-udev-bridge binary so its not used there as well ?
[08:50] <jhunt> TJ__: the version of upstart in debian is very old. This needs to be rectified.
[08:51] <TJ__> aah... ok....   but then still... in my ubuntu development pc, we have the latest and greatest upstart provided by ubuntu, it has the upstart-udev-bridge, but still the if-up.d scripts are used... any specific reason why ?
[08:53] <TJ__> or is this just something on ubuntu's todo list ? 
[10:11] <bradleyayers> so I've written a user job, and I assume i wouldn't need to use sudo with initctl (if i do, it  says unknown job)
[10:12] <bradleyayers> $ start my-test-job 
[10:12] <bradleyayers> start: Rejected send message, 1 matched rules; type="method_call", sender=":1.27" (uid=1000 pid=1480 comm="start my-test-job ") interface="com.ubuntu.Upstart0_6.Job" member="Start" error name="(unset)" requested_reply="0" destination="com.ubuntu.Upstart" (uid=0 pid=1 comm="/sbin/init")
[10:12] <bradleyayers> this is on ubuntu 11.10
[10:13] <jhunt> jobs are run as root, so you need to be root to start them :)
[10:14] <bradleyayers> doesn't that contradict the point of user jobs?
[10:14] <bradleyayers> the man-page suggests users can control only their jobs
[10:15] <bradleyayers> or am I just missing something :S
[10:18] <jhunt> sorry - didn't notice that you were using user jobs. User jobs are not enabled by default in ubuntu, even 11.10. Looks like the man page is reflecting the upstream version of upstart. We need to fix that.
[10:19] <bradleyayers> i've been making some edits to the cookbook, by editting the restructuredtext source
[10:20] <bradleyayers> what's the best way for me to get the changes to you?
[10:20] <bradleyayers> just a bug ticket?
[10:21] <jhunt> If you want to enable user jobs, you'll need to modify /etc/dbus-1/system.d/Upstart.conf so it looks like the upstream version: http://bazaar.launchpad.net/~upstart-devel/upstart/trunk/view/head:/dbus/Upstart.conf
[10:21] <jhunt> bradleyayers: please raise bugs as specified in the cookbook itself (https://bugs.launchpad.net/upstart-cookbook/+filebug)
[10:22] <bradleyayers> and i'll just attach a patch?
[10:22] <jhunt> that would be fine
[10:22] <bradleyayers> great
[10:23] <bradleyayers> thanks for the upstart.conf tip :)
[10:24] <jhunt> np - thanks for pointing out the man page issue :)
[10:25] <bradleyayers> and user jobs aren't really mentioned at all in cookbook either :(
[10:26] <bradleyayers> what stops someone from writing a job that just hooks into some "starting" event, and then does a sleep 10000 etc.?
[10:26] <bradleyayers> (task job)
[10:29] <vaxerdec> bradleyayers: to what end? you mean to disrupt the operation of the system?
[10:29] <bradleyayers> yes, to just denial of service
[10:30] <bradleyayers> (inadvertantly or maliciously)
[10:30] <vaxerdec> perhaps they haven't worked out those details yet, which is why it's not in the released version
[10:31] <vaxerdec> there must be permissions checking...
[10:31] <vaxerdec> might want to check out the code to find out
[10:32] <vaxerdec> is there really a need for user events?
[10:33] <bradleyayers> this isn't user events though
[10:33] <bradleyayers> it's user jobs hooking global events
[10:33] <vaxerdec> eh? what did you mean then?
[10:33] <vaxerdec> right...
[10:33] <vaxerdec> i guess that's what i meant
[10:33] <vaxerdec> i meant, users interacting with the events in some way
[10:34] <bradleyayers> well my use-case is having a script that i want to run when a database is running
[10:34] <bradleyayers> and when the database is shutting down, my script should shut down
[10:34] <vaxerdec> but you can't connect to the database?
[10:35] <vaxerdec> you could run inotifywatch on the pidfile
[10:35] <bradleyayers> ill have a look at inotifywatch
[10:36] <vaxerdec> actually i'm not sure you can anonymously monitor that
[10:36] <vaxerdec> .
[10:36] <vaxerdec> i mean you could poll with stat() of course in the rundir but that's silly
[10:36] <bradleyayers> yeah
[10:37] <bradleyayers> there'll always be some manual scripting approach to check conditions etc
[10:37] <vaxerdec> is there some reason you can't just maintain a connection to the database?
[10:37] <vaxerdec> it'll probably dump you with a particular exit code even
[10:38] <bradleyayers> but i liked the way upstart handles this type of problem with events
[10:41] <vaxerdec> seems like the wrong mechanism to me
[10:42] <vaxerdec> maybe you could subscribe to the event and it could broadcast them
[10:42] <vaxerdec> i really have no idea what restrictions the dbus interface imposes
[10:43] <vaxerdec> of course i'd just advocate a unix domain socket access by a client library in client's address space.  or possibly, arrange to be signalled.
[10:45] <vaxerdec> this stuff is too fancy though.  should rely on helpers for all this... not build into init.
[10:45] <vaxerdec> i mean, it's arguable
[10:46] <vaxerdec> but pretty soon you guys are going to be putting tcp into the thing and doing notifications over the network
[10:47] <vaxerdec> which actually sounds somewhat interesting if it weren't so dirty to be doing that in PID1.
[10:49] <vaxerdec> i think perhaps it would be best to stick to current model where init has a specific role: to start, stop and reap processes only.  it's already spawning processes... why not have user-notify.conf which defines some other programs to do this stuff
[10:52] <bradleyayers> hmm, you raise some interesting points
[10:53] <bradleyayers> i think i do agree that user jobs are outside the responsibility of init
[10:53] <vaxerdec> kitchen sink approach is tempting, but time has taught us that the unix way of trying to do only one thing is a superior model
[10:54] <vaxerdec> this is exactly the problem with systemd although they are much worse and make no attempt to even limit the wreckage
[10:55] <vaxerdec> shit why not stuff it all in the kernel and call it a day ;)
[10:56] <vaxerdec> that will be next... modprobe systemd.ko
[10:57] <vaxerdec> or maybe they will call it lennart.ko
[10:57] <vaxerdec> now one thing i think is an excellent idea is the use of cgroups
[10:59] <bradleyayers> i hear if you put it in the kernel it's fast
[11:00] <vaxerdec> i would say the cgroups should go in a cgroupd but then you're just calling cgroupd and moving all the spawn logic from init to cgropud, which probably serves no purpose
[11:01] <vaxerdec> unless you could somehow hand off...
[11:04] <vaxerdec> cgroups are extremely powerful isolation and control mechanisms.
[11:04] <vaxerdec> come to think of it, you could do that in pam
[11:07] <vaxerdec> already pam does much/all of resource allocations and limit imposition
[11:26] <vaxerdec> hm.  can upstart just start arbitrary services and have all requirements for that service come up, automatically and recursively? 
[11:45] <vaxerdec> (no matter what state those other services were in)
[11:45] <bradleyayers> well the dependencies might not all be for some things to be started
[11:46] <vaxerdec> i'm not sure that it can... perhaps this is one argument for real dependencies.  once you had those the rest could be derived.
[11:46] <bradleyayers> if there's other jobs that have hooked the 'starting' event of the thing you're starting, then they'll be started
[11:48] <vaxerdec> i have to read more about changes they have made.  i think with earlier codebases perhaps this would have been difficult to know deterministically.
[11:50] <vaxerdec> something else... the "it forked twice" or "it forked three times and i lost track" problem: couldn't that be solved by using netlink? i.e. via "proc connector" ?
[11:52] <vaxerdec> oh hah.  i'm reading a post about it by one Scott James Remnant :) guess they are one step ahead! 
[11:53] <vaxerdec> bradleyayers: is it mysql or postgres?
[11:53] <bradleyayers> postgres
[11:53] <vaxerdec> (assuming it is relational)
[11:53] <bradleyayers> but… my usecase was a lie
[11:53] <bradleyayers> (sort of)
[11:53] <vaxerdec> bradleyayers: you could use notify(7)
[11:54] <bradleyayers> i have a background worker for a web site that depends on postgresql and rabbitmq
[11:54] <vaxerdec> i have just looked at zeromq, it looks quite lean.
[11:56] <vaxerdec> now that's an ipc i wouldn't mind using.  but not in init :)
=== JanC_ is now known as JanC