I believe the upstart jobs inherit the stdio settings the upstart (init)
itself had at bootup, which likely point to whatever was considered the
"console".  Simply telling upstart to "start" a job (service vsftpb
start) notifies the upstart daemon over d-bus to start the child
process.  Hence, it has no direct means of knowing the current console
session of the user.

The sysv init script system, by contrast, would start the daemon
directly from the issuing command (like sudo /etc/init.d/vfstartd start)
which of course would inherit the stdio settings of the user executing
the command.

This of course does not offer a solution, but rather offers better
understanding of the actual core problem.

I believe this question and issue should be forwarded to upstart at
least for discussion.  I could do a separate summary and bug report for
that.

Basically, some daemons (like vsftp) may prompt the user during startup.
A common case might be to get the password for unlocking a password
protected private key, and I am sure this can apply to many other
daemons that may do this including for example apache.  I do not believe
upstart has any provision to handle this kind of scenario other than, at
boot, if the process is started then, it's password prompt should appear
on whatever was the "console".

-- 
Unable to start vsftpd with upstart if private key
https://bugs.launchpad.net/bugs/604185
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to