Upstart upgrades are creating problematic processes

[Removed by request]

I'm using Ubuntu 13.10 dev with upstart 1.9-0ubuntu2. I have noticed that the last few upgrades from Upstart are creating the process "/bin/sh -e /proc/self/fd/9" with the child process "/sbin/sulogin". These processes doesn't disappear until the system is rebooted. Trying to manually close these processes will result in an immediate reboot.
---
ApportVersion: 2.11-0ubuntu1
Architecture: amd64
DistroRelease: Ubuntu 13.10
EcryptfsInUse: Yes
MarkForUpload: True
NonfreeKernelModules: nvidia
Package: upstart 1.9.1-0ubuntu3
PackageArchitecture: amd64
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-3.10.0-4-generic root=UUID=05338ff8-a226-421b-90a4-1dd45199f783 ro
ProcVersionSignature: Ubuntu 3.10.0-4.13-generic 3.10.1
Tags: saucy
Uname: Linux 3.10.0-4-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UpstartBugCategory: System
UserGroups:

modified.conffile..etc.acpi.powerbtn.sh: [modified]
modified.conffile..etc.init.acpid.conf: [modified]
modified.conffile..etc.lxdm.lxdm.conf: [modified]
mtime.conffile..etc.acpi.powerbtn.sh: 2012-12-28T03:54:47.777320
mtime.conffile..etc.init.acpid.conf: 2012-12-28T03:54:47.825320
mtime.conffile..etc.init.control.alt.delete.conf: 2012-12-28T03:55:27.305318
mtime.conffile..etc.init.tty2.conf: 2012-12-28T03:55:27.321318
mtime.conffile..etc.init.tty3.conf: 2012-12-28T03:55:27.329319
mtime.conffile..etc.init.tty4.conf: 2012-12-28T03:55:27.337318
mtime.conffile..etc.init.tty5.conf: 2012-12-28T03:55:27.349319
mtime.conffile..etc.init.tty6.conf: 2012-12-28T03:55:27.357318
mtime.conffile..etc.lxdm.lxdm.conf: 2013-05-18T10:27:48.229151

[James Hunt (jamesodhunt)]

@Sworddragon - Thanks for reporting. Is this on a single system? Do you just have a single instance of the /proc/self/fd/9 process?

Please can you run 'apport-collect 1197789' on an affected system and follow the prompts to help debug this.

[Removed by request (removed3425744)]

Yes, it is a single user system and I'm seeing only one instance of both processes.

[Removed by request (removed3425744)]

apport fails at some point:

Authentication is required to collect system information for this problem report
Authenticating as: ,,, (sworddragon)
Password: .................................................................................................................................................................................................................................................

This goes infinite (access to my Launchpad account was already granted).

[Removed by request (removed3425744)]

apport information

[Removed by request (removed3425744)]

apport information

[Removed by request (removed3425744)]

apport information

[Removed by request (removed3425744)]

apport information

[Removed by request (removed3425744)]

apport information

[Removed by request (removed3425744)]

apport information

[Removed by request (removed3425744)]

apport information

[Removed by request (removed3425744)]

apport information

[Removed by request (removed3425744)]

apport information

[Removed by request (removed3425744)]

I have tried it now again and got the same problem with apport but after using sudo it worked without any delay.

[Steve Langasek (vorlon)]

The only case in which sulogin will be spawned this way in the default configuration is if the mountall job exits abnormally, triggering /etc/init/mountall-shell.conf. Do you have anything in /var/log/upstart/mountall.log that would explain such a failure?

[Removed by request (removed3425744)]

/var/log/upstart/mountall.log does not exist (even the directory /var/log/upstart does not exist). Does upstart create this directory correctly if it is missing and it has something to log? Because sometimes I'm cleaning up the /var/log directory.

[Steve Langasek (vorlon)]

upstart creates the directory on package install; it does not create it at runtime if it has been removed. So you will need to create this directory and then reboot, to get logs for mountall.

[Removed by request (removed3425744)]

After creating the directory and making a reboot here is my mountall.log. It is showing an error which is related to this problem: https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/855933

[Steve Langasek (vorlon)]

ok. and when this happens, is the mountall service still running?

[Removed by request (removed3425744)]

Permanently as a daemon? Then no, it is not running.

[Steve Langasek (vorlon)]

So the processes are almost certainly tied to the mountall-shell job. Does the problem happen after every reboot? When it does occur, you can confirm that it's the mountall-shell job by running 'sudo service mountall-shell status', which probably shows that the service is start/running.

There's nothing in mountall that would trigger this behavior because of a plymouth failure; anything that caused mountall to fail should also have printed a line out in the upstart log. So this looks like mountall is instead dying with a signal from outside. Any idea what could be causing such a thing on your system?

[Removed by request (removed3425744)]

> Does the problem happen after every reboot?

Yes, I'm currently never seeing mountall running. But I remember that I have seen it running permanently a few months ago.

> When it does occur, you can confirm that it's the mountall-shell job by running 'sudo service mountall-shell status', which probably shows that the service is start/running.

The output is "mountall-shell stop/waiting".

> Any idea what could be causing such a thing on your system?

No, I don't know what causes this behavior especially because I'm using a minimalistic system.

[mikewhatever (mikewhatever)]

Exactly the same thing happens on Trusty.

The content of the mountall log is simply:

fsck from util-linux 2.20.1
/dev/sda1: clean, 121029/9707520 files, 2596272/38812672 blocks
fsck from util-linux 2.20.1
/dev/sda1: clean, 121051/9707520 files, 2596257/38812672 blocks
/var/log/upstart/mountall.log (END)