On Do, 11.04.19 11:32, Przemek Klosowski (przemek.klosowski@xxxxxxxx) wrote: > 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. Why would't they? If you want to to run your own stuff independent of you being logged in then do "loginctl set-linger" on your user and it's done. The logic in systemd is more strict on putting boundaries on resource usage, and thus will by default not allow you to consume resources while you are not logged in. It's really how this always should have been designed. However, we fully acknowledge that there are many uses where the ability to run stuff independently of any login as your own user is fine, but you need to turn on lingering for that (which is privileged), so that this is explicitly marked OK. But anyway, it's totally fine if you use cron for what you are doing too, if you are more comfortable with it. It's just a question if cron needs to be around on the workstation default install. I mean, all the stuff you list up there, it's not precisely part of the base install either, you installed a number of packages to make that work, and it should be fine if crond is one of them, no? > 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. Privileges are required to turn on lingering for your user. After that your user can consume resources on the system from power-on to power-off without further privileges. i.e. it's the act of turning on lingering that requires privs. After that's done once you don't have to think about that anymore. Lennart -- Lennart Poettering, Berlin _______________________________________________ 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
