CentOS - Feb 2016 - CentOS 7, NSF, "feature" [SOLVED]

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

On Feb 3, 2016, at 10:30 AM, Ricardo J. Barberis <ricardo at
palmtx.com.ar> wrote:
> 
> El Mi?rcoles 03/02/2016, Warren Young escribi?:
>> 
>> Again, I don?t know why they couldn?t just do it with links.
> 
> I guess that's probably to execute scripts and "hide" the
name of the
> interpreter, e.g.:
I get why second-rate programmers would care to do that, but what I don?t get is
why systemd would need a feature to support that wish.

No, I suspect the real reason systemd needs to support this is to work around
someone?s broken argv[0] parsing.  For instance, there may be a program that
assumes it is always started through the PATH, so argv[0] never contains
slashes.  But, systemd only works with absolute paths for security, so rather
than fix the broken program, they added a feature to systemd that lets it lie to
the broken program, supplying the program?s basename in argv[0] even though it
was started via an absolute path.

Just a guess, of course.

I notice that none of the service files on my main EL7 box use this leading-@
feature.

On Wed, 2016-02-03 at 13:57 -0700, Warren Young wrote:
> On Feb 3, 2016, at 10:30 AM, Ricardo J. Barberis <ricardo at
palmtx.com.ar> wrote:
> > 
> > El Mi?rcoles 03/02/2016, Warren Young escribi?:
> >> 
> >> Again, I don?t know why they couldn?t just do it with links.
> > 
> > I guess that's probably to execute scripts and "hide"
the name of the
> > interpreter, e.g.:
> 
> I get why second-rate programmers would care to do that, but what I don?t
get is why systemd would need a feature to support that wish.
Perhaps the Systemd are all 'second-rate' programmers ?  Good
programmers always try to avoid the crap.


-- 
Regards,

Paul.
England, EU.      England's place is in the European Union.