No subject

really has nothing that ties it to users/groups.  It *does* have the
ability to act on new processes that are by certain user or group
though, so probably the section you are reading.

Besides that feature, it works on just plain ole processes as well.
There does not need to be any user/group trickery involved.  Just
putting * * in cgrulesd.conf shows that.

>
> I understand, first case - from userspace perspectve - means task should be launched via suexec().

Not necessarily - see above

> In mythtv sources I see commands are launched via:
> /* Run command */
> execl("/bin/sh", "sh", "-c", cmdargs, (char *)0);
>
> I didn't see here suexec() and I'm not sure are tasks launched by myth in above way are handled by cgrulesengd.

*All* tasks are handled by cgrulesend

> I'm wonder: did You do tests with mythcommflag in Your setup for checking is it correctly moved to myth_low group ?

Yes I did :)  However, over the weekend I was doing additional testing
with 4 commflaggers running and saw some microfreezes again, but since
I was running sshd at the highest priority, it may have been my fault.
 The shell I was using was running all of my commands and starving
even mythfrontend while I was compiling some software.  I am going to
re-think that portion on how I have it setup.  I just removed sshd
from the rules engine for now.  Before I added it, my shell was
sluggish during those times.

As long as a new PID is created with the name specified in cgrulesend,
then those perms take affect.  Now, if no perm is specified for
mythcommflag for example, it would automatically inherit those from
mythbackend which is in the mythtv_med group.

-Greg

> br
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>