#upstart 2007-06-11
<asmlinkage> do the "start on" and "stop on" commands work in upstart 0.2.7-7 (Edgy's default version)
<asmlinkage> I've written one main script that works fine, but a second script that uses start on and stop on to be started and stopped after the main script but upstart never starts or stops it when I start/stop the main daemon
<AlexExtreme> hmm, I saw some commits that looked like the new config code should work now. am I right?
<Keybuk> yup
<Keybuk> you should be able to write a parse_profile.c in the manner of parse_job.c
<Keybuk> and add bits to the enums/switches in conf.h/conf.c
<AlexExtreme> hmm
<AlexExtreme> i tested it when I saw those commits this morning and it didn't work, some assert failed messages that were going past so fast that I couldn't read them
<AlexExtreme> a clean checkout from main, that is
<Keybuk> which revno?
<AlexExtreme> 720
<Keybuk> hmm
<Keybuk> "make check" failed?
* AlexExtreme runs it
<AlexExtreme> hmm
<AlexExtreme> works fine
<AlexExtreme> let me try again
<Keybuk> could be insufficient testing ;)
<AlexExtreme> yikes, i cd'd up one dir too far before doing rm -rf upstart ><
<AlexExtreme> oh well
<Keybuk> oh yeah
<Keybuk> it does kinda break, doesn't it
<AlexExtreme> yep ;)
<JK455> hi
<JK455> i have a dumb newbie question about upstart 
<Keybuk> hi
<Keybuk> sure
<JK455> thx 
<JK455> how do i use it for an ordered shutdown 
<Keybuk> so an ordered shutdown is an interesting thing
<Keybuk> in fact, shutdown in general is interesting
<Keybuk> at the minimum, you're going to have an emitted event that indicates you want to shutdown
<Keybuk> the compat/sysv uses "runlevel 0" and "runlevel 6" for this
<Keybuk> you might use those, or call it "shutdown"
<JK455> ok, 
<Keybuk> you'd then have some jobs that have "start on shutdown"
<JK455> can it be dbus event ?
<Keybuk> dbus => not right now, a dbus proxy is planned
<Keybuk> (but not yet implemented)
<Keybuk> one of the shutdown jobs can order a sequence of other jobs
<Keybuk> e.g. you might just have a shutdown job that does the sequence
<JK455> am not sure to understand :
<JK455> you mean, having an event on all setted process for shutdown
<Keybuk> no, just an emitted event
<Keybuk> I'm not sure what you mean by setted process ?
<JK455> for exemple, in my script i put that it have to stop on that event
<Keybuk> right
<JK455> like : stop on "shutd_event"
<JK455> ok
<Keybuk> yeah, that can stop running services
* AlexExtreme has a "shutdown" job that starts on the runlevel 0 or runlevel 6 event, and then all the other jobs that i want to stop on shutdown have "stop on starting shutdown"
<JK455> and i will respect all previously marked dependencies ?
<Keybuk> AlexExtreme: that's actually an extremely good way to do it
<Keybuk> since the shutdown script won't actually run until the jobs have stopped
<JK455> i think not, right ?
<Keybuk> JK455: upstart has no concept of dependencies
<AlexExtreme> yeah, since the actual shutdown job's script will block until the jobs are stopped
<Keybuk> AlexExtreme: *ahem* http://codebrowse.launchpad.net/~keybuk/upstart/main/revision/scott%40netsplit.com-20070611152233-klj9h8f5icjhjurh?start_revid=scott%40netsplit.com-20070611152233-klj9h8f5icjhjurh
<AlexExtreme> hmm, is there an echo here? :p
<JK455> ok, i have to wrote all events for repect of my own dependencies
<AlexExtreme> ah, cool. that fixes it?
<Keybuk> AlexExtreme: yeah, stupid mistake
<AlexExtreme> k, i'll try it
<JK455> and i were to wrote the piece of code that receives dbus message and use them as event, were would i had to start ?
<JK455> "if i were"
<Keybuk> JK455: how do you mean?
<JK455> i would like to receive events by sending dbus messages to upstart
<JK455> if i want to do that, do you have any tips for me ?
<JK455> well, in fact, maybe i dont need that
<AlexExtreme> brb, testing that fix
<Keybuk> JK455: you'd need something linked with libdbus to receive the messages/events
<Keybuk> and linked to libupstart to pass them on to upstart
<Keybuk> (you can do the reverse too, the same way)
<Keybuk> libupstart is in the upstart source code in the upstart directory
<JK455> ok
<Keybuk> util/initctl,c links to it to do everything
<Keybuk> fundamentally, you'd match certain dbus messages and use UPSTART_EVENT_EMIT to send them on to upstart
<Keybuk> and listen for UPSTART_EVENT messages from upstart, and send them across dbus
<JK455> ok, great
<JK455> maybe i will wrote it i we decide using it
<JK455> thanks a lot for this informations
<AlexExtreme> Keybuk: works fine now
<AlexExtreme> (mental note: it helps to bzr pull *before* trying)
<Keybuk> heh
<Keybuk> woo
<Keybuk> Keybuk 1 - Config code 0
<ion_> \/
<Keybuk> I now just have to write the tests for init.conf
<AlexExtreme> so init.conf is now possible to implement?
<AlexExtreme> uhh
<AlexExtreme> so it's now possible to have an init.conf, is what i meant
<Keybuk> AlexExtreme: in theory, yup
<AlexExtreme> nice
<AlexExtreme> hmm
<AlexExtreme> some debian guy has sent something to upstart-devel about this meta initscript stuff
<Keybuk> AlexExtreme: yeah was just talking to him on #debian-devel
<Keybuk> well
<Keybuk> ubuntu-devel
<Keybuk> and not just
<Keybuk> before doctor who, the f word, etc.
<Keybuk> AlexExtreme: so the plan there is to have
<Keybuk> /etc/init/init.conf (optional configuration file, overrides:
<Keybuk> /etc/init/conf.d (directory of configuration files, overrides:
<Keybuk> /etc/init/jobs.d (directory of job definitions)
<Keybuk> config files can define jobs
<Keybuk> e.g.
<Keybuk> /etc/init/conf.d/some-random-conf could contain
<Keybuk>   job foo
<Keybuk>     exec /sbin/daemon -d
<Keybuk>     respawn
<Keybuk>   end job
<Keybuk> which is equivalent (but higher priority than) the same text in /etc/init/jobs.d/foo
<Keybuk> conf.d becomes useful when we can define profiles, states, etc.
<Keybuk> in general, I expect distros to not use init.conf at all (useful for single-parse embedded systems)
<Keybuk> to use conf.d rarely for complicated inter-twining defaults, and setting other configuration things that we define
<Keybuk> and largely use jobs.d
<Keybuk> (conf.d may make some more sense than states.d though, since you could just have an /etc/init/conf.d/udev that defined states for add->remove of all devices udev emits events for)
#upstart 2007-06-12
<ion_> Sounds good.
<madduck> Keybuk: is it just me or why did the installation of upstart just pull in a finger client?
<madduck> are you using finger?
<madduck> i am currently challenged by the task of authenticating users via unix sockets
<madduck> http://lists.alioth.debian.org/pipermail/netconf-devel/2007-June/000128.html
<madduck> and since upstart also uses unix sockets (i think), this attracted my attention.
<madduck> anyway, if you or anyone has some input to the issue in the mailing list post, i would love to hear it.
<madduck> but for now: sorry for spamming the channel
<shawarma> madduck: I was recently made aware of SO_PEERCRED.
<shawarma> madduck: Doesn't that solve your problem?
<shawarma> -> /msg
<madduck> someone else just said this
<madduck> i am reading up on this now. -> /msg
<Keybuk> madduck: I've no idea why it would pull in a finger client
<madduck> shawarma: or #netconf/irc.debian.org
<Keybuk> it shouldn't do, there's not one in the dependencies
<madduck> Keybuk: i can't figure it out either. maybe it's the scottish beer in my head?
<Keybuk> maybe
<Keybuk> upstart uses SO_PEERCRED for authentication of commands
<Keybuk> (one of the reasons it uses unix domain sockets and not a fifo
<Keybuk>  the other being the ability to pass file descriptors from initctl)
<madduck> i am prototyping in python, so i hope it can do it.
<madduck> i'll read up now.
* Keybuk is catching up on some LCA talks :p
<Keybuk> wasabi: in particular "Eat My Data: How everybody gets file I/O wrong" :p
* Keybuk giggles at "gdb test_core"
<Keybuk> freudian typo, that
<Keybuk> http://codebrowse.launchpad.net/~keybuk/upstart/main/revision/scott%40netsplit.com-20070612135558-5cp54lvyxc5pwax5?start_revid=scott%40netsplit.com-20070612135714-innzwjnyivysns66
<ion_> Whee
<AlexExtreme> \o/
<AlexExtreme> "Retain loading from /etc/event.d" << does that mean that it'll use jobs in both event.d and the new jobs.d?
<Keybuk> yes
<AlexExtreme> cool, that'll make upgrading easier ;)
<Keybuk> they'll fight over job names right now
<AlexExtreme> that's no problem for me, really
<AlexExtreme> anyway, /me gets on with porting profiles to the new code
<AlexExtreme> <ot>hmm, i like your new blog theme</ot>
<Keybuk> the port should be quite easy, since now most of the hard work is taken care of for you by conf.c
<AlexExtreme> yep
<AlexExtreme> brb, testing latest bzr code
<Keybuk> 732 is current
<AlexExtreme> yep, got that
<AlexExtreme> seems to work. although, moving all the jobs to jobs.d from event.d before booting the new /sbin/init wasn't one of my greatest ideas :p
<AlexExtreme> had to sync and reboot -f
<Keybuk> lol
<AlexExtreme> Keybuk: should CONF_PROFILE also go into the ConfItemType enum in conf.h?
<Keybuk> yup
<Keybuk> actually, you'll want that to be CONF_PROFILE_DIR, no?
<Keybuk> and then add a case for it and parse directories of profiles?
<Keybuk> oh
<Keybuk> right, CONF_PROFILE_DIR in ConfSourceType
<Keybuk> and CONF_PROFILE in ConfItemTypoe
<Keybuk> :p
<AlexExtreme> ok
<AlexExtreme> :)
<AlexExtreme> hmm
<AlexExtreme> Keybuk: is it right that there's a Job entry specifically defined in the ConfItem struct?
<Keybuk> it's in a union
<Keybuk> so there should be a Profile *profile there as well
<AlexExtreme> ahh
<Keybuk> so in the appropriate case bits you refer item->profile
<AlexExtreme> right, forget i said anything :p
#upstart 2007-06-13
<AlexExtreme> trying to code shortly after you wake up never works too well
<Keybuk> morning
<Keybuk> yeah I find that
<AlexExtreme> i'm trying to work on this profiles code and my brain just says "uhh?" :p
<Keybuk> have a bananananana :p
<AlexExtreme> :D
<AlexExtreme> oh well, bbl
* Keybuk tackles the problem of namespace collision
<Keybuk> too many structs :-/
<Keybuk> conf_sources -(hash)-> ConfSource -(hash)-> ConfFile -(list)-> ConfItem -> job/state/etc.
<Keybuk> to track names, I'd need
<Keybuk> namespace -(hash)-> Name -(list-> job/state/etc.
<Keybuk> http://people.ubuntu.com/~scott/conf.jpg
<Keybuk> :-(
* Keybuk wonders whether objects of different types should share namespaces
<Keybuk> e.g. should states and jobs share a namespace?
<wasabi> states and jobs?
<wasabi> states are jobs, no?
<Keybuk> no
<wasabi> you mean something other than what I was thinking you did, then
<Keybuk> an example of a state is the period between tty-added and tty-removed for the same $TTY
<Keybuk> this state can have multiple concurrent instances, since you can have multiple $TTYs
<wasabi> Hmm. This is all getting very confusing. I like dit when you needed one file per tty. :0
<wasabi> It made the idea of a state easy: while job-name
<Keybuk> heh
<Keybuk> I like the idea of one file for all ttys
<Keybuk> since they're identical
<wasabi> Just being identically doesn't make it automatically a case to combine.
<wasabi> identical
<wasabi> What was wrong with our initial idea of jobs themselves defining named states?
<Keybuk> doesn't work for the tty case
<wasabi> Actually, I guess I don't really even know what I'm talking about anymore. Ya'll have probably done a lot of work since I was last in on it.
<Keybuk> or the network interface case
<Keybuk> it works on paper, but not for the use cases it's actually needed for
<wasabi> Explain the tty case?
<Keybuk> network interface is less controversial, so let's use that as an example
<wasabi> Okay, that. ;0
<Keybuk> we have a pair of events with a common variable
<Keybuk> interface-up eth0
<Keybuk> interface-down eth0
<Keybuk> so we can define the pairing and name that, say, interface-is-up
<Keybuk>   interface-up ... interface-down $IFACE
<Keybuk> so when any interface comes up, the state is true
<Keybuk> and when that same interfaces goes down, the state becomes false
<Keybuk> ok?
<wasabi> ok.
<Keybuk> computers have multiple interfaces
<Keybuk> we don't just want to track the first one that we see, we want to track them all
<Keybuk> so when we see "interface-up lo", the state is true "for lo"
<Keybuk> we might next see "interface-up eth0", now the state is true "for lo" and "for eth0"
<Keybuk> next we might see "interface-down eth0"
<Keybuk> this only matches the second half of the "for eth0" true state, so that state becomes false
<Keybuk> now the state is only true "for lo"
<Keybuk> by thinking in this way, we can answer the questions
<Keybuk> is the state true for any interface (any network interface is up!)
<wasabi> I'd start with a network job, which only started when Any interfaces were up, and stopped itself when the last interface went down. You can then depend on the start/stopped of that job to define a state where any interaface is up.
<Keybuk> is the state true for a specific interface (or any non-lo interface)
<Keybuk> wasabi: but that involves defining a job that tracks the up/down events it receives, no?
<wasabi> Yes, it does.
<Keybuk> how would you define a job that was running while any interface, apart from lo, was up?
<wasabi> It would start on any interface up, and stop on any interface down. And the pre-stop handler would check if ALL interfaces were down, if not, it wouldn't really stop.
<wasabi> In code.
<Keybuk> the nice things about having first-class states is that you don't need to do that
<Keybuk> upstart can track that for you
<Keybuk> in fact, we then get to do things like
<Keybuk> "is the set of paths that are mounted a subset of the following list?"
<Keybuk> so upstart itself can track the problem of the writable filesystem
<wasabi> interesting.
<wasabi> Not sure if that's completely beneficial to implement that way or not. The script thing, as far as I can tell, works.
<Keybuk> jobs implicitly have a state coupled to them
<Keybuk> so by defining a job, you are also defining the state which defines when they are running
<Keybuk> but I figured that since the machine is sufficiently useful, one should be able to define states in their own right, for use in the definitions of other jobs
<Keybuk> the /etc/init/conf.d/udev example holds here; where udev ships a rule that calls initctl for appropriate events, and ships upstart states for each of the event pairs
<Keybuk> so a job doesn't have to worry about module-loaded ... module-removed
<Keybuk> you could do this simply by defining jobs for them all
<Keybuk> but they would have to be all instance jobs
<wasabi> All the modules? Not worth it. They are very situation specific.
<Keybuk> (an alternative viewpoint is to make all jobs instance jobs by default :p)
<wasabi> Why is from module-loaded foo to module-removed foo so bad?
<wasabi> Ya know, another thing I'm concerned about in all of this is starting a job midstream.  What if you install the job file while the foo module is loaded, does it sit there waiting for foo to show up?
<wasabi> Or are you going to always model all system state in upstart at all times?
<wasabi> I don't think so. I think you'd install the job, and ask it to start, right now. And it would check if the module was loaded, in pre-start.
<wasabi> And this is all weird anyways because it's inherently race. You can never guarentee that the module didn't remove itself after the job was started.
<wasabi> s/race/racey/
<wasabi> So every job still has to verify that the system is proper, it has to check if the module is loaded.
<wasabi> So inevitably each script will have sanity checks in pre-start. Regardless how much help upstart gives it.
<wasabi> All of this together makes me wonder if it's not getting just too complicated.
<wasabi> Maybe I'm just being negative today.
<wasabi> You could do network interfaces like that today.
<wasabi> interface-up job which fires when udev tells it an interface is up. It can itself main some state files in /var/run or something.
<Keybuk> believe it or not, this way is simpler to implement than having raw jobs as states
<wasabi> And it can keep track itself what interfaces are or are not up... and emit events for specific interfaces.
<Keybuk> I think that services will almost always describe the states in which they should be running, rather than being directly event based
<wasabi> hmm
<Keybuk> ie. "while there is a network interface up, and the filesystem is writable, and dbus is running"
<Keybuk> if true, the state graph can be evaluated when the job is created, so yes, it would start automatically
<Keybuk> it is inherently racey, so the service should fail normally if the resources it expects are not available
<wasabi> It can only be evaluated if the state which is defined by events is installed before those events happen.
<Keybuk> (this is not unreasonable)
<wasabi> No?
<Keybuk> right, that is true in the current upstart model
<Keybuk> upstart would need to record all events to avoid that
<wasabi> Yeah, and that's probably unreasonable.
<wasabi> So, somebody is still going to have to, after installing a new job with a new state, give it a push.
<wasabi> Write some code which checks if the state is true by evaluating the system.
<Keybuk> I think it will be rare that this is true, no?
<wasabi> I'm not sure.
<Keybuk> jobs that should be started in postinst will rarely need to define a state based on events
<Keybuk> but yes, that is a concern
<Keybuk> there's more interesting examples
<wasabi> But if those states were maintained by stateless jobs, it's not a concern.
<Keybuk> ?
<wasabi> So you have a network job, which fires anytime a network interface, any interface, comes up or down. It keeps a count in /var someplace about the total number of active interfaces, by actually checking the interfaces, not reading the events.
<Keybuk> ok
<mbiebl> Keybuk: hi
<wasabi> And a job which cares about the network would need to start on any network event also, and check that file. Or something.
<wasabi> I don't know.
<wasabi> Which is still racey.
<Keybuk> the same network-monitoring job could register the states in upstart's memory directly
<wasabi> It would have to check itself.
<Keybuk> avoiding the use of filesystems
<wasabi> But then we're just talking about reusable scripts.
<Keybuk> fiddly scripts :)
<wasabi> Explain how states in upstart are maintained?
<wasabi> It makes me wonder if what is being built doesn't actually solve any issue, is all.
<wasabi> Since hte issue is still there.
<Keybuk> what issue do you think we're attempting to solve?
<wasabi> Every job that cares about network has to actually check the network and exit gracefully in pre-start.
<Keybuk> why pre-start?
<wasabi> Or start.
<Keybuk> it can exit ungracefully in main
<wasabi> True, you are correct, but still, every job has to do that.
<Keybuk> and log in syslog that it was unable to bind to the interface
<Keybuk> *shrug* every job does that already if it's checking the return codes of its syscalls like a good daemon
<wasabi> Yup.
<mbiebl> Keybuk: I've got two questions. 
<wasabi> So, by recording states, at all, in upstart or otherwise, what are you solving? They may be recorded in upstart, but jobs still have to check on their own properly.
<wasabi> So why not just let jobs do that?
<Keybuk> wasabi: solving the reattempt to start the job issue
<mbiebl> First: Is the Ubuntu udev patched to create /dev/console,null and the std* symlinks?
<Keybuk> the job doesn't just have to check it, it has to accept all possible states can fail intermittently, and fallback to some kind of "waiting for appropriate state" inner loop
<Keybuk> if it cannot bind() to the interface, it has to loop until it can
<wasabi> But doesn't the job have to reeveluate that in that loop on EVERY event that might contribute to the state?
<Keybuk> perhaps with some kind of asynchronous notification from an interface daemon that a new interface is up, to reattempt the bind
<Keybuk> exactly
<Keybuk> this is the launchd model, btw
<wasabi> Well, no. If it can't bind, it dies. And starts again next time something that might make it work appears.
<wasabi> Yeah, I know.
<Keybuk> no
<Keybuk> it doesn't start again
<Keybuk> because nothing will restart it
<Keybuk> it failed, bad bad job
<Keybuk> what upstart provides is that loop
<Keybuk> the job defines what state it likes
<wasabi> Eh? If it's waiting for both the file system and network, if any of those happen, it will restart.
<Keybuk> and upstart guarantees that it will attempt to start the job every time the system is in that state
<Keybuk> and that it will kill the job when the system goes out of that state
<wasabi> And check to see if both conditions are acceptable. So, when the file system comes up, it will start and look for the network. No network? Okay die. Network comes up a few minutes later and it starts again. Checks again and starts successfully.
<Keybuk> it cannot guarantee that the state will remain true for any period after the initial "this is true"
<Keybuk> but it can guarantee that the job will be killed again if it hasn't noticed
<Keybuk> *and* it guarantees that the job will be restarted if the state should become true again
<Keybuk> wasabi: sorry, I appear to have confused you
<wasabi> Perhaps.
<wasabi> I confuse easily these days.
<Keybuk> wasabi: my initial description of the looping application is the upstart-less world
<wasabi> I think my brain has been leaking a lot lately.
<Keybuk> the launchd model:
<Keybuk>  - all jobs are started immediately
<Keybuk>  - if a resource the job needs is not available, the job should sleep until it is available
<Keybuk>  - if a resource the job needs becomes unavailable, the job should sleep until it is available again
<ion_> As far as ive understood what Keybuk has been describing, it sounds good.
<Keybuk> ie. monitor your syscalls, if any fail due to an error (bind fails, write fails, etc.) you should fall into a kind of slumber loop
<Keybuk> how you wake yourself up from that slumber loop is anyone's guess
<Keybuk> asynchronous notification of the potential availability of resources?
<Keybuk> or maybe you just use blocking writes and blocking binds? :p
<wasabi> Ya know, I don't really mind that model, except for the wake up part.
<wasabi> But upstart has the wakeup part, in events.
<Keybuk> right
<wasabi> So slumber, but get poked when an event happens.
<Keybuk> so what upstart provides is the acceptance of the reality that states come and go
<wasabi> Where slumber == "just exit and let upstart start you again later"
<Keybuk> it guarantees that you'll be started when the state is true, and stopped when it becomes false
<Keybuk> so you can assume that any failure to obtain resources is bad, and just exit(1)
<Keybuk> because you'll get restarted again next time you can have a go
<wasabi> Except that those states are inherently hard to monitor, and can't be relied upon anyways.
<Keybuk> states are easy to monitor
<wasabi> Since they might be untrue by the time you get around to actually running.
<mbiebl> Keybuk: What for ressources that upstart can't easily monitor?
<Keybuk> and can be relied on to be true
<Keybuk> sure, they can become false again
<Keybuk> upstart says it will stop you if that happens
<Keybuk> ok, you might hit the failure first, but the worst thing there is a syslog entry
<mbiebl> E.g. remote services that are required, e.g. tomcat requiring a remote sql service.
<Keybuk> but you *will* get restarted next time the state is true for a while
<wasabi> mbiebl: I really don't think upstart offers anything there. You'd want tomcat and the database to be started independently of ech other... as there might be tomcat services that don't need the database.
<Keybuk> apps become "just assume that syscalls should work, check the return value, and bail out if they don't"
<Keybuk> upstart takes care of restarting you when the state is true again
<wasabi> Well, okay. Yeah. I like that... but that's how it is without upstart monitoring states too.
<mbiebl> Well, how is upstart supposed to know the state "remote sql service available"
<mbiebl> My point is, there are states, that upstart can't provide.
<wasabi> mbiebl: It's not. You'd have to implement something which feeds that state to upstart.
<wasabi> Keybuk: apps can function in the maner you describe whether upstart watches states or not. Since upstart *will* start it again when any event happens that might make it runnable.
<Keybuk> ah
<Keybuk> upstart doesn't *monitor* states
<Keybuk> upstart just provides a state whiteboard for everything else
<Keybuk> e.g. heartbeat could do it for the remove case
<Keybuk> remote case
<Keybuk> or monit
<Keybuk> or whatever
<Keybuk> they just emit events which upstart can combine into states
<Keybuk> or can set states true/false directly
<Keybuk> (registered through the usual initctl/libupstart layer)
<wasabi> Hmm. You can set states.
<Keybuk> I don't see why not
<wasabi> Okay, so a postinst script should set appropiate states.
<wasabi> That solves that.
<wasabi> A new state, for instance.
<Keybuk> postinsts for new things might end up having some kind of udevtrigger-a-like
<Keybuk> in fact, since many deviceish states will come with udev and HAL, udevtrigger is all you'd run :p
<wasabi> postinst: "hi upstart, I know this state is valid from x to y and n to m, but I just checked x and n, and it's good. So set it right now."
<Keybuk> right
<Keybuk> initctl set wibble true
<wasabi> So actually, a postinst for a new job might in fact set all states for that job to true without checking.
<Keybuk> mbiebl: remote services should be easy with heartbeat or monit
<wasabi> And the job might fail. But that's okay.
<Keybuk> wasabi: or it could just "start" the job *shrug*
<wasabi> Well, if it starts the job, and the job exits, the might might want to be started again properly.
<wasabi> Even though events that contribute to the state the job cares about aren't set.
<Keybuk> mbiebl: A to question 1 -- ubuntu's udev copies /lib/udev/devices into /dev before starting, that directory contains the usual console, null, etc. devices
<wasabi> I am jumbling all my words. I have no idea why I do that.
<wasabi> Let me try again.
<mbiebl> Keybuk: Well, you'd still have to patch heartbeat to emit upstart events.
<wasabi> job: from X to Y and N to M.   The postinst runs. Currently X is true and N is false, but upstart doens't yet know. So the postinst starts the job. The job exits because N is false (syscall fails). N becomes true, but since X isn't yet known, the job doesn't start again.
<wasabi> Hence the postinst has to set X and N to the proper values at the time of being installed, and let new events from that point on alter them.
<Keybuk> yeah
<Keybuk> postinsts for packages registering new states, or jobs that use unique states, should make an effort to check whether the requisites are true and set the state accordingly
<wasabi> And what sets the state?
<Keybuk> e.g. a package installing a state that says whether users are logged in should perhaps look at utmp
<wasabi> In the normal case?
<Keybuk> in the normal case, the state would be set by the daemon or by events
<wasabi> Where are teh events for the state defined?
<wasabi> And are states binary?
<Keybuk> by some daemon or other?
<wasabi> Hmm. I mean for, like the network interface case.
<wasabi> Who watches the interfaces and sets the states?
<Keybuk> not quite following
<Keybuk> whoever installs the postinst
<Keybuk> upstart does no watching
<Keybuk> network interface case => udev
<Keybuk> or maybe Network Manager
<Keybuk> I can't remember whether that one comes via udev, HAL or NM
<Keybuk> but it does come from one of them :p
<wasabi> So udev essentially runs initctl set network-up $IFACE true/false?
<wasabi> Or are the states defined in a file which contains `from X to Y`?
<Keybuk> either is valid
<Keybuk> in the udev case, I would have it emit events
<Keybuk> (in fact, I think events are generally preferred)
<wasabi> So oddly enough, states are back to being exactly what a job is: started or stopped, true or false. :0
<wasabi> Just without any executable.
<Keybuk> yes
<Keybuk> the implementation is very closely coupled internally
<Keybuk> in fact, all jobs have a state associated with them
<Keybuk> since it's that state that causes them to be started or stopped
<Keybuk> the difference in definition is simply that one has more options than the other
<wasabi> Hmm. I see.
<wasabi> So, you might in fact have a state and a job file both in /etc/event.d. Both files would look about the same, except the state one wouldn't have any exec lines.
<wasabi> And why the syntax difference between 'set' and 'start/stop' in initctl?
<Keybuk> that's the bit I'm trying to work out now :)
<Keybuk> whether it is worth exposing the internal difference externally
<ion_> Are states going to go to a separate directory than jobs according to the current plan?
<wasabi> Well, if jobs are internally states...
<wasabi> Then they belong in the same dir.
<Keybuk> and if the difference isn't exposed, how do we avoid the bloat of every state carrying the entire Job structure with it?
<wasabi> Are we talking about /etc/state.d? :0
<Keybuk> /etc/init
<ion_> /etc/init/{job.d,state.d}?
<wasabi> Keybuk: Well, you have a set of states, and a set of jobs.
<wasabi> Jobs depend on states. There is no external visibility of a job, except for the various running executables.
<Keybuk> jobs show up in initctl list
<wasabi> initctl stop foo actually means "set state `foo` to false", which internally results in the job structure going through the lifecycle for termination.
<Keybuk> should states?
<wasabi> Perhaps.
<ion_> Im in favour of putting jobs and states to separate directories. When there are going to be a lot of files in the directories, it will be helpful.
<Keybuk> ion_: then you have namespace collision issues
<wasabi> I'd not put them in seperate directories because it will intrduce some confusion. If a job is a state... then a job can depend on another job.
<wasabi> But also on a state.
<wasabi> Because there is no difference.
<wasabi> So if a job depends on `foo`, go find foo.
<Keybuk> there is a difference at the moment
<Keybuk> states are instantiable by default
<Keybuk> jobs aren't
<wasabi> Anyways, we've come full circle again. Back to jobs being exactly the same as states. There being no real internal difference except one has a structure for process lifecycle management.
<Keybuk> which is where it becomes interesting
<Keybuk> because if the lifecycle management can be separated, then we get to interesting ideas
<Keybuk> for example, imagine you have a state for the existance of a particular file
<Keybuk> tied into inotify maybe
<wasabi> ECOMPREHEND
<Keybuk> jobs could be run while and for /etc/site/*/apache.conf
<Keybuk> in other words, one copy of the job is run for each of the files that exists
<wasabi> That is interesting.
<wasabi> state---<job
<wasabi> Or, not really.
<wasabi> Is that one state or many states? heh
<wasabi> Well, it's one state... effected by many files.
<wasabi> affected
<wasabi> where each file defines a job structure hanging off the state.
<wasabi> When using the inotify/glob thing you just said, what is the value of the state at any time?
<Keybuk> true for a given filename
<wasabi> But when does it become false?
<Keybuk> states can have one false value, or one or more truths
<Keybuk> when there are no trues
<wasabi> Well, inotify is an event that says the file was altered. There is no correspondening point in time that the file "is not altered".
<Keybuk> not 100% sure about this bit yet
<wasabi> So it doesn't form a timeline of any sort.
<Keybuk> with inotify, we know when the file exists, when it is deleted and when it is modified
<Keybuk> so you put create on the left of the state
<Keybuk> delete on the right of the state
<Keybuk> and put modify on both sides, so the job is restarted
<wasabi> So while the file exists?
<wasabi> Ahh.
<Keybuk> the part of upstart that supplies this notification would set the states on startup using stat()
<wasabi> And now you have a true/false state that actually means file existance, but it toggles when it's modified.
<wasabi> But you can't detect the toggle, you can just see the fall out from it.
<Keybuk> right
<Keybuk> you may be more discreet, and define a file-exists state, and a file-same state or something
<Keybuk> so the job can choose
<wasabi> This could be implemented outside of upstart as well, in a way.
<wasabi> Which might be ... better?
<wasabi> Upstart only knows of the state. A seperate runnable daemon watches the files and toggles the states.
<wasabi> An extremely simple daemon.
<Keybuk> right
<Keybuk> my theory is that upstart would be able to supply the answer to a request of "what arguments to the file-created event are states expecting?"
<Keybuk> so the daemon would register that it supplies that event
<Keybuk> and upstart would respond with the arguments that it knows, and with new ones as jobs are created
<Keybuk> so the daemon knows what to watch
<Keybuk> this is all my next thing to tackle, anyway
<Keybuk> now that the config code is better
<AlexExtreme> porting the profile code to the new config stuff is harder than I would have liked ;)
<wasabi> Now, what do profiles do?
<wasabi> I think I missed that conversation.
<AlexExtreme> http://upstart.ubuntu.com/wiki/Profiles
<AlexExtreme> (this code isn't in main, it's in my branch)
<wasabi> ahh
<wasabi> Seems simple, reasonable, and sane.
<AlexExtreme> cool
<wasabi> ie not a huge subsystem, just a simple filter of state names.
<wasabi> at uds-mtv we talked about some sort of flag thing which you could set, and instead of using profiles (something outside of the job) to determine whether the job would run, the job itself would check the flag.
* wasabi shrugs.
<AlexExtreme> yeah
<wasabi> Which could interestingly enough be done with states.
<AlexExtreme> i didn't particularly like that idea for some reason which i can't remember
<wasabi> where states were settable from the loader prompt.
<AlexExtreme> bbl
<Keybuk> an interesting thought has occurred
<Keybuk> the state in which the apache job can be run
<Keybuk> is not the same as
<Keybuk> the state in which the apache job is running
<wasabi> Hmm. I barely understand that.
#upstart 2007-06-14
<Keybuk> wasabi: so let me try and explain :)
<Keybuk> you have a job for a web server
<Keybuk> in this job, you define the configuration for the web server itself; what needs to be run, how to prepare the machine and clean up afterwards, etc.
<Keybuk> any chroot/chdir/resource limits/etc.
<Keybuk> this is the "job"
<Keybuk> you also define the machine state in which the web server should be running
<Keybuk> these are events and pairs of cancelling events
<Keybuk> or references to other job/states
<Keybuk> e.g. the web server is running while there is at least one non-local network interface up and the filesystem has been assembled
<Keybuk> this is "the state in which the web server can be run"
<Keybuk> and the web server job state is nominally coupled to this state
<Keybuk> any changes to this state change the goal of the web server job
<Keybuk> however this is not "the state in which the web server IS running"
<Keybuk> because the web server could fail to start, and stop again, without the underlying state being changed
<Keybuk> or the web server could be started and stopped manually
<Keybuk> or the web server could be a member of a disabled profile
<Keybuk> etc.
<Keybuk> jobs that reference "when a web server is running" are NOT referencing the state in which the server could be running, but the state in which it IS running
<Keybuk> so there's a second state here
<Keybuk> one state is defined in the job configuration and is tied to the goal of the job
<Keybuk> the other state is implicit and is tied to the state of the job
<Keybuk> so "with apache" means the state of the apache job
<Keybuk> not the state in which the apache job can be running
<wasabi> i see
<Keybuk> does that make sense?
* Keybuk has issues with blocking
<wasabi> does this # have logs?
<Keybuk> yeah
<Keybuk> people.ubuntu.com/~fabbione/irclogs/upstart-devel-....
<Keybuk> err
<Keybuk> upstart-... :p
<Keybuk> http://upstart.ubuntu.com/wiki/States
<AlexExtreme> heh, the implementation of profiles i did before was purely lazy
<Keybuk> hmm?
<AlexExtreme> well, it had absolutely no support for changing profile at runtime, in fact it was quite easy to do that
<AlexExtreme> it used multiple variables to store info about the current profile rather than a struct
<AlexExtreme> so i've had to do a fair bit of work to get it working with the new config code, rather than changing a few lines
<AlexExtreme> laziness != good ;)
<Keybuk> oops, sorry
<AlexExtreme> \o/
<AlexExtreme> parse_profile.c written
* AlexExtreme adds the necessary parts to conf.c
<Keybuk> never read code you wrote when you were 18
<Keybuk> it's very disturbing
<AlexExtreme> heh
<AlexExtreme> i have code here that i wrote when I was 9
<AlexExtreme> it's *very* disturbing ;)
<AlexExtreme> not to mention that it's written in VB
<ion_> Anything VB is disturbing.
<AlexExtreme> true
<ion_> Speaking of disturbing and VB, http://johan.kiviniemi.name/blag/2006/12/26/excellence/ (in you havent been spammed with this URL yet).
<AlexExtreme> interesting
<wasabi> blah. this new server will not run mdrun and vgchange properly in the initramfs
<wasabi> these packages are constantly pissing me off heh
<Keybuk> wasabi: which release?
<wasabi> feisty
<Keybuk> heh, yeah, that was pretty bustef
<wasabi> My desktop on gutsy is busted too.
<Keybuk> yeah, gutsy is more busted righ tnow
<wasabi> ... my desktop is weird. It looks like udev spawns a ton of mdadm processes.
<wasabi> infinitly.
<Keybuk> evms installed?
<wasabi> Nope, I've removed EVMS from teh picture.
<Keybuk> oh right
<Keybuk> dunno then
<wasabi> You win.=)
<Keybuk> I do?
<wasabi> Yup. No more evms for me. heh
<Keybuk> lol
* Keybuk starts on the next project
<Keybuk> "make wasabi use ext3" <g>
<wasabi> Are you still familiar with the local-top/mdadm|run scripts, or is somebody else doing them now?
<wasabi> Oh, you won that too.
<Keybuk> I'm trying to understand what they do/are for
<wasabi> I just reformatted to ext3.
<wasabi> Mostly because half of my files because mysteriously truncated.
<Keybuk> heh, it's interesting how most people abandon XFS after an "event"
<Keybuk> mine was when a bunch of files had \0 through them for no readily apparent reason
<wasabi> ldconfig: file /usr/lib/libwine.so.1 is truncated
<wasabi> at least ldconfig is very clear about the problem. heh
<wasabi> RUN+="watershed -i udev-mdadm /scripts/local-top/mdadm from-udev"
<ion_> keybuk: Ditto.
<Keybuk> yeah
<wasabi> That's an odd one. What's the 'udev-mdadm' in there refer to?
<Keybuk> I don't understand why ian runs that
<Keybuk> since in the real filesystem, we just run mdadm itself
<wasabi> You mean mdrun?
<Keybuk> err, mdadm I think
<Keybuk> I don't really understand what the difference between the two mdadm related initramfs scripts is
<Keybuk> and what the difference between mdrun and mdadm is
<Keybuk> once I understand, mdadm shall be fixed
<wasabi> Looks like mdrun does auto detection. It's a single shot line that probes all drives.
<wasabi> Probably not what you need with udev feeding events.
<wasabi> Hmm. Yeah, looks like mdadm has the work mdrun does duplicated... just in a harder fashion.
<wasabi> ... builds a config file on the fly from --scan, and then uses that.
<Keybuk> interesting
<Keybuk> neither seems right though, since we need to run something repeatedly until it sticks?
<wasabi> Yeah. I think what mdrun does is technically rigth... probes all devices.
<wasabi> Just watershed it on any device event.
<wasabi> Oh except mdrun is deprecated.
<wasabi> well that cinches that. *deletes the file*
<Keybuk> lol
<Keybuk> welcome to my world
<Keybuk> "ah, this looks exactly right ... wait, what'd'ya mean deprecated?"
<ion_> :-)
<AlexExtreme> :)
* Keybuk scowls at the weather
<Keybuk> you rained yesterday, so flying was cancelled
<Keybuk> you're raining again today
<Keybuk> you better not rain on Saturday
<AlexExtreme> heh. sometimes I wonder whether this really is summer...
<AlexExtreme> i think we had summer here in april ;)
<Keybuk> yeah
<ion_> Not very summer-ish here either, but thats to be expected, this is Finland after all. :-)
<AlexExtreme> well, that's a start
<AlexExtreme> it segfaulted
<AlexExtreme> :p
<AlexExtreme> bah
<wasabi> honest question. how do you know what is "supported" and not "supported" on ubuntu. md, for instance. How can it be that it is knowingly busted in feisty?
<wasabi> Heh.
<AlexExtreme> it helps to call nih_list_init on a NihList before using it
<wasabi> In fact who specifically should be tarred and feathered for this?
<AlexExtreme> i'm not sure about md in feisty, i used it once it it was broken, kinda.
<AlexExtreme> can't remember what happened exactly
<AlexExtreme> brb, testing again
<wasabi> Or perhaps it's my fault for thinking feisty would work at all the same things dapper did. Perhaps the lack of the LTS.
<AlexExtreme> neat
<AlexExtreme> it worked
<wasabi> hmm. wonder if mdadm and vgchange could somehow deadlock on each other.
* Starting logfile irclogs/upstart.log
#upstart 2007-06-15
<wasabi> hmm well so i got the mdadm thing working.... by removing half of the file.
<redline6561> hi devs. hate to be asking dumb questions and bothering people but i've been trying to get a servlet container (tomcat, jetty, or resin) to load as a system service on feisty and been unable for several weeks.
<redline6561> my employer and I feel that somebody is doing this and we're just not doing it right. i was wondering if it might be upstart related. essentially, placing a script in /etc/init.d and running update-rc.d $script defaults isn't working.
<redline6561> is there some modification to the script i need to make or is update-rc.d deprecated? what's going on?
<AlexExtreme> that's not an upstart problem
<redline6561> ok. do you have any advice? i have no problem believing that i'm an idiot and have done something wrong i just don't see this thing loading on startup. i've disabled splash and checked logs.
<redline6561> alternatively, where would you suggest i go for help?
<AlexExtreme> ask in #ubuntu
<redline6561> thanks alex
<shawarma> AlexExtreme: Alternatively, #ubuntu-server would be alright.
<redline6561> thanks for the hint shawarma
#upstart 2009-06-08
<ion_> https://lists.ubuntu.com/archives/upstart-devel/2009-May/000967.html âMy wiki implementation will have a comment chain / mailing list attached to each page.â Heâs duplicating Google Wave?
#upstart 2009-06-09
<twb> I am looking at /etc/event.d/ on an Ubuntu Server 8.04 system.
<twb> Can someone explain why tty1 and tty2 differ in their start/stop parameters?
<twb> It looks like tty2 through 6 are only active for runlevels 2 and 3.
<JamesB192> twb: tty1 should also come up for single console mode. j/k I dunno.
<JamesB192> I don't have any *buntu boxes or boxes w/ upstart, so I'm actually guessing wildly.
<twb> JamesB192: out of curiosity, what are you running upstart on, then?
<JamesB192> nothing atm, I haven't gotten around to (re)installing it on my ??ntoo box.
<twb> Righto.
<JamesB192> I think I remember though that some linux boxes have a single console mode for non live coaster rescue type stuff.
<twb> They do; this is traditionally runlevel 1.
<JamesB192> and no doubt in 30 minutes someone who know what they're talking about will explain what I'm missing.
<JamesB192> but I answered first.
<twb> I imagine that is very important to you.
<JamesB192> I think I have a tarball with jobs similar to those, but I can't seem to find them atm.
<twb> JamesB192: upstart's source contains some examples along those lines.
<Keybuk> twb: actually, it's exactly as JamesB192 says
<Keybuk> in Ubuntu, we don't start getty on tty2-6 unless in runlevel 2 or 3
<Keybuk> just a hold-over from sysvinit
<twb> Keybuk: it's not a holdover from sysvinit, because Debian's inittab starts all six in all those runlevels (2 through 5).
<twb> Unless you're referring to an intermediary instance of inittab, or RH's inittab ;-)
<Keybuk> I'm pretty sure ours didn;t
<twb> Oh well.
<twb> At least the differences make sense.
 * Keybuk grabs a copy of sysvinit's source to check
<Keybuk> 1:2345:respawn:/sbin/getty 38400 tty1
<Keybuk> 2:23:respawn:/sbin/getty 38400 tty2
<Keybuk> 3:23:respawn:/sbin/getty 38400 tty3
<Keybuk> 4:23:respawn:/sbin/getty 38400 tty4
<Keybuk> 5:23:respawn:/sbin/getty 38400 tty5
<Keybuk> 6:23:respawn:/sbin/getty 38400 tty6
<twb> What version is that from?  6.04?
<Keybuk> current (karmic)
<twb> Huh?  But most of inittab is completely ignored, at least in 8.04.
<Keybuk> sure, we still have the source in the archive though
<twb> Ah, OK.
<Keybuk> err
<Keybuk> I just grabbed the Debian source
<Keybuk> it has the same
<twb> Wow.
<twb> What is Debian doing, changing behind my back?
<Keybuk> how do you mean?
<Keybuk> it looks like it's always been like this
<twb> Maybe I misunderstood it, then.
<Keybuk> can you paste the getty lines from yours?
<twb> I could've sworn that at some time, probably around Sarge, it defaulted to :2345:
<twb> Keybuk: eh, my instances are modified ;-)
<Keybuk> doesn't look like it
<twb> Oh well.
<Keybuk> no idea why Debian is like this, of course
<soren> Keybuk: Have you had a chance to look at https://bugs.edge.launchpad.net/ubuntu/+source/upstart/+bug/372864 ?
<Keybuk> if I haven't commented on it, I missed it
<soren> You haven't :)
#upstart 2009-06-10
<mbiebl> Md: around
<mbiebl> ?
<Md> mbiebl: yes
<mbiebl> Md: hi
<mbiebl> could you take a look at http://debs.michaelbiebl.de/bootchart.png
<mbiebl> especially the modprobe calls during udevadm phase
<mbiebl> Is it normal, that they take 3 secs?
<Md> mbiebl: I think so, IIRC there is some kind of serialization in the kernel. the most recent kernel and m-i-t should have some performance improvements
<Keybuk> if you're using 2.6.30 there's no in-kernel lock
<Keybuk> which m-i-t is it?
<mbiebl> 3.7-pre9
<Keybuk> hmm, that should be fine
<mbiebl> or is bootchart lying to me ;-)
<Keybuk> well, those will be all your combined modprobes
<Keybuk> but it's odd it's taking taht long
<Keybuk> udevadm is ~0.5s for me
<mbiebl> Keybuk: fwiw, this is a bootchart of a up-to-date karmic system: http://debs.michaelbiebl.de/pluto-karmic-20090609-1.png
<Keybuk> the IO looks pretty crappy there
<Keybuk> HDD or SSD?
<mbiebl> HDD
<Keybuk> and you have the same death-by-devkit that I see ;p
<mbiebl> yeah, I was already puzzled by that
<ion_> You call that a death by devkit? http://launchpadlibrarian.net/27624460/virhe-karmic-20090607-1.png :-P
<mbiebl> wow, that looks bad :-o
<ion_> TBH, itâs not devkitâs fault. https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/384579
<Keybuk> lol
<mbiebl> ion_: do you use MODULES=dep in initramfs.conf (I'm wondering because your initramfs stage is much shorter than mine)
<ion_> MODULES=most
#upstart 2009-06-11
<hadess> Keybuk: around?
<hadess> i have that event.d script for upstart: http://pastebin.com/m222f649a
<hadess> but it doesn't seem to do what it's supposed to, and i don't know how to turn on debug for upstart
<Keybuk> to answer your second not-quite-question first
<Keybuk> boot with --debug on the kernel command line
<hadess> ok, doesn't make for easy debug switching on an already started machine
<Keybuk> 0.3.x or 0.5.x ?
<Keybuk> try "initctl log-priority debug"
<hadess> upstart-0.3.9-24.fc11.x86_64
<hadess> though i'm trying to get something that'd run on both, and could stick upstream
<Keybuk> 0.3 and 0.5's job syntax isn't compatible
<Keybuk> (nor will 0.10's be compatible with either)
<hadess> ok
<hadess> well, let's start with 0.3 then
<hadess> do i have the idea right for that script for 0.3?
<Keybuk> yes
<Keybuk> as long as something calls initctl emit fedora.bluetooth-adapter-{,not-}available
<hadess> any idea why it wouldn't be working?
<Keybuk> it'll be started when an adapter is available
<Keybuk> and stopped when *either* an adapter is no longer available *or* the system is shutdown/entered into single user mode
<hadess> i used "initctl emit --no-wait fedora.bluetooth-adapter-available"
<hadess> in a udev helper
<Keybuk> ok
<hadess> and that bit works
<hadess> as the helper also dumps junk into a temp file, and that got updated
<hadess> could bluetoothd forking as a daemon break things?
<Keybuk> yes
<Keybuk> upstart will think it has died
<hadess> ok, let's fix that already
<hadess> exec bluetoothd --no-daemon
<Keybuk> supervision of forking daemons is one of the major features of the upstart-nl branch
<hadess> that's not really a problem for me here though
<hadess> nope, still not working
<hadess> i wonder where the syslogd config lives these days
<hadess> there's a bug in my rules
<hadess> the helper uses udevadm to list devices, and obviously, when the rule is run, udev doesn't know about the device yet...
<hadess> so it emits fedora.bluetooth-adapter-not-available all the time
<Keybuk> ah
<hadess> you wouldn't happen to know how to defer that call slightly?
<Keybuk> not on fedora
<hadess> notting also told me that i'd get into trouble getting the udev event real early with the root still r/o
<hadess> i'll discuss those with kay
<hadess> thanks for the help!
<Keybuk> yeah, udev runs when the root is still r/o
<hadess> Keybuk: got it running, any ideas why it stops it straight away here: http://pastebin.com/m5cf62c70 ?
<Keybuk> #
<Keybuk> Jun 11 11:26:46 cookie init: bluez main process (4330) terminated with status 1
<Keybuk> whatever you're running is exiting
<hadess> weird, not sure why it would be
<hadess> i'm an idiot :)
<soren> Keybuk: I'm not sure I understand your comment on bug 372864. Will there be a better mechanism for doing this in the Karmic cycle?
<hadess> Keybuk: awesome, working :)
<Keybuk> soren: definitely
<Keybuk> soren: though it may be quite late in the karmic cycle, like in the next one ;)
<soren> Keybuk: ah  :)
<Keybuk> but certainly not worth trying to come up with an upstart-y way of doing it now, if I'm doing a ground-up rewrite/redesign of Upstart ;)
<Keybuk> about the point you get it working, I'll break it again
<soren> Keybuk: So if I need that console to be there for the Karmic release, what do I do?
<soren> Cry?
<soren> :)
<Keybuk> soren: how would you do it in sysvinit?
<Keybuk> create the file in a postinst depending on how being installed?
<soren> Keybuk: I was hoping not to have to do anything like that.
<soren> Keybuk: So far, I've managed to not have to special case anything for kvm based virtual machines.
<soren> In the sense of installing additional packages to make stuff work, that is.
<soren> I'd really, really like to keep it that way.
<soren> I don't know how I'd have done it in the old days with plain old sysvinit.
 * soren contemplates a udev rule that installs the job description in /etc/event.d when the hvc0 device pops up
<soren> (only joking)
<Keybuk> filesystem is read-only when your rule is run
<soren> Another cunning plan foiled by pesky reality. Darn it.
<cubicool> Is it possible for an upstart job to grab control of the init process and demand some input before continuing? (In my case, insisting a password is entered to decrypt a filesystem)
#upstart 2009-06-12
<JamesB192> add an 'initctl -emit rootfs_decrypt' or something to the end of the stanza that requires input triggering the next steps.
<JamesB192> which is to say probably.
<cubicool> Is it possible for an upstart job to "grab focus" somehow during boot and ask the user for some input before continuing? (In my case, to get a password interactively)
<cubicool> Is it possible for an upstart job to "grab focus" somehow during boot and ask the user for some input before continuing? (In my case, to get a password interactively)
<cubicool> Sorry to keep asking, but my project is pretty much dead until I figure this out. :/
<cubicool> I guess I could try the lists.
<sadmac> cubicool: I think if you add console output to the job it should do it
<sadmac> that's one line
<sadmac> "console output"
<sadmac> no quotes
<cubicool> Well, it certainly prints my output and wants to read input, but the rest of the init continues unhindered.
<cubicool> And in my case, the rest of the startup will require a drive being unecrypted via a password.
<cubicool> (That is to say, my job already has that line. :))
<sadmac> cubicool: ah, I see...
<sadmac> cubicool: you need that job not to show up as running until it has what it needs, and you need everything else to wait for that job
<cubicool> And so what happens is GDM starts up and my query is still on TTY1, although it's difficult to see because other output has scrolled it off screen.
<cubicool> Yes, but the more I learn about upstart the more I think this kind of thing is either not possible or simply not wise.
<sadmac> cubicool: depends on what you want to do. drive decryption is typically an initrd issue for us
<cubicool> We have a client, however, that must have this functionality; and the distros they could use (Fedora or Ubu) both use upstart now.
<cubicool> Really? That's not a bad idea with a sufficiently smart initrd.
<sadmac> cubicool: fedora's encrypted root implementation does it in initrd
<cubicool> Iinteresting.
<sadmac> since, well, root is encrypted
<cubicool> In my case now it's not actually /, but a special /data mount.
<cubicool> But it needs to be up quick before their proprietary stuff starts up
<sadmac> you need to tell their proprietary stuff not to start until /data is ready. what does it start on now?
<cubicool> It's hard to say. They can't give us a lot of information.
<sadmac> that's kind of a problem
<cubicool> All they can tell us is that they must be able to interactively decrypt the drive via a password as one of the VERY first actions. :/
<sadmac> that could require adjusting a lot of the surrounding upstart config
<cubicool> So probably more sensible to do it in our initrd then?
<sadmac> and it does get into things that 0.3.9/0.5 aren't good at (hence 1.0 being a pretty heavy redesign)
<sadmac> yeah, do it there.
<cubicool> Actually, I can't actually because the initrd just does a pivot_root or whatever. THis particular encfs isn't /...
<cubicool> Hmmm.
<cubicool> Maybe I'll try and take a look at the source.
#upstart 2010-06-14
<Kamil_> can someone point me to some example upstart scripts? for example, something controlling apache or named would be interesting
<ion> See /etc/init
<Kamil_> is there a way i can see them without having to isntall the packages on my machine?
<ion> Do you not have Upstart running on your system?
<Kamil_> i have upstart on the system
<Kamil_> i dont have anything controlling apache or bind
<ion> There should be various jobs in /etc/init.
<Kamil_> i created a script to execute a special build of named. it starts fine, but when i query its status, upstart doesnt seem to know about it
<Kamil_> $ sudo start bind
<Kamil_> bind start/running, process 2018
<Kamil_> $ sudo status bind
<Kamil_> bind stop/waiting
<Kamil_> but it's definitely running
<ion> It probably daemonizes. Itâs easiest just to tell it not to daemonize. Upstart 0.6 has preliminary functionality for tracking forks, but itâs very easy to confuse that functionality. If you want to experiment with it, see the âexpectâ stanza. Upstart 0.10 will handle that well.
<Kamil_> thanks i will take a look at that
<ion> That is, if you know exactly how the main process forks, feel free to use the expect stanza. If youâre uncertain, simply tell the daemon not to fork.
<Kamil_> understood
<Kamil_> another question, if there is a special stop command, is the correct place for that within a pre-stop script?
<ion> Yes
<Kamil_> thanks
<Omahn> Is it possible to receive a log message from upstart of the exact command run from an 'exec' after all the variables have been populated?
<Omahn> Will removing an upstart job from /etc/init automatically 'stop' the job (when removing a package) or should the package explicitly stop the job before removing the file?
#upstart 2010-06-15
<h0rnman> good morning/afternoon/evening everyone :)
<h0rnman> can anyone tell me if there is an event in Upstart that I can trap to ensure that a CIFS unmount script runs before any sort of network down scenario when I shut down or reboot?
<mbiebl> Keybuk: hi. You mentioned that you have a patch implementing native sysv/LSB support
<mbiebl> when do you plan to merge/commit that patch?
#upstart 2011-06-13
<alcane> yo
<alcane> anybody here?
<alcane> it's been a while for me at the command line and ubuntu's telling me I should use upstart instead of the init.d script... can't seem to find the command for using upstart
<JanC> what do you want to do?
<JanC> most likely you tried to use a service that was converted to upstart already, and not using the sysvinit-compatibility anymore
#upstart 2011-06-14
<alcane> needed to add sudo, lol
<alcane> thx anyway
<Keybuk> sudo is like cowbell
<Keybuk> if it's not working, add more
<benbro> what "restart myserver" suppose to do?
<benbro> "stop myserver" and "start myserver" works as expected
<benbro> but "restart myserver" just stop it
<wraiden> *still hacking on the alias stanza*
<wraiden> Scott?
<Keybuk> hey
<wraiden> i plan to send my alias work to the list in the next few minutes
<wraiden> its still untested
<wraiden> i think the utmp handling still desn't work with 1.3
#upstart 2011-06-15
<SpamapS> Keybuk: 1.3, huzzah!
<wraiden> *running testsuite with alias stanza draft added*
<Rioting_Pacifist> is there an easy way to monitor upstart events?
<Rioting_Pacifist> it's cool i got an answer in #ubuntu-devel sorry if i woke anybody from their sleep
#upstart 2011-06-16
<wasabi1> Anybody have any links to an overview of Fedoras decision process to go to systemd?
<ion> wasabi1: Here you go: http://i.imgur.com/vFeQt.jpg
<wasabi1> haha
<wasabi1> So I notice the Upstart.ubuntu.com page is pretty unmaintained.
<wasabi1> Latest release 0.6.7?
<cjbottaro> Hello.  I'm trying to use upstart to control a python program that daemonizes itself.
<cjbottaro> The problem (apparently) the python script starts a new process that thus upstart isn't aware of.  How to remedy?
<cjbottaro> got it:  expect daemon
<cjbottaro> Is there a way to have to restart succeed even if the job isn't already running (i.e. behave like start if job isn't running)?
<Keybuk> no
<Keybuk> stop job; start job
<bhuga> can anyone tell me how i might start a screen via upstart so i can attach to something that starts at boot later?
<bhuga> 'exec screen -dm bash', for example, fails in upstart but works from the shell
<cipher> "fails?"
<bhuga> 'terminated with status 1' in the log files, followed by auto-respawns until it stops for going too quickly
<cipher> what's your start on stanza
<cipher> actually can you paste your conf?
<bhuga> http://pastie.org/private/wfzagb0p8wieak9ce20aea
<bhuga> after lots of playing with the real thing (which is a wordy attempt to get a lisp image running that i can get into and debug), i cannot even get that to work
<bhuga> it has not pasted correctly
<bhuga> it seems
<bhuga> there is a newline before the end script :)
<cipher> try playing with the start on being rc
<bhuga> this is with 'service spocq start'
<bhuga> running at boot isn't the trick, it just errors when it runs
#upstart 2012-06-11
<stefw> hey guys. can I use upstart + a dbus interface to restart a system service (eg: winbind)
<stefw> after installation of winbind i don't see it listed as an upstart job (looking via d-feet)
#upstart 2012-06-12
<wt> Anyone here know how to read a variable for an upstart script from another file?
<wt> I'd like to be able to make the user a job runs as configurable.
<wt> so I want to read a file that defines a var (e.g. "exec_user") and then use something like the following for my exec line: exec start-stop-daemon --signal SIGQUIT --start -c "$exec_user" --exec /usr/bin/foo
<wt> oh, maybe I can use another upstart job to start it with an instance var
<wt> it's not really multiple instances though, so, just out of curiosity, is there a way to do with without and instance var?
#upstart 2012-06-13
<jongleur> Hi. Probably anyone here can help me. Itry to get Openstack running, and have a problem with nova-volume. nova-volume should run as an upstart demon, but it get's killed immediately after I start it (after start nova-volume returned success).
<jongleur> calling sudo nova-volume directly works.
<jongleur> calling nova-volume directly does not work as it needs root privileges
<jongleur> start nova-volume returns success, but the corresponding service is killed more or less immediately thereafter
<jongleur> is there anything I could do to get it working?
<jongleur> is it possible to start the demon itself with sudo-privileges?
<MarkShark> Is this the right place to talk about what looks to like a race between the gdm job and the mounted-tmp job and the x11-common script in rcS.d?
<Etale> Hi people. Whenever I try to reboot my Ubuntu 12.04LTS, it gets stuck on the splash screen. I think it might be a hanging upstart script. Do you have any ideas on how to solve it?
<Etale> I think that's what it must be because using sysreq magic I can restart just fine.
<Etale> Also, when I change the grub commands in various ways that people told me to, and then update grub, it doesn't help.
#upstart 2012-06-15
<djwn> here goes: how does one use a config file of env vars with upstart jobs?
<djwn> looks like sourcing the conf might work
<djszapi> salhey
<djszapi> slangasek: ^ :)
<djszapi> shall I just use pre-start and post-stop if I would like to modprobe a module for my daemon, and rmmod that once that is stopped.
<djszapi> so that the g_serial.ko module would only be needed for my module, and nothing else. Hence, I would not like to put into the /etc/modules file.
<jodh> djszapi: seems reasonable - some services already do this in Ubuntu.
<djszapi> shall I use exec before modprobe and rmmod, or not ?
<djszapi> jodh: does this look sane then ? http://paste.kde.org/500420/
<djszapi> something is broken with that, because after running my "start foobar" job, I am not getting the g_serial loaded, nor my binary running :(
<jodh> djszapi: I'd take out that sleep which is a hack seemingly. Also, I believe we have previously discussed the fact that Upstart runs all jobs with "/bin/sh -e", hence see: http://upstart.ubuntu.com/cookbook/#debugging-a-script-which-appears-to-be-behaving-oddly
<djszapi> jodh: hack, but needed anyway
<djszapi> jodh: unless you fix upstart.
<SpamapS> djszapi: isn't that sleep because the event you are trying to handle isn't handled properly in udev, not upstart?
<djszapi> no any real clue
<SpamapS> djszapi: I think I recall the issue was that you want this to be run if the device is plugged in, but not before some state has been reached in the boot
<djszapi> the daemon should be running, once the device is recognized by the kernel, and then udev in userspace.
<SpamapS> ok, but the sleep 60 would imply that there is something else you need
<djszapi> ?
<djszapi> it is a hackaround without knowing any better way.
<SpamapS> and your start on doesn't mention the device attributes, just udevtrigger.. so its hard to agree that we need to 'fix upstart' when you're not using it the way it was designed
<SpamapS> I'd expect a  something-device-added
<djszapi> I use at this was designed
<djszapi> agreed by few people
<djszapi> you can say all of us said bullshit
<djszapi> but you need to technically prove that
<SpamapS> If you want a job to be run when a specific device is recognized by udev, 'start on udevtrigger' is not the way to do that.
<djszapi> I would suggest reading the log back
<djszapi> there was more than this discussed.
<SpamapS> #start on tty-device-added DEVNAME=/dev/ttyUSB1
<djszapi> we tried other triggerings as well
<SpamapS> I suspect this failed for some odd reason?
<djszapi> nothing worked really :)
<djszapi> we tried to make both as a condition
<SpamapS> I recall the case now
<djszapi> not even that
<SpamapS> but not the real issue
<djszapi> we do not know the real issue
<djszapi> it is either in udev, or in the linux kernel
<djszapi> this is a workaround
<djszapi> and it is gonna remain so until someone shows up a more elegant solution.
<SpamapS> ok, so while it is making upstart a pain to use, its not actually upstart doing something "wrong"
<SpamapS> djszapi: sorry to complicate things. Did you still have an unanswered question?
<djszapi> if you can review the job, that would be great.
<djszapi> and provide feedback.
<jodh> djszapi: I updated the Cookbook regarding the udev issue you've observed: http://upstart.ubuntu.com/cookbook/#careful-use-of-udev-events, but note that this is not an Upstart issue. Do you eventually get a udev event containing a ID_* variable?
<djszapi> jodh: no clue
#upstart 2013-06-10
<hyperair> hi. i'm getting a lot of these messages: [1384111.170887] init: Failed to spawn startpar-bridge (mountall-net--stopped) main process: unable to change root directory: No such file or directory
<hyperair> is there any way i can stop this without having to reboot?
<FoShizz_> anyone here?
<FoShizz_> just lookin for some help.
<Cheery> hi
<Cheery> I'd like to understand linux systems better, and for this I'm trying to build a filesystem.
<Cheery> it means I need to understand how linux boots up.
<Cheery> well. grub2 handles the bootup into the linux. linux initializes itself then calls /sbin/init
<Cheery> I'd like to try something like: bash+init+linux+grub today.
<xnox> Cheery: calls init from initramfs ( https://wiki.ubuntu.com/Initramfs ) which mounts root filesystem and then exec /sbin/init from the new root fs.
<Cheery> xnox: so I also need initframfs
<xnox> Cheery: one can have busybox-static in the initramfs, thus your initramfs can already have shell. And the init in initramfs is no more than just a very long shell script. See the wiki page I linked to, on how to unpack ubuntu's initramfs.
<xnox> Cheery: thus for a minimal testing you only need: grub + linux (kernel img + initramfs)
<Cheery> nice
<Cheery> I'll try figure out the rest on my own.
#upstart 2013-06-11
<xnox> slangasek: how about modifying init-functions that upon sourcing check with upstart if there is a matching job name & then execute if init_is_upstart case and provide correct exit codes for each action?
<xnox> or adding a helper function exit_if_init_is_upstart
<slangasek> xnox: well, I'm not really in favor of that, but I also don't oppose it strongly.  Propose it to the lsb package maintainers?
<xnox> slangasek: also i really, really do not like sourcing /etc/default/* and how that is messing up with simple jobs.
<slangasek> xnox: I maintain that sourcing /etc/default is the lesser evil, compared with dropping the admin's service customizations when switching to upstart
<xnox> ok. adding two extra lines.
#upstart 2013-06-12
<delfick> hi there. I have an upstart conf that starts up my uwsgi server and it seems that it's causing every message from uwsgi to be duplicated to syslog. If I run the script on the command line (start-stop-daemon executing uwsgi) then they don't duplicate
<delfick> does anyone have any ideas on how to debug this issue? or why it would happen at all?
<hyperair> check how many syslog processes are running.
<hyperair> presumably uwsgi talks to rsyslogd which writes to /var/log/syslog. if every message is being duplicated, that could mean that either more than one rsyslogd process is running, or uwsgi is logging everything twice (multiple uwsgi instances?)
<hyperair> what does the output from either case look like anyway?
<hyperair> the terminal output from starting uwsgi i mean.
<delfick> ok
<delfick> so
<delfick> there's only one rsyslog process
<delfick> and the log looks like this http://pastebin.com/nYsYLjBf
<callen> I'm having problems with my upstart job in /etc/init, service/initctl/et al don't seem to see the job. status: Unknown job
<callen> https://www.refheap.com/5471cb430dda4d0e426aa86ab this is the script, I don't see any relevant logs in /var/log/upstart either.
<callen> is there something I've seriously misunderstood? I'm running service as root, the conf in /etc/init is owned by root:root
<xnox> callen: Please try running: init-checkconf /etc/init/YOUR-JOB.conf
<xnox> to verify syntax.
<xnox> callen: please note upstart job configuration files are not executable scripts. Thus should not have "#!upstart", should be regular files, with ".conf" extension.
<callen> xnox: noted, I didn't have that before, it was cargo cult in the midst of my desperation to get it working.
<xnox> callen: cargo cult from here http://upstart.ubuntu.com/cookbook/
<xnox> =) it's the documentation, guide and examples.
<callen> xnox: have been'
<callen> I branched out from that when it didn't work.
<callen> xnox: it doesn't like my script stanza.
<xnox> callen: any hidden/non-printable characters? windows line ending?
<callen> ah bloody hell
<xnox> callen: copy & pasting from the paste, validates correctly by init-checkconf here on Ubuntu.
<callen> xnox: I had a stale file remotely.
<callen> xnox: it checks out now, although it seems to be stuck on stop/waiting.
<callen> xnox: it's choking on my use of "source"
<callen> xnox: what's the proper way to inject an environment?
<callen> .?
<xnox> callen: both source and '.' are the same.
<xnox> callen: you have respawn set. So if you are trying to start it, and daemon exits it gets stuck respawing. I'd try removing respawns & check to see that it starts & stops correctly.
<xnox> callen: check logs under /var/log/upstart/YOURJOB
<callen> xnox: it's working now.
<callen> xnox: the problem was source, using . fixed it.
<callen> must be /bin/sh
<xnox> hm. ok.
<callen> xnox: I'm in good shape now, thank you so much for helping me out.
<callen> xnox: the suggestion to use init-checkconf saved my sanity :)
<xnox> callen: =) no problem and your welcome.
<xnox> callen: guess why it was written in the first place...... =)
<codelotus> can someone tell me if the following is possible in upstart:
<codelotus> script
<codelotus>   # a shell file that launches a java daemon
<codelotus> end script
<codelotus> I've been through the cookbook with no luck and I'm starting to wonder if I'm thinking about this the wrong way
<xnox> yes, one can do so.
<xnox> codelotus: but you should be careful about how many times all of that forks and be aware of getting the expect stanza correct.
<codelotus> xnox: ok, thanks
<xnox> codelotus: the "status yourjob" should show the same pid, as you would expect, from looking at the "main" process in ps output.
<xnox> codelotus: there are examples of running java daemons here: http://upstart.ubuntu.com/cookbook/#run-a-java-application
<xnox> but that's without using a shell script.
<codelotus> right, I was able to get that example to work, i.e. putting the java -jar â¦ in the exec stanza 
<xnox> codelotus: i'd recommend to spawn as many process as needed and setup environmental variables in pre-start script / end script. And then in "script / end script" simply either source variables and do a single call to only start your app, such that you can run in foreground, or expect fork, or expect daemon. And correctly track the right pid.
<xnox> codelotus: see documentation about expect http://upstart.ubuntu.com/cookbook/#expect
<codelotus> so it is advised not to use a single *.sh script that does all of the init work and spawns the process?
<xnox> codelotus: no, because if it forks more than twice, you will not be able to track the correct PID to stop/respawn/reload/restart your daemon.
<codelotus> ahh, and that would be what I am doing wrong
<codelotus> thank you sir
<xnox> codelotus: Doing it like described in the first method here http://upstart.ubuntu.com/cookbook/#run-a-java-application
<xnox> codelotus: is the fastest and most reliable and secure way to run java apps under upstart.
<codelotus> xnox: I did it like that the first time, but then I tried to go down the exec /opt/app/myscript.sh route and began to smack my head against the wall
<codelotus> xnox: thank you, I'll go back to the run-a-java-application method and utilize the pre-start block
<xnox> codelotus: for the pre-start see for example: http://upstart.ubuntu.com/cookbook/#post-stop   in the pre-start multiple commands are executed, but the script stanza only sources variables and has the final "exec cmd..." that starts the daemon. This way the "expect fork" and "respawn" actually work correctly and restart/reload/stop work correctly as well.
<xnox> (job example under that section)
<codelotus> i see
<Diranged> Can I create a user-specific upstart directory and trigger those scripts to start or stop while inside that users shell?
<xnox> Diranged: yes, in saucy it's enabled by default. In raring it's optional. In quantal/precise there is a way to do it, but it was clunky and never advertised, but possible.
<xnox> Diranged: see http://ifdeflinux.blogspot.co.uk/2013/04/upstart-user-sessions-in-ubuntu-raring.html
<Diranged> interesting
<Diranged> thank you.. reading
#upstart 2013-06-13
<Cheery> xnox: you told me to look into initramfs yesterday.
<Cheery> or wait.. it was few days ago
<Cheery> in fact 4 days ago
<Cheery> so I did
<Cheery> now I've had little bit of time to put together a system. it took about a hour to figure out everything.
<Cheery> well.. it's not huge system.
<Cheery> http://bpaste.net/show/106915/
<Cheery> I gave it /etc/passwd, /etc/groups along that, and installed busybox into the directory
<Cheery> it sleeps a little so the kernel stops bothering with the messages.
<Cheery> I know the point of initramfs is not this though.
<Cheery> also I figure those kernel messages could go somewhere.
<Cheery> I'll try something more sophisticated tomorrow.
#upstart 2013-06-14
<xnox> Ctrl-Alt-T stop ENTER
<xnox> awesome trick I would never have thought would work in saucy =)
<xnox> but once one realises what it does, it becomes oh so obvious.
#upstart 2014-06-09
<xnox> "This paste has been removed!"
<ion> So has the user.
<jodh> xnox: hey - can you point me at one of the branches where we dropped state_only from job_process_terminated() ?
<xnox> jodh: one sec.
<xnox> jodh: https://code.launchpad.net/~xnox/upstart/dead-beef/+merge/220334
 * xnox but of course i've named it "dead-beef" instead of "drop-state_only"
<jodh> xnox: thanks. Time for a 0xC0FFEE !
<xnox> LOL =) i like it
#upstart 2014-06-10
<fluter> hi, I use expect daemon, but then I add exec mydaeomin in script block, it cannot track the right pid,
<fluter> anyone suggests?
<fluter> hello people
<fluter> hello people
<fluter> hello people
<xnox> fluter: "exec" cancels any expect, and tracks that pid.
<xnox> don't use exec, if you want to use expect daemon
<xnox> (inside script block that is)
<fluter> xnox, what is exec will track if no script block?
<xnox> fluter: exec outside script block is an upstart stanza, and will use expect correctly.
<xnox> fluter: exec inside script block is exec(1posix) which doesn't consider "expect" upstart stanzas.
<xnox> http://manpages.ubuntu.com/manpages/trusty/en/man1/exec.1posix.html
<xnox> vs
<fluter> xnox, because I have some setups before exec, so have to use script block
<xnox> can you pastebin your full job.
<xnox> ?
<fluter> xnox, sure, 
<fluter> xnox, http://sprunge.us/DMhP
<fluter> I use this, and the pid is wrong
<xnox> fluter: just remove "exec" word, and all should just work.
<xnox> fluter: why did you add exec, instead of just:
<xnox> script
<xnox> [ -f /etc/sysconfig/chunk_server_main ] && . /etc/sysconfig/chunk_server_main
<xnox> /usr/sbin/chunk_server_main  $CHUNK_SERVER_MAIN_OPTIONS
<xnox> end script
<fluter> xnox, I read the docs, it says exec is to run the command :) I read it wrong :(
<fluter> section for exec in upstart cookbook
<fluter> thanks a lot xnox 
<xnox> fluter: on it's own, not inside a script block, which is fed completely into "sh -c"
<fluter> xnox, another question, inside script, there are mutiple lines, which pid will upstart tracking?
<xnox> the first one.
<xnox> so e.g. sourcing /etc/sysconfig/chunk_server_main may not exec processes.
<fluter> xnox, that would be the [  ] one?
<fluter> xnox, /usr/sbin/chunk_server will fork twice  to become a daemon, witll that work?
<xnox> it should work.
<xnox> [ ] is not a process, but a shell builtin. Checked with strace against dash.
<fluter> xnox, I see
<fluter> xnox, I removed exec, but it still says the wrong pid
<fluter> xnox, initctl status says 1521, but ps shows it is 1523
<fluter> I think it got the pid before fork
<xnox> fluter: what's the pid you want to track, and what does "status job" say?
<fluter> xnox, status says "chunkd sttart/running, process 1521"
<fluter> but in ps, it is 1523
<xnox> fluter: did you follow http://upstart.ubuntu.com/cookbook/#how-to-establish-fork-count ?
<fluter> because it's the wrong pid, stop job will hang
<fluter> xnox, yes, the daemon fork twice, so I used expect daemon
<xnox> fluter: did you fully stop the job after modifying the config files?
<fluter> xnox, yes
<xnox> (as in initctl said stop/waiting)
<xnox> ok.
<fluter> xnox, I rebooted
<xnox> fluter: can you provide the strace.log ? is in http://upstart.ubuntu.com/cookbook/#how-to-establish-fork-count ?
<fluter> ok, 1 sec
<xnox> also try a basick job first http://paste.ubuntu.com/7622871/
<fluter> xnox, http://sprunge.us/LaUG
<fluter> xnox, it works, 
<fluter> the paste you gave, it tackes right pid, so I can start stop without hang
<xnox> fluter: what's the contents of  /etc/sysconfig/chunk_server_main ?
<fluter> some lines of NAME=VALUE paris
<fluter> pairs
<xnox> does it have any $(), `cmd` or commands that are executed ?
<fluter> xnox, no, it is all static shell variables
<fluter> hmm, if use script block, if only one line of /usr/sbin/..., it works,
<fluter> if I add . /etc/sysconfig/some config file, it does not work anymore
<fluter> I think source a shell file is the problem
<xnox> one option is to have two jobs
<xnox> in one job do:
<xnox> task
<xnox> script
<xnox> . /etc/sysconfig/chunk_server_main
<xnox> start chunk-server VAR1=$VAR1
<xnox> end script
<fluter> in the chunk-server job, it will get the VAR1 variable?
<xnox> yes.
<fluter> aha, ok
<fluter> let me try that
<xnox> so one job is a "sourcer/environment assembler", the other one just runs the daemon straight.
<fluter> xnox, start command will start it, but will it be started twice,
<fluter> when init says chunk-server in /etc/init 
#upstart 2014-06-11
<fluter> hi
<fluter> is there a tool to log and track all the events emited and handled by upstart and jobs?
<xnox> upstart-monitor
<gansbrest> hello. In my upstart scripts I often do the following /usr/local/bin/node /release/thanks-jetpack/current/bin/txjp >> /media/ephemeral0/logs/txjp_web 2>&1
<gansbrest> but now I'm trying to attach logrotate to that log file and trying to figure out how to cause upstart to reopen the file after rotation
<xnox> gansbrest: recent enough upstart, collects all stdout & stderr, and does log rotation
<xnox> into /var/log/upstart/$job.log
<xnox> gansbrest: so don't do that at all =)
<xnox> gansbrest: otherwise, you should use logger
<xnox> e.g. see $ man logger. I believe that correctly reopens files etc.
<gansbrest> xnox: you mean just keep  /usr/local/bin/node /release/thanks-jetpack/current/bin/txjp and upstart will do the rest?
<gansbrest> will it create 2 files, .out and .err?
<xnox> gansbrest: no single .log with both stdout & stderr.
<xnox> in /var/log/upstart/
<xnox> gansbrest: do you have /var/log/upstart/ on your system?
<xnox> or what's the output of $ sudo initctl version
<gansbrest> I think I'm out of luck here 
<gansbrest> init (upstart 0.6.5)
<gansbrest> very old version
<gansbrest> it's interesting that upstart is installed to amazon AMI seem like which is REHL and CentOS 
<gansbrest> I mean it's installed for us, someone installed it )
<gansbrest> I think logger may be an answer as you say
<gansbrest> or writing log directly from the app, and handle HUP signal cause by upstart reload
#upstart 2014-06-12
<fluter> hi
<fluter> is there a tool to log and track all the events emited and handled by upstart and jobs?
<xnox> fluter: please stay on irc
<xnox> fluter: i've answered before, but you left.
<xnox> fluter: there is upstart-monitor
<xnox> and one can also use dbus-monitor
<xnox> fluter: another option is to set $ initctl log-priority debug
<fluter> xnox, sorry about that,
<fluter> xnox, I'd like to see all event since system starts, 
<fluter> initctl will be late I think
<fluter> I will use upstart-monitor, thanks a lot
<xnox> fluter: you can specify "--debug" on kernel command line, then it will be honer from the start of upstart
<fluter> xnox, ah, that's great,
<fluter> let me try it
<jgornick> hey guys, if I start my application via start-stop-daemon, how can I run some script to stop the daemon when service my-service stop is called?
<xnox> jgornick: did you look into "pre-stop" stanzas?
<xnox> jgornick: in the cookboot
<xnox> jgornick: in the cookbook
<jgornick> xnox: Yes, but does that mean I should start-stop-daemon --start in the pre-start stanza and start-stop-daemon --stop in pre-stop stanza?
<xnox> jgornick: no, why?
<xnox> jgornick: pre-stop runs before killing the main pid.
<xnox> jgornick: if you want to do clean up after your daemon is killed, use "post-stop"
<xnox> (post-stop exec; or post-stop script/end script)
<jgornick> xnox: I think you just shed some light on how Upstart works.
<xnox> jgornick: it's all in the cookbook.
<xnox> jgornick: read about the job life-cycle and what happens after what.
<jgornick> xnox: Will do. Thank you!
<jgornick> xnox: Is it good practice to use start-stop-dameon with Upstart?
<detrout> I'm running upstart on debian testing/unstable and with kde and networkmanager. my laptop doesn't try to redetect network after changing locations while its sleeping.
<detrout> any suggestions on where to look to diagnose that?
<xnox> jgornick: usually no. but it's the last resort, if the daemon miss-behaves. (E.g. forks more than twice to reach the "main" process)
<xnox> detrout: as far as I understand that's unrelated to upstart, just pure network-manager debugging.
<xnox> detrout: and/or standard debian if-up / if-down scripts
<detrout> ok
<jgornick> xnox: Thanks for the insight. I've been able to get my application to start and stop gracefully now.
<xnox> jgornick: no problem
<detrout> i was wondering if upstart was missing the sleep/resume event and not triggering a reconnect
<xnox> detrout: upstart drops an if.up script to generate events. but it doesn't configure networking at all.
<detrout> where would the if.up script be?
<xnox> detrout: no, upstart doesn't do anything on sleep/resume. pm-utils handles that.
<detrout> ahh ok
<xnox> detrout: if up & down scripts are all in /etc/network/. Again it's not upstart, but rather standard debian.
<detrout> ok
<detrout> and to make sure i'm understanding it... pm-utils is responsible for triggering on the ACPI sleep resume events, it calls into debian ifup/down, 
<detrout> xnox: thank you for explaining.
<xnox> detrout: pm-utils is responsible, unless you are running under logind session management, in that case it does take over some functionalities - e.g. activies triggered by power button, etc.
<detrout> xnox: sid's network-manager pulls in libsystemd-logind
<xnox> detrout: it's best for you to seek support on #debian / #debian-devel on OFTC.
<detrout> Ok. thank you
<xnox> detrout: i'm not that involved in debian network / boot stacks. despite being a debian developer =)
<detrout> at least now I have a better idea why it worked when I was running systemd-sysv
#upstart 2014-06-13
<fluter> I have a service with depends on mongod, but when I added start on runlevel [345] and started mongod,
<fluter> the boot always hang
<fluter> but I can log into the system to see what's wrong, since there isn't a tty avaibale yet
<fluter> any ideas why the boot hangs?
#upstart 2014-06-15
<zfj> hi, i've got a question about an upstart with multiple dependencies
<zfj> i'm writing an upstart script for a job with dependencies on a database and a message bus
<zfj> i'm wondering if i can make the dependent script `start on DB && MB` or something like that
#upstart 2015-06-08
<SaintMoriarty> hello
<SaintMoriarty> I am trying to execute a command that needs sudo, but how is it going to handle the password portion?
#upstart 2015-06-09
<whatevs> Hi guys, I have a quick question I hope someone can help me with.  I have a box with multiple ethernet interfaces.  I want a service to start if any of the interfaces go up, and stop when ALL of the interfaces are down. I'm having trouble with that last part.  any ideas?
#upstart 2015-06-10
<jouk> noob here, I have an error in my /etc/init/foo.conf. I fixed the file, but when I try to "stop", the fix is not present. It looks like it's using a cached file somewhere
<jouk> How do I make upstart "reload" my new foo.conf?
<astrumas> jouk: Is this what you mean? http://upstart.ubuntu.com/faq.html#reload
<astrumas> Supposedly it should do it automatically, but looks like you can force it.
<jouk> hm, the problem is that the "stop" command does not work (that's what I fixed)
<jouk> so when I try to initctl reload, the same error occurs
<astrumas> Hmm... is it safe for you to kill the job the hard way?
<astrumas> Or even reboot the machine if thats possible in your environment, heh
<jouk> astrumas: what's the hard way?
<astrumas> initctl list, find your running jobs, "process XXX", where XXX should be the PID, then "kill XXX".
<astrumas> Essentially kill all the jobs that use that config and try to restart them.
<jouk> oh, yeah I can do that. let me give it a shot
#upstart 2015-06-12
<kshep> Hi folks... soo... what starts upstart? Trying to tshoot some ubuntu startup sequencing, and it looks like upstart services all start after all the sysvinit services
#upstart 2016-06-13
<slangasek> hallyn: formally, Keybuk never stopped being the maintainer of libnih in Debian; so you'd want to start there
<hallyn> hm, ok, thx.  not yet certain i'll do that rather than drop it :)  will think it over
<rhett> hi
<rhett> i just made a myservice.conf file in /etc/init/ do I need something in /etc/init.d/ ?
<AnrDaemon> â¦
<AnrDaemon> rhett: I just grew four legs and a tail. Do I need horns?
<supergonkas> Great answer 
<hallyn> slangasek: so just to be sure - you're saying upstream, not just in debian/ubuntu, upstart is not maintained, right?
<slangasek> hallyn: yes
<hallyn> was there any discussion on mailing list to seek volunteers?
<slangasek> hallyn: no
 * hallyn just wondering - decent chances noone would want to,
<slangasek> there hasn't really been much discussion on the upstream mailing list in approximately forever
<hallyn> :)
<hallyn> curse of a too stable code base
<hallyn> do a new release with a little off by one error in there
<slangasek> and with Ubuntu switching to systemd, seeking volunteers for maintaining it seems like opening the door for people to volunteer for things that aren't actually what they want :)
<hallyn> what do you mean by 'waht they want'?
<hallyn> the new ubuntu flavor i'm starting may be upstart based :)
<hallyn> (half joking - don't expect to have time for that)
<slangasek> heh
#upstart 2016-06-16
<ahri> i'm trying to force mysql to start after remote filesystems have been mounted (as i've moved /var/lib/mysql to an NFS share and left a symlink in its place). i altered /etc/init/mysql.conf so that: "start on (runlevel [2345] and started remote-filesystems)" but upon reboot the service is stuck in "mysql stop/waiting" - i'm on 14.04 LTS (but actually it's Mint)
<AnrDaemon> Do not edit tasks.
<AnrDaemon> Create .override if you want.
<ahri> oh, ok!
<ahri> will that make the execution order i want actually work, though?
<AnrDaemon> And MySQL will not start with moved datadir, becaus it is not allowed to read from any other places.
<ahri> um, running "service mysql start" or "start mysql" works fine
<ahri> obviously after mounting
<AnrDaemon> Then try mounted MOUNTPOINT=/xxx
<ahri> cool, i'll try that. can i selectively override with a .override file? i.e. only say "start on (runlevel [2345] and mounted MOUNTPOINT=/share)" in that file?
<ahri> also: "mounted" worked perfectly! thank you very much for that tip!
<ahri> now it's working i just need to revert that file and make the .override
<AnrDaemon> Of course. .override is read after main task definition, and any stanzas found in .override willâ¦ well, override stanzas in .conf.
<ahri> nice, upstart seems way neater than other solutions
<ahri> i've not really had much need to investigate this stuff before
<ahri> one last question: what should me "stop on" stanza be? i guess i want to stop mysql before that share is unmounted
<AnrDaemon> It's straightforward. >.> Translating initd job to upstart job often means you delete 90% of it, and then it just works.
<ahri> is there an "unmounting"?
<AnrDaemon> IDK. Probably not.
<AnrDaemon> http://upstart.ubuntu.com/cookbook/
<ahri> excellent, thanks a bunch
#upstart 2016-06-17
<bddy> Hi. One of my /etc/init/somename.conf daemons keeps starting in a chroot for some reason. Is it possible to somehow understand - from where does it take the chroot path and how to make it not chroot?
<AnrDaemon> bddy: If there's nothing suspicious in job definition file, it may have that functionality builtin. Check its documentation.
<bddy> AnrDaemon: Yeah, I'm reading source code now. Unfortunately can't debug easily since this is init 1 pid
<AnrDaemon> *facepalm*
<bddy> AnrDaemon: What do you mean?
<bddy> This is production server unfortunately and I can't kill it, neither reproduce :(
<AnrDaemon> You have misbehaving application - and you are debugging init daemon?
<bddy> AnrDaemon: chroot happens here: init forks, then it chroots, then execve()
<AnrDaemon> What?
<bddy> There is some chroot support in upstart - from the source code  Isee that it reads some xml stanza and gets "chroot" value from it
<AnrDaemon> If you don't specify chroot in your job file, it won't do it.
<AnrDaemon> And least of all it reads anything CML.
<AnrDaemon> XML**
<bddy> But it does it. :( see parse_job.c
<bddy> ah, this is another stuff, you are right, this is not xml
<bddy> hmm, for some reason when I do initctl reload-configuration, it goes to /home/name/chroot/etc/init/somename.conf and reads configuration file from there.
<AnrDaemon> Ok, first question: What OS version?
<bddy> Sorry, was away, OS is Ubuntu 12.04 precise, upstart is 1.5
<AnrDaemon> Then what you did to it? I have same OS, and nothing extraordinary happens to it. Whatever I try. (And I've tried many weird things in the past two weeks.)
<bddy> Ok, it was solved by kill -TERM 1
#upstart 2016-06-19
<blazeme8> Hail upstart. systemd sucks.
<AnrDaemon> Can you argument your last statement?
<blazeme8> AnrDaemon: the point of linux is customization, using lots of small swappable bits that work together. systemd is a bad idea because it is a monolith.
<AnrDaemon> That's not the "point", that was the philosophy thus far.
<AnrDaemon> But for distribution maintainers, it's easier to deal with one program, rather than many.
<blazeme8> semantics 
<AnrDaemon> My only two gripes with systemd is logging and syntax.
<blazeme8> and they should do what works best for users, not what works best for "upper management"
<AnrDaemon> I can't reanimate or investigate a dead system with systemd without another system with systemd.
<blazeme8> why is that?
<AnrDaemon> And syntax for tasks is justâ¦ Least user-friendly.
<AnrDaemon> Binary logs.
<blazeme8> Ah yes the logs drive me crazy hah
<blazeme8> text logs are for humans, lets put them in a binary format lol
#upstart 2017-06-13
<IOMonster> Hello all! Quick question about pre-stop scripts - is there a way to tell Upstart to not restart an app if it closes while the pre-stop script is running?
<IOMonster> as part of my pre-stop script i have to send a kill signal to the process upstart is supervising, and upstart sees the application end and restarts it
<IOMonster> (i'm using upstart 0.6.5, and trying to work around an issue where runuser only gives my application 2 seconds to clean up before it gets SIGKILL'd)
<IOMonster> so my pre-stop script sends a SIGTERM to the process upstart is supervising and waits for it to clean up
<IOMonster> y'know, nevermind. i just realized that i should be using "expect fork" so upstart doesn't track runuser's pid
<IOMonster> sometimes, the simple solution is the one you don't think of until you've done something the hard way :)
<AnrDaemon> IOMonster: I'm afraid it's a problem in your version.
<AnrDaemon> IOMonster: Also, if it is at all possible, don't run your applications in forking mode under supervising init daemons.
<IOMonster> AnrDaemon: indeed, the application isn't actually forking
<IOMonster> the script section does "exec runuser <blah>"
<AnrDaemon> WTF
<AnrDaemon> WHY?
<IOMonster> <blah> doesn't fork, it runs exec java
<IOMonster> hm?
<AnrDaemon> Just start daemon directly with upstart.
<IOMonster> unfortunately
<IOMonster> i need to run this as a user other than 'root'
<IOMonster> so, runuser is required
<AnrDaemon> DO THAT WITH UPSTART
<AnrDaemon> runuser is useless.
<IOMonster> no need for all caps :)
<IOMonster> upstart 0.6.5 doesn't have user options
<AnrDaemon> Then upgrade your shit already, it's well over six years.
<IOMonster> http://upstart.ubuntu.com/cookbook/#stanzas-by-category
<IOMonster> setgid is only 1.4
<IOMonster> unfortunately i'm not in control of the init version my OS is using
<AnrDaemon> $ init --version
<AnrDaemon> init (upstart 1.12.1)
<AnrDaemon> And it's a 4 years old version.
<AnrDaemon> Then use a different OS.
<IOMonster> yep, amazon linux is based off cent5, which is indeed ancient
<IOMonster> however
<AnrDaemon> LOL
<IOMonster> it's what i've QA'd
<AnrDaemon> Get a better hosting. Seriosuly.
<AnrDaemon> It's beyond stupid.
<IOMonster> changing OS just because upstart is ancient in this version isn't an option
<IOMonster> this isn't a hobby project
<AnrDaemon> The more stupid it sounds.
<IOMonster> haha
<AnrDaemon> If you are unable to use nromal, quality software, this is justâ¦ not sane.
<IOMonster> thanks for your input
<IOMonster> i am using quality software, it's been QA'd by myself and amazon ec2 engineers
<IOMonster> i'm not going to re-QA a whole OS just because i can't use a specific option
<IOMonster> if this was my home box, sure, i'd switch to fedora or something more recent
<IOMonster> but a full review of all configurations, applications, and even kernel modules would cost me time i don't have
<AnrDaemon> You know, what? Nobody is going to help you with extremely outdated, probably insecure versions of software.
<IOMonster> ok, i'm trying to be nice here, but seriously why are you so aggressive?
<IOMonster> i asked a question, answered it myself and wasn't rude
