On Thu, Feb 13, 2014 at 5:19 PM, Paul Gideon Dann <pdgiddie@xxxxxxxxx> wrote: > On Thursday 13 Feb 2014 13:36:35 Denis A. Altoé Falqueto wrote: >> On Thu, Feb 13, 2014 at 1:29 PM, Paul Gideon Dann <pdgiddie@xxxxxxxxx> wrote: >> > Yeah, though actually I'm just really surprised that, given the incredible >> > administrative benefits of systemd, there isn't currently anything that >> > leverages it for actual process monitoring and reporting. As far as I >> > can tell, systemd is also not yet able to automatically restart bloated >> > or stale services (e.g. worker instances that may go haywire). Hopefully >> > these things will come along now that "systemd --user" is maturing. >> I think you can rely on software or hardware watchdogs, which are >> supported by systemd. > > 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. > > Paul Well, you have the LimitAS= option. I've used it with Restart=on-failure with some services. If I understand it correctly, it will not restart the service when the memory limit is reached, but `malloc()` will return an error. Since many programs are not prepared for that, they segfault and then they are restarted automatically. Not very elegant, but you don't need the polling interval. Rodrigo
