Anfängerfragen - Linux Neuling? Hier ist der richtige Platz für deine Fragen (2)

[Elmario]

Hihi, ich kam her um mitzuteilen, dass ich genau diese Lösung selbst herausgefunden habe
Nach etlichen Experimentden mit diversen su, bash, sudo, pkexec Konstruktionen, bekam ich irgendwann die Fehlermeldung, dass $DISPLAY nicht gesetzt sei.
Also habe ich mir $DISPLAY als angemeldeter Desktopuser ausgegeben ( :0.0 ) und habe mir noch ein kleines extra docking-script gebaut, das von der rule aufgerufen wird.

90-docking.rules

SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="0d8c", ATTR{idProduct}=="0102", RUN+="/bin/su -c /opt/scripts/dockedscript.sh ladmin"
ACTION=="remove", ENV{ID_MODEL_ID}=="0102", RUN+="/bin/su -c /opt/scripts/undockedscript.sh - ladmin"

und

docked.sh

#!/bin/bash
export DISPLAY=':0.0'
/opt/scripts/hotkey-display.sh extended1+2+3

(Und dementsprechend auch gleich noch ein undocked.sh)

Hurra, dass es endlich funktioniert!
Danke euch.

Zwei Fragen bleiben natürlich:
1. Weshalb heißt es bei mir :0.0 und nicht nur :0 ? Was ist der Unterschied?
2. Und weshalb funktioniert das ganze Geraffel mit sudo / su usw. nicht? Wenn man schon die Optionen verwendet, die angeblich die Umgebungsvariablen der angebgebenen Users verfügbar machen, dann sollte doch auch $DISPLAY dabei sein. Wird hier evtl. unterschieden zwischen Uservariablen und Umgebungsvariablen, wie unter Windows? Oder nach welcher Systematik kann man denn wisse, welche Variablen dann nun mit übergeben werdenm und welche nicht?

 

[theoradicus]

Hihi, ich kam her um mitzuteilen, dass ich genau diese Lösung selbst herausgefunden habe
Nach etlichen Experimentden mit diversen su, bash, sudo, pkexec Konstruktionen, bekam ich irgendwann die Fehlermeldung, dass $DISPLAY nicht gesetzt sei.
Also habe ich mir $DISPLAY als angemeldeter Desktopuser ausgegeben ( :0.0 ) und habe mir noch ein kleines extra docking-script gebaut, das von der rule aufgerufen wird.

90-docking.rules


und

docked.sh

(Und dementsprechend auch gleich noch ein undocked.sh)

Hurra, dass es endlich funktioniert!
Danke euch.

Zwei Fragen bleiben natürlich:
1. Weshalb heißt es bei mir :0.0 und nicht nur :0 ? Was ist der Unterschied?
2. Und weshalb funktioniert das ganze Geraffel mit sudo / su usw. nicht? Wenn man schon die Optionen verwendet, die angeblich die Umgebungsvariablen der angebgebenen Users verfügbar machen, dann sollte doch auch $DISPLAY dabei sein. Wird hier evtl. unterschieden zwischen Uservariablen und Umgebungsvariablen, wie unter Windows? Oder nach welcher Systematik kann man denn wisse, welche Variablen dann nun mit übergeben werdenm und welche nicht?

zu 1: Multihead also mehrere Monitore (archwiki) - kommt vermutich auf die konkrete konfiguration von X und dem Windowmanager (?) an, wie mehrere Bildschirme gemanaget werden - oder an der Xorg config - auf KDE mit 2 monitoren seh ich nur ":0" zB

zu 2: "Systemweite" scripts haben kein "sudo" feature - und die Umgebung unter denen sie gestartet werden ist eine andere - systemd hat auch einen User und einen Systemdienst (zumindes bei Arch)

 

[Elmario]

Hier stand eine lange Antwort mit zwei weiteren Fragen. Aber Katze musste sich beim freudigen Herumwälzen auf dem Tisch, auf die Tastatur rollen und dabei einerseits den Shortcut für Seite zurück und gleichzeitig den Shortcut für "Cache leeren" des Webbrowsers auslösen.

Danke und Gute Nacht!

 

[Kuzorra]

Welche Taste löscht denn den Cache?

 

[Elmario]

Naja, das Verständnis über die Details, weshalb von welchem "Agent" die Übernahme des Environments bis zu welchem Grad funktioniert, werde ich dann wohl erst Mal auf die lange Bank schieben.

Im Moment habe ich nämlich das Problem, dass ich mit dem Skript welches ja nun nach dem Docking läuft, auch gerne den Pulseaudio Default Output umstellen möchte. Denn Pulse schaltet nach Anstecken des Docks automatisch auf die am Dock befindliche USB-Soundkarte um, aber das möchte ich nicht. Also soll ein

pacmd set-default-sink 1

eigentlich dafür sorgen, dass die Ausgabe wieder automatisch auf den internen Codec zurückgestellt wird, aber leider funktioniert das auch nur per direktem Command, aber nicht aus dem Skript heraus das von udev gestartet wird
Leider habe ich keine Ahnung, wie ich das Debuggen könnte. Unter journalctl finde ich einfach gar Nichts dazu.

Welche Taste löscht denn den Cache?

Ein AddOn namens ClearCache, das ich erst vor ca. drei Tagen installiert habe, macht das per F9, vielleicht schon fast zu einfach
Wenn man das oft benötigt ist das schon sehr viel praktischer, als sich jedes Mal durch die umständliche Chronik des Fuchs zu wurschteln. Das dachte wohl auch meine Katze.

 

[Fallwrrk]

Das funktioniert wahrscheinlich deshalb nicht, weil PulseAudio per Default pro User läuft (und auch laufen sollte). Dementsprechend führst du "pacmd" als "root" oder "udev" aus (keine Ahnung grad unter welchem User der läuft). Ob ein "runuser" da hilft weiß ich nicht.

 

[bitteklingeln]

Welche Taste löscht denn den Cache?

Aus eigener Erfahrung weiss ich, dass Katzen ganz geheime Shortcuts kennen, die es für den gemeinen Nutzer eigentlich nicht gibt.

 

[Kuzorra]

Hmmm, ich dachte bisher immer, das Katzen für andere Features verantwortlich wären....

Spoiler

$ cat --help
Aufruf: cat [OPTION]... [DATEI]...
Aneinanderfügung aller DATEI(en) sortiert auf die Standardausgabe schreiben.

Ohne DATEI oder wenn DATEI „-“ ist, Standardeingabe lesen.

  -A, --show-all           äquivalent zu -vET
  -b, --number-nonblank    nichtleere Ausgabezeilen nummerieren
  -e                       äquivalent zu -vE
  -E, --show-ends          $ am Ende jeder Zeile ausgeben
  -n, --number             alle Ausgabezeilen nummerieren
  -s, --squeeze-blank      aufeinander folgende Leerzeilen unterdrücken
  -t                       äquivalent zu -vT
  -T, --show-tabs          Tabulator�Zeichen als ^I ausgeben
  -u                       (wird ignoriert)
  -v, --show-nonprinting   ^� und M�Notation benutzen, außer für LFD und Tab.
      --help     diese Hilfe anzeigen und beenden
      --version  Versionsinformation anzeigen und beenden

Beispiele:
  cat f - g  Gibt den Inhalt von f aus, dann die Standardeingabe,
              schließlich den Inhalt von g.
  cat        Kopiert die Standardeingabe in die Standardausgabe.

GNU coreutils Onlinehilfe: <http://www.gnu.org/software/coreutils/>
Melden Sie Übersetzungsfehler für cat an <translation-team-de@lists.sourceforge.net>
Die vollständige Dokumentation ist hier: <http://www.gnu.org/software/coreutils/cat>
oder auch lokal mittels „info '(coreutils) cat invocation'“

 

[Elmario]

Das funktioniert wahrscheinlich deshalb nicht, weil PulseAudio per Default pro User läuft (und auch laufen sollte). Dementsprechend führst du "pacmd" als "root" oder "udev" aus (keine Ahnung grad unter welchem User der läuft). Ob ein "runuser" da hilft weiß ich nicht.

udev läuft hier als root, das konnte ich sehen durch die Testversion mit "touch".
Ich rufe das Skript ja so auf:

RUN+="/bin/su -c /opt/scripts/dockedscript.sh ladmin"

Dadurch sollte das Problem doch eigentlich umgangen werden, deshalb wundert es mich ja, dass es trotzdem all diese Probleme gibt.

Wie könnte ich denn erreichen, dass ich eine Debuggingmöglichkeit habe? Irgendeine Ausgabe des fehlgeschlagenen Commands. In welchem Log?

 

[docsnydor]

Kurze Frage: Welcher Desktop hat euerer Meinung nach die wenigsten Probleme mit Dual-Monitor-Betrieb. Ich bekomme demnächst einen neuen Laptop und kann mich im Moment nicht entscheiden, welche DE ich einsetzen soll / will. Ich möchte gerne den Laptop im laufenden Betrieb vom externen Monitor abziehen und danach einfach wieder dran stecken. Im Moment habe ich KDE, aber das verändern sich immer die Panel. Zur Auswahl stehen noch Gnome oder XFCE. (ich würde gerne bei den 3 "Großen" bleiben). Im Single-Monitor Betrieb finde ich alle 3 gleich-toll. Ich würde es also nur davon abhängig machen.
Distro wird vermutlich Manjaro...

 

[Fallwrrk]

GNOME. Weil Wayland. Wayland funktioniert um ein Vielfaches besser mit Multimonitoring. Sofern du aber die gleiche Skalierung auf beiden Monitoren nutzt (also nicht ein Full HD- und ein 4K-Monitor), sollte XFCE aber auch keine Probleme machen. Das ist über die Jahre auch ausreichend gereift.

Wie könnte ich denn erreichen, dass ich eine Debuggingmöglichkeit habe?

Sollte eigentlich im Log von udev stehen, also "journalctl -u systemd-udevd.service". Wenn nicht, wrappe das Script. Erstell dir n Script, welches dein "echtes" Script aufruft und lass es die Ausgabe in ne Datei umleiten.

 

[docsnydor]

@Fallwrrk

Danke. Ich hatte auch Richtung Gnome tendiert... Ich werde es mit Manjaro (da ist wayland noch nicht default, oder?) testen.

 

[Fallwrrk]

Wayland ist inzwischen bei jeder Distri mit aktuellem GNOME der Standard. Nur Ubuntu stellt sich diesbezüglich noch quer, hauptsächlich wegen den proprietären Nvidia-Treibern, die ne Abneigung gegen Wayland haben.

 

[ClisClis]

hatte ubuntu nicht wayland ewig gepusht? ^^

 

[Fallwrrk]

Die haben nicht Wayland gepusht, die haben Mir gepusht. Wayland wird bei Ubuntu STS auch durchaus benutzt, aber bei der 18.04er LTS haben sie sich dann doch für X11 als Standard entschieden. Denke mal mit 20.04 wird es aber auch bei Ubuntu LTS default. Und selbst wenn nicht, es sind nur zwei Mausklicks.

 

[ClisClis]

stimmt, da war noch Mir..

18.04 läuft bei mir jetzt übrigens auf dem homeserver... ich hab mich endlich dazu bewegt, mein altes Crunchbang abzulösen, was ja noch auf debia wheezy basierte und inzwischen überhaupt nicht mehr supportet ist.

Aber das Ding war halt einfach top, da war nie was mit.
Hab ich 2014 auf einem damals 3 jährigen Laptop aufgesetzt und musste nur neu gestartet werden als ich zwei mal umgezogen bin. Einfach alles drauf gehauen und lief und lief und lief, wie es soll.

eigentlich wollte ich den Server dann ja auf bunsen labs neu aufsetzen. Aber irgendwie hatte ich nen Linux PC den ich erst als Client für Bürokram nutzen wollte mit 18.04 aufgesetzt und hab da was getestet und dann war der halbe Server schon da

 

[Elmario]

GNOME. Weil Wayland. Wayland funktioniert um ein Vielfaches besser mit Multimonitoring. Sofern du aber die gleiche Skalierung auf beiden Monitoren nutzt (also nicht ein Full HD- und ein 4K-Monitor), sollte XFCE aber auch keine Probleme machen. Das ist über die Jahre auch ausreichend gereift.



Sollte eigentlich im Log von udev stehen, also "journalctl -u systemd-udevd.service". Wenn nicht, wrappe das Script. Erstell dir n Script, welches dein "echtes" Script aufruft und lass es die Ausgabe in ne Datei umleiten.

Danke, habe das Skript nun mit "2>&1>>/tmp/pacmdlog.log" gestartet
Herausgefunden, dass sich die Indexnummer der Sink zum eingebauten Codec scheinbar zufällig zwischen 0 und 1 ändert.
Deshalb habe ich nun ein Weiteres pacmd in das Skript

/usr/bin/pacmd set-default-sink 0
/usr/bin/pacmd set-default-sink 1

gepackt. Damit scheint es zumindest momentan weitestgehend zu funktionieren, auch wenn ich damit schon einmal einen Fehlschlag hatte:
Einmal zeigte pavucontrol den Default Output zwar als "Eingebautes Tongerät Analog Stereo" an, was ja so sein soll, aber es kam trotzdem kein Ton. Mal sehen, was sich da noch ergibt..

 

[docsnydor]

habe gerade mal Manjaro Gnome (iso frisch gezogen) installiert. Standard ist da immernoch X11. Habe dann auf wayland umgestellt und bemerke an der Testkiste erstmal überhaupt keinen Unterschied. Ansonsten gefällt mir das Gnome richtig gut. Das wird es wohl auf dem Laptop werden... Eigentlich würde ich gerne Arch nehmen, aber da fehlt mir die Zeit für das Gefrickel, bis es schön aussieht und auch was kann ;-)

 

[Fallwrrk]

GNOME auf Wayland hat ein paar Unterschiede. Zum Beispiel 4-Finger-Gestern zum Wechseln zwischen den Workspaces aufm Touchpad.

 

[ClisClis]

Long shot ich weiss:
Heute morgen hab ich Nachricht bekommen, dass Kalender und Kontakte nicht mehr sauber synchronisieren auf OwnCloud.
Hab dann einfach mal den Apache Service rebooten wollen. Das ist fehlgeschlagen. Warnung kam etwas von wegen dass der Servername wohl auf localhost gesetzt werde da 127.0.0.1 ein Problem mache (hab die Meldung nicht mehr genau). Das solle man wohl in die Apache2.conf schreiben.

Nun, da ich nichts in ein File schreiben konnte, da die Meldung kam, das System sei Read-Only (war als Root angemeldet!) und ich grad nicht viel Zeit hatte, habe ich gedacht ich mach mal nen Neustart.

Nun, der Server ist wieder oben (wird im WebUI des Routers angezeigt und ist Pingbar) aber SSH und RDP funktionieren nicht. Keine Refused connections oder so, sondern Timeout.

Ist der einfach nicht ganz hoch gekommen? Ich komm da physisch jetzt grad nicht dran. Gibts da irgend ne Möglichkeit?
Ich bezweifle es ja, aber wer weiss. ...

Sonst muss ich da heute Abend mal vor die Kiste hocken.

 

[flxmmr]

hört sich nach einem Disk-Crash an?

Andere Frage: wie kann man in GNOME/Wayland environment-Variablen festlegen. Normalerweise habe ich einfach in der Xsession/xinitrc meine ./profile gesourct, aber mit Wayland funktioniert das halt nicht...

Nun durfte ich aber feststellen, dass einige der Variablen in .profile trotzdem in meinem Gnome-Terminal gesetzt sind. Füge ich ein `export FOO="bar"`dort ein, ist FOO auch in der Shell... PATH/MANPATH und co lassen sich aber nicht setzen??! Ich werde jetzt mal weiter nach dem passenden Repo suchen, aber vielleicht weiß ja jemand von euch, was zum Teufel da passiert?

EDIT: .config/environment.d/test.conf funktioniert nicht... (Fedora 31)

 

[ClisClis]

ja, fschk war nötig..

 

[flxmmr]

war ja dann eher ein einfaches Problem.

So, ich bin jetzt kurz davor, die PATH-Initialisierung in die bashrc zu schreiben... Beim login über gdm scheint ja zuerst `gdm-wayland-session` aufgerufen zu werden, das dann wiederum das bekannte `gdm-session`-Skript aufruft, in dem eine Login-Shell ausgeführt wird, um das Environment zu setzen.

In .profile setze ich ein paar Variablen und habe ein if, um "doppel-sourcing" zu vermeiden. Mittlerweile logge ich jeden Aufruf der .profile und jeder Aufruf hat ein neues SHLVL, nach mehrmaligem Login werden auch manchen Variablen gesetzt.... Vllt. liegt es auch daran, dass die gnome-shell gerade einen Bug hat, aber das ganze treibt mich zusehends in den Wahnsinn :/

 

[ClisClis]

war es, nur irgendwie schon das 2. mal.. in ein paar tagen

 

[flxmmr]

Hast du schon mal die SMART-Werte gecheckt.

Habe nun eine Lösung für mein Problem, gefunden, das Problem sitzt wohl zwischen Bildschirm-Tastatur, bei der nichtexistenten Doku zu systemd/dbus/gdm/gnome-session dauert das dann halt auch etwas länger.

Grundsätzlich scheint es so zu sein, dass beim Start von Gnome via gdm/wayland das genannte `gnome-session`-Skript bei jedem Start zuerst das Environment des (über Logins persistenten) user-systemds abfragt, in diesem Environment .profile ausführt und das enstehende Environment dann irgendwann selektiv (- PATH/MANPATH/...) zum Update des user-systemds verwendet wird. Mein Problem wird durch ein beherztes `dbus-update-activation-environment --all` in .profile behoben (das muss man zwar jetzt bei jedem GNOME+WAYLAND neu ausführen), aber es ist auf jedenfall ein zufriedenstellendere Lösung, als .bashrc...

 

[theoradicus]

EDIT: .config/environment.d/test.conf funktioniert nicht... (Fedora 31)

Sind die Variablen dort korrekt deklariert als NAME=VALUE ? , bei Pfaden zB mit $HOME und kein "~" ?

Eigentlich sollte das ja lt. der offiziellen Dokumentation funktionieren - man environment.d

aber nicht immer: Redhat Bugzilla bei Fedora29
Also ein Bug oder fehlende / falsche Doku in Gnome ...

 

[Gelöschtes Mitglied 144635]

Habe schon länger nicht mehr an meinem OS rummgeschraubt. Es läuft und läuft einfach. Dennoch würden mich neue Erkenntnisse/Erfahrungen über Sway interessieren. Kann doch nicht sein, dass ich der einzige bin, der das nutzt?

 

[Elmario]

Naja, schon mit Wayland reduzierst du die Menge an Gleichgesinnten auf ca. drei im Forum
Und der Composer/Windowmanager, wie auch immer, splittert diesen Rest dann noch weiter auf.

 

[flxmmr]

Sind die Variablen dort korrekt deklariert als NAME=VALUE ? , bei Pfaden zB mit $HOME und kein "~" ?

Glaub' mir, ich habe das schon erstmal ganz ohne Variablenspielereien ausprobiert... Warum environment.d nicht geht, weiß ich allerdings wirklich nicht...

Also ein Bug oder fehlende / falsche Doku in Gnome ...

Ich glaube hier liegt der Hund begraben, wie ich das sehe liest beim Login 1) `gdb-wayland-session` das user-dbus/systemd-environment aus, und setzt sein Runtime-Environment entsprechend, 2) das gnome-session-Skript ruft eine Login-Shell aus (nur für Wayland-Sessions, für X hat man ja seine xinitrc), um Variablen zu sammeln 3) gnome-session startet dbus/systemd und pusht das environment dort "hinein", allerdings werden irgendwie einige "sicherheitsrelevante" Variablen gefiltert (mangels Doku weiß ich das nicht anders zu beschreiben, dafür habe ich auch keinen Code gefunden) 4) in Gnome bekommt die bash im Terminal das environment von systemd (das kann man übrigens mit `systemctl --user show-environment anschauen) 5) bei Logout bleiben der user-dbus/systemd bestehen → 6) nächster Login: bei 1) bekommt `gdb-wayland-session` das unvollständige environment, wenn man jetzt mit einer Variable checkt, ob .profile bereits gesourct wurde, führte das bei mir anfangs zu extremer Verwirrung...

ich habe jetzt einfach einen check eingefügt, der dafür sorgt, dass bei einem gnome-wayland login alles in .profile evaluiert wird

if [ "${XDG_SESSION_DESKTOP}" = "gnome" ] && [ "${XDG_SESSION_TYPE}" = "wayland" ]
then unset PROFILE_SOURCED

und am Ende sorge ich dafür, dass auch PATHs im dbus/systemd ankommen (kein Ahnung ob das so gedacht ist, aber es geht).

    if [ "${XDG_SESSION_DESKTOP}" = "gnome" ] && [ "${XDG_SESSION_TYPE}" = "wayland" ]
    then dbus-update-activation-environment --all
    fi

Anscheinend wurde aber auch erst in Gnome 3.34 die gesamte Infrastruktur des Gnome-environment Handlings vollständig in die Hände von dbus/systemd gelegt, es kann gut sein, dass mein Problem darin liegt.

Der Bugtracker von gnome-session ist übrigens zur Hälfte voll mit dbus/systemd-bugs, die sich um das drehen, in Anbetracht der Heulerei vieler Nutzer ist eine niedrige 2stellige Zahl an Issues allerdings wirklich lustig... Vllt. wissen auch die meisten einfach nicht, wohin man reporten soll....

Bei der ganzen Gnome/Systemd-Komplexitätskatastrophe habe ich mittlerweile auch den grundlegenden Eindruck, dass sich das auf Windows-WTF-Level bewegt, weil man mit viel zu wenig Manpower versucht tolle Systeme zu entwickeln, die auch die Konkurrenz nicht bugfrei und dokumentiert hinbekommt. Vorteil der Konkurrenz ggü ist, man muss es nicht nutzen und kann den Code ansehen (und dank geringer Manpower ist der sogar vom Volumen sehr übersichtlich...)

EDIT: sway habe ich mal angesehen, wollte ich auch mal ausprobieren, aber Gnome mit Dash-to-Dock war bis zum Wochenende auf der "just-works (tm)"-Liste recht weit oben angesiedelt und nachdem ich ehrlich gesagt zur Zeit nur wenig Lust habe, mich um meinen Desktop zu kümmern (nachdem ich ja hauptsächlich der Sicherheit wegen auf Wayland umgestiegen bin und dann erstmal feststellen durfte, dass XWayland in Gnome leider bis 3.34 ohne ~/.Xauthority, sonder mit fixem, hardgecodetem `xhost +SI:localuser:<username>` und abstract-Sockets lief und da ja fast alle Applikationen damit laufen, ein mnt-namespace-basiertes Sandboxing reichlich sinnlos erscheint... – welchen Zweck Dinge wie snaps und flatpaks dabei haben sollen, weiß ich wirklich nicht....)

 

[Dani2070]

@Ape: Ich nutze Sway seit der 1.0 Beta auf meinem privaten Laptop und bin bisher auf keine unlösbaren Probleme gestoßen. Allerdings nutze ich auch 90% der Zeit nur Browser (Firefox) und Terminal (Termite). Thunderbird muss man momentan noch aus dem AUR nehmen, wenn man richtige Wayland-Unterstützung will. Ach so wichtig zu erwähnen sind noch wl-clipboard (xclip für Wayland) und mako (Notification Daemon, quasi Dunst für Wayland).
Wenn ich mein Arbeitslaptop mit Windows an einen Monitor/Beamer stecke und plötzlich alles kaputt geht, sehne ich mich nach Sway zurück.