Bug#727708: upstart user jobs
On Mon, Dec 30, 2013 at 05:35:49PM +, Ian Jackson wrote:
> Steve Langasek writes ("Re: Bug#727708: upstart user jobs"):
> > On Sat, Dec 14, 2013 at 12:31:57PM +, Ian Jackson wrote:
> > > I have some questions about these. Forgive me if I could just have
> > > looked up the answers:
> > > Are they enabled by default in jessie/sid ?
> > > (If the answer is "no" then feel free not to answer the rest...)
> > "No" :)
> > Using upstart user jobs in Debian would imply a whole added level of
> > transition above and beyond adoption of upstart as init, and would require
> > coordination with maintainers of e.g. desktop environment packages and
> > display manager packages. I think it would be a logical next step for
> > Debian to consider, if it adopted upstart as a default; but so long as
> > upstart is not the default in Debian I don't think it would be a good idea
> > to try to support this in Debian.
> I'm not sure I see the connection. AIUI user jobs are a way to do
> roughly what cron's @reboot facility does, only better.
The topic of upstart user jobs has evolved since upstart 1.6. As they're
used in Ubuntu 13.04 and later, the entire desktop session is run as a set
of upstart jobs, giving service supervision and better cleanup handling on
logout. That is not something that we should try to enable in the upstart
package in Debian without careful coordination with other maintainers.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
Bug#727708: upstart user jobs
Steve Langasek writes ("Re: Bug#727708: upstart user jobs"):
> On Sat, Dec 14, 2013 at 12:31:57PM +, Ian Jackson wrote:
> > I have some questions about these. Forgive me if I could just have
> > looked up the answers:
>
> > Are they enabled by default in jessie/sid ?
> > (If the answer is "no" then feel free not to answer the rest...)
>
> "No" :)
>
> Using upstart user jobs in Debian would imply a whole added level of
> transition above and beyond adoption of upstart as init, and would require
> coordination with maintainers of e.g. desktop environment packages and
> display manager packages. I think it would be a logical next step for
> Debian to consider, if it adopted upstart as a default; but so long as
> upstart is not the default in Debian I don't think it would be a good idea
> to try to support this in Debian.
I'm not sure I see the connection. AIUI user jobs are a way to do
roughly what cron's @reboot facility does, only better.
> > In the manpage I read:
> > | Note that a user job configuration file cannot have the same name
> > | as a system job configuration file.
> > I don't understand this restriction. It's sounds like it's referring
> > to the pathnames in which case it's trivially true, so I assume it's
> > referring to job names.
>
> Hmm, this sounds like a documentation bug, a throwback to an earlier
> iteration of the user job support. Which manpage did you find this in?
http://manpages.debian.net/cgi-bin/man.cgi?query=init&sektion=5&apropos=0&manpath=Debian+testing+jessie&locale=
> > The docs say:
> > | Files in this directory will be read and an inotify(7) watch
> > | created the first time a user runs initctl(8).
> > Does this really mean that if I'm fiddling around with writing some
> > jobs, but not quite ready yet, and say "initctl --help", my jobs will
> > start to run ? Also, it would appear to imply that user jobs aren't
> > started automatically at boot.
>
> This seems to be a quote from the 1.6.1 version of the manpage, in wheezy.
> The user session support in the current releases of upstart (the only
> implementation that's been used in production in Ubuntu) doesn't work this
> way; and the manpage has been updated to match.
OK, good, thanks.
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727708: upstart user jobs
Hi Ian, On Sat, Dec 14, 2013 at 12:31:57PM +, Ian Jackson wrote: > I have some questions about these. Forgive me if I could just have > looked up the answers: > Are they enabled by default in jessie/sid ? > (If the answer is "no" then feel free not to answer the rest...) "No" :) Using upstart user jobs in Debian would imply a whole added level of transition above and beyond adoption of upstart as init, and would require coordination with maintainers of e.g. desktop environment packages and display manager packages. I think it would be a logical next step for Debian to consider, if it adopted upstart as a default; but so long as upstart is not the default in Debian I don't think it would be a good idea to try to support this in Debian. > In the manpage I read: > | Note that a user job configuration file cannot have the same name > | as a system job configuration file. > I don't understand this restriction. It's sounds like it's referring > to the pathnames in which case it's trivially true, so I assume it's > referring to job names. Hmm, this sounds like a documentation bug, a throwback to an earlier iteration of the user job support. Which manpage did you find this in? The current implementation certainly has no such restriction. For instance, on an Ubuntu system there are both /etc/init/dbus.conf and /usr/share/upstart/sessions/dbus.conf, for the system bus and the session bus respectively, and these do not collide. System-level events are visible to the user session, but they are qualified with a disambiguating ":sys:" prefix. > Does anything that user jobs do depend on upstart being pid 1, or > being root ? Does the thing which reads (and watches) the user's > configuration files run as root, or as the user ? I.e., what is the > privilege separation ? The upstart "session init" runs as the user, not as root. I'm not sure if upstart as a user session has any dependencies on upstart being PID 1. Cc:ing James, who would know better - James, do you know if upstart session init works on non-upstart systems? > The docs say: > | Files in this directory will be read and an inotify(7) watch > | created the first time a user runs initctl(8). > Does this really mean that if I'm fiddling around with writing some > jobs, but not quite ready yet, and say "initctl --help", my jobs will > start to run ? Also, it would appear to imply that user jobs aren't > started automatically at boot. This seems to be a quote from the 1.6.1 version of the manpage, in wheezy. The user session support in the current releases of upstart (the only implementation that's been used in production in Ubuntu) doesn't work this way; and the manpage has been updated to match. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#727708: upstart user jobs
I have some questions about these. Forgive me if I could just have looked up the answers: Are they enabled by default in jessie/sid ? (If the answer is "no" then feel free not to answer the rest...) In the manpage I read: | Note that a user job configuration file cannot have the same name | as a system job configuration file. I don't understand this restriction. It's sounds like it's referring to the pathnames in which case it's trivially true, so I assume it's referring to job names. In which case surely this is a troublesome restriction: what, for example, if a user, knowing that the sysadmin is going to install something that creates job "foo", creates a job "foo" themselves first ? Can two different users create two jobs with the same name ? The underlying purpose of the restriction would seem to probably be to make job names unqualified by username but unique across users, but that seems wrong to me. Does anything that user jobs do depend on upstart being pid 1, or being root ? Does the thing which reads (and watches) the user's configuration files run as root, or as the user ? I.e., what is the privilege separation ? The docs say: | Files in this directory will be read and an inotify(7) watch | created the first time a user runs initctl(8). Does this really mean that if I'm fiddling around with writing some jobs, but not quite ready yet, and say "initctl --help", my jobs will start to run ? Also, it would appear to imply that user jobs aren't started automatically at boot. Thanks, Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
