[Pkg-sysvinit-devel] Bug#636054: [Pkg-xfce-devel] Bug#636054: Bug#636054: The lightdm service can't be handled by the "service" utility

[Fernando Lemos]

2011/8/1 Yves-Alexis Perez <corsac at debian.org>:
> reassign 636054 sysvinit-utils
> thanks
>
> On lun., 2011-08-01 at 10:51 +0200, Yves-Alexis Perez wrote:
>> On sam., 2011-07-30 at 12:14 -0300, Fernando Tarlá Cardoso Lemos wrote:
>> > I think the problem is that the lightdm package installs an upstart
>> > init
>> > script. /usr/sbin/service thinks upstart is available and fails to
>> > start
>> > lightdm:
>> >
>> > fernando at munchkin:~$ sudo service openntpd restart
>> > Restarting openntpd: ntpd.
>> > fernando at munchkin:~$ sudo service lightdm restart
>> > exec: 129: restart: not found
>> > fernando at munchkin:~$
>> >
>> > I guess this bug could also have been filed against sysvinit-utils,
>> > but
>> > on the other hand, I'm not sure we're supposed to be shipping upstart
>> > init files yet. The "service" utility has no problem whatsoever with
>> > packages that ship systemd init files (and it works with systemd), but
>> > seems to choke on upstart init files.
>>
>> I've taken the time to look a bit more at this and I'm wondering. Why do
>> you think this has anything to do with /etc/init/lightdm?
>>
>> 'service' seems to try to execute 'restart' instead of calling the right
>> script with argument, but that looks completely unrelated to upstart
>> files.
>
> Replying to myself: because 'service' has a compatibility layer for
> upstart which I don't get at all:

Hi,

The "start", "restart" and "status" binaries are in the upstart
package. I don't disagree with your point, I think "service" should
have handled that better (not sure how, tbh). The only reason I filed
this against lightdm is that this is the first time "service" fails
like this for me, so I believe other packages shipping upstart init
files might be doing something different (or not shipping upstart init
files at all).

I guess a simple "fix" would be checking if the "action" binary is
executable (test -x /sbin/start or something like that), and if that
fails, fall back to invoking the init script directly.

Regards,