Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script

[Mert Dirik]

On Sun, Dec 2, 2018 at 1:00 AM Michael Biebl <biebl at debian.org> wrote:
>
> Hi Mert!
>
> Am 29.11.18 um 14:44 schrieb Mert Dirik:
> > I've created a merge request for 40-systemd at
> > https://salsa.debian.org/systemd-team/systemd/merge_requests/19 .
> > Reviews and comments are welcomed.
> >
> > If this is fully applied, systemd redirection will work correctly for
> > all init-d-script scripts (using init-d-script as the shebang or
> > sourcing it afterwards) under all init-d-script versions ( whether it
> > sets "__init_d_script_name" variable or not ) . In that case there
> > would be no need for "__init_d_script_name" code in
> > /lib/init/init-d-script anymore thus it can be dropped.
>
>
> I'm still convinced, that fixing this properly in init-d-script would be
> the much better solution. If init-d-script was implemented in C, it
> could be used as a shebang/interpreter on non-Linux and it would be
> possible to have $0 be set properly. Which also means, no changes to
> 40-systemd would be necessary.
>
> Now we have the unfortunate situation, that implementation details like
> __init_d_script_name leak into 40-systemd (or the init-d-script name in
> your second commit), and I do not like that at all.
>
> Also, keep in mind, that 40-systemd might not be the only script which
> relies on $0 being set properly. E.g. pidofproc in
> /lib/lsb/init-functions uses $0. So I can only hope, that no init script
> based on init-d-script ever uses pidofproc or $0 directly.
>
> In the interest of unbreaking the current situation, I'm ok with merging
> this MR, even if I'm not happy with the overall solution.
> That said, I very much appreciate the detailed testing you did and the
> effort you put into this MR. The only (minor) comment I have, is that we
> prefer "gbp dch" style git coments. Which means, Closes statements are
> listed as
>
> Closes: #12345
>
> I'll fix that up when I pull the MR though, so no need to push an update
> for that.
>
> Thanks again, Mert.
>

You're welcome and thank you, too.


> Btw, so far no (convincing) reason was presented why this is not fixed
> in init-d-script directly.

> Would be interested to know, why the sysvinit maintainers came to this
> conclusion.

I can't talk for the sysvinit maintainers but my personal opinion is as
follows:

I can't really think of a way to write a C version of init-d-script without
embedding a complete shell interpreter in it. init-d-script scripts are
fully fledged shell scripts and init-d-script is just a clever way to source
another script.

If somebody can think of an easier way to write a C version without having
to embed a full interpreter or reinventing a shell script parser and can
guide/help me I'm willing to give it a shot.

I thought we had almost solved this because invoking init-d-script with
the "set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script"
snippet worked fine without breaking $0 $1 ....  It was the recommended style
in /etc/skel and all the scripts in the repository are using init-d-script
this way.

I think the best way to solve this in short term is making that snippet the
preferred way of using init-d-script and discouraging the shebang invocation
by printing big warnings about it.

That's why I suggested making the the preferred way of use and discouraging the
use of shebang in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=913247#55
but if shebang invocation must really be supported then working it around
in 40-systemd is the only practical solution.