That is a template service and it requires an argument.
http://0pointer.de/blog/projects/instances.html

understood -- but the error message returned says nothing of this (the '@' is a clear indicator). systemctl 'seems' to work in some cases, but not in others

A three year old blog post is not documentation, nor a substitute for a credible error message, or a man page describing such behaviours

https://github.com/systemd/systemd/pull/2915

https://github.com/lnykryn/systemd-rhel/commit/9b33863a2cfa31bbe57bab685776b64731f528f1

Verified on RHEL 7.3 Beta with systemd-219-26.el7.

Old package:
# systemctl status user@.service; echo $?
Failed to get properties: Unit name user@.service is not valid.
1

New package:
# systemctl status user@.service; echo $?
Failed to get properties: Unit name user@.service is missing the instance name.
1

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2016-2216.html

Dear Red Hat,

I am coming from the community: Scientific Linux 7.4

This issue has come back.  Would you please re-open it.

This is from the systemd recommendations in "man saned":
https://www.mankier.com/8/saned#Systemd_configuration_for_saned_with_systemd_support_compiled_in

# systemctl start saned\@.service

    Failed to start saned@.service: Unit name saned@.service is missing the instance name. 

Would you please re-fix this?

Many thanks,
-T

Those recommendations are simply wrong. There's nothing in that service file that would use the argument of that service. You have two options:

1) Just remove the '@' from the service's name, as it's not used inside the service anyway. (This is what I would do.)

2) Change the service file to actually use the argument and then run the service with the argument like so:

# systemctl start saned

The 'foobar' part is the argument, the instance name that the error message is complaining about.

(In reply to Todd from comment #13)

> This is from the systemd recommendations in "man saned":
> https://www.mankier.com/8/
> saned#Systemd_configuration_for_saned_with_systemd_support_compiled_in
> 
> # systemctl start saned\@.service
> 
>     Failed to start saned@.service: Unit name saned@.service is missing the
> instance name. 

From manpage it is clear that saned is socket activated service. saned.socket has Accept=yes set. This means that saned@.service template is required and each connection to socket starts a new instance of that service template. You are expected to work with socket unit (start/stop/enable ...) instead of the service.

Also searching in the man page I fail to see where exactly does it recommend to start the service directly.

(In reply to Michal Sekletar from comment #15)
> This means that saned@.service template is
> required and each connection to socket starts a new instance of that service
> template.

I didn't know that, sorry for the confusion.

So, will you please reopen the bug?

Or should I open a new one and reference this one?

And are there any workaround?  (I did try saned\@sane.service and that got rid of the error message, but it also did not start saned.)

You just need to start the socket instead of the service
systemctl start saned.socket

(In reply to Lukáš Nykrýn from comment #18)
> You just need to start the socket instead of the service
> systemctl start saned.socket

# systemctl -l start saned.socket

# systemctl -l status saned.socket
● saned.socket - saned incoming socket
   Loaded: loaded (/etc/systemd/system/saned.socket; enabled; vendor preset: disabled)
   Active: active (listening) since Sun 2017-11-19 15:54:30 PST; 13h ago
   Listen: [::]:6566 (Stream)
 Accepted: 0; Connected: 0

Nov 19 15:54:30 foo.bar.local systemd[1]: Listening on saned incoming socket.
Nov 19 15:54:30 foo.bar.local systemd[1]: Starting saned incoming socket.

# ps ax | grep [s]aned
<nothing>

And PDF Studio can't find the scanner either.  PDF Studio can, if I start saned manually.

/usr/sbin/saned -a saned -d128; echo $?; ps ax | grep -i [s]aned
0
29857 ?        Ss     0:00 /usr/sbin/saned -a saned -d128 


Am I misunderstanding something?

You can't see any saned procvess running, because in this configuration saned is socket-activated. Which means that systemd listens on port 6566 and if there is an incoming connection it starts the saned process and hands over the connection.

I have no idea why PDF studio does not work. Maybe it uses a different mean to communicate with saned? But for that you need to talk to saned/pdf studio developers. Everything works on systemd level as expected.

ToddAndMargo

The systemd functionality is similar, to, and a partial formal sub-set of what the former 'xinetd' did -- listening for an inbound connection, and when content  is heard, ONLY THEN firing up the underlying application, here the 'saned' daemon.  This may be changed (tuned, really) in the cases of slow to start, or daemons which spawn off sub-process 'children', but this is one of scope here

It is also a subset of TCP-WRAPPERS functionality -- it can do source IP based restriction -- with a little work, so that one might limit connections to say only the localnet, or only selected 'outside network' IPs

The service is partial as id does not link in DNS resolution for name based permits or denies, but it is at least something

As to your question about 'should you clone this bug' or not, that is up to you.  My initial filing was about the documentation issue, and conformance, or non-conformance with LSB initscripts requirements.  Yours is more a usage question, and so really rather off topic in this bug

as to 'cloning' a bug to preserve context, see the upper right corner at the top of this bug.  It may make more sense to file it against the 'saned' providing SRPM package:   sane-backends

particularly, I do not see explicit systemd support there

$ rpm -ql sane-backends | grep syst
$

with kind regards,

-- Russ herrold

Hi Russ,

Fedora has the daemon broken out of backends:

sane-backends-daemon.x86_64 1.0.27-5.fc27

Apparently, RHEL's version (1.0.24) came before the two were broken out AND RHEL's version did not throw the compiler switch to include the daemon.

$ ./configure --help | grep systemd
      --with-systemd          enable systemd support [default=yes]

Would you consider putting the daemon back in to where it goes.  I would ADORE it if you updates to Fedora's (1.0.27).

Please note that saned.socket will not run without the daemon support

Many thanks,
-T

(In reply to Todd from comment #22)
> Hi Russ,
> 
> Fedora has the daemon broken out of backends:
> 
> sane-backends-daemon.x86_64 1.0.27-5.fc27
> 
> Apparently, RHEL's version (1.0.24) came before the two were broken out AND
> RHEL's version did not throw the compiler switch to include the daemon.
> 
> $ ./configure --help | grep systemd
>       --with-systemd          enable systemd support [default=yes]
> 
> Would you consider putting the daemon back in to where it goes.  I would
> ADORE it if you updates to Fedora's (1.0.27).
> 
> Please note that saned.socket will not run without the daemon support
> 
> Many thanks,
> -T

Can you please open a new bug for this? This one was solving a different issue.

(In reply to Lukáš Nykrýn from comment #23)
> Can you please open a new bug for this? This one was solving a different
> issue.

Your wish is my command:
https://bugzilla.redhat.com/show_bug.cgi?id=1517029