mountall vomits a shell onto virtual console when you run vi

[James Troup]

Binary package hint: mountall

I have an awesome bug. On a server upgraded from hardy -> karmic, if
I run vi as root on the console, mountall loses it's mind (because
it's still running and thinks it owns the console, apparently) and
spawns a shell onto the console that vi is running on.

--debug log of mountall attached

[James Troup (elmo)]

 mountall 0.2.6~boot1 from the ubuntu-boot PPA fixes this for me. Thanks, Scott

[J. Alexander Jacocks (jjacocks)]

I can confirm this same issue on a freshly-installed 9.10 rc i386 system.

[Michael B. Trausch (mtrausch)]

Please see bug 460153 for additional information. This causes some strange other issues that prevent me from being able to use 9.10 RC on a server.

[Scott James Remnant (Canonical) (canonical-scott)]

The fix introduced other regressions, Johan had a better fix

[Launchpad Janitor (janitor)]

This bug was fixed in the package mountall - 1.0

---------------
mountall (1.0) karmic; urgency=low

  [ Kees Cook ]
  * Call out to restorecon after mounting tmpfs filesystems. LP: #456942.

  [ Johan Kiviniemi ]
  * Fix a bug introduced by the 0.2.6 change. In certain situations, we’d
    quit even though we’re still waiting for some filesystems to be
    mounted. LP: #456806.

  [ Scott James Remnant ]
  * Don't clear the splash screen when we're waiting for filesystems,
    instead just output following whatever else is there. In non-verbose
    mode this won't look any different, but it means we don't clear previous
    verbose mode text. LP: #458389.
  * Only update the "waiting for one or more mounts" text if there's actually
    a change in the set we're waiting for; this removes the need for a CLEAR
    this case anyway.
  * Don't say we're waiting for mounts we're, in fact, not waiting
    for. LP: #459859.
  * Stop mountall (normally) when entering recovery mode. LP: #458060.

  * Clean up source tarball. LP: #460348.

 -- Scott James Remnant <email address hidden> Mon, 26 Oct 2009 09:30:41 +0000

[FormerSlacker (sousa-paul)]

Just thought I'd pipe in and mention this issue still exists on my system even with the latest mountall.

[Scott James Remnant (Canonical) (canonical-scott)]

Oh , I see the problem:

change "stop on rcS" in /etc/init/mountall.conf to:

 stop on starting rcS

Scott
--
Scott James Remnant
<email address hidden>

[FormerSlacker (sousa-paul)]

Thank you Scott. I can confirm that your fix solves the recovery console issues on my machine, it now functions as expected.

However, the tty1 mountall maintenance issue persists. Log into tty1, execute vim, press ESC and I'm greeted with the mountall maintenance menu and a root prompt.

[Kevin Light (klight)]

After boot I was seeing constant disk activity and moderate cpu usage (50% +) and eventually determined that mountall was the reason. My symptoms were similar to those posted for bug # 460153.

I applied the change in post #8 and rebooted and the problem went away.

[Nicholas Campion (campnic)]

I am seeing this issue as well. The final messages I see on my vanilla server install after boot are:

One or more of the mounts listed in /etc/fstab cannot yet be mounted:
(ESC for recovery shell)
swap: waiting for /dev/mapper/cryptswap1

This is a fully upgraded but completely default (not additional software selected) install of 9.10 with encrypted user folders.

The reason I wanted to add a comment is that I was experiencing some other behaviors that might be related. The first thing I tried to do was to apt-get update / upgrade to see if that fixed the mountall error and I couldn't sudo because my password got rejected. When I would type the password and hit enter, the prompt would not respond, so I'd hit enter again, and it would respond and say the password was incorrect. It was as if the first enter keystroke was lost.

I tried to ssh into another box to see if that was working and had my password rejected by the remote system. Again, the password prompt would act as though my first enter keystroke was lost. And then my password was rejected on a system I could access from another terminal.

The shell on the system works well as long as I don't hit escape (the mountall recovery shell problem) and as long as I don't try to enter a password. I haven't yet determined that they are directly related but thought this might catch someone's eye.

[Launchpad Janitor (janitor)]

This bug was fixed in the package mountall - 1.1

---------------
mountall (1.1) lucid; urgency=low

  * Update to use external libnih.
  * Updated autoconf details at same time to match libnih.
  * rcS is a job, not an event. LP: #456806.
 -- Scott James Remnant <email address hidden> Sun, 29 Nov 2009 20:16:10 +0000

[Micah Gersten (micahg)]

Scott, someone came in asking about this bug, so I figured I'd attach the patch for the SRU.

[Micah Gersten (micahg)]

I meant to say someone asked in #ubuntu-bugs about it.

[Scott James Remnant (Canonical) (canonical-scott)]

On Sun, 2009-12-06 at 09:25 +0000, Micah Gersten wrote:

> Scott, someone came in asking about this bug, so I figured I'd attach
> the patch for the SRU.
>
> ** Attachment added: "Debdiff for Karmic"
> http://launchpadlibrarian.net/36494855/mountall_1.0.1.debdiff
>
This patch is already in the bzr branch for karmic

Scott
--
Scott James Remnant
<email address hidden>

[Martin Pitt (pitti)]

Accepted mountall into karmic-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[artlogic (artlogic)]

This fix works for me - thanks Martin and all.

[artlogic (artlogic)]

Unfortunately I spoke too soon. It seems like the issue has come back. After upgrading I verified mountall wasn't still running when I logged in with "ps -A | grep mountall" and got nothing back. But today, oddly enough after flashing the BIOS, the issue seems to have returned. Unfortunately on reboot I noticed the same issues (mountall interfering with the shell, arrow keys, and editors). It's still running and I verified I'm on mountall 1.0.1. Once I kill it, normally things go back to normal - sometimes - once in a while it seems to clobber the terminal - but I can switch to another virtual terminal (Ctrl-Alt-F2, etc...) and cleanup.

Not sure if this is related or not - but I am running with encrypted home directories, and on bootup I always see the message: one or more mounts listed in /etc/fstab cannot yet be mounted. I'm also running mdadm RAID 1. Both things seem to be working fine.

This is a fresh install of 9.10 server 64 bit with fairly small changes configuration wise.

[Laurent Birtz (laurent-birtz)]

Demonize code:

/* Become daemon */
if (daemonise) {
        pid_t pid;

        /* Fork once because Upstart makes us a session leader,
         * or we may be a session leader of an existing process
         * group.
         */
        pid = fork ();
        if (pid < 0) {
                nih_fatal ("%s: %s", _("Unable to become daemon"),
                           strerror (errno));

                exit (EXIT_ERROR);
        } else if (pid > 0) {
                exit (0);
        }

        /* Create a new session */
        setsid ();

        /* Fork again so that we're not the leader of that session */
        pid = fork ();
        if (pid < 0) {
                nih_fatal ("%s: %s", _("Unable to become daemon"),
                           strerror (errno));

                exit (EXIT_ERROR);
        } else if (pid > 0) {
                exit (0);
        }

        /* Usual daemon cleanups */
        if (chdir ("/"))
                ;
        umask (0);

        /* Send all logging output to syslog */
        //openlog (program_name, LOG_PID, LOG_DAEMON);
        //nih_log_set_logger (nih_logger_syslog);

        nih_signal_set_ignore (SIGHUP);
}

The standard input file descriptor isn't closed so mountall is still
using the terminal after the daemon is started. The daemon is thus
reading input from the terminal and modifying its settings concurrently
with whatever process is using the terminal after the launch of mountall.

On my system running 'mountall --daemon' manually will hang the shell
roughly 50% of the time. The race condition is highly
environment-dependent. Running with strace -f won't trigger the problem,
for example.

In my opinion the behavior of mountall --daemon is broken.

This bug is still present in mountall-2.1.

[mrmookie (mrmook)]

This is still happening in MARCH! Any way to fix this permanently yet?

[Scott James Remnant (Canonical) (canonical-scott)]

On Thu, 2010-03-11 at 21:58 +0000, mrmookie wrote:

> This is still happening in MARCH! Any way to fix this permanently yet?
>
The fix was NAK'd by artlogic on 2010-01-02; our Stable Release Updates
procedure does not allow us to continue with the backport AFAIK

Scott
--
Scott James Remnant
<email address hidden>

[Martin Pitt (pitti)]

In order to not block the followup SRU I reopen the bug. While the -proposed update was said to not fix this bug, it wasn't a regression either.

[Peter McKenna (peter-mckenna)]

I've just come across this bug. I have the following setup.
/dev/md0 is a 4 disk RAID1 array (/dev/sda1 to sdd1) mounted on /.
/dev/sda2 to /dev/sde2 are all swap partitions (sde2 is on the spare disk). In fstab all swap partitions use options sw,pri=1,ifexists. I don't think the ifexists option is having any affect.
/dev/md1 is a 4 disk RAID5 array (/dev/sda3 to sdd3)with 1 spare (sde3) mounted on /home.
When I tested a disk failure by disconnecting sda, the RAID arrays all worked fine, but I started getting errors about the swap partition on sda2 not being there. Then I got to experience the nasty effects that mountall has on nano...(same as described on vim above) and the console. Interestingly, a second console opened with ctl-alt-f2 is not affected.
It appears to me that mountall spews when it can't mount sda2 as if it is using swapon -a instead of swapon -a -e, which is what I am trying to achieve with the ifexists option in fstab.
I don't know how to pass the swapon -e option to mountall or even if it is possible, but it would at least solve part of the problem if it was.

[Scott James Remnant (Canonical) (canonical-scott)]

Have given up with this SRU. Anyone affected can upgrade to Lucid soon enough.

[James Roper (jroper2-gmail)]

I'd love to upgrade to Lucid, but I can't log in to my machine, I've got a graphics card issue that prevents normal boot, and this issue prevents recovery mode from working. Are there any work arounds I can use so I can get a root shell that works?