Logid doesn't apply config on boot, when restarted works flawless

[supermar1010]

Hello,
first thanks for the great software!

Now my problem is I'm running arch and using the logiops git package from the aur, I recently updated so I'm on the newest version.
Problem is when logid starts while booting it fails to apply the config, systemctl status logid shows this:

logid.service - Logitech Configuration Daemon
     Loaded: loaded (/usr/lib/systemd/system/logid.service; enabled; vendor preset: disabled)
     Active: active (running) since Mon 2021-02-15 16:58:14 CET; 4min 34s ago
   Main PID: 582 (logid)
      Tasks: 6 (limit: 38430)
     Memory: 1.8M
        CPU: 8ms
     CGroup: /system.slice/logid.service
             └─582 /usr/bin/logid

Feb 15 16:58:14 mario-desktop systemd[1]: Started Logitech Configuration Daemon.
Feb 15 16:58:17 mario-desktop logid[582]: [WARN] Error adding device /dev/hidraw2: std::exception
Feb 15 16:58:17 mario-desktop logid[582]: [WARN] Error adding device /dev/hidraw1: std::exception
Feb 15 16:58:17 mario-desktop logid[582]: [WARN] Error adding device /dev/hidraw0: Invalid sub ID
Feb 15 16:58:18 mario-desktop logid[582]: [WARN] Error adding device /dev/hidraw2: open failed: No such file or directory
Feb 15 16:58:18 mario-desktop logid[582]: [WARN] Error adding device /dev/hidraw1: open failed: No such file or directory
Feb 15 16:58:20 mario-desktop logid[582]: [WARN] Error adding device /dev/hidraw4: std::exception
Feb 15 16:58:22 mario-desktop logid[582]: [WARN] Error adding device /dev/hidraw3: std::exception
Feb 15 16:58:22 mario-desktop logid[582]: [WARN] Error adding device /dev/hidraw0: Invalid sub ID

So it seems like it is trying to start but either failing to add the device or failing to see my unifying receiver.

After restarting my status looks likes this

logid.service - Logitech Configuration Daemon
     Loaded: loaded (/usr/lib/systemd/system/logid.service; enabled; vendor preset: disabled)
     Active: active (running) since Mon 2021-02-15 17:08:35 CET; 13s ago
   Main PID: 5095 (logid)
      Tasks: 7 (limit: 38430)
     Memory: 764.0K
        CPU: 16ms
     CGroup: /system.slice/logid.service
             └─5095 /usr/bin/logid

Feb 15 17:08:35 mario-desktop systemd[1]: Started Logitech Configuration Daemon.
Feb 15 17:08:37 mario-desktop logid[5095]: [WARN] Error adding device /dev/hidraw4: std::exception
Feb 15 17:08:38 mario-desktop logid[5095]: [WARN] Error adding device /dev/hidraw3: std::exception

So i guess it starts too early and the system did not detect my receiver yet

[Anghellos]

Same problem here. if i run sudo systemctl start logid after boot is working ok.
Any suggestion?

[ZzTriplett]

Same issue here. I was using my mouse over Bluetooth and it seemed to be working, but now I am using a unify receiver and it only works after a second run.

[tilldeathcoder]

Same issue here. I was using my mouse over Bluetooth and it seemed to be working, but now I am using a unify receiver and it only works after a second run.

I have the same problem when started to use the unifying device. No problems with Bluetooth only

[Cherkah]

same problem here too (... std::exception)
systemctl enable logid is set
occurs on unifying pc & bluetooth pc.

my logid.cfg :

devices: ({
2   │ name: "Wireless Mouse MX Master 3";
3   │ buttons: (
4   │ { cid: 0xc3;
5   │   action: { type: "ChangeHost"; host: "previous"; }
6   │ });
7   │ });

Manjaro + KDE

[ReillyBrogan]

I've noticed similar behavior when my mouse has gone to sleep due to inactivity. When I move it again and it wakes up the mouse defaults to default settings until I restart logid. I wonder if it's the same issue.

[Aditeya]

I've has the same issue at first, then i tried using sudo systemctl enable logid and that seems to have fixed the problem.

[ReillyBrogan]

@Aditeya All that command does is flag the service to be started on boot. If that fixes it for you then your issue was just that you forgot to do that in the first place (most services do not default to enabled when they are installed).

The rest of us are experiencing a different issue.

[Aditeya]

@ReillyBrogan I'm sorry, I should've been more clear. I meant that using sudo to start and enable the service, as opposed to just doing it as a regular user is what solved the problem for me.

[ReillyBrogan]

You know I just noticed this starting working perfectly for me again, and it got me wondering if this is something library related. My system is Solus which just updated a few packages, perhaps the latest Systemd fixes it? We went from 247.4 to 247.6.

[Aditeya]

I'm also getting the issue where if the mouse is left untouched it goes to powersave mode, and when I turn the computer on it doesn't apply the config. But if i move the mouse, which activates it, and then i turn it on the computer the config is applied.

[ReillyBrogan]

Yes, I wonder if my experience with it starting to work was just that I was touching the mouse before I started the computer.

IE, the root cause of this issue is that logid is seemingly not handling a mouse coming online.

[jixbo]

I'm facing a similar issue on Ubuntu 21.04, using the latest logiops.
I'm not getting a std::exception tho, I'm getting "Invalid function ID" when booting the laptop.

systemd[1]: Started Logitech Configuration Daemon.
logid[1893]: [WARN] Error adding device /dev/hidraw1: Invalid function ID
logid[1893]: [WARN] Error adding device /dev/hidraw1: Invalid function ID

After restarting the service, it works fine.

[kris7t]

I was experiencing similar issues under Arch linux with systemd 248rc4, but it went away after upgrading to systemd 248.

It seems the difference is that now the kernel module hid-logitech-hidpp.ko gets incorporated into my initramfs, so that the Logitech driver is initialized in early userspace.

[jixbo]

Seems like @kris7t was right. I have fixed the issue by adding hid-logitech-hidpp.ko to the initframfs.
For debian based distros, like ubuntu, the solution is to add hid-logitech-hidpp to /etc/initramfs-tools/modules file, then run sudo update-initramfs -u.

[ReillyBrogan]

Hmmm I'm not sure that's the correct solution in all cases. I am using Solus which pre-bakes the initramfs into the kernel package and that initramfs already contains the hid-logitech-hidpp module. It also doesn't explain why the mouse goes back to an unconfigured state when it wakes back up after being unused for a while.

I'm thinking there might be two separate issues at play here:

• Missing hid-logitech-hidpp module in the initramfs
• Logid not handling "wake" events from the mouse

I suspect that if the second issue was solved it would probably result in the first fix no longer being needed as well.

[jixbo]

I have tested not touching the mouse until the the system has booted, and I did not have any issue. There might be two separate issues.

[thiagolucio]

I solve this problem in Fedora 33 just made install use dnf "sudo dnf install logiops" and when restarting the problem it's solved. Need to wait a feel seconds (I'm don't count).
https://bodhi.fedoraproject.org/updates/?search=logiops

https://koji.fedoraproject.org/koji/buildinfo?buildID=1735923

In my case, the logiops start with system but don't have any practical effect.

I have libratbag install too. And I try stop this service because don't have any effect in my system and piper too. But I have the same problem yet.

I think the provisory solution it's input at the terminal when the system starts "sudo systemctl restart logid" because logid starts with the system but no have an effect and restarting made them force to up effectively.

[thiagolucio]

I believe I have discovered the problem. It does not run automatically when initializing because the "vendor" class of "systemctl" logid.service" has a "disable" status. When this value is disabled it does not start automatically, indicating that you need to do it manually. this status for vendor enabled, I'm still researching.
I found in Gnome (Fedora 33/34), the SystemdManager extension that allows you to manually add a service at startup or at least facilitate the manual process if necessary.

[ReillyBrogan]

@thiagolucio All that means is that the logid service shouldn't be automatically enabled when the package is installed, which I think is the better default. After all somebody installing it is going to need to create a config file anyway so there's no point in having it run until then.

[thiagolucio]

@thiagolucio Tudo isso significa que o serviço logid não deve ser habilitado automaticamente quando o pacote é instalado, o que eu acho que é o melhor padrão. Afinal, alguém que o instala vai precisar criar um arquivo de configuração de qualquer maneira, então não há por que executá-lo até então.

But I have the configuration file implemented in the correct place path. It's really a problem I think. But your opinion it's relevant because I don't think in this perspective. I created an alias in my bash to activate the service typing in terminal the command "mx" but I think in the past this service runs automatically right?

[ReillyBrogan]

@thiagolucio If you ran sudo systemctl enable logid then the service should start on boot (it does for me). Are you experiencing something different after running that command?

[thiagolucio]

@thiagolucio If you run sudo systemctl enable logid then the service should start on boot (it does for me). Are you experiencing something different after running that command?

Yes. I actually activated the service using this command. I actually researched a lot about it. If you look at the image of the service I posted earlier, you will see that the service is "enable". However, for not being able to force the "enable" of "vendor" in systemctl, it does not start automatically. If you look at the systemctl documentation you will see that "vendor" must be enabled for it to automatically start with the system. It is this problem that I am trying to solve. Anyone else experiencing this problem could do this same check by typing in the bash 'systemctl list-unit-files --state = enabled' and doing this check.

Actually, in my view, this is the service problem that is occurring in this ticket.

[ReillyBrogan]

@thiagolucio I did read the documentation. The vendor flag determines whether or not the service automatically starts after the service file is installed. However if a user uses systemctl enable or systemctl disable it overrides the vendor flag. So in your screenshot above where you show that the logid service is state enabled and vendor disabled then the service starts on boot. Changing the vendor flag doesn't change this behavior in any way.

[thiagolucio]

@thiagolucio I did read the documentation. The vendor flag determines whether or not the service automatically starts after the service file is installed. However if a user uses systemctl enable or systemctl disable it overrides the vendor flag. So in your screenshot above where you show that the logid service is state enabled and vendor disabled then the service starts on boot. Changing the vendor flag doesn't change this behavior in any way.

But that is exactly the problem that I noticed. As much as I apply the command "systemctl enable" the status of "vendor" does not change for the logid. It continues to disable. Why I don't know how to tell you. I just put this information in because I thought it might help in some way.

[Nicryc]

Any news on that ?
I've tried every solution proposed in this thread and none of them worked for me. Still have this issue, have to restart the service each time the mouse is disconnected.

I'm using the latest release 0.2.3 on Fedora 34 with Gnome 40.

[ReillyBrogan]

@Nicryc I don't believe anyone has figured it out yet. Unfortunately I'm not familiar enough with how HID works under Linux to properly know how to debug this and it doesn't seem that the dev has had the time/inclination lately to look at it (which is cool, this is a volunteer project after all).

If anyone has any idea of where to start feel free to let me know (breakpoints in the code? USB protocol capture?)

[ReillyBrogan]

@wooparadog I experimented with this a bit more and got it working with Wants=basic.target, After=basic.target, and WantedBy=graphical.target`. I still see some errors/exceptions in the logid service output however I'm no longer experiencing that it takes ~20 seconds after logging in before logid begins working with my mouse.

I think that might be a better compared to multi-user.target assuming it works for you as well. I think the errors are due to a race between systemd-udevd setting up the hidraw devices under /dev/ and the kernel mapping them to USB devices and can probably be ignored.

[thiagolucio]

@wooparadog I experimented with this a bit more and got it working with Wants=basic.target, After=basic.target, and WantedBy=graphical.target`. I still see some errors/exceptions in the logid service output however I'm no longer experiencing that it takes ~20 seconds after logging in before logid begins working with my mouse.

I think that might be a better compared to multi-user.target assuming it works for you as well. I think the errors are due to a race between systemd-udevd setting up the hidraw devices under /dev/ and the kernel mapping them to USB devices and can probably be ignored.

I believe my system has some wrong config or something like that. Just manually to start work. Back to the research from me.

[ReillyBrogan]

@wooparadog I was looking at the system journal and I noticed that systemd-logind also processes keyboard events. That service depends on user.slice and modprobe@drm.service. Experimentally I used those for Wants and After and the last few boots have had logid working as soon as I logged in. I'm not sure if those are the correct ones but it might be worth testing to see if it works for you too. It might be best to try to find whatever is the actual service dependencies just so we can have logid be ready sooner than later.

[thiagolucio]

I changed my operating system. I am now using Ubuntu LTS 20.04 and performed the installation. It is now operating normally as expected.
I believe the problem really was with my previous system. Fedora 34, Gnome 40.
In addition, in the new installation, the service is working as expected also in "vendor".

[ReillyBrogan]

You know I've half wondered if this might be related to GNOME 40. I'm running that as well.

[thiagolucio]

You know I've half wondered if this might be related to GNOME 40. I'm running that as well.

Yes. I thought the same. However, this may also be a recurrence of Fedora 34 itself. In this new version, there have been many changes in the system itself. Assuming btrfs by default, Wayland as a graphical manager, pipeware to manage the sound. Since installing Fedora 34, I have bitterly regretted having removed Fedora33 that I used before because it was extremely stable, while Fedora 34 went through a lot of problems, mainly with Wayland because it really is not yet stable as it should be to be a standard of any system. I believe that all changes in the Fedora 34 ecosystem for these new features in addition to Gnome 40 itself are causing problems with logiops.
In fact, I consider this problem solved because if it is necessary to solve the automatic activation problem in all distributions and all versions, it will never be done again. For those wishing to be premature adopter, they will have to be satisfied with experiencing this type of problem. In my case, as I use my notebook to work I found it more recommended to install an LTS, stable, and Debian distro again and the problem was solved.

[brunobmello25]

might be related to gnome 40 after all. I'm running arch and faced the same issue.

[bulletmark]

As a note to people who come here with this problem, the suggestion above is to change the systemd [Install] from WantedBy=multi-user.target to WantedBy=graphical.target, etc as described above. I am trialing that change myself now to fix this issue, but I should point out to others that it is not enough to simple re-enable the service after changing that. You must first disable the service and then re-enable it, e.g:

$ sudo systemctl daemon-reload
$ sudo systemctl disable --now logid
$ sudo systemctl enable --now logid

The reason is that the disable ensures that the old systemd "wants" symlinks are cleared out (it clears them all regardless of which were set) so it fixes the issue @ReillyBrogan mentioned.

[bulletmark]

Maybe it is a separate issue but after a resume from suspend I have to restart logid to make it apply my settings.

[wooparadog]

Notes for more debugging info: If you're still encountering this problem. You can check if logid is started at last stages of startup, especially after various udev jobs(search dev) by following command:

$ systemd-analyze plot > systemd.svg

There might be differences between all kinds of setups. You can change your systemd target accordingly.

[ReillyBrogan]

Interestingly a few times I've noticed that logiops will be working when I log in and will stop working a few seconds in. I wonder if we're seeing Gnome break it somehow?

[thiagolucio]

Interestingly a few times I've noticed that logiops will be working when I log in and will stop working a few seconds in. I wonder if we're seeing Gnome break it somehow?

Man. I suggest you install "Stacer" and put them to run manually (including vendor boolean to true).
https://github.com/oguzhaninan/Stacer

I think then solve this (and other's) problems you have around.

[Freder211]

I tried every solution on this thread, but couldn't manage to make it work. Anyone still having troubles with this issue?

distro: arch linux
wm: qtile

[thiagolucio]

I tried every solution on this thread, but couldn't manage to make it work. Is anyone still having trouble with this issue?

distro: Arch Linux wm: qtile

I don´t use Arch. But in this case, I think using the same solution including in Manjaro it's possible. Another solution you can try is installing Solaar in your system to have a redundancy solution.

https://archlinux.org/packages/community/any/solaar/
https://github.com/pwr-Solaar/Solaar

[wooparadog]

Update: this workaround doesn't work. I'm still trying to find the solution here..

---

:(

My solution stopped working recently, and it seems that a simple wait for udev is not good enough anymore.. I'm trying more solutions right now. If anyone is interested, you could help test if this works.

Basically, it's letting udev tagging input devices with systemd, and systemd can then involve those input devices into its dependency handling.

1. udev tagging: make a new rule for udev at /etc/udev/rules.d/99-input-tagging.rules

   ACTION=="add", KERNEL=="event*", SUBSYSTEM=="input", TAG+="systemd", , ENV{SYSTEMD_ALIAS}+="/sys/subsystem/input/devices/$env{ID_SERIAL}"
   

2. Reboot

3. Search for logitech related devices with systemctl list-units --type device| grep -i logi

4. Add that device to logid.service's unit section with systemctl edit logid.service

   After=sys-subsystem-input-devices-Logitech_USB_Receiver.device
   Wants=sys-subsystem-input-devices-Logitech_USB_Receiver.device
   

5. Reboot again to see if it works.

[thyarles]

graphical.target

Those steps worked for me, I just need to add sudo systemctl start logid on the end. After next reboot I'll tell you if it was a permanent solution.

[thiagolucio]

Too much time after this issue was created. This problem does not exist anymore.

[thyarles]

Too much time after this issue was created. This problem does not exist anymore.

Unfortunately the problem still here, at least for me after upgrade my Ubuntu to 22.04. Every day I need to start logid as root and keep an open terminal if I want to have it working...

[brunobmello25]

@thiagolucio this issue is still happening today. I'm always having to restart logid after the system boots

[thyarles]

@thiagolucio this issue is still happening today. I'm always having to restart logid after the system boots

@brunobmello25, so far this solution worked for me: #204 (comment) I did three reboots after that, still working. As I said here, I just needed to add a restart in to work on the first without rebooting.

[thiagolucio]

@thiagolucio this issue is still happening today. I'm always having to restart logid after the system boots

Sorry about that. In my case I don't use logiops anymore. I'm using Solaar. Works great no my Fedora.

[thyarles]

@thiagolucio this issue is still happening today. I'm always having to restart logid after the system boots

Sorry about that. In my case I don't use logiops anymore. I'm using Solaar. Works great no my Fedora.

@thiagolucio, are you using it on Wayland? I used to use Solaar on Ubuntu 20.04 LTS, but after the upgrade to 22.04 LTS it stopped working, so I migrate to Logiops.

[thiagolucio]

@thiagolucio this issue is still happening today. I'm always having to restart logid after the system boots

Sorry about that. In my case I don't use logiops anymore. I'm using Solaar. Works great no my Fedora.

@thiagolucio, are you using it on Wayland? I used to use Solaar on Ubuntu 20.04 LTS, but after the upgrade to 22.04 LTS it stopped working, so I migrate to Logiops.

I'm using the last version of Fedora (36). Fedora has used Wayland for a long time. Pipeware too. No problem at all.

[valerionew]

This would probably be fixed out of the box for everyone (if not everyone, for a large share of the people here) if a new version that includes the fix was released.

@PixlOne is there any particular reason why there is no release yet that includes 5947cc9?