[CentOS] CentOS 7, NSF, "feature" [SOLVED]

[Ricardo J. Barberis]

El Miércoles 03/02/2016, Warren Young escribió:
> On Feb 3, 2016, at 8:57 AM, m.roth at 5-cent.us wrote:
> > Notice the *deeply* weird syntax of "=-<cmd>”.
>
> That syntax comes from make(1), where it means the same thing.  make(1) has
> been with us since 1977, so I’d think “old and familiar” is a better
> description than “deeply weird.”
>
> > And, I read in the manpage for systemd.service that if you precede it
> > with an @, it will pass arguments. Why it does not use the
> > used-everywhere-else of *post*fixing those parms, I have no data.
>
> You’ve misread the page.
>
> All this option does is lets you run one command but tell the command
> itself that it was called by a different name.  I’m not sure why the
> systemd creators added this, since you normally get this behavior with
> links:
>
>     $ sudo yum install unzip
>     $ ls -li /bin/unzip /bin/infozip
>     135096149 -rwxr-xr-x.   2 root root     181248 Mar 18  2015 unzip
>     135096149 -rwxr-xr-x.   2 root root     181248 Mar 18  2015 zipinfo
>
> That is, we have a single program binary with two different names. 
> Invoking the program as “zipinfo” makes it behave differently than if you
> invoke it as “unzip”.
>
> All this systemd feature does is lets you say something like:
>
>     ExecStart=@/bin/unzip zipinfo ...
>
> That is, you can run the unzip binary but *call it* zipinfo.
>
> Again, I don’t know why they couldn’t just do it with links.  However, I
> will point out that the C programming interfaces on your system (execv()
> and friends) also support this feature, and have since back before 1977, so
> that this, too, is not some fresh new weirdness.

I guess that's probably to execute scripts and "hide" the name of the 
interpreter, e.g.:

ExecStart=@/usr/bin/python my_cool_service --my_args


> > I also don't
> > understand why you'd set as an out-of-the-box default that it should fail
> > to come up if it can't resolve any export host, rather than default to
> > coming up.
>
> You do it for the same reason you’d fail when mounting any other
> filesystem.  It may be critical to operation, as with shared /usr.


-- 
Ricardo J. Barberis
Usuario Linux Nº 250625: http://counter.li.org/
Usuario LFS Nº 5121: http://www.linuxfromscratch.org/
Senior SysAdmin / IT Architect - www.DonWeb.com