Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #121216 > unrolled thread

Screensaver auf Console aktiviert

Back to article view | Back to de.comp.os.unix.linux.misc

Contents

  Screensaver auf Console aktiviert Peter Schütt <newsgroup@pstt.de> - 2022-02-10 08:41 +0100
    Re: Screensaver auf Console aktiviert Peter Blancke <blancke@gmx.de> - 2022-02-10 12:31 +0000
      Re: Screensaver auf Console aktiviert Gerald E¡scher <Spamer@fahr-zur-Hoelle.org> - 2022-02-10 16:07 +0000
        Re: Screensaver auf Console aktiviert Tim Ritberg <tim@server.invalid> - 2022-02-10 19:28 +0100
          Re: Screensaver auf Console aktiviert Michael Brand <brandm@gmx.net> - 2022-02-10 19:35 +0100
          Re: Screensaver auf Console aktiviert Kay Martinen <usenet@martinen.de> - 2022-02-22 23:58 +0100
            Re: Screensaver auf Console aktiviert Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-02-23 08:12 +0000
              Re: Screensaver auf Console aktiviert Kay Martinen <usenet@martinen.de> - 2022-02-23 14:28 +0100
                Re: Screensaver auf Console aktiviert Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2022-02-23 19:10 +0000
                  Re: Screensaver auf Console aktiviert Marc Haber <mh+usenetspam1118@zugschl.us> - 2022-02-25 10:33 +0100
                Re: Screensaver auf Console aktiviert Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-02-23 21:05 +0100
                  Re: Screensaver auf Console aktiviert Thomas Dorner <de.comp.os.unix.linux.misc.220224.dorner@spamgourmet.com> - 2022-02-24 19:10 +0100
                    Re: Screensaver auf Console aktiviert Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-02-24 21:10 +0100
                      Re: Screensaver auf Console aktiviert Claus Reibenstein <creibens@gmail.com> - 2022-02-25 11:15 +0100
                        Re: Screensaver auf Console aktiviert Thomas Dorner <de.comp.os.unix.linux.misc.220225.dorner@spamgourmet.com> - 2022-02-25 20:23 +0100
                      Re: Screensaver auf Console aktiviert Claus Reibenstein <creibens@gmail.com> - 2022-02-25 11:17 +0100
                        Re: Screensaver auf Console aktiviert Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-02-26 20:38 +0100
                          Re: Screensaver auf Console aktiviert Claus Reibenstein <creibens@gmail.com> - 2022-02-26 21:38 +0100
                      Re: Screensaver auf Console aktiviert Thomas Dorner <de.comp.os.unix.linux.misc.220225.dorner@spamgourmet.com> - 2022-02-25 20:27 +0100
                        Re: Screensaver auf Console aktiviert Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-02-26 20:16 +0100
                Re: Screensaver auf Console aktiviert Christian Garbs <mitch@cgarbs.de> - 2022-02-27 16:45 +0000

Page 1 of 2  [1] 2  Next page →

#121216 — Screensaver auf Console aktiviert

Hallo,
ich habe meinen Server (Debian stable) parallel mit meinem 
Arbeitsrechner an den selben Monitor angeschlossen (DVI und VGA), um 
notfalls auch direkt auf den Server zu kommen.
Seit Debian 9 (oder so) ist der screensaver auf der Konsole abgeschaltet.
Das heißt, wenn man Arbeitsrechner in den Schlafmodus geht, wechselt der 
Monitor zur Server-Konsole und wenn ich dann die Maus von meinem 
Arbeitsrechner bewege, muss ich erst am Monitor wieder umschalten.

Ich habe mir schon ein kleines Script gebastelt:
enable_screensaver.sh:

setterm -blank 10

das ich dann einmal im Root-Terminal ausführe, wenn der Server 
neugestartet ist. Dann ist das behoben.

Wie kann ich das reboot-fest einstellen?

Danke für alle Hinweise und Tips.
Ciao
   Peter Schütt

[toc] | [next] | [standalone]

#121223

Am 2022-02-10, Peter Schütt <newsgroup@pstt.de> schrieb:

> setterm -blank 10
>
> Wie kann ich das reboot-fest einstellen?

Möglicherweise in /etc/rc.local.

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

Gruß,

Peter Blancke

-- 
Hoc est enim verbum meum!

[toc] | [prev] | [next] | [standalone]

#121225

Peter Blancke schrieb am 10/2/2022 13:31:

> Am 2022-02-10, Peter Schütt <newsgroup@pstt.de> schrieb:
>
>> setterm -blank 10
>>
>> Wie kann ich das reboot-fest einstellen?
>
> Möglicherweise in /etc/rc.local.

Kann man machen, rc.local ist allerdings seit Jahrzehnten deprecated.
Besser für den systemd eine Service-Datei schreiben.

-- 
Gerald

[toc] | [prev] | [next] | [standalone]

#121231

Am 10.02.22 um 17:07 schrieb Gerald E¡scher:
>>
>> Möglicherweise in /etc/rc.local.
> 
> Kann man machen, rc.local ist allerdings seit Jahrzehnten deprecated.
> Besser für den systemd eine Service-Datei schreiben.
Nicht jedes Linux hat ein systemd...

Tim

[toc] | [prev] | [next] | [standalone]

#121232

Tim Ritberg wrote:
> Am 10.02.22 um 17:07 schrieb Gerald E¡scher:
>>>
>>> Möglicherweise in /etc/rc.local.
>>
>> Kann man machen, rc.local ist allerdings seit Jahrzehnten deprecated.
>> Besser für den systemd eine Service-Datei schreiben.
> Nicht jedes Linux hat ein systemd...

Ketzer! Ungläubiger! Nur systemd ist der wahre Heilsbringer!
;-)
Deswegen bin ich mit meinem Devuan auch auf ewig verdammt...mich damit
nicht befassen zu müssen :-)

> Tim

Michael

[toc] | [prev] | [next] | [standalone]

#121445

Am 10.02.22 um 19:28 schrieb Tim Ritberg:
> Am 10.02.22 um 17:07 schrieb Gerald E¡scher:
>>>
>>> Möglicherweise in /etc/rc.local.
>>
>> Kann man machen, rc.local ist allerdings seit Jahrzehnten deprecated.

Tot gesagte leben halt länger. :) Zeig mir ein 'ls -al' deiner 'local'

$Hier hab ich sie auch nicht mehr. Aber auf dem Server

# ls -al /etc/init.d/local
-rwxr-xr-x 1 root root 1061 Jan  7  2020 /etc/init.d/local

Und dann gibt es ja noch 'console-setup.sh'

Da könnte es zumindest thematisch passen.

>> Besser für den systemd eine Service-Datei schreiben.
> Nicht jedes Linux hat ein systemd...

"Yogiii, dem Ranger wird das aber nicht gefallen" :-)

Ich frag mich jetzt aber, service-datei für WAS. einen rc.local oder ein
schnödes 'setterm'

Irgendwie krank für einen einzelnen scriptbefehl eine extra datei zu
schreiben die dem init-surrogat angibt wann, wo und wie das aus zu
führen ist.

Ｂｙｅ／
   ／Ｋａｙ

-- 
"Kann ein Wurstbrot die Welt retten?" :-)

[toc] | [prev] | [next] | [standalone]

#121447

Kay Martinen <usenet@martinen.de> wrote:

> Irgendwie krank für einen einzelnen scriptbefehl eine extra datei zu
> schreiben die dem init-surrogat angibt wann, wo und wie das aus zu
> führen ist.

Deshalb haben alle meine Linuxe ein /etc/rc.local
Funktioniert bei allen mir bekannten Distributionen.

Auf User-Basis geht das auch via crontab @reboot

-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#121449

Am 23.02.22 um 09:12 schrieb Ulli Horlacher:
> Kay Martinen <usenet@martinen.de> wrote:
> 
>> Irgendwie krank für einen einzelnen scriptbefehl eine extra datei zu
>> schreiben die dem init-surrogat angibt wann, wo und wie das aus zu
>> führen ist.
> 
> Deshalb haben alle meine Linuxe ein /etc/rc.local
> Funktioniert bei allen mir bekannten Distributionen.

Vermutlich durch den sysv-generator (o.w.a.i.) der das nach systemd
übersetzt. Auf meinem Server (Eisfair) liegt die aber nicht in /etc
sondern wie vor genannt.

> Auf User-Basis geht das auch via crontab @reboot

Ach guck, den hatte ich übersehen und @reboot auch eher als root-only
gesehen.

Ist ja fast "wie bei windows"... 1000 Wege für autostarts. ;-)

Für die GUI ist @reboot aber wohl eher nichts und da scheinen KDE u.a.
auch eher ein eigenes süppchen zu kochen. Oder kennst du ein well known
script-eckchen a la rc.[nn|local] das erst nach login oder nach
X-Session start angesteuert wird - von allen Desktops, window- und
login-managern?

Ｂｙｅ／
   ／Ｋａｙ

-- 
"Kann ein Wurstbrot die Welt retten?" :-)

[toc] | [prev] | [next] | [standalone]

#121454

Kay Martinen <usenet@martinen.de> wrote:

> > Deshalb haben alle meine Linuxe ein /etc/rc.local
> > Funktioniert bei allen mir bekannten Distributionen.
> 
> Vermutlich durch den sysv-generator (o.w.a.i.) der das nach systemd
> übersetzt. 

Habe ich nie explizit aufgerufen oder gar installiert.
Es tut einfach (so) :-)


> > Auf User-Basis geht das auch via crontab @reboot
> 
> Für die GUI ist @reboot aber wohl eher nichts 

Crontab ist es voellig egal, ob da eine GUI laeuft oder nicht :-)


> Oder kennst du ein well known script-eckchen a la rc.[nn|local] das erst
> nach login oder nach X-Session start angesteuert wird - von allen
> Desktops, window- und login-managern?

Ich verwende nur XFCE und ignoriere den Rest :-)


-- 
Ullrich Horlacher              Server und Virtualisierung
Rechenzentrum TIK         
Universitaet Stuttgart         E-Mail: horlacher@tik.uni-stuttgart.de
Allmandring 30a                Tel:    ++49-711-68565868
70569 Stuttgart (Germany)      WWW:    http://www.tik.uni-stuttgart.de/

[toc] | [prev] | [next] | [standalone]

#121471

Ulli Horlacher <framstag@rus.uni-stuttgart.de> wrote:
>Kay Martinen <usenet@martinen.de> wrote:
>
>> > Deshalb haben alle meine Linuxe ein /etc/rc.local
>> > Funktioniert bei allen mir bekannten Distributionen.
>> 
>> Vermutlich durch den sysv-generator (o.w.a.i.) der das nach systemd
>> übersetzt. 
>
>Habe ich nie explizit aufgerufen oder gar installiert.

Musst Du auch nicht, wird automatisch on the fly beim Systemstart
generiert.

|[1/5191]mh@drop:~ $ sudo systemctl cat exim4
|[sudo] password for mh: 
|# /run/systemd/generator.late/exim4.service
|# Automatically generated by systemd-sysv-generator
|
|[Unit]
|Documentation=man:systemd-sysv-generator(8)
|SourcePath=/etc/init.d/exim4
|Description=LSB: exim Mail Transport Agent
|Before=multi-user.target
|Before=multi-user.target
|Before=multi-user.target
|Before=graphical.target
|After=remote-fs.target
|After=nss-lookup.target
|After=network-online.target
|After=time-sync.target
|After=postgresql.service
|After=mysql.service
|After=clamav-daemon.service
|After=greylist.service
|After=spamassassin.service
|Wants=network-online.target
|
|[Service]
|Type=forking
|Restart=no
|TimeoutSec=5min
|IgnoreSIGPIPE=no
|KillMode=process
|GuessMainPID=no
|RemainAfterExit=yes
|SuccessExitStatus=5 6
|ExecStart=/etc/init.d/exim4 start
|ExecStop=/etc/init.d/exim4 stop
|ExecReload=/etc/init.d/exim4 reload
|[2/5192]mh@drop:~ $ 

Das hab ich auch nie geschrieben, dennoch läuft der exim ohne halt
nicht.

Grße
Marc
-- 
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber         |   " Questions are the         | Mailadresse im Header
Mannheim, Germany  |     Beginning of Wisdom "     | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[toc] | [prev] | [next] | [standalone]

#121458

Kay Martinen <usenet@martinen.de>:

>Oder kennst du ein well known script-eckchen a la rc.[nn|local] das 
>erst nach login

Je nach Shell «"${HOME/}"/.profile», «"${HOME/}"/.bash_profile» oder 
… siehe Handbuch des entsprechenden Shells.

>oder nach X-Session start angesteuert wird - von allen Desktops, 
>window- und login-managern?

Wenn dabei ein Login‐Shell gestartet wird, dann wirkt das oben 
angeführte auch hier.

[toc] | [prev] | [next] | [standalone]

#121467

Helmut Waitzmann <nn.throttle@xoxy.net> writes:
> Kay Martinen <usenet@martinen.de>:
>> Oder kennst du ein well known script-eckchen a la rc.[nn|local] das
>> erst nach login
>
> Je nach Shell «"${HOME/}"/.profile», «"${HOME/}"/.bash_profile» oder …
> siehe Handbuch des entsprechenden Shells.
>
>> oder nach X-Session start angesteuert wird - von allen Desktops,
>> window- und login-managern?
>
> Wenn dabei ein Login‐Shell gestartet wird, dann wirkt das oben
> angeführte auch hier.

Gegebenenfalls noch ergänzt um Tests wie

    `tty` != 'not a tty'

und/oder

    -n "$DISPLAY"

vgt
-- 
Adresse gilt nur kurzzeitig!

[toc] | [prev] | [next] | [standalone]

#121468

Thomas Dorner 
<de.comp.os.unix.linux.misc.220224.dorner@spamgourmet.com>:
>Helmut Waitzmann <nn.throttle@xoxy.net> writes:
>> Kay Martinen <usenet@martinen.de>:
>>> Oder kennst du ein well known script-eckchen a la rc.[nn|local] 
>>> das erst nach login
>>
>> Je nach Shell «"${HOME/}"/.profile», «"${HOME/}"/.bash_profile» 
>> oder … siehe Handbuch des entsprechenden Shells.
>>
>>> oder nach X-Session start angesteuert wird - von allen Desktops, 
>>> window- und login-managern?
>>
>> Wenn dabei ein Login‐Shell gestartet wird, dann wirkt das oben 
>> angeführte auch hier.
>
>Gegebenenfalls noch ergänzt um Tests wie
>
>    `tty` != 'not a tty'
>

Ja.  Der angeführte Test scheitert allerdings beispielsweise in einem 
deutschsprachigen Locale.  Darüber hinaus braucht man die 
Fehlermeldung nicht zu prüfen:  «tty» liefert das Testergebnis auf das 
Vorhandensein eines Terminals im Exit‐Status frei Haus (steht im 
Handbuch!):

  tty > /dev/null 2>&1


Oder, was gleichbedeutend ist: 


  test -t 0

>und/oder
>
>    -n "$DISPLAY"
>

Das liefert das Ergebnis «ja», wenn es die Shell‐Variable «DISPLAY» 
gibt und sie einen nicht‐leeren Inhalt hat.  Inwiefern beantwortet das 
die Frage, ob der Prozess an einer virtuelle Konsole, deren 
Bildschirmschonerfunktion man einstellen könnte, hängt?


Ich würde mit dem Test 


  (
    terminal="$( tty 2> /dev/null )" &&
    expr " $terminal" : ' /dev/tty[0123456789]\{1,\}$' > /dev/null
  )

beginnen.  Er überprüft, ob Standard Input eines der Terminals mit 
einem Namen, bestehend aus dem Anfangsstück «/dev/tty» gefolgt von 
mindestens einer Ziffer, ist.  Vielleicht will man auch noch oder 
anstelle der Namensprüfung den Terminal‐Typ überprüfen.  Das Handbuch 
zu «setterm» nennt die Terminaltypen «linux» und «con».

[toc] | [prev] | [next] | [standalone]

#121472

Helmut Waitzmann schrieb am 24.02.2022 um 21:10:

> Thomas Dorner 
> <de.comp.os.unix.linux.misc.220224.dorner@spamgourmet.com>:
>
>> Gegebenenfalls noch ergänzt um Tests wie
>>
>>    `tty` != 'not a tty'
>
> Ja.  Der angeführte Test scheitert allerdings beispielsweise in einem 
> deutschsprachigen Locale.

`LANG=C tty` != 'not a tty'

> Darüber hinaus braucht man die 
> Fehlermeldung nicht zu prüfen:  «tty» liefert das Testergebnis auf das 
> Vorhandensein eines Terminals im Exit‐Status frei Haus (steht im 
> Handbuch!):

Das ist natürlich eleganter.

> Oder, was gleichbedeutend ist: 
>
>   test -t 0

Das kannte ich noch nicht. Wieder was gelernt :-)

Gruß
Claus

[toc] | [prev] | [next] | [standalone]

#121475

Claus Reibenstein <creibens@gmail.com> writes:
> Helmut Waitzmann schrieb am 24.02.2022 um 21:10:
>> Oder, was gleichbedeutend ist: 
>>
>>   test -t 0
>
> Das kannte ich noch nicht. Wieder was gelernt :-)

dito. :-)
-- 
Adresse gilt nur kurzzeitig!

[toc] | [prev] | [next] | [standalone]

#121473

Hab' noch was vergessen:

Helmut Waitzmann schrieb am 24.02.2022 um 21:10:

>   tty > /dev/null 2>&1

tty -s

Gruß
Claus

[toc] | [prev] | [next] | [standalone]

#121478

Claus Reibenstein <creibens@gmail.com>:
>Hab' noch was vergessen:
>
>Helmut Waitzmann schrieb am 24.02.2022 um 21:10:
>
>>   tty > /dev/null 2>&1
>
>tty -s

Ja, wenn man ein entsprechendes Programm «tty» hat.  (In POSIX ist
«-s» nicht enthalten.)

[toc] | [prev] | [next] | [standalone]

#121479

Helmut Waitzmann schrieb am 26.02.2022 um 20:38:

> Claus Reibenstein <creibens@gmail.com>:
>
>> tty -s
>
> Ja, wenn man ein entsprechendes Programm «tty» hat.

Oder eine Shell, dessen eingebautes "tty" das kann, z.B. bash.

Gruß
Claus

[toc] | [prev] | [next] | [standalone]

#121476

Helmut Waitzmann <nn.throttle@xoxy.net> writes:

> Thomas Dorner
> <de.comp.os.unix.linux.misc.220224.dorner@spamgourmet.com>:
>>Helmut Waitzmann <nn.throttle@xoxy.net> writes:
>>> Kay Martinen <usenet@martinen.de>:
>>>> oder nach X-Session start angesteuert wird - von allen Desktops,
>>>> window- und login-managern?
>>und/oder
>>
>>    -n "$DISPLAY"
>>
>
> Das liefert das Ergebnis «ja», wenn es die Shell‐Variable «DISPLAY»
> gibt und sie einen nicht‐leeren Inhalt hat.  Inwiefern beantwortet das
> die Frage, ob der Prozess an einer virtuelle Konsole, deren
> Bildschirmschonerfunktion man einstellen könnte, hängt?

Das beantwortet den Teil mit der X-Session, ohne X sollte DISPLAY
hoffentlich nicht gesetzt sein.  (Und es kommt ohne externes Programm aus.)

Viele Grüße, Thomas
-- 
Adresse gilt nur kurzzeitig!

[toc] | [prev] | [next] | [standalone]

#121477

Thomas Dorner 
<de.comp.os.unix.linux.misc.220225.dorner@spamgourmet.com>:
>Helmut Waitzmann <nn.throttle@xoxy.net> writes:
>
>> Thomas Dorner 
>> <de.comp.os.unix.linux.misc.220224.dorner@spamgourmet.com>:

>>>
>>>    -n "$DISPLAY"
>>>
>>
>> Das liefert das Ergebnis «ja», wenn es die Shell‐Variable 
>> «DISPLAY» gibt und sie einen nicht‐leeren Inhalt hat.  Inwiefern 
>> beantwortet das die Frage, ob der Prozess an einer virtuelle 
>> Konsole, deren Bildschirmschonerfunktion man einstellen könnte, 
>> hängt?
>
>Das beantwortet den Teil mit der X-Session, ohne X sollte DISPLAY 
>hoffentlich nicht gesetzt sein. (Und es kommt ohne externes 
>Programm aus.)

Wenn man beispielsweise in einem XTerm einen Shell laufen lässt, 
dann sieht der die Umgebungsvariable «DISPLAY» mit nicht‐leerem 
Inhalt, obwohl er nicht an einer virtuellen Konsole hängt.

(Umgekehrt sieht ein Login‐Shell an einer virtuellen Konsole, an der 
man sich textorientiert einloggt, keine Umgebungsvariable «DISPLAY», 
obwohl er an einer virtuellen Konsole hängt.)

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web