'reboot now' reverting to maintenance mode, instead of rebooting

Actually just exoerienced this same symptom on a machine running 12.04.2, on 'shutdown now' went into maintenance console. Is this normal ?

Status changed to 'Confirmed' because the bug affects multiple users.

Also happening to me - same symptoms. Updated server to 13.04.
MOTD still says "New release '13.04' available"
"reboot" command on its own works fine - it displays the following:

Rather than invoking init scripts through /etc/init.d, use ther service(8)
utility, e.g. service S35networking stop
initctl: Unknown job: S35networking

Since the script you are attempting to invoke has been converted to an
Upstart job, you may also use the stop(8) utility, e.g. stop S35networking

"reboot now" comes up with a 'fail' when killing all remaining processes and then a prompt:
Give root password for maintenance

screenshot attached.

"shutdown now" is supposed to switch to single-user mode (see bug 1065851).

"reboot now" is invalid - the shutdown command takes a time parameter (such as "now"), but the reboot command does not (see the man page). By specifying "reboot now" you are asking the system to reboot by running the "now" command, which is erroneous.

Usage: shutdown [OPTION]... TIME [MESSAGE]
Bring the system down.

Usage: reboot [OPTION]...
Reboot the system.

Just out of curiousity. Why no 'time' for reboot? These commands are similar in purpose, so one would expect that level of consistency between them

I'll also be happy go back on my previous rant which may otherwise have come across as rude, if it can be explained why 'shutdown now' does not halt the system by default. It would seem to me that 'power-off' is a far more intuitive default action to be associated with 'shutdown TIME' than merely reverting to single-user mode? Why doesn't single-user mode require an argument the way halt would anyway?

Because that is how shutdown has worked for 20+ years.

That is the point though. If retaining conventions of the past is such an important factor, then I wonder why I could (until recently, at least) issue 'shutdown now' or 'reboot now' on any machine running debian/ubuntu, and it would complete a full power-off, or reset, respectively, each time...
If you wish to insist that, well, I was 'doing it wrong' for what could well be 20+ years in my case prior to these changes, then I am happily to concede that. However, if that is the case, then I wish know why it behaved the way I have described until these recent changes. You see, these bugs (1174272 & 1065851) were confirmed by others, implying that others have also experienced the 'unexpected' (unintuivie/'buggy') effects of these changes. If indeed shutdown only powers-off when '-h/-H' is used, and reboot is expected to revert to single-user mode when 'now' is supplied as an argument [who would have thought...?]) then it would seem that the method I've used for the past 20+ years, or to rephrase: 'the way shutdown has worked' for at least the last couple of years, that I can recall, has been recently changed? Surely mere convention is no excuse to obstruct progress to code in any case...

Welcome to Ubuntu 12.04.2 LTS (GNU/Linux 3.2.0-40-generic-pae i686)
root@host1:~# reboot now
The system is going down for reboot NOW!

Welcome to Ubuntu 13.04 (GNU/Linux 3.9.0-030900rc8-generic i686)
root@host2:~# reboot now
The system is going down to maintenance mode NOW!

(the same for shutdown)

It would seem that, sometimes, logic is not enough proof :)

It was an error in that release of upstart that has been corrected. Classic sysvinit shutdown has behaved this way because that is how unix systems have always done it.

I just performed a fresh install of Ubuntu Server 13.04 i386. The initial reboot was fine, but using "sudo reboot -h now" caused this to happen. From single-user mode root I was able to run "shutdown -h now" and it booted back up fine.

So, the preferred method is just "sudo reboot" from here on out? I'm fine with it, just making sure.

reboot with no arguments reboots now. shutdown -h powers off, and shutdown -r reboots, with an optional time argument. As always, Read The Friendly Manual ;)

same here - reboot now worked for me for years... now doesnt work after upgrade to 13.04 desktop.

Trusty is borked.

This also affects 13.10 (Saucy Salamander). Extremely aggravating, especially on a remote headless server. (Thus no screenshot.)

There is no need to keep commenting on this: once again, it is not a bug, the reboot command does not take a time argument.

Not taking an argument is one thing, failing to reboot with an error message would then be fine.

A completely different thing is showing unexpected behavior, by shutting everything down and leaving an open root console.

This is the current manual page in trusty:

----
SYNOPSIS
       reboot [OPTION]... [REBOOTCOMMAND]

       halt [OPTION]...

       poweroff [OPTION]...

DESCRIPTION
       These programs allow a system administrator to reboot, halt or poweroff the system.

       When called with --force or when in runlevel 0 or 6, this tool invokes the reboot(2) system call
       itself (with REBOOTCOMMAND argument passed) and directly reboots the system. Otherwise this simply
       invokes the shutdown(8) tool with the appropriate arguments without passing REBOOTCOMMAND argument.

       Before invoking reboot(2), a shutdown time record is first written to /var/log/wtmp
----

It says that it will simply invoke shutdown *without passing REBOOTCOMMAND*. If the command actually did that, then this bug wouldn't exist.

So, yes, it IS a bug.

You are right, the man page does say it is only used with --force. Interestingly, it seems the reboot command from the old sysvinit package completely ignored this argument, not using it even with --force, despite the man page saying so. Upstart's reboot command did the same thing in precise. It was patched to try and fix this and actually do as the man page says, but it looks like the patch was wrong, and causes a shutdown without the -r switch to reboot when REBOOTCOMMAND is given without --force. What is more weird, is that the kernel doesn't actually use this REBOOTCOMMAND anyhow; it seems to have absolutely no purpose.

This bug was fixed in the package upstart - 1.12.1-0ubuntu10

---------------
upstart (1.12.1-0ubuntu10) utopic; urgency=medium

  * Revert spurious +x -> -x change on daily upstart cron file.
  * Cherrypick reboot command fix to not process REBOOTCOMMAND argument
    when in runlevels 2-5 and without using force flag. (LP: #1174272)
 -- Dimitri John Ledkov <email address hidden> Fri, 20 Jun 2014 12:09:51 +0100

When this fixed in 14.04 Trusty Tahr for 14.04.1 (24 July)?

Many "critical" bugs on ReleaseNotes Trusty Tahr page don't fixed presently: https://wiki.ubuntu.com/TrustyTahr/ReleaseNotes#Known_issues
Installation bugs too:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1066480
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1172572
https://bugs.launchpad.net/ubuntu/+source/graphite2/+bug/1303516
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1297851
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1066342
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1172161
https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1297234

upgrade:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1308530
https://bugs.launchpad.net/ubuntu/+source/tex-common/+bug/1304972
https://bugs.launchpad.net/ubuntu/+source/flightgear/+bug/1308338

and other:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1054732
https://bugs.launchpad.net/unity/+bug/1305586
https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/1271591
https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1308037
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1305522
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1308761
https://bugs.launchpad.net/ubuntu/+source/unity-greeter/+bug/1292467

Too many errors in Trusty on: http://errors.ubuntu.com
Please fix the most annoying bugs. It interferes with work, use and distribution advice to friends.

Hello Dimitri, or anyone else affected,

Accepted upstart into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/upstart/1.12.1-0ubuntu4.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Dimitri, or anyone else affected,

Accepted upstart into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/upstart/1.12.1-0ubuntu4.2 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello everyone, I tested the proposed package using the test case provided
Ubuntu Trusty amd64
upstart (12.1.1-0ubuntu4.2)
machine rebooted OK, without dropping to runlevel 1

I haven't tested the package in any other ways, so i'm not sure about regression and 'll keep verification-needed tag

`$ sudo reboot please` now correctly reboots machine, instead of erroneously dropping to runlevel 1.

Thanks for implementing this fix. I have not had time to test it myself yet

I do notice however that verification-needed has been removed already, on the basis of 'reboot please' working. What about 'reboot now' -- does this also work as expected? Remember that this bug report was specifically opened/filed on the basis of 'reboot now'...

If 'reboot now' is working also, then we can surely consider this resolved.

reboot now works OK too

This bug was fixed in the package upstart - 1.12.1-0ubuntu4.2

---------------
upstart (1.12.1-0ubuntu4.2) trusty; urgency=medium

  * Safe guard against SESSIONTYPE-less sessions. (LP: #1343905)

upstart (1.12.1-0ubuntu4.1) trusty; urgency=medium

  [ James Hunt ] LP: #1317727
  * debian/manpages/upstart-events.7: Correction for 'rotate-logs'.
  * debian/upstart.cron.daily: Specify full path to initctl.
  * init/man/init.8: Add missing information on '--chroot-sessions'.
  * debian/upstart.apport: Sort system and session jobs.

  [ Iain Lane ]
  * xsession-init: Set $GNOME_DESKTOP_SESSION_ID if we are launching a
    gnome-session session. Some applications (Qt4) require this to be set to
    any value to detect the environment in use. It was historically set by
    gnome-session but now this is no longer the root of the session so not all
    user processes are guaranteed to have it. (LP: #1305294)

  [ Dimitri John Ledkov ]
  * Cherrypick reboot command fix to not process REBOOTCOMMAND argument
    when in runlevels 2-5 and without using force flag. (LP: #1174272)
 -- Dimitri John Ledkov <email address hidden> Fri, 18 Jul 2014 10:27:27 +0100

The verification of the Stable Release Update for upstart has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.