=== erkules_ is now known as erkules [13:45] /topic Upstart 1.9 | http://upstart.ubuntu.com/cookbook/ | Post to mailing list if no response here: http://bit.ly/ooeNVv [13:45] === jodh changed the topic of #upstart to: Upstart 1.9 | http://upstart.ubuntu.com/cookbook/ | Post to mailing list if no response here: http://bit.ly/ooeNVv [15:19] jodh: \o/ [15:19] jodh: could I safely run upstart 1.9 on raring if I backport it? [15:22] elmo: wait for us to merge 1.9 into saucy & apply ubuntu-specific patches for apparmor, and then backport that package. [15:22] xnox: ok [15:23] elmo: well, i expect you will just be able to recompile for raring. [15:26] ahoi short question. having in his old init script an own option. Does upstart has any way to have own options? I was thinking about using emit, but that is too fuzzy. [15:31] erkules: what do you want to achieve? and what do you want to do? [15:32] erkules: all common tricks are described here: http://upstart.ubuntu.com/cookbook/#cookbook-and-best-practises [15:32] xnox: hi, I was reading a blogpost. There they patched galera-init with a bootstrap option. So when you start the script with that option it creates a new GTID [15:34] xnox: okidoki [15:36] erkules: i'm still confused what your initial problem/question is. =) [15:37] erkules: if you want to launch different instances of the same daemon you can be using instances [15:37] hehe [15:37] erkules: what is galera-init? what is GTID? [15:37] ok GTID (global transaction id) [15:37] it is a galera thing [15:38] mysql-multi-master [15:38] service mysql start -> starts the server with old GTID [15:39] service mysql start --bootstrap forces the server to create a new GTID [15:52] erkules: if a job is already running, upstart will not try starting it again. Thus you should stop; start. [15:53] erkules: if you want to keep the "old one" running. and run a new one with a different GTID simultaniously. Look into passing variables to jobs and/or instances. [15:53] erkules: it looks like above is an init.d script, are you converting it to a native upstart job? [15:53] erkules: cause under upstart, you can continue using init.d scripts and above should just work as upstream uses it. [16:04] xnox: I would like to implement the idea of extra options in my own upstart script [16:07] erkules: they are not scripts, and are not executed. [16:08] erkules: they are configuration files. [16:08] erkules: you can pass environment variables to them. [16:08] erkules: e.g. you can have $ start myjob BOOTSTRAP=true [16:09] but not arbitrary arguments. [16:44] * xnox slowly builds on disk. [16:48] jodh: all 18 tests pass for me with saucy sbuild. [16:48] jodh: please note that for me locally upstart testsuite fails if sbuild is using: overlayfs, tmpfs, eatmydata. [16:48] xnox: thats cool [16:49] xnox++ [16:49] jodh: thus to build upstart I always use sbuild with a configuration closer to the distro builders: [16:50] jodh: so my /etc/schroot/chroot.d/sbuild-saucy-amd64 looks like this: http://paste.ubuntu.com/5808343/ [16:50] jodh: and I build upstart with sbuild -c saucy-plain-amd64 path-to.dsc [20:02] xnox: so I confirm your result that the branch builds fine in my sbuild environment; must be something specific to eatmydata or other optimization