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

2015-03-25 Thread god
I think mentioning this bug in release notes would only confuse users:
the bug here is in the person who relied on undocumented racy behavior -
this have nothing to do with systemd or ubuntu or sshd.

-- 
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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


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

2015-03-25 Thread Jason Gerard DeRose
Except that previously this wasn't racy behavior in practice.

I have automation tooling that has executed tens of thousands of reboot
and shutdown commands over SSH in this way with perfect consistency over
the last two years. The moment the switchover to systemd happened in
Vivid, this tooling broken.

I get that my assumptions weren't robust and that I have to change my
tools to accommodate systemd (which  I already did). But communicating
this change is courteous and helpful, very Ubuntu if you will.

And this isn't something that needs to be prominent. It just effects
people working with servers, VMs, etc, not everyday desktop users.

-- 
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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


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

2015-03-25 Thread Egmont Koblinger
IMHO this particular issue is way too specific, and is likely to affect
very few people only. And Google very easily finds this page.

What might be worth documenting is a few generic words about reboot
and some other similar commands slightly changing behavior due to
systemd. E.g. reboot just sends a command to systemd and immediately
returns -- this gives a great clue to what's wrong in your use case, yet
is way more generic and probably useful for more people. Or mention that
locally logged in users can now execute reboot without sudo (I don't
think it was like this previously). Or just simply something along the
lines of due to systemd, some system tools such as reboot now might
behave slightly differently...

-- 
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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


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

2015-03-18 Thread Rolf Leggewie
** Tags added: regression-release

-- 
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:
  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.

  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 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.

  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:

  apt-get -y purge openssh-server ssh-import-id
  apt-get -y autoremove
  shutdown -h now

  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.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


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

2015-03-18 Thread Jason Gerard DeRose
** 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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


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

2015-03-18 Thread Jason Gerard DeRose
I reworked the description as my original assessment was quite off.

But after more thought, I think this behavior change is something that
really needs mentioning in the Vivid releases notes.

After all, the perceived correct behavior of a system strongly tends
toward what the actual behavior has been historically.

Yet one of these kids is clearly not like the other :D

-- 
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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


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

2015-03-17 Thread Egmont Koblinger
  perhaps (sleep 3; poweroff ) ?

I recently did something similar, and noticed that the ssh channel
doesn't close as long as the background process's file descriptors use
the ssh channel.  So you'll probably have more luck with:

(sleep 3; poweroff) /dev/null /dev/null 

-- 
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:
  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.

  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 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.

  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:

  apt-get -y purge openssh-server ssh-import-id
  apt-get -y autoremove
  shutdown -h now

  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.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


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

2015-03-11 Thread Martin Pitt
Ah right, that makes more sense. By definition, shutdown -h now or
poweroff etc. are racy -- sometimes it survives and comes back,
sometimes the shutdown of the machine is too fast. It seems that with
systemd it's just a bit faster. I suggest calling shutdown -h +1, or
if you don't want to wait for a minute, perhaps (sleep 3; poweroff )
?

** Summary changed:

- stopping ssh.service closes existing ssh connections
+ reboot does not return under systemd

** Package changed: openssh (Ubuntu) = systemd (Ubuntu)

** Changed in: systemd (Ubuntu)
   Status: Incomplete = Invalid

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

Title:
  reboot does not return under systemd

Status in systemd package in Ubuntu:
  Invalid

Bug description:
  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.

  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 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.

  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:

  apt-get -y purge openssh-server ssh-import-id
  apt-get -y autoremove
  shutdown -h now

  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.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


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

2015-03-11 Thread Jason Gerard DeRose
Martin,

Okay, much thanks!

-- 
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:
  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.

  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 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.

  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:

  apt-get -y purge openssh-server ssh-import-id
  apt-get -y autoremove
  shutdown -h now

  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.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp