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 <[email protected]> On Behalf Of Dave Mielke Sent: Friday, February 1, 2019 2:05 PM To: Informal discussion between users and developers of BRLTTY. <[email protected]> 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: [email protected] | 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: [email protected] For general information, go to: http://brltty.app/mailman/listinfo/brltty
brltty.service
Description: Binary data
70-brltty.rules
Description: Binary data
_______________________________________________ This message was sent via the BRLTTY mailing list. To post a message, send an e-mail to: [email protected] For general information, go to: http://brltty.app/mailman/listinfo/brltty
