## Launch and reattach to a long-running processCockpit pages should never spawn long-running precious processes, as a Cockpitsession is not reliably connected for a long time: Network interfaces go downor roam, TCP timeouts happen, browsers crash, tabs get closed accidentally,batteries drain, people close/suspend their laptops, and so on.Most services that Cockpit talks to manage their own runtime state and jobs,such as udisks, libvirt, or podman. But this is not the case for e.g. runningAnsible playbooks or installer scripts. These should be wrapped into atransient service unit, so that systemd takes over the role of the job manager.This example demonstrates how to do that. It runs an arbitrary shell command ina transient cockpit-longrunning.service, shows the live log output, andreattaches to it on page load. I.e. you can start the process, log out, logback in, and the service is recognized as "already running" with the completeoutput.For your own use case, the most important design question is the choice of theservice name, especially if the page can manage more than one process (such aslaunching parallel playbooks with different environment variables). It mustcontain exactly all the identifying properties in the name, so that it ispredictable.If your page does manage multiple processes in parallel, it needs to enumeraterunning units with [ListUnits()](https://www.freedesktop.org/wiki/Software/systemd/dbus/).This example page only manages one at a time, and thus just uses a `GetUnit()` callwith a known name.