That might be the case, but I don’t know how the process can start again even after a full reboot, not even as a zombie process. As for now it uses around 6-8MB of ram, which is kinda baffling ; what binary is even running under that process
What’s the modern-day equivalent for this 
? On Arch wiki and forums would be hard to find this issue since we EnOS use dracut instead of mkinitcpio
Sorry man, but on https://brltty.app/guidelines.html looking good to know… for my mistake 
Alternative is looking in brltty package source for understanding how is started from initramfs image… it’s very annoying task indeed.
I think the modern equivalent would just be the systemd journal. You could try:
journalctl -b | grep brltty
Oh, and you can try to install ‘linux-lts’ first, for trigger another rebuild of dracut stuff yeah.
lmao my dumbass brain forgot to grep the journalctl. Thank you for reminding me. It did show dracut-cmdline service starting the brltty process. So definitely related to dracut.
And it fix it! 
I just reinstalled both main linux and linux-zen kernel. Somehow the dracut-rebuild command probably didn’t replace the existing init img. The ghost process no longer starts.
To recap for future me reading this, because this will definitely happen again and I’ll probably forget about it.
I resorted to
printf "omit_dracutmodules+=" brltty "\n" >> /etc/dracut.conf.d/nobrltty.conf
dracut-rebuild