This is rather an interesting one: we first added support for running upstart as a non-priv user, we forced it to run in debug mode (since debugging was the main reason for running init as a non-priv user). As such, when you run "init --user", you are automatically in debug mode ('initctl log-priority' confirms this).
This problem has not been seen on the desktop because there, the login script redirect stdout to null and only redirect stderr to $HOME/.xsession-errors... but Upstart, when run as a non-priv user, outputs its debug to stdout.
There are 2 work-arounds for this problem:
1) Create a job that specifies:
start on startup
exec initctl log-priority message
2) Use shell redirection to change the exec line in /etc/init/ubuntu-touch-session.conf to discard stdout.
This sounds a little extreme, but higher priority messages from Upstart go to stderr and hence *will* still get logged to /var/log/upstart/ubuntu-touch-session.log as expected.
This is rather an interesting one: we first added support for running upstart as a non-priv user, we forced it to run in debug mode (since debugging was the main reason for running init as a non-priv user). As such, when you run "init --user", you are automatically in debug mode ('initctl log-priority' confirms this).
This problem has not been seen on the desktop because there, the login script redirect stdout to null and only redirect stderr to $HOME/. xsession- errors. .. but Upstart, when run as a non-priv user, outputs its debug to stdout.
There are 2 work-arounds for this problem:
1) Create a job that specifies:
start on startup
exec initctl log-priority message
2) Use shell redirection to change the exec line in /etc/init/ ubuntu- touch-session. conf to discard stdout.
This sounds a little extreme, but higher priority messages from Upstart go to stderr and hence *will* still get logged to /var/log/ upstart/ ubuntu- touch-session. log as expected.