[GH-ISSUE #76] Run as service via systemd

gitea-mirror commented

2026-05-05 22:04:55 -06:00

Owner

Originally created by @CupricReki on GitHub (Jan 15, 2024).
Original GitHub issue: https://github.com/feschber/lan-mouse/issues/76

Here is an example service file. Connection still needs to be activated via GUI until #70 is sorted.

/usr/lib/systemd/user/lan-mouse.service

[Unit]
Description=Mouse & keyboard sharing via LAN
Wants=network-pre.target
After=network-pre.target NetworkManager.service systemd-resolved.service

[Service]
ExecStart=/usr/bin/lan-mouse -d
Restart=on-failure

[Install]
WantedBy=multi-user.target

Start now and on boot

systemclt --user daemon-reload
systemctl --user enable --now lan-mouse.service

Originally created by @CupricReki on GitHub (Jan 15, 2024). Original GitHub issue: https://github.com/feschber/lan-mouse/issues/76 Here is an example service file. Connection still needs to be activated via GUI until #70 is sorted. ``` /usr/lib/systemd/user/lan-mouse.service ``` ``` [Unit] Description=Mouse & keyboard sharing via LAN Wants=network-pre.target After=network-pre.target NetworkManager.service systemd-resolved.service [Service] ExecStart=/usr/bin/lan-mouse -d Restart=on-failure [Install] WantedBy=multi-user.target ``` Start now and on boot ``` systemclt --user daemon-reload systemctl --user enable --now lan-mouse.service ```

gitea-mirror closed this issue

2026-05-05 22:04:57 -06:00

gitea-mirror commented

2026-05-05 22:04:58 -06:00

Author

Owner

@alison-solsoft commented on GitHub (Jan 15, 2024):

This lines up with what I had created on my own end for a user daemon unit. Do we also want to consider the option of a system daemon unit, which would require both a global config path (/etc/lan-mouse/config.toml) and dedicated daemon user (lanmouse)?

I have a specific use case that will require either enabling lingering on my user session on one of my systems, or running the service under the system daemon. Using session lingering isn't a terrible solution, but it isn't obvious to less-experienced Linux users that lingering is even an option.

@alison-solsoft commented on GitHub (Jan 15, 2024): This lines up with what I had created on my own end for a user daemon unit. Do we also want to consider the option of a system daemon unit, which would require both a global config path (/etc/lan-mouse/config.toml) and dedicated daemon user (lanmouse)? I have a specific use case that will require either enabling lingering on my user session on one of my systems, or running the service under the system daemon. Using session lingering isn't a terrible solution, but it isn't obvious to less-experienced Linux users that lingering is even an option.

gitea-mirror commented

2026-05-05 22:04:59 -06:00

Author

Owner

@feschber commented on GitHub (Jan 15, 2024):

A system service will not work because lan-mouse does not wait for a session to come online and simply falls back to the dummy backend. I would need to implement a way to wait for a session first. (Using systemd?)

I have been thinking about how that could be done but it will definitely take some effort. Maybe something similar to how rkvm works.

@feschber commented on GitHub (Jan 15, 2024): A system service will not work because lan-mouse does not wait for a session to come online and simply falls back to the dummy backend. I would need to implement a way to wait for a session first. (Using systemd?) I have been thinking about how that could be done but it will definitely take some effort. Maybe something similar to how rkvm works.

gitea-mirror commented

2026-05-05 22:05:01 -06:00

Author

Owner

@alison-solsoft commented on GitHub (Jan 15, 2024):

Upon further review, I have an additional thought:

Is there a reason you used "network-pre.target " rather than simply "network.target"? I think it would be better to avoid tying service ordering to specific network management services, as that can potentially lead to issues for users of other network daemons (e.g. netctl in my case). If it's a startup delay concern, I don't think ordering against network.target would drastically increase startup times, at least not as much as network-online.target.

@alison-solsoft commented on GitHub (Jan 15, 2024): Upon further review, I have an additional thought: Is there a reason you used "network-pre.target <network services>" rather than simply "network.target"? I think it would be better to avoid tying service ordering to specific network management services, as that can potentially lead to issues for users of other network daemons (e.g. netctl in my case). If it's a startup delay concern, I don't think ordering against network.target would drastically increase startup times, at least not as much as network-online.target.

gitea-mirror commented

2026-05-05 22:05:02 -06:00

Author

Owner

@feschber commented on GitHub (Jan 15, 2024):

Upon further review, I have an additional thought:

Is there a reason you used "network-pre.target " rather than simply "network.target"? I think it would be better to avoid tying service ordering to specific network management services, as that can potentially lead to issues for users of other network daemons (e.g. netctl in my case). If it's a startup delay concern, I don't think ordering against network.target would drastically increase startup times, at least not as much as network-online.target.

Network should actually not be necessary at all, as lan-mouse is connection less and simply starts working as soon as a network is connected. It should however be ensured that a graphical session is running. I'm guessing graphical-session.target would be the right choice. Aside from that, there may still be a race condition between dbus an the lan-mouse service. I will need to look into that.

@feschber commented on GitHub (Jan 15, 2024): > Upon further review, I have an additional thought: > > Is there a reason you used "network-pre.target " rather than simply "network.target"? I think it would be better to avoid tying service ordering to specific network management services, as that can potentially lead to issues for users of other network daemons (e.g. netctl in my case). If it's a startup delay concern, I don't think ordering against network.target would drastically increase startup times, at least not as much as network-online.target. Network should actually not be necessary at all, as lan-mouse is connection less and simply starts working as soon as a network is connected. It should however be ensured that a graphical session is running. I'm guessing `graphical-session.target` would be the right choice. Aside from that, there may still be a race condition between dbus an the lan-mouse service. I will need to look into that.

gitea-mirror commented

2026-05-05 22:05:02 -06:00

Author

Owner

@feschber commented on GitHub (Jan 15, 2024):

Same goes for DNS. We probably should not assume that systemd-resolved is used either way.

@feschber commented on GitHub (Jan 15, 2024): Same goes for DNS. We probably should not assume that systemd-resolved is used either way.

gitea-mirror commented

2026-05-05 22:05:03 -06:00

Author

Owner

@CupricReki commented on GitHub (Jan 15, 2024):

All good reasoning. Makes sense to exclude all the Wants/After. It was mostly there based on the example I was using.

@CupricReki commented on GitHub (Jan 15, 2024): All good reasoning. Makes sense to exclude all the Wants/After. It was mostly there based on the example I was using.

gitea-mirror commented

2026-05-05 22:05:04 -06:00

Author

Owner

@feschber commented on GitHub (Jan 16, 2024):

It should now be possible to automate everything. Tell me if you notice any bugs :) And also feel free to open a PR for the user service.

@feschber commented on GitHub (Jan 16, 2024): It should now be possible to automate everything. Tell me if you notice any bugs :) And also feel free to open a PR for the user service.

gitea-mirror commented

2026-05-05 22:05:04 -06:00

Author

Owner

@CupricReki commented on GitHub (Jan 16, 2024):

Great news! I'll give it a go this evening. Have you thought about adding a daemon option to the GUI and/or a tray icon?

@CupricReki commented on GitHub (Jan 16, 2024): Great news! I'll give it a go this evening. Have you thought about adding a daemon option to the GUI and/or a tray icon?

gitea-mirror commented

2026-05-05 22:05:05 -06:00

Author

Owner

@feschber commented on GitHub (Jan 16, 2024):

My latest commit broke it again. Have to fix asap

@feschber commented on GitHub (Jan 16, 2024): My latest commit broke it again. Have to fix asap

gitea-mirror commented

2026-05-05 22:05:06 -06:00

Author

Owner

@feschber commented on GitHub (Jan 16, 2024):

fixed

@feschber commented on GitHub (Jan 16, 2024): fixed

gitea-mirror commented

2026-05-05 22:05:07 -06:00

Author

Owner

@feschber commented on GitHub (Jan 16, 2024):

Have you thought about adding a daemon option to the GUI and/or a tray icon?

I initially had a (non functional) switch as a mockup and removed that. Technically I could add that back but that would break the "normal" way of running lan-mouse where the service is started as a child process and terminated when the gui exits. I also want to eventually implement the service functionality with the background / autostart portal which is probably more userfriendly, would work with flatkap and also would not require a toggle.

As for the system tray: I have not thought about it yet. I will add it to my list.

@feschber commented on GitHub (Jan 16, 2024): > Have you thought about adding a daemon option to the GUI and/or a tray icon? I initially had a (non functional) switch as a mockup and removed that. Technically I could add that back but that would break the "normal" way of running lan-mouse where the service is started as a child process and terminated when the gui exits. I also want to eventually implement the service functionality with the [background / autostart portal](https://flatpak.github.io/xdg-desktop-portal/docs/doc-org.freedesktop.portal.Background.html) which is probably more userfriendly, would work with flatkap and also would not require a toggle. As for the system tray: I have not thought about it yet. I will add it to my list.

gitea-mirror commented

2026-05-05 22:05:07 -06:00

Author

Owner

@feschber commented on GitHub (Jan 16, 2024):

[Unit]
Description=Mouse & keyboard sharing via LAN
After=graphical-session.target

[Service]
ExecStart=/usr/bin/lan-mouse --daemon
Restart=on-failure

[Install]
WantedBy=graphical-session.target

Did some testing my self. The above seems to work for me. After=graphical-session.target must be specified as After, if it were Required it does not work (because lan-mouse would start at the same time).

@feschber commented on GitHub (Jan 16, 2024): ```ini [Unit] Description=Mouse & keyboard sharing via LAN After=graphical-session.target [Service] ExecStart=/usr/bin/lan-mouse --daemon Restart=on-failure [Install] WantedBy=graphical-session.target ``` Did some testing my self. The above seems to work for me. `After=graphical-session.target` must be specified as `After`, if it were `Required` it does not work (because lan-mouse would start at the same time).

gitea-mirror commented

2026-05-05 22:05:08 -06:00

Author

Owner

@feschber commented on GitHub (Jan 16, 2024):

There was one final bug that prevented it from working (forgot to do an initial dns request ...)

@feschber commented on GitHub (Jan 16, 2024): There was one final bug that prevented it from working (forgot to do an initial dns request ...)

gitea-mirror commented

2026-05-05 22:05:09 -06:00

Author

Owner

@CupricReki commented on GitHub (Jan 17, 2024):

Works perfectly for me with the activate_on_startup = true option in the config.

Much appreciated!

@CupricReki commented on GitHub (Jan 17, 2024): Works perfectly for me with the `activate_on_startup = true` option in the config. Much appreciated!

gitea-mirror commented

2026-05-05 22:05:10 -06:00

Author

Owner

@feschber commented on GitHub (Jan 21, 2024):

If you want, you could update the AUR packages @CupricReki

@feschber commented on GitHub (Jan 21, 2024): If you want, you could update the AUR packages @CupricReki

gitea-mirror commented

2026-05-05 22:05:11 -06:00

Author

Owner

@CupricReki commented on GitHub (Feb 17, 2024):

So I'm thinking, install the systemd unit but don't enable it.

@CupricReki commented on GitHub (Feb 17, 2024): So I'm thinking, install the systemd unit but don't enable it.

gitea-mirror commented

2026-05-05 22:05:12 -06:00

Author

Owner

@feschber commented on GitHub (Feb 18, 2024):

Yeah, it should not be enabled by default. Especially since the Input Capture / Emulation popups show up every restart on e.g. Gnome Desktop.

@feschber commented on GitHub (Feb 18, 2024): Yeah, it should not be enabled by default. Especially since the Input Capture / Emulation popups show up every restart on e.g. Gnome Desktop.

gitea-mirror referenced this issue

2026-05-05 22:07:23 -06:00

[GH-ISSUE #139] Custom global/host hotkeys #60

gitea-mirror referenced this issue

2026-05-05 22:08:01 -06:00

[GH-ISSUE #164] Feature Request: Support for one-way control #72

gitea-mirror referenced this issue

2026-05-05 22:13:02 -06:00

[GH-ISSUE #354] First time user feadback, feature request(and a bug?) #183

Rows
Columns

[GH-ISSUE #76] Run as service via systemd #26