does not work with starters (remux, oxide, draft)

[torwag]

It seems that the printer restarts xochitl by utilising the systemd service. stdout, err := exec.Command("systemctl", "restart", "xochitl").CombinedOutput()

Most (all?) starters disable the start of xochitl as a system service and start it by themselves. The printer should find a way to identify whether to restart xochitl via systemd service or signalling remux, oxide and Co to restart xochitl.

[Evidlo]

Is there a reason why these launchers can't use systemd for stopping and starting xochitl?

[torwag]

I am not sure, but as they start them by themselves, they get hold of the PID and can control them.

[raisjn]

Is there a reason why these launchers can't use systemd for stopping and starting xochitl?

the systemd unit for xochitl has a watchdog in it which will restart xochitl if the watchdog isn't activated every X seconds. when we pause xochitl (for multi-tasking purposes), it no longer sends the watchdog signal and systemd will restart xochitl after a while. this is why we don't use systemd managed xochitl.

you can check if xochitl is active using systemctl (systemctl is-active xochitl, i think) and check if it's running using pgrep or ps, etc and change behavior.

[Evidlo]

@raisjn Wouldn't it be more idiomatic for the launchers to install their own service at /etc/systemd/system/xochitl.service with WatchdogSec=60 removed? This should take precedence over /usr/lib/systemd/system/xochitl.service. If they need it, the launchers can watch for xochitl restarts through dbus.

This way, application developers don't need to worry about having to implement signalling for each launcher and just rely on systemd infrastructure.

[raisjn]

that's a great idea! cc @Eeems

in general, i don't like editing a working system in a way that could cause problems which is why i didn't modify the original service file. this way seems mostly reasonable but it could stick around if someone deletes entware without removing that file

[raisjn]

i think it's maybe safe for you to also just do a killall xochitl (instead of restart via systemctl)

[Eeems]

If we do implement this, I'd like to do it in a generic way that all launchers can share, that way any fixes will be pushed out to all launchers instead of requiring all of us to update. Also pinging @dixonary

[dixonary]

Perhaps we could add a package to Toltec called managed-xochitl which includes /etc/systemd/system/xochitl.service and sorts out the disabling/enabling process? Launchers can then depend on that.

[raisjn]

this will modify the behavior of the system and remain if someone wipes toltec/entware, which is not preferred. i think killall xochitl is less work for everyone

[Eeems]

this will modify the behavior of the system and remain if someone wipes toltec/entware, which is not preferred. i think killall xochitl is less work for everyone

So everything that already is using the xochitl service will need to be updated to use killall?

[raisjn]

So everything that already is using the xochitl service will need to be updated to use killall?

ideally we solve "need to restart xochitl to refresh documents", but it's a tradeoff - do we modify user system (in a way that they wouldn't realize) or do we make it easy for app developers. if you are both for modifying the system service, sounds fine to me, we will just need to coordinate the implementation and roll out.

another thing here is that remarkable_printer is not respecting the system's preference on xochitl. the system has xochitl service stopped and this script restarts it. (if it is running systemctl restart xochitl). i think the script should check if it is stopped and if it is, it should not run restart. whether it runs killall or not, i don't care (esp. since user can restart xochitl through their launcher), but it should respect the system state.

[Evidlo]

this will modify the behavior of the system and remain if someone wipes toltec/entware, which is not preferred. i think killall xochitl is less work for everyone

Haven't you already modified the behavior of the system by disabling the xochitl service? If toltec is wiped by the user, you will end up with a broken system where nothing is launched at boot.

It seems to me like post-uninstall hooks are necessary in either case.

[raisjn]

Haven't you already modified the behavior of the system by disabling the xochitl service? If toltec is wiped by the user, you will end up with a broken system where nothing is launched at boot.

no, i haven't

[Eeems]

So the one issue with killall when they aren't using a launcher is that if you do it enough times remarkable-fail will trigger and switch to the other root partition to initiate an upgrade.

[raisjn]

yes, good point - so let's just say "if xochitl is running via systemd, run systemctl restart; else do nothing"

[Eeems]

Perhaps we should provide a script for this that applications can use?

[raisjn]

Perhaps we should provide a script for this that applications can use?

i agree with you, but i think evidlo's point is that application developers shouldn't have to do anything other than systemctl restart xochitl

[Evidlo]

I have no problem with conditionally restarting xochitl if enabled. The killall approach seems brittle to me though.

[raisjn]

The killall approach seems brittle to me though.

you are right, good catch!

[raisjn]

Haven't you already modified the behavior of the system by disabling the xochitl service? If toltec is wiped by the user, you will end up with a broken system where nothing is launched at boot.

to elaborate: i think draft and oxide require disabling xochitl service which would lead to what you said, but remux does not disable xochitl, it just runs systemctl stop xochitl when it starts up (disable != stop), specifically because i don't like the idea of bricking a system by accident in the way you described. this leads to it looking like xochitl restarts when remux is first called (which is bad user experience), but i don't know way around that yet

[torwag]

My two cents.... no program should terminate another program which it did not get hold off / started in the first place. As you never know why and who started it. That could cause all kind of troubles depending on the end-users set-up.

Thus, I agree that killall is a bad approach.

[raisjn]

looking at https://github.com/Evidlo/remarkable_printer/commit/7e50dbb48fc768407359f46b4ac0ecebdc0088cf, you use 'is-enabled' but should use 'is-active' bc it's possible for xochitl to be enabled but in-active (systemctl stop xochitl moves to active=false, is-enabled=true). oxide and other launcher disables xochitl (is-enabled=false, is-active=false) but remux does not disable xochitl, only stops it (is-active=false)

[Evidlo]

Should be fixed with 11.0.0