On 4/11/19 10:16 AM, Lennart Poettering wrote:
However, that's intended for system services only (i.e. for
running as users UID < 1000). For regular users (i.e. human ones,
those with UID >= 1000), the idea is to install timer units in the
per-user instance of the systemd service manager instead. That service
manager runs inside a PAM session of the user, and the lifetime is
normally bound to the time the user is logged in, meaning that users
who are not logged in cannot run stuff. (however, specific users can
be marked as "lingering" though a privileged operation and if so
their specific service manager is started at boot and stays around
until shutdown, so that their timers can run outside of the immediate
login time of the user).
I run a bunch of background jobs like harvesting podcasts that are
released weekly, collecting weather stats for my garden watering system,
monitoring my power feed and UPS, collecting ADSB data, etc. I don't
think of those as 'system' services, so I run them in my own cron jobs.
The system works well because even if my system reboots on a power
glitch, or my session crashes, the jobs still run--but in the systemd
world it wouldn't work.
I'd like the system jobs to be strictly about the OS
infrastructure---both for the 'ideological purity' and because it seems
to me that it'd be easier to move them to some sort of cloud environment
where I don't manage the underlying OS.
I think you're saying that systemd is designed on an assumption that
such jobs are part of system operation, and will have to run as
system/privileged jobs or at least be designated as 'lingering', which
you say requires system privilege. I would argue that on my own system
(which is a majority of systems now) it should be easy to designate
low-privilege jobs as lingering: I should get to decide if it's useful
for them to run even if I don't have a current login session.
Compare this with Android: the apps can run in background, and it's
fine; I implicitly authorized them by owning the device, and installing
the app after authenticating to the device and to the app store and
maybe to cloud services they depend on. I think the Android model is
more relevant in this IoT age than the traditional timesharing,