On Sat, Apr 4, 2015 at 3:43 PM, Ian Campbell <i...@debian.org> wrote:

> On Sat, 2015-04-04 at 14:48 +0200, reportbug wrote:
> > Package: qcontrol
> > Version: 0.5.4-1
> > Severity: normal
> >
> > After a recent wheezy->jessie upgrade, I noticed that qcontrol sometimes
> > fails to start on boot (or qcontrold? not sure what the difference is).
>
> qcontrold starts the qcontrol daemon at some point during the boot while
> qcontrol is supposed to run at the very end and signal that the system
> has finished booting, i.e. by turning the LEDs green, beeping or putting
> something on the LCD etc.
>
> AFAIUI under systemd what happens is that qcontrol.service runs qcontrol
> commands, which use /run/qcontrol.sock, which causes qcontrold.socket to
> kick in, which in turn causes qcontrold.service to run and start the
> daemon.
>

That’s correct.


>
> [...]
> > Apr 02 12:08:28 hostname qcontrol[617]: qcontrol 0.5.4 daemon starting.
> > Apr 02 12:08:28 hostname qcontrold[480]: Starting qcontrol daemon:
> qcontrol.
> > Apr 02 12:08:28 hostname qcontrol[617]: evdev: Error opening
> /dev/input/by-path/platform-gpio-keys-event: No such file or directory
> > Apr 02 12:08:28 hostname qcontrol[617]: register() - Error loading module
>
> I think this is probably the root cause, this path doesn't exist for
> some reason, so qcontrold doesn't start.
>
> Do you have that device path now? I suppose you must since a later
> manual start of qcontrold worked. If not then do you have anything
> similar (i.e. "tr - _" perhaps)?
>
> If you have the device then my guess would be that this indicates a
> missing dependency from qcontrold onto which ever bit of systemd should
> have loaded the module which provides this device.
>
> The qcontrold.service file contains:
>
> Requires=dev-input-by\x2dpath-platform\x2dgpio\x2dkeys\x2devent.device
>         After=dev-input-by\x2dpath-platform\x2dgpio\x2dkeys\x2devent.device
> which looks like it was intended to do the right thing.
>
> I know next to nothing about systemd, Michael, since you added this
> support do you have any clues what might be going wrong or what to look
> for next?
>
> http://www.freedesktop.org/software/systemd/man/systemd.device.html
> seems to imply that except for block+network and "a few others" some
> explicit configuration (TAG+="systemd") is needed to allow these
> dependencies. Perhaps /dev/input-by devices are not in the set of "a few
> others"?
>
> Thanks,
> Ian.
>
> > Apr 02 12:08:28 hostname systemd[1]: Started LSB: Start qcontrol daemon.
>

This line in the logfile indicates that systemd is using the sysvinit
script (hence the “LSB: ” prefix) of qcontrold, not the native systemd
service file.

The git log shows that 0.5.2 is the first version that is supposed to have
systemd service files, but actually, when I look at
https://packages.debian.org/jessie/armhf/qcontrol/filelist, I don’t see any
files in /lib/systemd/system/, which suggests that the Debian package
doesn’t install the systemd service files that upstream provides.

Ian, it seems like you should be following
https://wiki.debian.org/systemd/Packaging#Using_debhelper_with_dh_systemd
to get the package to properly pick up the systemd service files, at which
point this bug should be fixed.

I’ve added the systemd service files manually on my qnaps before I
contributed them upstream, hence I never ran into this issue.


> > Apr 02 12:08:36 hostname systemd[1]: qcontrol.service: control process
> exited, code=exited status=255
> > Apr 02 12:08:36 hostname systemd[1]: Unit qcontrol.service entered
> failed state.
> > Apr 02 12:08:36 hostname qcontrol[972]: System boot completed.
> > Apr 02 12:08:36 hostname qcontrol[972]: Error connecting to socket: No
> such file or directory
> > Apr 03 15:45:43 hostname qcontrol[17505]: System boot completed.
> > Apr 03 15:45:43 hostname qcontrol[17505]: Error connecting to socket: No
> such file or directory
> > Apr 03 15:45:43 hostname systemd[1]: qcontrol.service: control process
> exited, code=exited status=255
> > Apr 03 15:45:43 hostname systemd[1]: Unit qcontrol.service entered
> failed state.
> > Apr 03 15:47:20 hostname systemd[1]: Stopping LSB: Start qcontrol
> daemon...
> > Apr 03 15:47:20 hostname qcontrold[17602]: Stopping qcontrol daemon:
> qcontrol.
> > Apr 03 15:47:20 hostname systemd[1]: Stopped LSB: Start qcontrol daemon.
> > Apr 03 15:47:23 hostname systemd[1]: Starting LSB: Start qcontrol
> daemon...
> > Apr 03 15:47:23 hostname qcontrold[17624]: Starting qcontrol daemon:
> qcontrol.
> > Apr 03 15:47:23 hostname systemd[1]: Started LSB: Start qcontrol daemon.
> > Apr 03 15:47:23 hostname qcontrol[17628]: qcontrol 0.5.4 daemon starting.
> > Apr 03 15:47:23 hostname qcontrol[17628]: confdir: loading from
> /etc/qcontrol.d...
> > Apr 03 15:47:25 hostname qcontrol[17649]: System boot completed.
> > Apr 03 15:47:25 hostname qcontrol[17628]: System status: start
> > Apr 03 15:47:28 hostname qcontrol[17628]: ts41x: temperature 34
> > Apr 03 15:47:28 hostname qcontrol[17628]: ts41x: temperature 34 setting
> fan to "high"
> > Apr 03 15:47:33 hostname qcontrol[17628]: ts41x: temperature 34 setting
> fan to "medium"
> > Apr 03 15:47:38 hostname qcontrol[17628]: ts41x: temperature 34 setting
> fan to "low"
> > Apr 03 23:19:37 hostname qcontrol[17628]: ts41x: temperature 32
> > Apr 04 04:05:59 hostname qcontrol[17628]: ts41x: temperature 34
> > Apr 04 04:36:08 hostname qcontrol[17628]: ts41x: temperature 32
> > Apr 04 07:43:13 hostname qcontrol[17628]: ts41x: temperature 31 setting
> fan to "silence"
>
>
>


-- 
Best regards,
Michael

Reply via email to