espanso-wayland: service start failure #249364
Comments
|
@bobvanderlinden I am only tagging you as if I remember correctly, the wayland support/update to the 2.x series was added by you. If not, please ignore. 👍 Thank you. |
|
I think this is related to this espanso/espanso#1638 |
|
I'm guessing the espanso service needs a wrapper. Wireshark does the following for its Instead of dumpcap, espanso needs Maybe alternatively it might be better for systemd to set the capability. It seems https://www.freedesktop.org/software/systemd/man/systemd.exec.html#CapabilityBoundingSet= should be able to do so. |
|
I see I forgot to add that I'm not running wayland. I tried espanso's wayland support under xorg, but I'm not sure about the full wayland integration. I'm probably not the right person to look into this. |
|
Any update on this ? I've got the same issue. |
|
Any news on this issue? |
|
Is there any process to mark the package as "broken" until the maintainers can look at it? |
|
The package itself doesn't seem to be broken. Last time I tried to run espanso-wayland in Weston within Xorg. That seemed to work. It is possible to fail when (It would still be great if someone with a Wayland setup could look into the .service file/configuration 😅) |
|
Well, what I meant by "broken" is that the software itself does not work in its current state. I had a look for the service file, and they seem to have: I also ran the wrapper direct and received: Thank you. |
|
Ah sorry, I'm using Espanso integration from home-manager, which seems to be working fine. I'm not sure whether Espanso needs to be run as root (on system level) or as part of the user. I thought the latter. Maybe the Espanso service in NixOS needs to be removed eventually? |
|
ok, I was not running it with home-manager. Do you have a repo with your config? Happy to move it over and test. |
|
This is how I enable espanso in home-manager: https://github.com/bobvanderlinden/nixos-config/blob/5ea926a81216691364c10071b173b68b59bdea82/home/default.nix#L273 |
|
Any updates on this? |
|
So the core problem is that Espanso binary doesn't get proper capabilities. In the world of ordinary UNIX'es it's just a
Becoming tired of it I've resorted to a hack... TLDR 🥳Here's what I've put into my Home Manager config: In order for this to work I had to perform the following as well:
This is obviosly a hack, and will most likely break and require me to fix those Espanso binaries with mostly every update. However, this is the problem of the future Homer (tm). |
|
My draft PR #328890 may resolve this issue. It uses the |
|
@pitkling |
|
@GimmeDataNow Sorry for the delayed answer, I was a bit busy. The original draft PR was probably difficult to use without using my fork directly. But I recently updated the PR, it is now just a simple NixOS module. One should be able to copy the directory With this, other modules can simply use |
|
Thank you very much! It is working :). A quick note: This is probably due to an error on my part, but this resolves it regardless |
|
Glad it works :). The infinite recursion seems strange. Were you using the overlay I posted? In that case, you indeed have to also use |
That's amazing! I assume it's just waiting for merge, etc.... |
We're not quite there yet w.r.t. the merge. I discussed with @n8henrie and there are some valid concerns whether this is the best/correct way to enable user-space espanso, even though it seems the best solution we have so far. If it were to be merged, it still needs some cleanup. Anyway, @robryk was so nice to also take a look, since the underlying problem that prevents to simply use In any case, if the draft PR is not merged, I might just provide a flake with the module, so at least it will become easier to use this until we have a proper solution. |
|
@pitkling I think the idea of getting this built into security.wrappers would make a lot of sense -- if using |
|
Hmm, actually is this already supposed to work? e355020 |
@n8henrie I would also say so, although integrating this into security.wrappers might be somewhat subtle and not so simple. I played around a bit and there seem to be some obstacles to get this to work reliably. So I guess discussing this in a separate issue with the corresponding devs seems reasonable. I only first want to wait and see if @robryk confirms my guess for the cause of this in my draft PR #328890 (and maybe sees an immediate solution).
Kind of, although this does not work in the case of espanso. If I understand the implementation of security.wrappers correctly, the patched line that commit references raises the correct capabilities into the ambient set (to ensure that capabilities are inherited by forks). However, the problem is that espanso drops its capabilities (and with them, the capabilities in the ambient set!) and relies on file capabilities when forking itself (via |
|
That's right, thanks for refreshing my memory. (BTW your technical writing is excellent -- very approachable and readable! In spite of your humility, I think you understand this much better than me.)
Just out of curiosity, looks like you may be primarily on darwin? (guessing -- one of your popular repos appears to be for Hammerspoon). One of my few NixOS machines that uses a graphical desktop is my dual-boot Asahi Macbook, on which I'm primarily running macOS -- reluctance to close down all my open tabs and windows to reboot into NixOS has definitely slowed my participation here. A few things I'll tinker on:
Alternatively, maybe a PR to espanso to drop capabilities post-fork (instead of pre-fork) could be considered? |
No worries, we all have to do enough other things in real life; and I can definitely relate wrt the tabs 😆. But yes, I'm primarily on Darwin, using Linux mostly for hobby projects like tinkering with some Raspberry Pies.
I think so after looking into the code. It seems
I don't think that'll work.
Hm, this might be difficult. It seems that Also, it seems actually a valid design choice for an app to rely on file capabilities together with the capabilities in the ambient set to reduce the potential attack area. So even if one could change espanso to avoid it, the problem might surface in other places. It would be good to have some way to deal with it. If not possible in general by |
|
@pitkling -- I have espanso running (including forms and the UI) under KDE Plasma / Wayland using just the Can you try and see if you can confirm?
|
|
Actually, I didn't copy verbatim -- I used |
On Wayland, Espanso depends on `cap_dac_override+p` for the EVDEV backend. Specifically, this capability is required by the `worker` thread, which is forked from the main espanso process when run by the usual means (`espanso start` or `espanso daemon`). Espanso (responsibly) drops capabilities as soon as possible, prior to forking the worker process. Unfortunately, `security.wrappers` sets the capabilities in such a way that the forked process does not pick up these capabilities (due to `/proc/self/exe` pointing to the original espanso binary, which does *not* have these capabilities). By running `worker` directly from the capability-enabled wrapper, the worker thread is able to run without issue, and Espanso runs as expected on wayland. - NixOS#249364 - NixOS#328890 - https://espanso.org/docs/install/linux - fixes NixOS#249364
Indeed, launching the worker directly with the security wrapper should avoid all the problems I described before. I tried that myself when I first looked into this issue and basic functionality was there. However, I did not do any extensive testing. I see two potential problems with this approach:
So even if it seems to work, we might easily be breaking some stuff without us noticing right away. Even if it works now, it might break future features if some internals change. |
You're likely correct, I only know about it from months worth of digging to figure out #247162 / espanso/espanso#1946
True, but the nix input won't change until we change it. I've been trying to help the espanso team here and there; there's been talk about a big-ish refactor of the GUI to remove the wx dependency, but I haven't heard of any immediate plans for a major refactoring of the backend. (EDIT: espanso roadmap)
Good point, I need to double check this. Requiring manual reload to pick up config changes would be a bit of a bummer (since they've already done the work to make this smoother). The systemd unit should be automatically restarting on failure, which might obviate the need for some of their checks.
That's of course possible, though I'm not sure what approach could prevent upstream changes from breaking the always-unconventional nix way. I also wonder why they're using ffi to get the executable path: https://github.com/espanso/espanso/blob/fd9a7dd4f2afccaeb61623286b1230c0df0c7033/espanso-info/src/x11/native.cpp#L138 as opposed to Actually, nevermind: https://github.com/espanso/espanso/blob/fd9a7dd4f2afccaeb61623286b1230c0df0c7033/espanso/src/path/linux.rs#L71 Looks like we might be able to spoof the executable path with |
|
In case it helps anyone, this is my current config for espanso that's been working for me: # Allow input access of espanso
security.wrappers.espanso = {
source = "${pkgs.espanso-wayland}/bin/espanso";
capabilities = "cap_dac_override+p";
owner = "root";
group = "root";
};
services.espanso.enable = true;
systemd.user.services.espanso = {
serviceConfig.ExecStart = lib.mkForce "/run/wrappers/bin/espanso worker";
# Commands needed for expansions:
path = with pkgs; [
bash
dig
gopass
];
}; |
|
@KenMacD thanks for chiming in -- @pitkling brings up some reasonable concerns, in my mind most relevant for whether this affects the current functionality of espanso.
|
Umm… I've had it running on and off for most of the last year, iirc. In the past I did run in to some issues around espanso showing a rainbow screen, so I had to locally bump the version for that. When it's not working in NixOS as a service I've just keep a
Sorry, only NixOS
No, it doesn't currently pick up change to the config files. I don't change them very often though. It also doesn't pick up when I put in another keyboard. In both cases I just Not saying my solution is the best solution or anything. Just posting it as a workaround for people. One thing that would be nice to have in the module would be have an easy way to add things to the path. It took me a bit to figure out why my |
I finally got around to create a flake that exports the module from my PR #328890. So while we're waiting for one of the pending PRs #328890/#339594 (or a different one) to be finalized and merged, it should now be possible to get Espanso to work under Wayland simply by:
Some notes:
|
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/espanso-daemon-problem/35309/27 |
|
why do i get attribute wayland missing this config ? |
Are you on NixOS 24.05? If so, then it is because the |
okay |
|
Espanso works for me under Wayland with integrated GPUs from Intel or AMD (didn't need With an NVIDIA GPU it panics with:
|
@pbek Hmm, strange that the GPU seems to make a difference here. My laptop (Dell Latitude 7440) comes with an integrated Intel GPU and does experience the Wayland problems described in this thread. Are you sure there is no other difference between the systems that could cause the problems? Or maybe there is even a problem with the GPU detection in general on the NVIDIA system? What does |
|
This the log on an Intel GPU Laptop: On my main working machine, I switched back to X11, because not having Espanso is not an option. 😁 They use almost the same nixcfg (see above links). |
|
@pbek: I had a quick look at your config. I think I know at least why it is working on some of your systems under Wayland for you without the fix from this thread. You already have another workaround for the Wayland issue in your configuration. The Concerning your problem with the NVIDIA GPU: That's probably a different problem. I'd suggest to open a new issue and, if possible, somehow get a more complete log file for the failing machine via |
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/home-managers-espanso-module-does-not-create-config-directory/51170/14 |
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/using-espanso-on-wayland-nixos/55268/2 |
|
This issue has been mentioned on NixOS Discourse. There might be relevant details there: https://discourse.nixos.org/t/prs-ready-for-review/3032/4910 |
Describe the bug
A clear and concise description of what the bug is.
The service will not start properly. Resulting in Espanso not working. Running
journalctl --user -u espanso -eI can see the following:The Espanso
Steps To Reproduce
Steps to reproduce the behavior:
espanso-waylandviaenvironment.systemPackages = with pkgs; [services.espanso.enable = true;systemctl --user restart espansosystemctl --user status espansojournalctlwithjournalctl --user -u espanso -eand you will see the above error.Expected behavior
Additional context
This is expected, but:
Notify maintainers
@kimat
@theHedgehog0
Metadata
Please run
nix-shell -p nix-info --run "nix-info -m"and paste the result.Thank you.
The text was updated successfully, but these errors were encountered: