Re: [Patch] Revised resource-support [aka. "proc"-support]

[Jan-Henrik Haukeland]

First, I'm impressed, this looks good. Although I have to admit that I
don't understand much of the sys. dependent code. Even if I appreciate
it, this is your code so add yourself as the only author (or at least
as the first author in the @author tag.)

Here are some initially comments in no particular order:

- I have changed the macros used in configure.in to test against so
  they are alligned with your code:

  FREEBSD
  LINUX
  SOLARIS

- I think it's safely to assume that you will have to be root to use
  the proc system. So adding something like the following in p.y in the
  semantic action is necessary:

   | MEMUSAGE REAL { 

       if(getuid()) {
          error("%s: You must run as root to utilize the process "
                "statement at line: %d\n",prog, lineno);
           cfg_errflag++;
        } else {
         resourceset.resource_id= RESOURCE_ID_MEM_PERCENT;
         resourceset.max_value= (int) ($2 * 10.0); 
        }
    }

   and so on, maybe for safty also add the same to init_proc_info():
       if(!getuid())
          error("%s: You must run as root to utilize the "
                "process status functionality.\n", prog);


- Structure suggestion. Create a directory called proc (or something)
  and copy the sysdep files to this directory. Keep proc_interface.* in
  the top-level dir. but maybe rename the files to monit_process.* like we 
  have done with monit_http for the http sub-system?


> check foo-inet with pidfile /var/run/foo_daemon.pid
>     # long version
>     if memusage greater 10.0 for 2 cycles
>     if memkbyte greater 2000 for 2 cycles
>     # short version
>     cpuusage 10.0 3

- We should add actions to the statements. Like,
       
      if cpuusage is greated than 10.0 for 3 cycles then restart
      if memusage is greated than 10.0 for 2 cycles then stop
      if memkbyte is greated than 90M  for 2 cycles then alert

  And where the last one only sends an alert message. This means that
  we need to add more event types to alert.
      
  We could even do (I'm stretching it here, I know. Better for a later
  version)
       
       if cpuusage is greated than 80.0 for 4 cycles then 
          stop until load < 1.5 and then restart


> 
> 3) Zombie check environment changed... the zombie check is separated
>    as check_process_state(p).  Thus, we can add other states and it is
>    actually no resource.

Since any user can run monit (it's one of its features) you will need
to mask out calls to update_proc_data, check_resources and
check_process_state, add something along the line
 if(getuid()) then do not test.

> 1) Alarm integration... clear, or?

?

> 3) Web interface support (maybe with all the nice performance statistics)

Yeah, that would be nice, after everything runs okay.


-- 
Jan-Henrik Haukeland