Bug 86497 - systemd socket activation confuses saned
Summary: systemd socket activation confuses saned
Status: RESOLVED NOTABUG
Alias: None
Product: systemd
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Hardware: All Linux (All)
: medium normal
Assignee: systemd-bugs
QA Contact: systemd-bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-11-20 19:54 UTC by Felix Braun
Modified: 2014-12-17 20:30 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
socket unit file (132 bytes, text/plain)
2014-11-20 19:54 UTC, Felix Braun
Details
saned@ service file (181 bytes, text/plain)
2014-11-20 19:54 UTC, Felix Braun
Details

Description Felix Braun 2014-11-20 19:54:07 UTC
Created attachment 109776 [details]
socket unit file

I'm trying to run saned via systemd socket activation on Debian jessie.

When I contact the scanner server from a remote system, systemd starts saned correctly. However, saned thinks it is being started for localhost

systemd[1]: Starting Scanner Service (192.168.220.17:57533)
systemd[1]: Started Scanner Service (192.168.220.17:57533)
saned[607]: saned (AF-indep+IPv6) from sane-backends 1.0.24
saned[607]: check_host: access by remote host: localhost
saned[607]: init: access by host localhost denied
saned[607]: saned exiting

If I add localhost to the allowed hosts (saned.conf) I get the following error

systemd[1]: Starting Scanner Service (192.168.220.17:57533)...
systemd[1]: Started Scanner Service (192.168.220.17:57533).
saned[788]: saned (AF-indep+IPv6) from sane-backends 1.0.24 starting up
saned[788]: check_host: access by remote host: localhost
saned[788]: init: bad status=22 or procnum=-1225192048
saned[788]: saned exiting

When I use xinetd to start saned in the same setup, everything works as expected.

I have reported a bug to the sane bug tracker
https://alioth.debian.org/tracker/index.php?func=detail&aid=314883

Somebody is experiencing the same problem with RedHat (I'm on Debian)
https://bugzilla.redhat.com/show_bug.cgi?id=1091566
Comment 1 Felix Braun 2014-11-20 19:54:51 UTC
Created attachment 109777 [details]
saned@ service file
Comment 2 Lennart Poettering 2014-11-21 18:19:54 UTC
Do things work if you use ListenStream=0.0.0.0:6566 or ListenStream=[::]:6566? This will force IPv4 or IPv6 listening.

Also, consider explicitly setting BindIPv6Only=ipv6-only.
Comment 3 Felix Braun 2014-11-21 18:55:48 UTC
I haven't set up IPv6 on my network, so I have only tried 0.0.0.0:6566, but that doesn't change the outcome.

Anyway, saned gets invoked just fine with as well as without this modification. It's not so much the listening part that seems to be the problem, but the message passing between systemd and saned, if that makes any sense.
Comment 4 Zbigniew Jedrzejewski-Szmek 2014-11-27 06:02:24 UTC
I'm guessing that 

StandardInput=null
StandardOutput=syslog

are wrong. With inetd-style socket activation the socket is passed as stdin and stdout to the process. Does it work if those lines are removed (after systemd daemon-reload && systemctl restart saned.socket)?
Comment 5 Felix Braun 2014-12-03 17:13:58 UTC
No, that didn't bring any changes either. Same error as before :-(

I'm on armel architecture by the way. But I don't think that matters because the RedHat-Bug seems to be on amd64 (the reporter there only mentions 64-Bit)
Comment 6 Lennart Poettering 2014-12-08 23:28:05 UTC
Any chance you can strace the sane binary?

Prefix the ExecStart= command line with "strace -o /log/to/somewhere -D ..." 

Then attach the log file that creates, this should give us a hint what saned might be failing on.
Comment 7 Zbigniew Jedrzejewski-Szmek 2014-12-17 00:19:53 UTC
This unit file is missing StandardInput=socket and some other stanzas to work correctly. See https://bugzilla.redhat.com/show_bug.cgi?id=1091566#c8 for a detailed explanation.
Comment 8 Felix Braun 2014-12-17 20:30:03 UTC
I can confirm that the solution described in the redhat bugzilla works for me too. Thanks a lot for your efforts!


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.