Run as service via systemd

[CupricReki]

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

[alison-solsoft]

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.

[feschber]

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.

[alison-solsoft]

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.

[feschber]

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]

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

[CupricReki]

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

[feschber]

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.

[CupricReki]

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?

[feschber]

My latest commit broke it again. Have to fix asap

[feschber]

fixed

[feschber]

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]

[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]

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

[CupricReki]

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

Much appreciated!

[feschber]

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

[CupricReki]

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

[feschber]

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