#upstart 2007-01-09
<b0nn> hi all, Im trying to edit an upstart script, and I want to be sure of what I am doing before I break things :-)
<b0nn> I want to link one configuration file in runlevel 4
<b0nn> but I want to link a different configuration file in runlevel 5
<b0nn> with inittab I would have added these lines 
<b0nn>  lnk4:4:wait:/bin/ln -sf /etc/X11/xorg_vesa.conf /etc/X11/xorg.conf
<b0nn> and for runlevel 5
<b0nn>  lnk5:5:wait:/bin/ln -sf /etc/X11/xorg_radeon.conf /etc/X11/xorg.conf
<b0nn> is it possible to just paste those directly into rc4, and rc5?
<oblio> hello
<oblio> i have a question about upstart - how can i make restart automatically something?
<__keybuk> put "respawn" in the job definition
<oblio> respawn, thought so
<__keybuk> 52 revision(s) pushed.                                                         
<__keybuk> whee
<oblio> __keybuk: scott remnant, right?
<AlexExtreme> 52 revisions? :o
<_ion> keybuk: Wow. :-)
<_ion> oblio: /whois
<oblio> _ion: right, sorry :)
<AlexExtreme> is there any way to browse a bazaar repo in launchpad?
<_ion> 52 revision(s) pulled.
#upstart 2007-01-10
<Keybuk> interesting
<Keybuk> Jimmy has "quit" initNG
<Keybuk> and some fun stats
<Keybuk> development from scratch to 0.2.7 (which was in edgy)
<Keybuk>  62 files changed, 19961 insertions(+)
<Keybuk> development since then
<Keybuk>  68 files changed, 18083 insertions(+), 9995 deletions(-)
<pkt> hi Keybuk
<Keybuk> hihi
<pkt> how is progress on upstart scripts?
<Keybuk> pkt: for feisty?  we haven't formally begun them yet, though they're all mapped out
<pkt> ah, ok
<pkt> I 'm hoping to use upstart for my private (LFS-based) distro
<Keybuk> current timeline
<Keybuk> 0.3.2 today if I can
<Keybuk> that fixes all of the "rushed" code in 0.2.7, and introduces a stable IPC layer, etc.
<pkt> nice to hear that :-)
<Keybuk> then I start on the proper features listed in the wiki for the 0.3 milestone
<Keybuk> https://launchpad.net/upstart/+milestone/0.3
* pkt looks ...
<Keybuk> most of those make changes to the job structure that we wanted to do the startup scripts
<Keybuk> so I hope to have those done over the next week or two after 0.3.2
<Keybuk> leaving a few weeks to do the boot scripts themselves
<pkt> ah, ok so you suggest to take a look again in a few weeks correct?
<Keybuk> so the first run of those should be done by Feb 8th
<pkt> btw, have you looked at depinit?
<Keybuk> no, URL?
<pkt> wait a sec ..
<pkt> ha! found it http://www.nezumi.plus.com/depinit/
<pkt> It has some interesting features
<pkt> like using different signals to stop daemons and shells
<pkt> reliable loggers (from daemontools) etc
<pkt> of course it is primitive and never had a development community with size > 1
<pkt> but it has some nice ideas to get inspiration from
<Keybuk> never seen that one before
<pkt> mostly only old LFSers know about it
<pkt> btw, the author released a newer version and probably forgot to update the page
<pkt> so the last (known to me) version is probably http://www.nezumi.plus.com/depinit/depinit-0.1.5.tar.bz2
<Keybuk> tbh, from a glance at the features list, there's not much there that'd be useful to us
<Keybuk> a lot of it is to do with being a dependency-based init system, which upstart is expressly not
<pkt> well some of its "side" features are interesting
<pkt> like pipelines between daemons for reliable logging
<pkt> I 'll probably try to port some of the interesting stuff to upstart
<pkt> (assuming I 'm able to base my system on it first)
<Keybuk> yeah, that bit's kinda interesting
<_ion> Would 'state' work as the 'FOO'?
<_ion> It's somewhat ambiguous, admittedly.
<Keybuk> "the 'FOO'" ?
<_ion> https://lists.ubuntu.com/archives/upstart-devel/2006-December/000200.html
<AlexExtreme> hrm
<AlexExtreme> Keybuk, what was the alternative to the Profiles spec?
<Keybuk> Flags
<Keybuk> there's no spec for that one yet
<AlexExtreme> and what did it involve? passing parameters on the kernel command line?
<Keybuk> profiles, iirc, involves defining lists of jobs either by include or exclude
<Keybuk> so you'd have the "with networking" profile which would include jobs that are excluded by the "without networking" profile,e tc.
<Keybuk> those profiles would have to be defined elsewhere
<Keybuk> they're a bit like existing runlevels, or initng goals
<Keybuk> and would have to be maintained by hand
<AlexExtreme> yes, I wrote a spec for that
<Keybuk> *nods*
<Keybuk> Flags was an alternate idea
<Keybuk> they'd be states that were either up or down, and set by the kernel by default
<Keybuk> uh, kernel command-line
<Keybuk> obviously ;p
<Keybuk> so you could have a networking flag, a multi-user flag, etc.
<AlexExtreme> I'd definitely prefer the profiles idea
<Keybuk> jobs can then say "if FLAG" or "unless FLAG"
<Keybuk> the advantage to flags is they're more flexible
<Keybuk> FOO (network-up until network-down if networking) or if multi-user
<AlexExtreme> but, when we write a gui to configure upstart, it would have to detect which bootloader is in use and modify it's configuration file
<AlexExtreme> to set the kernel command line
<Keybuk> ah no :)
<Keybuk> flags are just command-less jobs
<Keybuk> so there's an /etc/event.d/networking that has "start on startup" in it
<Keybuk> or something like that, anyway
<Keybuk> which flags were up or down is the only thing dictated by the kernel command line
<Keybuk> which is the same with profiles; which profile you're in is dictated by the kernel command line
<Keybuk> the difference is the method of inclusion of jobs into them
<Keybuk> profiles is defined by seperate files
<Keybuk> flags are defined within the job file
<AlexExtreme> mmm
<AlexExtreme> you've lost me :)
<Keybuk> heh
<Keybuk> I need to write the spec
<Keybuk> or wasabi does :p
<Keybuk> I don't particularly favour or disfavour either of them
<AlexExtreme> i'd certainly prefer profiles
<wasabi> Hmmm.
<wasabi> lemmie load that back into my head
<wasabi> it's long been swapped out
<wasabi> I think I have a natural tendency to suport, as much as possible, alterting the obvious parts of the configuration without modifying the job files themselves.
<wasabi> modifying the job files themselves introduces an upgrade issue.
<wasabi> Hmm. Cept that isn't an issue.
<wasabi> HMMM.
<AlexExtreme> Well, flags would require some modification of job files, definitely
<wasabi> So, a flag would be a job named 'flag-networking' or something.   And the actual network scripts would define a level between flag-networking started and flag-networking stopped
<Keybuk> if profiles are stored in a configuration file, then that still has the same upgrade issue
<Keybuk> you'd end up with conflicts modifying /etc/bootprofiles
<wasabi> Then you could use hte kernel commad line to make the system boot into a state where flag-networking is "started"
<Keybuk> if they were directories of symlinks, otoh ...
<wasabi> Which is an unnatural state, as nothing starts flag-networking, ever, except that.
<wasabi> Yeah, Keybuk, that's why I just now realized it was a non-issue.
<wasabi> I don't think we want users modifying profiles.
<AlexExtreme> but what if they want to disable services?
<wasabi> I think they'll end up being more of a tool for us.
<wasabi> like safe-mode is for windows.
<Keybuk> AlexExtreme: define disable
<Keybuk> does disable mean that "start JOB" will return "DISABLED"
<AlexExtreme> stop a service from starting
<wasabi> Maybe disabling services BY THE USER, is a completely seperate act from defining run states.
<Keybuk> or does it mean it's just not started by its usual events?
<Keybuk> and that a sysadmin can still start it manually?
<AlexExtreme> yes they could still start it manually, just wouldn't be started at boot
<wasabi> How are we with adding a "disabled" line-item to the job definition?
<wasabi> And making an installer merge?
<wasabi> Which is what we already have I think.
<wasabi> And defining boot profiles using distro-supplied files.
<wasabi> Such as extra jub definitions.
<wasabi> lemmie write that out once.
<Keybuk> that makes adding disabled equivalent to commenting out the start events :)
<AlexExtreme> basically, all I'm concerned about is having a system where you can stop services from being started at boot
<Keybuk> both are job file edits
<Keybuk> something in SMF(?) I liked ...
<Keybuk> if you list jobs on the kernel command line, they're started at boot automatically
<Keybuk> if you list them with "!" in front, they're not started
<wasabi> Okay, lets wait a second, we have one up front question we need to clear up.
<wasabi> Should we EXPECT< during normal OS operation, the user to edit the distributed job files to change stuff. If yes: are we willing to take care of that during hte upgrade procedure.
<wasabi> There's not much doubt in my mind that "turning off a service" is normal OS operation.
<wasabi> And I suspect we'll have lovely and wonderful UI's that do it in the future.
<Keybuk> I think that normal users will likely only want to disable or enable services/tasks
<Keybuk> advanced users may wish to configure when services/tasks are run
<Keybuk> and advanced users may also wish to modify them
<wasabi> Yes, we need to plan for the normal use case.
<AlexExtreme> yes
<wasabi> Some guy sitting down at his server and flipping a switch to turn off apache.
<wasabi> That seems pretty understandable to me.
<wasabi> If apache is configured wrong, that's a bug.
<wasabi> Or if it starts at the wrong times so he has to edit the files, it's a bug.
<wasabi> (or a missing feature)
<wasabi> So, if we put "disabled" in the job file, we commit to making the upgrade scripts detect and remember it.
<AlexExtreme> But I don't think editing the job file is the best way of doing it
<wasabi> I'm unsure if it is. Adding one line "disabled" isn't the hardest thing to build a merge for.
<AlexExtreme> If there was a line that could be added in the job file, 'required', then that job would always be started, for example in udev's job file. Then anything that hasn't got required in could be overridden. Having a line like '!foo' in say, /etc/bootprofiles, under a profile section would disable foo in the profile it's listed under
<Keybuk> why is udev required?
<AlexExtreme> it was just an example ;)
<wasabi> one thing at a time. Are we going to merge job files? :)
<Keybuk> wasabi: I tend to think that needs human intervention
<AlexExtreme> It'd certainly be easier not to
<Keybuk> e.g. user adds "limit core 0 0", distro adds "limit core 100 100"
<Keybuk> you need a human to resolve that
<wasabi> Yup. I mean, we can merge SIMPLE stuff.
<wasabi> We could merge "disabled", and prompt on anything else.
<wasabi> if disabled in old; if !disabled in new; add disabled to new
<AlexExtreme> Prompting wouldn't be good, there are distros (including Frugalware) that don't like having the upgrade process interactive
<wasabi> Prompting would only happen if the user changed stuff manually.
<wasabi> Other than disabled.
<AlexExtreme> It'd make 'update-manager -d' more difficult, too
<Keybuk> Ubuntu forbids prompting also
<Keybuk> (well, where the user didn't change anything)
<wasabi> Prompting in ALL cases? Even if the USER went in and edited a text file?
<wasabi> Okay. Heh.
<wasabi> I would be fine with disabled being in the job files, and handled silent during upgrade.
<wasabi> I think that's fairly easy to do.
<wasabi> So, that takes care of the user being able to disable services from some UI of some sort.
<wasabi> On to profiles. Who are these for?
<wasabi> I don't, or can't yet see, any reason to support allowing users to write their own profiles.
<wasabi> I suspect we'll just want to use these to drive out stuff like a Safe Mode boot prompt.
<wasabi> Where X doesn't start, and maybe no networking or something.
<AlexExtreme> Hmm.
<wasabi> I think at it's simpliest this could be accomplished by letting the distro define a few items they want to provide to their users, no X, no network, etc... and implement those in the job files THEY distribute.
<wasabi> And I think as Keybuk mentioned earlier, these are actually just flags.
<AlexExtreme> All the examples I came up with in my head for using profiles can be solved with events :p
<AlexExtreme> Gotta disappear for half an hour, bbl
<wasabi> These don't HAVE to be anything more than a set of flags which a service can choose to check to disable itself.
<_ion> Switch to libelektra and forget about any problems with syncing config files. ;-)
<Keybuk> that looks a lot like gconf
<Keybuk> which has the same problems :p
<Keybuk> and it used leverage on the first paragraph of its website
<Keybuk> hmm, there's nothing there that eliminates upgrade issues that I can see?
<_ion> I was under the impression that there would be a system config tree (parts of which would be updated when upgrading software) and a user config tree (corresponding to /etc) which would override key/value pairs in the system config tree, but maybe i remembered wrong; i don't seem to find such information from the website.
<Keybuk> yes
<Keybuk> so then you update the system config tree
<Keybuk> but if the user has logged in and used the app, they'd be using the user config tree instead
<Keybuk> so wouldn't get the change
<Keybuk> cf. gconf
<_ion> If that happens, the system hasn't been designed correctly.
<_ion> If root disables a certain job, the only thing that should be added to the user tree would be the "disabled" key.
<Keybuk> bzzt
<_ion> Not a full copy of the settings from the system tree.
<Keybuk> that way lies madness
<Keybuk> because now you have an application that has to handle BOTH v1 and v2 config keys
<Keybuk> which may have different formats
<Keybuk> in fact, it has to handle every possible combination of every possible key it's ever used
<Keybuk> also
<Keybuk> what user doesn't open up every preference dialog for a look at some point or other?
<Keybuk> if you only write when the user toggles ... do you delete the key from the user tree if they put it back to the default?
<Keybuk> AND to make matters worse
<Keybuk> if you don't copy the entire tree
<_ion> Valid points.
<Keybuk> you now have the "I configured my app, was perfectly happy with it, AND AN UPGRADE CHANGED THE WAY IT WORKED!!(*"(*(*" problem
<Keybuk> simply because the user didn't look at that page, or didn't toggle that option on/off, ect.
<Keybuk> difficult problem :p
<_ion> So it seems that whatever we do (re: the "updated config file" issue, out of upstart's context), we lose. :-)
<_ion> Every path seems to have compromises.
<AlexExtreme> back
<AlexExtreme> All I can say is that we simply add a file in /etc containing a list of services that the user *doesn't* want to start, and upgrade wouldn't touch that. The file would be updated by a config gui or by a command line tool like gentoo's rc-update.
#upstart 2007-01-14
<chillywilly> is it possible with a server running edgy to see pass/fail results of each job on boot up like it shows in /var/log/boot ? Or is it assumed you will just look at /var/log/boot to see what might've failed on boot up?
<chillywilly> cause on a server I could care less about a fancy splash screen and I am more concerned with whether services started up like they are supposed to
<chillywilly> but I also don't like all the extra noise remove "quiet" from the kernel params causes....I just want to see the services messages and their ok/fail statuses
<chillywilly> removing*
<chillywilly> seems when I remove quiet but leave splash I almost get what I want but some of the messages never show me an "ok"
<chillywilly> and I definitely do not get the same output as I see in /var/log/boot
#upstart 2008-01-08
<sadmac> Is Mr. Remnant here? By what name does he go on IRC?
<ion_> Keybuk
#upstart 2008-01-09
<sadmac> Ahh, lets try again, and hope not for a sudden power outage.
<sadmac> Is Mr. Remnant here?
<ion_> Not at the moment.
<sadmac> ion_: could you recommend an email to reach him by (specifically Re: upstart)?
<ion_> The mailing list, or scott@netsplit.com
<sadmac> thanks
<foolano> hi
<foolano> any example of managing apache 1.3.x with upstart?
#upstart 2008-01-10
<Gadi> can somebody tell me if I can make an event file similar to control-alt-delete but keyed off of a different key combo?
<Gadi> (like kbrequest in inittab, keyed off of alt-uparrow)
<foolano> hi again
<foolano> have you ever  tried to manage apache 1.3 with upstart?
<foolano> i'm experiencing some issues
<Keybuk> no
<Keybuk> not yet
<Keybuk> what issues are you experiencing?
<foolano> well
<foolano> if i launch apache without -F, it's started it correctly
<Keybuk> what does -F do?
<foolano> but it can't be stopped
<foolano> foreground
<foolano> if i launch it with -F
<foolano> start apache-perl never returns
<Keybuk> no idea, sorry
<Keybuk> I don't know apache 1.3 well enough
<foolano> i used -F when i used runit to manage it
<foolano> is there any option in upstart i can try?
<foolano> cuz the only option related to this in apache is -F
<foolano> which is intended for supervisors
<mbiebl> foolano: what do you mean by "it can't be stopped"?
<Keybuk> right
<Keybuk> -F sounds like the right option to me
<foolano> the problem with -F is what i said
<Keybuk> what's "start apache-perl" ?
<Keybuk> oh
<Keybuk> you ran that on the command-line?
<foolano> yep
<foolano> that's it
<Keybuk> (you named the job "apache-perl" not "apache"? :P)
<Keybuk> did you include "service" or "respawn" in your job definition?
<foolano> just exec
<foolano> right
<foolano> with respawn
<foolano> works just ok
<foolano> :)
<Keybuk> the default behaviour in Upstart for jobs is that they are tasks, not services
<Keybuk> (since that's less destructive)
<foolano> ok i c
<foolano> my bad
<foolano> thanks a lot :)
<foolano> i thought respawn was just to rerun the job in case it exists
<Keybuk> right
<Keybuk> that's what it does
<Keybuk> it also implies "service"
<Keybuk> if you don't want it respawned, use "service" instead
<foolano> i want it respawned
<foolano> great
<foolano> :)
<foolano> thx again guys
#upstart 2008-01-11
<joshk> Keybuk: is there a way to force a rc script to run in the foreground?
<joshk> example: I'm installing a fully automated ubuntu on VMware and I have it so that rc.local triggers an installation of the vmware tools
<joshk> but upstart lets that run in the bg
<joshk> so it just drops to a login prompt (I disable X for the installation as well)
<joshk> and that's kind of awkward for users who will be wondering wtf is going on
<Keybuk> define foreground
<joshk> Keybuk: i just want it to be the last thing the user sees in the init messages, and not go to a login prompt
<joshk> easy way to describe it is.. as if ubuntu was using sysvinit and i had put the same stub in rc.local
<joshk> it would say "Please wait, installing tools" and not show the login prompt
<Gadi> hey, there, all!  I am trying to write an upstart script similar to control-alt-delete but for a different key-combo
<Gadi> is there a way to do this?
<Gadi> I am unclear as to where c-a-d gets the actualy keystroke event from
<Keybuk> the kernel
<Keybuk> it's specially handled
<Keybuk> when you press Ctrl-Alt-Del the kernel sents init SIGINT
<Gadi> ah
<Keybuk> (and I think the only reason the kernel traps it is because it's an interrupt on a PC)
<Gadi> is there anyway to implement the old inittab's kbrequest?
<Keybuk> "on kbdrequest"
<Keybuk> that's Alt-UpArrow, and support for it is likely compiled out of your kernel
<Gadi> :(
<Gadi> really?
<Gadi> damn
<Gadi> well, I'm on gutsy
<Gadi> sotck kernel
<Gadi> I sppose its worth attempting
<Keybuk> what are you trying to do? :)
<Gadi> execute a command at the console based on alt-uparrow ;)
<Gadi> is there a way to load a newly written upstart script (short of rebooting)
<Keybuk> they load automatically
<Gadi> ah
<Gadi> then, it doesnt quite work :)
<Keybuk> it doesn't?
<Keybuk> which bit?
<Keybuk> does "status JOBNAME" show anything?
<Gadi> start on kbdrequest
<Keybuk> right, your kernel probably doesn't have kbdrequest support
<Gadi> exec echo "Alt-Uparrow pressed"
<Gadi> right
<Keybuk> did you have "console output" in there too?
<Gadi> no
<Gadi> before exec?
<Keybuk> so where's that echo going to go? :)
<Gadi> (sorry - upstart newbie :) )
<Gadi> still doesnt work
 * Gadi wonders why kbdrequest was not compiled in 
<Gadi> and whther to patch the kernel just for this :)
<Gadi> s/patch/recompile/
<Keybuk> hmm
<Keybuk> looking at the kernel it's always compiled in
<Keybuk> I just can't figure out what key it's bound to
<Gadi> hmm
<Gadi> ah, maybe /etc/console/ is just not set right
<Keybuk> maybe
<Keybuk> check for KeyboardSignal in your key map
<Gadi> hmm its there:  alt keycode 103 = KeyboardSignal
<Keybuk> and keycode 103 is set to?
<Gadi> Up
<Keybuk> should work then
<Keybuk> if not, you're deep into the mysteries of the console
 * Keybuk has never got it to work
<Gadi> heh, I used to do it all the time with inittab
<Gadi> on Dapper :P
<Gadi> pre-upstart
<Gadi> u sure I dont need to reboot?
 * Gadi reboots for the heck of it
<Keybuk> try upstart on dapper
<Keybuk> it doesn't work for me on sysvinit either
<Keybuk> we changed the console layer a *lot* in edgy
<Keybuk> (switched to using X keyboard maps)
<Gadi> ah
<Gadi> ok, I will play a bit
<Gadi> otherwise, I'll workaround
<Gadi> thanks for guiding a poor newb
<ion_> Phew. I finally got around to wiring my rack today. About fifty cables connected. :-)
#upstart 2008-01-12
<ion_> rning
#upstart 2009-01-05
<sadmac> Keybuk: good morning
<Keybuk> morning
<Keybuk> happy new year
<sadmac> Keybuk: you too
<sadmac> Keybuk: just pushed events-related code to my state machine prototype
<sadmac> Keybuk: so what's up with that secret kernel patch? :)
<ion_> I want to know, too
<Keybuk> I posted it to lkml already
<Keybuk> http://lkml.org/lkml/2008/12/27/80
<Keybuk> (patch is in my in-reply-to message)
<sadmac> Keybuk: ah. I misthunderbirded
<Keybuk> misthunderbirded?
<Keybuk> v. to use the wrong mail client
<Keybuk> ? :p
<sadmac> probably the case
 * Keybuk likes the fact the objections to that patch all come from @redhat.com :p
<sadmac> Keybuk: well it is lkml :P
<Keybuk> as I keep pointing out, if we do so well, you guys give up - we're *screwed*! :p
<sadmac> heh.
<sadmac> Keybuk: well, now that I've implemented large chunks of the state machine, I've found it to be even less quirky and more simple than I thought.
<sadmac> I've been able to nudge out a lot of the semi-strange behavior.
<Keybuk> you've been working during the break, haven't you? :p
<Keybuk> that's naughty
<sadmac> Keybuk: well, I became almost totally noctournal. Nobody's around to party with between 3 and 7am
<Keybuk> odd
<Keybuk> I returned to something like normal UK waking hours
<sadmac> heh
<soren> Keybuk: I'm looking at that patch, and can't help but wonder if there's a mechanism for reparenting a process to a different process than pid 1?
<sadmac> soren: check the clone() manpage. I almost want to say I saw something like that in there
<sadmac> I might be thinking of the option to signal the parent with something other than sigchld though
<sadmac> the most fun part of my waitfd patch: read returns ECHILD
<sadmac> took a bit to convince myself that was legal
<soren> Keybuk: I understand that if it only works for init, the code would just never be triggered if another process has done the PR_SET_ADOPTSIG thing, and that there's no particular reason to hardcode anything like that, but still it left me wondering.
<Keybuk> it's the same mechanism
<Keybuk> that's why the 1 isn't hardcoded, but uses a child_reaper variable
<Keybuk> you'd generally not use SIGCHLD for that notification, since they're not queued
<Keybuk> you'd use SIGRTMIN+n
<soren> I don't think I get it. How can a process other than init adopt a process?
 * sadmac wonders what happens if you clone with CLONE_PARENT from init...
<Keybuk> soren: you're forgetting that in Linux, threads are just processes :p
<Keybuk> so when a thread parent dies, it's reparented to another thread in the same group, not init
<Keybuk> sadmac: init's ppid is 1, so nothing - you get a child of init
<sadmac> Keybuk: I was goig to mention that, but I think he wanted to know if there was a way to explicitly set where a child will be reparented
<sadmac> Keybuk: ah
<sadmac> Keybuk: what about unices like (I think) HPUX that display a system_idle process with pid 0
<sadmac> does that not appear as the parent of anything?
<Keybuk> does HPUX even have clone() ? :p
<sadmac> nobody has clone
<sadmac> that's just us
<Keybuk> so who cares? :p
<sadmac> someone at HP I'd imagine
<Keybuk> Upstart doesn't work on HPUX, so EOFFTOPIC :p
<sadmac> Linux also has a system idle process of a kind I believe, but it doesn't appear in ps.
<sadmac> it may not be a "process" of any real sort.
<Keybuk> actually, I'm lying
<Keybuk> init has a ppid of 0
<sadmac> ah. thought so
<sadmac> graphs with loops feels very un-unix
<Keybuk> Linux has kernel threads, they are all children of kthreadd
<Keybuk> which is pid=2, ppid=0
<sadmac> ah
<Keybuk> we looked
<Keybuk> summary
<Keybuk> "Don't do that then"
<Keybuk> it'd be ok until the clone exited, at which point you'd maybe get an OOPS or a PANIC :)
<sadmac> add that to the list of "things to make an intern patch when you're bored"
<sadmac> yeah, I could see that reading as an init crash
<sadmac> There's something kind of sad about all of APL being in unicode
<sadmac> not quite as sad as the klingon alphabet, but still...
<Keybuk> APL?
<sadmac> Keybuk: "A Programming Language"
<Keybuk> what's wrong with unicode?
<sadmac> Keybuk: there's nothing wrong with unicode per se
<sadmac> Keybuk: APL has no textual commands
<sadmac> Keybuk: its all symbols. some greek ones, some not even in any alphabet
<Keybuk> ah, how silly
<sadmac> Keybuk: its the esoteric programming language that saw production time
<sadmac> Enterprise Brainfuck
<sadmac> Keybuk: it was reeeeely good at matrix operations, which was good for getting certain tasks done in a hurry.
<sadmac> http://en.wikipedia.org/wiki/File:LifeInApl.gif
<sadmac> ^^conway's game of life
<Keybuk> does it use the Unicode Interrobang character as an exception operator?
<sadmac> dunno. It predates unicode by about 30 years, so it wouldn't have drawn the inspiration from there
<Keybuk> n < 2 â â
<ion_> Thatâs not an interrobang.
<sadmac> N is less than 2 implies WTF
<Keybuk> 1 + 1 â  2 â â¼
<Keybuk> ion_: yes it is?
<ion_> â½
<sadmac> â¸
<sadmac> where is your god now?
<Keybuk> ah, right
<Keybuk> we can use utf-8 in C now, right ?
<ion_> What i still donât know is why Unicode has white smiling and frowning face, but only a black smiling face.
<ion_> faces
<sadmac> ion_: I blogged on this once
<ion_> Oh
<sadmac> ion_: http://screwyouenterpriseedition.blogspot.com/2008/02/worst-of-unicode.html
<ion_> Yeah, just found it with google.
<Keybuk> most of Unicode's symbol characters are inherited from other standard sets
<Keybuk> I mean
<Keybuk> you're talking about a character set that has an entire code block reserved for "Byzantine Musical Symbols" and you're complaining about its smiley faces
<sadmac> Keybuk: I believe I did mention the klingon alphabet earlier
<sadmac> Keybuk: and there are musical instrument companies open today that were around during the byzantine empire
<sadmac> (World's oldest corporation: Zildjian)
<Keybuk> Unicode doesn't have space for Klingon
<Keybuk> that's nowhere near the oldest company!
<Keybuk> there are European breweries older than that! :p
<sadmac2> Keybuk: when does fork return EBUSY?
<sadmac2> or whatever equates to Resource temporarily unavailable
<Keybuk> memory limits, process limits, etc.
<sadmac2> hmm
<sadmac2> left my workstation running over the break
<sadmac2> and my login session appears to be unwell
<sadmac2> heh, the whole python state machine is 390 lines
<sadmac2> I have a real desk now!
<sadmac2> Keybuk: what do you think the interface for waitfd should look like?
<Keybuk> waitfd(flags)
<Keybuk> gives you an fd
<Keybuk> you read() something like siginfo_t with all the expanded status information
<sadmac2> Keybuk: its more the list of pids to wait on that concerns me
<Keybuk> how do you mean?
<sadmac2> Keybuk: do you always want to wait on /all/ children with waitfd, or do you want some of the selection power that you have with waitpid&co
<sadmac2> Keybuk: and if so, what replaces the wait on just one process mechanic? it doesn't make much sense for this case
<sadmac2> but waiting on a few specific ones might
<Keybuk> I figured you'd  use something like the waitid() syntax
<Keybuk> waitfd (P_PID, pid, 0)
<Keybuk> waitfd (P_ALL, 0, WEXITED | WSTOPPED)
<Keybuk> type thing
<Keybuk> but then I'm about the only person in the world who even knows about waitid() :p
<sadmac2> Keybuk: yes, but say I want to wait on pid 3, 4, and 7, but not 5,6,whatever else
<Keybuk> fd = waitfd (-1, P_PID, 6, WEXITED);
<Keybuk> err
<Keybuk> fd = waitfd (-1, P_PID, 3, WEXITED);
<Keybuk> waitfd (fd, P_PID, 4, WEXITED);
<Keybuk> waitfd (fd, P_PID, 7, WEXITED);
<Keybuk> ?
<Keybuk> signalfd-style?
<sadmac2> Keybuk: if that's ok with everyone
<sadmac2> Keybuk: right now it has waitpid's signature
<Keybuk> I don't really like the whole "read an int and figure it out" type approach
<Keybuk> that int is squashed from a siginfo_t-style struct in the first place
<Keybuk> why not just read that struct?
<sadmac2> Keybuk: I didn't use waitid because it doesn't return a different status if it errors out due to WNOHANG, so you have to zero the return struct and then test
<sadmac2> Keybuk: and I need to check this from /inside/ the kernel in places.
<sadmac2> Keybuk: but I think all of this was in the name of not having to add crap to exit.c, and I think I've had to do that already anyway
<sadmac2> there goes my laptop
<sadmac2> IRC > Nagios
<Keybuk> sadmac2: err, isn't the point that read() returns you that status now ? :P
<sadmac2> Keybuk: poll() was the issue
<Keybuk> you don't *have* a WNOHANG flag with waitfd
<Keybuk> instead you make the socket blocking/non-blocking
<Keybuk> and read() returns EAGAIN
<sadmac2> Keybuk: I use WNOHANG for poll
<Keybuk> why?
<sadmac2> Keybuk: check if something exited with WNOHANG+WNOWAIT. If it didn't, poll_wait, if it did, return
<Keybuk> oh, I see
<sadmac2> Keybuk: you do have a WNOHANG flag with waitfd
<sadmac2> Keybuk: WNOHANG == O_NONBLOCK
<sadmac2> I've allowed it, and its cheap enough that I'm going to keep on allowing it
#upstart 2009-01-07
<sadmac2> Keybuk: Ingo Molnar seems to like the waitfd idea.
<sadmac2> which is good because Alan Cox doesn't, and I'd rather not fight my way upstream against that
#upstart 2009-01-09
<mcarter> hello
<mcarter> in an upstart job, how can I specify the user to run the job as?
<keesj> don't know 
<plundra> mcarter: I don't think there is a built in way.
<plundra> mcarter: I'm using 'sudo -u user cmd' 
<plundra> "chdir /some/where", "exec sudo -u foo ./app" 
<plundra> Anyway, I came here with a question! :-D What's the best way to restart stuff? Make a script that is invoked by emitting something fancy?
<plundra> Or using ... stop ... ; ... start ... manually.
<Keybuk> there's a restart command?
<plundra> Not with initctl in 0.3.9 (I'm using the latest Ubuntu LTS release)
<plundra> So I guess it was added in 0.4.x or 0.5.0, darn it :-D
<Keybuk> ah, no there's no restart there
<Keybuk> stop && start is as close as you can get
<Keybuk> though that's not entirely atomic, it's close enough
<plundra> Yeah, but it will do. Thanks anyway :)
<keesj> when I do "stop on starting service_xxx"  in service_yyy and I start service_xxx. the service_xxx is not waiting for the service_yyy to stop
<keesj> is there a wait around this?
<keesj> to be stopped 
<Keybuk> err, it should
<keesj> I am not sure what is indened. the reverse "start on starting an_other_service" does wait
<Keybuk> which version of Upstart
<keesj> so if (a = start on starting b) and I start B b will only reach started once a i staterd
<keesj> 0.3.9
<keesj> Ok at leat I now know what is indened. I only discovered this recently because the stop script wat taking very long
<Keybuk> WFM here
<Keybuk> quest event.d# cat test-stopper
<Keybuk> stop on starting test-starter
<Keybuk> service
<Keybuk> post-stop script
<Keybuk>    sleep 5
<Keybuk> end script
<Keybuk> quest event.d# cat test-starter 
<Keybuk> service
<Keybuk> -- 
<Keybuk> quest event.d# status test-stopper   
<Keybuk> test-stopper (start) running
<Keybuk> --
<Keybuk> quest event.d# start test-starter | ts
<Keybuk> Jan 09 11:16:54 test-starter (start) waiting
<Keybuk> Jan 09 11:16:54 test-starter (start) starting
<Keybuk> Jan 09 11:16:59 test-starter (start) pre-start
<Keybuk> Jan 09 11:17:00 test-starter (start) spawned
<Keybuk> Jan 09 11:17:00 test-starter (start) post-start
<Keybuk> Jan 09 11:17:00 test-starter (start) running
<Keybuk> note the 5s delay
<keesj> yes, the problem is probably a little more complex , I just wrote about the same test and it "works"
<keesj> what is ts?
<Keybuk> timestamps its input?
<keesj> I see
<keesj> while read i ; date -n ; echo $i ; done
<keesj> somethine like that :p
<Keybuk> indeed
<keesj> something like that , sorry for the spam
<Keybuk> it's in moreutils in Debian/Ubuntu
<keesj> 113 lines of perl :p
<ion_> Well, its sloccount is 62. :-)
<sadmac2> notting: so what do we do about 450488?
<sadmac2> I vote kill telinit u support
<notting> 1) fix it to translate job state
<notting> 2) fix it so it ignores 'u'
<notting> (*accepts the argument, but ignores it)
<sadmac2> 1 isn't productive because the damn code isn't sitting still long enough
<Keybuk> telinit u?
 * Keybuk tries to remember his sysvinit
<Keybuk> that's "reload configuration *and make changes to running state*" isn't it?
<Keybuk> oh, no
<Keybuk> telinit u is reexec
<Keybuk> I thought you implemented that one?
<Keybuk> I remember seeing some very very amusing code that had initctl send a special message to upstart, had upstart receive and process that message; and then just send itself SIGTERM
<notting> it loses track of job state
<Keybuk> oh
<Keybuk> that's just a general "not yet 1.0" bug ;)
<Keybuk> I fully intend to have state passing working before 1.0
<notting> sadmac2: so, yeah. make it a no-op for now
<sadmac2> notting: agreed
<sadmac2> I'll do that when I get home
<sadmac2> Keybuk: could you please weigh in on the new waitfd thread on lkml?
<sadmac2> they're asking for why/wherefore stuff, and that's not my strong suit :)
#upstart 2009-01-10
<Keybuk> sadmac2_: I don't see the why/wherefore?
<Keybuk> I see quite a positive discussion about the best way to do it
<Keybuk> sadmac2_: http://bazaar.launchpad.net/~scott/libnih/trunk/revision/476
<Keybuk> (re your most recent lkml post)
<Keybuk> note comment/changelog entry
#upstart 2010-01-13
<Zer> Howdy. Anyone here by any chance?
#upstart 2010-01-15
<^arky^> hi, can anyone help me with this question ? Upstart Script: emergency keypress handling - https://answers.edge.launchpad.net/upstart/+question/97511
<^arky^> hi, can anyone help me with this question ? Upstart Script: emergency keypress handling - https://answers.edge.launchpad.net/upstart/+question/97511
<sadmac2> ^arky^: you'd make the application start on a certain event (ctrl-alt-f12-pressed for example) and then you'd have something else emit that event when the key was pressed (not upstart's job to actually track keypresses)
<ion> Does it echo in here?
<^arky^> sadmac2: I haven't used upstart that long the bug 507953 explains what I trying to do
<^arky^> the gnome a11y already start the screen reader orca by default, I was think that having a keybinding that restarts it automatically 
<sadmac2> ^arky^: well I explained the answer. upstart doesn't handle keybindings
<ion> How would the Upstart job the user and the display for the orca process?
<ion> s/job/job know/
<^arky^> sadmac2: I see 
<ppm> folks, I need help.  When booting 9.1, my runlevel is not set, and my services (ssh, sendmail, etc.) are not running.
<ppm> i am a complete beginner, but did check the obvious things.  Would be grateful for help!
<ion> https://bugs.edge.launchpad.net/upstart/+bug/506727 perhaps
<ppm> ion: thanks, now looking at this
<henke_> is it possible to set up upstart jobs for situations where the program is already started like "foo start", and stopped by "foo stop"?
#upstart 2011-01-10
<JanC> ducktype: my guess is that upstart thinks mysql is started before it's actually listening
<ducktype> oh good
<ducktype> checking that one
<JanC> at least, that could explain things  ;)
<ducktype> a simple pre-start sleep should do the trick
<ducktype> nothing :(
<ducktype> mm wait
<JanC> you can try to log something before it starts mydns
<JanC> to make sure it actually tries to start it
<ducktype> mm why: post-start script sleep 3 end script
<ducktype> in the mysql job make start mysql wait forever, like when i specified "task" before to try
<ducktype> JanC: i've logged from mysql pre/post start and mydns pre/post start i nto a file
<ducktype> i only see one line mysql pre-start end
<ducktype> seems thath the mysql job is't considered finished
<JanC> so basically upstart doesn't detect when mysql is finished starting
<ducktype> hangs on exec /usr/sbin/mysqld
<JanC> you might need an "expect" stanza
<JanC> or cheat and start mysqld from pre-start instead  ;)
<JanC> hm, it seems like Ubuntu starts mysqld without such tricks...
<JanC> ducktype: this is the default mysql.conf in Maverick: http://paste.ubuntu.com/552322/
<ducktype> thamk you, checking..
<JanC> things like the AppArmor profile you probably don't need
<ducktype> i'm using mariadb not mysql but they are really the same
<ducktype> seems to be: exec /usr/sbin/mysqld &
<ducktype> the &
<ducktype> now doesn't hang on exec
#upstart 2011-01-11
<ristok> Can I have a .conf which contains just emits and start on ?
<ristok> Is there an event which comes after startup has been done ?
<ristok> If I have multiple emits in one file, will those come at the same time or one after another ?  Like can I expect that the scripts listening first emit are run before the ones listening the second emit ?
<ristok> Or those are run simultaneously ?
<twb> When translating a Debian start-stop-daemon(8)-style sysvinit script to an upstart job, is there any need to preserve pidfile support?
<twb> I mean, AFAIK the sysvinit script only does it so start-stop-daemon can find the process again, to stop it
#upstart 2011-01-12
<kreign> could someone take a peek at an upstart conf file for me and tell me if it's correct? 
<JanC> kreign: depends on what you mean by "correct", but if you post a link to a pastebin or such, people can try...
<kreign> JanC, ok. 
<kreign> JanC, just found a false assumption, and then someone needs my attention, and then.... well, i might get to it by dinner, at this rate. :|
<kreign> thanks though
#upstart 2011-01-13
<factorx> Hi guys! I have a problem with upstart concerning the event "net-device-up" which is emitted too early, which leads to the problem, that networking services such as NFS should be used, before the networking connection really works. Is there a way to control the emission of particular events in upstart or how can I fix this problem in any other way?
<jstrunk> Is this an okay place to get help with writing an upstart job?
<JanC> if you stay around, sure...  :P
#upstart 2011-01-14
<djszapi> Why does upstart not print the Process ID of an application launched from a script section ?
<djszapi> What is the advantage of this way ?
<Keybuk> it does
<djszapi> w00t ?
<djszapi> Script part can have tens of commands and those are not printed. Only if there is problems like this one /proc/self/fd/6: /etc/pulse/pulseaudio_pre-start.sh: line 53: amixer: not found pulseaudio start/running, process 599. /proc/self/fd is where it runs script part of the .conf files
<Keybuk> process 599 is the script itself
<Keybuk> and the shared process group of all of those tens of commands
<djszapi> so it does not print then.
<djszapi> well, what is the solution way if I need that sort of information, Keybuk ?
<djszapi> I have just read your mail and I am still not sure the next version (that I do not know when will be released) is useful for my purpose.
<djszapi> and for sure I do not have time to wait for that.
<djszapi> audit kernel stuff I thought can be a hackaround for now, but let me know, I am newbie in this area.
<Keybuk> I don't know what your purposes are
<djszapi> well
<Keybuk> (so it's hard to me to answer questions where you state "for my purpose")
<djszapi> I need the configuration file name and pid of the application that was run by upstart.
<djszapi> as it happens quite perfectly with 'exec' entries in the /etc/init/*.conf files.
<Keybuk> but it does give you that, it gives you the pid of the script
<Keybuk> which is all that was run by Upstart ;-)
<djszapi> nope
<Keybuk> what do you mean "nope"
<Keybuk> I'm pretty sure only one of the two of us *wrote* Upstart, so knows what he's talking about :p
<djszapi> hwclock:329,sh:328,init:1
<djszapi> for example this is the procedure, init -> sh (upstart) -> hwclock
<Keybuk> right, Upstart ran "sh"
<djszapi> I need the pid of the hwclock and the configuration file name which started it.
<Keybuk> so status in that example will give you the pid of sh
<Keybuk> not of hwclock
<Keybuk> ok, that's *NOT* what you said above
<Keybuk> you said "id of the application that was run by upstart"
<Keybuk> upstart ran sh
<djszapi> no
<Keybuk> what sh did is entirely up to sh
<Keybuk> are you disputing what you typed?
<Keybuk> because I just copy & pasted it
<djszapi> okay, you do not still understand it :)
<djszapi> let me give you an example:
<Keybuk> no, I understand far more than you
<Keybuk> you're just not explaining yourself
<Keybuk> and probably you don't actually know what you want
<Keybuk> and don't understand how processes work on UNIX
<djszapi> do not insult me, please.
<Keybuk> I believe what you want is:
<Keybuk>   script
<Keybuk>     foo &
<Keybuk>     bar &
<Keybuk>     baz &
<Keybuk>   end script
<djszapi> as said, WAIT
<Keybuk> to give you the pids of foo, bar and baz ?
<djszapi> I am gonna give you an example, patient pls...
<djszapi> I need to boot the device up.
<Keybuk> is that not what you want?
<djszapi> seems you cannot be patient :)
<Keybuk> no
<Keybuk> I'm busy
<Keybuk> I'm answering you rather than working
<Keybuk> because I'm nice ;-)
<Keybuk> but I don't have much time
<djszapi> work now and ask when I provide info ?
<djszapi> and to avoid the guesswork and wasted time till that ?
<Keybuk> sure, will you hang around here for, say, 6 hours?
<djszapi> please do not be arrogant for hours, if I may ask...
<Keybuk> I'm not being arrogant, I am, right now, using my lunch hour to try and help you
<Keybuk> and you're not answering my question
<djszapi> because I still cannot ?
<Keybuk> why?  you can answer questions?
<djszapi> http://pastebin.com/GjeJiy7n
<djszapi> 14th line for instance.
<Keybuk> that's a shell script
<djszapi> I would like to get this configuration file back and hwclock pid 
<Keybuk> hwclock has no pid at the point that script has finished
<Keybuk> because the shell runs hwclock, waits for it to finish, and reaps it
<djszapi> weird it has.
<djszapi> every process has pid
<Keybuk> tell you what
<Keybuk> why not read what I typed?
<Keybuk> AT THE POINT THAT SCRIPT HAS FINISHED
<djszapi> even tho. the same sometimes than the parent process (setuid e.g.)
<Keybuk> the shell does something like:
<Keybuk>   fork()
<Keybuk>     (child:
<Keybuk>       exec hwclock)
<Keybuk>     (parent:
<Keybuk>       wait)
<Keybuk>   // now at the next line of shell
<Keybuk> so there's no backgrounding going on here
<djszapi> k, so I cannot get this information by upstart....
<Keybuk> the fact that hwclock has a separate pid is basically an implementation detail
<djszapi> how can I get then ?
<Keybuk> for example, a particularly over-the-top shell could have hwclock as a built-in
<Keybuk> which means it would have no pid
<Keybuk> get it when?
<djszapi> nope
<Keybuk> the pid (if there even is one) will appear and vanish pretty quickly
<Keybuk> stop saying "nope" to me
<Keybuk> I know what I'm talking about
<djszapi> let me wait for someone else to help then...
<Keybuk> they'll either tell you the same thing 
<Keybuk> or they'll give you incorrect information
<djszapi> seems you are in god-mode.
<Keybuk> no, I'm trying to help you
<Keybuk> but you're not actually listening to anything I say
<Keybuk> which is exasperating
<djszapi> by screaming at me ?
<Keybuk> I'm not screaming at you
<Keybuk> I'm telling you how things work
<djszapi> and screaming if I am saying sth ?
<Keybuk> and you're refusing to believe me
<djszapi> interesting help, never tried
<Keybuk> which is insulting
<Keybuk> you're wrong
<Keybuk> do you accept that there is no need for hwclock to have a separate pid at that point?
<Keybuk> (feel free to relink /bin/sh -> /bin/busybox and run that script, if you need physical proof)
<djszapi> no idea whether it has got pid that point, but I need the 1) conf file name 2) PID when it ran.
<Keybuk> you could add strace -f to the shell invocation
<djszapi> exactly as it happens in case the exec line in the configuration files.
<Keybuk> that way you'd trace all the system calls, and follow forks, so you'd get the pids that way
<Keybuk> you could use the proc connector kernel interface to follow the forks/execs of the shell and again get the pids
<Keybuk> proc connector is racey though, because the pid may vanish before you have an opportunity to read /proc/PID/cmdline and actually figure out what it is
<Keybuk> (strace at least blocks)
<djszapi> pid is not enough, as said also the config file where it was run frm.
<Keybuk> audit, ftrace, etc. any of those kernel tracing hooks
<djszapi> * from
<djszapi> well, my original idea was the audit stuff.
<Keybuk> you could mount a subsystem-less cgroup hierarchy and place that script into a new cgroup within it
<Keybuk> that would collect the pids run in the tasks file
<Keybuk> but again, that only really tells you background processes
<Keybuk> hwclock would come and go, so unless you polled the tasks file *really hard* you may not even see the pid
<Keybuk> (and even then, /proc/PID/cmdline would probably be gone by the time you found the pid)
<djszapi> yeah, but audit should not be racey.
<Keybuk> audit is racey
<djszapi> or "slow".
<Keybuk> and slow
<djszapi> lol
<Keybuk> sadly
<Keybuk> audit doesn't block the shell from doing its work
<djszapi> which is nifty.
<Keybuk> so when the shell forks off hwclock, it doesn't actually stop anything
<Keybuk> so by the time that the audit system is told about the new pid, it could have already finished running
<djszapi> hard to imagine.
<Keybuk> which means there won't be any information about it - not even the fact it was hwclock at all
<Keybuk> happens all the time
<djszapi> as long as the audit follows the syscalls.
<Keybuk> you'd have to follow the fork and the exec calls
<Keybuk> and extract the strings from the exec call (which is actually an array of strings)
<Keybuk> that's what then makes it slow
<djszapi> well, not really.
<djszapi> it depends on the kernel configuration.
<Keybuk> no, really ;(
<djszapi> you are not obligate to enable the syscall tracing capability.
<Keybuk> no, I mean it's just slow when enabled
<Keybuk> it can be nearly free when turned off
<Keybuk> your best bet, really, is to get the shell to tell you the pids ;)
<Keybuk> for example, you could write that script as
<Keybuk>   hwclock -s -u &
<djszapi> yeah, but that option is just one of the available audit options, you can still use audit with no syscall trace.
<Keybuk>   # you now have the PID in $!
<Keybuk>   wait $!
<Keybuk> sure, but audit with no syscall trace means you won't get the pids ;)
<djszapi> mmh
<djszapi> so the easiest way is to modify ALL the configuration files existing.
<Keybuk> well, it depends yeah
<Keybuk> a better question is why do you need to know the PID of that hwclock invocation?
<djszapi> I cannot talk about that, sorry. Company project and NDA.
<Keybuk> do you need to know the pid of the date and test invocations?
<djszapi> if it was run directly by upstart shell then yeah.
<Keybuk> there's no such thing as "upstart shell"
<Keybuk> that's what I was referring to earlier
<djszapi> wtf ? :D
<Keybuk> everything in that script block - upstart thinks is a big string
<Keybuk> you can put whatever you want in there
<Keybuk> all upstart does is exec /bin/sh and pipe that string to it
<djszapi> I mean in the process queue, there is a shell process after the init process and I meant that shell as an upstart shell.
<Keybuk> which is what I mean about "the application that Upstart runs" *is* /bin/sh
<Keybuk> interesting example:
<Keybuk>   script
<Keybuk>     exec hwclock -s -u
<Keybuk>   end script
<Keybuk> what will Upstart say the pid of that is? :-)
<Keybuk> (hwclock)
<djszapi> no idea
<Keybuk> without knowing your project
<Keybuk> one option would be for you to patch /bin/sh itself
<djszapi> lol
<Keybuk> why lol ?
<djszapi> funny
<Keybuk> let's say you have this upstart job
<Keybuk>   exec /lib/foo/some-binary
<Keybuk> if that some-binary is that shell script you paste-binned
<Keybuk> do you *still* need the pids from it?
<djszapi> no
<Keybuk> interesting, why the distinction?
<djszapi> :)
<Keybuk> *shrug*
<Keybuk> seems pretty arbitrary to me
<Keybuk> btw, that script is *completely* bat shit insane
<Keybuk> you don't need to run hwclock like that
<djszapi> no we need.
<djszapi> and it was just an example if you do not like, the point is you got the idea.
<Keybuk> but I don't get the idea
<djszapi> do not make it with me, pleae :)
<djszapi> * please
<Keybuk> I don't get why you're treating scripts pasted into an upstart conf file differently to those elsewhere
<djszapi> do not do it to me :)
<Keybuk> let's give a hypothetical example:
<djszapi> you do not need to understand that bit.
<Keybuk> let's say you have a system which is entirely an upstart-native boot
<Keybuk> no, I *do* to help you
<djszapi> our system is that.
<Keybuk> ok
<Keybuk> so have upstart as the last thing run a shell
<djszapi> well, I can tell you why tbh.
<Keybuk> the PIDs run by Upstart are "1 thru the PID of that shell:"
<Keybuk> no?
<djszapi> but it requires a more in-depth understanding.
<djszapi> and not 1 min
<djszapi> that is why I would like to avoid it for now.
<djszapi> I would not like to bother you.
<Keybuk> if, after booting, the shell's pid is 1456 then Upstart has resulted in 1,456 processes being run
<djszapi> yeah, a sheel after the jobs, daemons.
<djszapi> * shell
<djszapi> yeah, it is trivial
<djszapi> but what is your gist ?
<Keybuk> no gist, I'm trying to understand what you're trying to do
<djszapi> well
<Keybuk> for example, if you were trying to measure the overhead of using shell scripts for things rather than writing them in C
<djszapi> there are more shell scripts in fact, not just one.
<djszapi> depends on the amount of configuration file stuff
<djszapi> well, put it that way.
<djszapi> do you know Maemo, MeeGo ?
<Keybuk> of course
<djszapi> define "of course".
<Keybuk> it's hard to work out, because - for example - what if hwclock forked off an extra child?
<Keybuk> do you want to know two pids or one?
<djszapi> are you a nokian ?
<Keybuk> of course I know of Maemo/MeeGo
<Keybuk> no, but I know lots of people who are
<djszapi> excellent
<djszapi> so we use upstart in this project.
<djszapi> right ?
<Keybuk> indeed
<djszapi> well
<Keybuk> well, on/off
 * Keybuk checks whether there's a "u" in the day
<djszapi> ?
<Keybuk> sorry, possibly an English expression
<djszapi> nvm...
<Keybuk> Maemo/MeeGo uses Upstart on Sunday, Tuesday, Thursday and Saturday
<Keybuk> but something else on Monday, Wednesday, Friday
<djszapi> so you know maemo, meego security framework
<Keybuk> a joke about the fact that they change their mind every minute
<Keybuk> no, I don't know about that I'm afraid
<djszapi> it is a bit different compared to the traditional posix capability stuff.
<djszapi> it is more fine tuned stuff, like selinux, smack
<djszapi> and the like
<Keybuk> ok
<djszapi> btw, do not starve because of me :)
<Keybuk> I've eaten :)
<djszapi> *Nifty, googles*
<djszapi> *giggles*
<djszapi> typo king, so
<djszapi> we use manifest files for fine-tune capability management
<djszapi> and upstart and daemon maintainer did something wrong :)
<djszapi> no manifest stuff, and all the run jobs, daemon, upstart have all the capabilities.
<djszapi> We wrote a debugger kernel module which gives a line like that:
<djszapi> [    9.701293] captrace:allow=25|hwclock:329,sh:328,init:1
<djszapi> 25 obv. comes from /usr/include/linux/capabili.*
<djszapi> it is a capability
<djszapi> that is the output during the boot-up
<djszapi> and I do some kind of reverse engineering with the perl script
<djszapi> to generate the manifest files for upstart and jobs, daemons maintainers.
<djszapi> can you follow ?
<Keybuk> yup
<djszapi> okay, great I need the conf path to put into the manifest file.
<djszapi> and just the daemon binary path in case daemons
<djszapi> that is why it does not matter in that case.
<djszapi> so the jobs, daemons capabilities are separated.
<djszapi> because they are different debian packages.
<djszapi> or rpm, whateva'
<djszapi> e.g. /usr/bin/pulseaudio
<djszapi> but the stuff run by upstart.
<djszapi> will be dropped by the upstart package.
<djszapi> and we are still speaking about credentials.
<djszapi> is it clear ?
<djszapi> so [    9.701293] captrace:allow=25|hwclock:329,sh:328,init:1 is a good line, but I need to pass it with a configuration file
<djszapi> from which hwclock was run actually.
<djszapi> hwclock pid is there, 329
<djszapi> and that is what I should match with upstart debug output, if any
<djszapi> and get the related configuration file name
<djszapi> that is all about, feel free to ask if something is vague.
<Keybuk> ah, I usee
<Keybuk> so if you had a line saying date:330,sh:328,init:1
<Keybuk> you'd just ignore it?
<Keybuk> so there's an easy way to map <blah>:<pid>,init:1 to an Upstart conf name
<Keybuk> boot with --verbose, in the system logs upstart will list all the pids along with the job
<Keybuk> so you could compare the syslog to that log, and extract :PID,init:1 and map all instances of those to a .conf
<Keybuk> as for the things like hwclock and soforth run by the scripts, audit is *probably* the right place
<Keybuk> since in those cases, hwclock's ppid remains 328, init never finds out about it - the only time init really cares about a pid is when the ppid dies and it gets reparented to init, you see
<djszapi> usee ?
<Keybuk> "see" sorry
<djszapi> I would not ignore a line, why do you think that ?
<Keybuk> well, date doesn't need any extra capabilities? :-)
<Keybuk> or maybe it does
<djszapi> gotcha
<djszapi> you are right
<djszapi> the common linux commands do not.
<djszapi> but it is just a whitelisty parsy thingy.
<djszapi> this is not the main question here for now.
<djszapi> so there's an easy way to map <blah>:<pid>,init:1 to an Upstart conf name
<djszapi> nope ^
<djszapi> <blah>:<pid>,sh:xxx,init:1
<Keybuk> --verbose will give you the log messages to do that
<djszapi> the blah process can most likely be "advanced" cmd.
<djszapi> advanced = extra credentials for now
<djszapi> most likely the one left to that in the line is gonna be a common tool as you have just mentioned.
<djszapi> it is a kinda process tree tho.
<Keybuk> --verbose will give you:
<Keybuk> Jan 14 14:52:49 deathspank init: tty6 main process (8557)
<Keybuk> log messages
<Keybuk> that means you know that all
<djszapi> boot with --verbose, in the system logs upstart will list all the pids along with the job -> nope
<Keybuk> <blah>:<pid>,sh:8557,init:1
<djszapi> as said, we do not need jobs
<djszapi> just commands from the scripts
<Keybuk> no, not ALL
<djszapi> jobs means by me the daemons.
<Keybuk> but you don't need all
<Keybuk> Jan 14 14:52:49 deathspank init: tty6 main process (8557)
<Keybuk> <blah>:<pid>,sh:8557,init:1
<Keybuk> see how the 8557 lines up there
<djszapi> so ?
<Keybuk> every <blah> run by that script will still end ",sh:8557,init:1"
<Keybuk> <blah>:<pid>,sh:8557,init:1
<Keybuk> hwclock:8558,sh:8557,init:1
<Keybuk> date:8559,sh:8557,init:1
<djszapi> give me 2-3 mins to read your posts again.
<Keybuk> mkdir:8560,sh:8557,init:1
<Keybuk> hwclock:8563,sh:8557,init:1
<Keybuk> for example
<Keybuk> if that script ran at least those four commands, that's what you'd see, no?
<Keybuk> (the ppid of each of those remains 8557)
<Keybuk> and, in fact, the pgid and sid of even hwclock is 8557
<Keybuk> so that tells you that the shell script run by upstart for the "tty6.conf" ran those four commands
<djszapi> since in those cases, hwclock's ppid remains 328, init never finds out about it - the only time init really cares about a pid is when the ppid dies and it gets reparented to init, you see
<Keybuk> right
<djszapi> -> yes, I mentioned an example in the beginning for that.
<Keybuk> unless a process deliberately attempts to shed its session, the pgid and sid will remain the same as the shell
<djszapi> 16:57 < Keybuk> Jan 14 14:52:49 deathspank init: tty6 main process (8557)
<djszapi> well it is not enough
<Keybuk> why not?
<djszapi> it is just about the shell script, not the application run by that.
<Keybuk> why is it just about the shell script?
<Keybuk> from what you've told me, that'd exactly what you want, isn't it?
<djszapi> nope
<djszapi> okay, give me a better example and not hwclock
<Keybuk> no, what _do_ you want then?
<djszapi> * let me give you
<djszapi> sorry Keybuk
<Keybuk> maybe I should have picked a better test command than "stop gdm" :p
<djszapi> :P
<djszapi> you were right
<Keybuk> http://people.canonical.com/~scott/forkwatch.c.txt
<djszapi> I did not understand what I mean
<djszapi> * You mean
<djszapi> * meant..erm
<Keybuk> if you need something that *really* can watch all the forks, that C program should help
<djszapi> wait
<Keybuk> though you'll see what I mean about the cmdline race there
<Keybuk> audit might be better
<djszapi> we have just discussed the verbose stuff is ok'ish
<Keybuk> the verbose stuff should get you back to an upstart .conf file, yeah
<Keybuk> and you can turn it off after boot with "initctl log-priority warn"
<djszapi> well, the pid idea was about the identification
<djszapi> but I need the config file only at last.
<djszapi> http://people.canonical.com/~scott/ -> is it your stuff ?
<djszapi> Keybuk: well not an issue
<Keybuk> djszapi: yup
<Keybuk> my stuff
<djszapi> as you got the point this task is because of a wrong maintainer past
<djszapi> so hopefully it is not gonna require continous running.
<djszapi> during the lifecycle of the device, os.
<Keybuk> *nods
<Keybuk> you can turn on --verbose btw with "initctl log-priority info"
<Keybuk> so you don't even need to reboot to enable it
<djszapi> but for confirmation, let me give you a better example than hwclock was.
<djszapi> [    8.318542] captrace:allow=6|aegis-loader:191,sh:188,init:1
<djszapi> aegis-loader is an internal application
<djszapi> run by upstart's script section
<djszapi> right ?
<Keybuk> right
<Keybuk> I assume from that that aegis-loader still has pgid/sid=188
<Keybuk> ?
<djszapi> highly doubt
<Keybuk> is it a background process?
<djszapi> RM680-02-2_RD_001:/etc/init# grep -rni aegis-loader .
<djszapi> ./aegis.conf:14:    if [ -d /sys/kernel/security/credp -a -x /usr/bin/aegis-loader ]; then
<djszapi> ./aegis.conf:15:        /usr/bin/aegis-loader || echo "Failed to load aegis"
<Keybuk> right, so doesn't look backgroundy to me
<Keybuk> so it should still be easy to match up
<djszapi> righty
<djszapi> k
<djszapi> one thingy I do not understand about your posts.
<Keybuk> what's that?
<djszapi> 16:52 < Keybuk> as for the things like hwclock and soforth run by the scripts, audit is *probably* the right place
<Keybuk> right, to find out the pid of hwclock in the first place, rather than the shell
<Keybuk> you know the pid of the shell, upstart knows the pid of the shell, upstart logs it, etc.
<Keybuk> but upstart doesn't know (or care) what the shell does
<Keybuk> so you need something to get the pid of the things the shell runs
<Keybuk> so then you map those things back to the .conf file
<Keybuk> basically you'll end up with a process tree
<Keybuk> pid 1 forked pid 57 forked pid 134
<Keybuk> 134 might be hwclock
<Keybuk> so you look up its parent, 57, in the log - and that tells you its wibble.conf
<Keybuk> wibble main process (57)
<djszapi> well
<djszapi> sh:pid,init:1
<Keybuk> right
<djszapi> shS are the shell scripts coming from upstart (during the boot-up for instance), aren't they ?
<Keybuk> not always
<Keybuk> that's why I asked about exec /lib/blah/blah style
<Keybuk> that can show up as just "sh" too
<Keybuk> (if blah is a shell script)
<djszapi> because that way I would say we do not need anything else than the process id of the shell if it is quite enough information to figure out the configuration file.
<djszapi> let us grep for exec lines, momment
<djszapi> well I do not see any shell script in the output.
<djszapi> getty, syslogd, sshd, udevd, internal binaries...
<djszapi> no shell script.
<djszapi> mostly /usr/(s)bin stuf.
<djszapi> and /sbin ofc.
<Keybuk> cool
<Keybuk> you're using dash then? ;-)
<djszapi> your mean ?
<Keybuk> readlink /bin/sh
<Keybuk> probably /bin/dash or /bin/bash
<djszapi> busybox
<Keybuk> oh right
<djszapi> ofc embedded mobile phones
<Keybuk> that's usually a bugger for not setting proctitles ;-)
<djszapi> and some netbook
<djszapi> we are talking about in case Maemo, MeeGo.
<djszapi> 'that's usually a bugger for not setting proctitles ;-)' -> can you be a bit more expressive, please ?
<Keybuk> oh, I mean that busybox often doesn't bother setting the proctitle
<Keybuk> (the thing you see in ps)
<Keybuk> so when it gets a shell script, you often just see 'sh' rather than '/bin/foo'
<Keybuk> but that, of course, depends on its configuration when built
<Keybuk> doesn't matter
<Keybuk> since it obviously does the right thing for you
<djszapi> y
<djszapi> so it seems we do not need audit and kernel hacking then
<djszapi> but let me know the truth (aka. fixme).
<djszapi> After this command: 'initctl log-priority warn' -> it works perfectly after every reboot that way until I set it back, right ?
<Keybuk> right
<djszapi> right what ?
<Keybuk> right :)
<djszapi> well, I said/asked two things, both ?
<Keybuk> both
<djszapi> k, ty.
<djszapi> btw, are you an upstart developer ?
<Keybuk> I wrote Upstart
<djszapi> alone ?
<Keybuk> pretty much
<djszapi> lol
<djszapi> you are crazy :D
<Keybuk> yes
<djszapi> CONFIG_CMDLINE="init=/sbin/preinit root=0xB302 rootfstype=ext4 rw console=ttyS0,115200n8 omap3_die_id" -> this is the default, so just -> CONFIG_CMDLINE="init=/sbin/preinit root=0xB302 rootfstype=ext4 rw console=ttyS0,115200n8 omap3_die_id verbose" ?
<djszapi> or what is the correct syntax ?
<Keybuk> --verbose
<djszapi> weirdy
<djszapi> well, it does not print anything in fact, I have just tried it out.
<Keybuk> no, it logs it so syslog
<djszapi> highly doubt
<djszapi> we redirect it to console and watch in minicom
<djszapi> there is no syslog here.
<djszapi> mmh....
<djszapi> no idea I guess.
<djszapi> ok I gave it up :/
<Keybuk> I've no idea what your configuration is wrt syslog
<Keybuk> but that's where upstart sends its log messages
<djszapi> by default: /var/log/syslog ?
<Keybuk> no, syslog
<Keybuk> man 3 syslog
<djszapi> there is no /var/log/messages*
<Keybuk> syslog is a socket interface
<Keybuk> where they go after that, depends entirely on your setup
<Keybuk> (or even if anything listens)
<djszapi> man 3 -> developer man pages.
<djszapi> I do not develop with syslog.
<Keybuk> I do :)
<djszapi> by default: -> there is not "depends entirely on your setup" thingy :)
<djszapi> anyways...no idea where the log should be then
<Keybuk> you need to speak to the maemo/meego developer who knows where syslog() messages go on meego
<djszapi> again: minimum, serial port
<djszapi> at least my printk goes there...
<djszapi> and printk is supposed to go to the syslog if nothing else h appens.
<djszapi> * minimum = minicom
<djszapi> seems verbose does not work
<djszapi> maybe the command line option struggles.
<djszapi> is there any way to check the command line with which the system was booted up ?
<djszapi> some sysfs or procfs heuristics ?
<djszapi> RM680-01-2:~# initctl log-priority warn
<djszapi> RM680-01-2:~# 
<djszapi> this does not help either after the rebootl.
<djszapi> * reboot
<djszapi> the upstart might not work on this boot at all ??
<djszapi> I do not see any other upstart related entries either.
<djszapi> should they occur at all ?
<sam-_-> so i want to disable an upstart job. would i just uncomment the "start on" line? what's the preferred way to do this?
<djszapi> how can that be Keybuk, I do not get any upstart messages, nor the debug statements about the stopped, started processes ?
<JanC> sam-_-: I think you mean *comment* the "start on" line?  (and yes, that should prevent it from getting started automatically)
<sam-_-> JanC, is the preferred way?
<sam-_-> JanC, y. that's what i meant. 
 * sam-_- hits himself in the head
<JanC> âº
<Stevee> if you are using upstart 0.6.7, there is a stanza called "manual" add this entry to any jobfile to prevent upstart to start it by any event
<sam-_-> Stevee, ah ok. thx
<JanC> in case you are using Ubuntu, Maverick still has 0.6.6
<sam-_-> i'm on 0.6.6 though :-(
<JanC> so 0.6.7 is very new
<sam-_-> yes
<sam-_-> so the comment will have to do it :-)
<sam-_-> so the commenting will have to do it :-)
<JanC> for now at least
<sam-_-> y. no problem.
<JanC> even natty still has 0.6.6 it seems
<JanC> (but I guess that will change?)
<Keybuk> natty has 0.6.7
<JanC> hm, no
<JanC> package says 0.6.7, --version says 0.6.6
<JanC> initctl --version
<JanC> so probably it's 0.6.7 but doesn't know that itself  ;)
<Keybuk> huh
<SpamapS> Has there very been a discussion of an 'expect listen' ?
<Keybuk> yes
<Keybuk> though it goes something more like "why not use 'start on socket'" :p
<SpamapS> Yeah thats where I get to as well.. the example I'd give is mysql .. which may take 20 minutes to start if it has to recover large innodb transaction logs.
<Keybuk> yeah, and on a server you might want mysql always running
<Keybuk> not just started on first activation
<Keybuk> though even then, it would have the listening socket passed to it
<Keybuk> so it's a bit of a tricky one
<Keybuk> the other side of the question is - does the kernel even notify userspace of new sockets?
<Keybuk> I had a vague idea there might be something netlink-y but I've not looked
<djszapi> Keybuk: gotta go, ty for your help today :)
<djszapi> my virtual beer is yours, heh
<JanC> Keybuk: the source package for upstart 0.6.7 in natty says 0.6.6 in configure.ac & configure, but that seems to be correct/fixed in upstream 0.6.7
<Keybuk> weird
<Keybuk> wonder why 
<SpamapS> t 
<SpamapS> 1
<SpamapS> oops wrong window
<bencc> can you give an example of ubuntu package that uses upstart?
<bencc> I'm trying to package a server and want to see how to include the upstart script
<JanC> bencc: you mean a server package?
<bencc> JanC: a web server
<bencc> what do you mean by a server package?
<JanC> well, there are many packages that use upstart jobs, but starting a server isn't the same as starting a TTY of course  ;)
<bencc> ok
<bencc> I have a basic upstart job that start the server
<bencc> I want to see how to include it in a .deb package
<JanC> I see mysql & squid have upstart jobs
<bencc> thanks, checking
<bencc> JanC: dh-make produces example files like init.d.ex
<bencc> I don't see an example for upstart
<JanC> bencc: maybe file a (wishlist) bug about that then?
<bencc> JanC: ok but I don't know how to use it
<bencc> JanC: if there is init.d.ex the packaging tool probably handle it in a special way
<bencc> so I'm not sure if I need to put the upstart on the root or maybe treat it as a normal file
<tgm4883> When looking at upstart services, what is the meaning of +, -, and ?. for example   [ ? ]  acpi-support
<tgm4883> I've been querying the info, but + and ? tend to be the same
#upstart 2011-01-16
<jackqu7> Hello
<jackqu7> I've got a job stuck on 'start/killed', and trying to start or stop it just hangs
<jackqu7> I was changing the conf for it, but even after reverting to a known good version the same thing is happening
<jackqu7> I was wondering if anyone had any suggestions?
<ion> The main process most likely has different forking behavior than claimed in the âexpectâ stanza, confusing Upstartâs preliminary fork-following code. Either be 100Â % sure of the forking behavior or make it not fork and drop the âexpectâ. A future release of Upstart will have more intelligent code to follow forks.
<jackqu7> ion: I've tried setting it to both fork and daemon, no luck
<ion> âTryingâ to set it to seomthing indicates you donât actually know the precise forking behavior of the main process. It might be best just to make it not fork at all.
<jackqu7> The process has a switch to either fork or not
<jackqu7> What happened was I set that switch, but didn't add "expect fork" the first time
<jackqu7> And now even after adding that, or removing the switch from the process it still hangs
<jackqu7> As if it's still tracking the process initiated from the bad configuration
<ion> Yes, Upstart is still in a confused state. Can you reboot?
<jackqu7> I would really rather not
<jackqu7> I'm foolishly making changes on a production box
<jackqu7> Is there any other way to flush it?
<ion> http://heh.fi/tmp/workaround-upstart-snafu
<ion> ./workaround-upstart-snafu 12345 where 12345 is the pid reported by âstatus jobnameâ.
<jackqu7> Thanks! That worked
<jackqu7> Cheers for your help
<jackqu7> Out of interest, what does that script actually do?
<ion> When in the confused state, Upstartâs fork-following code is waiting to reap a parentless child by the tracked pid which never appears. The workaround creates new child processes until one with the right pid appears, then kills its parent and lets the child die afterwards. Ugly, but effective.
<JanC> sort of a benign fork bomb?  ;)
<ion> Not a fork bomb, since it has no more than two child processes running at any given time.
<JanC> ion: but it would work much faster as a fork bomb!  :P
<ion> heh
<JanC> j/k
#upstart 2012-01-09
<lucido> hello, how can I start a daemon with a specific user?
<ion> exec sudo -H -u user -- cmd
<lucido> it's harmattan system, has no sudo only su
<jodh> lucido: http://upstart.ubuntu.com/cookbook/#run-a-job-as-a-different-user
<ion> su seems to like to leave an extra process running, leading Upstart to track it instead of your daemon.
<ion> Even if you add âexecâ to everything, including the sh script passed to su.
<lucido> the problem that I'm trying to solve is that if I run my app from the shell it functions correectly but if its launched by upstart even if its being run as the same user as in the shell it fails to recieve some qt signals. Is there anyothing else different between these two scenarios than the eviroment variables?
<toabctl> jodh, the current test cases fail for me on ubuntu precise. see https://lists.ubuntu.com/archives/upstart-devel/2012-January/001785.html
<jodh> lucido: does the job run via cron/at?
<jodh> toabctl: I've never seen this problem and have run the tests on a lot of precise systems. Is it repeatable? Please can you open a bug https://bugs.launchpad.net/upstart/+filebug with full details.
<toabctl> jodh, ok.
<jodh> toabctl: thanks
<lucido> jodh, no all it does is export DISPLAY=':0'
<lucido>     /usr/bin/aegis-exec -s -u user /opt/digimedaemon/bin/digimedaemon
<jodh> lucido: this is a daemon with a gui?
<lucido> yes it shows a gui at times
<lucido> jodh, harmattan ahs no start-stop-daemon nor sudo to run as alternate user, now its running as nobody
<lucido> ok, for the record, the solution to my upstart problems can be found here: http://pastebin.com/izjm27m7
 * JanC thinks people need to learn "daemons with a GUI" are a bad concept, especially when they are system daemons...
#upstart 2012-01-10
<ahammond> I have a program I want to run in a loop, sleeping about 10 seconds between each run. What is the correct way to do this? Should I have a script section that has a while true; do foo; sleep 10; done?
<JanC> ahammond: I don't think you should implement that in an upstart script...
<ahammond> JanC: what is the recommended method?
<JanC> well, if it's just something ad-hoc, you could do it in the upstart job definition, I guess
<JanC> but it feels a bit ugly when the service is written inside the job configuration  ;)
<ahammond> I can extend the program to include a looping aspect. Shouldn't be that difficult.
<ahammond> so, how do I achieve the pattern of "run, wait a bit, run againâ¦"?
<ahammond> I looked in to daemonizing the script and I'd rather not do it that way.
#upstart 2012-01-11
<ahammond> figured it out. we're using an older version of upstart and setgid / setuid stanzas aren't supported. wrapped the whole thing in start-stop-daemon. Ugly, but upgrade friendly.
<ion> Iâve had better experiences with sudo than start-stop-daemon. âexec sudo -H -u user -- cmdâ
<Lekensteyn> hi all
<Lekensteyn> The `pidfile` stanza has been removed a while ago, is there any way I can make upstart aware of the right PID?
<Lekensteyn> Our program fork&execs some program to do some initialization tests and then forks&(in parent) exist if the command line options say so
<Lekensteyn> exits*
<jodh> Lekensteyn: Upstart doesn't use pid files as it tracks pids itself. Read this: http://upstart.ubuntu.com/cookbook/#expect
<Lekensteyn> I saw that, but it does not work for me since all fork()s are traced
<Lekensteyn> the application first loads the configuration and then daemonizes if it should do that according to the config
<Lekensteyn> during loading of the config, fork&exec could occur (modinfo $driver)
<jodh> Lekensteyn: your app uses ptrace itself?
<Lekensteyn> nope
<Lekensteyn> start program (pid 100), fork (child 101) & execve "modinfo driver" (multiple times), fork (child 102), child continues, parent (100) is exited
<jodh> Lekensteyn: well, you must either ensure the config doesn't change, or auto-gen the upstart .conf file with an appropriate expect stanza, or use start-stop-daemon or an equivalent tool.
<Lekensteyn> currently, the config and environment is validated before daemonizing, should it be done in an other way then? (i.e. validate after daemonizing)
<jodh> if you have a tool to validate your apps config file, maybe that tool could ensure that if your apps config says something like "daemonize=true" that the upstart config contains "expect daemon"?
<Lekensteyn> well, it's ran like "programm --daemon". If that option is encountered, it knows that it should daemonize later. Before daemonizing, other settigns are evaluated (like --driver or Driver from conffile)
<Lekensteyn> thanks for your help btw
<Lekensteyn> How can I clear stale pids without rebooting or renaming the job? Related bug https://bugs.launchpad.net/upstart/+bug/406397
<jodh> http://upstart.ubuntu.com/cookbook/#recovery-on-misspecification-of-expect. If that fails, you'll have to reboot.
<Lekensteyn> so I've to reboot or rename :s
<jodh> Lekensteyn: the recommendation is to develop your .conf file on a non-critical dev box. Once you have fully tested it, then deploy to your server(s).
<Lekensteyn> It is on my dev box ;)
<Lekensteyn> Now, I've tried program --daemon;wait "$(cat /var/run/program.pid)" but the pid tracked by Upstart is wrong. How do I make Upstart aware of my pidfile?
<jodh> Lekensteyn: as I already said, upstart doesn't use pidfiles - it uses ptrace to establish the pid.
<Lekensteyn> what PID is tracked if "script \n .... \nend script" is used?
<jodh> Lekensteyn: that is all covered in the previously referenced http://upstart.ubuntu.com/cookbook/#expect
<Lekensteyn> jodh: thanks for your help so far, is it possible to redirect stdout/stderr from the program to syslog?
<jodh> Upstart 1.4 can log job output. If you're using an older version though, use the technique here: http://upstart.ubuntu.com/cookbook/#obtaining-a-log-of-a-script-section, but rather than writing to /dev/.initramfs/..., write to /dev/kmsg.
<jodh> alternatively, run "mycmd | logger" if creating that extra logger process won't cause your job problems.
<Lekensteyn> Thanks, I
<Lekensteyn> 'll try it, should I use exec or script
#upstart 2012-01-13
<leehambley> I believe I have a problem with the umask stanza having no effect, could someone please take a look at config & terminal session here - https://gist.github.com/90f931594debddb3e972
<leehambley> I need files to be created ug+rw, and directories to be created ug+rwx - I'm sure this is correct.
<leehambley> I'm wondering if the `exec su -s /bin/sh -c 'exec "$0" "$@"'â¦â¦â¦.` trick is rendering the `umask` stanza useless
<codebeaker> I posted the stanza:umask question to the mailing list, hope to receive an answer
<leehambley> http://stackoverflow.com/questions/8851848/upstart-unicorn-with-umask-ignored now at SO
<trondmm> Hi. I have an upstart job that starts several instances of another job. This works fine, and I can stop and restart each individual instance by passing the correct variables in the shell. However, I'd like to stop all instances by stopping the parent job. How do I do this?
<trondmm> right now, "initctl stop parent" results in "stop: Unknown instance:"
<jodh> trondmm: Have the parent job run 'initctl list' then stop each instance found (see http://upstart.ubuntu.com/cookbook/#determining-how-to-stop-a-job-with-multiple-running-instances)
<jodh> jodh: oh, so your "parent" job contains 'instance'?
<trondmm> no, the parent only includes a script block that starts the sessions. basically for var in ...; do start instance; done
<jodh> trondmm: can you pastebin your config?
<trondmm> I tried adding a pre-stop block which did the same loop, and stop instance, that didnÃ't work
<trondmm> hangon
<trondmm> http://pastebin.com/dMxDLQDU
<jodh> trondmm: 'start on started' is probably wrong here as the disks aren't mounted at that point.
<trondmm> Ah, OK. I've only actually started it manually so far.
<jodh> trondmm: also, you'll need to say "start wmsinstance ... || true". See http://upstart.ubuntu.com/cookbook/#develop-scripts-using-bin-sh and http://upstart.ubuntu.com/cookbook/#debugging-a-script-which-appears-to-be-behaving-oddly
<jodh> 'start on filesystem' would be safer. See upstart-events(7).
<jodh> trondmm: again, "chdir ... || true".
<trondmm> right. 
<jodh> trondmm: for the problem you're mentioning you'll need to change 'script' in your parent job to 'pre-start'. This will make it an abstract job that will run "forever". See http://upstart.ubuntu.com/cookbook/#jobs-that-run-forever
<trondmm> hey! that worked :) Thanks!
<jodh> trondmm: np. If you set a "stop on" for the parent job, you can use the for loop again in a 'pre-stop script' to handle stopping all the instances.
<trondmm> actually, I can't get it work with pre-stop, but it works in post-stop
#upstart 2013-01-07
<leandrosansilva> Hello to all. What signal is sent to the process when I call service stop or service restart? I used SIGTERM in my application for some time, but suddenly it stopped working
<leandrosansilva> the signal isn't treated anymore
<jodh> leandrosansilva: SIGTERM is the default unless you've specified 'kill signal' (http://upstart.ubuntu.com/cookbook/#kill-signal). You are using the SysV commands. What happens if you use the Upstart command 'stop $job'?
<xnox> jodh: =) mumble =)
<xnox> jodh: stgraber: how to cross-compile libnih
<xnox> considering that it tries to execute nih-dbus-tool
<xnox> build two?
<xnox> for the build
<xnox> and then for the host
<xnox> ok. I'll do that.
<xnox> *sigh*
<stgraber> xnox, jodh: success: UPSTART_SESSION=unix:abstract=/com/ubuntu/upstart-session/201105/24023
<xnox> awesome =)
<stgraber> now I just need to make initctl look for that environment variable
<xnox> there are nih helpers for environment. but in xdg bits I simply used getenv.
<xnox> jodh: thank you !
<jodh> xnox: thank you! Great piece of work - I just caught a few typos ;)
<jodh> stgraber: shiny! :)
<SpamapS> stgraber: does that mean we can run two upstarts on the same dbus?
<ajp> hi all, i'm trying to run my script on startup through upstart on my ubuntu server. What do I save my job file as? and where do I put it?
<ajp> hi all, i'm trying to run my script on startup through upstart on my ubuntu server. What do I save my job file as? and where do I put it? and does this look right ?http://pastebin.com/xjACPjk4
#upstart 2013-01-08
<jodh> xnox/stgraber: lp:~jamesodhunt/upstart/setenv+getenv now has working set-env, get-env and list-env. I'll add unset-env and reset-env tomorrow.
<stgraber> cool!
<xnox> awesome =)
<jodh> I also found a nasty bug in d-feet in the process: https://bugs.launchpad.net/ubuntu/+source/d-feet/+bug/1097303
<jodh> that'll teach me to use gui tools :)
<toabctl> jodh, about lp #1097303: can you try "true" or tell me the function with the (string, boolean) signature, please?
<gansbrest> hello
<gansbrest> Is there a way to create a job with attibutes, something like start sevice one, start service two
<gansbrest> so I have one service job, but I also supply specific attibutes
<gansbrest> based on those attibutes I start/stop different processes
<SpamapS> gansbrest: you can pass environment variables into jobs with initctl/start
<SpamapS> gansbrest: so 'start jobname FOO=1' will set FOO=1 in the environment of jobname
<SpamapS> gansbrest: you can also use the 'instance' keyword to run multiple instances of the same job based on different variable values.
<SpamapS> gansbrest: you might notice that each network interface has its own instance of the 'network-interface' job
<gansbrest> wow, this is useful info, thanks a lot!!
<JanC> gansbrest: be sure to read the upstart cookbook (see /topic )
<gansbrest> yes yes, I'm reading it now, it looks exactly like I need 
<gansbrest> http://upstart.ubuntu.com/cookbook/#instance
<JanC> âº
<JanC> and I mean read the whole cookbook, it has lots of useful information & tips
#upstart 2013-01-09
<jodh> stgraber/xnox: my setenv branch should be usable if you want to give it a try. Tests will take a day or so to write (he says optimistically ;-) before I raise an MP.
<jonnor> I have a custom software running on Ubuntu 12.04 where I just converted from using sysvinit scripts to an upstart job for starting. Problem is: the service crashes when ran with upstart, and not without
<jonnor> How is the runtime environment of an upstart (system) job different from that of sysvinit or when using a shell?
<jonnor> And how may I attach gdb to my service when ran from upstart?
<jonnor> The issue is reproducible when the upstart job just consists of "exec /opt/my/service"
<jonnor> I am able to run gdbserver from inside the upstart job, and connect to it using gdb (on same machine). However, when ran this way, no symbols are found for the executable and the stack only has one entry in ld. When running gdb /opt/my/service I get all symbols and proper stack (and no crash...)
<xnox> when running from upstart there isn't much of environment at all. Try for example `exec env` and look at the logs.
<xnox> (under sysvinit the environment is poluted more)
<xnox> for example $HOME is not set at all.
<jonnor> xnox: thanks! It is very minimal indeed. The code uses $HOME, could be that is what takes it down
<jonnor> xnox: haha, exporting HOME fixed it. Thanks a lot!
<xnox> well it did take down and caused emacs daemon to hang. it turns out software doesn't often handle missing environment variables well ("e.g. surely $HOME will always be set")
<jonnor> you can tally this piece of software up on that list :p
<jonnor> and confirmed - converting my sysvinit script to upstart fixed my original issue as well. Now I can sleep
<jonnor> good night
<xnox> night
#upstart 2013-01-10
<drockna> i want to source in an upstart script?? how do i do that?
#upstart 2013-01-11
<SegFaultAX> I have a trivial upstart script (basically just the exec line). `service myserv start` works as expected, but `service myserv stop` does not (errors with "Unknown instance")
<SegFaultAX> The /var/run/myserv.pid is being updated correctly.
<stgraber> sounds like that service is forking and you're missing an "expect fork" or "expect daemon" statement
<SegFaultAX> stgraber: So that's the strange bit...
<SegFaultAX> stgraber: It seems like my program is actually writing its pre-daemonized pid to the pidfile.
<SegFaultAX> (uwsgi in this case). But I do have an expect fork, should it be expect daemon?
<SegFaultAX> stgraber: Pff, you're a king. Got it.
<SpamapS> seems like everybody has been fighting uwsgi + upstart these days
<stgraber> SegFaultAX: most daemons do double-fork, those need "expect daemon", for simple fork, "expect fork" is enough. If you're not familiar with the code of the daemon, you basically have to try and see which works.
<SpamapS> I dunno if I'd say most daemons do
<SpamapS> in my experience it has been 50/50
<SpamapS> since its not actually necessary to fork twice
<SegFaultAX> SpamapS: Is it not? I thought you need 2 to ensure your process doesn't reconnect to a tty by accident?
<SpamapS> nope
<SpamapS> SegFaultAX: you just have to close/setsid properly.
#upstart 2013-01-12
<Rosuav> Hi, I'm having trouble building Upstart from source, is this the place to ask?
<Rosuav> Hi JanC, are you familiar with building Upstart from source?
 * Rosuav notes that this channel is one of the quieter ones
<rhagu> hi I am running ubuntu 12.04 and want mediatomb to run on a trunked interface called bond0 and created with ifenslave, I therefore changed its upstart conf from: start on (local-filesystems and net-device-up IFACE=lo) to start on (local-filesystems and net-device-up IFACE!=bond0), this setup sadly does not start mediatomb, what can I do now?
#upstart 2013-01-13
<SpamapS> rhagu: just make it 'runlevel 2'
<SpamapS> rhagu: and make sure your bond0 is listed in /etc/network/interfaces as 'auto bond0'
<SpamapS> rhagu: the system will not boot up until bond0 is up as long as it is listed there
<rhagu> SpamapS this is what /etc/network/interfaces looks like, bond0 is brought up and gets an IP from the dhcp server
<SpamapS> rhagu: good, then just change mediatomb to 'start on runlevel 2'
<rhagu> I will try that, but shouldnt it work the other way, too?
<rhagu> does it need to look like this: "start on runlevel [2345]"?
<SpamapS> no
<SpamapS> err
<SpamapS> yes it can look like that
<SpamapS> but you don't need the [2345] if you don't use runlevels 3, 4, or 5
<SpamapS> thats just a distro level thing for the very tiny number of people who use runlevels for things
<rhagu> I dont know if I use them but it wont hurt if I write it with brackets and the other numbers, right?
#upstart 2014-01-06
<p3rsist> If I want a service to be started after home directory is decrypted on my development machine and I also want to use that same init upstart conf for the server where there no encrypted home directory, does the filesystem event will work for both?
<p3rsist> ion?
<Jordan_U> Is there any way that https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1077579 could be a bug in something other than upstart? Not reaping a child seems like a pretty basic failure of PID 1 so I'm surprised this hasn't (seemingly) recieved much attention.
<xnox> Jordan_U: if pid 1 / upstart receives SIGCHLD for that process, it wil reap it.
<xnox> Jordan_U: so something else has probably already received that signal and ignored it.
<Jordan_U> xnox: So something like the process dying before becoming a child of PID 1? I would expect even then that PID 1 would reap the child, so I think I'm misunderstanding something.
<xnox> Jordan_U: when should it reap it? upon a defunct process getting re-parented to pid1, i guess sigchild will never arrive in that case.
<Jordan_U> xnox: I think a check for defunct processes when they're inherited would probably make sense.
<kaimast> stupid question. how do i build upstart?
<kaimast> simply running automake doesn't seem to work
<xnox> kaimast: it's covered in the cookbook. I think you want $ autoreconf -f -i; ./configure --with-options-you-need --exec-prefix=you-need; make; make check.
<xnox> kaimast: do run the extensive test-suite, that validates the build in many different ways.
<kaimast> thanks xnox! :)
<kaimast> do you also know if there are tests for extras? especially upstart-socket-bridge?
<xnox> kaimast: http://upstart.ubuntu.com/cookbook/#development-and-testing should be helpful.
<xnox> kaimast: i'm not sure check the code, the bridge itself are well just emitting events. Sockets are unit-tested in the libnih side of things, and fd passing in the events (as done by socket bridge) is unit tested in the init/ tests portion.
<xnox> kaimast: (or actually possibly in the nih-dbus part of codebase)
<xnox> kaimast: ideally one would do "imperical" integration tests for a bridge, the way it's done for re-exec in ./scripts/test/*.py which is in python unit tests =)
<kaimast> wth? ./configure: line 2510: syntax error near unexpected token `[Copyright'
<xnox> kaimast: do you have all dependencies installed? sudo apt-get build-dep upstart
<xnox> kaimast: and did your "autoreconf -f -i" resulted without any severe warnings?
<kaimast> yeah, btw in the cookbook it says "apt-get install build-dep" 
<xnox> kaimast: oops that's wrong =)
<kaimast> okay rerun autoreconf and now it seems to do something :)
#upstart 2014-01-07
<taharqa> hi ! last day xnox told me that I can override stanza in the /etc/init/SERVICE.conf file. But I have a script...end section : do I have to override the whole script section ? or I can override a line ?
<taharqa> in the http://upstart.ubuntu.com/cookbook/#override-files documentation is not that clear for me
<jodh> taharqa: overrides apply to an entire stanza so if you can only override the entire script using a .override file.
<taharqa> then, what happen if in my SERVICE.conf I have several script section ? how does upstart can know which script to override ?
<jodh> taharqa: you can override individual script sections so if your .conf file contains a pre-start script and a "main" script, your .override can override either or both by just specifying a new "pre-start script" or "script" stanza.
<taharqa> jodh: thank you
<p3rsist> Hi guys. How come, /bin/sleep doesnt seem to work in upstart scripts sections
<p3rsist> ?
#upstart 2014-01-08
<LtWorf> can anyone tell me the syntax for "kill signal"? On the documentation the example is "kill signal INT", does it mean that if I want to use SIGTERM I must write "kill signal TERM"?
<jodh> LtWorf: you can specify either "kill signal SIGTERM" or "kill signal TERM".
<LtWorf> okay. Perhaps this could be made explicit in the documentation, if anyone here has access to that
<jodh> LtWorf: in fact, you can also specify "kill signal 15" but I would strongly avoid doing that.
<jodh> LtWorf: yes, I'll update that...
<LtWorf> jodh: thank you for the help
#upstart 2014-01-10
<nikias> anyone around?
<nikias> so I'm try to write an upstart job for usbmuxd. but it hangs on start.
<nikias> it does 2 forks (also verified with what cookbook 6.12.4 says) so I use expect daemon but it doesn't work...
<nikias> 6.12.6.1   When start hangs states what do to but at point 4 it doesn't say usbmuxd stop/waiting but instead usbmuxd start/running
<nikias> job: http://pastie.org/8621969
<nikias> any tips would be appreciated.
#upstart 2014-01-12
<SpamapS> slangasek: note I just pinged you in #debian-devel, but I'll ask here in case you ignore that one
<SpamapS> vorlon: Hey, say I was totally insane and wanted to have a Debian box that used upstart.. 
<SpamapS> slangasek: Hey, say I was totally insane and wanted to have a Debian box that used upstart.. 
<SpamapS> slangasek: specifically a VM... how might I get that upstart to be verbose and spray things to the console?
<SpamapS> slangasek: have you experienced any issues with startpar and upstart on sid?
<SpamapS> slangasek: for me, rc RUNLEVEL=2 never returns when using startpar
<slangasek> SpamapS: not specifically, though certainly there have been scattered reports of broken init scripts preventing startpar from doing the right thing
<SpamapS> What seems to happen..
<SpamapS> is startpar never returns
<SpamapS> so rc RUNLEVEL=2 never finishes.. and tty1 never starts
<SpamapS> slangasek: I have a really minimal set of software installed
<SpamapS> slangasek: anyway, I'm filing a bug against sysvinit-utils .. upstart seems to be doing the right thing.. /etc/init.d/rc or startpar seems more likely as the problem.
<slangasek> SpamapS: ok, well, I can't reproduce that in a basic sid VM here
<SpamapS> slangasek: I'm building the VM myself using debootstrap and diskimage-builder (OpenStack image builder)
<SpamapS> slangasek: so perhaps we're missing a dep somewhere?
<slangasek> SpamapS: I don't see how a missing dep would cause any upstart-specific problems
<slangasek> SpamapS: have you turned up the debugging on startpar, to see where it gets stuck?
<slangasek> er... or does startpar have any debugging
<SpamapS> I don't know how to do that :(
<SpamapS> yeah I don't see anything in the manpage
<SpamapS> slangasek: I can work around it by just diverting startpar...
<SpamapS> slangasek: I'm using upstart specifically because I want upstarty things to keep working.. don't care much about speed of /etc/rc2.d/* :)
<slangasek> SpamapS: hah - so I just dist-upgraded my vm, pulling in new versions of udev and ifupdown, and the VM hasn't come back up
<SpamapS> slangasek: could it be a bug in the cloud-init packages? I see that cloud-init ships /etc/init/cloud-config.conf _and_ I have /etc/rc2.d/S03cloud-config
<slangasek> SpamapS: diverting startpar doesn't work, upstart relies on startpar integration to force skipping of init scripts that duplicate upstart jobs
<SpamapS> slangasek: mine dies after cron says it started
<SpamapS> slangasek: so it 'works' but not really :)
<slangasek> SpamapS: it 'works' except that it doesn't work after I update, so something changed in sid recently
<SpamapS> slangasek: ok so it is normal to have an S03cloud-config and /etc/init/cloud-config.conf ?
<slangasek> SpamapS: yep
<slangasek> SpamapS: ah, my boot failure is unrelated, EC2 console shows that the kernel config explodeded :P
<SpamapS> slangasek: one other problem I'm having is that I"m not able to just add --verbose to kernel command line and get lots of init: stuff on console
<SpamapS> slangasek: startpar appears to only have debugging printing stuff if you compile with -DDEBUG
#upstart 2015-01-06
<mattzuba> Hoping someone can help real quick... I'm trying to write an upstart job to start up a daemon, but the daemon requires to be run under a different user.  I'm running on AWS EC2 with upstart 0.6.5, so I can't use setuid/setgid, and sudo/su isn't working (Terminated with status 1).  I can paste my script if needed
<jodh> mattzuba: just read http://upstart.ubuntu.com/cookbook/#run-a-job-as-a-different-user
<mattzuba> I've used a few of those suggestions, but they haven't worked.  I have to source a script prior to running the daemon to setup some environment variables, so I'm using a script stanza.  I've used various versions of those exec calls and they all fail to stay running.  I can't use start-stop-daemon since it's not available either.
<mattzuba> script
<mattzuba>     . /opt/elasticbeanstalk/support/envvars
<mattzuba>     sudo -Eu webapp /var/app/current/artisan queue:work --daemon --tries=3 --sleep=5
<mattzuba> end script
<mattzuba> the sudo line works fine when I run it on the command line, but not via upstart
<mattzuba> i tried putting exec in front of sudo as well with the same results
<jodh> mattzuba: in which case, you'll want to look at http://upstart.ubuntu.com/cookbook/#see-the-environment-a-job-runs-in and http://upstart.ubuntu.com/cookbook/#checking-how-a-service-might-react-when-run-as-a-job. Also, presumably you're using 'sudo -E'?
<jodh> mattzuba: ah - sorry, yes you are :)
<mattzuba> thanks, I'll take a read over those. The cookbook has lots of great info, just wish it was easier for a Upstart newb like me to parse through, heh
<jodh> mattzuba: try using my procenv tool as you can diff the output. It's covered in the links above. Changes are the problem is that when upstart runs your job, key env vars are not set. Note: http://upstart.ubuntu.com/cookbook/#job-environment
<mattzuba> cool.  the only envvars I need are custom ones set in the elastic beanstalk support envvars file, nothing special to the system that I can think of anyway
<mattzuba> got it!!!
<mattzuba> this seemed to work, the only one I hadn't tried yet: exec su -s /bin/sh -c 'exec "$0" "$@"' webapp -- /var/app/current/artisan queue:work --daemon
#upstart 2015-01-07
<Duncan_> hey guys, is it possible to start upstart services as a non-privileged user *without* adding a line to sudoers/sudoers.d?
#upstart 2015-01-08
<zfj> hi
<zfj> i'm wondering if there's any way i cna view the upstart cookbook for an older version of upstart?
<zfj> i'm trying to develop an upstart svc for a centos6 system which uses upstart 0.6.5 and i cna't see any manpages or docs for that version, since it's pretty old
#upstart 2015-01-09
<hramrach> hello
<hramrach> where is hostname set when using upstart
<lazyPower> Can upstart be run outside of init?
#upstart 2016-01-14
<topi`> hi, I've got strange behaviour on my .conf scripts, (some of) them will not start at startup even though I've double checked that everything should work. And they also work via manual invocation "initctl start foo"
<topi`> system is ubuntu trusty
<topi`> I googled and found some ppl asking the same question, but none of those answers seem to help me
<topi`> -rw-r--r-- 1 root root 243 Jan 14 13:41 /etc/init/n2n.conf                      
<topi`> I guess the permissions are just fine.
<topi`> I wish "initctl" would give me more diagnostics info about *why* a unit did not start even though it has exactly the same "start on ..." stanza as another unit which starts just fine
<topi`> init-checkconf says "syntax ok"
<topi`> upstart version is 1.12.1-0ubuntu4
<supergonkas> Hey anyone around?
#upstart 2016-01-15
<topi`> supergonkas: very quiet here. I asked something yesterday and nobody said anything after that
<Joy> hi there... so i have this machine where 'initctl start rc' hangs :)
<Joy> i messed with upstart config by injecting several local tasks
<Joy> what's the best way to debug this?
<Joy> i have a job that runs a long time upon boot, 291 seconds the last time around
<Joy> and then it finishes, and things should proceed after that, but they don't
<Joy> is there a timeout on upstart's attempts to proceed?
<topi`> Joy: there might be some, but I didn't find in docs
<topi`> Joy: I also have a weird startup problem, a .conf file mysteriously fails but no trace of the reason in logs
<topi`> hmm, actually, now there WAS a reason in syslog... it could not change the working directory
<topi`> need to reboot, br
#upstart 2017-01-09
<adfeno> Hi all! :)
<adfeno> We have a job script that is in a directory inside "/root" and we have a symlink pointing to it from "/etc/init"
<adfeno> But, for some reason, Upstart-related tools are unable to remember that the service exists across reboots.
<adfeno> We always end up having to do `initctl reload-configuration`
<LordShadowWing> It's quite annoying
<adfeno> Does anyone know how to fix this?
<adfeno> By the way: LordShadowWing's copy of Upstart is the one affected
<adfeno> I'm just assisting him.
<adfeno> For those interested:
<adfeno> sudo ls -al ~root/.guix-profile/lib/upstart/system/guix-daemon.conf
<adfeno> -r--r--r-- 2 root root 351 Dec 31  1969 /root/.guix-profile/lib/upstart/system/guix-daemon.conf
<adfeno> ls -al /etc/init/guix-daemon.conf
<adfeno> lrwxrwxrwx 1 root root 55 Jan  8 14:19 /etc/init/guix-daemon.conf -> /root/.guix-profile/lib/upstart/system/guix-daemon.conf
<adfeno> LordShadowWing: I'll try reproducing your issue.
<LordShadowWing> adfeno, I could give you ssh access
<adfeno> LordShadowWing: Don't worry... Let's see If I can test it from here.
<LordShadowWing> ok
<adfeno> Wait a moment, have to reboot.
<adfeno> #upstart: We have decided to give ourselves some time on the matter. Thanks.: )
<twb> I've got an abandonware ubuntu 10.04 server here (upstat 0.6.5), and I'm trying to give its dovecot a higher nofiles limit.  Do I need to explicitly tell upstart to reread /etc/init/foo.conf after I edit it (like "systemctl daemon-reload")?  My memory says no, but I don't see any "init: reloading!" messages in syslogâ¦
<twb> Ah initctl reload-configuration
<twb> slice init: Failed to spawn dovecot-inmate main process: unable to set "nofile" resource limit: Operation not permitted
<twb> Grargh
<twb> OK "limit nofile 9999 9999" worked, so maybe "limit nofile unlimited unlimited" is just not allowed
<Md> how I do I debug upstart hanging at boot time? I have managed to boot in bash, open a second shell and then exec'ed upstart
#upstart 2019-01-13
<iovec> damn, never expected this would still be alive =)
