Bug#826214: SysV init scripts using init-d-script are not properly redirected to systemctl

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Bug#826214: SysV init scripts using init-d-script are not properly redirected to systemctl

Michael Biebl-3
Package: sysvinit-utils
Version: 2.88dsf-59.4
Severity: important
File: /lib/init/init-d-script

Hi,

a SysV init script based on the new skeleton using
/lib/init/init-d-script is not properly redirected to systemctl when
being run under systemd as PID 1.
/etc/init.d/apache-htcacheclean from apache2 is an example useing
init-d-script:

# systemctl status apache-htcacheclean.service
● apache-htcacheclean.service - LSB: Cache cleaner process for Apache2 web server
   Loaded: loaded (/etc/init.d/apache-htcacheclean; generated; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:systemd-sysv-generator(8)
# /etc/init.d/apache-htcacheclean start
[ ok ] Starting Apache htcacheclean: apache-htcacheclean.
# systemctl status apache-htcacheclean.service
● apache-htcacheclean.service - LSB: Cache cleaner process for Apache2 web server
   Loaded: loaded (/etc/init.d/apache-htcacheclean; generated; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:systemd-sysv-generator(8)

As you can see, the start request is not redirected to systemctl, so the
systemd integration is broken.

I suspect this happens because init-functions is sourced before $1 is
shifted, so the systemd lsb init hook get's the wrong parameters.



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages sysvinit-utils depends on:
ii  init-system-helpers  1.34
ii  libc6                2.22-10
ii  startpar             0.59-3
ii  util-linux           2.28-5

sysvinit-utils recommends no packages.

Versions of packages sysvinit-utils suggests:
pn  bootlogd  <none>
pn  sash      <none>

-- no debconf information

-- debsums errors found:
debsums: changed file /lib/init/init-d-script (from sysvinit-utils package)

Reply | Threaded
Open this post in threaded view
|

Bug#826214: SysV init scripts using init-d-script are not properly redirected to systemctl

Martin Pitt-3
Hello Michael,

Michael Biebl [2016-06-03 13:22 +0200]:
> As you can see, the start request is not redirected to systemctl, so the
> systemd integration is broken.
>
> I suspect this happens because init-functions is sourced before $1 is
> shifted, so the systemd lsb init hook get's the wrong parameters.

Correct:

+ set /etc/init.d/apache-htcacheclean start
[...]
+ prog=apache-htcacheclean
+ service=apache-htcacheclean.service

Thus $0 is okay (from the "set" in init-t-script)

+ systemctl -p CanReload show apache-htcacheclean.service
+ [ CanReload=no = CanReload=no ]
+ [ /etc/init.d/apache-htcacheclean = reload ]

This corresponds to [ "${1:-}" = "reload" ], thus this check is
broken. Apparenlty the "set" (first traced line) doesn't assign
"$start" to $1, but to $2, and the script name to $1 as well.

This then finally fails when init-functions.d/40-systemd tries to act
on the action $1:

+ [ x/etc/init.d/apache-htcacheclean = xstart -o x/etc/init.d/apache-htcacheclean = xstop -o x/etc/init.d/apache-htcacheclean = xrestart -o x/etc/init.d/apache-htcacheclean = xreload -o x/etc/init.d/apache-htcacheclean = xforce-reload -o x/etc/init.d/apache-htcacheclean = xstatus ]

I tried to add something like

  if [ "$0" = "$1" ]; then shift; fi

above the sourcing of /lib/lsb/init-functions and adjust the
scriptname= assignment; that works when calling it as an init script
then, but the systemd redirection is then broken. Also, this wouldn't
do anything to fix #826215, so changing only init-d-script by itself
wouldn't be a complete solution anyway.

Thanks,

Martin

--
Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Reply | Threaded
Open this post in threaded view
|

Bug#826214: SysV init scripts using init-d-script are not properly redirected to systemctl

Mert Dirik
In reply to this post by Michael Biebl-3
Package: sysvinit-utils
Version: 2.88dsf-59.9
Followup-For: Bug #826214

Please forgive my naivety, but simply moving the argument shift part before
sourcing /lib/lsb/init-functions seems to successfully redirect to systemctl.

The only variable leaking to /lib/lsb/init-functions is "script", which can be
easily renamed and namespaced in case of a possible problem.

After patching /lib/init/init-d-script, both /etc/init.d/<...> start and
"service <...> start" shows up correctly in "systemctl status <...>" output.


--- /lib/init/init-d-script.orig        2018-01-09 21:25:41.763183856 +0000
+++ /lib/init/init-d-script     2018-01-09 22:38:48.463185948 +0000
@@ -5,6 +5,8 @@
 # Depend on lsb-base (>= 3.2-14) to ensure that this file is present
 # and status_of_proc is working.

+script="$1"
+shift
 . /lib/lsb/init-functions

 # PATH should only include /usr/* if it runs after the mountnfs.sh
@@ -154,11 +156,9 @@
     set -x
 fi

-SCRIPTNAME=$1
-scriptbasename="$(basename $1)"
+SCRIPTNAME="$script"
+scriptbasename="$(basename "$script")"
 if [ "$scriptbasename" != "init-d-script" ] ; then
-    script="$1"
-    shift
     . $script
 else
     exit 0


Is there anything wrong with this approach?



-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (x86_64)
Foreign Architectures: amd64, armhf

Kernel: Linux 4.4.91-mert (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages sysvinit-utils depends on:
ii  init-system-helpers  1.48
ii  libc6                2.24-11+deb9u1
ii  util-linux           2.29.2-1

sysvinit-utils recommends no packages.

sysvinit-utils suggests no packages.

-- no debconf information

Reply | Threaded
Open this post in threaded view
|

Bug#826214: SysV init scripts using init-d-script are not properly redirected to systemctl

Petter Reinholdtsen
[Mert Dirik]
> Please forgive my naivety, but simply moving the argument shift part before
> sourcing /lib/lsb/init-functions seems to successfully redirect to
> systemctl.

Interesting.  This seem like a very good idea. :)

> The only variable leaking to /lib/lsb/init-functions is "script", which can be
> easily renamed and namespaced in case of a possible problem.

Perhaps good to give it some init-d-script related prefix, to reduce the
chance of a future collision?

> Is there anything wrong with this approach?

Nothing I could think of from the top of my head. :)

--
Vennlig hilsen
Petter Reinholdtsen

Reply | Threaded
Open this post in threaded view
|

Bug#826214: SysV init scripts using init-d-script are not properly redirected to systemctl

Mert Dirik
On 01/10/18 21:20, Petter Reinholdtsen wrote:
> [Mert Dirik]
>> Please forgive my naivety, but simply moving the argument shift part before
>> sourcing /lib/lsb/init-functions seems to successfully redirect to
>> systemctl.
> Interesting.  This seem like a very good idea. :)
I'm happy to hear that.
>
>> The only variable leaking to /lib/lsb/init-functions is "script", which can be
>> easily renamed and namespaced in case of a possible problem.
> Perhaps good to give it some init-d-script related prefix, to reduce the
> chance of a future collision?
Maybe "__init_d_script_path"?
>
>> Is there anything wrong with this approach?
> Nothing I could think of from the top of my head. :)
>
Great :) I'll test it again in stretch or sid and I'll post the result
here. (previous test was done in jessie)

Reply | Threaded
Open this post in threaded view
|

Bug#826214: SysV init scripts using init-d-script are not properly redirected to systemctl

Mert Dirik
On Wed, 10 Jan 2018 22:49:17 +0300 Mert Dirik <[hidden email]> wrote:
 > On 01/10/18 21:20, Petter Reinholdtsen wrote:
 > > [Mert Dirik]
 > >> Please forgive my naivety, but simply moving the argument shift
part before
 > >> sourcing /lib/lsb/init-functions seems to successfully redirect to
 > >> systemctl.
 > > Interesting. This seem like a very good idea. :)
 > I'm happy to hear that.
 > >
 > >> The only variable leaking to /lib/lsb/init-functions is "script",
which can be
 > >> easily renamed and namespaced in case of a possible problem.
 > > Perhaps good to give it some init-d-script related prefix, to
reduce the
 > > chance of a future collision?
 > Maybe "__init_d_script_path"?
 > >
 > >> Is there anything wrong with this approach?
 > > Nothing I could think of from the top of my head. :)
 > >
 > Great :) I'll test it again in stretch or sid and I'll post the result
 > here. (previous test was done in jessie)
 >

I've tested the attached patch in a sid lxc container and the issue
seems to be fixed there.
Here is a relevant output:

> root@sid:~# cat /etc/init.d/sleep-daemon
> #!/bin/sh
> # kFreeBSD do not accept scripts as interpreters, using #!/bin/sh and
> sourcing.
> if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
>     set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
> fi
> ### BEGIN INIT INFO
> # Provides:          sleep-daemon
> # Required-Start:    $remote_fs $syslog
> # Required-Stop:     $remote_fs $syslog
> # Default-Start:     2 3 4 5
> # Default-Stop:      0 1 6
> # Short-Description: Sleep daemon
> # Description:       Sleep daemon
> ### END INIT INFO
>
> # Author: Foo Bar <[hidden email]>
>
> DESC="Sleep daemon"
> DAEMON=/bin/sleep
> DAEMON_ARGS=120
> START_ARGS="--background --make-pidfile"
>
> root@sid:~# /etc/init.d/sleep-daemon start
> [ ok ] Starting sleep-daemon (via systemctl): sleep-daemon.service.
> root@sid:~# systemctl status sleep-daemon | cat
> ● sleep-daemon.service - LSB: Sleep daemon
>    Loaded: loaded (/etc/init.d/sleep-daemon; generated; vendor preset:
> enabled)
>    Active: active (running) since Wed 2018-01-10 22:35:58 UTC; 2s ago
>      Docs: man:systemd-sysv-generator(8)
>   Process: 1467 ExecStop=/etc/init.d/sleep-daemon stop (code=exited,
> status=0/SUCCESS)
>   Process: 1513 ExecStart=/etc/init.d/sleep-daemon start (code=exited,
> status=0/SUCCESS)
>     Tasks: 1 (limit: 4915)
>    CGroup: /lxc/sid/system.slice/sleep-daemon.service
>            └─1529 /bin/sleep 120
>
> Jan 10 22:35:58 sid systemd[1]: Starting LSB: Sleep daemon...
> Jan 10 22:35:58 sid systemd[1]: Started LSB: Sleep daemon.
> root@sid:~#


826214.patch (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#826214: Direktoriaus kontaktai - tai Jūsų klientas

Gautas pranešimas
In reply to this post by Michael Biebl-3
Laba diena,

Noriu Jus informuoti apie šių metų pasikeitimą dėl atnaujintos visos Lietuvos įmonių bazės 2018 metų sausio vidurio.
Visi juridiniai asmenys pateikti bazėje yra veikiantys, realiai vykdantys veiklą, turintys įdarbintų darbuotojų. Duomenys pagal Sodrą, Registrų centrą.
 
Bazėje nurodoma ir apyvarta, darbuotojų atlyginimai, darbuotojų skaičius, transporto skaičius ir daug kitų duomenų, kuriuos matysite pavyzdyje.
 
Duomenis galima filtruoti pagal veiklas, miestus ir kitus duomenis.
 
 
Šią bazę verta turėti visoms įmonėms. Pateiksiu priežastis:
 
1) Kontaktai pateikti bazėje direktorių ir kitų atsakingų asmenų, didelė tikimybė Jums surasti naujų klientų, partnerių, tiekėjų, kai tiesiogiai bendrausite su direktoriais, komercijos vadovais.
 
2) Konkurentų analizavimas, tiekėjų atsirinkimas pagal Jums reikalingus kriterijus, galite atsifiltruoti pagal įmonės dydį, bazėje nurodoma kiek įmonės skolingos Sodrai.
 
3) Lengva, greita ir patogu dirbti su šia baze, elektroninius pašto adresus galite importuoti į elektroninių laiškų siuntimo programas ar sistemas iš kurių siunčiate elektroninius laiškus.
Taip pat galite importuoti mobiliųjų telefonų numerius į SMS siuntimo programas.
 
 
Išsirinkite iš "Veiklų sąrašo" veiklas kurių Jums reikia.
( Sąrašas prisegtas laiške excel faile )
 
Parašykite, kurias veiklas išsirinkote 
ir atsiųsime pavyzdį ir pasiūlymą su sąlygomis įmonių bazei įsigyti


Pagarbiai,
Tadas Giedraitis
Tel. nr. <A style="COLOR: rgb(17,85,204)" href="tel:+370%20678%2081041" rel="noopener noreferrer" target=_blank>+37067881041

Veiklos.xlsx (19K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#826214: SysV init scripts using init-d-script are not properly redirected to systemctl

Michael Biebl-3
In reply to this post by Michael Biebl-3
Control: tags -1 + pending

On Thu, 11 Jan 2018 01:38:00 +0300 Mert Dirik <[hidden email]> wrote:

> On Wed, 10 Jan 2018 22:49:17 +0300 Mert Dirik <[hidden email]> wrote:
>  > On 01/10/18 21:20, Petter Reinholdtsen wrote:
>  > > [Mert Dirik]
>  > >> Please forgive my naivety, but simply moving the argument shift
> part before
>  > >> sourcing /lib/lsb/init-functions seems to successfully redirect to
>  > >> systemctl.
>  > > Interesting. This seem like a very good idea. :)
>  > I'm happy to hear that.
>  > >
>  > >> The only variable leaking to /lib/lsb/init-functions is "script",
> which can be
>  > >> easily renamed and namespaced in case of a possible problem.
>  > > Perhaps good to give it some init-d-script related prefix, to
> reduce the
>  > > chance of a future collision?
>  > Maybe "__init_d_script_path"?
>  > >
>  > >> Is there anything wrong with this approach?
>  > > Nothing I could think of from the top of my head. :)
>  > >
>  > Great :) I'll test it again in stretch or sid and I'll post the result
>  > here. (previous test was done in jessie)
>  >
>
> I've tested the attached patch in a sid lxc container and the issue
> seems to be fixed there.

Thanks Mert for the patch and Petter for the review.

I've prepared an NMU with Mert's latest version of the patch and
uploaded it to DELAYED/7.
Full debdiff is attached.

Regards,
Michael

--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

sysvinit_2.88dsf-59.11.debdiff (2K) Download Attachment
signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#826214: fixed in sysvinit 2.88dsf-59.11

Michael Biebl-3
In reply to this post by Michael Biebl-3
Control: found -1 2.88dsf-59.11

On Sun, 14 Oct 2018 15:02:51 +0000 Michael Biebl <[hidden email]> wrote:

>  sysvinit (2.88dsf-59.11) unstable; urgency=medium
>  .
>    * Non-maintainer upload.
>  .
>    [ Mert Dirik ]
>    * Make sure that services using init-d-script can be properly redirected to
>      systemctl. (Closes: #826214)
>    * Avoid naming collisions when storing the script name in init-d-script by
>      using a custom prefix.

Re-opening again. Looks like the redirection is still broken when using
#!/lib/init/init-d-script or
#!/usr/bin/env /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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Mert Dirik
In reply to this post by Michael Biebl-3
On Fri, 23 Nov 2018 01:24:07 +0100 Michael Biebl <[hidden email]> wrote:

> Hi
>
> On Thu, 22 Nov 2018 16:01:33 +0000 Ian Jackson
> <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

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

Dmitry Bogatov-3

[2018-11-29 16:44] Mert Dirik <[hidden email]>

> 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}" ].

Reply | Threaded
Open this post in threaded view
|

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

Thorsten Glaser-6
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⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)

Reply | Threaded
Open this post in threaded view
|

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

Michael Biebl-3
In reply to this post by Mert Dirik
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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Michael Biebl-3
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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Michael Biebl-3
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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Thorsten Glaser-6
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⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)

Reply | Threaded
Open this post in threaded view
|

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

Michael Biebl-3
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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Thorsten Glaser-6
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

Reply | Threaded
Open this post in threaded view
|

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

Michael Biebl-3
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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Michael Biebl-3
In reply to this post by Thorsten Glaser-6
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 (849 bytes) Download Attachment
12