Hallo Gruppe.
Ich habe hier ein neues Notebook Lenovo V7 G4, es läuft Slackware Current, und ich habe xsane 0.999 installiert. Starte ich xsane als root oder mit sudo, wovon xsane selber hektisch abrät, weil das "wirklich gefährlich" sei, funktioniert alles gut, also die Einrichtung sollte doch stimmen?
Starte ich als mein user, erscheint nach Scan-Befehl:
"Konnte Scanner nicht starten: Ungültiges Argument".
Habe lange gegugelt, wahrscheinlich zu unbeholfen, denn ich bekam nur schier unendlich viele Meldungen zur richtigen Einrichtung, aber nicht zu den Permissions und nicht zu dem Problem, dass der Scanner unter root gut funktioniert.
Den localen Ordner .sane habe ich gelöscht gehabt, Scanner aus- und eingesteckt...
Mein user ist in diesen Gruppen:
disk lp wheel floppy audio video cdrom games plugdev power netdev scanner users console
Dankbar für jeden Hinweis bleibt Erich
On Sat, Nov 16, 2024 at 08:16:42AM +0000, E. Hoffmann wrote:
Hallo Gruppe.
Ich habe hier ein neues Notebook Lenovo V7 G4, es läuft Slackware Current, und ich habe xsane 0.999 installiert. Starte ich xsane als root oder mit sudo, wovon xsane selber hektisch abrät, weil das "wirklich gefährlich" sei, funktioniert alles gut, also die Einrichtung sollte doch stimmen?
Starte ich als mein user, erscheint nach Scan-Befehl:
"Konnte Scanner nicht starten: Ungültiges Argument".
Ist Dein regulärer User in der "scanner"-Gruppe?
Tippe mal, als regulärer User in ein Terminal:
groups
Ist "scanner" dabei? Wenn nicht: probiere doch mal
sudo usermod -G scanner <dein-user-name>
(unter Debian gibt es auch "adduser <user> <group>" dafür).
lg
Am Samstag, November 16, 2024 09:30 CET, schrieb tomas@tuxteam.de:
Ist Dein regulärer User in der "scanner"-Gruppe?
Tippe mal, als regulärer User in ein Terminal:
groups
Ist "scanner" dabei? Wenn nicht: probiere doch mal
sudo usermod -G scanner <dein-user-name>
(unter Debian gibt es auch "adduser <user> <group>" dafür).
Wichtig: damit das wirksam wird muss man sich danach ab- und wieder anmelden.
Gruss RalfD
On Sat, Nov 16, 2024 at 10:33:37AM +0100, Ralf Mattes wrote:
Am Samstag, November 16, 2024 09:30 CET, schrieb tomas@tuxteam.de:
Ist Dein regulärer User in der "scanner"-Gruppe?
Tippe mal, als regulärer User in ein Terminal:
groups
Ist "scanner" dabei? Wenn nicht: probiere doch mal
sudo usermod -G scanner <dein-user-name>
(unter Debian gibt es auch "adduser <user> <group>" dafür).
Wichtig: damit das wirksam wird muss man sich danach ab- und wieder anmelden.
Korrekt, danke für die Erinnerung.
lg
* Ralf Mattes: " Re: Schon wieder xsane "Konnte scanner nicht starten Ungültiges Argument"" (Sat, 16 Nov 2024 10:33:37 +0100):
Am Samstag, November 16, 2024 09:30 CET, schrieb tomas@tuxteam.de:
Ist Dein regulärer User in der "scanner"-Gruppe?
Tippe mal, als regulärer User in ein Terminal:
groups
Ist "scanner" dabei? Wenn nicht: probiere doch mal
sudo usermod -G scanner <dein-user-name>
(unter Debian gibt es auch "adduser <user> <group>" dafür).
Wichtig: damit das wirksam wird muss man sich danach ab- und wieder anmelden.
Nitpick: nicht unbedingt.
Man kann auch mit 'newgrp' zur neuen Gruppe und wieder zurück switchen, dann ist sie auch mit 'id' bekannt.
Grüße Mathias
Am Sonntag, November 17, 2024 21:01 CET, schrieb Mathias Behrle m9s@mailbox.org:
Wichtig: damit das wirksam wird muss man sich danach ab- und wieder anmelden.
Nitpick: nicht unbedingt.
Man kann auch mit 'newgrp' zur neuen Gruppe und wieder zurück switchen, dann i sie auch mit 'id' bekannt.
Hmm ,interessant. Ist mir neu dass man von "aussen" das Environment eines laufenden Prozesses ändern kann. Man lernt nie aus ....
Gruss RalfD
Grüße Mathias
--
Mathias Behrle PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6 AC29 7E5C 46B9 D0B6 1C71 7681 D6D0 9BE4 8405 BBF6
On Sun, Nov 17, 2024 at 09:18:40PM +0100, Ralf Mattes wrote:
Am Sonntag, November 17, 2024 21:01 CET, schrieb Mathias Behrle m9s@mailbox.org:
Wichtig: damit das wirksam wird muss man sich danach ab- und wieder anmelden.
Nitpick: nicht unbedingt.
Man kann auch mit 'newgrp' zur neuen Gruppe und wieder zurück switchen, dann i sie auch mit 'id' bekannt.
Hmm ,interessant. Ist mir neu dass man von "aussen" das Environment eines laufenden Prozesses ändern kann. Man lernt nie aus ....
Mathias hat recht. Aber das gilt natürlich nur in der gerade laufenden Shell, so dass das "irgendwie schon" von aussen ist (so wie wenn Du "export blah=foo" sagen würdest).
Die anderen gerade laufenden Shells (oder sonstige Anwendungen) kriegen da nichts mit. Wenn also z.B. die Scan-Applikation irgendwelche obskure DBUS- Gymnastik macht, dann könnte es evtl. trotzdem schiefgehen.
lg
Am Montag, November 18, 2024 06:40 CET, schrieb tomas@tuxteam.de:
Hmm ,interessant. Ist mir neu dass man von "aussen" das Environment eines laufenden Prozesses ändern kann. Man lernt nie aus ....
Mathias hat recht. Aber das gilt natürlich nur in der gerade laufenden Shell, so dass das "irgendwie schon" von aussen ist (so wie wenn Du "export blah=foo" sagen würdest).
Die anderen gerade laufenden Shells (oder sonstige Anwendungen) kriegen da nichts mit. Wenn also z.B. die Scan-Applikation irgendwelche obskure DBUS- Gymnastik macht, dann könnte es evtl. trotzdem schiefgehen.
O.k. - auch jenseits der D-Bus Gymnastik wird ein Programm wie xsane ja gemeiniglich aus einer Desktop-Umgebung gestartet (per Doppelklick oder Menueintrag etc.). Da hilft das doch garnicht, oder?
Gruss RalfD
lg
t
On Mon, Nov 18, 2024 at 07:54:08AM +0100, Ralf Mattes wrote:
Am Montag, November 18, 2024 06:40 CET, schrieb tomas@tuxteam.de:
Hmm ,interessant. Ist mir neu dass man von "aussen" das Environment eines laufenden Prozesses ändern kann. Man lernt nie aus ....
Mathias hat recht. Aber das gilt natürlich nur in der gerade laufenden Shell, so dass das "irgendwie schon" von aussen ist (so wie wenn Du "export blah=foo" sagen würdest).
Die anderen gerade laufenden Shells (oder sonstige Anwendungen) kriegen da nichts mit. Wenn also z.B. die Scan-Applikation irgendwelche obskure DBUS- Gymnastik macht, dann könnte es evtl. trotzdem schiefgehen.
O.k. - auch jenseits der D-Bus Gymnastik wird ein Programm wie xsane ja gemeiniglich aus einer Desktop-Umgebung gestartet (per Doppelklick oder Menueintrag etc.). Da hilft das doch garnicht, oder?
Korrekt -- mensch müsste es schon von der Shell starten, in der mensch das "newgrp" aufgerufen hat. Bei einer ehrwürdigen Anwendung wie xsane besteht tatsächlich eine Chance, dass es auch klappt.
lg
On Sat, 16 Nov 2024 09:30:21 +0100 tomas@tuxteam.de wrote:
On Sat, Nov 16, 2024 at 08:16:42AM +0000, E. Hoffmann wrote:
Hallo Gruppe.
(...)
Ist Dein regulärer User in der "scanner"-Gruppe?
Ja, ist er. Vielen Dank für die prompte Reaktion!
Hier noch mal meine groupliste:
disk wheel floppy audio video cdrom games plugdev power netdev scanner users console lucaschess
Ciào Erich
On Sat, Nov 16, 2024 at 09:42:03AM +0000, E. Hoffmann wrote:
On Sat, 16 Nov 2024 09:30:21 +0100 tomas@tuxteam.de wrote:
On Sat, Nov 16, 2024 at 08:16:42AM +0000, E. Hoffmann wrote:
Hallo Gruppe.
(...)
Ist Dein regulärer User in der "scanner"-Gruppe?
Ja, ist er. Vielen Dank für die prompte Reaktion!
Hier noch mal meine groupliste:
disk wheel floppy audio video cdrom games plugdev power netdev scanner users console lucaschess
Hmpf. "Operation not permitted" ist ja die Text-Inkarnation von EPERM, was darauf hindeutet, das ein system call diesen Fehler zurückwirft.
Vielleicht lernt mensch was daraus, wenn Du den Aufruf unter strace laufen lässt? Weisst Du, wie das geht?
lg
On Sat, 16 Nov 2024 11:08:31 +0100 tomas@tuxteam.de wrote:
On Sat, Nov 16, 2024 at 09:42:03AM +0000, E. Hoffmann wrote:
On Sat, 16 Nov 2024 09:30:21 +0100 tomas@tuxteam.de wrote:
(...)
Vielleicht lernt mensch was daraus, wenn Du den Aufruf unter strace laufen lässt? Weisst Du, wie das geht?
Oh, nein, aber ich habe es gerade gegoogelt, nur komme ich mit der Unmenge an Informationen nicht klar, die bei den verschiedenen Optionen (-e , -i usw.) und mit dem flag -o erhalte ich eine Output-Datei mit über 30'000 Zeilen...
Cheers Erich
On Sat, Nov 16, 2024 at 10:26:21AM +0000, E. Hoffmann wrote:
On Sat, 16 Nov 2024 11:08:31 +0100 tomas@tuxteam.de wrote:
On Sat, Nov 16, 2024 at 09:42:03AM +0000, E. Hoffmann wrote:
On Sat, 16 Nov 2024 09:30:21 +0100 tomas@tuxteam.de wrote:
(...)
Vielleicht lernt mensch was daraus, wenn Du den Aufruf unter strace laufen lässt? Weisst Du, wie das geht?
Oh, nein, aber ich habe es gerade gegoogelt, nur komme ich mit der Unmenge an Informationen nicht klar, die bei den verschiedenen Optionen (-e , -i usw.) und mit dem flag -o erhalte ich eine Output-Datei mit über 30'000 Zeilen...
Ja, das produziert ziemlich viel Müll. Trick dabei ist, wie Du schon herausgefunden hast, -o <Datei>. Die andere wichtige Option (imE) ist -f, so dass Unterprozesse auch mitmachen dürfen. Manchmal löst so ein Kommando einen Rudel von Prozessen und die Schweinerei passiert irgendwo "da unten".
Mit -ff (eine Datei pro Prozess, mit PID im Namen) bin ich nie glücklich geworden. Für Menschen mit viel mehr Fokus als ich habe ;-)
Dann brauchst Du etwas, um die Datei anzugucken -- ein Editor, dem bei der Grösse nicht schwindlig wird (Vim oder Emacs tun es) oder einfach less.
Schliesslich die Feststellung, dass das, was Du suchst, ziemlich am Ende steht: nachdem das Programm mit EPERM eins auf die Finger gekriegt hat, torkelt es noch ein Bisschen, gibt beleidigt die Fehlermeldung aus, packt vielleicht ein- zwei Zelte ein und geht.
Du suchst also ein EPERM ziemlich am Ende, vielleicht ein paar hundert Zeilen davon entfernt. Und davor, den Syscall, der das "gemacht" hat (manchmal ist Syscall und Fehler nicht in derselben Zeile, insbesondere, wenn mehrere Prozesse durcheinanderschreien).
Das könnte z.B. ein Open sein. Der Pfad ist dann interessant. Oder es ist ein openat, dann muss mensch sich über das fd des Directories zu dessen Pfad hangeln. Oder...
Mit Dem Pfad kannst Du z.B. die Permissions der Datei angucken. Oder ob ein AppArmor oder SELinux-Fluch draufliegt. Oder.
Sowas in der Art :)
lg
On Sat, 16 Nov 2024 11:57:11 +0100 tomas@tuxteam.de wrote:
Danke, Thomas. Ich fürchte, da muss ich mich erst einarbeiten und -denken; das wird wohl ein bisschen dauern, und weiß noch nicht, wann ich dazu komme (immerhin kann ich die paar Scans auch als root machen) Bis dann - Erich
On Sat, Nov 16, 2024 at 10:26:21AM +0000, E. Hoffmann wrote:
On Sat, 16 Nov 2024 11:08:31 +0100 tomas@tuxteam.de wrote:
On Sat, Nov 16, 2024 at 09:42:03AM +0000, E. Hoffmann wrote:
On Sat, 16 Nov 2024 09:30:21 +0100 tomas@tuxteam.de wrote:
(...)
Vielleicht lernt mensch was daraus, wenn Du den Aufruf unter strace laufen lässt? Weisst Du, wie das geht?
Oh, nein, aber ich habe es gerade gegoogelt, nur komme ich mit der Unmenge an Informationen nicht klar, die bei den verschiedenen Optionen (-e , -i usw.) und mit dem flag -o erhalte ich eine Output-Datei mit über 30'000 Zeilen...
Ja, das produziert ziemlich viel Müll. Trick dabei ist, wie Du schon herausgefunden hast, -o <Datei>. Die andere wichtige Option (imE) ist -f, so dass Unterprozesse auch mitmachen dürfen. Manchmal löst so ein Kommando einen Rudel von Prozessen und die Schweinerei passiert irgendwo "da unten".
Mit -ff (eine Datei pro Prozess, mit PID im Namen) bin ich nie glücklich geworden. Für Menschen mit viel mehr Fokus als ich habe ;-)
Dann brauchst Du etwas, um die Datei anzugucken -- ein Editor, dem bei der Grösse nicht schwindlig wird (Vim oder Emacs tun es) oder einfach less.
Schliesslich die Feststellung, dass das, was Du suchst, ziemlich am Ende steht: nachdem das Programm mit EPERM eins auf die Finger gekriegt hat, torkelt es noch ein Bisschen, gibt beleidigt die Fehlermeldung aus, packt vielleicht ein- zwei Zelte ein und geht.
Du suchst also ein EPERM ziemlich am Ende, vielleicht ein paar hundert Zeilen davon entfernt. Und davor, den Syscall, der das "gemacht" hat (manchmal ist Syscall und Fehler nicht in derselben Zeile, insbesondere, wenn mehrere Prozesse durcheinanderschreien).
Das könnte z.B. ein Open sein. Der Pfad ist dann interessant. Oder es ist ein openat, dann muss mensch sich über das fd des Directories zu dessen Pfad hangeln. Oder...
Mit Dem Pfad kannst Du z.B. die Permissions der Datei angucken. Oder ob ein AppArmor oder SELinux-Fluch draufliegt. Oder.
Sowas in der Art :)
lg
t
Am Samstag, November 16, 2024 13:09 CET, schrieb "E. Hoffmann" h0ffmann@posteo.net:
[...] noch nicht, wann ich dazu komme (immerhin kann ich die paar Scans auch als root machen) Bis dann - Erich
Meine Frage wäre wie genau Du das als 'root' machst und ob Du das ggf. zuerst als 'root' versucht hast. Hintergrund: Programme als root laufen zu lassen ist nicht immer eine gute Idee. Manche Programme/Prozesse generieren Dateien falls sie noch nicht vorhanden sind (Konfigurationsdateien aber auch Sockets etc.). Wenn man ein Programm beim ersten Mal als root auf- ruft dann gehören diese Dateien natürlich root. Beim Aufruf als normal- sterblicher Benutzer können die dann nicht gelesen werden. Wenn das ein möglicher Grund ist kannst Du strace mit der Option --trace=%file aufrufen, das filtert dann die Systemcalls die Dateioperationen implementieren auf.
Gruss RalfD
On Sat, Nov 16, 2024 at 10:26:21AM +0000, E. Hoffmann wrote:
On Sat, 16 Nov 2024 11:08:31 +0100 tomas@tuxteam.de wrote:
On Sat, Nov 16, 2024 at 09:42:03AM +0000, E. Hoffmann wrote:
On Sat, 16 Nov 2024 09:30:21 +0100 tomas@tuxteam.de wrote:
(...)
Vielleicht lernt mensch was daraus, wenn Du den Aufruf unter strace laufen lässt? Weisst Du, wie das geht?
Oh, nein, aber ich habe es gerade gegoogelt, nur komme ich mit der Unmenge an Informationen nicht klar, die bei den verschiedenen Optionen (-e , -i usw.) und mit dem flag -o erhalte ich eine Output-Datei mit über 30'000 Zeilen...
Ja, das produziert ziemlich viel Müll. Trick dabei ist, wie Du schon herausgefunden hast, -o <Datei>. Die andere wichtige Option (imE) ist -f, so dass Unterprozesse auch mitmachen dürfen. Manchmal löst so ein Kommando einen Rudel von Prozessen und die Schweinerei passiert irgendwo "da unten".
Mit -ff (eine Datei pro Prozess, mit PID im Namen) bin ich nie glücklich geworden. Für Menschen mit viel mehr Fokus als ich habe ;-)
Dann brauchst Du etwas, um die Datei anzugucken -- ein Editor, dem bei der Grösse nicht schwindlig wird (Vim oder Emacs tun es) oder einfach less.
Schliesslich die Feststellung, dass das, was Du suchst, ziemlich am Ende steht: nachdem das Programm mit EPERM eins auf die Finger gekriegt hat, torkelt es noch ein Bisschen, gibt beleidigt die Fehlermeldung aus, packt vielleicht ein- zwei Zelte ein und geht.
Du suchst also ein EPERM ziemlich am Ende, vielleicht ein paar hundert Zeilen davon entfernt. Und davor, den Syscall, der das "gemacht" hat (manchmal ist Syscall und Fehler nicht in derselben Zeile, insbesondere, wenn mehrere Prozesse durcheinanderschreien).
Das könnte z.B. ein Open sein. Der Pfad ist dann interessant. Oder es ist ein openat, dann muss mensch sich über das fd des Directories zu dessen Pfad hangeln. Oder...
Mit Dem Pfad kannst Du z.B. die Permissions der Datei angucken. Oder ob ein AppArmor oder SELinux-Fluch draufliegt. Oder.
Sowas in der Art :)
lg
t
-- E. Hoffmann h0ffmann@posteo.net
On Sat, 16 Nov 2024 13:32:05 +0100 "Ralf Mattes" r.mattes@mh-freiburg.de wrote:
Am Samstag, November 16, 2024 13:09 CET, schrieb "E. Hoffmann" h0ffmann@posteo.net:
[...] noch nicht, wann ich dazu komme (immerhin kann ich die paar Scans auch als root machen) Bis dann - Erich
Meine Frage wäre wie genau Du das als 'root' machst und ob Du das ggf. zuerst als 'root' versucht hast. Hintergrund: Programme als root laufen zu lassen ist nicht immer eine gute Idee. Manche Programme/Prozesse generieren Dateien (...)
Leuchtet ein. Wenn ich mich recht erinnere, habe ich das auch anfangs gar nicht gemacht, sondern erst, als der normal-user gescheitert war.
Würde es denn etwas helfen, wenn ich xsane erst deinstalliere, den Computer neu starte, dann wieder installiere und als user es nochmal versuche?
Wenn das ein möglicher Grund ist kannst Du strace mit der Option --trace=%file aufrufen, das filtert dann die Systemcalls die Dateioperationen implementieren auf.
Das habe ich getan, weiß aber leider (noch) nicht, wie ich mit den 10'000 Zeilen umgehen soll...
Gruß Erich
Gruss RalfD
On Sat, Nov 16, 2024 at 10:26:21AM +0000, E. Hoffmann wrote:
On Sat, 16 Nov 2024 11:08:31 +0100 tomas@tuxteam.de wrote:
On Sat, Nov 16, 2024 at 09:42:03AM +0000, E. Hoffmann wrote:
On Sat, 16 Nov 2024 09:30:21 +0100 tomas@tuxteam.de wrote:
(...)
Vielleicht lernt mensch was daraus, wenn Du den Aufruf unter strace laufen lässt? Weisst Du, wie das geht?
Oh, nein, aber ich habe es gerade gegoogelt, nur komme ich mit der Unmenge an Informationen nicht klar, die bei den verschiedenen Optionen (-e , -i usw.) und mit dem flag -o erhalte ich eine Output-Datei mit über 30'000 Zeilen...
Ja, das produziert ziemlich viel Müll. Trick dabei ist, wie Du schon herausgefunden hast, -o <Datei>. Die andere wichtige Option (imE) ist -f, so dass Unterprozesse auch mitmachen dürfen. Manchmal löst so ein Kommando einen Rudel von Prozessen und die Schweinerei passiert irgendwo "da unten".
Mit -ff (eine Datei pro Prozess, mit PID im Namen) bin ich nie glücklich geworden. Für Menschen mit viel mehr Fokus als ich habe ;-)
Dann brauchst Du etwas, um die Datei anzugucken -- ein Editor, dem bei der Grösse nicht schwindlig wird (Vim oder Emacs tun es) oder einfach less.
Schliesslich die Feststellung, dass das, was Du suchst, ziemlich am Ende steht: nachdem das Programm mit EPERM eins auf die Finger gekriegt hat, torkelt es noch ein Bisschen, gibt beleidigt die Fehlermeldung aus, packt vielleicht ein- zwei Zelte ein und geht.
Du suchst also ein EPERM ziemlich am Ende, vielleicht ein paar hundert Zeilen davon entfernt. Und davor, den Syscall, der das "gemacht" hat (manchmal ist Syscall und Fehler nicht in derselben Zeile, insbesondere, wenn mehrere Prozesse durcheinanderschreien).
Das könnte z.B. ein Open sein. Der Pfad ist dann interessant. Oder es ist ein openat, dann muss mensch sich über das fd des Directories zu dessen Pfad hangeln. Oder...
Mit Dem Pfad kannst Du z.B. die Permissions der Datei angucken. Oder ob ein AppArmor oder SELinux-Fluch draufliegt. Oder.
Sowas in der Art :)
lg
t
-- E. Hoffmann h0ffmann@posteo.net
-- Ralf Mattes
Hochschule für Musik Freiburg Projektleitung HISinOne Mendelssohn-Bartholdy Platz 1, D-79102 Freiburg http://www.mh-freiburg.de
Am Samstag, November 16, 2024 15:54 CET, schrieb "E. Hoffmann" h0ffmann@posteo.net:
Leuchtet ein. Wenn ich mich recht erinnere, habe ich das auch anfangs gar nicht gemacht, sondern erst, als der normal-user gescheitert war.
Würde es denn etwas helfen, wenn ich xsane erst deinstalliere, den Computer neu starte, dann wieder installiere und als user es nochmal versuche?
Mit an Sicherheit grenzender Wahrscheinlickeit - nein.
Wenn das ein möglicher Grund ist kannst Du strace mit der Option --trace=%file aufrufen, das filtert dann die Systemcalls die Dateioperationen implementieren auf.
Das habe ich getan, weiß aber leider (noch) nicht, wie ich mit den 10'000 Zeilen umgehen soll...
Wir Tomas schon schrieb: grep EPERM taradie.txt
Gruss RalfD
P.S.: bitte an die Liste antworten und nicht mich in's CC sonst bekomme ich alles zweimal.
Gruß Erich
Gruss RalfD
On Sat, Nov 16, 2024 at 10:26:21AM +0000, E. Hoffmann wrote:
On Sat, 16 Nov 2024 11:08:31 +0100 tomas@tuxteam.de wrote:
On Sat, Nov 16, 2024 at 09:42:03AM +0000, E. Hoffmann wrote: > On Sat, 16 Nov 2024 09:30:21 +0100 > tomas@tuxteam.de wrote: (...)
Vielleicht lernt mensch was daraus, wenn Du den Aufruf unter strace laufen lässt? Weisst Du, wie das geht?
Oh, nein, aber ich habe es gerade gegoogelt, nur komme ich mit der Unmenge an Informationen nicht klar, die bei den verschiedenen Optionen (-e , -i usw.) und mit dem flag -o erhalte ich eine Output-Datei mit über 30'000 Zeilen...
Ja, das produziert ziemlich viel Müll. Trick dabei ist, wie Du schon herausgefunden hast, -o <Datei>. Die andere wichtige Option (imE) ist -f, so dass Unterprozesse auch mitmachen dürfen. Manchmal löst so ein Kommando einen Rudel von Prozessen und die Schweinerei passiert irgendwo "da unten".
Mit -ff (eine Datei pro Prozess, mit PID im Namen) bin ich nie glücklich geworden. Für Menschen mit viel mehr Fokus als ich habe ;-)
Dann brauchst Du etwas, um die Datei anzugucken -- ein Editor, dem bei der Grösse nicht schwindlig wird (Vim oder Emacs tun es) oder einfach less.
Schliesslich die Feststellung, dass das, was Du suchst, ziemlich am Ende steht: nachdem das Programm mit EPERM eins auf die Finger gekriegt hat, torkelt es noch ein Bisschen, gibt beleidigt die Fehlermeldung aus, packt vielleicht ein- zwei Zelte ein und geht.
Du suchst also ein EPERM ziemlich am Ende, vielleicht ein paar hundert Zeilen davon entfernt. Und davor, den Syscall, der das "gemacht" hat (manchmal ist Syscall und Fehler nicht in derselben Zeile, insbesondere, wenn mehrere Prozesse durcheinanderschreien).
Das könnte z.B. ein Open sein. Der Pfad ist dann interessant. Oder es ist ein openat, dann muss mensch sich über das fd des Directories zu dessen Pfad hangeln. Oder...
Mit Dem Pfad kannst Du z.B. die Permissions der Datei angucken. Oder ob ein AppArmor oder SELinux-Fluch draufliegt. Oder.
Sowas in der Art :)
lg
t
-- E. Hoffmann h0ffmann@posteo.net
-- Ralf Mattes
Hochschule für Musik Freiburg Projektleitung HISinOne Mendelssohn-Bartholdy Platz 1, D-79102 Freiburg http://www.mh-freiburg.de
-- E. Hoffmann h0ffmann@posteo.net
On Sat, 16 Nov 2024 16:13:51 +0100 "Ralf Mattes" r.mattes@mh-freiburg.de wrote:
(...)
Wenn das ein möglicher Grund ist kannst Du strace mit der Option --trace=%file aufrufen, das filtert dann die Systemcalls die Dateioperationen implementieren auf.
Das habe ich getan, weiß aber leider (noch) nicht, wie ich mit den 10'000 Zeilen umgehen soll...
Wir Tomas schon schrieb: grep EPERM taradie.txt
Ahem Entschuldigung hier ist die Zeile:
openat(AT_FDCWD, "/usr/share/icons/elementary-xfce/actions/22/gtk-cancel.png", O_RDONLY|O_NOATIME|O_CLOEXEC) = -1 EPERM (Die Operation ist nicht erlaubt)
Dieses gtk-cancel.png ist ein symlink ; ls -l gtk-cancel.png:
lrwxrwxrwx 1 root root 16 Okt 20 14:34 gtk-cancel.png -> process-stop.png
-rw-r--r-- 1 root root 1305 Okt 19 23:29 process-stop.png
(ich habe mal probehalber für 1 Minute allen rwx auf process-stop.png gewährt, aber das brachte erwartungsgemäß nix es ist ja auch ein png, das alle lesen können)
vielen Dank für Deine Mühe!
Erich
Gruss RalfD
P.S.: bitte an die Liste antworten und nicht mich in's CC sonst bekomme ich alles zweimal.
Gern, auf jeden Fall. Es ist jetzt halt nur so, dass auch ich alle Mails doppelt bekomme, einmal an mich selber, einmal an die Gruppe (mit Ausnahme dieses Mails). Da hielt ich das für guten Stil, wollte "brav" sein, habe auf "Antwort an Alle" geklickt und unterlasse das natürlich geflissentlich ...
Gruß Erich
Gruss RalfD
On Sat, Nov 16, 2024 at 10:26:21AM +0000, E. Hoffmann wrote:
On Sat, 16 Nov 2024 11:08:31 +0100 tomas@tuxteam.de wrote:
> On Sat, Nov 16, 2024 at 09:42:03AM +0000, E. Hoffmann wrote: > > On Sat, 16 Nov 2024 09:30:21 +0100 > > tomas@tuxteam.de wrote: > (...) > > Vielleicht lernt mensch was daraus, wenn Du den Aufruf unter strace laufen > lässt? Weisst Du, wie das geht?
Oh, nein, aber ich habe es gerade gegoogelt, nur komme ich mit der Unmenge an Informationen nicht klar, die bei den verschiedenen Optionen (-e , -i usw.) und mit dem flag -o erhalte ich eine Output-Datei mit über 30'000 Zeilen...
Ja, das produziert ziemlich viel Müll. Trick dabei ist, wie Du schon herausgefunden hast, -o <Datei>. Die andere wichtige Option (imE) ist -f, so dass Unterprozesse auch mitmachen dürfen. Manchmal löst so ein Kommando einen Rudel von Prozessen und die Schweinerei passiert irgendwo "da unten".
Mit -ff (eine Datei pro Prozess, mit PID im Namen) bin ich nie glücklich geworden. Für Menschen mit viel mehr Fokus als ich habe ;-)
Dann brauchst Du etwas, um die Datei anzugucken -- ein Editor, dem bei der Grösse nicht schwindlig wird (Vim oder Emacs tun es) oder einfach less.
Schliesslich die Feststellung, dass das, was Du suchst, ziemlich am Ende steht: nachdem das Programm mit EPERM eins auf die Finger gekriegt hat, torkelt es noch ein Bisschen, gibt beleidigt die Fehlermeldung aus, packt vielleicht ein- zwei Zelte ein und geht.
Du suchst also ein EPERM ziemlich am Ende, vielleicht ein paar hundert Zeilen davon entfernt. Und davor, den Syscall, der das "gemacht" hat (manchmal ist Syscall und Fehler nicht in derselben Zeile, insbesondere, wenn mehrere Prozesse durcheinanderschreien).
Das könnte z.B. ein Open sein. Der Pfad ist dann interessant. Oder es ist ein openat, dann muss mensch sich über das fd des Directories zu dessen Pfad hangeln. Oder...
Mit Dem Pfad kannst Du z.B. die Permissions der Datei angucken. Oder ob ein AppArmor oder SELinux-Fluch draufliegt. Oder.
Sowas in der Art :)
lg
t
-- E. Hoffmann h0ffmann@posteo.net
-- Ralf Mattes
Hochschule für Musik Freiburg Projektleitung HISinOne Mendelssohn-Bartholdy Platz 1, D-79102 Freiburg http://www.mh-freiburg.de
-- E. Hoffmann h0ffmann@posteo.net
-- Ralf Mattes
Hochschule für Musik Freiburg Projektleitung HISinOne Mendelssohn-Bartholdy Platz 1, D-79102 Freiburg http://www.mh-freiburg.de
-- E. Hoffmann h0ffmann@posteo.net
On Sat, Nov 16, 2024 at 04:27:17PM +0000, E. Hoffmann wrote:
On Sat, 16 Nov 2024 16:13:51 +0100 "Ralf Mattes" r.mattes@mh-freiburg.de wrote:
(...)
Wenn das ein möglicher Grund ist kannst Du strace mit der Option --trace=%file aufrufen, das filtert dann die Systemcalls die Dateioperationen implementieren auf.
Das habe ich getan, weiß aber leider (noch) nicht, wie ich mit den 10'000 Zeilen umgehen soll...
Wir Tomas schon schrieb: grep EPERM taradie.txt
Ahem Entschuldigung hier ist die Zeile:
openat(AT_FDCWD, "/usr/share/icons/elementary-xfce/actions/22/gtk-cancel.png", O_RDONLY|O_NOATIME|O_CLOEXEC) = -1 EPERM (Die Operation ist nicht erlaubt)
Dieses gtk-cancel.png ist ein symlink ; ls -l gtk-cancel.png:
lrwxrwxrwx 1 root root 16 Okt 20 14:34 gtk-cancel.png -> process-stop.png
-rw-r--r-- 1 root root 1305 Okt 19 23:29 process-stop.png
(ich habe mal probehalber für 1 Minute allen rwx auf process-stop.png gewährt, aber das brachte erwartungsgemäß nix es ist ja auch ein png, das alle lesen können)
Das ist... bizarr. Zumal process-stop.png selbst für alle lesbar ist.
Ist eins von den Pfadelementen (/usr, /usr/share, /usr/share/icons...) evtl. nicht world readable?
lg
On Sat, 16 Nov 2024 17:35:27 +0100 tomas@tuxteam.de wrote:
(...)
Das ist... bizarr. Zumal process-stop.png selbst für alle lesbar ist.
Ist eins von den Pfadelementen (/usr, /usr/share, /usr/share/icons...) evtl. nicht world readable?
Nein, alle für alle lesbar... Erich
Am Samstag, November 16, 2024 17:27 CET, schrieb "E. Hoffmann" h0ffmann@posteo.net:
Ahem Entschuldigung hier ist die Zeile:
openat(AT_FDCWD, "/usr/share/icons/elementary-xfce/actions/22/gtk-cancel.png", O_RDONLY|O_NOATIME|O_CLOEXEC) = -1 EPERM (Die Operation ist nicht erlaubt)
Dieses gtk-cancel.png ist ein symlink ; ls -l gtk-cancel.png:
lrwxrwxrwx 1 root root 16 Okt 20 14:34 gtk-cancel.png -> process-stop.png
Und bricht das Programm wirklich nach diesem Fehler ab?
(ich habe mal probehalber für 1 Minute allen rwx auf process-stop.png gewährt, aber das brachte erwartungsgemäß nix es ist ja auch ein png, das alle lesen können)
Bitte, bitte - nie machen! Eine executable Image-Datei macht keinen Sinn. Ich frage mich ob das nicht eher ein 'red herring' ist. Wie ist denn Dein Scanner angeschlossen? USB? Dann würde ich mal nachsehen ob das USB-Device wirklich für die Gruppe scanner lesbar ist. Das macht oft eine udev-Regel und die greift (zumindest früher) gerne mal nicht wenn das Device nach dem Booten angeschlossen wurde.
Gruss RalfD
vielen Dank für Deine Mühe!
Erich
Gruss RalfD
P.S.: bitte an die Liste antworten und nicht mich in's CC sonst bekomme ich alles zweimal.
Gern, auf jeden Fall. Es ist jetzt halt nur so, dass auch ich alle Mails doppelt bekomme, einmal an mich selber, einmal an die Gruppe (mit Ausnahme dieses Mails). Da hielt ich das für guten Stil, wollte "brav" sein, habe auf "Antwort an Alle" geklickt und unterlasse das natürlich geflissentlich ...
Gruß Erich
Gruss RalfD
On Sat, Nov 16, 2024 at 10:26:21AM +0000, E. Hoffmann wrote: > On Sat, 16 Nov 2024 11:08:31 +0100 > tomas@tuxteam.de wrote: > > > On Sat, Nov 16, 2024 at 09:42:03AM +0000, E. Hoffmann wrote: > > > On Sat, 16 Nov 2024 09:30:21 +0100 > > > tomas@tuxteam.de wrote: > > (...) > > > > Vielleicht lernt mensch was daraus, wenn Du den Aufruf unter strace laufen > > lässt? Weisst Du, wie das geht? > > Oh, nein, aber ich habe es gerade gegoogelt, nur komme ich mit der Unmenge an Informationen > nicht klar, die bei den verschiedenen Optionen (-e , -i usw.) und mit dem > flag -o erhalte ich eine Output-Datei mit über 30'000 Zeilen...
Ja, das produziert ziemlich viel Müll. Trick dabei ist, wie Du schon herausgefunden hast, -o <Datei>. Die andere wichtige Option (imE) ist -f, so dass Unterprozesse auch mitmachen dürfen. Manchmal löst so ein Kommando einen Rudel von Prozessen und die Schweinerei passiert irgendwo "da unten".
Mit -ff (eine Datei pro Prozess, mit PID im Namen) bin ich nie glücklich geworden. Für Menschen mit viel mehr Fokus als ich habe ;-)
Dann brauchst Du etwas, um die Datei anzugucken -- ein Editor, dem bei der Grösse nicht schwindlig wird (Vim oder Emacs tun es) oder einfach less.
Schliesslich die Feststellung, dass das, was Du suchst, ziemlich am Ende steht: nachdem das Programm mit EPERM eins auf die Finger gekriegt hat, torkelt es noch ein Bisschen, gibt beleidigt die Fehlermeldung aus, packt vielleicht ein- zwei Zelte ein und geht.
Du suchst also ein EPERM ziemlich am Ende, vielleicht ein paar hundert Zeilen davon entfernt. Und davor, den Syscall, der das "gemacht" hat (manchmal ist Syscall und Fehler nicht in derselben Zeile, insbesondere, wenn mehrere Prozesse durcheinanderschreien).
Das könnte z.B. ein Open sein. Der Pfad ist dann interessant. Oder es ist ein openat, dann muss mensch sich über das fd des Directories zu dessen Pfad hangeln. Oder...
Mit Dem Pfad kannst Du z.B. die Permissions der Datei angucken. Oder ob ein AppArmor oder SELinux-Fluch draufliegt. Oder.
Sowas in der Art :)
lg
t
-- E. Hoffmann h0ffmann@posteo.net
-- Ralf Mattes
Hochschule für Musik Freiburg Projektleitung HISinOne Mendelssohn-Bartholdy Platz 1, D-79102 Freiburg http://www.mh-freiburg.de
-- E. Hoffmann h0ffmann@posteo.net
-- Ralf Mattes
Hochschule für Musik Freiburg Projektleitung HISinOne Mendelssohn-Bartholdy Platz 1, D-79102 Freiburg http://www.mh-freiburg.de
-- E. Hoffmann h0ffmann@posteo.net
On Sat, 16 Nov 2024 20:56:18 +0100 "Ralf Mattes" r.mattes@mh-freiburg.de wrote:
(...)
(Ich lasse mal das Erste weg, das ist natürlich alles richtig, was Du schreibst)
Der Tipp mit dem USB hat's gebracht.
Ich frage mich ob das nicht eher ein 'red herring' ist. Wie ist denn Dein Scanner angeschlossen? USB? Dann würde ich mal nachsehen ob das USB-Device wirklich für die Gruppe scanner lesbar ist. Das macht oft eine udev-Regel und die greift (zumindest früher) gerne mal nicht wenn das Device nach dem Booten angeschlossen wurde.
Eine Suche wurde fündig hier ⇒ https://wiki.ubuntuusers.de/Scanner/
In /etc/udev/rules.d/40-libsane.rules soll ein Eintrag für den Scanner stehen. Bei Slackware Current ist es 80-libsane.rules, und der Eintrag ist da:
lsusb ergibt :
Bus 003 Device 006: ID 04a9:1913 Canon, Inc. CanoScan LiDE 300
libsane-rules:
# Canon LiDE 300 | Canon CanoScan LiDE 300 ATTR{idVendor}=="04a9", ATTR{idProduct}=="1913", MODE="0660", GROUP="lp", ENV{libsane_matched}="yes"
Das scheint zu stimmen.
Dann gibt es eine Zeile in /etc/udev/rules.d/52-udev-default.rules:
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", MODE="0664"
die nach "0666" geändert werden soll. Habe ich gemacht; aber dann habe ich noch gefunden
/etc/udev/rules.d/00-usb-permissions.rules
und auch hier die permissions von 0660 auf 0666 gesetzt:
SUBSYSTEM=="usb", MODE="0666", GROUP="plugdev"
Seitdem nach Neustart lauft alles problemlos. (Anscheinend. Hoffentlich habe ich nicht noch sonstige Probleme erzeugt.)
Ja ich kann mich nur bedanken für Deine und Eure Mühe!
Das war wirklich alles sehr förderlich und interessant. Ich bin sonst ja nur so'n "User" …
Grüße vom Erich
Gruss RalfD
vielen Dank für Deine Mühe!
Erich
Gruss RalfD
P.S.: bitte an die Liste antworten und nicht mich in's CC sonst bekomme ich alles zweimal.
Gern, auf jeden Fall. Es ist jetzt halt nur so, dass auch ich alle Mails doppelt bekomme, einmal an mich selber, einmal an die Gruppe (mit Ausnahme dieses Mails). Da hielt ich das für guten Stil, wollte "brav" sein, habe auf "Antwort an Alle" geklickt und unterlasse das natürlich geflissentlich ...
Gruß Erich
Gruss RalfD
> On Sat, Nov 16, 2024 at 10:26:21AM +0000, E. Hoffmann wrote: > > On Sat, 16 Nov 2024 11:08:31 +0100 > > tomas@tuxteam.de wrote: > > > > > On Sat, Nov 16, 2024 at 09:42:03AM +0000, E. Hoffmann wrote: > > > > On Sat, 16 Nov 2024 09:30:21 +0100 > > > > tomas@tuxteam.de wrote: > > > (...) > > > > > > Vielleicht lernt mensch was daraus, wenn Du den Aufruf unter strace laufen > > > lässt? Weisst Du, wie das geht? > > > > Oh, nein, aber ich habe es gerade gegoogelt, nur komme ich mit der Unmenge an Informationen > > nicht klar, die bei den verschiedenen Optionen (-e , -i usw.) und mit dem > > flag -o erhalte ich eine Output-Datei mit über 30'000 Zeilen... > > Ja, das produziert ziemlich viel Müll. Trick dabei ist, wie Du schon > herausgefunden hast, -o <Datei>. Die andere wichtige Option (imE) ist > -f, so dass Unterprozesse auch mitmachen dürfen. Manchmal löst so ein > Kommando einen Rudel von Prozessen und die Schweinerei passiert irgendwo > "da unten". > > Mit -ff (eine Datei pro Prozess, mit PID im Namen) bin ich nie glücklich > geworden. Für Menschen mit viel mehr Fokus als ich habe ;-) > > Dann brauchst Du etwas, um die Datei anzugucken -- ein Editor, dem bei > der Grösse nicht schwindlig wird (Vim oder Emacs tun es) oder einfach > less. > > Schliesslich die Feststellung, dass das, was Du suchst, ziemlich am > Ende steht: nachdem das Programm mit EPERM eins auf die Finger gekriegt > hat, torkelt es noch ein Bisschen, gibt beleidigt die Fehlermeldung > aus, packt vielleicht ein- zwei Zelte ein und geht. > > Du suchst also ein EPERM ziemlich am Ende, vielleicht ein paar hundert > Zeilen davon entfernt. Und davor, den Syscall, der das "gemacht" hat > (manchmal ist Syscall und Fehler nicht in derselben Zeile, insbesondere, > wenn mehrere Prozesse durcheinanderschreien). > > Das könnte z.B. ein Open sein. Der Pfad ist dann interessant. Oder es > ist ein openat, dann muss mensch sich über das fd des Directories zu > dessen Pfad hangeln. Oder... > > Mit Dem Pfad kannst Du z.B. die Permissions der Datei angucken. Oder > ob ein AppArmor oder SELinux-Fluch draufliegt. Oder. > > Sowas in der Art :) > > lg > -- > t
-- E. Hoffmann h0ffmann@posteo.net
-- Ralf Mattes
Hochschule für Musik Freiburg Projektleitung HISinOne Mendelssohn-Bartholdy Platz 1, D-79102 Freiburg http://www.mh-freiburg.de
-- E. Hoffmann h0ffmann@posteo.net
-- Ralf Mattes
Hochschule für Musik Freiburg Projektleitung HISinOne Mendelssohn-Bartholdy Platz 1, D-79102 Freiburg http://www.mh-freiburg.de
-- E. Hoffmann h0ffmann@posteo.net
-- Ralf Mattes
Hochschule für Musik Freiburg Projektleitung HISinOne Mendelssohn-Bartholdy Platz 1, D-79102 Freiburg http://www.mh-freiburg.de
-- E. Hoffmann h0ffmann@posteo.net
Hallo zusammen,
[...] lsusb ergibt :
Bus 003 Device 006: ID 04a9:1913 Canon, Inc. CanoScan LiDE 300
libsane-rules:
# Canon LiDE 300 | Canon CanoScan LiDE 300 ATTR{idVendor}=="04a9", ATTR{idProduct}=="1913", MODE="0660", GROUP="lp", ENV{libsane_matched}="yes"
Hmm, da wird der Gruppe 'lp' Zugriff gewährt. Bist Du in der Gruppe 'lp'? (einfach im Termninal 'id' eintippen).
Das scheint zu stimmen.
Dann gibt es eine Zeile in /etc/udev/rules.d/52-udev-default.rules:
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", MODE="0664"
die nach "0666" geändert werden soll. Habe ich gemacht;
Damit erlaubst ALLEN Lese- und Schreibrechte auf das Gerät. Kann man machen, will man das aber?
aber dann habe ich noch gefunden
/etc/udev/rules.d/00-usb-permissions.rules
und auch hier die permissions von 0660 auf 0666 gesetzt:
SUBSYSTEM=="usb", MODE="0666", GROUP="plugdev"
Siehe oben - Lese- und Schreibrechte für alle. Ich würde eher versuchen in der "richtigen" Gruppe zu sein.
Aber schön wenn's läuft. Gruss & schönes Wochenende RalfD
-
E. Hoffmann -
Mathias Behrle -
Ralf Mattes -
tomas＠tuxteam.de