[02:48] <unixpro1970> is it possible to send a dbus event to upstart?  I am having issues with PID tracking ( the app forks more than twice )  My app generates a pid file so I wish to send a dus message to change the PID that upstarts has stored for my service.  However when I issued a dbus-send it mentioned the PID field is READ-ONLY for my upstart application.
[03:13] <SpamapS> unixpro1970: no, thats not really possible.
[03:13] <SpamapS> unixpro1970: why does your service fork twice to daemonize?
[03:15] <unixpro1970> It forks multiple times and I don't have controll over the amount of times it forks.  Someone else wrote it and I am not allowed to modify the functionality. :-(
[03:15] <unixpro1970> Due to this the PID tracking is off.
[03:16] <SpamapS> unixpro1970: yeah, you're out of luck. Use pre-start and post-stop to start/stop the daemon.
[03:16] <SpamapS> unixpro1970: oh, and write a nasty email to the author.
[03:16] <unixpro1970> Tried that without luck.
[03:17] <unixpro1970> The other possible solution I was thinking of developing, was creating a proxy program that will catch upstart signals and can foward them.
[03:18] <unixpro1970> basically creating my own signal handler to catch the upstart signals and forward them using the pid file.
[03:18] <SpamapS> unixpro1970: thats a waste of your time honestly
[03:18] <SpamapS> unixpro1970: you can use pid files with upstart. Just use pre-start and post-stop.
[03:19] <unixpro1970> how can I force upstart to associate the PID within the pidfile?
[03:20] <unixpro1970> I have seen the start-stop-daemon example but I don't see how that will fix the upstart pid tracking problem.
[03:21] <unixpro1970> exec start-stop-daemon --pidfile
[03:24] <SpamapS> unixpro1970: no don't use exec. In pre-start, start it the same way you would start it in a sysvinit, and in post-stop, the same way sysvinit would stop it
[03:24] <SpamapS> unixpro1970: if you already have a sysvinit script, you can just call that in those methods. This is only useful if you need to coordinate other services with this one.
[03:25] <unixpro1970> but it will still track the incorrect PID even without exec keyword
[03:26] <unixpro1970> remember it forks more than twice
[03:27] <unixpro1970> the application creates a pidfile that contains the correct pid which I can read.  Howeve can I force upstart to use it?
[03:27] <unixpro1970> In other words, overwrite the PID that upstart thinks it is using.
[10:28] <drebolo> hi... I have some questions... I'm trying to create a user job in a ubuntu server but initctl is not seeing my jobs at $HOME/.init
[10:29] <drebolo> I'm using upstart 1.5
[10:29] <drebolo> I try to do the same thing in my desktop also with upstart 1.5 and worked
[10:32] <drebolo> both machines are Ubuntu 12.04.2 LTS
[10:32] <drebolo> the main difference is that the server doesn't have X installed
[10:35] <drebolo> any ideas ?
[10:36] <drebolo> this is just a test script: "task
[10:36] <drebolo> script
[10:36] <drebolo>     sleep 5
[10:36] <drebolo> end script
[10:36] <drebolo> "
[10:37] <drebolo> init-checkconf returns "syntax ok"
[13:22] <xnox> drebolo: user jobs are not enabled by default.
[13:22] <xnox> drebolo: and user jobs have been removed in the recent 1.7 upstart in raring.
[13:23] <xnox> drebolo: one needs to do a full login to initialise user session over dbus.
[13:23] <xnox> drebolo: there were tricks of doing it on the server but i can't quite remember how it was done.
[13:23] <xnox> drebolo: it is usually recommend to simply use setuid/setgid to change username/group.
[13:24] <drebolo> hum... that's the problem....
[13:24] <xnox> drebolo: what are you trying to do? maybe there is another way to do it better =)
[13:24] <drebolo> I don't do a full login... I just do su - username from root
[13:28] <drebolo> I want to start a pinto server (https://metacpan.org/module/Pinto) from a specific user
[13:34] <drebolo> I tried to do it from root but it keeps failing when I do ". /some/bashrc", and  If I managed to do it for that user I would not need to do that...
[14:05] <monkeynipples> how can i give a unprivileged user the ability to run a specific upstart job ?
[14:05] <monkeynipples> to start/stop/restart it
[14:06] <ion> Take a look at sudoers(5)
[14:07] <monkeynipples> ion: something like sudo -u username /etc/init/job.conf ? 
[14:08] <ion> The user won’t need -u username, it defaults to root. The user will use sudo start jobname.
[14:09] <xnox> monkeynipples: you can use policykit to grant users to work/do actions to specific jobs
[14:10] <xnox> monkeynipples: by adjusting /etc/dbus-1/system.d/Upstart.conf
[14:10] <xnox> monkeynipples: granting sudo might be a bit "haevy-weight" as granting sudo on "start" command will allow that user to start _any_ job.
[14:11] <monkeynipples> maybe just restart ? 
[14:11] <monkeynipples> xnox: i'll look into policykit thanks
[14:15] <monkeynipples> http://askubuntu.com/questions/229809/allow-non-sudo-group-to-control-upstart-job is a good link for anyone else interested
[14:16] <ion> xnox: Of course you would limit the parameters to exactly the specific jobname and nothing else.
[14:31] <monkeynipples> xnox: i tried adding https://gist.github.com/jarradh/1458fe6f105b561683f4 to /etc/dbus-1/system.d/Upstart.conf, rebooted server and tried to run it as testuser stop: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
[14:33] <xnox> hmm... not sure. jodh ^ do you know how to fiddle those settings?
[14:33] <xnox> or maybe we can poke pitti about it?
[14:34] <monkeynipples> I don't want to cause a fuss :S
[15:14] <xnox> monkeynipples: no fuss =) this stuff should just work™ and it doesn't seem like it's documented well enough in the cookbook.
[16:52] <X-warrior> if upstart is not tracking my PID correctly is it possible to set upstart to use a PID inside a file?
[16:56] <ion> PID files are horrible and unreliable.
[16:56] <ion> Can you make the process not daemonize?
[17:13] <X-warrior> not right now 
[17:14] <X-warrior> :/
[17:14] <X-warrior> and the daemon/fork doesn't works
[18:30] <Jeeves_> Hi
[18:30] <Jeeves_> I've got a mysqld that's not starting and an upstart that does not accept my explicit call to stop starting mysqld.
[18:30] <Jeeves_> Any hints?
[20:32] <SpamapS> Jeeves_: what version of Ubuntu?
[20:32] <SpamapS> Jeeves_: the mysql upstart job in 10.04 is quite tempermental.
[20:37] <Jeeves_> 12.04
[20:37] <Jeeves_> fixed it by chmod -x /usr/sbin/mysqld
[20:38] <Jeeves_> upstart lets me down 
[20:40] <SpamapS> Jeeves_: erm..
[20:40] <SpamapS> Jeeves_: there was nothing in /var/log/syslog, /var/log/upstart/mysql.log ?
[21:03] <Jeeves_> that mysql couldn't start
[21:03] <Jeeves_> and it would try to start it again
[21:04] <SpamapS> Jeeves_: so, it told you the truth, and that is letting you down?
[21:05] <SpamapS> Jeeves_: /usr/sbin/mysqld not being executable is *not* a normal situation.
[21:08] <Jeeves_> SpamapS: No, I told it to stop trying to start mysqld, which it refused to do
[21:08] <Jeeves_> 'stop ' would just hang
[21:09] <Jeeves_> It's not Upstarts problem mysql doesn't start, it's Upstarts problem that it will not stops trying to start it, even though I ask for it
[21:10] <Jeeves_> And I know -x on mysqld is not normal. But was the only way to stop mysqld
[21:24] <SpamapS> Jeeves_: the stop not responding is also not normal
[21:24] <SpamapS> Jeeves_: did you happen to see what 'status mysql' showed?
[21:26] <Jeeves_> Kinda lost that in my terminal..
[21:27] <SpamapS> Jeeves_: so stop will wait 300 seconds for mysqld to respond to its SIGTERM
[21:28] <SpamapS> Jeeves_: however if it was in respawn/post-start , it would be waiting for that section to exit presumably indefinitely.
[21:29] <SpamapS> Jeeves_: I think at most, that would have been 30 seconds
[21:30] <SpamapS> Jeeves_: what version of mysql-server-5.5 do you have installed btw?
[21:33] <SpamapS> Jeeves_: one other possibility is that there is something on your system 'start on stopping mysql', that will cause stop to hang.
[21:37] <Jeeves_> the only thing in /etc/init/ mentioning mysql is mysql.conf
[21:51] <SpamapS> Jeeves_: ok, its hard to debug this w/o knowing the status.. but likely was stuck in post-start