Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script
On Sun, Dec 2, 2018 at 1:00 AM Michael Biebl 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.
Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script
On Sat, Dec 1, 2018 at 9:48 PM Thorsten Glaser wrote:
>
> On Sat, 1 Dec 2018, Dmitry Bogatov wrote:
>
> > AFAIK, in shell [ "${foo}" ] is equal to [ -n "${foo}" ].
>
> Not always / portably.
>
>
> I recommend
>
> test -n "$foo"
>
> for POSIX (which is equivalent to [ -n "$foo" ] but better legible and
> making it clear that test is an external command, not a language con‐
> struct), and
>
> [[ $foo ]]
>
> for Korn shell and compatibles, including (here) GNU bash.
>
> bye,
> //mirabilos (mksh developer)
> --
> 15:41⎜ Somebody write a testsuite for helloworld :-)
Thank you Dmitry and Thorsten reviews and suggestions.
This needs to run under both dash and bash, also other lines in the
file are using [ so it'd be better not using a different style than
the rest.
Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script
Am 01.12.18 um 23:31 schrieb Thorsten Glaser: > This will also make it easier to switch to a binary > implementation later. Ok, I take this as a positive signal. So far this has been rejected outright. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script
Am 01.12.18 um 23:40 schrieb Thorsten Glaser: > On Sat, 1 Dec 2018, Michael Biebl wrote: > >> If there is a binary implementation, then you would be using >> #!/lib/init/init-d-script > > Yes, but it would *also* still work with env(1). But it would only be an unnecessary redirection. That said, part 1 of my previous reply is actually the more interesting one -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script
On Sat, 1 Dec 2018, Michael Biebl wrote: > If there is a binary implementation, then you would be using > #!/lib/init/init-d-script Yes, but it would *also* still work with env(1). bye, //mirabilos -- >> Why don't you use JavaScript? I also don't like enabling JavaScript in > Because I use lynx as browser. +1 -- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel
Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script
Am 01.12.18 um 23:31 schrieb Thorsten Glaser: > On Sat, 1 Dec 2018, Michael Biebl wrote: > >> I'd also be interested to know why >> >> #!/usr/bin/env /lib/init/init-d-script >> is preferred over >> #!/bin/sh /lib/init/init-d-script >> given that init-d-script is *no* C implementation. > > That’s easy: this way, the shebang at the start of > /lib/init/init-d-script can, if needed, select a > shell other than /bin/sh to be the interpreter, e.g. > if shell-specific features need to be used. Is that actually a good thing? If shell specific features are needed, do we know that they are compatible with lib/init/init-d-script? > This will also make it easier to switch to a binary > implementation later. If there is a binary implementation, then you would be using #!/lib/init/init-d-script -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script
On Sat, 1 Dec 2018, Michael Biebl wrote: > I'd also be interested to know why > > #!/usr/bin/env /lib/init/init-d-script > is preferred over > #!/bin/sh /lib/init/init-d-script > given that init-d-script is *no* C implementation. That’s easy: this way, the shebang at the start of /lib/init/init-d-script can, if needed, select a shell other than /bin/sh to be the interpreter, e.g. if shell-specific features need to be used. This will also make it easier to switch to a binary implementation later. bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script
Am 01.12.18 um 23:04 schrieb Michael Biebl: > Am 01.12.18 um 23:00 schrieb Michael Biebl: >> 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. > > 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'd also be interested to know why #!/usr/bin/env /lib/init/init-d-script is preferred over #!/bin/sh /lib/init/init-d-script given that init-d-script is *no* C implementation. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script
Am 01.12.18 um 23:00 schrieb Michael Biebl: > 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. 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. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script
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. Regards, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script
On Sat, 1 Dec 2018, Dmitry Bogatov wrote:
> AFAIK, in shell [ "${foo}" ] is equal to [ -n "${foo}" ].
Not always / portably.
I recommend
test -n "$foo"
for POSIX (which is equivalent to [ -n "$foo" ] but better legible and
making it clear that test is an external command, not a language con‐
struct), and
[[ $foo ]]
for Korn shell and compatibles, including (here) GNU bash.
bye,
//mirabilos (mksh developer)
--
15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script
[2018-11-29 16:44] 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.
Thank you. Looks fine to me.
AFAIK, in shell [ "${foo}" ] is equal to [ -n "${foo}" ].
Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script
On Fri, 23 Nov 2018 01:24:07 +0100 Michael Biebl wrote: > Hi > > On Thu, 22 Nov 2018 16:01:33 + Ian Jackson > wrote: > > > To the systemd maintainers: will you have time to look at this, and > > make the appropriate change, soon ? If not then one of us could > > probably prepare a patch, if that would be helpful. > > A patch for 40-systemd would be highly appreciated [1]. > > A few things which should be considered: > > > - It should work with both > > #!/usr/bin/env /lib/init/init-d-script > > and > > if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then > set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script > fi > > Otherwise we need a flag day and convert all packages using > init-d-script at once. > > > - Older versions of sysvinit-utils (prior to 2.88dsf-59.11) did not use > __init_d_script_name=. 40-systemd should either work with older and > newer versions of /lib/init/init-d-script or systemd would need a > versioned Breaks: sysvinit-utils (<< 2.88dsf-59.11) > > I would prefer if we can avoid the Breaks as those are prone to > complicate dist-upgrades. > > > > Regards, > Michael > > [1] A MR via https://salsa.debian.org/systemd-team/systemd/ would be > even better > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > 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.
Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script
On 11/23/18, Michael Biebl wrote: > Hi > > On Thu, 22 Nov 2018 16:01:33 + Ian Jackson > wrote: > >> To the systemd maintainers: will you have time to look at this, and >> make the appropriate change, soon ? If not then one of us could >> probably prepare a patch, if that would be helpful. > > A patch for 40-systemd would be highly appreciated [1]. > > A few things which should be considered: > > > - It should work with both > > #!/usr/bin/env /lib/init/init-d-script > > and > > if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then > set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script > fi > > Otherwise we need a flag day and convert all packages using > init-d-script at once. > > > - Older versions of sysvinit-utils (prior to 2.88dsf-59.11) did not use > __init_d_script_name=. 40-systemd should either work with older and > newer versions of /lib/init/init-d-script or systemd would need a > versioned Breaks: sysvinit-utils (<< 2.88dsf-59.11) > > I would prefer if we can avoid the Breaks as those are prone to > complicate dist-upgrades. > > I'll work on a patch for 40-systemd this week, but of course anyone else should feel free to work on it before I do.
Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script
Hi On Thu, 22 Nov 2018 16:01:33 + Ian Jackson wrote: > To the systemd maintainers: will you have time to look at this, and > make the appropriate change, soon ? If not then one of us could > probably prepare a patch, if that would be helpful. A patch for 40-systemd would be highly appreciated [1]. A few things which should be considered: - It should work with both #!/usr/bin/env /lib/init/init-d-script and if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script fi Otherwise we need a flag day and convert all packages using init-d-script at once. - Older versions of sysvinit-utils (prior to 2.88dsf-59.11) did not use __init_d_script_name=. 40-systemd should either work with older and newer versions of /lib/init/init-d-script or systemd would need a versioned Breaks: sysvinit-utils (<< 2.88dsf-59.11) I would prefer if we can avoid the Breaks as those are prone to complicate dist-upgrades. Regards, Michael [1] A MR via https://salsa.debian.org/systemd-team/systemd/ would be even better -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script
Control: retitle -1 Please would 40-systemd honour __init_d_script_name
Control: reassign -1 src:systemd
Mert Dirik writes ("Re: Bug#826214: Bug#913247: Please provide a C
implementation of /lib/init/init-d-script"):
> "__init_d_script_name" variable is set inside init-d-script before
> sourcing /lib/lsb/init-functions and it can be used for this purpose.
Now that I reread #913247 I see we are going round in circles. Thanks
for your patience, Mert, in explaining it again.
Dmitry wrote in #913247:
> As far as I know, there is no way to modify "$0". So we have two
> options:
>
> * have systemd folks use `${__init_d_script_name##*/}' in
> `40-systemd' instead of `$0'
>
> * write wrapper in C, which sets $0 to value, expected by
> `40-systemd'. Actually, there is number of utilities floating
> around, which set $0 to arbitrary value (`chpst' from bin:runit is
> one of them :)), but we do not want to add new dependency to
> essentail sysvinit-utils, don't we?
I think reimplementing init-d-script in C is the wrong solution to
this bug. Certainly, if the only thing it is buying is us an ability
to manipulate $0. I infer from Dmitry's closing of #913247 which
requests init-d-script in C, that he also doesn't like that idea.
So I think both Dmitry and I are in agreement that the right solution
here is the first of Dmitry's two bullet points above. Ie, the
sysvinit maintainers are of the opinion that this should be fixed by
amending 40-systemd, which is part of the systemd package.
I'm therefore reassigning this bug. Benda, if you disagree; or,
Dmitry, if I have misunderstood your view: please do say.
To the systemd maintainers: will you have time to look at this, and
make the appropriate change, soon ? If not then one of us could
probably prepare a patch, if that would be helpful.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script
On 11/22/18, Ian Jackson wrote:
> Mert Dirik writes ("Re: Bug#913247: Please provide a C implementation of
> /lib/init/init-d-script"):
>> On 11/22/18, Ian Jackson wrote:
>> > So I think this would be fixed if /lib/init/init-d-script detected
>> > this situation and set $0 to the original script name (which it gets
>> > in $1). That is probably desirable anyway.
>>
>> The problem is there is no way of setting $0 inside a shell script as
>> far as I know. So either init-d-script shouldn't be used in shebang or
>> 40-systemd should handle a special case for it (this is up to the
>> systemd maintainers as 40-systemd is in systemd package)
>
> Ah, yes. I looked at the dash manpage and didn't see anything
> appropriate. But it would be a simple matter to invent a new
> variable, surely.
>
"__init_d_script_name" variable is set inside init-d-script before
sourcing /lib/lsb/init-functions and it can be used for this purpose.
Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script
Mert Dirik writes ("Re: Bug#913247: Please provide a C implementation of
/lib/init/init-d-script"):
> On 11/22/18, Ian Jackson wrote:
> > So I think this would be fixed if /lib/init/init-d-script detected
> > this situation and set $0 to the original script name (which it gets
> > in $1). That is probably desirable anyway.
>
> The problem is there is no way of setting $0 inside a shell script as
> far as I know. So either init-d-script shouldn't be used in shebang or
> 40-systemd should handle a special case for it (this is up to the
> systemd maintainers as 40-systemd is in systemd package)
Ah, yes. I looked at the dash manpage and didn't see anything
appropriate. But it would be a simple matter to invent a new
variable, surely.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#826214: Bug#913247: Please provide a C implementation of /lib/init/init-d-script
Mert Dirik writes ("Re: Bug#913247: Please provide a C implementation of
/lib/init/init-d-script"):
> On 11/22/18, Ian Jackson wrote:
> > I don't know what `systemd redirection' is. Why does it not work ?
> > Can it be fixed ?
>
> To sum it up, when /lib/lsb/init-functions is sourced from a script in
> /etc/init.d, /lib/lsb/init-functions.d/40-systemd is also sourced and
> the script is executed using a corresponding "systemctl " command
> so that systemd can track the daemon. Relevant bug report is #826214.
Thanks.
This doesn't seem so difficult to fix. (CCing that bug.)
> The problem here is, 40-systemd uses the value of "$0" to figure out
> whether the caller was a script inside /etc/init.d/ and using
I just experimented:
mariner:d> pwd
/u/iwj/junk/d
mariner:d> egrep . init-d-script daemon
init-d-script:#!/bin/sh
init-d-script:echo "in init-d-script \$0=$0 \$*=$*"
daemon:#!/usr/bin/env /u/iwj/junk/d/init-d-script
daemon:some thing or other
mariner:d> ./daemon start
in init-d-script $0=/u/iwj/junk/d/init-d-script $*=./daemon start
mariner:d>
So I think this would be fixed if /lib/init/init-d-script detected
this situation and set $0 to the original script name (which it gets
in $1). That is probably desirable anyway.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
