Merkwürdiges Drucker-Phänomen

[TuxPeter]

Merkwürdiges Drucker-Phänomen mit Brother Laserprinter, nach Entfernen von Lightdm

Mein Umstieg auf ein neu installiertes Buster - Testing war eigentlich völlig problemlos. Und, das kann ich an dieser Stelle einfügen, absolut empfehlenswert; vieles ist im Detail verbessert zu haben, Verschlechterungen habe ich noch keine festgestellt.

Sogar mein Sonderwunsch, keinen Display-Manager benutzen zu müssen, konnte mit Hilfe eines Forums-Tipps und des Befehls „systemctl.disable lightdm.service“ leicht erfüllt werden. Auch mein S/W-Laserprinter namens Brother HL-L2310D ließ sich mit Hilfe des hl[…].deb – Paketes vom Hersteller leicht installieren.
Laut Brother muss man vorher die lib32stdc++ (die jetzt lib32stdc++6 heißt) installieren und ein Verzeichnis var/spool/lpd anlegen – welches aber anscheinend gar nicht gebraucht wird.
Die Installation mit dpkg -i –force-all hl[…].deb lief in Sekundenschnelle durch. Beim Ausführen im Xterminal ploppt sogar ein Fensterchen auf, in dem noch ein paar Parameter wie Namen etc. vergeben werden können. Der Eintrag in CUPS ist dann schon fix und fertig, und man kann los drucken. Prima Sache!

Dann kam, beim Drucken von Bildern, das Merkwürdige!

Kleine Bilder wurden völlig problemlos gedruckt, aber ab einer Größe von ca ¼ DIN-A4 blinkte zwar die zuständige LED am Drucker vielversprechend; und im CUPS wurde der Job auch anschließend als ordnungsgemäß beendet gemeldet, Allein, es kam kein Fitzelchen bedrucktes Papier aus dem Drucker. Drucken mit (dem schön runderneuertem) Gimp, mit gThumb, mit vorher umgewandelten pdf-Dateien – egal, es ging nicht. Was habe ich rumprobiert mit verschiedenen Auflösungen, vorheriger Umwandlung in SW-Bilder, mit verschiedenen Auflösungen und Skalierungen – alles nix. Und immer wieder zwischendurch Stretch gebootet und probiert, Einstellungen verglichen (Stretch ist noch auf dem gleichen PC in anderer Part. vorhanden), und da ging es.

Schließlich habe ich mir den Insallationsvorgang noch mal angeschaut der gibt Warnungen aus, was aber wegen des nur 32-bittigen Treibers normal ist. Wegen des - -force-all tut er alles anscheinend trotzdem richtig. Es werden aber die Programme „ldconfig“ und „start-stop-daemon“ „nicht im PATH gefunden“. Das wars.
Deinstalliert, in CUPS entfernt, neu installiert – mit korrektem Pfad natürlich, und jetzt läuft es.

Bleibt die Frage, warum der Pfad im Xterm (im XFce4-Terminal ebenso) nur auf „/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games“ wie beim Normaluser und nicht auf „/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin“ gesetzt ist, wie sich das für root gehört. (Auf der „richtigen“ Konsole stimmt es, nur im Terminal nicht. Eventuell wird das normalerweise vom Displaymanager gemanaged, so meine wilde Vermutung.

Wie wäre denn der richtige Weg, den root-Pfad auch im Xterm nach Wechsel zu root mittels su sicherzustellen? Mir fällt dazu nur ein, diesen Pfad in /root/.bashrc am Schluss zu setzen, ist aber sicherlich nicht der optimale und korrekte Weg.

Ansonsten hoffe ich, hiermit in Smalltalk ein wenig zur allgemeinen Unterhaltung beigetragen zu haben,
Grüße
TuxPeter

[smutbert]

mit

Code: Alles auswählen

su -

wird eine loginshell gestartet, bei der dann u.a. auch path root-typisch gesetzt ist.

[TuxPeter]

Genauso war ich es gewohnt: Im XTerm su und Passworteingabe, und ich habe eine vollwertige root-Umgebung.
Passiert aber jetzt nicht, der alte User-Path bleibt erhalten!

[smutbert]

Hast du den Bindestrich hinter su gesehen?
(Das ist die Ablürzung für die Option »-l«, die du natürlich auch verwenden kannst.)

Das Verhalten von su hat sich geändert. Bei stretch und davor hat su (ohne - bzw, -l) gesetzte Variablen vom aufrufenden User beibehalten und nur durch die Variablen des neuen Users zusätzlich gesetzt/überschrieben, damit hat man eine Art gemischte Umgebung erhalten. Bei ssh hat das dafür gesorgt, dass man den ssh-agent des aufrufenden Nutzers verwenden konnte, bei Pulseaudio hat das dagegen zu Problemen geführt.

Das jetzige Verhalten ist konsistenter. Ohne Option bleiben die Variablen soweit möglich erhalten und unverändert (du hast das an PATH bemerkt), bei -l oder - wird eine loginshell gestartet, in der keinerlei Variablen des su-aufrufenden Benutzers mehr vorhanden sind.

[TuxPeter]

Oh - und herzlichen Dank für die Aufklärung!

(und nein, den "-" hatte ich zwar gesehen, aber nicht als zugehörig betrachtet, obwohl du ihn schön ins Code-Tag eingeschlossen hast)

Gut, dass ich das jetzt weiß, sonst wäre ich da garantiert noch mal drüber gestolpert. Übrigens geht es dann auch gleich ins Verzeichnis /root, praktisch. Die ganzen apt Befehle, die ich zwischenzeitlich mittels su ohne Bindestrich abgesetzt habe, hat das neue Verhalten aber nicht gestört. Anscheinend sind die original-deb-Pakete da mit exakten Pfadangabe versehen, oder sie setzten erstmal ihre korrekte Umgebung.

Nachtrag: mal man su angeschaut. Was da alles noch an so einem kleinen harmlosen, zumindest von mir vielgenutzten Befehlchen dranhängt ...