On Thu, 11 Apr 2019 19:08:38 +0200 Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > 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. Was this the privileged operation? What privilege does it require? I just run the command as a non-admin user and saw no errors or prompts for passwords or anything. -Steve > 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 _______________________________________________ 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
