[11:25] <tseliot> hi all, if I used a symlink in /etc/init to the actual job in, say, /usr/share/$package_name, would upstart follow the symlink and start the job properly? Note: this is a hack and I know it wouldn't be good practice
[11:26] <tseliot> and shall I expect any issues with this?
[11:28] <xnox> tseliot: no, it will not work. Upstart ignores all symlinks.
[11:28] <tseliot> xnox: ok, thanks
[11:28] <xnox> tseliot: so your symlinked name will not be picked up.
[11:28] <tseliot> right
[11:28] <xnox> tseliot: if you have "one job which should have similar instances which are tiny bit variable" maybe you need an instance job.
[11:28] <xnox> tseliot: what is it for?
[11:29] <xnox> tseliot: e.g. see /etc/init/network-interface.conf where one job instance per network interface is started.
[11:31] <tseliot> xnox: well, the nvidia flavours in Precise can be installed at the same time and I need them to install the same job. It's not an issue in Saucy (where they are not coinstallable) but I'm trying not to have a big diff between the different versions that I ship in the different ubuntu releases
[11:31] <xnox> tseliot: i see =/ if it helps you can put jobs into sub-directories under /etc/init/
[11:32] <xnox> tseliot: but don't forget to think about the dist-upgrade case from precise -> trusty =/ with all of those hwe stacks.
[11:33] <tseliot> xnox: yep, that's something I'll have to test
[11:35] <tseliot> xnox: if I have jobs with different names,  can I make sure only one of them can run?
[11:35] <tseliot> xnox: so that if one is running the others won't
[11:37] <xnox> tseliot: you'd need to add a pre-start in the one which should not be running. In that pre-start check the output of e.g. "initctl status goodjobname" and if there is better one do { stop; exit 0; }
[11:37] <xnox> tseliot: let me fetch an example from cookbook.
[11:37] <xnox> tseliot: supporting "states" is often requested feature which hasn't been implemented yet.
[11:42] <xnox> tseliot: hm, I see mutual exclusion in the cookbook. The "bad" job can have "stop on starting goodone", this way whenever good one tries to start the bad one will be stopped first.
[11:43] <xnox> tseliot: or "pre-start exec ! status goodjob"
[11:44] <tseliot> xnox: right. Except that there's probably no such thing as the good one and it would be a matter of having whatever starts first prevent other jobs of the same kind from running
[11:44] <xnox> if goodone exists, status will exit with 0, ! will invert it, thus pre-start will exit with 1 and prevent the "badjob" from running.
[11:44] <xnox> tseliot: oh, so it's many2many and only one should run?
[11:45] <tseliot> xnox: yep. All the jobs will be the same
[11:45] <tseliot> it's just a matter of having only one running
[11:45] <xnox> tseliot: can I see them? where are they?
[11:45] <xnox> (cause one would not want to encode the names of all of them in each and everyone of them)
[11:46] <tseliot> xnox: they are not there yet. I'll pastebin one
[11:46] <xnox> tseliot: i think i missed pastebin.
[11:46] <xnox> tseliot: =) oh you haven't yet.
[11:46] <tseliot> xnox: something like this http://paste.ubuntu.com/6335293/
[11:47] <tseliot> don't mind the __USER__ thing, it's a template
[11:47] <xnox> tseliot: ship that job in a common package which the rest of the packages depend on?
[11:48] <xnox> tseliot: and you can source __USER__ from a config file, if there are different users.
[11:48] <tseliot> xnox: I tried but it got stuck in NEW and was rejected when Saucy was released... I was hoping to get around it
[11:48] <xnox> tseliot: well talk to archive admins. that looks like the cleanest solution, imho.
[11:49] <tseliot> xnox: yes, it is. I'll try again getting the package into the archive
[11:49] <tseliot> thanks for your help
[11:50] <xnox> tseliot: you can even ship that job anywhere else, e.g. in x11-common or some such, just add a check "pre-start [ ! -x /usr/bin/nvidia-persistance ] && { stop; exit 0; }"
[11:50] <xnox> tseliot: it's nice to have in the same package(s) that ship nvidia-persistance binary, but you don't have to.
[11:50] <tseliot> right
[11:50] <xnox> (apart from making sure postinst scripts attempt to start it)
[11:51] <xnox> tseliot: yeah, just talk to archive-admins about it. Or upload with a bug # in the changelog, and in that bug explain what the problem is, mark all affected packages and explain how you solved it and subscribe archive admins.
[11:52] <tseliot> xnox: yes, I'll try with Trusty first
[11:52] <xnox> tseliot: i think rejection was not "reviewed and rejected the package", but rather "it's release day, step X/N to release is to rejected all new packages", as there is no simple way to redirect new queue to the next series.
[11:52] <xnox> which didn't get time to be reviewed.
[11:53] <tseliot> xnox: yes, the package was reviewed a first time, then I made the required changes but it was never reviewed again
[13:39] <crankharder> jodh: I was unable to reproduce that issue yesterday on a clean system - thanks for all the troubleshooting help yesterday anyways :)