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