4 ms·
You could also hand all the invocations of run_intensive_process to at, and let it take care of running them when the load average permits: https://linux.die.n
by twic 3y ago
You could also hand all the invocations of run_intensive_process to at, and let it take care of running them when the load average permits:
https://linux.die.net/man/1/at https://linux.die.net/man/1/at
I don't think at is very heavily used on modern systems, so it's quite possible that it doesn't actually have very useful behaviour here.
- dredmorbius 3y agoMore specifically, batch(1). at(1) runs jobs after a specified time. (A common mistake is to presume that "at" means "will run when specified" when in fact it means "will run no earlier than specified", and depending on system characteristics, could run substantially later.) batch runs jobs ... as system load permits, without any time specification, in a FIFO queue. There's also cron, the third Unix scheduler, which executes a set of specified tasks on a regular schedule. All three are related.
- twic 3y agoI have the idea that at is more widespread than batch, and since you can say 'at now' (or 'at $(date)'), at is a better bet. As far as I know, cron doesn't pay attention to load average, but I would love to be corrected. All of this feels like a very crufty and highly neglected part of Unix, which is a shame. There's an alternate history of Unix where it's all about batch jobs and datagram Unix domain sockets.
- michaelcampbell 3y ago> As far as I know, cron doesn't pay attention to load average, but I would love to be corrected. It does not. Up to whatever you run from cron to deal with that.
- dredmorbius 3y agoat and batch are both part of the same underlying facility. The former seems more known than batch, but where you find one you will pretty much always find the other. On many systems they'll share an integrated manpage.