#upstart 2007-01-29
<CJari> hi
<CJari> can some one say where is the stuff from inittab located now?
#upstart 2007-01-31
<chillywilly> so has there been a big push in fiesty development to write more upstart jobs?
#upstart 2007-02-01
<_ion> atool is handy. http://johan.kiviniemi.name/blag/2007/02/01/atool/
#upstart 2007-02-03
<Keybuk> gnargh, I hate UNIX sometimes
<Keybuk> SIGCHLD isn't getting delivered :-/
<Keybuk> (gdb) p sigpending (&act.sa_mask)
<Keybuk> $34 = 0
<Keybuk> (gdb) p sigismember (&act.sa_mask, 17)
<Keybuk> $35 = 1
<Keybuk> is definitely pending
<Keybuk> yet, when I remove the procmask, it doesn't turn up
#upstart 2007-02-04
<Seveas> Keybuk, some stupid suggestions: if it's sent while masked, isn't it just ignored? Do you actually give it a chance to be delivered (eg not looping inside a sighandler)?
<Keybuk> the point of masks is to block their delivery, not cause them to be ignored :)
<Keybuk> I figured what it was; before setting the handler, I set it to SIG_DFL first just to make things sane
<Keybuk> setting a signal to SIG_DFL means it gets handled in the kernel, so the process signal mask doesn't apply
<Keybuk> solution: don't reset the signals when being restarted, and voila
<Keybuk> signals are "reliable" in that they can be raised, and you will get them if you're listening
<Keybuk> however you may just get one, not several, depending on the OS
<theCore> I always start to think Unix system programming is hard when I see all the fancy abbrv.
<theCore> 96 revision(s) pulled.
<theCore> whoa, Keybuk, you seem to work hard
<Keybuk> heh
<Keybuk> there are scarier stats
<theCore> bzr diff -r-96.. | diffstat
<theCore> it seems most of your work is centred on test suites
<Keybuk> -r 223 was 0.2.7 (edgy version), 179 in libnih
<Keybuk> $ bzr diff -r ..223 | diffstat
<Keybuk>  62 files changed, 19751 insertions(+)
<Keybuk> $  bzr diff -r ..179 | diffstat
<Keybuk>  63 files changed, 17881 insertions(+)
<Keybuk> -- 
<Keybuk> vs.
<Keybuk> $ bzr diff -r 223.. | diffstat
<Keybuk>  80 files changed, 21029 insertions(+), 10311 deletions(-)
<Keybuk> $  bzr diff -r 179.. | diffstat
<Keybuk>  66 files changed, 20752 insertions(+), 8230 deletions(-)
<Keybuk> a lot of it is test suite, yeah
<Keybuk> and all the bugs I've found in the process
<Keybuk> getting the code base sane so I can merge in the new stuff
<theCore> just a question, does test driven programming worth the effort. It seems to be the norm at Canonical 
<theCore> effort. -> effort?
<Keybuk> I'm not sure about test-*driven* programming, where you write the tests first, then the code second
<Keybuk> I've found it *very* useful for complex algorithms
<Keybuk> but find it gets in the way of straight forward bone-playing
<Keybuk> I'm certainly a great fan of *tested* programming
<theCore> I was thinking writing a test-suite for my small project, a easy-to-use iptables front-end. 
<theCore> but, I don't think it will be necessary
<theCore> the whole is < 1000 lines, without any fancy algorithm
<Keybuk> you should still try and have it tested though
<Keybuk> I've found all manner of silly bugs in the simplest of functions by testing it
<Keybuk> e.g. "initctl shutdown" tried to send message 1 to the pid of the UPSTART_SHUTDOWN enum entry
<theCore> hmm, right. In fact, it could be a good learning experience
<theCore> after all, I will probably end-up as a software engineer, so I will to learn how to test my code sooner-or-later
<theCore> will need*
<theCore> hehe, you're a Lord of the Ring fan?
<Keybuk> heh, all the frodo/bilbo references?
<theCore> yeah
<Keybuk> they're just common english metasyntactic variables
<Keybuk> foo/bar/baz/frodo/bilbo/drogo/wibble/wobble/etc.
<Keybuk> but yes, also I do like LotR
<theCore> also, you got some pretty neat macro in nih/test.h
<Keybuk> originally I didn't have any, and the upstart tests were all just written by hand, even down to  printf ("Testing some_function()\n");
<Keybuk> I grew them into those macros simply to make it easier
<Keybuk> TEST_ALLOC_FAIL is my new favourite; it loops over the enclosed code, counts how many times malloc is called, and then runs the code again causing each one to fail in turn -- so you can test the side-effects of -ENOMEM :p
<theCore> yes, I was looking at this one
<theCore> TEST_CHILD is neat too
<Keybuk> that reminds me, I have a fix for TEST_CHILD to turn it into one statement :p
<theCore> hehe
<theCore> I always been a bit scared by C's macros, since I saw #define MAX(A, B) (A > B ? A : B) 
<Keybuk> that's a tricky one, because it evaluates both A and B twice
<theCore> yep
<Keybuk> so MAX(a++, b++) will expand to (a++ > b++ ? a++ : b++)
<theCore> exactly
<theCore> the pleasure of side-effects
<Keybuk> so if a was 3 and b was 4, then you'd get 5 as the value, and a would be 4 and b 6
<Keybuk> there's a gccish way of writing that
<Keybuk> but it only works if you know the types
<Keybuk> e.g.
<theCore> #define MIN(A,B) ((A) < (B) ? : (A) : (B))
<Keybuk> #define maxsize_t(a,b) ({size_t _a = (a), _b = (b); _a > _b ? _a : _b; })
<theCore> oh, #define MIN(A,B) (A <? B)
<Keybuk> I've never heard of "<?"
<theCore> I just learned it
<theCore> http://developer.apple.com/documentation/DeveloperTools/gcc-3.3/gcc/Min-and-Max.html
<Keybuk> those are C++ extensions only, no?
<theCore> I don't know
<Keybuk> the only note I can find in the gcc 4.1 manual is
<Keybuk>  The G++ minimum and maximum operators (`<?' and `>?') and their
<Keybuk> compound forms (`<?=') and `>?=') have been deprecated and will be
<Keybuk> removed in a future version.  Code using these operators should be
<Keybuk> modified to use `std::min' and `std::max' instead.
<theCore> that makes sense
<theCore> C++ STL is way more powerful than C's preprocessor
<Keybuk> I don't really like C++
<Keybuk> if they wanted to make a new language, they should have unbolted it from C
<Keybuk> instead they ended up with a hideous half-breed
<Keybuk> both Java and C# are far more elegant
<theCore> well, it depends of your point of view
<Keybuk> the principal thing about C++ that I hate is that it still has header files
<theCore> but, I agree that Java and C# are more elegant
<Keybuk> which artificially separates your class structure and code
<Keybuk> AND by inference, exposes your private information to anyone reading them
<Keybuk> they should have dropped the pre-processor, and made cpp files self contained units that could be referenced
<theCore> I agree, but I don't think we will ever see a such change in C++
<Keybuk> indeed
<Keybuk> which is a shame
<Keybuk> the obvious bogosity is "#define private public"
<theCore> haha
<theCore> oh?
<theCore> gcc has improved
<theCore> the MAX macro works 
<_paulfm> hi everyone
<_paulfm> Is anyone home? :-)
<_paulfm> I am looking for some upstart help... I have just built it on Debian etch (testing)
<_paulfm> I am hesitant to do a make install.... Im worried I may hose the init system
<_paulfm> If I reconfigure and build.. with the /opt/upstart prefix
<_paulfm> how do I start upstart at boot... so my upstart tests get run... but I leave the "regular" init in place
<_paulfm> hmmm... nobody home
<dns_server> is anyone around that can help me write a script?
<popey> moo
<popey> hmm - wrong channel :)
<AlexExtreme> lol
<Keybuk> cows are welcome here
<Seveas> cows make good meat
<Keybuk> they do indeed
<_paulfm> hellooo...doe anyone here use upstart on debian
#upstart 2008-01-28
<alephant> Hi all!
<alephant> Can I use output redirection in an upstart script, e.g. /bin/fnord >> /var/log/fnord.log?
<alephant> Or is my only option /dev/console and thence to syslog?
#upstart 2008-01-30
<Rigolo> good morning/afternoon
<Rigolo> I would like to make a script that will start a service on ubuntu
<Rigolo> I have examples of a "normal" init script for this service but I would like to make it a upstart script because that seems to be the way of the future
<Rigolo> I have read the documentation but I still have some questions. Especially about the events. How are these triggered? If i want this service to be started after an other service is started with the normal init scripts then how do I do that?
<chrisfarms> hi #upstart ... does anybody know of a list of emited events? .... I'm looking for something that is fired when a network interface is brought up?
<chrisfarms> (or should I just go back to ip.up.d/ ?)
<chrisfarms> :(
<DShepherd> hey question. ubuntu doesnt use inittab again right? if so what does it use now?
#upstart 2009-01-26
<Keybuk> sadmac, keesj: http://bazaar.launchpad.net/%7Escott/libnih/trunk/annotate/635?file_id=NEWS-20060424160942-032abeceeca6157f
<Keybuk> this should hopefully alleviate some of the issues with libnih's unstable API
<Keybuk> (ie. documenting the changes as we go)
<keesj> cool. 
<sadmac2> Keybuk: cool
<sadmac2> Keybuk: I have the beginnings of an async api at home. It needs a couple tweeks and a lot more testing but its there.
<Keybuk> sweet
<Keybuk> I'm going to push a 0.5.1 once I've got upstart up to date with the libnih changes
<Keybuk> because there were some realloc oom failure issues I found in the process of changing the allocator
<Keybuk> then 0.5.2 we'll either push in the async api or the properties support (whichever comes first), and 0.5.3 will get whichever comes second
<sadmac2> sounds good
<sadmac2> I'll re-hash initctl as soon as the properties support comes in
<Keybuk> the plan being to start making some very rapid releases
<Keybuk> since we have a test suite, in theory, upstart is always releasable as long as it passes
<Keybuk> in hindsight, the "drop all the IPC, rewrite the core, add D-Bus back" plan wasn't ideal
<sadmac2> Keybuk: have you looked at the manpages in 0.5.0? I get this funny feeling nobody updated them :)
<Keybuk> no :)
<Keybuk> I actually did start on some new manpages about a year ago
<Keybuk> which actually tried to document what happened events-wise
<Keybuk> I should finish them up, then we have a 0.5.4 ;)
<sadmac2> Keybuk: in 0.10, when someone installs a .deb/.rpm with a service, can that service be disabled by default?
<Keybuk> should be possible, yes
<Keybuk> the timing of that is kinda critical though
<Keybuk> since if rpm unpacks the file, upstart will notice ;) - the disabled flag needs to appear before the definition
<sadmac2> Keybuk: and if you disable a service, does it disable all its dependents?
<Keybuk> right
<Keybuk> since none of the dependants can be automatically started
<sadmac2> Keybuk: consider ypbind and gdm: if yp is installed, configured, /and/ enabled, gdm should depend on it. if it is not all of those, gdm should not depend on it.
<sadmac2> just thought of this while setting up the auth for my new workstation :D
<Keybuk> that's done by putting the gdm dep into the ypbind file
<Keybuk> e.g. today start on starting gdm; stop on stopped gdm
<sadmac2> Keybuk: ah right
<sadmac2> Keybuk: so in ypbind: before gdm
<Keybuk> exactly
 * sadmac2 doesn't like that word "before"
<sadmac2> it has very task-y semantics, which is misleading
<Keybuk> before implies there's an after, doesn't it
<Keybuk> or implies ordering
<sadmac2> yeah
 * Keybuk has to run for a bit
<notting> well, ideally it's an asbtract nss event that hides away the ypbind/ldap/krb/whatever, but... details details
<Keybuk> Fedora Rawhide broked my disk, and I need to buy a new one
<Keybuk> plus I need some food ;)
<sadmac2> Keybuk: we're hardcore like that. not everyone can handle the intensity of Rawhide
<sadmac2> that's why it says "Raw"
 * keesj will start looking into improving his state machine for upstart this week
<notting> obviously we need runtime-pluggable state machines
 * keesj remebers somebody else also was busy with something similar
<keesj> I guess I should post how we did it and get shot
<ion_> Note to self: ask Keybuk why: * nih_config_parse() now reads the file into memory, instead of using mmap().
<sadmac2> ion_: git has gotten itself into trouble with nmap before
<ion_> How?
<sadmac2> ion_: mmapping very very large things causes pain
<sadmac2> thrashing and other ugliness
<ion_> Yeah, but iâm sure nih_config_parse isnât going to read huge files. :-)
<sadmac2> ion_: one man's uninteresting use case is another man's security vulnerability
<sadmac2> why give an application the ability to crash the system, no matter how well written?
<ion_> In this case, the change seems to be to read the entire file to memory, so the case of a user passing a huge config file to the function would potentially cause even more RAM to be used than with mmap.
<sadmac2> ion_: As 4chan so elloquently puts it: OH SHI-
#upstart 2009-01-27
<sadmac> Keybuk: ping
<keesj> sadmac2: I am trying to download your state machine stuff from git but can't find the right git url http://people.fedoraproject.org/gitweb?p=sadmac/public_git/upstate.git;a=summary
<Keybuk> sadmac: hey
<keesj> sadmac: ping
<keesj> sadmac2: ping
<sadmac2> keesj: pong
<sadmac2> keesj: yeah, you had a git question while I was asleep?
<sadmac2> Keybuk: and you rang?
<keesj> indeed , what is the git url of your state machine stuff? 
<Keybuk> sadmac2: you rang
<Keybuk> <sadmac> Keybuk: ping
<sadmac2> Keybuk: ah. so I did
<sadmac2> Keybuk: I was thinking of replacements for the "before" keyword. What do you think of "meanwhile" ?
<Keybuk> lol, no ;)
<sadmac2> well pee on my parade why don't ya?
<sadmac2> keesj: git://git.fedorapeople.org/sadmac/public_git/upstate.git
<keesj> http://www.paste-it.net/public/c2b595c/ (tipical git error message)
<sadmac2> typical even
<sadmac2> keesj: git://fedorapeople.org/~sadmac/upstate.git
<sadmac2> gitweb phails at displaying url
<keesj> that worked thanks
<sadmac2> np
<keesj> hmm it's not what I hoped for :(
<sadmac2> keesj: what'd you hope for?
<keesj> more something with  states events and transitions
<sadmac2> keesj: its more predicates, implications, and events
<sadmac2> and now class
<keesj> and would it run as daemon as upstart event listener or you you see it more intergrated into upstart?
<sadmac2> keesj: I can see both
<sadmac2> keesj: but no matter. Upstream doesn't like it
<sadmac2> :D
<Keybuk> Upstream is a grumpy old man
<sadmac2> my open source life is riddled with grumpy old men
 * sadmac2 works in the company that employs Drepper
<sadmac2> Ulrich "Pointless BSD Crap!" Drepper
<Keybuk> ?
<sadmac2> Keybuk: next time you bump into uli, ask him when we'll get strlcpy in glibc
<sadmac2> Keybuk: wear a helmet.
<Keybuk> why do you want strlcpy?
<sadmac2> Keybuk: I don't particularly care really, but I don't think its an ungodly sin.
<Keybuk> once you add a function, you have to support it forever
<Keybuk> worse still is adding a function because BSD has it, when Solaris has it too and behaves differently
<Keybuk> iirc strlcpy correctly, it's a "C strings are hard, I can't be arsed, let's go shopping" kind of function
<Keybuk> it makes programmers lazyly ignore errors
<sadmac2> Keybuk: that was roughly the justification for not including it. Honestly its a fairly minor change ofer the existing str*cpy functions
<sadmac2> I just wanted it so I could compile jot from FreeBSD
<Keybuk> sure, but then you'd fail to compile something from Solaris
<Keybuk> so I can see Ulrich's point
<Keybuk> having someone who says "no" a lot in charge of libc is better than someone who always says "yes"
<sadmac2> Keybuk: agreed. there's a difference between "no" and "I'm confiscating your spinal cord" though.
<Keybuk> :)
#upstart 2009-01-28
 * Keybuk finally gets around to proving some of the bugs sadmac fixed in 0.5
<sadmac> Keybuk: which ones?
<Keybuk> $ENV's replacement being the same length as the variable name+$ for example
<sadmac> oh yes
<Keybuk> I'm going to be strict from now on ;) all bug fixes must come with test cases
<sadmac> not a problem
 * sadmac goes back to writing tests
<sadmac> Keybuk: test_com.netsplit.Nih.Test_object: tests/com.netsplit.Nih.Test_impl.c:766: my_setup: Assertion `server != ((void *)0)' failed.
<sadmac> Keybuk: I started getting these failures writing my testcases, but reverting my changes doesn't fix them
<Keybuk> err
<Keybuk> that implies your test d-bus server isn't running?
<Keybuk> have you checked it got killed ok before?
<Keybuk> usually it's test_dbus-daemon
<sadmac> I see a test_com.netspli
<sadmac> that's probably it
<sadmac> ahh, segmentation fault
<sadmac> something strangely comforting about knowing its your own fault after one of those phantom errors.
<sadmac> Keybuk: how much later will you be around?
<Keybuk> not much
<Keybuk> why?
<sadmac> Keybuk: I have the async api and one test case. I want to show it to you before I write more so I know if the API as at least right. But I have a segfault left to scrub out so its not quite ready :)
<Keybuk> cool
<Keybuk> I may be around long enough ;)
<sadmac> Keybuk: dbus_shutdown is triggering the segfault. Its being called from the teardown function (which I haven't touched). Only thing I can think of that would do it is a call to dbus_connection_read_write_dispatch (conn, -1);
<sadmac> seems like without that it didn't segfault (though the test didn't really run)
<Keybuk> that implies you've got your references mixed up somewhere
<sadmac> ah
<sadmac> what's happening then?
 * sadmac sees definite double-deref
<sadmac> dunno how that could do this, but its a bug
<sadmac> Keybuk: \o/
<sadmac> Keybuk: how do you want this then?
<Keybuk> got a bzr tree?
<sadmac> Keybuk: yeah, writing the commit notes now...
<sadmac> I had more outstanding than I thought.
<sadmac> Keybuk: https://code.launchpad.net/~cjdahlin/libnih/async
<Keybuk> ok, give me a few minutes to finish up this bit
<Keybuk> and I'll take a look
<sadmac> k
<Keybuk> urgh
<Keybuk> the valgrind attacks.  you die
<Keybuk> (not your code, mine)
<Keybuk> http://rafb.net/p/EzdMTh82.html
<Keybuk> nothing worse than an invalid write into a freed block where the write and free are inside the same function
<Keybuk> (and that function is "free" :p)
<sadmac> ot
<sadmac> *oy
<sadmac> isn't it 4am over there?
<Keybuk> yes
<Keybuk> don't you ever stay up all night hacking? :)
<Keybuk> why names?
<Keybuk> unless I'm missing something, the dispatch function doesn't take the method call arguments
<Keybuk> I'd generate a typedef for the callback function and put it in the .h file
<Keybuk> and use that
<Keybuk> if callback is NULL, should send without expected reply
<Keybuk> NihAsyncNotifyData should be in the .c file, since it should never be exposed
<Keybuk> should be typedef'd to that name
<Keybuk> member names should line up
<Keybuk> userdata -> data
<Keybuk> proxy should probably go first too
<sadmac> Keybuk: for which callback?
<Keybuk> argument to the async dispatch function
<sadmac> Keybuk: ah, nm, I misunderstood for a moment
<Keybuk> struct nih_blah_blah -> NihBlahBlah
<Keybuk> I wouldn't call it that though
<Keybuk> make it similar to the DBus Name
<Keybuk> NihDBusPendingCall or something
<sadmac> Keybuk: you omit the CamelCase form on another struct in dbus.h
<Keybuk> do I?
<sadmac> pretty sure
<Keybuk> I bet I typedef'd it first ;)
<Keybuk> NihDBusInterface?
<Keybuk> line 44: typedef struct nih_dbus_interface NihDBusInterface;
<sadmac> Keybuk: ah. so it is.
<Keybuk> I can't quite work out what you're doing with the callback definition in asyncDispatchPrototype() - a typdef would definitely help here
<Keybuk> and then it'd be obvious you've forgotten all about in_args ;)
<sadmac> Keybuk: line 1283
<Keybuk> oh
<Keybuk> they should go first
<sadmac> Keybuk: I figured put the consistent-between-all stuff first
<Keybuk> proxy, input arguments, callback, data
<Keybuk> my_str_to_int (proxy, "foo", get_int, NULL);
<Keybuk> reads the right way then
<sadmac> yeah, I can see that..
<Keybuk> you don't actually check whether the pending call completed?
<Keybuk> in fact
<Keybuk> dbus_pending_call_steal_reply doesn't return NULL to indicate out of memory
<Keybuk> it returns NULL to indicate no reply received yet
<Keybuk> in case of timeout, dbus_pending_call_steal_reply returns an error
<Keybuk> in fact, how do we deal with errors at all? :)
<sadmac> oh yeah, I hadn't done that yet had I?
<Keybuk>         # FIXME: Reply isn't the best parent for this, but proxy isn't here. 
<Keybuk> comment doesn't make sense given you use proxy ;)
<sadmac> oh, fixed it
<Keybuk> should the proxy be passed to the callback function?
<Keybuk> I think it makes sense for it to be
<Keybuk> in case the callback wants to make more calls
<Keybuk> an error handler is going to look like  void (*error_handler) (void *data, NihDBusProxy *proxy;
<Keybuk> which I guess means you have to provide both
<Keybuk> my_str_to_int (proxy, "foo", get_int, deal_with_error, NULL);
<Keybuk> but it's probably ok for the error handler to be NULL
<Keybuk> actually
<Keybuk> no it's not, let's make that required if a callback is givne
<Keybuk> nih_alloc (..., struct) -> nih_new ()!
<Keybuk> you don't provide a free function for the pending call
<Keybuk> that's kinda important, since otherwise you'll leak the async data structures
<Keybuk> the free call might want to do something like call the error handler
<Keybuk> setting some useful error
<sadmac> ok
<Keybuk> so for str_to_int, that'd look something like
<Keybuk>   my_str_to_int (proxy, "1234", int_reply, error_handler, data);
<Keybuk> with the others being
<Keybuk> void int_reply (void *data, NihDBusProxy *proxy, int num);
<Keybuk> void error_handler (void *data, NihDBusProxy *proxy);
<Keybuk> ( the error would be retrieved with nih_error_get() )
<sadmac> Keybuk: we could save a function pointer by just adding an "int succeeded" to the callback
<Keybuk> error_handler would be more consistent with other functions
<Keybuk> e.g. nih_io
<sadmac> Keybuk: did you look at the testcase?
<sadmac> there's a bit of conventional intrigue there too
<Keybuk> I did, my eyes have not recovered ;)
<sadmac> Keybuk: I do like gcc's mandate of the auto keyword in that context
<sadmac> "hey, we need to break a grammar ambiguity. Know any keywords that aren't busy?"
<Keybuk> hah
<sadmac> Keybuk: if you have a better way to structure those I'm open to it. What I like about this method is that the tests still read in the order they're run.
<Keybuk> I'll either hate it ...
<Keybuk> or convert everything else to use them ;)
<Keybuk> ngggarrrrgh
<sadmac> huh?
<Keybuk> the valgrind error can be replicated with the absolute simplest of code
<Keybuk> c = job_class_new (NULL, "foo");
<Keybuk> j = job_new (c, NULL);
<Keybuk> nih_free (c)
<sadmac> that's ugly
<Keybuk> the strange thing is that this should all just work now
<Keybuk> the whole point of refs is that if you have a pointer, you have a ref
<Keybuk> so they should collapse cleanly *sigh*
<sadmac> one thing I wish we could do (and I'm nearly certain we can't) is have a NIH_FRAME macro instead of nih_local, and you simply parented things to it to make them have a reference held by the current stack frame
<Keybuk> I considered that approach
<Keybuk> I decided nih_local was nicer
<sadmac> I like having the frame parent, but the things you'd have to do to make it work would offset any nicety.
<sadmac> you'd have to hide a var somewhere in the function somehow to run your cleanup
<sadmac> or pillage the stack manually
<Keybuk> having the frame parent feels a bit like assembler
<sadmac> or keep a costack and call everything that uses it through wrappers
<Keybuk> just saying "this is local" feels a bit like python ;)
<sadmac> I think its the word "frame"
<Keybuk> the aim is to simplify the code
<Keybuk> you'd have to do something like:
<Keybuk>   {
<Keybuk>     NIH_LOCAL local;
<Keybuk>     char *str;
<Keybuk> ...
<Keybuk>      str = nih_strdup (local, "foo");
<Keybuk>   }
<Keybuk> it kinda gets lost in the fog a bit
<sadmac> the need to declare it is what kills it
<sadmac> and that's what I can't factor out
<Keybuk> yeah
<Keybuk> if that were
<Keybuk>   {
<Keybuk>     char *str;
<Keybuk> ...
<Keybuk>     str = nih_strdup (NIH_LOCAL, "foo");
<Keybuk> that would be ok
<Keybuk> but I don't think you can declare variables right there ;)
<Keybuk> and even if you could, the second use of NIH_LOCAL would break it
<sadmac> what I /really/ wish is that you could do this:
<Keybuk> (and I see what causes this valgrind bug now ...
<Keybuk>  it's the ancient thing-is-in-a-hash-table bug)
<sadmac> void foo (char nih_local *bar) {...
<Keybuk> class->jobs is a hash table
<Keybuk> job is in that
<sadmac> and it would make bar nih_local and /ref/ it
<Keybuk> when you free job, it removes itself from the hash
<Keybuk> but if you free class, the hash should be freed first
<Keybuk> sadmac: huh?
<Keybuk> how does that work
<Keybuk> it's an arg passed in, it's inherently already ref'd by something and you don't need to care
<sadmac> Keybuk: pthread_create()
 * Keybuk wonders why this valgrind bug doesn't affect old nih_alloc
<Keybuk> timestamp: Thu 2006-12-21 00:24:05 +0000
<Keybuk> message:
<Keybuk>   * nih/io.c (nih_io_message_new): Do not assign a default list
<Keybuk>   destructor, it's not in a hidden list and there are bad consequences
<Keybuk>   of freeing a child with a default destructor if the list its in gets
<Keybuk>   freed first; new rule - default destructors only if the list is hidden
<Keybuk>   and never freed!
<Keybuk> ...
<Keybuk> especially since I apparently hit it over 2 years ago :p
<sadmac> Keybuk: if we go thread-safe, stack references are more important, because a piece of code referencing a function doesn't tell us as much about other pieces of code that might be dealing with the memory area
<sadmac> that's when things like this become interesting
<sadmac> but back to your valgrind issue... have a fix?
<Keybuk> no, not yet
<Keybuk> I'm trying to understand why it's breaking now first
<sadmac> Keybuk: while we're here, I had a hypothesis: why do you put the function types on the line above the name when defining and on the same line when declaring?
<Keybuk> common C practice
<Keybuk> grep ^function_your_looking_for *.c
<Keybuk> as a way of locating the code
<sadmac> part A confirmed
<sadmac> Keybuk: part B: do you use cscope?
<Keybuk> nope
<sadmac> mhm
<Keybuk> why?
<sadmac> Keybuk: the theory is that if you used cscope you wouldn't put the function definition on two lines'
<sadmac> Keybuk: because you'd be able to find the function no matter how it was formatted
<Keybuk> I use ctags, which are pretty much the same thing
<Keybuk> but it's something I find useful in other people's code
<Keybuk> so I do it too
<Keybuk> and it has the advantage of making a function definition really obvious
<sadmac> gives you more space for arguments too
 * sadmac used to pride himself on the distant right margin of his VB code
<sadmac> ah was I ever that young?
<Keybuk> heh
<Keybuk> my C coding style is kinda wacky really
<Keybuk> like the way I line up argument and variable names
<Keybuk> and if (! foo)
<sadmac> Keybuk: the putting spaces between function names and open parens kills me. especially now that I'm paid to be in kernel code
<Keybuk> haha
<Keybuk> someone once said that there are only two types of programmers
<Keybuk> those that put a space between function names and their parameters, and those that don;t
<sadmac> Keybuk: and the guys who wrote procmail
<sadmac> that's definitely a new species
<sadmac> fd.o's C style guidelines are pretty backward too
<sadmac> 2-space tabs? doing it wrong.
<Keybuk> here's a question for you then
<Keybuk> if you don't like foo(...)
<Keybuk> do you do for(...) ?
<sadmac> Keybuk: no, because for is yellow in vim
<sadmac> yellow things get a space before the args
<sadmac> except for sizeof
<sadmac> because linus says so
<Keybuk> sizeof shouldn't have ()s
<Keybuk> sizeof int
<sadmac> you take the size of nicer things than I do
<sadmac> sizeof(typeof(**x))
<Keybuk> typeof doesn't have ()s either
<Keybuk> besideswhich
<Keybuk> sizeof/typeof is meaningless
<Keybuk> sizeof **x
<Keybuk> is the same
<sadmac> ...whoa...
<sadmac> you're right
<sadmac> Keybuk: what about those people that name the function arguments outside of the declaration header?
<Keybuk> those people need to stop denying the 80s happened
<sadmac> or go code COBOL in a hole somewhere
<sadmac> HOLBOL?
<Keybuk> arguments outside the header is old-style K&R C
<Keybuk> we program in ANSI C nowadays
<sadmac> sort of
<sadmac> Keybuk: can we add cscope.out to the ignorefile?
<Keybuk> no ;)
<Keybuk> for the same reason I don't put TAGS in there
<Keybuk> (you should only ignore output expected to be generated by the ordinary build process)
<sadmac> Keybuk: does bzr have a local ignore?
<Keybuk> I don't think so
<sadmac> damn
 * sadmac misses git
<Keybuk> oh, yes
<Keybuk> ~/.bazaar/ignore
<sadmac> cool
<sadmac> bug!
<sadmac> as soon as I added a line to ~/.bazaar/ignore, all the object files showed up in bzr status
<Keybuk> oh, I think that's deliberate
<Keybuk> bzr has a built-in global ignore
<Keybuk> if you make a new one, it overrides bzr
<sadmac> can I source the normal one?
<Keybuk> hmm
<Keybuk> did you not have a .bazaar/ignore already ?
<Keybuk> you just did echo > .bazaar/ignore
<Keybuk> didn't you?
<sadmac> FUUUUUUUUUUUUUUUUUUUUUUUUUUUU
<Keybuk> rm it
<Keybuk> run bzr ignored
<Keybuk> then edit it ;)
<sadmac> superior usability!
<Keybuk> you can't use that word
<Keybuk> you like git
<sadmac> I /can/ however use my vcs
 * sadmac uses interactive rebase to do obscure things you can't even imagine in O(1)
<Keybuk> I can use git too, I just strongly dislike it
<Keybuk> Linus tells you not to rebase
<Keybuk> he says every time someone rebases, he kills a kitten
<sadmac> interactive rebase is better than rebase
<sadmac> it basically lets you put everything in the repo in any order you want.
<sadmac> its like using ed on the object files, but you can play louder techno music
<Keybuk> you're not supposed to fuck with the repo
<sadmac> I don't get much other action, and the repo understands my needs
<sadmac> don't judge me, what we do is beautiful
<Keybuk> :D
<sadmac> oh /repo/. I thought you said horses.
<Keybuk> how equus of you
<sadmac> I don't think he actually fucked the horse.
<sadmac> He stabbed the horse. He rode the horse naked.
<sadmac> Not sure you could stage a fucking in the way that play was supposed to be staged
<Keybuk> no idea
<sadmac> its kind of a funny image actually...
<sadmac> http://www.asiaarts.ucla.edu/media/images/EQUUS%201.jpg
<sadmac> that's pretty funny already. If that broke down into some hardcore I'd be seriously amused.
<Keybuk> heh
 * Keybuk spots the basic difference between old nih_alloc and new nih_alloc
<sadmac> o yeah?
<Keybuk> revno: 455
<Keybuk> committer: Scott James Remnant <scott@netsplit.com>
<Keybuk> branch nick: libnih
<Keybuk> timestamp: Mon 2007-10-15 23:14:14 +0100
<Keybuk> message:
<Keybuk>   * nih/alloc.c (nih_alloc_using, nih_alloc_reparent, nih_realloc):
<Keybuk>   Change the order in which children allocations are stored in the
<Keybuk>   list such that the last allocation is freed first rather than
<Keybuk>   the other way around.  This solves issues of children being stored
<Keybuk>   inside an allocated hash table which will be freed first.
<Keybuk> in other words, old nih_alloc frees things in the opposite order to that they are allocated in
<sadmac> that working implies that the parenting ordering is a subset of the allocation ordering
<sadmac> its perfectly possible to:
<sadmac> 1) allocate item with no parent
<sadmac> 2) allocate hash table
<sadmac> 3) stick item in hash table
<sadmac> in which case this would break
<Keybuk> yeah I never really fixed the original bug
<Keybuk> I just kept moving it around every time I noticed it ;)
<sadmac> what you should do is not free the memory right away but put it into some kind of list, and then free everything in the list only when its know that all the references are stable.
<sadmac> nih_free (void *item)
<sadmac> {
<sadmac>         static int rec_depth = 0;
<sadmac>         ...
<sadmac>         rec_depth++;
<sadmac>         ...
<sadmac>         nih_insert_item_into_free_list(item);
<sadmac>         if (! --rec_depth) {
<sadmac>                 nih_free_all_free_list();
<Keybuk> yeah, that's the plan
<Keybuk> finalise the object first
<sadmac> Keybuk: where do I move the NihAsyncNotifyData struct so it shows up in the C files?
<Keybuk> you might have to define something to do that
<sadmac> mmh
 * sadmac thinks about rewriting all this with a templating engine again
<Keybuk> ...with child in older sibling list
<Keybuk> BAD: block 0xacd108 (child->entry.next) freed unexpectedly
<Keybuk> 	at tests/test_alloc.c:243 (child_destructor_test).
<Keybuk> sweet
<sadmac> have a testcase then?
<Keybuk> I think so
<Keybuk> though one passes but fails valgrind
<Keybuk> oh, hah
<Keybuk> because I'm an idiot
<Keybuk> my test case uses TEST_FREE_TAG ... which uses nih_alloc
<Keybuk> can't test nih_alloc with TEST_FREE_TAG you dolt
<Keybuk> right
<Keybuk> I now have two test cases
<Keybuk> that both work
<Keybuk> if you use _add () the first test case fails
<Keybuk> if I change it to _add_after () the second test case fails
<sadmac> Keybuk: ok, last I saw I asked about typedefs
<Keybuk> I didn't see that
<sadmac> <sadmac> Keybuk: is there a place to put the typedefs for the callbacks
<Keybuk> anything above that?
<sadmac> 01:43  * sadmac fixes a longstanding problem with his vimrc
<sadmac> then before that you said you were an idiot
<Keybuk> heh
<Keybuk> not sure if there's a place in the python code
<Keybuk> I certainly meant to have one, but may not have added that func
<Keybuk> should go at the top, before externPrototypes
<sadmac> I'm sleeping now.
<Keybuk> heh
<Keybuk> I'm just about to do that
<Keybuk> I'm worried
<Keybuk> my code worked first time
<Keybuk> Upstart's test suite largely works too
<Keybuk> there's a few failures, but I don't _think_ they are related
<Keybuk> (and frankly, the d-bus stuff works - and that really abuses nih_alloc :p)
<Keybuk> http://bazaar.launchpad.net/%7Escott/libnih/trunk/revision/639
<Keybuk> in summary: first call all the destructors, then free them all
<Keybuk> but rather more efficient without the need to recurse ;)
<Keybuk> right
<Keybuk> you and me, valgrind...
<sadmac> Keybuk: what about you, him, and valgrind?
<Keybuk> going to fix these remaining test case failures
<Keybuk> I'm also trying to decide whether it's a bug to call nih_free () on an object with a parent
<Keybuk> ion_: what do you think?
<ion_> Iâd lean on only allowing to free by unrefing.
<ion_> uh, towards
<Keybuk> what if you never allocated it with a reference in the first place? :)
<sadmac> Keybuk: I'd lean toward /that/ being a bug
<sadmac> or rather impossible
<Keybuk> well, you have to start somewhere?
<ion_> Ah, right, parentless objects donât have a reference.
<ion_> Hmm
<Keybuk> otherwise you'd need a global reference, which is basically the same as NULL ;)
<sadmac> Keybuk: exactly
<Keybuk> so why not use NULL?
<Keybuk> the disadvantage of a global reference, and the reason nih_alloc doesn't have one, is that valgrind thinks the object is in use ;)
<sadmac> Keybuk: yes. Use NULL by all means.
<Keybuk> so doesn't bitch if you forget to free
<Keybuk> that was the other main reason I opted for "nih_local" and NULL rather than NIH_LOCAL as the parent
<sadmac> Keybuk: you could have a debug mode where you htonl() the refs that are from the root object
<Keybuk> huh?
<sadmac> Keybuk: "encrypt" references from the root object when -DDEBUG so valgrind can't read them
<ion_> How about just making unref() free parentless objects, and behave as before with objects with parents?
<Keybuk> that involves having a debug mode though ;)
<Keybuk> ion_: nih_unref (ptr, NULL) type thing?
<ion_> Or maybe make nih_free barf if the object has parents?
<Keybuk> or make nih_free only do something if the object has parents?
<ion_> How should it be used then?
<ion_> If you nih_new() without a parent and nih_free() it, nothing would happen, right?
<Keybuk> I mean if the object hasn't parents
<Keybuk> so nih_free() matches nih_new(NULL, ...)
<sadmac> Keybuk: what's the difference between what you get from nih_alloc(NULL, ...) and what you have in nih_unref() when you've removed the last ref and its about to be freed
<Keybuk> and nih_unref() matches nih_ref() or nih_new(ptr, ...)
<Keybuk> sadmac: none
<Keybuk> if you like, nih_alloc (NULL, ...) gives you something that's unreferenced, but not free
<Keybuk> a bit like gobject's sunken ref ;)
<sadmac> Keybuk: that's my issue. its identical to the dead state
<Keybuk> it means you can allocate something, add a reference, and then not worry about it
<Keybuk> you don't have to drop your own
<sadmac> Keybuk: IMHO such an object persisting for any amount of time is as bad as a pointer to already freed memory persisting for any amount of time.
<Keybuk> it varies
<Keybuk> some reference-counting systems are strict
<Keybuk> when you allocate, what you have returned has a single reference
<Keybuk> if you pass that to anything and it takes a reference, it must add *another* reference
<Keybuk> and if you don't want it anymore, you *must* drop the single reference you had when it was allocated
<Keybuk> D-Bus's is like that
<sadmac> Keybuk: why does nih_unref() free the object then?
<Keybuk> the problem with these is that it's easy to forget to drop the reference you got when you allocated it, or easy to forget to take one when you want it
<sadmac> Keybuk: its a valid object still
<Keybuk> so others have the concept of a floating reference
<Keybuk> when you allocate, what you have has only a floating reference
<Keybuk> if anything references it, the floating reference is sunk and turned into a real reference
<Keybuk> so when you pass it to things that take a reference, it gets turned into a real one
<Keybuk> and since that happens, you don't need to worry about unrefing when you don't want it anymore
<Keybuk> ...
<Keybuk> non-deliberately, nih_alloc turns out to be a bit like the last one
<Keybuk> you can allocate with a reference, or without
<Keybuk> if you allocate without, it kinda behaves like a non-explicit floating reference
<Keybuk> in reality, it's an unreferenced objetc
<Keybuk> this works nicely for things like nih_local
<Keybuk> since that only discards unreferenced objects
<Keybuk> indeed, there's a call for - nih_discard() - which is a safety "I'm done with an unreferenced object, but am not sure that anyone else took a reference" call
<Keybuk> and you can return an object to unrefernced as well - nih_unref_only ()
<Keybuk> this is all a bit ... strange really ;)
<Keybuk> it's what happens when you design an API by evolution
<sadmac> Keybuk: I can see the argument for it existing, but I don't like it as a long-term condition
<Keybuk> especially when you turn a simple halloc rip-off, into a talloc rip-off into something that afaik is unique
<sadmac> Keybuk: I'd like to think of it as mid-transaction database inconsistency
<sadmac> Keybuk: its an error for such a thing to exist, but we defer the error on the grounds of "it'll not be that way anymore in a few lines"
<ion_> Perhaps rename nih_free as nih_discard (deleting the present nih_discard) to avoid confusion and make it free the object if it has no parents.
<Keybuk> ion_: err, that would be exactly what nih_discard does right now, no? :p
<ion_> Indeed.
<Keybuk> though would it error if it has parents?
<sadmac> Keybuk: so rather rename nih_discard to nih_free, and kill the current nih_free
<Keybuk> (nih_discard doesn't)
<ion_> No, ignore it if it has parents.
<ion_> It shouldnât be called nih_free if it might not free the object IMO.
<Keybuk> nih_free always frees right now
<Keybuk> even if it has parents
<Keybuk> I tend to agree there though, nih_free would be a bit odd if it didn't always free
<ion_> Yes, i suggest getting rid of it. :-)
<sadmac> Keybuk: nih_free not always freeing is weird
<sadmac> Keybuk: but if you have an interest in API consistency (and it /is/ kind of convenient that we don't have to rewrite all that much right now) it might be better to keep the old symbol/
<ion_> So the norm would be to nih_discard anything you allocated without a parent, and nih_unref anything you referenced. No nih_free.
<Keybuk> heh
<Keybuk> I just made nih_free assert
<Keybuk> (if there were parents left)
<Keybuk> lots of things broke
<ion_> :-)
<Keybuk> mostly test cases, by the looks of it
<sadmac> Keybuk: what I would prefer is that if you are going to allocate without a parent, you /must/ assign the pointer to an nih_local. dunno what C gives us to enforce that though.
<Keybuk> dunno, dig through the gcc ref manual ;)
<sadmac> I've learned to like that thing
<sadmac> Keybuk: I wonder what happens if you do void * nih_local my_func () {...
<Keybuk> the attribute will apply to the function instead of the return value
<sadmac> Keybuk: but it can't because its not a function attribute
<Keybuk> so gcc will error
<Keybuk> return types don't have variable attributes ;)
<sadmac> probably
<Keybuk> the __attribute__ binds right
#upstart 2009-01-29
<Keybuk> whoah
<Keybuk> now I've hit a segfault that looks like mr pointer went west
<ion_> Thought flow: West. Go west. Someone should feed Go West to Songsmith and post it to Youtube.
<Keybuk> huh?
<ion_> You havenât seen the numerous Songsmith versions of songs on Youtube?
<Keybuk> nope
<Keybuk> exampel?
<ion_> http://www.youtube.com/watch?v=YSWmh9ZTLOY http://www.youtube.com/watch?v=_V1DuHUs22Q http://www.youtube.com/watch?v=itsT9zgWRoM http://www.youtube.com/watch?v=ypycpKQxXR0 http://www.youtube.com/watch?v=e1e_h1OJfS4 http://www.youtube.com/watch?v=6iCJHTzH5DY http://www.youtube.com/watch?v=WmC28cXWqLc http://www.youtube.com/watch?v=Um6WeRFC934
<Keybuk> wonderfully bad
<ion_> Yeah
<ion_> So, what was the segfault problem?
<Keybuk> not sure yet
<Keybuk> it's uninitialised data
<Keybuk> which is surprising
<Keybuk> I was expecting write to freed memory
<Keybuk> it _is_ happening inside a destructor though
<Keybuk> (gdb) p source->files->bins[4]
<Keybuk> $52 = {prev = 0x7fff2454a6f0, next = 0x7fff2454a6f0}
<Keybuk> hah
<Keybuk> now, how the hell does that happen?
<Keybuk> ohhhhhhhhhhhhhhhhhhhhh
<Keybuk> I know what that is
<Keybuk> that's a list iterator!
<Keybuk> this is the bug I knew there was with cursors in NIH_LIST_FOREACH_SAFE
<Keybuk> that makes me happy
<ion_> How is the bug triggered?
<Keybuk> iterating a linked list while iterating a linked list with NIH_LIST_FOREACH_SAFE
<Keybuk> honestly, the real problem here is that the ConfFile destructor is bogus
<Keybuk> it does all sorts of heavy work, which really isn't appropriate
<Keybuk> destructors are for cleaning up a structure, not for going around and restarting other jobs ;)
<ion_> Yeah...
<ion_> 2009-01-26 22:38:22 < ion_> Note to self: ask Keybuk why: * nih_config_parse() now reads the file into memory, instead of using mmap().
<Keybuk> truncate a file while it's mmapped and try reading from it ;)
<ion_> Ok
<sadmac> Keybuk: take file lock?
<Keybuk> sadmac: how does that help?
<Keybuk> file locks only work if everyone co-operates
<sadmac> Keybuk: never mind
<Keybuk> you can core the process with just :> filename
<ion_> At least the command is happy.
<Keybuk>                 /* Mark the job to be deleted when it stops, in case            
<Keybuk>                  * it cannot be deleted here.                                   
<Keybuk>                  */
<Keybuk>                 file->job->deleted = TRUE;
<Keybuk> ...
<Keybuk> what does _that_ do?
<Keybuk> this whole job deletion stuff always scares me
<Keybuk> it's just a bag or corner cases
<ion_> Heh
<Keybuk> aha
<Keybuk> this makes sense
<Keybuk> conf_file_new () doesn't do anything with a job
<Keybuk> so the destructor bloody well shouldn't either
<Keybuk> code gets easier to understand by being less clever
<sadmac> Keybuk: can you make the alloc system error when someone tries to code this way?
<Keybuk> I don't see how
<Keybuk> sweet
<Keybuk> nih and upstart are now valgrind-clean
<sadmac> nice
<Keybuk> fixed the issue where test_job_process sometimes locks up too
<sadmac> ah. don't remember that one
<Keybuk> damn
<Keybuk> grepping for usage of nih_free() and many of these are quite valid
<Keybuk> 1) clean-up in case of function error
<Keybuk> but most importantly
<sadmac> Keybuk: shouldn't that be an nih_local thing now?
<Keybuk> 2) hanging workers
<Keybuk> sadmac: not really, since the parent is passed in
<Keybuk> here's an example of #2
<Keybuk> nih_io_reopen (job, ...)
<Keybuk> ie. create an nih_io structure that's a child of job, but never actually make job know about it
<Keybuk> it's just doing something on job's behalf
<Keybuk> nih_timer_new (job, ...)
<Keybuk> in fact, I do this for just about everything
<Keybuk> if you free job, the io or timer are automatically cancelled and cleaned up
<Keybuk> but they're only doing work on its behalf
<Keybuk> many of them are handled from the main loop and self-free
<Keybuk> timer's a good example, the main loop frees timers
<sadmac> hm
<Keybuk> also NihError relies on its quite heavily ;)
<Keybuk> but then NihError is an aberration since it's the only part of libnih you can't reference <g>
<Keybuk> (except you can now - but don't <g>)
<sadmac> Keybuk: ...I have complete working code in another project for try{}catch{}
<Keybuk> using setjmp?
<sadmac> yeah
<sadmac> its amazing what it does to clean up code. especially with the wrapper macros.
<Keybuk> usually try looks something like
<Keybuk> setjmp, if (! error)
<Keybuk> and catch something like
<Keybuk> if (error)
<sadmac> not quite
<sadmac> its if (! error)
<sadmac> and else if (error == foo)
<sadmac> and a bunch of for loops which don't loop but throw code after the block.
<sadmac> but once all the bits are in place
<sadmac> if (! bytes = read(...)) { /* handle error in 2 or 3 lines */ }
<sadmac> becomes bytes = e_(read(...))
<Keybuk> why read?
<sadmac> Keybuk: just an example.
<sadmac> Keybuk: I have 2 or 3 character wrappers to turn all the varying POSIX errno-based semantics into exception throws
<Keybuk> ah
<Keybuk> why e_?
<Keybuk> oh, I see
<Keybuk> dpkg has something a bit different
<Keybuk> you push cleanup handler functions with push_cleanup()
<Keybuk> and you set checkpoints
<Keybuk> if an error occurs, you call ohshit() or ohshite()
<Keybuk> that rolls back to the last checkpoint, calling up cleanup handlers on the way
<sadmac> Keybuk: I do memory management that way :)
<sadmac> Keybuk: Memory is allocated on obstacks, and then simply forgotten about, like it had been malloc'd and there was a garbage collector
<sadmac> Keybuk: and then at a few points in the program, particular obstacks are simply dumped out completely
<Keybuk> it was one of my original ideas for nih_alloc
<Keybuk> that the contexts would match the error handling contexts
<sadmac> there's a few cases it doesn't work for. but I'm ok with it varying
<sadmac> Keybuk: have you looked at the way lisp does exceptions?
<Keybuk> no?
<sadmac> Keybuk: its something like this:
<sadmac> on_error("fooerror") do { /*closure*/ }
<sadmac>  /* stuff that might trigger error */
<sadmac> restore_handler("fooerror")
<sadmac> we could do it in C, but to do it right we'd need nested functions and pointers thereto (read: trampolines (read: executable stack (read: in pid 1 (read: cancer))))
<Keybuk> err
<Keybuk> ??
<sadmac> Keybuk: they call it signals, and it works a bit like unix signals.
<sadmac> Keybuk: you install a function to handle a particular type of error.
<sadmac> Keybuk: but its lisp, so this can be done for very granular short-term cases
<sadmac> (because defining a function in lisp is simple)
<Keybuk> and the function lasts for the inner scope?
<sadmac> Keybuk: in most cases. If it makes sense to install a global function as an error handler you do it
<sadmac> Keybuk: but the big technical difference is you don't rewind the stack when you get an error. You execute the handler in place. meaning its more likely that you can get at state info and see what happened
<sadmac> You then have the /option/ to rewind the stack.
<Keybuk> yeah, I often wish you could do that with exceptions in Python
<Keybuk> except KeyboardInterrupt:
<Keybuk>   bank
<sadmac> bank?
<Keybuk> any language that has a "pass" keyboard should have a "bank" keyword ;)
<sadmac> ...I get the sense there's a language barrier here.
<sadmac> is this a British pun?
<Keybuk> you have "Weakest Link" in the US, right?
<sadmac> we did for a bit
<sadmac> don't think we do anymore
<sadmac> which is sad
<Keybuk> ahh
<sadmac> because it was awesome
<sadmac> Keybuk: in this system it would look like (in python
<sadmac> on_error("KeyboardInterrupt", lambda: pass)
<sadmac> # go about your business
<sadmac> Keybuk: http://www.gigamonkeys.com/book/beyond-exception-handling-conditions-and-restarts.html
<Keybuk> I love my test suite
<sadmac> I like it too
<Keybuk> I feel nice and safe about making far sweeping changes
<sadmac> what far sweeping changes are you making now?
<Keybuk> I was just thinking in terms of rewriting the fundamental function call that manages memory
<sadmac> what will you change?
<sadmac> right now isn't it just a realloc?
<Keybuk> no, I mean what I've changed
<Keybuk> ie. the switch to multi-reference nih_alloc
<sadmac> ah.
<Keybuk> gnargh
<Keybuk> I wish gcc could understand the TEST_ALLOC_FAIL loop
<sadmac> what's it doing wrong?
<Keybuk> it thinks variables can be unused
<Keybuk> err, used unused I mean
<Keybuk> used uninitialized
<Keybuk> :)
<sadmac> we got there eventually
<sadmac> damn. every time I commit a 2-line change to a Fedora Infrastructure project, they give me commit access, and it comes with a mailing list that emails me every time someone changes something
<Keybuk> heh
<Keybuk> we have similar problems
<Keybuk> customer bugs as generally private at first, since they often involve NDA hardware
<Keybuk> so if you want to read the bug (or have to), they join you to the team working on that hardware
<Keybuk> which usually means you get flooded with all the bug traffic, commits,e tc.
<sadmac> heh
<sadmac> Our IT system at work has public and private comments.
<sadmac> Public are... public. Private can be seen by me (the engineer), and either an L2 or a TAM
<sadmac> If its an L2, you give your usual nerdy harshing-shit-up spiel about the problem, and the L2 tells the customer in much more polite terms
<sadmac> TAMs get you in trouble.
<sadmac> rh.com email, but they live, work, and eat with the people having the issue.
<sadmac> You try to whisper through them and then realize they're on the other side.
<Keybuk> Yeah I've heard about that
<sadmac> Its all good, I mean, we're all "on the same side"
<sadmac> its just a tone selection.
<sadmac> Keybuk: what error should I raise if the reply hasn't been received somehow within the callback?
<sadmac> Keybuk: I almost think it should be an nih_assert, since why would dbus have called us if there was no reply?
<Keybuk> hmm
<Keybuk> if the reply is corrupt you mean?
<Keybuk> or missing entirely?
<sadmac> Keybuk: dbus_pending_call_steal_reply returns the reply or NULL if none received.
<Keybuk> ah, yeah, I'd assert on that one()
<sadmac> ok
<Keybuk> a more interesting question is what do you do when the arguments in the reply don't match what you're expecting <g>
<Keybuk> (call the error handling with the NIH_DBUS_INVALID_ARGS error)
<sadmac> the current type error raises ENOMEM. I don't know how that works out...
 * sadmac was pretty sure that part of the code was copypasta...
<sadmac> also neither of the error conditions for the marshaller unref anything before returning
<Keybuk> they all get attached to the message object, I think
<Keybuk> which gets unref'd
<sadmac> mem_error unrefs reply but type_error doesn't
<sadmac> I'm in ur black box, bein white?
<Keybuk> dunno, I'd have to read the code again ;)
<sadmac> Keybuk: nih_free is type void and takes one type void* right?
<Keybuk> returns an int
<Keybuk> and takes void *
<sadmac> ah, that explains that
<Keybuk> oh?
<sadmac> Keybuk: why it wasn't a valid DBusFreeFunction
<Keybuk> heh
<Keybuk> yeah
<Keybuk> of course, shouldn't that be nih_discard? :)
<sadmac> Keybuk: I hate you >:(
<Keybuk> why?
<sadmac> stupid discard is for poopy-heads
<Keybuk> heh
<sadmac> Keybuk: go look at that async branch again
<sadmac> bzr+ssh://bazaar.launchpad.net/~cjdahlin/libnih/async/
<sadmac> Keybuk: did you get that?
* Keybuk changed the topic of #upstart to: Upstart 0.5.1 "Unexpected item in bagging area"
<Keybuk> sadmac: I got your branch URL
* Keybuk changed the topic of #upstart to: Upstart 0.5.1 "Unexpected item in bagging area" | http://upstart.ubuntu.com/
<sadmac> Keybuk: ok, there was nothing after that
<sadmac> Nice release name
 * sadmac hits McDonalds
<sadmac> bbs
<sadmac> I return
 * Keybuk shall just brain dump review again
<Keybuk> you still have the extra names() functions, what are those about?
<sadmac> Keybuk: for bulk-passing a group of variables to a function
<sadmac> Keybuk: where using vars would yield foofunc(int foo, int bar)'
<Keybuk> do you use it anyway?
<sadmac> using names would yield foofunc(foo, bar)
<Keybuk> oh, I see
<sadmac> I use it
<Keybuk> mem_error/type_error
<Keybuk> you raise the errors then return
<Keybuk> which means the errors will get eaten somewhere inside libnih-dbus
<Keybuk> I expect you meant to call the error handler there?
<Keybuk> style, errno = ENOMEM, nih_error_raise_system () - instead of doing it by hand
<sadmac> Keybuk: line number?
<Keybuk> 1363..
<Keybuk> also missing _() around NIH_DBUS_INVALID_ARGS_STR on 1369
<sadmac> Keybuk: copypasta. That should be your code
<sadmac> Keybuk: I don't think it gets it. its defined with N_ already
<Keybuk> N_ just marks for translation
<Keybuk> N_ stuff needs _() called on it later
<Keybuk> userdata -> data
<Keybuk> NihAsyncNotifyData -> NihDBusPendingCall ?
<sadmac> Keybuk: I dunno about that one
<sadmac> I don't think those are the same thing
<Keybuk> NihDBusCallback_%s -> YourFunctionNameInCapsCallback
<Keybuk> NihDBusErrback_%s -> YourFunctionNameInCapsErrorHandler
<sadmac> is there a underscore-to-camel converter in this already?
<Keybuk> probably not
<sadmac> one liner
<Keybuk> wouldn't bother with the async_notify_data_free function
<Keybuk> just cast it
<Keybuk> cf. nih-dbus/dbus_connection.c
<sadmac> Keybuk: cf. ?
<Keybuk> compare to
<sadmac> ok
<Keybuk> can you stick a changelog entry on that, and I'll merge it
<sadmac> Keybuk: I had just casted nih_free before, and then I moved to the function. If you pop off the top commit you get that one fixed.
<sadmac> I'll do a revert commit and then add the changelog and push
<Keybuk> if you can be reasonable detailed (at least describe each new function, etc.) that would be muchly appreciated
<sadmac> Keybuk: pull
<sadmac> and now sleep
<keesj> morning
<suihkulokki> Keybuk: http://repository.maemo.org/pool/fremantle/free/u/upstart/
<keesj> suihkulokki: doing maemo stuff?
<suihkulokki> keesj: yes
<keesj> as maemo platform developer?
<ion_> Nokia is both cool and extremely evil.
<keesj> suihkulokki: I also work on upstart for an embedded platform. 
<keesj> ion_: it greatly depends at what side of Nokia you look.
<keesj> suihkulokki: are you also going to fosdem?
<suihkulokki> keesj: unfortunately not this year
<keesj> alright
<keesj> I am looking into the problems faced while creating as state machine inside upstart
<keesj> I currently implmented as upstart job but that gives a few problems
<keesj> first of all I can't recieve all events becasue the events don't get send while my state machine is running. for example I did start on event_a or event_b and if emit event_a and event_b one after the oder I can miss the second event
<hiciu> I have problem with upstart on armv4 machine (Neo Freerunner)
<keesj> what kind?
<hiciu> as far as I can see the code works up to line 308 here: http://pastebin.com/d6558c132
<hiciu> then it jumps here: http://pastebin.com/d7dbb1990
<hiciu> on screen I can see everything up to last "return!"
<hiciu> and it stops
<hiciu> any idea how to debug it?
<hiciu> (the code if from: http://upstart.ubuntu.com/download/0.5/upstart-0.5.0.tar.bz2, compiled with "--exec-prefix=/ --enable-compat=sysv")
<Keybuk> hiciu: does "make check" pass?
<hiciu> I will check that now
<keesj> does that mean that event is NULL?
<keesj> hiciu: given the arguments I guess you must be using sbox or compiling on the target?
<hiciu> yes
<keesj> the only configure magic I have going is adding export ac_cv_func_malloc_0_nonnull="yes"
<keesj> but I can't remember why..
<keesj> but the configure doesn't use it
<keesj> suihkulokki: acting dead mode is battry charging?
<hiciu> I mean, under 'sbox2' :)
<hiciu> in event_new, on return event != null
<hiciu> but it does not pass tests: http://pastebin.com/d2154bba0
<Keybuk> you might need to do some porting
<keesj> ./.libs/libnih.a: could not read symbols: File in wrong format??
<Keybuk> keesj has Upstart working on ARM, I believe?
<keesj> yes, I have it running without modifs on qemu-arm and arm11
<hiciu> http://pastebin.com/d5b909a81
<suihkulokki> keesj: da
<suihkulokki> maemo also has upstart workin on arm (obviously)
<suihkulokki> but that still 0.3.x
<keesj> hiciu: how do you run upstart anyway under qemu?
<keesj> (I run a full system including a kernel)
<hiciu> i'm running it on freerunner
<hiciu> ok, I will try to build it on freerunner (on device, not crosscompiling) later (when I manage to boot freerunner ;]).
<hiciu> in meantime, simple bash script should work
<hiciu> thanks for help! :)
<keesj> :P
<keesj> Keybuk: would it be possible to listen to /(and consume) to all the events perfomed by upstart?
<keesj> much like 0.3.9 had "initctl events" but with the addition that the event only get probatated once the "jobs" consumed the event
<keesj> why can't I gdb --pid 1 ?
<sadmac2> keesj: kernel too old?
<sadmac2> keesj: (its veeery recent that they made that actually work)
<sadmac2> like, during the end of the 0.5.0 dev cycle that started working for me
<keesj> thanks for the tip . so .28 or something?
<sadmac2> keesj: not quite that recent
<sadmac2> 27, maybe late 26
<keesj> alright 
<KDesk> hi
<KDesk> Will upstart 0.5 be in Jaunty?
<sadmac> KDesk: I don't think so
<KDesk> hi sadmac, isn't it ready, is the version 0.3 better?
<sadmac> KDesk: its proven a bit shaky so far (0.5.1 should fix a /lot/ of that). Keybuk could tell you more if he were around
<KDesk> sadmac oh, hopefully the new upstart will be in ubuntu some time in the future. Thanks for your explanation.
<mbiebl> Keybuk: hi
#upstart 2009-01-30
<Keybuk> KDesk: hi
<keesj> Morning
<keesj> today is d-day for me and my upstart state machine...
<keesj> my goals is to get events queued so I can emit multiple events to a task scripts and be able to handle then all
<keesj> something like http://www.paste-it.net/public/tf5a413/ 
<keesj> but I guess "start" should be renamed to "queued start"
 * Keybuk still doesn't know what you're doing
<keesj> I have one upstart "job" that acts like a state machine its' called change_handler and listens to many external event (emit usb_detected stuff like that) , that state machine is used to support swiching between different "runlevels" (boot|mass_storage|main_app)
<Keybuk> the built-in one doesn't work for you?
<keesj> next to that I have emtpy state_boot state_mass_storage,,, jobs and services that depend on those state jobs
<keesj> and all the change_handler does is determin the currently running state and the event and stop one state and start a different state
<keesj> built-in state machine?
<Keybuk> well, pretty much the point of upstart is that it does that kind of thing internally
<keesj> well I do use it a lot for simple service depenencies but that is not enough
<keesj> (trying to explain why..)
<keesj> well it's also what the sysv replacement does
<keesj> would it help if I send a mail to the mailing list explaining the problems I have?
<Keybuk> sure
<keesj> I really boils down to the http://upstart.ubuntu.com/getting-started.html on bounce example not wokring 
<Keybuk> it doesn't?
<keesj> no
<Keybuk> I don't see a bug about that anywhere
<keesj> well it's not like there is a definitive list of the syntax of the files so I would know what to expect to be honest
<Keybuk> http://upstart.ubuntu.com/wiki/Stanzas
<keesj> This page corresponds to upstart 0.3.9. The syntax and job control mechanisms is greatly improved in 0.5.0. 
<Keybuk> ...if only it were a wiki ;)
<keesj> I did edit some parts of that 
<keesj> on that page the console also had non existent options 
<Keybuk> seriously though, if something isn't working, then a bug should be filed
<keesj> ok suppose the on bounce would work and would take 5 seconds to run and I emit 5 bounce withing one second , what should the behaviour be?
<Keybuk> depends on what you do in bounce
<Keybuk> you either want just one running at a time
<Keybuk> so use the default behaviour
<Keybuk> you want one running for each bounce
<Keybuk> so add "instance ..." to your job
<Keybuk> or you want one running at a time, but if bounce occurs while it's running, it needs to be run again (but only once no matter how many bounces occur)
<Keybuk> so instance and exec watershed
<keesj> if I would like a single instance to be run 5 times would that be possibe?
<Keybuk> sure, in 0.3.x just add "instance" to the job
<keesj> I am on 0.5
<keesj> 0.5.1 even
<Keybuk> that's a bit more tricky, you need to add something to the bounce to instance on
<Keybuk> which is a bug in 0.5
<Keybuk> well, more of a misdesign
<keesj> hm. can you explain a little more?
<Keybuk> in 0.5, you have to have something to define the limits of the instance
<Keybuk> it doesn't let them be unlimited
<Keybuk> so in the bounce example, you'd have to include (for example) a BOUNCENUM variable that changed for each one
<Keybuk> then the job could have instance $BOUNCENUM in it
<keesj> but woudl that run the jobs in parallel?
<Keybuk> yes
<keesj> what I reall woudl like is that this task gets executed 5 time
<Keybuk> that works in 0.3 and will work again by 0.10
<keesj> writing the mail..
<Jc2k> wg 8
<Keybuk> bah, that one's less fun than "win"
<keesj> I guess what needs doing for the Stanzas is to Create 2 pages one for 3.8 and one for 0.5
<keesj> https://lists.ubuntu.com/archives/upstart-devel/2007-March/000241.html tels that "on EVENT" was removed
<Keybuk> yes, in all versions of upstart since 0.2, "on" has been identical to "start on"
<keesj> I am trying to implement some hack/proof of concept for the handler. From my current understanding what needs to happen is that I need to block events to a jobs instance while it is running as handler
<keesj> so increasing the blocker on start and decreasing it on stop when that job is defined as ... "handler"
<Keybuk> I'm not sure what you mean by "block events"
<Keybuk> jobs don't "receive" events
<Keybuk> but they can have their state changed by them
<keesj> what I want to happen (I guess) is that in event_poll (in event.c) the event gets skipped because there are "bockers"
<keesj> blockers
<Keybuk> then it would be missed
<keesj> and would be removed from the queue?
<Keybuk> right
<Keybuk> events can be held in the queue while things are processing them
<Keybuk> but that's after job states have been changed
<keesj> do you understand the difference between "my" state machine and the upstart states?(I think that mainly the logic to perform a state change is put in a script)
<Keybuk> no
<Keybuk> I shall read the mails later ;)
<sadmac2> Keybuk: around?
<Keybuk> briefly
<Keybuk> what's up?
<sadmac2> Keybuk: was anyone working on the dbus properties code?
<Keybuk> me
<Keybuk> right now
<Keybuk> that depends on variant code
<Keybuk> which is what I'm trying to figure out
<sadmac2> Keybuk: ok. I'll leave that to you then
<sadmac2> Keybuk: variant code?
<Keybuk> properties use variants
<Keybuk> right, bbl
#upstart 2009-01-31
<sadmac> blist online
<sadmac> whoa... wrong window
#upstart 2009-02-01
<sadmac> Keybuk: pull the async branch again for all the fixes you requested, a couple more, and a pile of test cases
<Keybuk> sweet
<Keybuk> with changelogs? :p
<sadmac> damnit. I knew I forgot something.
<sadmac> Is there a way to change the arguments bzr passes to diff?
<Keybuk> bzr diff --help ;)
<Keybuk> (--diff-options iirc)
<sadmac> aah
<sadmac> now to figure out what git passes to it to show the function name for each hunk...
<sadmac> Keybuk: all set now. go get em.
#upstart 2010-02-01
<ion> O hai
<ion> keybuk: A couple of small changes: https://code.edge.launchpad.net/~ion/ubuntu/lucid/upstart/lucid
<sadmac2> Keybuk: you're alive!
<ion> You guys might get a kick out of a hack i did: âevilâ implements âreferenceâ without branching. http://gist.github.com/290066
<ion> An excellent introduction to Erlang, btw: http://www.viddler.com/explore/rentzsch/videos/8/
<Keybuk> hi
<Keybuk> I am
<Keybuk> very much alive - and very much refreshed
<Keybuk> holidays FTW
<ion> Good to hear
<sadmac2> Keybuk: I just got my first upstart 0.6/SELinux clash bug today. We're leaking pipes.
<sadmac2> why O_CLOEXEC wasn't the default behavior in POSIX... well, actually there's weirder shit in POSIX to wonder about.
<ion> Someone should form a committee to design a better POSIX!
<sadmac2> ion: one day when I gain superpowers I will submit a giant patch to linux introducing a second process tree with better semantics and interfaces.
<sadmac2> then we can phase POSIX out altogether
<soren> I'm curious.. Has any thought been put into the impact on memory requirements caused by running a whole bunch of things in parallel rather than sequentially?
<sadmac2> soren: the majority of those things are long running processes.
<Keybuk> sadmac2: which pipe is being leaked?
<soren> sadmac2: I'm not sure what significance that has?
<sadmac2> Keybuk: dunno yet. It could quite possibly be something inside of libdbus
<sadmac2> soren: eventually they'll all be running in parallel anyway.
<soren> sadmac2: True.
<sadmac2> soren: I doubt there's anything interesting to explore in that avenue, but if you'd care to measure something it might be interesting to look at.
<soren> sadmac2: We're just seeing a problem somewhere that might be due to everything running in parallel rather than sequentially. I'm not entirely sure yet.
<Keybuk> sadmac2: at some point, upstart will use the newer syscalls that I can specify the cloexec flag
<Keybuk> when I have some time
<Keybuk> *cry*
<sadmac2> Keybuk: yeah.
 * Keybuk plans to beg for upstart time next cycle
<sadmac2> Keybuk: I've been having some nasty interruptions to my coding time lately, the last one involving a new car and some bruised ribs that I really need to get looked at.
<soren> sadmac2: Short story: We have some virtual machines with 256 MB of RAM and no swap.. During boot, the OOM killer gets invoked for some reason.
<sadmac2> but my airbags were in working order, which was nice to find out.
<Keybuk> soren: fsck probably
<Keybuk> fsck consumes terabytes of memory
<Keybuk> its why things try so hard to activate swap first
<soren> sadmac2: ...and one of the working hypotheses is that it's caused by things being run in parallel that used to be run sequentially. I don't really buy that hypothesis, but was just curious about the general problem.
<soren> Keybuk: Interesting.
<sadmac2> soren: you'd have to instrument and see. certainly upstart has tools to serialize out stuff if you need them. certainly those tools could get better if there's many people like you.
<sadmac2> but yeah, counting up how many of those things you're running are tasks which will actually release memory in the short term would help test your theory.
<Keybuk> perf ftw
<soren> Keybuk: These should be clean images, though. fsck shouldn't be doing anything other than telling me that everything is fine and that it won't bother with a proper check.
<soren> Keybuk: "perf"?
<sadmac2> "performance"
<sadmac2> the genre of debuggering you're entering into
<soren> Ah, I thought it was a reference to another tool in Keybuk's shiny magic box of tools.
<sadmac2> there might be a perf tool called perf. I think there is.
<soren> Perhaps. It's not in ubuntu.
 * sadmac2 doesn't have it
<sadmac2> soren: there's oprofile, which is awful, but also the only thing that does what it does. Thankfully your problem isn't suited to it.
<sadmac2> soren: and there's systemtap, which may come into play here
<sadmac2> <3 systemtap
<Keybuk> it comes in the kernel source
<sadmac2> It keeps me employed, and as things people pay for go, its not so bad to work with
<soren> sadmac2: How can systemtap be useful here? This it the first time I've heard of it.
<sadmac2> soren: hard to say. Its problem scope is gigantic.
<soren> I see.
<sadmac2> soren: it lets you write custom trace programs
<soren> sadmac2: I'm curious about your "things people pay for" remark. We have it in Ubuntu, so it must be free software?
<sadmac2> soren: for your issue though, getting top running early enough would do it.
<sadmac2> soren: people pay me to /use/ it
<sadmac2> soren: I'm a support engineer. I solve fiddly performance issues in a hurry while the customer's hair is on fire.
<sadmac2> fiddly...
 * sadmac2 notices his diction getting Britisher now that Keybuk is back
<soren> sadmac2: Ah, I see what you mean.
<soren> sadmac2: As for getting top to run that early, I think that will be hard. The OOM killer gets upset quite early.
<soren> smoser: can you reproduce this problem in a regular VM?
<smoser> yes. under "normal" kvm
<sadmac2> soren: actually, just turn on kdump and disable the OOM killer, and let it core. the crash dump tool should be able to get you what you need.
<smoser> lucid: http://pastebin.com/f16fba185
<smoser> karmic: http://pastebin.com/f5d42cbf8
<soren> Maybe a low-tech approach would do: Run a script very early on that dumps the output of "ps -eFl" somewhere every 0.1 seconds and go and look at it afterwards?
<smoser> ^^^ output of ps -eo pid,vsz,args
<Keybuk> sadmac2: perf is the new systemtap
<sadmac2> Keybuk: really?
<sadmac2> its hard to google because google expands "perf" into "performance"
<sadmac2> "prioritize results with the least amount of interpolation" doesn't seem to have made it into google's secret sauce.
<ion> Google for +perf
<sadmac2> as of 2005 the readme declares it dead.
<sadmac2> OR there's 2 things called perf
<sadmac2> Keybuk: ah, this is looking familiar
<sadmac2> Keybuk: I think you have it wrong though. This looks like the new oprofile, not the new systemtap
<smoser> soren, http://pastebin.com/f37a27768 is updated with i386 
<Keybuk> it's the new systemtap too
<Keybuk> there's nothing you can do with systemtap that you can't do with perf_event/trace_event
<sadmac> Keybuk: I'll be interested to test that.
 * sadmac remembers to check the RHEL 6 kernel packages for it
#upstart 2010-02-02
<Grimsqueaker> I am trying to make an upstart script in Ubuntu Karmic for Virtualbos-OSE 3. Basically I want it to start up some virtual machines on boot, respawn them if they die, and save their state / shut them down if the box shuts down. My current script is http://pastebin.com/m8e8fd79.
<Grimsqueaker> Can anyone help out? Its not working when I boot the box.
<keesj> Keybuk: going to FOSDEM ?
<JanC> he's probably in the US now, not sure he will be back in time
<JanC> although he's very welcome of course  âº
<keesj> He did a talk last year so I guessed he might 
<JanC> they are at a sprint in Portland AFAIK
<sadmac2> where in the US is he?
<keesj> I did not do so much upstart work in the last year.
<sadmac2> Even I've not done all that much
<ion> Washington, it seems.
<sadmac2> graduation, $dayjob, life's been interesting
<sadmac2> ion: as in DC?
<ion> A GeoIP lookup puts his IP address at 45.9420,-122.6720 with no guarantee of accuracy of any kind, of course.
<sadmac2> ion: smart money puts him in Portland
<ion> Indeed, a whois lookup on the IP address says the block is owned by a company in Portland, Oregon.
<sadmac2> ion: you're a good stalker
<JanC> I know there is a sprint with lots of Canonical people in Portland, so I supposed he was there  ;)
<ion> sadmac: On the Internet, perhaps. :-P
<JanC> anyway, I'm not sure exactly when it ends
<JanC> I will be at FOSDEM, but I guess that's less important for keesj...   ;-)
<keesj> I don't really know :p 
<ion> Meanwhile, /me is amazed of how easy failover between computers is in Erlang: http://ftp.sunet.se/pub/lang/erlang/doc/design_principles/distributed_applications.html
<JanC> ion: well, that's what Erlang was designed for
<ion> Obviously, but it could have been made much more difficult by worse designers.
<JanC> true
 * sadmac2 tries to think of actual relevant products coming out of Ericcson proper.
<sadmac2> non-pure functional languages kind of worry me. Its an opportunity to not really "get" functional programming.
<JanC> sadmac2: their mobile phones & TV sets have a pretty good reputation AFAIK  ;)
<keesj> last years FOSDEM I really had fun with ADA. I wonder what this year will bring , JanC is that TOR related to the tor proxy?
<sadmac2> JanC: the mobile phones are Sony-Ericcson, which is a very different animal
<sadmac2> JanC: not sure about the TVs
 * sadmac2 knew a Sony-Ericcson employee
<JanC> sadmac2: now yes, my brother had an Ericsson mobile phone for years, and they don't make any like that anymore  ;)
<sadmac2> keesj: ADA? as in the programming language? (I'd think not)
<sadmac2> JanC: brick-o-phone?
<JanC> it wasn't too big, but you could throw it against a brick wall and it would still work  :P
<JanC> I think they still use Erlang for (mobile) telephony switches though?
<ion> Iâm sure Erlangâs telephony infrastructure stuff has a good reputation. They boast 99.9999999 % (ânine ninesâ) reliability for some products. And having learned about the workings of Erlang, i can see how such reliability can be achieved.
<JanC> thats' why they designed it after all
<sadmac2> My dad used to work on that stuff at Alcatel
<JanC> I mean, Nokia telephony switches ran on Windows in the past (not sure if that's still true)
<JanC> or was it their SMS software or whatever
<JanC> I always found that weird  ;-)
<sadmac2> don't hear much from them these days actually. There's the n900, but I don't encounter it often.
<ion> (1 â 99.9999999 %) years = 30 milliseconds, btw. :-)
<Keybuk> keesj: unlikely ;)
<Keybuk> I am, indeed, in Portland, OR
<sadmac2> Keybuk: if you were in DC I'd tell you to move your departure to RDU and come take a bus and see me.
<Keybuk> no, the better coast
<sadmac2> Keybuk: you're not even a citizen yet and you're already a regional snob? :)
<Keybuk> "yet" ?
<JanC> so, who else outside of keesj & me comes to FOSDEM?  âº
<sadmac2> Keybuk: yet!
<Keybuk> sadmac2: I don't think there's any way for me to *become* a citizen
<sadmac2> Keybuk: don't you know? after about your 25th trip in we just shanghai you.
<sadmac2> Keybuk: going to Japan has me feeling nice and rosy about the US immigration process. There's 10th generation Koreans over there who aren't citizens.
<sadmac2> Keybuk: its impossible in the literal sense. If your parents aren't Japanese, neither are you. Period. Forever.
<Keybuk> huh?
<Keybuk> I was referring to the US
<JanC> sadmac2: that's weird, as at least 50% of the people in Japan are actually Korean ((pre-)historically speaking) ;)
<keesj> the n900 is rly great (and runs upstart)
<keesj> 0.3.8 that is
<sadmac> Keybuk: yes. I conducted a massive segue.
<Keybuk> right
 * Keybuk has no degree, no phd, etc.
<Keybuk> means no immigration
<Keybuk> no visa
<JanC> Keybuk: there is always the lottery IIRC ?  ;)
<JanC> or was that in Canada
<Keybuk> that's Canada I think
<Keybuk> US uses a points system, and I have zarro points
<JanC> ah, well, who cares  ;)
#upstart 2010-02-04
<ion> Woot, an implementation of Cucumber for Erlang. Thatâll be useful for me. http://github.com/northscale/cucumberl/blob/master/features/sample.feature http://github.com/northscale/cucumberl/blob/master/src/sample.erl
<sadmac2> Keybuk: suppose I have a job A, and a job B that's start on starting A, and B has post-start exec stop 
<sadmac2> post-start exec stop A *
<sadmac2> Keybuk: expected behavior, IMHO, is that B prevents A from starting, and runs instead.
<sadmac2> Keybuk: actual behavior is not, what are your thoughts.
<Keybuk> that a bug was filed about that yesterday
<sadmac2> Keybuk: probably by rstrode notting or plautrba :)
<sadmac2> Keybuk: I'd have filed it but I thought I might've just been doing it wrong.
 * sadmac2 doesn't see it in his launchpad mail
<Keybuk> no, by one of our developers
<sadmac2> Keybuk: hmm. funny we hit that at the same time.
<Keybuk> might be in a slightly different way
<Keybuk> but basically trying to do the same things
<sadmac2> think B ended up killing itself instead of A
<notting> sadmac2: correct,that's what happened AFAICT
<notting> sadmac2: erm
<notting> if you pass --no-wait, it stops itself. if you don't pass --no-wait, it hangs :)
<sadmac2> ah
<sadmac2> that makes sense. Its waiting for itself to stop, which can't happen because it can't progress beyond post-start until its done waiting
<sadmac2> my first thought was that it was ignoring the argument and stopping $UPSTART_JOB instead of the target
<sadmac2> but that all looks right.
<sadmac2> come to think of it, running initctl stop with no arguments will cause some funny things won't it...
<sadmac2> depending on where you do it.
<Keybuk> no.
<sadmac2> Keybuk: whatever terminal you are running is most likely the descendant of some upstart task, so it probably has an UPSTART_JOB of god knows what (most likely the getty or X session, which is actually ok)
<Keybuk> ?
<Keybuk> UPSTART_JOB isn't used if the command has arguments
<sadmac2> Keybuk: right. so if you happen to type "stop" in a terminal with no arguments, the results might be strange.
<Keybuk> sometimes
<Keybuk> in practice, most top-level things are good at sanitising their environment before running things like shells
<sadmac2> good to know.
<Keybuk> PAM does it, for example
<Keybuk> so if you have a PAM session, you have the env cleaned up
<sadmac2> polkit I'd assume the same?
<Keybuk> right
<smoser> Keybuk, https://bugs.launchpad.net/ubuntu/+source/linux-ec2/+bug/510130 and https://bugs.launchpad.net/ubuntu/+source/linux-ec2/+bug/510130
<JanC> smoser: that's 2x the same (guess you wanted to point to 2 different bugs)
<smoser> oops.
<smoser> https://bugs.launchpad.net/ubuntu/+source/mountall/+bug/509841 was the other
<traviscline> does anyone have an example nginx upstart file?
<traviscline> anybody have an apache upstart example?
<traviscline> it seems to me having more examples of typical servers would be a Good Thing
<sadmac2> traviscline: upstart changes api a lot. The result is we don't encourage people to actually /use/ it per se :)
<traviscline> i just upgraded from 0.3.9 and was using it for apache and varnish
<sadmac2> traviscline: what distro?
<traviscline> but upped to 0.6.2 so i could use the expect fork / daemon stuff
<traviscline> ubuntu, 9.10
<traviscline> when starting nginx (which daemonizes) with expect daemon the start just hangs
<traviscline> even though it starts it
<sadmac2> traviscline: doesn't it come with startup scripts? are you building yourself?
<sadmac2> traviscline: try expect fork instead.
<traviscline> i did, trying again
<traviscline> start hangs
<traviscline> with expect fork
<traviscline> and doesn't start it
<traviscline> ctl-c'd it -- it thinks the job is running now
<traviscline> stopping hangs
<sadmac2> traviscline: are you sure this job is running?
<sadmac2> *forking
<traviscline> ctl-c'd - marked as not running
<traviscline> when i just run 'nginx' it returns immediately
<traviscline> and starts at least 2 processes
<traviscline> running both start and stop with -v produce no additional output
<traviscline> here's strace output https://gist.github.com/586c7d3aff64c7e46429
<sadmac2> traviscline: no clone call
<traviscline> that does mark the job as running though
<traviscline> sadmac2: sorry, not familiar
<traviscline> is that nginx's fault?
<sadmac2> traviscline: the strace doesn't show anything forking. at all.
<traviscline> sadmac2: https://gist.github.com/586c7d3aff64c7e46429 that's it when i don't run it with start
<traviscline> this is my job https://gist.github.com/084de4d8d90ab87d6cc9
<sadmac2> traviscline: there's no use stracing the start command.
<traviscline> ok
<traviscline> any input on debugging paths?
<traviscline> or should i punt because upstart isn't ready for real use?
<sadmac2> traviscline: try strace -f
<traviscline> output looks appoximately the same
<traviscline> approximately*
<sadmac2> ...that's not right...
<sadmac2> that makes no sense in fact
<sadmac2> it should tell you what both sides of the fork do
<traviscline> sadmac2: with -f https://gist.github.com/586c7d3aff64c7e46429
<sadmac2> traviscline: no start
<traviscline> or did you want that on vanilla nginx (not start)
<traviscline> gotcha
<sadmac2> traviscline: stracing start makes no sense. It'll just tell us what the start command is doing. It tells us nothing about nginx
<traviscline> sadmac2: i see, sorry. https://gist.github.com/586c7d3aff64c7e46429 there it is with -f
<sadmac2> expect fork should do it.
<sadmac2> something odd happens to the first fork though
<sadmac2> Keybuk: any idea what's up with 6396 in that strace?
<traviscline> might be the same as this https://bugs.launchpad.net/upstart/+bug/406397
<traviscline> anyhow, it looks like there isn't an easy fix and i'll just use supervised to keep services up
<traviscline> or something like it
<Keybuk> sadmac2: probably getting stuck with fork following
<Keybuk> either by SIGCHLD handler, or because the job does something weird
<Keybuk> like fork/exec something else first
<sadmac> Keybuk: figured that much. It is weird in that we end up with two daemon processes, but with expect fork I'd think we'd be done tracing before that stuff happened
* Keybuk changed the topic of #upstart to: Upstart 0.6.5 "Our last, best hope for victory" | http://upstart.ubuntu.com/
#upstart 2010-02-05
<rittyan> hi all, is there some debhelper or cdbs thingie to install upstart jobs to the right place?
<rittyan> I could use install file, but I don't want to (not the right place in fact)
<rittyan> or, probably package.upstart will do the trick
<Md> rittyan: read the dh_installinit documentation
<rittyan> yup, found it already
<rittyan> thanks
<sadmac> Keybuk: for future reference, we have this policy: http://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath
<sadmac> Keybuk: not that I have an opinion but its making libnih kinda annoying to package.
<Keybuk> err, why?
<Keybuk> (not why don't you like rpath, but why are you getting one?)
<sadmac> Keybuk: I didn't do anything interesting when I built it
<Keybuk> wing-commander scott% objdump -x /lib/libnih.so | grep RPATH
<Keybuk> zsh: done       objdump -x /lib/libnih.so | 
<Keybuk> zsh: exit 1     grep RPATH
<Keybuk> I have no rpath
<sadmac> Keybuk: its libnih-dbus and nih-dbus-tool which its finding them in
<Keybuk> noep
<Keybuk> wing-commander scott% objdump -x /usr/bin/nih-dbus-tool | egrep "NEEDED|RPATH"
<Keybuk>   NEEDED               libnih.so.1
<Keybuk>   NEEDED               libexpat.so.1
<Keybuk>   NEEDED               libdbus-1.so.3
<Keybuk>   NEEDED               libpthread.so.0
<Keybuk>   NEEDED               libc.so.6
<Keybuk> wing-commander scott% 
<sadmac> ERROR   0001: file '/usr/lib64/libnih-dbus.so.1.0.0' contains a standard rpath '/usr/lib64' in [/usr/lib64]
<sadmac> ERROR   0001: file '/usr/bin/nih-dbus-tool' contains a standard rpath '/usr/lib64' in [/usr/lib64]
<Keybuk> oh
<Keybuk> well
<Keybuk> that's your busted distribution
<sadmac> don't think the template spec is doing anything beyond configure/make/make install
<Keybuk> if you're going to invent things like /usr/lib64 you need to tell your dynamic linker about it, etc.
<sadmac> notting: ^^what is this shit?
<notting> context?
<Keybuk> libtool only puts an rpath in if you install into a path it doesn't recognise as a system library path
<notting> usually it's libtool being shite
<sadmac> notting: is there a standard fix?
<Keybuk> notting: hardly
<Keybuk> if Fedora bothered to send patches upstream, you wouldn't have this problem ;)
<Keybuk> even when I was libtool upstream, we patiently waited for Fedora/RH to submit http://cvs.fedoraproject.org/viewvc/devel/libtool/libtool-2.2.6a-rpath.patch?view=log
<Keybuk> but nobody ever did
<notting> you were libtool upstream? i don't know whether to blame you or send booze
<Keybuk> sadmac: you should be able to apply that patch to m4/libtool.m4 in libnih's tree
<Keybuk> notting: once :)
<Keybuk> sadmac: you'll need to re-run autoconf afterwards to regenerate configure
<Keybuk> then it should not rpath lib64
<notting> you can cheat and do 'make LIBTOOL=/usr/bin/libtool'. but that obviously can have version-skew
<sadmac> the page I linked recommends a couple of sed lines. I'm afraid... but it is policy...
<Keybuk> you can
<Keybuk> all of these are valid
<Keybuk> but it's not _my_ problem ;)
<sadmac> Keybuk: my mistake
<Keybuk> strictly speaking, of course, your policy is wrong
<Keybuk> since /usr/lib64 is *not* a standard library directory
<Keybuk> you should have rpaths for it
<Keybuk> since otherwise libraries and binaries compiled on RH won't work on other distros ;P
<sadmac> the sed things don't work.
<Keybuk> but I digress
<sadmac> makes the build choke
<notting> Keybuk: the compiler thinks it's standard
<Keybuk> notting: only because you have a patch to your compiler
<sadmac> Keybuk: kernel32.dll doesn't work in ubuntu either :) distro-compatibility is a pipe dream.
<Keybuk> sadmac: sure it does, apt-get install wine ;)
<Keybuk> sadmac: is the sed for libtool 1.5 or 2.x ?
<sadmac> Keybuk: try libc.dylib :)
<sadmac> Keybuk: unspecified.
<sadmac> Keybuk: snippets floating in wikispace unknown and unloved
<notting> Keybuk: i could bring up the LSB stick, but, bleah.
<notting> but yes, the proper solution is to patch upstream libtool releases, get that in every distro, and make everyone redist their packages. wheee.
<sadmac> ugh. my apartment can be either 40 or 80 degrees. the thermostat ignores intermediate values.
<Keybuk> notting: sure
<sadmac> damn it to hell.
<sadmac> rpmbuild is eating the error output of patch
<sadmac> oh. oh wow. that is unfortunate.
<sadmac> makes sense though
<sadmac> %prep doesn't define the patch macros at all.
<sadmac> no, this is %build hold on..
<sadmac> I haven't built a new package in a while.
<ion> Fedora/RH could always switch to dpkg.
<sadmac> ion: coke, pepsi, whatever.
<sadmac> IMHO if the difference between your old package manager and your new one is any smaller than the difference between rpm and conary you're an idiot to switch
<sadmac> which is not to say you should switch to conary
<sadmac> Point is I can't in good faith support Jesse not seeing his kid for 2 months so we can switch to a /slightly better RPM/
<sadmac> besides, the package manager I want to use I haven't written yet.
<ion> I was joking, of course.
<sadmac> ion: all in good fun :)
<sadmac> Keybuk: the pkgconfig stuff ended up in lib rather than lib64 too :( guess we didn't fix autoconf either.
<sadmac> Keybuk: ah, this one is your fault
<Keybuk> why?
<sadmac> Keybuk: you defined pkgconfig's data path explicitly in Makefile.am
<Keybuk> yes
<Keybuk> if you put it in the wrong path, that's your fault :)
<sadmac> Keybuk: is there a separate list for libnih development now?
<Keybuk> no
<sadmac> Keybuk: good. patch is on upstart-devel
#upstart 2010-02-06
<Keybuk> patch?
<Keybuk> the patch is wrong
<sadmac> maybe. The important thing is that I submitted it though.
<sadmac> :)
<Keybuk> I name thee Casey "Android" Dahlin
<Keybuk> strictly speaking, you could do this in Fedora's config.site
<Keybuk> something like
<Keybuk> test $pkgconfigdir = '${prefix}/lib' && pkgconfigdir='${prefix}/lib64'
<Keybuk> etc.
<avb> hey all
<avb> guys, any ways do debug startup process?
<avb> couple days ago i upgraded my karmic desktop to lucid, now boot process stucking somewhere
<avb> and i have no idea what is the error is
<avb> screen is just blank
<avb> and there is a blanking cursor on it
<avb> no ttys is activated
<avb> no gdm
<sadmac> my screwy recursion scheme works!
#upstart 2010-02-07
<keesj_> \
#upstart 2011-01-31
<Lion-Simba> Hi all. Is there any command in Upstart to reset job hanging in "stop/killed" status?
<Lion-Simba> I'm trying to write my own job file for my service, and it don't work well yet. So, I need to debug it, but now I've stuck with this "stop/killed" state.
<ion> Upstartâs current fork-tracking code is preliminary and gets confused easily. You probably used the âexpectâ stanza claimin a certain style of daemonizing and the behavior of your main process was different. Can you reboot?
<ion> http://heh.fi/tmp/workaround-upstart-snafu if not.
<ion> â# workaround-upstart-snafu nâ, where n is the pid âstatus jobnameâ says, given that no such process actually exists.
<Lion-Simba> Yes, I can. But I'm not very happy to do it every time during development.
<ion> If youâre not absolute sure of the forking behavior of the main process, itâs better to make it not fork and not use the âexpectâ stanza.
<ion> ly
<Lion-Simba> WOW! I've just started workaround-upstart-snafu without arguments... and it start output a lot of numbers (pids?) and not interruptable by ctrl+c
<Lion-Simba> Not quite good behaviour..
<ion> pkill -f workaround
<ion> I never said itâs a good program. :-) As the name says, itâs a workaround.
<Lion-Simba> Ok. It's died. )
<Lion-Simba> But... â# workaround-upstart-snafu n' not helped.
<Lion-Simba> Same numbers.
<ion> Updated the file. Now it shouldnât behave incorrectly when given no parameters.
<ion> Exactly what does âstatus jobnameâ print?
<Lion-Simba> root@dahari:~# status stargazer
<Lion-Simba> stargazer stop/killed, process 12148
<ion> What does âps -p 12148â print?
<Lion-Simba> Oh. It's over. I used workaround-upstart-snafu 12148 and wait a bit longer, letting it proceed with numbers. :) Now status is stop/waiting. Thank you. :)
<cr3> when I run an upstart job on hary, initctl start doesn't return to the shell and just leave me hanging. if I ctrl-c, the process I exec'ed in my upstart job is running fine though
#upstart 2011-02-01
<SpamapS> Aha!
 * SpamapS is thinking about shutdown and sysvinit compatability...
<SpamapS> ... /etc/init.d/rc could emit upstart events for each thing it does, allowing upstart jobs to depend on sysvinit events.
<SpamapS> Keybuk: btw, welcome to California! :)
<Keybuk> SpamapS: yeah, I thought about that
<Keybuk> but decided that people would rely on those events too much
<Keybuk> and it would be better for the init scripts themselves to emit properly named events
<SpamapS> True
<SpamapS> would be good to have opposites to the startup events..   remote-filesystems  unmounted-remote-filesystems .. etc. One thing though, they need to be hook points in shutdown because it needs to block on them.
<Keybuk> yeah, I'm not saying it's a bad idea
<Keybuk> I just didn't do it because my plan was to get rid of the shutdown init scripts, so adding things that relied on their names would have defeated that
<SpamapS> Keybuk: are you interested in working on eliminating the sysvinit shutdown? Seems like you have more pressing, interesting things to do right now. :)
<SpamapS> Keybuk: btw.. Andalu .. best restaurant in SFO :)
<Keybuk> SpamapS: I'
<Keybuk> I'm interested, but as you say, time right now is limited
<Keybuk> time will grow as time goes on, of course
<Keybuk> my focus *should* probably be on getting upstart2 finished and released
<Keybuk> robbiew: howdy
<robbiew> Keybuk: ahoy
<Keybuk> how's it going?
<robbiew> Keybuk: eh...it's going...still doing too many jobs :/
<Keybuk> yeah, though you must be doing them well
<robbiew> Keybuk: damn cold today
<Keybuk> sunny here in the south bay! :D
<robbiew> Keybuk: it's sunny here too...just freezing
<robbiew> will blow through in a week or so
#upstart 2011-02-02
<twb> Is "pre-start exec" allowed (instead of "pre-start script")?
<twb> Also: WTF just happened: stop gitit ==> stop: Method "Get" with signature "ss" on interface "org.freedesktop.DBus.Properties" doesn't exist
<JanC> twb: yes
<JanC> an no clue about the DBus error  ;)
<JanC> and *
<twb> OK, thanks
<twb> I think it was pissed because I said "script end" instead of "end script"
<twb> http://paste.debian.net/106276/
<twb> Though strangely, it isn't writing anything to the logfile now I rotated it
<JanC> hm, how does it log?
<twb> not via syslog(3)
<twb> I think it opens it directly
<twb> http://paste.debian.net/106277/
<twb> This is on lucid, btw
<JanC> hm, and with savelog -p the permissions should be right too, I suppose
<twb> Hmm, even if I run gitit as root, it doesn't write to that file
<twb> Strace can see it opening the log, though
<twb> open("/var/log/gitit.log", O_WRONLY|O_CREAT|O_NOCTTY|O_APPEND|O_NONBLOCK, 0666) = 7
<JanC> is it supposed to write anything in absence of errors?
<twb> Ah, I think the original 271 bytes were logs of *init*
<twb> i.e. subsequent boots don't print anything, even for GETs
<twb> I give up.
<twb> BTW, do you know how to not have the extra su process hanging around?
<twb> http://paste.debian.net/106278/
<JanC> yes, but not sure if upstart will like that  ;)
<twb> Tell me and I'll check
<twb> Also re logging, it was because 'log-level: WARNING' is the default.
<JanC> basically, su is waiting for the process it starts to end
<twb> Why doesn't it do a forkless exec of sh -c?
<twb> I'd use sudo instead, but I'd prefer to avoid the syslog noise from sudo
<JanC> you can run gitit in the background
<JanC> but upstart might not like that  ;)
<twb> Yeah, obviously that's no good
<JanC> I doubt the su process does any harm to your system anyway  ;)
<twb> Sure, it's just ugly
<anchepiece> hi all, does anyone know where the upstart/initctl status is saved? like the association between the daemon and the pid.  i have a incorrectly stopped init that is now giving the 'start/killed' with a non-existant pid
<anchepiece> i was hoping to clear the config somewhere
<JanC> it's "saved" in memory only
<JanC> http://heh.fi/tmp/workaround-upstart-snafu might be useful 
<SpamapS> anchepiece: just stop the job .. 
<SpamapS> Oh I see.. can't kill the pid that doesn't exist. Interesting.
<SpamapS> JanC: where did that workaround-upstart-snafu script come from btw?
<JanC> SpamapS: ion pointed to it a couple of days ago
<SpamapS> Seems like init would know about any pids it was tracking dying.
<JanC_> grrr, why does my ISP insist on 36-hourly disconnects...  :-(
<JanC_> SpamapS: ion pointed to it a couple of days ago
<JanC_> I guess it's his script
<JanC> maybe it was tracking the wrong pid though?
<anchepiece> SpamapS: i cant find that script online anymore
<anchepiece> have a copy
<anchepiece> ?
<JanC> anchepiece: if you mean the snafu script, it's still there?
<anchepiece> the url is 404
<JanC> not from here...
<JanC> you in some place where internet is filtered?
<anchepiece> ah its back!
<anchepiece> thanks
<anchepiece> well it just spawns infinit threads
<SpamapS> JanC: my point is that even if it was tracking the wrong pid.. if the pid it is tracking dies.. it will know and respawn or not .. 
<anchepiece> i think ill wait till a reboot and leave the renamed daemon 
<SpamapS> anchepiece: so status foo shows a pid that doesn't exist?
<SpamapS> anchepiece: or status foo shows infinite pids ?
<JanC> SpamapS: it won't (always) respawn infinitely though
<anchepiece> status foo shows a pid that doesdnt exist
<SpamapS> JanC: right, I'm more saying that I can't see a situation where upstart shows a pid that is dead in status.
<anchepiece> the workaround-snafu prints out an increasing number (new pids?)
<SpamapS> seems like a bug somewhere.
<SpamapS> that workaround-snafu may take forever on a system that uses pseudo random pids.
<JanC> I've never seen it happen myself
<anchepiece> the bug was my fault (putting an expect fork when there shouldnt have been, then prematurely ctrl-c killing the stop command when it stalled)
<anchepiece> no it increments
<JanC> SpamapS: yeah, in theory it can as well take 100 years or something  ;)
<anchepiece> ie: start/killed, process 13790 ./workaround-upstart-snafu 13790  prints out the next pid available past 13790 like 22xxx then counts up as it creates new pids
<SpamapS> interesting
<anchepiece> going to leave it running just to see what happens
<anchepiece> ok it dropped back to 1000s
<anchepiece> now i understand how it works
<JanC> it tries until a process with that PID exists
<JanC> then we hope upstart gets unconfused  ;)
<anchepiece> it did, but it respawned the old conf
<JanC> it's normally used for a slightly different issue though
<anchepiece> nowe stop is hung 
<anchepiece> i think this tool will work
<JanC> upstart needs a built-in "unbreak" command I guess  ;)
<anchepiece> well maybe a non-ruby dependant version of the script will do
<JanC> that should be easy enough
<JanC> it just forks until a process has the requested PID
<SpamapS> JanC: the issue is that upstart can only do anything if a process's parent pid is 1.. it does that by either keeping it in the foreground, or ptrace attaching.. so somewhere, it detached from the process without making sure it was dead. That seems to be the bug.
<anchepiece> it worked -> status: Unknown job:
<anchepiece> thanks for help
<SpamapS> anchepiece: glad its resolved for you.. but thats pretty ugly.. forking through the whole pid namespace. :-P
<SpamapS> err.. pid space..
<JanC> SpamapS: that's why it's called a workaround  ;)
<anchepiece> and now respawning on a crash is working perfectly
<anchepiece> i vote to add that script or a bash variant to the release package 
<JanC> fixing the bug would be better  ;)
<anchepiece> a long-term state of stopped/killed with a pid may be a clue
<JanC> a command to tell upstart it has to forget or force the status of 1 particular job could be useful too
<JanC> but of course that's still a workaround
<SpamapS> Yeah
<SpamapS> better workaround
<SpamapS> It actually may be this bug https://bugs.launchpad.net/upstart/+bug/539175
<SpamapS> but.. in reverse
<anchepiece> https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/438313    https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/504989   https://bugs.launchpad.net/upstart/+bug/406397  
<SpamapS> anchepiece: thanks.. that does look like the problem
<ion> The real fix is the proc connector implementation that Just Worksâ¢. Meanwhile, people just need to use âexpectâ only when theyâre 100Â % sure of the forking behavior of their main process.
<SpamapS> given the response tho
<SpamapS> the existence of a "verify pids" workaround seems needed
<SpamapS> also it would make sense for init to just verify that its signal was acted on by checking the entry in /proc if available
<ion> Backups are needed for people who delete important stuff by mistake. Yes, people shouldnât delete important stuff by mistake.
<ion> Anyhoo, a clean patch that is not too nasty a kluge might make it into Upstart.
<ion> â¦if Keybuk approves it, of course. :-)
<Keybuk> what do I have to approve?
<ion> People have been suggesting that Upstart check the pids it thinks itâs tracking actually exist as a workaround when people confuse Upstart with incorrect use of âexpectâ. That is, until the proc connector implementation is there, of course. I said your approval is needed for a patch if someone feels like creating one.
<Keybuk> how would it "check" the pid?
<ion> In any case, it would be a kluge. I didnât really give thought to how to avoid a race condition etc.
<Keybuk> reminds me that I must finish my new supervisor code, give that to everyone to play with
<ion> The proc connector code?
<yuantai> Hello! I hope I'm in the right channel. I have a question on upstart. I have a daemon to monitor the power status. It needs to intercept shutdown/reboot event, i.e. runlevel 0 and 6, and before network goes down, it needs to report to a centralized server. My question is: in upstart how to I define "before network goes down and after shutdown/reboot"?
<yuantai> Or can someone point me to the right place/mailing list to ask the question? Thanks!
<anchepiece> yuantai: i think if you stick around a bit someone will have a good answer for you.. 
<anchepiece> i think yuo can throw a script into here though: /etc/network/if-down.d
<anchepiece> /etc/network/if-down.d/upstart i mean
<yuantai> thank you anchepiece,
<yuantai> I'm doing it on a RHEL6 machine, it doesn't have the /etc/network/if-down.d/upstart. Is it only in Ubuntu? 
<anchepiece> http://upstart.pastebin.com/vz8hq557
<SpamapS> yuantai: how about start on starting rc RUNLEVEL=[016]   ?
<anchepiece> thats the initctl emit
 * SpamapS doesn't know if RHEL6 uses rc either :-P
<anchepiece> that file is in marked executabe in /etc/network/if-down.d/ dir
<yuantai> Thanks SpamapS, it seems RHEL6 also uses rc.
<SpamapS> yuantai: note that that will make it run *before* the shutdown commences
<SpamapS> yuantai: but, as soon as your job finishes, the rc will start and shutdown
<yuantai> anchepiece: I'm wondering if I can use this code in my own machine? 
<anchepiece> in a conf file add a "start on net-device-down"
<yuantai> SpamapS: in this combined format, can I find out which runlevel the admin issued? My daemon also needs to know whether it's reboot or shutdown
<yuantai> anchepiece: for "start on net-device-down", is it going to run when ifdown command is issued?
<anchepiece> you need to drop that script in /etc/network/if-down.d/ ,which will emit and read in your conf
<anchepiece> so yes
<SpamapS> yuantai: yes $RUNLEVEL will be set to it I think
<anchepiece> i guess that ubuntu is much more tightly integrate with upstart than fedora/redhat
<SpamapS> anchepiece: I don't know if they have that in fedora/redhat
<anchepiece> /etc/network/if-down.d/ ?
<anchepiece> oh hrm
<anchepiece> yes you're right
<anchepiece> well, on this older fedora c7 its not there
<anchepiece> but i see mention of it in fc13
<anchepiece> i guess look thtough /etc/sysconfig/network-scripts
<yuantai> thanks anchepiece, yes it's in /etc/sysconfig/network-scripts, 
<yuantai> But is this folder the upstart scripts?
<anchepiece> i think you'd have to add a call yourself to the /etc/sysconfig/network-scripts/ifdown script (see how OTHERSCRIPT is run, duplicate that)
<anchepiece> sorry have to go but you are close
<yuantai> thank you anchepiece
#upstart 2011-02-03
<jarek83> hi guys
<jarek83> I have this use case with service dependencies
<jarek83> service A depends on service B, if A starts, B should be started before it (and this can be done with "start on starting A" in B), now I would also like service A to restart when service B is restarted (or respawns), how can it be done?
<jarek83> I know I can put "stop on stopping B, start on started B" in A but this would cause starting A if I just want to start B
<jarek83> and this is what I cannot solve
<jarek83> I have put my question at https://answers.launchpad.net/upstart/+question/143910
#upstart 2011-02-04
<nodie> hi
<nodie> is there some upstart command for executing actions with a specific user ?
<nodie> sudo -u ?
<djszapi> hi KeyBuk :)
<Keybuk> hi
<djszapi> sup ?
<Keybuk> not much...\
<SpamapS> Keybuk: forgive me for assigning some new upstart (Ubuntu) bugs to upstart. I'm on a triaging mission. :-P
<Keybuk> SpamapS: that's ok
<Keybuk> you'll want to subscribe James to them, obviously
<Keybuk> though he may be automatically
<SpamapS> Yes indeed. I'm trying to whittle it down to actual bugs.. there's a lot of cruft.
<Keybuk> I'll read them in a "will this be a problem in upstart2" kindof way
<SpamapS> You know, Coit Tower isn't actually made of ivory... 
<SpamapS> ;)
<Keybuk> huh?
<SpamapS> lame attempt to poke fun at your enviable position of being in charge of the rewrite
<Keybuk> heh :)\
<Keybuk> it's more that there's enough deep bugs in the design with good known fixes in 2 at this point that I find it hard to shift gears back to the existing design
<Keybuk> and since I'm not being paid to develop Upstart to Ubuntu's timescales anymore, I have the luxury of focussing on 2 rather than bolting fixes onto 1 ;-)
<SpamapS> Threw in a San Fran reference, just to make it that much more confusing. Thats what makes a good joke.. when you have to explain it to the smartest people you know. ;)
<Keybuk> ah, but I live in San Jose technically ;-)
<SpamapS> Where they do have ivory towers?
<Keybuk> dunno, I've not been into San Jose since 1999
<Keybuk> visiting Dustin at the Doubletree by the Airport on Monday doesn't count
<SpamapS> No but seriously.. we're all excited to see it and I like that you can tell people to go stuff it until its done.
<Keybuk> nor does visiting the Mercado Center
<SpamapS> I like the ultra-slow light rail that goes between San Jose and Mountain View.. very fun to run along side it and wave to the passengers.
<Keybuk> haha, yeah
<Keybuk> my apartment is right by that
<SpamapS> BTW have you run into Mathiaz? he's in DT SFO now
<Keybuk> I take the Google Shuttle into Mountain View ;-)
<Keybuk> no, I haven't
<Keybuk> bug #707479 -> by design
<SpamapS> oh?
<Keybuk> likewise the fact that restart errors if it's not running
<SpamapS> right, I think the restart command is broadly misunderstood
<SpamapS> and I include myself in the group that misunderstands it
<Keybuk> restart is exactly what it says
<Keybuk> it restarts a running service
<Keybuk> using the same configuration it is currently running with
<SpamapS> I expect it to work like init.d scripts' restart .. which calls $0 stop ; $0 start  .. but its just a little bit different.
<Keybuk> init.d scripts are massively variable on how they restart
<Keybuk> some send signals
<Keybuk> and others do call into themselves for stop and start
<Keybuk> so for Upstart, I had to pick one behaviour
<Keybuk> since you can just run "stop job ; start job" I decided having the other behaviour was more useful for restart
<SpamapS> Would it make sense to add a note about it in man 5 init?
<SpamapS> I think people will still misunderstand, but at least we can close the bug reports with RTFM.
<Keybuk> sure, feel free to add a patch to document that ;-)
<Keybuk> a good way of putting it
<Keybuk> restart is a special command to restart a running service without changing its configuration
<Keybuk> its intended for use when you're unsure whether or not someone may have altered the configuration file under you
<Keybuk> and you want the existing job restarted (e.g. to enact a config change of its own) and not have it replaced by another
<Keybuk> SpamapS: also can you do a bit of de-dupping if you're adding upstream tasks
<Keybuk> e.g. 703800 and 568288 might be the same?
<SpamapS> Keybuk: of course. Reading it, to me its not clear that they're duplicate, but I will most definitely take your word for it that they might be.
<Keybuk> no, I haven't read them thoroughly
<Keybuk> but since you're triaging, maybe worth a pass through
<Keybuk> and at least a comment to say why you don't think they are, etc. :p
<Keybuk> (hey, I get to pretend Ubuntu is terrible to upstreams :p)
<SpamapS> No no, we care about you, Mr. Upstream... are you done fixing it? did you fix it yet? Fix it now.
<Keybuk> patches welcome <g>
<Keybuk> but first, sign my copyright assignment agreement please
<Keybuk> it says you have to give me both copyright and ONE MILLION DOLLARS *pinky*
<SpamapS> only a million? but this patch is priceless!
<SpamapS> Oh wait, I'm giving you a million.. crap. This is almost as bad as trying to get patches into FreeBSD
 * Keybuk gets bored of pressing ^D to boot
<ion> keybuk: You might find this video about testing software with QuickCheck interesting. http://video.google.com/videoplay?docid=4655369445141008672
<Keybuk> QuickCheck?
<Keybuk> does that involve Haskell?
<ion> In that video, the Erlang implementation is used. There are implementations of it in multiple languages.
<ion> In particular, the examples of real world bugs uncovered by QuickCheck that werenât found with manually written unit tests are interesting.
#upstart 2011-02-05
<andi3> hallo
<andi3> I'm looking for a way to run/monitor process, which is accessible for 'normal' users
<andi3> Is Upstart only for 'root' users?
<andi3> Is it possible to have /home/USER/init directory?
<andi3> where users can put their own config files
<ion> Itâs in TODO, but not implemented yet.
<andi3> There is something running: https://lists.ubuntu.com/archives/upstart-devel/2010-December/001345.html
<andi3> ion: thanks!
<andi3> ion: do you know, is there a bug/task for it in launchpad?
<andi3> it may happen between 0.5 an 1.0 :-), as per https://answers.launchpad.net/upstart/+question/5219
#upstart 2011-02-06
<twb> When translating an LSB init script, does "Required-Start:    mountkernfs $local_fs" equate to "start on local-filesystems"?
<twb> Hmm, ufw seems to use "start on (starting network-interface
<twb>           or starting network-manager
<twb>           or starting networking)"
<twb> The comment says "# Make sure we start before an interface receives traffic", but I don't see how "starting" GUARANTEES that the ufw job will complete before any interface is up
<yml> Hello I am trying to write an upstart script to start/stop my uwsgi instance : http://dpaste.de/jdNF/
<yml> For some reason the it does not start. I have copied that file in /etc/init/
<yml> yml@toulouse:~$ start -v usgi_emperor
<yml> start: Unknown job: usgi_emperor
<yml> is there a way to get more verbose error about the error
<ion> Youâll probably find a parse error message in syslog. Btw, youâll most likely confuse Upstart by using âexpect forkâ and having a main process that doesnât behave as the expect stanza claims.
<yml> I see
<yml> ion: what is the log file that i need to look at ?
<ion> Try /var/log/syslog
<nfearnley> I'm trying to write an upstart conf file, but I don't understand what happens when I tell a service to stop. When I tell it to start, it runs the pre-start script, then runs exec line, then runs the post-start script. When I tell it to stop, it runs the pre-stop script, does ???? to halt the service, then runs the post-stop script. Can someone fill in the blank?
<JanC> nfearnley: it kills the process
<JanC> well, first a TERM signal, then if that didn't work a KILL signal IIRC
<JanC> you can set the timeout before KILL with the "kill timeout" stanza (see init(5) for that)
<nfearnley> Thank you.
#upstart 2012-02-02
<ona7O> hi. can anyone tell me how to prevent an supervised job from being stopped because of "respawing toot fast" - i have this problem with pppd/pptp when loosing connectitivty. respawn limit didnt help.
<jodh> ona7O: if pppd is not tolerant of networks going away, you could specify "start on net-device-up" and "stop on net-device-down" possibly.
<ona7O> jodh: ok, will try that ty
#upstart 2012-02-03
<flowerpot> How do I tell sshd to reload its configuration file using Upstart?
<flowerpot> sudo initctl reload ssh
<flowerpot> sudo reload ssh
<flowerpot> btw, why is the sshd job called ssh?
#upstart 2012-02-04
<njbair> can I use shell commands when setting the value of an env variable?
<SpamapS> njbair: commands like  env X=`foo` ?
<njbair> yeah that didn't work for me
<SpamapS> njbair: thats because that is just for setting defaults. :)
<SpamapS> njbair: just set it in a script..end script section
<njbair> do I use the env keyword inside the script section?
<ion> Itâs sh code. You might want âexportâ.
<njbair> oh I see
<njbair> i must be doing something wrong. when I start my test script it appears to work fine, I get a pid from initctl. but my echo statement is ignored and I dont see any output
<SpamapS> njbair: perhaps pastebin your job file?
<SpamapS> njbair: (hint, apt-get install 'pastebinit' and do 'pastebinit < /etc/init/foo.conf')
<njbair> SpamapS, got it. I was using the wrong command syntax elsewhere.
#upstart 2012-02-05
<cainus> anyone awake?  just wondering how to debug a job that won't start?  even with log level at DEBUG, I get no useful information logged (just 100 lines saying it started then stopped)
<ion> See âObtaining a log of a Script Sectionâ in the cookbook.
<ion> You can just use e.g. /tmp/myjob.log if youâre debugging it on an otherwise properly running system.
<cainus> thanks ion... I'll take a look
<ion> (That is, instead of /dev/.initramfs. But itâs just fine to use that, too.)
<cainus> hmmm I've already got a line like that... I used foreman to generate the .confs, and it added that apparently
<cainus> and yet nothing matching the process in /var/log/
#upstart 2013-01-28
<afournier> is possible to pass an env var from pre-start to exec ?
<jodh> afournier: the next release will support this, but for now, you'll need to use temporary files or configuration files or similar.
<afournier> i put the exec inside script and that'll do it
<xnox> afournier: that works too.
#upstart 2013-01-29
<afournier> where can i find the latest mysql upstart script (online) ?
<xnox> afournier: http://packages.ubuntu.com/search?suite=raring&section=all&arch=any&keywords=mysql.conf&searchon=contents says it's in the mysql-server-5.5 package
<afournier> thank a LOT !
<xnox> afournier: pull-lp-source mysql-5.5 should give a you unpacked source package and it will be there somewhere
<afournier> thanks*
<afournier> i did not ubuntu got a search engine for package files, that will save me a lot of time, thanks again
<xnox> afournier: yeah, it's handy. Can pick distributions you are interested in, and search source/binary/contents/etc.
<afournier> i have a task (let's say network-interface.conf) that can be instanciated with several INTERFACE (lo, eth0, etc.) the pre-start script is run only once for all instances is it normal ?
<jodh> afournier: no - pre-start will get run for each instance you start.
<xnox> afournier: pre-start script is run once per instance.
<afournier> :/
<xnox> afournier: you can check "if not any existing instances running" do the "one-time initialisation"
<xnox> afournier: but I'm not sure why would you want to. why are you using instances in this case?
<afournier> indeed i want one pre-start for each instance
<afournier> i dunno if i spotted a bug, or if my task is not correct
<xnox> well that's what you get by default......
<xnox> Just try simple job which for each instance it does "echo Starting instance $INSTANCE"
<afournier> ok
<xnox> and start a bunch of them and check the logs in /var/log/upstart/
<xnox> and work your way up, to spot the bug =)
<afournier> ok
 * afournier is doing that
#upstart 2013-01-30
<bizhanMona> HI is there a depency between upstart and dbus? Thx
<supster> Does anyone see any issues with this Upstart job? Are there any improvements to make? https://gist.github.com/4678285
<SpamapS> bizhanMona: yes, upstart uses dbus for some things.
<SpamapS> supster: start on startup is *way* too early
<SpamapS> supster: that event happens before any filesystems have been mounted
<SpamapS> supster: and before networking is available
<SpamapS> supster: also chdir is a declarative bit, so you can move that out of the script
<SpamapS> supster: further, newer versions of upstart will log all output at /var/log/upstart/$jobname.log ...
<SpamapS> supster: so you can consider just letting that be your log file..
<supster> SpamapS: I guess  I want start on runlevel [2345] then?
<supster> it will log STDOUT and STDERR there?
<xnox> yes.
<SpamapS> supster: http://paste.ubuntu.com/1591130/
<supster> runlevel [016], not just [016] - right?
<supster> and how is that different than "on shutdown"?
<SpamapS> supster: right, sorry I messed that up. .runlevel [016]
<SpamapS> supster: shutdown is not an event
<SpamapS> supster: that job will never stop
<supster> SpamapS: I see
<supster> SpamapS: if I don't use `set -a` i don't get the env variables from $CONF_PATH
<supster> SpamapS: is there something else wrong?
<SpamapS> supster: ah so $CONF_PATH doesn't export
<supster> correct ... should it?
<supster> i am not sure what the convention is for having a conf file that is just env variables
<SpamapS> supster: well...
<SpamapS> supster: if it were me I'd do it in /etc/init/jobname.override as env statements
<supster> SpamapS: for more context: I am passing things like the port to listen on and the database connection string to my app
<supster> SpamapS: what would the override file look like? just env stanzas? would those be automatically a part of my app's env or do i still need to pass them somehow?
<SpamapS> supster: that override file is parsed just like an upstart file
<SpamapS> supster: the difference is just that you can treat it more like a config file
<SpamapS> supster: actually why not just do those env statements in the .conf ?
<SpamapS> err
<SpamapS> supster: in the upstart job file I mean
<supster> SpamapS: yeah.... my original thought was that it would be better to separate the upstart logic and the application configuration
<supster> SpamapS: because different servers will need to run with different configuration
<supster> SpamapS: but maybe it can just all be in that file
<supster> *the single upstart job file
#upstart 2013-01-31
<bizhanMona> Spamaps: Thanks for replay, where can I get more info for what upstart uses dbus? Thx 
<xnox> bizhanMona: the source code? =)
<xnox> bizhanMona: initctl uses dbus to talk to upstart. and there is also dbus interface to query status & launch stuff. in trunk there is support for jobs to start/stop on dbus events.
<xnox> there is some dated information here http://upstart.ubuntu.com/wiki/DBusInterface
<xnox> i'm not sure we auto-generate dbus docs or not.
<jodh> bizhanMona: also some example here - http://upstart.ubuntu.com/cookbook/#controlling-upstart-using-d-bus
<ah-> hi, i have an embedded arm board that usually boots with sysv scripts, and instead of/after booting that I want it to chroot to a loopback image of a different distribution that's based on upstart and continue booting that
<ah-> my problem is that I can't just chroot and start upstart afterwards, since that would mean that upstart isn't pid 1
<xnox> use lxc, then upstart can become pid1
<xnox> lxc is chroot + a couple fancy tricks on top. it's the way to do stuff like that.
<ah-> thanks, i'll look into that, seems like a good fit
<ah-> does it require kernel support?
<xnox> ah-: also your case sounds a lot like initramfs -> root hand over, which does also give up pid1 and let the other instance take over.
<ah-> my real problem is that i can't/don't want to flash a new kernel/uboot config since that's a bit risky
<xnox> ah-: lxc? yeah but pretty much any recentish kernels support that. even like android kernels and what not.
<xnox> check, you might have lxc enabled.
<ah-> xnox: unfortunately a lot is missing: http://nopaste.me/paste/629141865510aa60037d45
<xnox> ah-: then look how initramfs does handover.
<ah-> i'm on it, thanks for the hint
<ah-> xnox: great, that looks pretty much like the thing i've been searching for. i'll just omit the rm -rf / part of it and then it should be fine
<xnox> np, your welcome =)
<bizhanMona> xnox: Thanks for your info, I am trying to catch up fast on this. One question when you say "in trunk ..."  do you mean is not part of the main release? thx
<bizhanMona> jodh: thanks for pointer
<xnox> bizhanMona: yeah, that event bridge got merged into lp:upstart. We will soon have an upstart release with that feature in.
<xnox> bizhanMona: even sooner we might get a usable rc / testing ppa.
<bizhanMona> xnox: this great thanks so much. Is there a mailing list that I can subscribe to get the future development releases? thx
<xnox> bizhanMona: there is upstart-devel mailing list, but it has also code-review and patches going to it. https://lists.ubuntu.com/mailman/listinfo/upstart-devel
<xnox> bizhanMona: just announcements of new releases are via RSS https://launchpad.net/upstart/+announcements
<bizhanMona> xnox: thanks so much for all the info.
<xnox> bizhanMona: =) no problem. We are a friendly bunch here, when online ;-)
<ndimatteo> hey all, I was hoping I could get some help with an upstart job for running forever.js
#upstart 2013-02-01
<ndimatteo> anyone able to assist in writing an upstart job for forever.js?
<karolyi> hi, is there a way to configure keyboard to emit upstart events on pressing some special key combinations?
<SpamapS> karolyi: if you can get the kernel to notify a userspace daemon, it can emit events
<karolyi> SpamapS: yes, but the question is, how
<karolyi> i've been goggling around for half a day now
<karolyi> *googling
<stgraber> karolyi: the easiest way would be to patch some of the keyboard handling code in the kernel to emit a uevent when the specific key combination is done, you could then have upstart trigger on that uevent with the existing udev bridge
<karolyi> stgraber: so, i guess i can't do that without actual patching
<stgraber> right
<stgraber> depending on the kind of keyboard, you may be able to eavesdrop through the /dev/input devices, but I'm not sure if that works and if it does, I doubt it's going to be particularly reliable
<karolyi> actually i'm not allowed to patch the kernel here, we should stick to the supplied ubuntu kernel version :)
<karolyi> however, this was my idea too, i just didn't knew that this can't be achieved now with the stock kernel
<stgraber> well, it's not something we need in the distro and having that kind of thing in the kernel and I guess people don't want to make it too simple to implement a key logger ;)
<karolyi> stgraber: you're right, but my target is now to achieve a volume controller by the multimedia keys, behind the X server, because my windowmanager steals the focus if i set the controller script to the appropriate keys
#upstart 2013-02-02
<Baribal> Hi. I'm just now writing my first upstart script, and I wrote a minimal service in Python to test it. What signal does upstart use when stopping a daemon? First STOP, then KILL?
<nimo> I want to execute a script at every shutdown.... can I do it simple?
<nimo> my upstart script wont run at boot... but when i run it on the fly it works
<nimo> http://pastebin.mozilla.org/2109288
#upstart 2013-02-03
<Baribal> Hi. I've been trying to write a minimal system service and run it using upstart. Here's the code for the service http://bpaste.net/show/XNevoDvVVENeuVmUfeV8/ and here's the one for upstart http://bpaste.net/show/ikCR7JeGdF3feVTC2DmQ/          When I run "sudo start testjob", output tells me the PID, but using ps, I don't see a process with that PID. Running the service from shell works fine, though. Any idea where I went wrong?
<nimo> not much action here..
<SpamapS> nimo: its mostly busy in europe/us working hours.
<Baribal> What signal will upsart send to stop a job? SIGTERM?
<Baribal> YES! It IS SIGTERM, and my service is running fine now. :D
<Hurga> Hello. I have a problem with a job misbehaving, and upstart getting confused about its state.
<Hurga> This should illustrate the problem:
<Hurga> root@titan:~# initctl list | grep rsyslog
<Hurga> rsyslog stop/killed, process 18975
<Hurga> root@titan:~# ps ax | grep 18975
<Hurga> root@titan:~#
<Hurga> When I try to start or stop rsyslog in this situation, the start or stop just hangs and nothign happens.
<Hurga> This is not a vserver... I already fixed a similar problem with lnux-vserver. In this case, the problem appears if I try to have rsyslogd use /dev/xconsole.
<Hurga> Distro is Xubuntu 12.04
<Baribal> Hurga, hanging on start might be a sign of a bad expect stanza.
<Hurga> The message I get - rsyslog stop/killed, process 18975 - hints at upstart believing the process is still there.
<Hurga> I can get rid of it by exhausting the PID space and creating a new process with the same PID. Which upstart can kill.
<Hurga> But this doesn't seem to be the right way...
<Baribal> ...or that that was the last runs PID? I'm actually rather new to Upstart, so here are a few grains of salt: .::.
<Hurga> well, the "process 18975" is the PID of rsyslogd before issuing the stop command which didn't return
<Rarrikins_z> Is there a way to limit log file size for a daemon?
<Baribal> Maybe logrotate?
<Rarrikins_z> Thanks :)
#upstart 2014-01-27
<woglinde> hi
<woglinde> I need some help with pppd and upstart 1.5
<woglinde> when I use respawn upstart does not get the pid right
<woglinde> okay I solved the problem myself, it was using updetach command in the pppd config
<yann2> hello! I am looking at what would be the easiest way to run a script after system start - but just a one off, this is not a daemon that needs to be controlled
<yann2> I ve written quite a few jobs that controlled daemons, but not sure how to do it just for a script
<SpamapS> hm
<SpamapS> salt-master stop/killed, process 2529
<SpamapS> bad expect daemon in the salt-master upstart job..
<SpamapS> but worse.. I've re-created pid 2529...
<SpamapS> and upstart is not killing it
<ion> spamaps: https://github.com/ion1/workaround-upstart-snafu
<SpamapS> ion: thats what I used. :)
<ion> huh
<SpamapS> yeah the process just sat there
<ion> (Well, Upstart isnât supposed to kill it, but it *is* supposed to notice when it exits without a parent. I donât know why that doesnât happen.)
<SpamapS> right hm
<SpamapS> running again..
<SpamapS> still can't believe this hasn't been fixed
<ion> Alas, the development of things like that kind of slowed down when Keybuk moved to Google. Upstart also never gained support for states (which i find an essential part of the design in addition to just events).
<ion> (States make it trivial to make the job C run whenever both job A and job B are running, no weird conditions with e.g. the event sequence A started, B started, B stopped, B started.)
<SpamapS> ion: it did work a second time. Coudl be pebkac.. don't know
<SpamapS> ion: Just FYI.. I was Canonical's server team upstart expert for a while.. quite familiar with the situation. I've written quite a few jobs myself. :)
<SpamapS> ion: such as /etc/init/wait-for-state.conf :)
<SpamapS> ion: upstart has intrinsic support for state. It does not, however, have a friendly way to use it. :)
#upstart 2014-01-28
<lpsmith> Hmm,  ok,  so I have an upstart job that failed on boot
<lpsmith> I checked the logs and discovered the problem is that I forgot a dependency on postgresql.
<lpsmith> The problem is,  postgresql is still using init.d scripts
<lpsmith> is there a way to indicate a dependency on something that is still init.d?
<lpsmith> I feel like this must be a common enough problem that there is a standard solution for it...
<lpsmith> I suppose I could convert postgresql to use upstart,  but honestly I'd prefer to not have to do that;  I'd prefer to have that coming from upstream
<lpsmith> (I'm using Ubuntu Server 12.04.4 and PostgreSQL 9.3 from the community repo... but even the Canonical-supplied postgresql packages are still init.d)
<ion> spamaps: Alright
#upstart 2014-01-29
<atomx> hi
<atomx> Now I noticed that Ubuntu does not use INIT, but upstart
<atomx> ... even if I've been using it for 7 years
<atomx> (at least 7(
<ion> Whatâs INIT?
<atomx> )
<ogra_> ion, a very loud pid 0 
<atomx> the standard process called by the kernel as the last step of tyhe boot
<ogra_> err
<ogra_> pid 1 
<ogra_> :)
<ion> atomx: Upstart comes /sbin/init.
<ion> with
<atomx> I tried a few times to read the init scripts, and saw that inittab misses, and I noticed that something unusual is there
<atomx> In fact, upstart represents the new init scripts of init ? Is there some change in executable init ?
 * ogra_ points to http://upstart.ubuntu.com/ 
<atomx> I saw on that huge page the link to this channel, this is why I am here, probably somebody here can explain me in 2 minutes how 1. to write a new script 2. what are the changes from the classic System V scripts 3. if I can study the new system in less than 1 hour, and completely understand it.
<ogra_> see the cookbook link at the top of the page 
<ogra_> and no, 1h is likely not enough
<atomx> hmmmm
<atomx> thanks
<atomx> but if your system explodes in a ball of fire or becomes unusable as a result of a suggestion from this document, you alone have the intellectual pleasure of fixing your systems
<atomx> (quote)
<atomx> I started to read the introduction, and upstart seems great 
<jodh> atomx: the best place to start is the Upstart Cookbook: http://upstart.ubuntu.com/cookbook/. The first few pages should explain what you need - you don't need to read it all to start with :)
#upstart 2014-01-31
<tds5016> hey. can someone tell me how I'd write the config to run a command on the stop?
#upstart 2015-01-26
<hitlin37> hi, i'm doing a start my_process when there is a file change. is there any overhead if the job already running and i call start.
<hitlin37> it says job is already running. 
<hitlin37> i can add another condition in bash to chehck if job is running or not...or i jsutleave it like this if doesn't make any difference to send start to a job which is already running.
<hitlin37> i think i do not understand something in upstart.
<hitlin37> hi have a job for updating system
<hitlin37> https://www.irccloud.com/pastebin/bV7W4oKt
<hitlin37> since i don't have inotify bridge versiion of upstart, i'm implementating my owh mechanism
<hitlin37> so i created another job which luaches a wifi_chehck_status script
<hitlin37> https://www.irccloud.com/pastebin/ay7j20so
<hitlin37> finally , in my wifi script, i chehck the status and enable if wifi is up
<hitlin37> https://www.irccloud.com/pastebin/lOfn79W1
<hitlin37> now, i'm keep getting from my wifi job that job terminated and respawinging.
<hitlin37> but i dont get the reson why its terminating the wifi .sh file.
<hitlin37> the same file runns fine from cmd line
<hitlin37> as its inotify in while loop!
<hitlin37> Problem is wifi job shows as "the job is terminated". but when i run the wifi_script, it works fine in blocking mode as it keeps looking at the directory using inotifywait. why would upstart terminate a while look on inotifywait? looks like i'm doing something wrong
<hitlin37> may be i should simply my question. is there a problem if a script, called from my job calls inotiywait.
#upstart 2015-01-27
<hitlin37> ah, my script was missing file permission, hence the job exited. my bad.
<athan> Hmm... `init-checkconf foo.conf` is telling me there's a syntax error, but no line number :\ http://lpaste.net/119297
<pv2b> I have an ubuntu 10.04 LTS server that i'm having an annoying issue on. I have a service for a Digi Realport (serial over ethernet) that need to start before tomcat starts, otherwise the application doesn't find the serial port and goes all sad on me. both tomcat6 and dgrp_daemon seem to be using init.d scripts rather than upstart jobs, but upstart is in use on the server. So I'm a bit confused 
<pv2b> as to what tool I should be using changing this with. i tried editing the tomcat startup script to loop until the serial port comes up, but that just causes an excellent deadlock on boot since the driver seems to be started after tomcat.
<pv2b> :q
<MFen> hi folks
<MFen> i'm having some issues understanding the flow of events. i'm trying to schedule one job to happen just before another job
<MFen> the main job is in backup.conf. There is a separate job, aorta-db-export. it must run first.
<MFen> at the top of aorta-db-export i have: start on (starting backup)
<MFen> but, it doesn't.
<MFen> i can start backup using either initctl or service
<MFen> it runs, successfully
<MFen> but never does aorta-db-export get triggered to start
<MFen> i'm using upstart 1.12.1 in ubuntu 14.04
<MFen> would i be better off rearranging things in the other direction? i don't really care for that because i might want to attach other things prior to backups running
<MFen> in that scenario i think i want "start on aorta-db-export" in backup? but i need backup to run only when aorta-db-export *completes*
<JanC> start on starting backup is right AFAIK
<JanC> but then aorta-db-export needs to be a task
<MFen> yes, it's a task. i figured it out, sorry i didn't update
<MFen> aorta-db-export.conf was malformatted so it wasn't being read
<JanC> :)
<MFen> thanks :)
<JanC> you can check for that
<MFen> o?
<MFen> that sounds like something useful to have in my server test scripts...
<JanC> init-checkconf
<JanC> that should be able to find malformed .conf files
<MFen> yep, that sounds awesome to me. gonna add that, thanks :)
<JanC> :)
<athan> Upstart keeps making my web server reset :\ how would I start testing?
<athan> It's weird, when I invoke the executable myself, everything is fine - it's only when used as an upstart job :S
<athan> http://lpaste.net/119354 <- forany interested. interested
#upstart 2015-01-28
<MFen> athan: just a theory here, but does bin/deconfigured start a daemon process?
<athan> MFen: Not quite, it does invoke a server though
<athan> it doesn't fork anything
<MFen> ok, so that process stays running in the foreground
<athan> It connects to port 80 & does the http stuff
<athan> yep!
<athan> It does some basic logs - 200 responses etc
<athan> (it's weird, my tests that caused resets actually logged as 200s)
<MFen> you've exhausted my knowledge then sry :)
<athan> Thanks anyway MFen !
<athan> hmm this is interesting, so the http response doesn't actually go through (even on `lo`)
<athan> I could show .pcap's if helpful :)
<athan> 6 ACK's from the browser, and nothing back :O
<athan> er... wait... shouldn't the ACK come _after_ the 200 response? :s
<athan> or maybe it's just a "resend" signal
<JanC> athan: when you start it yourself vs. upstart, there might be different users, and/or different environments
<athan> JanC: There isn't anything particular in the executable, though
<athan> I have full control over the code - there are only 2 or three things which vary based on the runtime
<athan> which are fully logged and don't matter much in terms of http responses :\
<JanC> e.g. things started by upstart probably don't have a console available etc.
<JanC> that's the sort of thing you might want to look into
 * JanC leaves now, have to get up early in the morning  :)
<athan> oop, sorry!
<athan> with `console log`, I thought all stdout/stderr got piped to a file? :S
<hitlin37> i have one conceptual question
<hitlin37> if i stop a job based on a false condition of configuration file than it will not respawn. 
<hitlin37> right?
<hitlin37> even if job says respqn.
<hitlin37> all i have to do is to exit 0 in pre-start.
<hitlin37> specifically, i'm talking about this : http://upstart.ubuntu.com/cookbook/#stop-a-job-from-running-if-its-configuration-file-has-not-been-created-modified
<hitlin37> so,, was interested to know if it will respwan if stopped in pre-start, even if job conf says resqpwan
#upstart 2015-01-29
<hitlin37> hi,  since i coudn't find it in cookbook, asking here.
<hitlin37> i want to start job B when job A stopped in pre-start stages
<hitlin37> what's the recommended way of doing it? should i just look for the exit code 0 and then start or is there anything else in upstart i can use it.
<hitlin37> ?
#upstart 2016-02-01
<JanC> 0.6.5 is pretty much antiqueâ¦  :-/
<JanC> is the daemon/application actually stopping, or does upstart only think so?
<JanC> if it's actually stopping (or crashing), try to make it log
<ikonia> JanC: I think it's acutally not a problem, I think it's my actual job thats just defined wrong
<ikonia> it's a php job - I think it's launching it and exiting, rather than launching it and keeping it alive, 
<ikonia> and yes, it's pretty much the dark ages of upstart, but it's what is in centos 6
#upstart 2016-02-03
<ikonia> are is there any suggestions on getting some form of debugging out of why an upstart job is starting and exiting straight away. I'm using RHEL 6 which is locked to upstart 6.5, I'm struggling to get any output as to why this job is not continuing to run 
<ikonia> sorry version 0.6.5
<ikonia> (just to be clear)
<ikonia> from working through the debug I've managed to get, I'm reasonably sure it's to do with $PATH not being set correctly, it sources a file which changes the PATH, and it looks like thats being lost when it executes the actual job
#upstart 2016-02-05
<srenatus> hi there. question from ancient history -- how would you check if a service is enabled without `show-config`? (upstart 0.6.5)
<srenatus> hmm a grep on `initctl list` might be way to go
<JanC> define "enabled"
<JanC> I guess anything that has a 'start on' stanza could be considered "enabled"
<srenatus> known to the system and "to be started on boot/should be running".   yes, this is kind of what I settled with: https://github.com/chef/inspec/pull/419 (oops all my tests are red)
<JanC> but even that would be muddy, as some services might have an on/off switch in /etc/default/*
<JanC> etc.  :)
<JanC> and some that have a 'start on' stanza could possibly only be triggered by a manually issued event
<srenatus> I'm not a huge fan of "enabled"
<JanC> :)
<srenatus> what does it tell you? the important question is if it's running. if you reboot the machine, your test run will tell you if it's running or not ;)
<JanC> well, depending on your configuration, services might run only on certain conditions
<JanC> hopefully those conditions are defined correctly  :)
<JanC> init systems can be quite complicated, be it sysvinit, upstart or systemd
<JanC> or bsd init, really
<srenatus> mhm yup
#upstart 2017-01-30
<[diablo]> Good afternoon #upstart 
<[diablo]> got a problem when I'm building a first-boot script for RHEL6
<[diablo]> seems that when the upstart service file is dropped in, that it's being ran
<[diablo]> I'm using Ansible to deploy it
<[diablo]> does upstart automatically run the service when it's copied?
<[diablo]> basically I'm creating RHEL6 and 7 templates with Packer, Ansible, and VMWare workstation
<[diablo]> the templates are then uploaded to our vcloud
<[diablo]> to deploy new machines...
<[diablo]> but the first boot (only on RHEL6) is running during template creation time :-/
<[diablo]> http://paste.ubuntu.com/23893353/
<[diablo]> thats my ansible task
<[diablo]> http://paste.ubuntu.com/23893355/
<[diablo]> thats the upstart conf file
<[diablo]> I have no idea wtf it's being ran
#upstart 2017-01-31
<[diablo]> afternoon guys
<[diablo]> is there anyoneeeee alive here please?
#upstart 2017-02-03
<aquarius_> if I do: initctl start mything MYVAR=myvalue, then scripts in mything.conf have access to MYVAR. If a second script, otherthing.conf, has start on started mything then it does _not_ have access to MYVAR. Can you think of a way that it could have that access, other than removing start on started mything and having mything.conf explicitly do initctl start otherthing MYVAR=$MYVAR? That would work but... it seems like I'm doing upstart's job for it, there.
#upstart 2018-02-01
<sonarKWA0BL> ââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  ghrnisund: hallyn Necrosan via âââââââââââââââââ
<sonarKWA0BL> ââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  wonxhnt: balkamos broder inara âââââââââââââââ
<sonarKWA0BL> ââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  nlojzs: hallyn Trevinho xMopx âââââââââââââ
<sonarKWA0BL> âââââââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  ldsnfkyvpp: blazeme8 xnox Trevinho âââââââ
<sonarKWA0BL> ââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  zrjxjh: blazeme8 via puhuri ââââââââââ
<sonarKWA0BL> ââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  zyjviy: inara xnox mmeyer ââââââââââ
<sonarKWA0BL> ââââââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  pfeygtwih: JanC via marrusl âââââââââ
<sonarKWA0BL> Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  cpxeumg: ubuntulog Trevinho mniip Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢
<sonarKWA0BL> Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  opgtj: blazeme8 Trevinho DzAirmaX Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢
<sonarKWA0BL> âââââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  ppvbtacxnu: hallyn broder balkamos âââââââââ
<sonarKWA0BL> Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  mmroajkie: dgw blazeme8 DzAirmaX Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢â
<sonarKWA0BL> ââââââââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  mryklir: dgw broder JanC âââââââ
<sonarKWA0BL> ââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  aodqa: hallyn mniip broder âââââââââââââ,
<sonarKWA0BL> âââââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  sqnoc: mmeyer kaylindris puhuri ââââââââââ
<sonarKWA0BL> ââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  roldvexgul: xnox dgw xMopx âââââââââââââ,
<sonarKWA0BL> ââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  euesmkhq: broder dgw Trevinho ââââââââââ
<sonarKWA0BL> âââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  ahrmuaq: dgw xnox Necrosan ââââââââââââ,
<hallyn> sigh
<sonarKWA0BL> ââââââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  dqijfpmei: broder JanC blazeme8 âââââââââ
<sonarKWA0BL> âââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  ufzbhvewnf: xMopx mmeyer via âââââââââââ
<hallyn> little girl likes her rainbows
<sonarKWA0BL> âââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  wwbghig: Necrosan DzAirmaX kaylindris âââââââââââââ
<sonarKWA0BL> ââââââââââââââââ SPECIAL ANNOUNCEMENT: IRC.SUPERNETS.ORG #SUPERBOWL IS HAVING A SUPERBOWL WATCH PARTY ON FEB. 4TH. MESSAGE CHRONO FOR DETAILS!!  rxouhqvws: JanC xnox broder âââââââââââ
