staging.inyokaproject.org

Arbeitsfläche automatisch sperren

Status: Ungelöst | Ubuntu-Version: Ubuntu 15.10 (Wily Werewolf)
Antworten |

uptime24

(Themenstarter)
Avatar von uptime24

Anmeldungsdatum:
25. Dezember 2014

Beiträge: 121

Ceglyx schrieb:

Mir wäre jetzt aber auch persönlich nicht bekannt, dass diese Funktion so unter Windows oder anderen Betriebsystemen umsetzbar wäre. 😐

Meinen Büro-Rechner (Windoof) kann ich mir einer batch Datei über einen geplanten Task im idle per

rundll32.exe user32.dll LockWorkStation

automatisch sperren lassen.

Unter Linux finde ich nur Tastenkombinationen oder Umwege über Bildschirmschoner.

Ceglyx

Anmeldungsdatum:
2. September 2015

Beiträge: 28

Cool, wusste gar nicht dass das ausgerechnet bei Windows machbar ist, danke für die Info 😀 Unsere Rechner sind da leider etwas zu stark eingeschränkt :/

Tut mir echt leid, dass ich dir jetzt keine bessere Antwort liefern kann. 😐

uptime24

(Themenstarter)
Avatar von uptime24

Anmeldungsdatum:
25. Dezember 2014

Beiträge: 121

Kein Problem, irgendjemand weiß dafür sicher eine Lösung. Ich muß ihn nur finden 😀

ChickenLipsRfun2eat Team-Icon

Anmeldungsdatum:
6. Dezember 2009

Beiträge: 12067

Interessanter thread. Hab mir bis eben auch noch keine Gedanken darum gemacht 😀

Also es gibt mehrere Wege zunächst die idle-time rauszufinden. Das einfachste für shell-scripts war seinerzeit xprintidle, welches es auch noch in den Repos gibt. Das macht nix anderes, als eine Ganzzahl mit der Zeit der Nichtbenutzung auszuspucken.

Dies in Verbindung mit dem "Benutzer wechseln" wäre als cronjob wahrscheinlich das, was du brauchst. Leider (nein, absichtlich) habe ich keine Ahnung von Unity und wäre daher auch auf die Hilfe anderer Nutzer hier angewiesen.

Simpler cronjob, der bspw. alle 3 Minuten die idle-time prüft und bei Wert > xyz den Befehl aufruft. Beispiel:

Achtung: Der qdbus command ist nur per Suchmaschine gefunden worden und bedarf der Prüfung!

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
#!/bin/bash

#Kann alles kürzer geschrieben werden, dient hier nur der Übersicht mit den Variablen
ABWESENHEIT=$(xprintidle) #idletime (Quelle X-Server) in Millisekunden
SPERRZEIT=180000 #3 Minuten in ms

if [ $ABWESENHEIT -gt $SPERRZEIT ]
then
  qdbus  com.canonical.Unity /com/canonical/Unity/Session com.canonical.Unity.Session.Lock
fi

uptime24

(Themenstarter)
Avatar von uptime24

Anmeldungsdatum:
25. Dezember 2014

Beiträge: 121

Das sieht doch schon mal nach was aus, wenn ich zuhause bin werde ich damit mal ein wenig herumexperimentieren!

Vielen Dank schon mal, das war ein großer Schritt in die (hoffentlich) richtige Richtung 👍

Vej Team-Icon

Moderator, Supporter
Avatar von Vej

Anmeldungsdatum:
7. März 2013

Beiträge: 3401

Hallo ChickenLipsRfun2eat.

ChickenLipsRfun2eat schrieb:

  qdbus  com.canonical.Unity /com/canonical/Unity/Session com.canonical.Unity.Session.Lock

Dieser Befehl funktioniert bei mir (im Terminal).

Viele Grüße

Vej

ChickenLipsRfun2eat Team-Icon

Anmeldungsdatum:
6. Dezember 2009

Beiträge: 12067

Danke fürs Testen, Vej!

uptime24, wenn dir das o.g. zu pauschal ist, gibt es auch noch die Möglichkeit die idle-time mit

w

Damit werden dann alle angemeldeten Konsolen angezeigt.

#beispiel
koffeinfriedhof@x220:~$ w
 17:07:36 up 10 min,  2 users,  load average: 0,22, 0,49, 0,44
USER     TTY      VON              ANMELD@   UNTÄ   JCPU   PCPU WAS
koffeinf pts/0    :0               16:57    9:37   0.00 s  2.49 s kded5 [kdeinit5]
koffeinf pts/1    :0               16:57    0.00 s  0.13 s  0.00 s w
koffeinfriedhof@x220:~$

#für awk gibts hier Helden. Ich bin keiner davon :)
koffeinfriedhof@x220:~$ w | awk '{ print $2 ":"  $5 }'
up:2
TTY:UNTÄ
pts/0:13:25 
pts/1:0.00
koffeinfriedhof@x220:~$

uptime24

(Themenstarter)
Avatar von uptime24

Anmeldungsdatum:
25. Dezember 2014

Beiträge: 121

Vielen Dank schon mal für Deine Unterstützung, ich denke wir kommen der Sache näher - aber es hackt noch ein wenig:

Ich lasse jetzt testweise minütlich einen Cron auf diese (ausführbare) lock.sh file los:

1
2
3
4
5
6
#!/bin/bash

if [[ xprintidle -gt 30000 ]]
then
  qdbus  com.canonical.Unity /com/canonical/Unity/Session com.canonical.Unity.Session.Lock
fi

Funktioniert leider nicht, als manueller Aufruf über die Konsole ./lock.sh gibt es aber keine Fehlermeldung.

Dein Session.Lock Befehl funktioniert soweit ja gut, hat aber den Effekt das die Bildschirme direkt nach dem Lock abgedunkelt und ausgeschaltet werden. Aktuell ist dieser workaround also vergleichbar mit dem abschalten des Bildschirms und sofortiger Sperrung, wie aus dem Helligkeit&Sperren Menü. 😢

ChickenLipsRfun2eat Team-Icon

Anmeldungsdatum:
6. Dezember 2009

Beiträge: 12067

#!/bin/bash

if [[ $(xprintidle) -gt 30000 ]]
then
  qdbus  com.canonical.Unity /com/canonical/Unity/Session com.canonical.Unity.Session.Lock
fi

Versuchs mal mit der Änderung. Und den richtigen Befehl für dein Vorhaben finden wir dann noch. Gibt ja ein "Benutzer wechseln", also ist das auch auslösbar.

uptime24

(Themenstarter)
Avatar von uptime24

Anmeldungsdatum:
25. Dezember 2014

Beiträge: 121

Leider auch nicht.

edit: Den Befehl zum sperren habe ich unterdessen gefunden:

dm-tool lock

Damit wird gesperrt ohne den Bildschirm auszuschalten.

Vej Team-Icon

Moderator, Supporter
Avatar von Vej

Anmeldungsdatum:
7. März 2013

Beiträge: 3401

Hallo.

Ich schlage vor, das Skript testweise so umzubauen, das es mit dem Benutzer ausgeführt wird, dessen Bildschirm gelockt werden soll (vgl. su).

Ich kann gerade nicht testen, aber ich würde behaupten, dass auch root keine anderen Benutzer sperren darf (bei manchen Screensavern darf root aus Sicherheitsgründen sogar gar keine Benutzer sperren. Auch nicht sich selbst).

Viele Grüße

Vej

ChickenLipsRfun2eat Team-Icon

Anmeldungsdatum:
6. Dezember 2009

Beiträge: 12067

Achso. Falls das Script als root ausgeführt werden soll, muss das natürlich anders aussehen.

Da wäre dann ein Auslesen des aktiven Benutzers nötig und mittels "su USER" der Befehl als dieser auszuführen. Ich dachte das der Benutzer das in seiner crontab verwendet. Das sollte ja funktionieren. Oder möchtest du das für alle User aktivieren, die sich an den PCs anmelden?

uptime24

(Themenstarter)
Avatar von uptime24

Anmeldungsdatum:
25. Dezember 2014

Beiträge: 121

Nein ich trage das in

crontab -e

ein.

Würde ich es als root ausführen wollen, müßte ich doch noch ein sudo davor setzen wenn ich das richtig im Kopf habe.

Aber mittlerweile bin ich mir bei gar nichts mehr sicher denn ich habe nun stundenlang alles mögliche probiert und kapituliere für heute. Es funktioniert einfach nicht als Cron.

Auch das

if [[ $(xprintidle) -gt 30000 ]]

bekomme ich nicht zum laufen, der Befehl dm-tool lock funktioniert über die Bash Datei nur, wenn ich die Zeit auf 0 stelle (was wenig Sinn macht).

ChickenLipsRfun2eat Team-Icon

Anmeldungsdatum:
6. Dezember 2009

Beiträge: 12067

1
2
3
4
5
6
7
#!/bin/bash
export DISPLAY=:0 #benötigt für xprintidle

if [[ $(/usr/bin/xprintidle) -gt 30000 ]]
then
  dm-tool lock
fi

So sollte es als cronjob klappen. Dem fehlt einfach die display-variable. Ich gucke aber eben nochmal online in der manpage vom dm-tool was es noch so gibt ☺

/edit: Vermutlich reicht dm-tool lock nicht. Ich müsste da mal etwas rumtesten auf dem andern Gerät auf dem lightdm läuft oder in ner vm. Das geht aber leider erst Morgen. Alternativ könntest du mal dm-tool switch-to-greeter probieren. Quelle der Information: http://manpages.ubuntu.com/manpages/wily/man1/dm-tool.1.html

uptime24

(Themenstarter)
Avatar von uptime24

Anmeldungsdatum:
25. Dezember 2014

Beiträge: 121

Also, wenn ich diese bash manuell direkt über die Konsole aufrufe (./lock.sh):

1
2
3
4
5
6
7
#!/bin/bash
export DISPLAY=:0 #benötigt für xprintidle

if [[ $(/usr/bin/xprintidle) -gt 0 ]]
then
  dm-tool lock
fi

dann werden die Bildschirme gesperrt (sofort*).

Lasse ich dieses script von dem cron aufrufen, passiert gar nichts. * * * * * /home/daric/lock.sh

Die lock.sh ist natürlich ausführbar und chmod 644

–-

* Ob eine größere idle time funktioniert, kann ich ja (nach meinem Verständnis) erst testen, wenn der cron das ganze aufruft. Aber prinzipiell funktioniert das Script ja. Beim Cron muß ich ja irgendwo einen fetten Fehler drin haben, den ich seit Stunden nicht sehe. Andere cronjobs laufen übrigens problemlos.