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

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

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

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


Hi!

The skeleton file using init-d-script contains:

'''
#!/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
'''

This is such an ugly construct that so far I did not want to use
init-d-script for any of my init scripts.
Assuming the above comment still holds true, please consider providing a
C implementation which can be used directly as shebang, like
#!/lib/init/init-d-script.

Michael

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

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

Versions of packages sysvinit-utils depends on:
ii  init-system-helpers  1.55
ii  libc6                2.27-8
ii  util-linux           2.32.1-0.2

sysvinit-utils recommends no packages.

sysvinit-utils suggests no packages.

-- no debconf information

Reply | Threaded
Open this post in threaded view
|

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

Ian Jackson-2
Michael Biebl writes ("Bug#913247: Please provide a C implementation of /lib/init/init-d-script"):
> Package: sysvinit-utils
> Version: 2.88dsf-59.11
> Severity: normal
> File: /lib/init/init-d-script
...
> This is such an ugly construct that so far I did not want to use
> init-d-script for any of my init scripts.
> Assuming the above comment still holds true, please consider providing a
> C implementation which can be used directly as shebang, like
> #!/lib/init/init-d-script.

env(1) would be helpful here.  If your daemon is on /usr anyway then
it doesn't matter that it isn't in /bin.

Ian.

Reply | Threaded
Open this post in threaded view
|

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

Michael Biebl-3
Am 08.11.18 um 18:54 schrieb Ian Jackson:

> Michael Biebl writes ("Bug#913247: Please provide a C implementation of /lib/init/init-d-script"):
>> Package: sysvinit-utils
>> Version: 2.88dsf-59.11
>> Severity: normal
>> File: /lib/init/init-d-script
> ...
>> This is such an ugly construct that so far I did not want to use
>> init-d-script for any of my init scripts.
>> Assuming the above comment still holds true, please consider providing a
>> C implementation which can be used directly as shebang, like
>> #!/lib/init/init-d-script.
>
> env(1) would be helpful here.  If your daemon is on /usr anyway then
> it doesn't matter that it isn't in /bin.
Given that this construct was added for kfreebsd, I would be interested
to know if

#!/usr/bin/env /lib/init/init-d-script

works on kfreebsd

--
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#913247: Please provide a C implementation of /lib/init/init-d-script

Michael Biebl-3
In reply to this post by Ian Jackson-2
Am 08.11.18 um 18:54 schrieb Ian Jackson:

> env(1) would be helpful here.  If your daemon is on /usr anyway then
> it doesn't matter that it isn't in /bin.

/usr is mounted by the initramfs nowadays, so this wouldn't be an issue
in practice.


--
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#913247: Please provide a C implementation of /lib/init/init-d-script

Dmitry Bogatov-3

[2018-11-08 19:06] Michael Biebl <[hidden email]>
> Am 08.11.18 um 18:54 schrieb Ian Jackson:
>
> > env(1) would be helpful here.  If your daemon is on /usr anyway then
> > it doesn't matter that it isn't in /bin.
>
> /usr is mounted by the initramfs nowadays, so this wouldn't be an issue
> in practice.

I made some experiments on FreeBSD-11 virtual image. I believe for
puproses we discuss, it is as good, as Debian GNU/kFreeBSD.

 * Note in /etc/init.d/skeleton still holds true -- shell script can't
   be used as interpreter in #! of another script
 * Trick with #!/usr/bin/env /path/to/script works.

As such, I will update init-d-script(5) and it will close this bug.

Reply | Threaded
Open this post in threaded view
|

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

Michael Biebl-3
Am 09.11.18 um 21:01 schrieb Dmitry Bogatov:

>
> [2018-11-08 19:06] Michael Biebl <[hidden email]>
>> Am 08.11.18 um 18:54 schrieb Ian Jackson:
>>
>>> env(1) would be helpful here.  If your daemon is on /usr anyway then
>>> it doesn't matter that it isn't in /bin.
>>
>> /usr is mounted by the initramfs nowadays, so this wouldn't be an issue
>> in practice.
>
> I made some experiments on FreeBSD-11 virtual image. I believe for
> puproses we discuss, it is as good, as Debian GNU/kFreeBSD.
>
>  * Note in /etc/init.d/skeleton still holds true -- shell script can't
>    be used as interpreter in #! of another script
>  * Trick with #!/usr/bin/env /path/to/script works.
>
> As such, I will update init-d-script(5) and it will close this bug.
Just tried the
#!/usr/bin/env /lib/init/init-d-script
proposal.
Seem like this breaks the systemctl integration again.
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826214

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#913247: Please provide a C implementation of /lib/init/init-d-script

Dmitry Bogatov-3

[2018-11-09 22:16] Michael Biebl <[hidden email]>
> Just tried the
> #!/usr/bin/env /lib/init/init-d-script
> proposal.
> Seem like this breaks the systemctl integration again.
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826214

Wierd. I have no systemd box to check, but are you sure it works with
#!/lib/init/init-d-script?

I did little experiment:

        $ cat /tmp/foo.sh
        #!/tmp/interpreter.sh

        $ cat /tmp/bar.sh
        #!/usr/bin/env /tmp/interpreter.sh

        $ cat /tmp/interpreter.sh
        #!/bin/sh
        printf '$# = %d\n' "$#"
        printf '$0 = %s\n' "$0"
        for arg ; do
            printf '= %s\n' "$arg"
        done

        $ /tmp/foo.sh
        $# = 3
        $0 = /tmp/interpreter.sh
        = /tmp/foo.sh
        = x
        = y

        $ /tmp/bar.sh
        $# = 3
        $0 = /tmp/interpreter.sh
        = /tmp/bar.sh
        = x
        = y

As you can see, in both cases $0 is path to interpreter, $1 name of
script, $2... is args. I fail to see how interpreter could distinguish
these two cases.

Reply | Threaded
Open this post in threaded view
|

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

Michael Biebl-3
Am 11.11.18 um 22:08 schrieb Dmitry Bogatov:

>
> [2018-11-09 22:16] Michael Biebl <[hidden email]>
>> Just tried the
>> #!/usr/bin/env /lib/init/init-d-script
>> proposal.
>> Seem like this breaks the systemctl integration again.
>> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826214
>
> Wierd. I have no systemd box to check, but are you sure it works with
> #!/lib/init/init-d-script?
It doesn't work with #!/lib/init/init-d-script either.

Only
============================
#!/bin/sh

if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
    set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
fi
============================
currently works wrt to systemctl redirection.


--
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#913247: Please provide a C implementation of /lib/init/init-d-script

Dmitry Bogatov-3

[Adding systemd maintainers into thread]
(We are discussing #826214)

[2018-11-11 22:37] Michael Biebl <[hidden email]>

> > #!/lib/init/init-d-script?
>
> It doesn't work with #!/lib/init/init-d-script either.
>
> Only
> ============================
> #!/bin/sh
>
> if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
>     set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
> fi
> ============================
> currently works wrt to systemctl redirection.

At least it does not feel magic. In case of #!/lib/init/init-d-script,
$0 = /lib/init/init-d-script; in case of sourcing $0 is path to script
(/etc/init.d/foo).

Now, issue seems to be /lib/lsb/init-functions.d/40-systemd from
bin:systemd. On line 7 we read:

        prog=${0##*/}

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?

Opinions?

Reply | Threaded
Open this post in threaded view
|

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

Mert Dirik
On Tue, 13 Nov 2018 20:22:16 +0000 Dmitry Bogatov <[hidden email]>
wrote:
 >
 > [Adding systemd maintainers into thread]
 > (We are discussing #826214)
 >
 > [2018-11-11 22:37] Michael Biebl <[hidden email]>
 > > > #!/lib/init/init-d-script?
 > >
 > > It doesn't work with #!/lib/init/init-d-script either.
 > >
 > > Only
 > > ============================
 > > #!/bin/sh
 > >
 > > if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
 > > set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
 > > fi
 > > ============================
 > > currently works wrt to systemctl redirection.
 >
 > At least it does not feel magic. In case of #!/lib/init/init-d-script,
 > $0 = /lib/init/init-d-script; in case of sourcing $0 is path to script
 > (/etc/init.d/foo).
 >
 > Now, issue seems to be /lib/lsb/init-functions.d/40-systemd from
 > bin:systemd. On line 7 we read:
 >
 > prog=${0##*/}
 >
 > 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?
 >
 > Opinions?
 >
 >

Hi,

I noticed the new snippet in the man page of experimental version uses the

#! /usr/bin/env /lib/init/init-d-script

shebang, which doesn't work with systemd redirection. I don't know any
packages in the archive using /lib/init/init-d-script in the shebang
line currently but I fear some scripts may start to use the new variant
(thus hitting #826214 again).

Can you please consider changing it with the snippet in the old
/etc/init.d/skeleton (the one using the INIT_D_SCRIPT_SOURCED trick), at
least until a better solution can be found for this or #826214)

Reply | Threaded
Open this post in threaded view
|

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

Ian Jackson-2
Mert Dirik writes ("Bug#913247: Please provide a C implementation of /lib/init/init-d-script"):
> I noticed the new snippet in the man page of experimental version uses the
> #! /usr/bin/env /lib/init/init-d-script
> shebang, which doesn't work with systemd redirection.

I don't know what `systemd redirection' is.  Why does it not work ?
Can it be fixed ?

Ian.

--
Ian Jackson <[hidden email]>   These 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.

Reply | Threaded
Open this post in threaded view
|

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

Mert Dirik
On 11/22/18, Ian Jackson <[hidden email]> wrote:

> Mert Dirik writes ("Bug#913247: Please provide a C implementation of
> /lib/init/init-d-script"):
>> I noticed the new snippet in the man page of experimental version uses
>> the
>> #! /usr/bin/env /lib/init/init-d-script
>> shebang, which doesn't work with systemd redirection.
>
> 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.

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
/lib/init/init-d-script breaks that. We partially fixed this in
init-d-script so that using the old "set "$0" "$@";
INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script" snippet (as it
was in the /etc/init.d/skeleton) works correctly, but if
/lib/init/init-d-script (or /usr/bin/env) is used as shebang there is
no way to fix it inside init-d-script since dash scripts can't change
the value of $0.

I'm in the process of writing a longer opinion mail on
/lib/init/init-d-script but it's not finished yet.

Reply | Threaded
Open this post in threaded view
|

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

Ian Jackson-2
Mert Dirik writes ("Re: Bug#913247: Please provide a C implementation of /lib/init/init-d-script"):
> On 11/22/18, Ian Jackson <[hidden email]> 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 Jackson <[hidden email]>   These 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.

Reply | Threaded
Open this post in threaded view
|

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

Mert Dirik
On 11/22/18, Ian Jackson <[hidden email]> wrote:

> Mert Dirik writes ("Re: Bug#913247: Please provide a C implementation of
> /lib/init/init-d-script"):
>> On 11/22/18, Ian Jackson <[hidden email]> 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.

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)

Reply | Threaded
Open this post in threaded view
|

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

Ian Jackson-2
Mert Dirik writes ("Re: Bug#913247: Please provide a C implementation of /lib/init/init-d-script"):
> On 11/22/18, Ian Jackson <[hidden email]> 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 Jackson <[hidden email]>   These 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.

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
On 11/22/18, Ian Jackson <[hidden email]> wrote:

> Mert Dirik writes ("Re: Bug#913247: Please provide a C implementation of
> /lib/init/init-d-script"):
>> On 11/22/18, Ian Jackson <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

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

Ian Jackson-2
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 Jackson <[hidden email]>   These 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.

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
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?


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
On 11/23/18, 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.
>
>

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.

Reply | Threaded
Open this post in threaded view
|

Bug#826214: Please would 40-systemd honour __init_d_script_name

Benda Xu-3
In reply to this post by Ian Jackson-2
Ian Jackson <[hidden email]> writes:

> 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.

I agree with Ian and Dmitry, and have no objections to this decision.

Thank you to all the parties coming together to fix this.

Yours,
Benda

12