staging.inyokaproject.org

MPW schrieb:

Ich hab es einfach als Warnbox hinzugefügt.

Danke dafür! Ich habe noch etwas an der Formatierung der Warnbox geschraubt. Ich denke, so passt es.

Gruß Justin Time

Diese Anleitung funktioniert leider so nicht mehr. Ich habe sie mit xenial ausprobiert, aber kann saned nicht mit systemd vereinen. Wenn man es versucht mit systemd zu starten, steht nur, das saned maskiert ist, was auch immer das genau bedeutet...

Hi!

Unter 16.04 scheint es Probleme mit systemctl zu geben, siehe 1577137.

Um saned unter systemd zu verwenden, braucht es zwei weitere Config-Dateien, siehe man-Datei:

SYSTEMD CONFIGURATION
 
        for systemd we need to add 2 configuation files in /etc/systemd/system.
 
        The first file we need to add here is called  saned.socket.   It  shall
        have the following contents:
 
               [Unit]
               Description=saned incoming socket
 
               [Socket]
               ListenStream=6566
               Accept=yes
               MaxConnections=1
 
               [Install]
               WantedBy=sockets.target
 
        The  second  file  to  be  added  is  saned@.service with the following
        contents:
 
               [Unit]
               Description=Scanner Service
               Requires=saned.socket
 
               [Service]
               ExecStart=/usr/sbin/saned
               User=saned
               Group=saned
               StandardInput=null
               StandardOutput=syslog
               StandardError=syslog
               # Environment=SANE_CONFIG_DIR=/etc/sane.d SANE_DEBUG_DLL=255
 
        Is  you  need  to  set  an  environment   variable   for   saned   like
        SANE_CONFIG_DIR  you will have to remove the # on the last line and set
        the  variable  appropriately.   Multiple  variables  can  be   set   by
        separating the assignments by spaces as shown in the example above.
 

saned sei dann zwar immernoch "maskiert", aber scanimage -L findet die Netzwerkscanner. Ich forsch da noch mal weiter...

so long
hank

Hi!

So, nach etwas Gebastel läuft das jetzt auch unter 16.04, sowohl als Server (und 14.04-Rechner als Client), als auch als Client (14.04 als Server). Allerdings habe ich es noch nicht mit zwei 16.04-Rechnern versuchen können, aber wenn man sowohl die Server- als auch die Client-Dateien bearbeitet, kann man unter 16.04 auch über das Net-Backend auf die Scanner zugreifen, (was z.B. für SwingSane notwendig ist, wenn man es ohne Client verwenden will, dazu aber später mehr).

so long
hank

Hi!

Die "radikalste" Lösung ist, systemd für saned gar nicht zu benutzen. Dazu muss man saned-Dateien die Dateien in /lib/systemd/system/, als da wären saned.service, saned.socket und saned@.service löschen oder zumindest umbenennen. Dann funktioniert alles wie vorher. Interessanterweise ist saned.service eine Verknüpfung mit /dev/null 🤣 , so ganz sauber scheint das ehe nicht gewesen zu sein...

Ich schreib das die Tage nochmal ins Wiki...

so long
hank

Hallo,

Dann funktioniert alles wie vorher.

Aber auch nur bis zu nächsten Aktualisierung des Pakets - dann würden die Dateien in /lib/systemd/system/ nämlich neu angelegt ☺

Gruß, noisefloor

Hi!

noisefloor schrieb:

Aber auch nur bis zu nächsten Aktualisierung des Pakets - dann würden die Dateien in /lib/systemd/system/ nämlich neu angelegt ☺

Naja, oder der Bug ist mit der Aktualisierung dann beseitigt 😉.

Ist wie bei der beschriebenen udev-Regel-Änderung, und ich glaube, wer saned eingerichtet bekommt, kann das dann auch nochmal wiederholen, zumal wenn es im Wiki vermerkt ist. (Was ja nicht das größte Problem sein sollte.. 🤓 )

Danke für den Hinweis!

so long
hank

Hi!

Nachdem ich jetzt etwas tiefer in die Materie eingestiegen bin, wird mir langsam klarer, wie saned unter systemd funktioniert. Die beiden in der manpage zu saned beschriebenen Dateien sind in dem sane-utils-Paket bereits enthalten, erscheinen allerdings nicht in /etc/systemd/system, sondern in /lib/systemd/system. Die zusätzlichen schaden zwar nicht, sind aber auch nicht wirklich notwendig. Wenn saned ansonsten vernünftig konfiguriert ist, funktioniert das, entweder mit den "neuen", oder auch ohne sie.

Der entscheidende Unterschied in 16.04 mit systemd ist, dass saned nicht "explizit" gestartet werden muss bzw. kann.

Das Auslesen des socket-Status mit dem Befehl

sudo systemtctl status saned.socket 

zeigt:

● saned.socket - saned incoming socket
   Loaded: loaded (/lib/systemd/system/saned.socket; enabled; vendor preset: enabled)
   Active: active (listening) since Mi 2016-05-25 16:46:07 CEST; 2h 17min ago
   Listen: [::]:6566 (Stream)
 Accepted: 0; Connected: 0

Mai 25 16:46:07 rechenername systemd[1]: Listening on saned incoming socket.

Der socket lauscht also erstmal nur am Port 6566, um dann reagieren zu können.

Erst wenn eine Anwendung saned verwenden möchte, also z.B. Xsane gestartet wurde, wird saned tatsächlich aktiviert, in der Systemüberwachung taucht dann auch ein saned-Prozess auf - Voraussetzung ein ansonsten wie im Artikel beschrieben Konfiguration von saned. Was geschieht, macht der Befehl

sudo systemtctl status saned@*.service 

klarer: (wichtig ist das * im Befehl, weil nur so der tatsächliche Service gefunden wird, mit Angabe, woher er kommt, und über welchen Port er dann abgewickelt wird!)

● saned@0-192.168.xxx.xx:6566-192.168.xxx.xx:38046.service - Scanner Service (192.168.xxx.xx:38046)
   Loaded: loaded (/lib/systemd/system/saned@.service; indirect; vendor preset: enabled)
   Active: active (running) since Mi 2016-05-25 18:47:01 CEST; 6min ago
 Main PID: 2181 (saned)
   CGroup: /system.slice/system-saned.slice/saned@0-192.168.xxx.xx:6566-192.168.xxx.xx:38046.service
           └─2181 /usr/sbin/saned

Mai 25 18:47:01 rechnername systemd[1]: Started Scanner Service (192.168.xxx.xx:38046).
Mai 25 18:47:01 rechnername saned[2181]: saned (AF-indep+IPv6+systemd) from sane-backends 1.0.25git starting up
Mai 25 18:47:01 rechnername saned[2181]: check_host: access by remote host: ::ffff:192.168.xxx.xx
Mai 25 18:47:01 rechnername saned[2181]: init: access granted to saned-user@::ffff:192.168.xxx.xx

saned[2181]: saned (AF-indep+IPv6+systemd) from sane-backends 1.0.25git starting up zeigt dass tatsächlich systemd verwendet wird.

Deshalb wird ist ein manueller Start von saned nicht nur überflüssig (und damit auch die Konfiguration von /etc/default/saned) sondern liefert etwa für sudo service saned (re)start das Ergebnisse "Failed to (re)start saned.service: Unit saned.service is masked". Ein Restart ist mit systemctl restart saned@*.service (man beachte auch hier das *!), möglich, entsprechend auch ein Stoppen (siehe auch systemctl), aber ein Start in diesem Fall eben nur durch eine Anforderung von einem Programm (auch scanimage -L lässt saned starten, aber sobald die Scanner angezeigt sind, wird saned dann schnell wieder beendet, weil nicht mehr benötigt)

saned.service ist, wie oben schon mal bemerkt, ein Link auf /dev/null, also ins Nirvana:

systemctl status saned.service 

● saned.service
   Loaded: masked (/dev/null; bad)
   Active: inactive (dead)

Warum das nötig, ist mir allerdings noch nicht ganz klar. Wenn ich es richtig verstanden habe, muss, wenn in einer Socket-Datei Accept=yes verwendet wird, die dazugehörige Service-Datei mit dem selben Namen und angehängtem @ verwendet werden, die ohne ist dann "sinnlos"; deshalb wohl die Umleitung ins nichts (in /lib/systemd findet man einige Fälle von solchen Verlinkungen auf /dev/null). Das ist mir aber momentan noch etwas zu hoch ... 😇

Es gibt allerdings auch Anwendungen (z.B. Baustelle/SwingSane) die versuchen, einen laufendes saned zu finden, ohne eine "Startaufforderung" zu schicken. Da muss dann "nachgeholfen" werden, indem die Serverdaten explizit angegeben werden, oder auf dem Server die systemd-Verwendung unterbunden wird (siehe drei posts weiter oben.)

Also werde ich das mit den neuen Dateien aus dem Wiki wieder rausnehmen, und dafür diese Erläuterungen für 16.04 mit aufnehmen... OK?

so long
hank

Finde ich super interessant. Hast du vielleicht noch ein paar Quellen zum stöbern? Danke!

Hi!

siehe z.B. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769196, die manpages zu systemd, systemd.service, saned etc. Eine Suchmaschine deiner Wahl fördert sicher noch etliches mehr zutage; dass saned nicht mehr richtig funktioniert (hat) wird bei archlinux, fedora, debian etc. diskutiert, natürlich auch auf Launchpad (https://bugs.launchpad.net/ubuntu/+source/sane-backends/+bug/1577137), oder askubuntu http://askubuntu.com/questions/762702/failed-to-start-saned-service-unit-saned-service-is-masked/775050#775050, oder https://bugzilla.redhat.com/show_bug.cgi?id=1091566...

so long
hank

Danke. Die reichen mir als Einstieg! Und ja, suchen kann ich an sich selbst. Aber du hast dir so viel Arbeit gemacht, die muss ich ja nicht nochmal machen ☺ Danke!

Hi!

Um saned.socket beim Systemstart laufen zu lassen, muss einmalig

sudo systemctl enable saned.socket 

ausgeführt werden. Meldung dann:

Created symlink from /etc/systemd/system/sockets.target.wants/saned.socket to /lib/systemd/system/saned.socket.

Erspart einem das sudo systemctl start saned.socket. Wenn man saned.socket irgendwann nicht mehr benötigen sollte, kann es mit

sudo systemctl disable saned.socket 

wieder abstellen. Siehe /usr/share/doc/sane-utils/README.Debian.

so long
hank

Hallo,

das ist jetzt aber keine wirkliche neue Erkenntnis... das steht allgemein erklärt genau so im Wikiartikel systemd/systemctl Gut, da steht nicht explizit, dass das mit .sockets auch funktioniert, aber trotzdem. ☺

Gruß, noisefloor

Hi!

Wer kennt sich schon mit systemd aus, wenn er gerade erst von 14.04 auf 16.04 umgestiegen ist... Mir war nicht klar, wie man gezielt dafür sorgt, dass saned.socket direkt läuft 😛 . Bist in letzter Zeit ganz schön streng mit mir...

so long
hank

Hallo,

Bist in letzter Zeit ganz schön streng mit mir...

Andere werden altersmilde, bei mir läuft es genau andersherum 😉

Gruß, noisefloor