On Thu, 11 Apr 2019 19:08:38 +0200
Lennart Poettering <mzerqung(a)0pointer.de> wrote:
On Do, 11.04.19 11:32, Przemek Klosowski
> 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
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.
The logic in systemd is more strict on putting boundaries on
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 Poettering, Berlin
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html