On Thursday 13 Feb 2014 17:58:05 Damjan Georgievski wrote: > > Yeah, I think it's possible to get systemd to poll a script, or there's > > always cron (or a timer > > unit) that should allow us to manually inspect a process and restart it if > > necessary. But it > > would be cooler if there were shortcuts to features that we see in Monit > > and other similar > > systems; something like this in a unit file: > > > > MaxMemoryThreshold=100M > > MaxMemoryCheckInterval=30 > > MaxMemoryIntervalThrehold=2 > > > > The memory is then checked every 30 seconds. When the unit exceeds this > > amount of RAM > > for 2 successive intervals, the unit is restarted. > > there is setting of ulimits in systemd, it's much more brutal though, will > not wait for 30 seconds > > man systemd.exec Thank you; I didn't know about that, and it's very interesting. The limits are indeed a bit strict for server process monitoring. I imagine it would be really handy as a failsafe in embedded environments, though. The great benefit of them is that (as far as I can tell), it's the kernel that enforces the limits, so there's no polling involved. I suppose that the gold standard for monitoring would be a combination of the two: a userspace component (e.g. systemd or associated monitoring tool) registering to receive events from the kernel on certain resource thresholds for a process, so that e.g. time spent above RAM threshold could be monitored accurately in an event-based way, without polling. That would be awesome. Paul
