Re: Can we maybe reduce the set of packages we install by default a bit?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux