Activity log for bug #1174272

Date Who What changed Old value New value Message
2013-04-29 11:35:05 Dimitri Pappas bug added bug
2013-04-29 11:36:23 Dimitri Pappas description A forum thread has been opened first, describing the problem. For reference, that forum thread can be found here: http://ubuntuforums.org/showthread.php?t=2139160&p=12624806#post12624806 Quote: When the command "reboot now" is issued: root@server:~# reboot now Broadcast message from root@server (/dev/pts/0) at 00:00 ... The system is going down to maintenance mode NOW! A few moments later.. SSHd is killed, but the box responds to pings (Inaccessible remotely unless a hard-reset is performed) * Asking all remaining processes to terminate... * Killing all remaining processes... [fail] * Will now switch to single-user mode Give root password for maintenance (or type Control-D to continue): Just "reboot", and it works fine root@server:~# reboot Broadcast message from root@server (/dev/pts/0) at 00:00 ... The system is going down for reboot NOW! Some distro's require a time / 'now' as an argument, and thus I became accustomed to performing my reboots in this way. Now it seems to be a potential trap that causes the machine not to reboot, which is especially painful if we're talking about a headless/hosted dedicated server. Even if ubuntu doesn't like 'reboot now' syntax, I still can't understand why "reboot now" should bring the box to console maintenance mode anyway - perhaps it should rather return an error, or syntax help ProblemType: Bug DistroRelease: Ubuntu 13.04 Package: upstart 1.8-0ubuntu1 Uname: Linux 3.9.0-030900rc8-generic i686 ApportVersion: 2.9.2-0ubuntu8 Architecture: i386 Date: Mon Apr 29 13:22:02 2013 InstallationDate: Installed on 2010-12-11 (870 days ago) InstallationMedia: Ubuntu-Server 10.10 "Maverick Meerkat" - Release i386 (20101007) MarkForUpload: True ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=en_ZA.UTF-8 SHELL=/bin/bash ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-3.9.0-030900rc8-generic root=UUID=cde38363-cc5e-4b66-ba3d-f64dd0ed4987 ro quiet SourcePackage: upstart UpgradeStatus: Upgraded to raring on 2013-04-26 (3 days ago) UpstartBugCategory: System A forum thread has been opened first, describing the problem. For reference, that forum thread can be found here: http://ubuntuforums.org/showthread.php?t=2139160&p=12624806 Problem is described below: When the command "reboot now" is issued: root@server:~# reboot now Broadcast message from root@server (/dev/pts/0) at 00:00 ... The system is going down to maintenance mode NOW! A few moments later.. SSHd is killed, but the box responds to pings (Inaccessible remotely unless a hard-reset is performed) * Asking all remaining processes to terminate... * Killing all remaining processes... [fail] * Will now switch to single-user mode Give root password for maintenance (or type Control-D to continue): Just "reboot", and it works fine root@server:~# reboot Broadcast message from root@server (/dev/pts/0) at 00:00 ... The system is going down for reboot NOW! Some distro's require a time / 'now' as an argument, and thus I became accustomed to performing my reboots in this way. Now it seems to be a potential trap that causes the machine not to reboot, which is especially painful if we're talking about a headless/hosted dedicated server. Even if ubuntu doesn't like 'reboot now' syntax, I still can't understand why "reboot now" should bring the box to console maintenance mode anyway - perhaps it should rather return an error, or syntax help ProblemType: Bug DistroRelease: Ubuntu 13.04 Package: upstart 1.8-0ubuntu1 Uname: Linux 3.9.0-030900rc8-generic i686 ApportVersion: 2.9.2-0ubuntu8 Architecture: i386 Date: Mon Apr 29 13:22:02 2013 InstallationDate: Installed on 2010-12-11 (870 days ago) InstallationMedia: Ubuntu-Server 10.10 "Maverick Meerkat" - Release i386 (20101007) MarkForUpload: True ProcEnviron:  TERM=xterm  PATH=(custom, no user)  LANG=en_ZA.UTF-8  SHELL=/bin/bash ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-3.9.0-030900rc8-generic root=UUID=cde38363-cc5e-4b66-ba3d-f64dd0ed4987 ro quiet SourcePackage: upstart UpgradeStatus: Upgraded to raring on 2013-04-26 (3 days ago) UpstartBugCategory: System
2013-05-02 19:11:29 Phillip Susi bug added subscriber Phillip Susi
2013-05-03 09:39:00 Launchpad Janitor upstart (Ubuntu): status New Confirmed
2013-05-03 10:23:25 Richard Willis-Owen attachment added screenshot of reboot command and reboot now command https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1174272/+attachment/3663596/+files/screenshot.png
2013-05-07 08:50:37 James Hunt upstart (Ubuntu): status Confirmed Invalid
2013-05-30 17:16:19 Peter L bug added subscriber Peter Lehoczký
2013-09-02 18:37:26 Alexey upstart (Ubuntu): status Invalid Fix Released
2013-11-08 15:09:33 Ben Gamari bug added subscriber Ben Gamari
2014-04-08 18:55:19 Peter Matulis attachment added reboot_now_hang.png https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1174272/+attachment/4075567/+files/reboot_now_hang.png
2014-04-08 18:55:44 Peter Matulis nominated for series Ubuntu Trusty
2014-04-08 18:56:38 Peter Matulis bug added subscriber Peter Matulis
2014-05-09 14:01:36 Phillip Susi upstart (Ubuntu): status Fix Released In Progress
2014-05-09 14:01:36 Phillip Susi upstart (Ubuntu): assignee Phillip Susi (psusi)
2014-05-09 14:18:29 Phillip Susi branch linked lp:~psusi/ubuntu/utopic/upstart/fix-reboot
2014-05-09 15:24:07 Launchpad Janitor branch linked lp:~xnox/upstart/reboot-fix
2014-05-09 15:24:33 Dimitri John Ledkov upstart (Ubuntu): importance Undecided Critical
2014-05-09 15:24:36 Dimitri John Ledkov upstart (Ubuntu): assignee Phillip Susi (psusi) Dimitri John Ledkov (xnox)
2014-05-09 15:24:44 Dimitri John Ledkov bug task added upstart (Ubuntu Trusty)
2014-05-09 15:24:51 Dimitri John Ledkov upstart (Ubuntu Trusty): status New In Progress
2014-05-09 15:24:53 Dimitri John Ledkov upstart (Ubuntu Trusty): importance Undecided Critical
2014-05-09 15:24:54 Dimitri John Ledkov upstart (Ubuntu Trusty): assignee Dimitri John Ledkov (xnox)
2014-05-09 15:30:49 Dimitri John Ledkov description A forum thread has been opened first, describing the problem. For reference, that forum thread can be found here: http://ubuntuforums.org/showthread.php?t=2139160&p=12624806 Problem is described below: When the command "reboot now" is issued: root@server:~# reboot now Broadcast message from root@server (/dev/pts/0) at 00:00 ... The system is going down to maintenance mode NOW! A few moments later.. SSHd is killed, but the box responds to pings (Inaccessible remotely unless a hard-reset is performed) * Asking all remaining processes to terminate... * Killing all remaining processes... [fail] * Will now switch to single-user mode Give root password for maintenance (or type Control-D to continue): Just "reboot", and it works fine root@server:~# reboot Broadcast message from root@server (/dev/pts/0) at 00:00 ... The system is going down for reboot NOW! Some distro's require a time / 'now' as an argument, and thus I became accustomed to performing my reboots in this way. Now it seems to be a potential trap that causes the machine not to reboot, which is especially painful if we're talking about a headless/hosted dedicated server. Even if ubuntu doesn't like 'reboot now' syntax, I still can't understand why "reboot now" should bring the box to console maintenance mode anyway - perhaps it should rather return an error, or syntax help ProblemType: Bug DistroRelease: Ubuntu 13.04 Package: upstart 1.8-0ubuntu1 Uname: Linux 3.9.0-030900rc8-generic i686 ApportVersion: 2.9.2-0ubuntu8 Architecture: i386 Date: Mon Apr 29 13:22:02 2013 InstallationDate: Installed on 2010-12-11 (870 days ago) InstallationMedia: Ubuntu-Server 10.10 "Maverick Meerkat" - Release i386 (20101007) MarkForUpload: True ProcEnviron:  TERM=xterm  PATH=(custom, no user)  LANG=en_ZA.UTF-8  SHELL=/bin/bash ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-3.9.0-030900rc8-generic root=UUID=cde38363-cc5e-4b66-ba3d-f64dd0ed4987 ro quiet SourcePackage: upstart UpgradeStatus: Upgraded to raring on 2013-04-26 (3 days ago) UpstartBugCategory: System [Impact] * reboot(8) command was behaviour different from the documented one, in particular when passing optional REBOOTCOMMAND argument, whilst not in runlevel 0 or 6 and without passing --force, shutdown(8) was not invoked with the appropriate arguments. Actual behaviour was dropping to runlevel 1, instead of the expected reboot. [Test Case] * Whilst booted normally to runlevel 2 after executing: $ sudo reboot please * machine should complete reboot.
2014-05-09 15:30:58 Dimitri John Ledkov description [Impact] * reboot(8) command was behaviour different from the documented one, in particular when passing optional REBOOTCOMMAND argument, whilst not in runlevel 0 or 6 and without passing --force, shutdown(8) was not invoked with the appropriate arguments. Actual behaviour was dropping to runlevel 1, instead of the expected reboot. [Test Case] * Whilst booted normally to runlevel 2 after executing: $ sudo reboot please * machine should complete reboot. [Impact]  * reboot(8) command has behaviour different from the documented one, in particular when passing optional REBOOTCOMMAND argument, whilst not in runlevel 0 or 6 and without passing --force, shutdown(8) was not invoked with the appropriate arguments. Actual behaviour was dropping to runlevel 1, instead of the expected reboot. [Test Case]  * Whilst booted normally to runlevel 2 after executing:    $ sudo reboot please  * machine should complete reboot.
2014-05-09 15:35:16 Dimitri John Ledkov summary 'reboot now' reverting to maintenance mode 'reboot now' reverting to maintenance mode, instead of rebooting
2014-05-09 15:42:36 Dimitri John Ledkov bug task added upstart
2014-05-09 15:42:44 Dimitri John Ledkov upstart: status New In Progress
2014-05-09 15:42:46 Dimitri John Ledkov upstart: assignee Dimitri John Ledkov (xnox)
2014-05-09 15:42:47 Dimitri John Ledkov upstart: importance Undecided High
2014-05-09 15:44:35 Dimitri John Ledkov description [Impact]  * reboot(8) command has behaviour different from the documented one, in particular when passing optional REBOOTCOMMAND argument, whilst not in runlevel 0 or 6 and without passing --force, shutdown(8) was not invoked with the appropriate arguments. Actual behaviour was dropping to runlevel 1, instead of the expected reboot. [Test Case]  * Whilst booted normally to runlevel 2 after executing:    $ sudo reboot please  * machine should complete reboot. [Impact]  * reboot(8) command has behaviour different from the documented one, in particular when passing optional REBOOTCOMMAND argument, whilst not in runlevel 0 or 6 and without passing --force, shutdown(8) was not invoked with the appropriate arguments. Actual behaviour was dropping to runlevel 1, instead of the expected reboot. [Test Case]  * Whilst booted normally to runlevel 2, after executing:    $ sudo reboot please  * machine should complete reboot.
2014-06-20 12:40:44 Launchpad Janitor upstart (Ubuntu): status In Progress Fix Released
2014-06-20 13:10:15 Launchpad Janitor branch linked lp:ubuntu/upstart
2014-07-09 10:23:32 Launchpad Janitor branch linked lp:ubuntu/trusty/upstart
2014-07-09 12:09:40 Peter L removed subscriber Peter Lehoczký
2014-07-18 00:02:39 Colin Watson upstart (Ubuntu Trusty): status In Progress Fix Committed
2014-07-18 00:02:42 Colin Watson bug added subscriber Ubuntu Stable Release Updates Team
2014-07-18 00:02:44 Colin Watson bug added subscriber SRU Verification
2014-07-18 00:02:52 Colin Watson tags apport-bug i386 raring apport-bug i386 raring verification-needed
2014-07-18 13:29:14 Dimitri John Ledkov tags apport-bug i386 raring verification-needed apport-bug i386 raring verification-done
2014-07-21 02:32:57 Dimitri John Ledkov upstart: status In Progress Fix Released
2014-07-22 15:12:12 Launchpad Janitor upstart (Ubuntu Trusty): status Fix Committed Fix Released
2014-07-22 15:12:32 Adam Conrad removed subscriber Ubuntu Stable Release Updates Team
2014-09-04 00:34:17 M. Nease bug added subscriber M. Nease
2015-07-10 00:57:34 Bady upstart: assignee Dimitri John Ledkov (xnox)
2016-12-17 10:58:23 Simone bug added subscriber Simone