On Sun, Dec 2, 2018 at 1:00 AM Michael Biebl <bi...@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.
