On 6 May 2014 05:52, Steve Langasek <vor...@debian.org> wrote:
>
> On Mon, May 05, 2014 at 03:49:38AM -0007, Cameron Norman wrote:
> > El Fri, 2 de May 2014 a las 8:12 PM, Dimitri John Ledkov
> > <x...@debian.org> escribió:
> > >On 3 May 2014 03:55, Cameron Norman <camerontnor...@gmail.com> wrote:
> > >> El Fri, 2 de May 2014 a las 7:46 PM, Dimitri John Ledkov
> > >><x...@debian.org>
> > >> escribió:
>
> > >> Would you like any help, or do you got it?
>
> > >Save attached file as /lib/lsb/init-functions.d/01-upstart-lsb . This
> > >is what i'm currently planning to do, this should mimic how service
> > >command operates on upstart jobs at the moment.
>
> > I hit two issues with this.
>
> > 1) It uses basename, which is in /usr/bin. A number of scripts are
> > not booted after remote_fs, so they must set their path to not
> > include anything from /usr and the call to basename fails even when
> > /usr is mounted. I used ${0#/etc/init.d/} instead (note the trailing
> > "/", I always forget).
>
> Yep, that makes sense.
>
> > 2) More than just init scripts source lsb init functions. Most
> > notably: many of the ifupdown scripts. Using basename would give you
> > problems because /etc/network/ifup.d/openvpn is different from
> > /etc/init.d/openvpn, but I think the change to ${0#/etc/init.d/}
> > will cover this. If $0 is the ifup thing, it will remain the full
> > path, and initctl status will fail.
>
> What version of openvpn is this in?  The version in unstable certainly
> doesn't source /lib/lsb/init-functions from its ifupdown hook.  If it did,
> I'm not sure we should regard that as anything but a bug anyway.

Most hilarious example is that /etc/network/if-up.d/upstart sources
/lib/lsb/init-functions =) Just to get init_is_upstart function which
imho would be better handled by just doing a direct `initctl version`
check.

-- 
Regards,

Dimitri.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to