← Back to team overview

touch-packages team mailing list archive

[Bug 1429938] Re: reboot does not return under systemd

 

** Description changed:

- On Trusty and Utopic, when you run `apt-get remove openssh-server` over
- an SSH connection, your existing SSH connection remains open, so it's
- possible to run additional commands afterward.
+ If you send a shutdown or reboot command over SSH to a Trusty or Utopic
+ host, the command will consistently finish successfully prior to the SSH
+ connection being closed, meaning your SSH client will exit with a
+ return-code of zero:
  
- However, on Vivid now that the switch to systemd has been made,  `apt-
- get remove openssh-server` closes the existing SSH connection
- immediately, causing your SSH client to exit with a non-zero status. I
- have a hunch there's a lot of automation tooling out there that relies
- on the old behavior.
+ For example:
  
- For what it's worth, this change breaks the internal image mastering
- tools that System76 uses. Prior to exporting an image tarball, I spin up
- a golden VM with qemu, rysnc a script to it, and then execute this
- script over SSH.
+ $ ssh root@myhost shutdown -h now
+ $ echo $?
+ 0
  
- The important step is that I need to remove openssh-server prior to
- shutting down the VM, so these scripts always end with something like
- this:
+ Or
  
- apt-get -y purge openssh-server ssh-import-id
- apt-get -y autoremove
- shutdown -h now
+ $ ssh root@myhost reboot
+ $ echo $?
+ 0
  
- As far as I can tell, this behavior change will likewise be a problem
- when running `do-release-upgrade` on a remote server over SSH. Or more
- generally, anytime you run "apt-get upgrade/dist-upgrade" via SSH, it
- seems this would be a problem whenever the openssh-server package
- happens to be updated.
+ However, on Vivid now that the switch-over to systemd has happened,
+ running the same consistently results in the abrupt closure of the SSH
+ connection prior to the command finishing, meaning your SSH client will
+ exit with a return-code of 255:
+ 
+ $ ssh root@my_vivid_host shutdown -h now
+ Connection to localhost closed by remote host.
+ $ echo $?
+ 255
+ 
+ Although in retrospect is was a bit naive for me to rely on this
+ (actually quite fragile) behavior, it had at least been consistent in
+ Ubuntu for some time (back to at least Raring from my personal
+ experience, but likely back even farther).
+ 
+ This isn't technically a systemd bug, but I still think it's something
+ worth mentioning in the release notes as I bet I'm not the only person
+ who built some "clever" hacks around the previous behavior :P

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1429938

Title:
  reboot does not return under systemd

Status in systemd package in Ubuntu:
  Invalid

Bug description:
  If you send a shutdown or reboot command over SSH to a Trusty or
  Utopic host, the command will consistently finish successfully prior
  to the SSH connection being closed, meaning your SSH client will exit
  with a return-code of zero:

  For example:

  $ ssh root@myhost shutdown -h now
  $ echo $?
  0

  Or

  $ ssh root@myhost reboot
  $ echo $?
  0

  However, on Vivid now that the switch-over to systemd has happened,
  running the same consistently results in the abrupt closure of the SSH
  connection prior to the command finishing, meaning your SSH client
  will exit with a return-code of 255:

  $ ssh root@my_vivid_host shutdown -h now
  Connection to localhost closed by remote host.
  $ echo $?
  255

  Although in retrospect is was a bit naive for me to rely on this
  (actually quite fragile) behavior, it had at least been consistent in
  Ubuntu for some time (back to at least Raring from my personal
  experience, but likely back even farther).

  This isn't technically a systemd bug, but I still think it's something
  worth mentioning in the release notes as I bet I'm not the only person
  who built some "clever" hacks around the previous behavior :P

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1429938/+subscriptions


References