[19:53] <durka42> hi. what's the right way to write an upstart conf that runs my service as a specific user?
[19:53] <durka42> I am using "setuid" and "setgid", but some strange things are happening with USB device access that make me think perhaps I'm doing it wrong
[21:06] <JanC> durka42: some things also require a login session (I think there is something about that in the cookbook--see topic)
[21:19] <durka42> JanC: I'm a little confused, the cookbook has section 11.43.1 about how to "Run a job as a different user", which is what I want to
[21:19] <durka42> but that eventually links to section 4.2.3, which actually doesn't explain at all how to run a job as a different user
[21:19] <durka42> is there a better guide?
[21:21] <durka42> it sort of says I should "arrange for `init --user` to be run", but I have no idea how to do that
[21:30] <JanC> --user is for running upstart as a session daemon after login
[21:31] <durka42> right
[21:31] <durka42> but "run a job as different user" links to "user job" which links to "session job"
[21:31] <durka42> which says I need session daemon
[21:31] <durka42> but doesn't explain how to solve the original problem :)
[21:33] <durka42> I guess a session daemon executes all jobs as the user that owns the session
[21:34] <durka42> but would those jobs still be managed using 'service'? and if not, how? also, this is a headless machine where I don't want to have to log in
[21:35] <JanC> http://upstart.ubuntu.com/cookbook/#run-a-job-as-a-different-user & http://upstart.ubuntu.com/cookbook/#checking-how-a-service-might-react-when-run-as-a-job might be useful
[21:35] <JanC> 11.43.2 on the first link
[21:35] <durka42> that first link is where I was already looking, but the second one might help me track down the device access bug
[21:36] <durka42> yeah, 11.43.2 is what I am trying now
[21:36] <durka42> even though it says "don't do this! here is how to do this", haha
[21:36] <durka42> well shit, now I have an unbootable system
[21:37] <JanC> for most things su/sudo are not appropriate, but if you have something that expects to be run as an interactive user...
[21:39] <JanC> also, screen/tmux is sometimes used
[21:39] <JanC> but fixing USB access rights is maybe a better solution  :)
[21:42] <durka42> I am running under screen yes
[21:42] <durka42> well, I figured root would be able to access all the devices!
[21:44] <durka42> argh, the pre-stop script doesn't work when I change it to use su instead of setuid/setgid
[21:44] <durka42> why so fragile, upstart :(
[21:45] <durka42> JanC: any change you want to take a look at my service file and tell me all the terrible mistakes I'm making?
[21:45] <durka42> chance*
[21:47] <JanC> the fact that you are running this under screen means that it's not a proper daemon and is not meant to be run like that...
[21:47] <durka42> that's correct
[21:47] <durka42> all I really want from upstart is start-on-startup and respawn-on-crash
[21:48] <durka42> is that too much to ask? :)
[21:48] <JanC> and I don't really have experience with running "services" under screen
[21:48] <durka42> or is there a middleman daemon that people use to get that kind of behavior
[21:49] <JanC> IIRC some people have been using it for that popular game (I forgot the name)
[21:49] <JanC> http://upstart.ubuntu.com/cookbook/#run-an-application-through-gnu-screen
[21:50] <durka42> minecraft?
[21:50] <JanC> yep
[21:50] <durka42> yes, I saw that section
[21:50] <JanC> there are probably tutorials for that somewhere
[21:50] <durka42> my exec line is similar but I have exec setsid screen -L -Dm -S nri ./run.sh
[21:50] <JanC> e.g on ask ubuntu
[21:51] <durka42> yeah
[21:51] <durka42> I'll check around there
[21:51] <durka42> or I'll give up on upstart and use some other hack :(
[21:52] <JanC> it's not really upstart that is the problem AFAIK  :)
[21:53] <durka42> well, upstart is ubuntu's service runner
[21:53] <durka42> maybe cron can do what I want with less fuss?
[21:53] <JanC> but you are trying to run a non-service as a service
[21:53] <JanC> cron will likely have the same issues
[21:54] <durka42> well, screen -D should take care of that
[21:54] <JanC> which is why you want to debug what you need but is missing
[21:55] <durka42> if my program were perfect, I wouldn't need the attachable screen _or_ the respawn-on-crash
[21:55] <durka42> but I have to be able to debug somehow
[21:56] <JanC> maybe the program can be run in debug mode, or whatever?
[21:56] <JanC> also, check if it runs with certain environment variables missing, etc. etc.
[21:57] <durka42> I wrote the program, so I know what environment variables it needs etc
[21:57] <durka42> it appears to run exactly the same except the camera driver fails with "device not found", that's all :(
[21:57] <durka42> even after the camera driver enumerates devices and says it is there :p
[21:58] <JanC> udev has to make it available
[21:58] <JanC> set the appropriate access rights etc.
[21:59] <durka42> hmm
[21:59] <durka42> and so somehow it's denying access to setuid'd root?
[21:59] <durka42> you'd think root would get what it wants
[21:59] <JanC> it might also be available under a not-so-well-known location
[22:00] <durka42> I admit to having no idea how the camera driver tries to access the device
[22:00] <durka42> I just tell it "search for any device with any serial number and give me a handle to the first one"
[22:01] <durka42> and for some reason this works in a shell, but not under my current upstart setup
[22:01] <JanC> the debug link I gave above should give you some ideas about debugging in an environment that differs from a normal shell
[22:02] <durka42> yes, I will try that
[22:02] <durka42> gotta run
[22:02] <durka42> thanks for your advice!
[22:03] <JanC> for example, some USB device access rights are set depending on the currently active login session
[22:03] <JanC> so e
[22:03] <durka42> interesting
[22:04] <JanC> so e.g. if you are working on your desktop, the currently active user session can access the camera  :)
[22:04] <durka42> right
[22:05] <JanC> and if you switch to another user, that user gets camera access
[22:05] <JanC> etc.
[22:05] <durka42> so there may be very good reasons that services are denied access to camera devices! :p
[22:05] <durka42> though I'm not sure linux knows this device is a camera
[22:05] <durka42> anyway, need to go see a man about a horse
[22:06] <JanC> it's not only for cameras of course