-
Notifications
You must be signed in to change notification settings - Fork 213
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not working after logout/login #20
Comments
You should be able to checkout the latest release of 1.0.4. It should resolve your issue. Just run back through the setup.py install. The error handling has been improved, and the app will restart automatically if it begins before x11 or the DE isn't fully ready for it. Additional verbosity has been added as well for those that want to add more terminals or additional keyswapping categories. I am closing this ticket as I am pretty certain this issue is now fully resolved. |
@rbreaves thanks. I checked out 1.0.4, reinstalled with There is now a new issue: after reboot the service is inactive and not started after a After logout/login, the service is inactive again: a Is there something I need to do besides |
Crap.. I left out a single line in the updated installer.. just run this command and the service will be re-enabled and will work fine after that.
I guess I will make a 1.0.4-1 release. |
@rbreaves thanks for your efforts So I checkout 1.0.4-1, installed it but after reboot, the service tried to start but failed: |
Under the [Service] section of the service file can you try adding this. RestartSec=3 nano ~/.config/systemd/user/keyswap.service and then reload the service config with this command
|
@rbreaves thanks, the The service is inactive, and starting it results in it being in an |
That is really odd.. I have been able to duplicate a similar issue on ubuntu 19.10 and I cannot say why it occurs yet. I think systemd believes it ran successfully but then stops it prematurely. There's really no good reason for it to end. Something is wrong with the service config file. I will keep working on it and get a release out later today addressing the problem. This behavior does not occur on xfce4, but I do not know why. I actually get an exit code of 15, and the only time I can get an activating message to appear is if I change the service type to forking instead of simple. |
@rbreaves thank you for looking into it. Kinto is an awesome project. |
@owzim Thanks, and I believe I have it worked out now in the 1.0.4-3 release. I found that re-adding the kinto.desktop file to ~/.config/autostart seems to fix it because it will also run the command to start up the service. If the service is already running, such as a fresh boot then it is simply ignored and has no impact from what I can tell. |
@rbreaves with |
Weird.. guess I’ll reopen the ticket then for now. My test vm didn’t show it failing on log off & logins, but I didn’t test a full reboot. Will work on several hours from now. |
I must have been tired last night.. I did not type in the correct path or name for systemctl in that desktop file. That has now been corrected and the kintox11 binary has been updated to apply the gui keymap on init if the window being detected is none. Particularly useful for people that want to immediately open their apps via "Cmd+Space" and not wait until they click on some app. I will leave this ticket open for the next 24 hours or so just to make sure release 1.0.4-4 fixes the problem. |
@rbreaves I just installed Issues persist: After Reboot, the service fails to start: After starting the service, it gets activated: Logout/Login problem persists as well: Can you not reproduce the issue, so you're stepping in the dark? How can I be of further help? I can reproduce the issues both on a vbox machine and a real machine with Pop!_OS 19.10 |
When I set Logout/Login issue then mutates from |
Yea, I purposely set it to 1 by default, I was asking you to do 3 just because it would give a longer interval between restarts for debugging purposes. removed some questions - irrelevant I will test this under my pop_os 19.10 vm. |
This is interesting, it is something that impacts just Pop OS 19.10 and not Ubuntu 19.10, but I will figure it out.. I like Pop OS lol. Also I will need to update the python setup file, it is not setting the right de tweaks at the moment. |
I've made a couple of improvements and merged it into master, but the issue is still unresolved for Pop!_OS atm. From what I can tell though.. the working path is not being respected from the service file. I can confirm that by doing the following The app will run just fine, but there's obviously an issue with systemd under Pop!_OS. I am not sure what just yet. |
Checkout the latest master branch, it is on the 1.0.4-5 release. If it still fails then run this command and give me the output. I had it still fail on one reboot, but then work after a 2nd reboot, but sadly I did not run this command on the first failure.
@owzim It should mostly be fixed now, the primary cause of your issue was that I had hardcoded the Display value in the services file.. which probably works out ok most of the time on other OS's, but there was no real reason to have hardcoded that. It was also something hardcoded in that file since the very beginning of Kinto, so it predated the new rewrite with the kintox11 binary and that really threw me off - hence all of the additional things I had looked into and added to the binary to try and help with error handling and giving more useful feedback into the terminal while it is running normally. |
on Here is the
|
I somehow need a more complete log from your journalctl -xe. That output completely missed anything about the keyswap service. |
*Updated to what Duckinahat says, the command I listed initially did not work with just -u. Try this
I think if you add -b it’ll also filter it down to the current boot. It’ll have the answer though, it’s much more verbose than getting the status. |
I was having a similar issue on ubuntu 18.04 While debugging though I noticed that keyswap.service wasn't appearing with Might help, really appreciate this tool, thanks |
Nice, thanks @Duckinahat and it appears like adding -b to it helps show the current errors, without it mine starts at the very beginning of my service logs instead of the latest. |
@rbreaves ok so
|
Thanks, that is what I was needing to see. I will take a moment and look through my code and see what I can do. It looks like it fails on the 1st run due to the DE still loading up, but the 2nd and the rest of the failures are happening for an unknown reason, but it's definitely happening as it is trying to get the current window. |
@owzim I can duplicate your error, sorta, but not consistently from boot or login, even on the same version of Pop!_OS. I have updated the dev branch with the latest kintox11 binary, and since I am batting 0 out of 8 so far I will let you confirm that the latest kintox11 binary in the dev branch fixes your problem before issuing another official release. Just checkout the latest dev branch. 26f70cc More details I'm actually glad you have forced me to make this change because it actually fixes another problem I was aware of but had not been able to fix until now. The way I had been able to emulate your problem was by opening and closing a preferences panel in the Gnome Terminal which would result in the exact same type of error as what you have in your log. The app in this instance though would actually recover because it was not consistently happening. So to resolve it I just added in a check to see where the x11 Window value is set at while it is retrieving the top window and if it is 0 then I do not run an XQueryTree function against it, otherwise it will crash and come back with XBadWindow error. I guess there is something different about how your X11 is working for some reason, as I am surprised you'd have a value of 0 that persistently. Previously the app would just exit and start itself back up again quietly and happened so rarely for me I did not worry about it too much. This specific problem is fixed now though and hopefully there's not yet another issue lurking on your setup! 😂 |
@rbreaves thanks for the efforts. I installed However if I set the |
Well that is interesting.. I may update the installer then and give people the option to set the restart interval. I'd prefer to recommend 1 second to most people, just so that the service will restart faster if it fails during normal usage any, but for the sake of a clean reboot 3 seems to be required for you. Perhaps you have a lot of other and additional services loading that requires it? I am not sure. I am going to go ahead and close it though since it appears like it is running well now on 26f70cc in the dev branch. I don't think there's much more I can add to the binary itself, well maybe a timeout loop of some kind on grabbing that display once it becomes available that could help with the clean reboot. Thanks for sticking with me this far lol, I know it took some effort to fix. |
@owzim I believe the current release, 1.0.4-6, should now allow you to have a 1 second RestartSec parameter as the Open Display function in the kintox11 program should now attempt to re-open the display for 60 seconds before giving up. At this point RestartSec could be removed altogether but I think I will keep it in there in case there are other variables I am not taking into account. Restarting too quickly will definitely trigger the service to give up too quickly. |
@owzim So cold boots were still having issues with another user as well, so I went back and re-added the timer service for cold reboots, but also kept a shortcut that will start the service from logout and login as well. In both cases those scripts and services have a 5 second delay to them to ensure that the service will start properly. I figured I'd mention this to you since you were the other user that had reported this type of issue. I am surprised I either had a bug regression or never fully resolved, I am not sure. |
After boot:
After logout/login:
After restart of service:
The fail also happens after fresh install, only a reboot solves it.
I also tried the current dev, as stated in this issue #11
The text was updated successfully, but these errors were encountered: