On Mon, Nov 17, 2014 at 11:42:51PM +0000, Roger Lynn wrote:
> >>> strace shows:
> >>> 17912 --- SIGTERM {si_signo=SIGTERM, si_code=SI_USER, si_pid=18045,
> >>> si_uid=0} ---
> >>> 17912 rt_sigaction(SIGTERM, {0x402cb0, [TERM], SA_RESTORER|SA_RESTART,
> >>> 0x7f779b2aec30}, {0x402cb0, [TERM], SA_RESTORER|SA_RESTART,
> >>> 0x7f779b2aec30}, 8) = 0
> >>> 17912 rt_sigreturn() = 0
> >>> 17912 read(3, <unfinished ...>
> >>> 17912 +++ killed by SIGKILL +++
> >
> > This is
> > ret = read(freefall_fd, &count, sizeof(count));
> > line 1249 from hdapsd.c
> >
> >>> Adding some debugging output, the SIGTERM handler is called, but the
> >>> while loop is not stopped, as the new "running" value doesn't find its
> >>> way into the main process. But here, my coding skills stop, sorry.
> >
> > read() blocks until there is something to read from /dev/freefall.
> >
> >> I started looking at this yesterday, but ran out of time. I assume the
> >> code is getting stuck in a loop or function call, which means it never
> >> returns to the main while loop in main(). This is slightly worrying: if
> >> the main loop is not running does that meant the hard disc protection is
> >> not working?
> >
> > No, it should be working, because in the case the hardware logic detects
> > a fall, the read will unblock.
>
> I can confirm that shaking the laptop while waiting for hdapsd to to
> terminate does make it unblock.
Thanks. Could you please test the following patched version:
https://people.debian.org/~evgeni/tmp/hdapsd_20141024-3~test1_amd64.deb
What I do not really understand: read() should be interrupted on
SIGTERM/SIGUSR1, so we already should jump out of the loop!?
Greets
Evgeni
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
