Uspavani uzivatelem z prikazove radky

Prosim nevi nekdo jakym kouzelnym slovem muze uzivatel uspat/hibernovat pocitac z prikazove radky v F29+?

Uprimne nechapu proc to nemuze zustat dve verze stejne, drive fungovalo:
dbus-send --system --print-reply --dest="org.freedesktop.login1" /org/freedesktop/login1 org.freedesktop.login1.Manager.Hibernate boolean:true
nyni vyskoci dialog zadajici heslo roota.
Jako admin jde samozrejme pouzit i systemctl hibernate, jako uzivatel opet pozaduje heslo roota.

A zde maly exkur do historie:
dbus-send --system --print-reply --dest=org.freedesktop.Hal /org/freedesktop/Hal/devices/computer org.freedesktop.Hal.Device.SystemPowerManagement.Hibernate
dbus-send --print-reply --system --dest=org.freedesktop.UPower /org/freedesktop/UPower org.freedesktop.UPower.Hibernate

Jen pro zabavu - notebook lenovo X220 v dokine pripojeny na AC a bez baterky se samozrejme po par minutach samovolne uspava. Zatim jedine reseni, ktere jsem nasel je
systemctl mask suspend.target
jenze pak uz zase nejde pustit systemctl suspend…
Tolik k tomu, ze se tato uzasna vlastnost ma aktivovat pouze pokud zarizeni neni na AC…

Je ten uživatelský účet s právy správce? Mně systemctl hibernate nebo suspend funguje bez hesla roota.

Co se týče toho samovolného uspávání, máš v nastavení napájení vypnuté automatické uspávání? By default je to vypnuté a s (ne)přítomností baterky by to nemělo mít nic společného.

Problem bude v tom ze nepouzivam Gnome… vim ze kdysi se musel jeste rucne poustet policy-kit, nebo kyho certa. Jinak jsem zkousel Gnome a koukal do nastaveni Power a neni tam vubec nic - akorat vypinani displeje po 1 hodine.

Ted jsem jeste v logu nasel tohle:
May 6 13:30:04 m systemd-logind[2189]: Suspending…
May 6 13:30:04 m systemd-logind[2189]: Unit suspend.target is masked, refusing operation.
May 6 13:30:04 m systemd-logind[2189]: Failed to execute operation: Permission denied
May 6 13:30:04 m systemd-logind[2189]: Suspending…
May 6 13:30:04 m rsyslogd: imjournal from <m:systemd-logind>: begin to drop messages due to rate-limiting
systemd-logind se zacykli pri pokusu o suspend na maskovanem targetu…

Tak pro autentizaci bude potreba
/usr/libexec/polkit-gnome-authentication-agent-1

zajimalo by me ale kde se nastavuje ten suspend, jeste jsem zkusil v dconfu nastavit
org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0
ale nema to na nic vliv.

Mělo by to být:

org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'
pro vypnutí automatického uspávání na AC.

org.gnome.settings-daemon.plugins.power sleep-inactive-battery-type 'nothing'
pro vypnutí automatického uspávání na baterce.

Jo to tam je a stejne se to suspenduje to musi prijit odnekud jinud. :frowning:

dbus vypisuje pri aktivace suspend timeoutu stale dokola:

method call time=1557210494.549127 sender=:1.13 -> destination=org.freedesktop.systemd1 serial=778549 path=/org/freedesktop/systemd1/unit/suspend_2etarget; interface=org.freedesktop.DBus.Properties; member=Get
   string "org.freedesktop.systemd1.Unit"
   string "LoadState"
method return time=1557210494.549800 sender=:1.3 -> destination=:1.13 serial=2338858 reply_serial=778549
   variant       string "masked"
signal time=1557210494.549831 sender=:1.3 -> destination=(null destination) serial=2338859 path=/org/freedesktop/systemd1; interface=org.freedesktop.systemd1.Manager; member=UnitNew
   string "suspend.target"
   object path "/org/freedesktop/systemd1/unit/suspend_2etarget"

ale moc moudrej z toho nejsem, to je zrejme jen nejake info ze unita je maskovana…

Jeste jsem nasel nastaveni v dconfu pro roota, kde byly zminene polozky na suspend, ale nemelo to zadny vliv, proste se to uspava. Zamaskovani suspend.target zpusobuje zaplavu logu a dbus vytizeni procesoru na 100% - takze jako fakt uspora energie. Jedine reseni ktere jsem zatim nasel je do
/etc/systemd/system/suspend.target vytvorit prazdnou unitu

[Unit]
Description=Suspend Target

to sice suspend taky vyvola, ale aspon to nedela porad dokola. Jen to network manager ma vypadek spojeni, protoze reinicializuje sitovky… proste supr systemd.

Jeste doplnim jednu perlicku - vypada to ze volani systemctl hibernate|suspend atd. neni blokujici. Tedy zavolani toho prikazu sice vyvola suspend ale vesele vrati rizeni a suspend probiha na pozadi.

       Hibernate the system. This will trigger activation of the special target unit
       hibernate.target. This command is asynchronous, and will return after the hibernation
       operation is successfully enqueued. It will not wait for the hibernate/thaw cycle to
       complete.

na rozdil od toho kdyz suspend provedete treba primym zapisem do sys kdy se rizeni vrati zpet az pri resume…