|
On 4/11/19 1:08 PM, Lennart Poettering
wrote:
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. It IS very useful for systemctl to prevent resource leaks by
killing errant processes (hanging browser, etc)---however, as we
discussed, some processes should not be killed; I know which
processes I want to annoint this way, and I take responsibility
for their possible misbehavior. I understand that set-linger disables process harvesting for all
processes in the session, though, and I would like to just do it
only for SOME processes. I guess I could create another user for the persistent jobs and
set-linger that session... but it gets complicated. I think it's a better design if I could designate individual
processes using my UID as set-linger. I remember talking about
remote sessions with long-running jobs, and how the connection
timeouts caused by remote clients or network routing prevented
their completion. The solution was IIRC running them in
tmux/screen. Here also, it'd be nice if I could designate
'my-long-running-service-like-executable' as eligible for
lingering. |
_______________________________________________ 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
