Re:Visualizing All Processes in a Datacenter
by lathiat on Wednesday September 06, 2017 @09:11AM
(#15183343)
I feel like having cron, by default, lock out the next iteration of a program or at least some kind of spawn limit would be ideal.
I see this a LOT with wordpress & PHP "developers" deployed on shared hosting (where they often don't observe the runtime and such of these things). They end up having one script step over the next and the next and eventually combined they are generating so much load on the database or some other service that none of them ever finish. Fun fun...
Re:Visualizing All Processes in a Datacenter
by smueller1234 on Wednesday September 06, 2017 @12:48PM
(#15185085)
It's also a fairly trivial thing to implement with flee system locks (just make sure your fs had sane semantics). In fact, with a bit of cleverness and fs locks you can implement more complex patterns trivially as well such as a pseudo daemon that is both cycled (without appreciable downtime) regularly as well as having a backup process to take over on failure.
Obviously, you don't run your webserver that way (right!?) but it's not nuts to manage (even near real-time) queue consumers in a backend that way.
Re:Visualizing All Processes in a Datacenter
by lathiat on Wednesday September 06, 2017 @09:14AM
(#15183360)
Seems like this is actually the default behaviour for a systemd timer, ha.
"Note that in case the unit to activate is already active at the time the timer elapses it is not restarted, but simply left running."
On the flip side I wonder if you can tell it to timeout and kill the service after a while, as I can equally see them getting stuck and never running again, a problem you don't have with the alternative method :-)
> When a job for this unit is queued, a time-out JobTimeoutSec= may be configured. Similarly, JobRunningTimeoutSec= starts counting when the queued job is actually started. If either time limit is reached, the job will be cancelled
I see this a LOT with wordpress & PHP "developers" deployed on shared hosting (where they often don't observe the runtime and such of these things). They end up having one script step over the next and the next and eventually combined they are generating so much load on the database or some other service that none of them ever finish. Fun fun...
I wonder if systemd timers can do that?
Obviously, you don't run your webserver that way (right!?) but it's not nuts to manage (even near real-time) queue consumers in a backend that way.
"Note that in case the unit to activate is already active at the time the timer elapses it is not restarted, but simply left running."
On the flip side I wonder if you can tell it to timeout and kill the service after a while, as I can equally see them getting stuck and never running again, a problem you don't have with the alternative method :-)
Ah, choices...
> JobTimeoutSec=, JobRunningTimeoutSec=, JobTimeoutAction=, JobTimeoutRebootArgument=
> When a job for this unit is queued, a time-out JobTimeoutSec= may be configured. Similarly, JobRunningTimeoutSec= starts counting when the queued job is actually started. If either time limit is reached, the job will be cancelled