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.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
