-
Notifications
You must be signed in to change notification settings - Fork 61
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
Launchers should manage xochitl through systemd #515
Comments
thanks for investigating this and following up! after i suggested the watchdog change, i realized there are a few things going on and my suggestion for changing watchdog may not be enough.
the previous solution was to run @Eeems, @matteodelabre, @LinusCDE - do you have thoughts here? i think oxide supports launching xochitl via an API. for remux, i have a clear idea of how to restart xochitl automatically from shell, just need to add some code for it. |
We probably should build a helper script that will properly kill/start xochitl for you based on whatever launcher you use. For Oxide you would use # Stop xochitl
rot apps get applications \
| jq -cr '."xochitl"' | sed 's|/codes/eeems/oxide1/||' \
| xargs -I {} rot --object Application:{} apps call stop
# Launch xochitl
rot apps get applications \
| jq -cr '."xochitl"' | sed 's|/codes/eeems/oxide1/||' \
| xargs -I {} rot --object Application:{} apps call launch
# Check what the currently active application is
rot apps get currentApplication \
| jq -cr | sed 's|/codes/eeems/oxide1/||' \
| xargs -I {} rot --object Application:{} apps get displayName \
| jq -cr
# Check if xochitl is running
if [[ "$(rot apps get runningApplications | jq '."xochitl"')" != "null" ]] || [[ "$(rot apps get pausedApplications | jq '."xochitl"')" != "null" ]];then
echo "Xochitl is running"
fi You'd probably do the following to stop/start xochitl, where you only start xochtil if it was the current application. xochitlPath="$(rot apps get applications | jq -cr '."xochitl"' | sed 's|/codes/eeems/oxide1/||')"
if [[ "x$xochitlPath" == "x" ]];then
echo "Xochitl is not registered"
exit 1
fi
currentApplication="$(rot apps get currentApplication jq -cr | sed 's|/codes/eeems/oxide1/||')"
if [[ "$(echo "$(rot apps get pausedApplications) $(rot apps get runningApplications)" | jq -s add | jq '."xochitl"')" != "null" ]];then
echo "Stopping Xochitl"
rot --object "Application:$path" apps call stop
fi
if [[ "x$xochitlPath" == "x$currentApplication" ]];then
echo "Starting Xochitl"
rot --object "Application:$path" apps call launch
fi |
@Eeems Sorry for the late response. Assuming xochitl stills needs a restart to load new documents, then yes, some restart scriptability is required. |
My understanding is that this was for disabling the watchdog timer for launcher support, and not restarting the service? Am I misunderstanding what is being asked for? |
What we need is a common interface for restarting xochitl in order to trigger a reload of documents. My suggestion is for launchers to let systemd manage xochitl instead of spawning their own child process. I believe xochitl can then be paused using There is still the issue that the default xochitl service file has a watchdog that will be triggered if xochitl is stopped for too long. This can be solved by adding |
I think it would be less work to just have remarkable_printer use the remux and oxide APIs to restart xochitl at this point. Having a wrapper script to call either for common things like starting and stopping applications would also be useful. There are currently larger issues that need resolving to allow oxide to support externally launched applications, and even when it does, having xochitl start at boot from an external location is still less than ideal. Longer term, I think someone should create a wrapper library around the USB web interface for uploading documents without having to restart xochitl. Now that https://github.com/rM-self-serve/webinterface-onboot and https://github.com/rM-self-serve/webinterface-persist-ip exist, it seems to be a much better user experience. |
I also think removing the watchdog would be a mistake as it serves an important role when using xochitl as the primary interface, if xochitl somehow deadlocks, systemd would not know to automatically restart the service when the watchdog times out. This isn't a concern with remux or oxide as they both allow the user to still interact and restart the misbehaving application. |
Revisiting this, I still think it's cleaner to keep xochitl managed by systemd instead of launchers disabling that service. We keep a common interface through systemd rather than a custom script. It's also better for the end users as it means that |
#795 provides a unified command line interface for interacting with launchers. With this, you will just need to run the following to restart xochitl if it's running, or stop it if it's in the background: if launcherctl list-running-apps | grep -q xochitl; then
# Restart xochitl if it's currently running
launcherctl stop-app xochitl
launcherctl start-app xochitl
elif launcherctl list-paused-apps | grep -q xochitl; then
# Stop xochitl if it's in the background, as it's not active
launcherctl stop-app xochitl
fi |
I'm in alignment with Eeems and using the launcher-ctrl script to manage xochitl. It's not clear to me that systemd services are an analog for what we are doing. Rather, the launchers are similar to a DE. Typically, people don't create a new systemd service per UI app, they create a .desktop file per app, which is equivalent to our .draft files If your objective is to have xochitl rescan documents, we can try to help solve that problem. |
Some launchers draw on top of xochitl and need to be able to pause it with SIGSTOP. However, the default xochitl service has
WatchdogSec=60
, which causes xochitl to restart after 60 seconds of inactivity.remux, for example, gets around this by launching xochitl directly instead of using systemd. Disabling the watchdog will allow xochitl to be systemd managed again.
This is especially pertinent to remarkable_printer, where I need to be able to restart xochitl to force it to reload documents, even when managed by a launcher.
We would need to add
WatchdogSec=0
to the[Services]
section of toltec-wrapper.conf.The text was updated successfully, but these errors were encountered: