Feature request: run executable after application started by cage exits

[casm]

Abstract: many types of kiosk environments would benefit from being able to run an executable after the application started by cage exits.

As an example, cage is being used in my environment to start a frontend for arcade game emulators; the machine it's running on is physically located inside of an arcade game cabinet. Gracefully exiting the frontend is necessary in order to commit unsaved changes, and being able to power off the machine after exiting the frontend is necessary in order to keep people who aren't me from sticking their hands in places they shouldn't be in order to turn off the machine :)

As a workaround, I'm having cage start a bash shell which in turn runs a script that launches the frontend with '&& systemctl poweroff -i' specified. The cage user has sudo permissions to specifically run `systemctl poweroff -i', and everything shuts down as expected when leaving the frontend. While this works, starting a shell in order to run the application and shut the system down isn't really ideal.

If this type of functionality could be brought into cage directly, it would add a ton of flexibility. Obviously there are wider uses for this than just controlling power, but that seems like one which would have a lot of commonality across kiosk installations.

[emersion]

I think the shell approach is a good one.

[joggee-fr]

If you run Cage as a systemd service you may directly use SuccessAction= with something like halt-immediate to do what I understand you want. No more wrapper script needed.

[casm]

I think the shell approach is a good one.

It definitely works, true. The thing is, it's less than ideal in a number of situations where someone may be able to leverage the underlying shell from the executable being run within it.

If you run Cage as a systemd service you may directly use SuccessAction= with something like halt-immediate to do what I understand you want. No more wrapper script needed.

Also true, but the downside to this approach is that the actions on exit are restricted to those that SuccessAction provides and the ways in which they behave. Completely agreed that it will achieve the poweroff scenario, but if more flexibility is needed (e.g., running an executable to perform a housekeeping task before shutdown) it may not achieve that in the desired manner.

It's also systemd-dependent. Granted, most folks are likely to be running systemd these days, but not everyone is.

[joggee-fr]

Still with systemd, an other service (or more) could be started with OnSuccess= if SuccessAction= options are not enough.

Without systemd, the Shell script is nice. Note that you don't have to be directly started by Cage and inherit its user. You just have to access the Wayland socket created by Cage.

[casm]

Still with systemd, an other service (or more) could be started with OnSuccess= if SuccessAction= options are not enough.

Which is a good point. Going to think about that one for a bit; something in my mind is thinking that OnSuccess= presents a certain restriction (or set of restrictions) in circumstances that might be relevant here, but I can't remember what they are off the top of my head. Might even be misremebering.

Without systemd, the Shell script is nice. Note that you don't have to be directly started by Cage and inherit its user. You just have to access the Wayland socket created by Cage.

True, but there are situations where (systemd or not), continuing to run under the existing cage user instance would be preferable, most likely in one-shot calls to an external executable doing housekeeping. Note that I'm not arguing against your point, just mentioning the corollary. Of course, being able to run as another user also has its benefits.

Just to clarify my thinking in all of this: there are circumstances where having cage be able to run executables in sequence may be preferable to falling back to systemd's capabilities or starting a shell under cage at first run. Both of those are certainly valid approaches and have their places, too, but being able to expand on them through cage itself would increase flexibility overall.

[joggee-fr]

Just thinking of your point. If Cage starts a second executable once the first exits. It will be started with the same constraints that the first one i.e. Cage user, etc.
So, I don't really get the point why it would be a better solution than a simple Shell script.