[00:00] Is there a way to run a command inside an upstart script as the root user if you are using setuid to run the process as a different user? [00:01] I need to ensure the existence of a pid directory, and the user running the process doesn't have permissions to create the dir [00:03] geekbri: unfortunately no, its a known deficiency of setuid/setgid :( [00:03] geekbri: for that, you'll want to remove the setuid/setgid and use start-stop-daemon to run the end-command as the user. [00:03] SpamapS: That stink :(. I want to use setuid and setgid so i can use "limit" to set the ulimits [00:04] geekbri: http://upstart.ubuntu.com/cookbook/#changing-user [00:05] geekbri: you can make a second job, that is 'start on starting foo' that does the directory bit [00:05] SpamapS: yeah, I was hoping to avoid that :-\ [00:05] geekbri: the idea I had is to have the pre-start/exec/script/etc. keywords take optional setuid/setgid args [00:06] geekbri: nobody has had time to implement it though [00:06] Yeah, it would be nice if you could force a particular script stanza to run as a different user [00:06] that would solve my problem, and makes perfect sense :) [00:07] geekbri: "patches accepted" [00:07] Yeah, I haven't looked at the upstart code base at all. I might be able to whip something up and submit a patch [00:08] Ah, wish it was using git :) [00:13] Well thanks for the help. Not sure how i'll end up dealing with this as i need to set the limits as well and thats a shell built in so can't be called with sudo. Either way appreciate it [12:19] jodh: does libnih also need malloc removal? [12:19] yeah [12:20] xnox: want to volunteer? ;) [12:20] *sigh* [13:06] woglind, when it returns 1, opkg marks the package as "install user unpacked" instead of "install user installed" that means the postinst failed, that means it will try to launch the postinst everytime opkg configure is launched [13:07] oops wrong channel === jeremy is now known as Guest68450 === Guest68450 is now known as Guest-jeremy [15:08] Hi guys! I googled my query but can't find any answers. I would like to wait a specific amount of time between each respawn of my process. Could upstart even capable of that? [15:21] http://upstart.ubuntu.com/wiki/Stanzas#respawn_limit [15:21] Guest-jeremy: ^ should do what you want [15:24] Guest-jeremy: ... or to actually delay the respawn itself, you could do something like 'post-stop exec sleep 7'. [15:24] thx guys ! [15:25] I think it answer perfectly my issue [18:20] ok so if expect fork expects the thing to fork 1, and expect daemon expects it to fork twice, what do i do for a piece of software i have that forks 3 damn times :) [18:21] geekbri: it's bad software. Why does it do that? =)))) [18:21] xnox: I don't know, but its sure not making life easy is it :) [18:21] geekbri: the best solution is to make it run in foreground and not fork at all. [18:21] Yeah, i was hoping to avoid doing that, but I think that is what i will do [18:21] geekbri: stdout & stderr will be logged into /var/log/upstart/$job.log [18:22] geekbri: it's actually for the best & most reliable way. [18:23] geekbri: in autofs5 i patched out pointless forks by moving daemonisation first and made all other forks it performs to be done once it has daemonised already. [18:23] that way the first fork was the right one to track all all others appeared & disappeared. [18:23] what is it doing in those three forks?! [18:23] xnox: I discovered the issue actually. I'm running the daemon via sudo, so I guess thats causing it to fork an extra time. I have to do this as I can't use setuid and setgid because I need to create a directory in the startup script, but if i setgid it doesn't have persm to create the directory [18:24] geekbri: yes sudo adds an extra pointless fork, don't do that. [18:24] how will i run it as a different user then if i can't use setuid because I need to run commands as a privileged user in the upstart script? [18:25] geekbri: what directories are you creating? can the be shipped by a package? Also directories can be created in a separate job with stanza task which you can depend on. [18:25] and later you can start/stop/restart your main daemon without worrying about directories, cause they will be there. [18:25] xnox: Was hoping to avoid creating 2 upstart jobs for 1 daemon as that seems like a hacky work around. I need to ensure the pid directories exist, or else it explodes why trying to run [18:26] Life would be so much easier if you could just specify only certain stanzas to run under setuid :) [18:26] geekbri: but if you are running it in foreground it shouldn't need any pid directories..... [18:26] right, but, ok the issue here is [18:26] geekbri: start-stop-daemon can exec, rather than fork+exec. Why are you using sudo? [18:26] Im working on writing a recipe esentially that runs on multiple platforms and supports multiple job control types, EG upstart / init.d etc [18:26] geekbri: I am not sure but doesn't setuid only affect script/exec or do they affect pre-start as well?! [18:27] So I was trying to create an upstart script that would cause the least amount of configuration file changes in the daemon itself [18:27] xnox: setuid and setgid effect everything in the upstart job [18:27] ok. [18:27] xnox: setuid is global [18:27] if you call setuid, no matter if you have something before or after it, the whole script is running as that user [18:27] xnox: we've talked about having overrides per execution stanza [18:28] geekbri: I still want to know which dir you are creating though =) [18:28] im creating a directory in /var/run for the daemon [18:28] yes i know if i run it in the foreground it shouldn't need a pid, so i may have to do all of that [18:29] I was just looking for ways to avoid it, as its going to cause a bunch of adding complexity and logic in the configuration file due to upstart [18:29] it looks like, unfortunately, I don't have a choice [18:30] the pid stanza is to tell upstart where it should store a pid file, not where the pidfile to read would be located correct? [18:30] upstart and pid stanza ?! [18:30] http://upstart.ubuntu.com/wiki/Stanzas#pid [18:31] geekbri: this is obsolete. [18:31] geekbri: http://upstart.ubuntu.com/cookbook/ [18:31] there is no pid stanza any more. [18:31] as far as I know. [18:32] ah ok, must have been deprecated. That's unfortunate [18:32] esentially none of the software write out pids correctly (together with clearing stales once and when dieing) [18:32] geekbri: please read the new cookbook I am sure you will be enlighten on how to potentially solve your use case better. [18:32] Sounds like the solution is, modify the configuration file when upstart is the job control type so that it does not daemonize [18:33] which is what i was trying to avoid, but thats ok. [18:33] geekbri: why would running in foreground cause complexity? [18:33] geekbri: ahh, it doesn't have a cli option to specify that? [18:34] which .. most things do [18:34] SpamapS: the complexity doesn't lie within configuring this thing to run with upstart so much as I am writing somethign that allows selection of the job control type (EG, upstart / initd / runit / monit) [18:34] so I was attempting to try and keep the majority of the configuration changes necessary for that in the startup scripts themselves, and out of the configuraiton of the daemon itself [18:35] yeah, thats what cli options are for [18:35] yeah, and I could move them out from the conf file to the CLI [18:35] exec yourthing --foreground is pretty darn clear and simple [18:36] im not sure if the cli options override was in the config file, thats a good question, lets find out. [18:37] always should [18:37] defaults -> conffile -> cli -> runtime .. that should be how things are set [18:40] how things should work and how they do work, well [18:40] not always 1:1 [18:46] aye [18:59] Ok, one last question here. [19:00] oh nevermind maybe i solved it