** Summary changed:

- non-X VTs should use energy star
+ regression:  non-X VTs stopped using energy star after xenial

** Description changed:

- it's simple.  it's easy.  let's get our servers being good energy star
- citizens shall we?
+ as of xenial, non-X VTs timed out and powered down even if nobody ever
+ logged in.  but that's no longer true in bionic and focal.
  
  if a VT is running X at all, whether that's running sddm and never
  logged in, or sddm and logged-in, or not running sddm and simply logged-
  in and running X started with startx, that VT will timeout and
- powerdown.  so far so good.
+ powerdown, even on bionic and focal.  no problem there.
  
  but a VT that's either running getty, or logged in and just running
- bash, will stay powered up and blazing away forever, whether it's ubuntu
- server 20.04, lubuntu 20.04, or centos 8.
+ bash, will stay powered up and blazing away forever, if it's ubuntu
+ 18.04 or 20.04, server or lubuntu.  or centos 8.
  
  so probably RHEL 8 too, so probably most servers, aren't being good
- energy star citizens!  boo!
+ energy star citizens anymore.  something happened since xenial.
  
  the util-linux package is used by both centos 8 and ubuntu 20.04, and
  contains both getty and setterm.
  
- thus getty seems to me to be the sensible place to call:
+ probably getty would be the place, that either used to call, or should
+ now call:
  
  setterm -term=linux -powersave=powerdown -powerdown=15
  -store>/dev/tty0</dev/tty0
  
- such that a VT running getty, or logged in and running bash, would then
- timeout and powerdown.
+ after giving that command, a VT running getty, or logged in and running
+ bash, will then timeout and powerdown.  i wonder why it's not happening
+ anymore?
  
  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: systemd 245.4-4ubuntu3.4
  ProcVersionSignature: Ubuntu 5.4.0-62.70-generic 5.4.78
  Uname: Linux 5.4.0-62-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.14
  Architecture: amd64
  CasperMD5CheckResult: pass
  Date: Tue Jan 19 05:13:35 2021
  InstallationDate: Installed on 2020-12-28 (21 days ago)
  InstallationMedia: Ubuntu-Server 20.04.1 LTS "Focal Fossa" - Release amd64 
(20200731)
  MachineType: Hewlett-Packard HP EliteDesk 800 G1 SFF
  ProcEnviron:
   TERM=screen
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/fs/boot/vmlinuz ro 
root=UUID=a671d866-a05f-4b83-8714-0b448b1eeac4 subroot=/fs 
init=/fs/etc/g/subroot
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 07/15/2014
  dmi.bios.vendor: Hewlett-Packard
  dmi.bios.version: L01 v02.33
  dmi.board.name: 1998
  dmi.board.vendor: Hewlett-Packard
  dmi.chassis.type: 4
  dmi.chassis.vendor: Hewlett-Packard
  dmi.modalias: 
dmi:bvnHewlett-Packard:bvrL01v02.33:bd07/15/2014:svnHewlett-Packard:pnHPEliteDesk800G1SFF:pvr:rvnHewlett-Packard:rn1998:rvr:cvnHewlett-Packard:ct4:cvr:
  dmi.product.family: 103C_53307F G=D
  dmi.product.name: HP EliteDesk 800 G1 SFF
  dmi.product.sku: J6D79UT#ABA
  dmi.sys.vendor: Hewlett-Packard

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

Title:
  regression:  non-X VTs stopped using energy star after xenial

Status in util-linux package in Ubuntu:
  New

Bug description:
  as of xenial, non-X VTs timed out and powered down even if nobody ever
  logged in.  but that's no longer true in bionic and focal.

  if a VT is running X at all, whether that's running sddm and never
  logged in, or sddm and logged-in, or not running sddm and simply
  logged-in and running X started with startx, that VT will timeout and
  powerdown, even on bionic and focal.  no problem there.

  but a VT that's either running getty, or logged in and just running
  bash, will stay powered up and blazing away forever, if it's ubuntu
  18.04 or 20.04, server or lubuntu.  or centos 8.

  so probably RHEL 8 too, so probably most servers, aren't being good
  energy star citizens anymore.  something happened since xenial.

  the util-linux package is used by both centos 8 and ubuntu 20.04, and
  contains both getty and setterm.

  probably getty would be the place, that either used to call, or should
  now call:

  setterm -term=linux -powersave=powerdown -powerdown=15
  -store>/dev/tty0</dev/tty0

  after giving that command, a VT running getty, or logged in and
  running bash, will then timeout and powerdown.  i wonder why it's not
  happening anymore?

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: systemd 245.4-4ubuntu3.4
  ProcVersionSignature: Ubuntu 5.4.0-62.70-generic 5.4.78
  Uname: Linux 5.4.0-62-generic x86_64
  ApportVersion: 2.20.11-0ubuntu27.14
  Architecture: amd64
  CasperMD5CheckResult: pass
  Date: Tue Jan 19 05:13:35 2021
  InstallationDate: Installed on 2020-12-28 (21 days ago)
  InstallationMedia: Ubuntu-Server 20.04.1 LTS "Focal Fossa" - Release amd64 
(20200731)
  MachineType: Hewlett-Packard HP EliteDesk 800 G1 SFF
  ProcEnviron:
   TERM=screen
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/fs/boot/vmlinuz ro 
root=UUID=a671d866-a05f-4b83-8714-0b448b1eeac4 subroot=/fs 
init=/fs/etc/g/subroot
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 07/15/2014
  dmi.bios.vendor: Hewlett-Packard
  dmi.bios.version: L01 v02.33
  dmi.board.name: 1998
  dmi.board.vendor: Hewlett-Packard
  dmi.chassis.type: 4
  dmi.chassis.vendor: Hewlett-Packard
  dmi.modalias: 
dmi:bvnHewlett-Packard:bvrL01v02.33:bd07/15/2014:svnHewlett-Packard:pnHPEliteDesk800G1SFF:pvr:rvnHewlett-Packard:rn1998:rvr:cvnHewlett-Packard:ct4:cvr:
  dmi.product.family: 103C_53307F G=D
  dmi.product.name: HP EliteDesk 800 G1 SFF
  dmi.product.sku: J6D79UT#ABA
  dmi.sys.vendor: Hewlett-Packard

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1912330/+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

Reply via email to