On 4/11/19 10:16 AM, Lennart Poettering wrote:
However, that's intended for system services only (i.e. for services 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, 'kick-me-off-when-I-log-out' mode.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
