Launchers should manage xochitl through systemd

[Evidlo]

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.

[raisjn]

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.

1. you want a way to restart xochitl automatically after loading documents through remarkable_printer
2. draft/oxide/remux don't use systemd to manage xochitl (because of the watchdog for remux and the execution model for oxide/draft)
3. using systemd restart xochitl will mess with what the launcher is currently focused on (and may end up showing two apps at once) - this is the main problem. the launchers won't know you launched xochitl.

the previous solution was to run killall xochitl if the service was not active, which would require re-launching xochitl manually if you are using a launcher. i'm assuming you want the re-launch to be automatic. i think one option is for us to do is provide a script for restarting xochitl in toltec that is launcher aware (and you call it if it exists). alternatively (but more work), we change the watchdog setting in the systemd file and modify oxide/remux/draft to use systemd to manage xochitl.

@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.

[Eeems]

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 rot to accomplish this. For example (With jq installed):

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

@Evidlo @raisjn is this still needed?

[Evidlo]

@Eeems Sorry for the late response. Assuming xochitl stills needs a restart to load new documents, then yes, some restart scriptability is required.

[Eeems]

@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?

[Evidlo]

What we need is a common interface for restarting xochitl in order to trigger a reload of documents. remarkable_printer needs this and probably other programs that deal with reMarkable document syncing.

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 systemd kill --signal SIGSTOP xochitl (untested) to allow launchers to draw on the screen.

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 WatchdogSec=0 to the toltec-provided xochitl service file.

[Eeems]

What we need is a common interface for restarting xochitl in order to trigger a reload of documents. remarkable_printer needs this and probably other programs that deal with reMarkable document syncing.

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 systemd kill --signal SIGSTOP xochitl (untested) to allow launchers to draw on the screen.

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 WatchdogSec=0 to the toltec-provided xochitl service file.

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.

[Eeems]

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.

[Evidlo]

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 systemctl restart xochitl will keep working.

[Eeems]

#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

[raisjn]

Revisiting this, I still think it's cleaner to keep xochitl managed by systemd instead of launchers disabling that service

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.