Can I use this with xmonad as window manager?

[sollymay]

hey @rbreaves first of all, wanted to give you a huge thank you for this project. I got myself already too used to the macOS like shortcuts and running this on linux has been a lifesaver.

I have been starting to experiment a bit with xmonad, and got myself very comfortable using it, and now would love to be able to use xmonad as my window manager but keep all my mappings with the standard kinto.sh script. I thought to myself, well, it should work since both kinto and xmonad use x11, so what could go wrong.

Essentially, when I try to run Kinto on xmonad, the window shows, but then, nothing happens. then if i restart the service, i get an issue with xhost not able to open display :1

Do you know if there's a way to make this work?

Thank you for your help and again, love the project and will soon support it as well!

[RedBearAK]

Essentially, when I try to run Kinto on xmonad, the window shows, but then, nothing happens. then if i restart the service, i get an issue with xhost not able to open display :1

@sollymay

I'm just another Kinto user, mainly, but I've run into this kind of problem on different distros. Sometimes it can be fixed by re-running the Kinto installer script. Don't ask me why, because I have no idea. Sometimes that only works until you reboot or restart the Kinto service.

Be aware that re-running the installer will overwrite your kinto.py config file, so have a backup of the config file if you have any customization in yours, then copy it back to kinto.py to overwrite the new one, and restart Kinto.

You don't say what Linux distribution you're using, or if you were already using Kinto in another DE/WM on that same distro before attempting to use it in xmonad. The DE/WM is usually not a big deal, other than possibly needing tweaks to some of the shortcuts, but usually what needs tweaking is the shortcut on the DE/WM side to match Kinto's existing shortcuts for things like Cmd+Tab. You'll see in the config file there are options for GNOME, KDE, XFCE that will get enabled by the installer. For something else like xmonad you're kind of on your own, but I'm sure it can be made to work.

On a couple of distros I've had to move Kinto from running as root from a systemd service to running as user, but that's a somewhat complicated procedure involving putting the user in uinput group and making some scripts and desktop entry files to make it all work. First thing to try is just re-running the Kinto installer, which you can do right from the Downloads/kinto-master folder with setup.py, if you didn't delete the folder.

Edit: Didn't look closely enough at the screenshot, of course it says Fedora. I do think that re-running the Kinto installer should fix it. That has worked for me recently on Fedora. But you should at least restart afterward, after cofirming that Kinto is working, to make sure it stays working after the reboot.

What I usually do to test that Kinto is really working the way I expect is to open a terminal app that supports tabs (with Ctrl+Shift+T without Kinto), and do Cmd+T a few times and then Cmd+Shift+Left_Brace/Right_Brace to make sure that I can open new tabs, move between them, and then close the new tabs with Cmd+W.

[sollymay]

Hey @RedBearAK that was more than enough to at least start the troubleshooting process. What's interesting is that I can run this on gnome for fedora 35 no problem, but as soon as I try running it in xmonad is when the service starts misbehaving. Maybe it's time to rerun the script and try all over again but this time doing it from within xmonad itself. Will post any progress here and thanks for the suggestions!

[RedBearAK]

@sollymay

FYI, make sure you do a full system update on F35 before attempting to upgrade F35 to F36. There was an annoying situation with SELinux containers or something that hit a lot of people who attempted the upgrade early (including me) and has caused the devs to delay the official release of F36 temporarily. Should be OK as long as you do a full update on F35 and then reboot before attempting to do the F36 upgrade (when it's officially released).

[rbreaves]

I’ve yet to play around w/ any tiling manager, xfce w/ zentile is as close I’ve gotten to it.

I’ll have to try xmonad & i3 sometime - possibly a weekend to debug it. You may want to checkout what ID your display environment var echos back in your terminal/user session. Make sure it matches the one that’s hard coded in the xkeysnail.service file.

echo $DISPLAY

[sollymay]

Hi @rbreaves @RedBearAK, sorry for the delay in my response, but I have been sick. @RedBearAK seems like what you mentioned previously

Sometimes that only works until you reboot or restart the Kinto service.

is exactly what happens in my case. Once I run it the first time, it works until I reboot/log out. after logging out/rebooting, it stops working and even if I call the service again (seems like it fails to start again).

Only after completely uninstalling and reinstalling it works again. Do you have any suggestions to make sure the service keeps working after restart?

[RedBearAK]

@sollymay

Hope you're feeling much better.

Only after completely uninstalling and reinstalling it works again. Do you have any suggestions to make sure the service keeps working after restart?

I haven't been able to track down exactly why this happens, but I think it has something to do with SELinux or AppArmor. Fedora of course uses SELinux. The simplest way to bypass the issue is to just set SELinux to "permissive" mode. It is up to you whether you find the extra security of SELinux important enough to not do this. Due to the complexity of how SELinux permissions (context) works, all my efforts to troubleshoot the problem have come to very little.

The other option is to convert Kinto to running as your user, rather than needing to run as root with a sudo command. This is a bit more complicated, but not too bad if you know how to make a couple of simple shell scripts and a couple of "desktop entry" or "dot desktop" files and stick them all in the right places to allow the easy (re)starting and stopping of the xkeysnail service.

Running Kinto as user completely bypasses the SELinux issues, and allows the addition of much simpler launch commands into the Kinto config file, with which you can do lots of useful things. The tradeoff is that you lose the functionality of the Kinto GUI/log app and the Kinto tray icon until those can be updated to allow a run-as-user scenario. Which is why you need to create your own start/stop scripts and desktop files.

I've been meaning to put together a script that will automate this process of converting Kinto from root to user, but in the meantime I can just post the contents of my own run-as-user files that make this work, if you're interested.

[sollymay]

hey @RedBearAK, thank you for the suggestions. Just to test the easiest route first, I actually set SELinux to "permissive"in my /etc/selinux/config and rebooted, then tried to fresh install but for some reason, seems like the issue still happens after fresh installing Kinto again. Am I missing anything there? This is the output of sestatus after changing the /etc/selinux/config:

SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   permissive
Mode from config file:          permissive
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      33```

[RedBearAK]

@sollymay

I really don't understand the root cause of anything that has been going wrong with Kinto on Fedora. Setting to permissive was something that had worked in the past. If it still doesn't work I'm afraid your only real option is to move to run-as-user. It's really not too difficult, if you are already capable of messing with your SELinux config.

You'll need to disable the systemd service for xkeysnail. Technically you don't need to touch the systemd service as it will just sit there and continue to fail to load without causing any real issue, but I would disable it or delete the xkeysnail.service file from /usr/lib/systemd/system if Fedora is still pretending the unit file doesn't exist.

First step, follow the instructions here to put your user in a uinput group, and reboot:

mooz/xkeysnail#64 (comment)

Immediately after rebooting you should be able to open a terminal and run the command (without sudo) xkeysnail ~/.config/kinto/kinto.py and wind up being able to open new tabs in the terminal with Cmd+T and navigate between the tabs with Cmd+Shift+Braces shortcuts, then close the tabs with Cmd+W. Just to test that it's going to work as user. Use Cmd+dot (period) or Ctrl+C to stop the xkeysnail command and continue. Well actually you can just leave the process running as you work, and use a different tab or terminal window. Eventually when you use the new GUI app it will kill the process and run a new one.

After that step you'll need simple start/stop scripts to run the xkeysnail command and avoid running it more than once. The only reason the scripts below are as long as they are is because I wanted some feedback in terminal and/or GUI to let me know it was working as intended.

My start script, at /usr/local/bin/start_xkeysnail.sh:

#!/bin/bash

echo -e -n "Stopping existing xkeysnail process(es)...  "
pkill -f bin/xkeysnail
echo -e "Starting new xkeysnail process...\n"
/usr/local/bin/xkeysnail --quiet --watch /home/$USER/.config/kinto/kinto.py &
notify-send "Kinto (Re)Started" &

My stop script, at /usr/local/bin/stop_xkeysnail.sh:

#!/bin/bash

echo -e -n "Stopping existing xkeysnail process(es)...  "
pkill -f bin/xkeysnail
echo -e "Stopped xkeysnail process...\n"
notify-send "Kinto (xkeysnail) Stopped" &

Probably don't need to remind you about this but make sure the Bash scripts are marked executable with chmod +x, or the desktop files won't be able to execute the commands. And I think you need to use sudo to move the script files into /usr/local/bin.

My desktop file to start Kinto as user, at $HOME/.local/share/applications/Start_Kinto.desktop:

#!/usr/bin/env xdg-open
[Desktop Entry]
Type=Application
Name=Kinto (xkeysnail non-sudo) 
Exec=/usr/local/bin/start_xkeysnail.sh
Icon=/home/kris/.config/kinto/kinto-color.svg
Categories=Utility;

Use GNOME Tweaks or some other method to pick the Start_Kinto.desktop file or the application which should show up as "Kinto (xkeysnail non-sudo)" as a startup application. That way it will start Kinto every time you log in to the desktop.

The start script is written such that it can also be used to safely (re)start Kinto whenever you change something in the config file. It kills the xkeysnail process and then starts a new one.

If you make a mistake with editing the config file and xkeysnail crashes, you can see the output by running the start_xkeysnail.sh command manually in the terminal. It will show which line in the config is causing the crash. Then you can fix it and restart Kinto with the new "app" again.

I guess I didn't go to the trouble of creating a "Stop_Kinto" desktop file on this system (Ubuntu 22.04) but you can either use a terminal to run stop_xkeysnail.sh if you ever need to, or just make another desktop file like this:

#!/usr/bin/env xdg-open
[Desktop Entry]
Type=Application
Name=Kinto (stop xkeysnail non-sudo) 
Exec=/usr/local/bin/stop_xkeysnail.sh
Icon=/home/kris/.config/kinto/kinto-color.svg
Categories=Utility;

Save that as $HOME/.local/share/applications/Stop_Kinto.desktop and it should within a few seconds be available to whatever graphical app launcher you happen to be using. It will appear as "Kinto (stop xkeysnail non-sudo)" or at least "Kinto (stop...".

Actually if you don't tell the Kinto tray icon to go away you can still stop Kinto from the tray icon menu, but you can't start or restart Kinto from the tray because it will be attempting to run the sudo command or restart the systemd service, which of course is what is failing to work. But the "stop" option should continue to function.

Place the new "Kinto (xkeysnail non-sudo)" app you've just created on a dock or some other launcher and you'll always have a way to launch or restart Kinto.

If you do this conversion just maintain awareness that if you ever re-run the Kinto installer again it will try to run the systemd service again. Which if you leave your system in permissive mode would temporarily work. I would move SELinux back to enforcing mode if you're going to run Kinto as user.

I think that's the whole procedure I follow every time I do this. You can see why I want to automate it all with a script. It's a bit tedious to do from scratch. But if you don't go around distro hopping every couple of weeks you'll only need to do this once.

Good luck and let me know if you have questions.

[sollymay]

hey @RedBearAK your method works FLAWLESSLY! Thank you for all the time you took to explain how to achieve it. Now I'm running kinto with xmonad with no problems at all and it doesnt die every time I reboot!

It would be awesome to include a scrip to do this into the Kinto installer (maybe as an optional flag?) so that all of this gets taken care of when/if you need it.

I'm gonna close this issue as this is exactly what i wanted to achieve, so no need to keep it open.

Thanks again for all the help!

[RedBearAK]

@sollymay

FYI, in case you aren't subscribed to the Kinto GitHub repo to receive info about new releases, Ben found the problem and was able to fix the installer and make a new release that seems to have no further issues running on Fedora 34/35/36.

If you remove whichever run-as-user startup option you're using to autostart Kinto as user, and then re-run the main Kinto installer from the web link at https://kinto.sh , everything should start working the way it was originally intended. The tray icon will be back to showing the actual status of Kinto, and the GUI app should show the log again.

Other than disabling the autostart option, leaving the other run-as-user files where they are shouldn't cause any problems. No need to track them down and remove them.

[sollymay]

hey @RedBearAK, I tried just now, but seems like it dies after reboot again (at least using xmonad as WM it dies). It might be related to needing a spawn to enable the service in the xmonad config, so for my case, I will keep the old approach. do you know whats the standard path/command to enable the service, cause might just need to add that same command in my xmonad config and that way, it will just be adding one line of code (which i can pre-add to my dotfiles) vs doing the process you explained

[RedBearAK]

@sollymay

seems like it dies after reboot again (at least using xmonad as WM it dies)

Hmm, figures. Well, as far as I understand, the systemd service file is set to wait for "graphical.target", which should mean it would automatically start the xkeysnail command from the service file as soon as you log in to anything from the login screen. But maybe there is some more specific signal that systemd is waiting for to reach "graphical.target" status, and logging into xmonad isn't triggering that event.

Obviously if the run-as-user setup was working you could stick with that. But if you want to keep hacking away at this maybe we can find a simple solution for xmonad and other WMs in the future.

If you cat /usr/lib/systemd/system/xkeysnail.service you'll see the actual command it tries to run:

[Unit]
Description=xkeysnail

[Service]
Type=simple
KillMode=process
ExecStart=/usr/bin/sudo /bin/bash -c '/usr/bin/xhost +SI:localuser:root && /home/MYUSERNAME/.config/kinto/killdups.sh && /usr/local/bin/xkeysnail --quiet --watch /home/MYUSERNAME/.config/kinto/kinto.py'
ExecStop=/usr/bin/sudo /bin/bash -c '/usr/bin/sudo pkill -f bin/xkeysnail && exit 0'
Restart=on-failure
RestartSec=3
Environment=DISPLAY=:0

[Install]
WantedBy=graphical.target

So it uses sudo to run bash and execute (reformatted for easier reading):

/usr/bin/xhost +SI:localuser:root && \
/home/MYUSERNAME/.config/kinto/killdups.sh && \
/usr/local/bin/xkeysnail --quiet --watch /home/MYUSERNAME/.config/kinto/kinto.py

Notice that being run as root means the user's name/home path has to be hard-coded into this command. You'll have to change everywhere you see MYUSERNAME to your actual username.

To break this down a bit, the xhost part is usually needed to bypass a permission problem with root not being allowed access to your X display server. Then if that is successful (&&) it runs a script (much more involved than my own simple "pkill xkeysnail") that tries to make sure it isn't going to duplicate the xkeysnail process, and then (&&) it launches xkeysnail with the special Kinto config file (/home/MYUSERNAME/.config/kinto/kinto.py) that does all the magic to make modifier keys and shortcuts work like a Mac.

The Kinto installer also sets up a new sudoers file that allows access to certain commands without sudo, like:

systemctl status xkeysnail.service
systemctl start xkeysnail.service
systemctl restart xkeysnail.service
systemctl stop xkeysnail.service

I would try running that first status command above, just to see what systemd says the status of the xkeysnail service is after you log into xmonad. It should show whether the service is stopped, running or failed, and a few lines of log info that may show a specific error.

I would also try just running the whole command from the service file in a terminal, and see what happens:

/usr/bin/xhost +SI:localuser:root && /home/MYUSERNAME/.config/kinto/killdups.sh && /usr/local/bin/xkeysnail --quiet --watch /home/MYUSERNAME/.config/kinto/kinto.py

After you run the xhost part at least once you should also just be able to run this part by itself:

sudo xkeysnail /home/MYUSERNAME/.config/kinto/kinto.py

This is just what the run-as-user script does, but with sudo to give it superuser privileges.

If course if you don't use one of the kill solutions or manually kill any existing xkeysnail process, running a command like this by itself can result in duplicate xkeysnail processes, unless you Ctrl+C to kill it each time.

The output either way should be illuminating as to why the service may not be loading when you log into xmonad. Or maybe it will work when run in the terminal but the systemd service is just not activated by logging into xmonad.

I'll be interested to see exactly what is going on.

If you know of a simple way to get a working xmonad desktop setup without running through the whole manual building of a configuration file, I could do some troubleshooting of my own more easily.

[RedBearAK]

@sollymay

I think the root of the trouble is as I expected, xmonad is not presenting the right trigger to start the systemd service correctly.

systemctl --user list-units --type target --all

This command reveals that there are only a few "targets" active when starting a basic xmonad session. Notably, graphical-session.target is inactive in xmonad, but active in other desktop sessions like GNOME.

Seems to be possible to just manually restart Kinto from the Kinto GUI app menu, or presumably from the Kinto tray icon if you have an indicator tray, after starting the xmonad session. Strangely the service file doesn't use sudo for the Exec command on Fedora, but if the user hasn't been added to the uinput group, running the command without sudo will complain... but will still work? Haven't really seen that before.

On Ubuntu when you use the commands from the /etc/sudoers.d/limitedadmins file, the terminal doesn't ask for the password, but on Fedora it still asks for your password. So I don't think you can just spawn systemctl restart xkeysnail to bypass the issue. That should either not work or possibly bring up a password dialog on every login. But I haven't actually tried it. I still have no xmonad config file. It might work.

Otherwise it will be necessary to find some way for graphical-session.target to be active when you login to an xmonad session.

[RedBearAK]

@sollymay

Looks like the GUI app, the tray icon, and even the systemctl commands simply won't work until you at least run this:

/usr/bin/xhost +SI:localuser:root

So maybe if you spawn just that part of the command the systemd service will be able to start normally. But you still might need to start the service manually after that. So the main solution will probably be to spawn the whole command:

/bin/bash -c '/usr/bin/xhost +SI:localuser:root && /home/MYUSERNAME/.config/kinto/killdups.sh && /usr/local/bin/xkeysnail --quiet --watch /home/MYUSERNAME/.config/kinto/kinto.py'

Again, replacing MYUSERNAME with your actual username.

Once the xhost part gets run successfully, everything else should work normally until you log out of the session.

[sollymay]

hey @RedBearAK your last suggestion worked! seems like its just making sure you run that line on the xmonad.hs and call it a day. would be awesome to have something along the lines of detecting if your current WM is xmonad and adding it automagically, but adding just one line of code to a file i already have a backup of (essentially making sure if i configure any other distro, to use the same username so that I don't need to do any changes is a very good compromise :+1)

Thank you for all your help!

[RedBearAK]

Glad it worked. I had to do a similar fix to use Kinto with IceWM on a very old laptop. It just wouldn't work unless I ran the xhost command somehow after logging in.