| 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:25 |
|---|---|---|
| tseliot | and shall I expect any issues with this? | 11:26 |
| 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:28 |
| xnox | tseliot: e.g. see /etc/init/network-interface.conf where one job instance per network interface is started. | 11:29 |
| 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:31 |
| xnox | tseliot: but don't forget to think about the dist-upgrade case from precise -> trusty =/ with all of those hwe stacks. | 11:32 |
| tseliot | xnox: yep, that's something I'll have to test | 11:33 |
| 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:35 |
| 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:37 |
| 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:42 |
| xnox | tseliot: or "pre-start exec ! status goodjob" | 11:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| 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:47 |
| 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:48 |
| tseliot | xnox: yes, it is. I'll try again getting the package into the archive | 11:49 |
| tseliot | thanks for your help | 11:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| tseliot | xnox: yes, the package was reviewed a first time, then I made the required changes but it was never reviewed again | 11:53 |
| crankharder | jodh: I was unable to reproduce that issue yesterday on a clean system - thanks for all the troubleshooting help yesterday anyways :) | 13:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!