[BRLTTY] Udev being fussy

[Keith Wessel]

Thanks, Dave. Yes, the thought did occur to me that the udev rules and the
system service might be working against each other. Am I correct that I
should either have brltty.service running or let system-udevd start and stop
brltty, but not both?

I thought that brltty, itself, had some polling built into it for
reconnects. Thanks for confirming that suspicion. Seems like running
brltty.service at start-up with a display of auto and a device of usb:
should be as good as anything for detecting reconnects. But I'm happy to go
either route on this.

The udev rules from /lib/udev/rules.d/70-brltty.rules is running /bin/brltty
directly, not a wrapper. I'm attaching it. There are no customized versions
of these rules in /etc/udev/rules.d, and these appear to have been installed
by the Gentoo ebuild of brltty-5.2-r1.

I'll also attach the system scripts for brltty from /lib/system/system.
Unlike my Centos server at work, my Gentoo system has a simple
brltty.service and no additional pieces. I suspect the extra pieces on my
Centos system which contains brltty 5.6 RPMS that I built myself from your
SRPMS might work better in a udev world.

Do you want the output of systemctl status brltty while it's running as a
service from a systemctl start brltty, or do you want me to send what ti
says when I let udev start brltty?

Thanks for the help with the detective work on this. I like system, but
there are days that I still miss the simplicity of openrc. :)

Keith


-----Original Message-----
From: BRLTTY <brltty-bounces at brltty.app> On Behalf Of Dave Mielke
Sent: Friday, February 1, 2019 2:05 PM
To: Informal discussion between users and developers of BRLTTY.
<brltty at brltty.app>
Subject: Re: [BRLTTY] Udev being fussy

[quoted lines by Keith Wessel on 2019/02/01 at 11:54 -0600]

>Since this new display is so portable, I'm sometimes disconnecting it 
>and taking it with me, but I find myself having to restart brltty to 
>get it to re-connect after plugging it back in. This, of course, was 
>because I was running brltty out of system on start-up, not letting the 
>udev rules start and stop brltty.

No, that can't be the reason because the driver does try to reclaim the
device.
Perhaps, though, there's a conflict between your manual starting of brltty
and the udev detection which, too, tries to start it.

>My problem is udevd seems to be randomly killing off brltty, even 
>though the display is still connected. It'll detect and start up brltty 
>but, several minutes later, it'll terminate.

Your log first says "taking too long", and then, a bit later, "killed". This
is what happens if the udev rules are there but the systemd unit isn't
started.
Ever since udev became a component of systemd it expects systemd to do the
scheduling and won't allow anything that it itself starts to run for very
long.

This being said, brltty does provide a udev-wrapper script that takes care
of this problem. I'm suspecting, therefore, that you don't have it. Also,
there are brltty systemd units which you also may not have. What does
"systemctl status btrltty" say?

Could you attach a copy of your brltty udev rules file (probably in
/etc/udev/rules.d/), as well as copies of brltty's systemd units (probably
in /usr/lib/systemd/system/), to a message so that we can have a look at
them?

--
I believe the Bible to be the very Word of God: http://Mielke.cc/bible/
Dave Mielke            | 2213 Fox Crescent | WebHome: http://Mielke.cc/
EMail: Dave at Mielke.cc  | Ottawa, Ontario   | Twitter: @Dave_Mielke
Phone: +1 613 726 0014 | Canada  K2A 1H7   |
_______________________________________________
This message was sent via the BRLTTY mailing list.
To post a message, send an e-mail to: BRLTTY at brltty.app For general
information, go to: http://brltty.app/mailman/listinfo/brltty
-------------- next part --------------
A non-text attachment was scrubbed...
Name: brltty.service
Type: application/octet-stream
Size: 382 bytes
Desc: not available
URL: <http://brltty.app/pipermail/brltty/attachments/20190201/2edddb2f/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 70-brltty.rules
Type: application/octet-stream
Size: 12014 bytes
Desc: not available
URL: <http://brltty.app/pipermail/brltty/attachments/20190201/2edddb2f/attachment-0001.obj>