m (Talk:Features/ControlGroupsTools moved to Talk:Features/ControlGroups over redirect: Merge ControlGroupsTools and ControlGroupsKernel together) |
mNo edit summary |
||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
For real integration, this shouldn't require manual fstab editing -- notting | For real integration, this shouldn't require manual fstab editing -- notting | ||
jsafrane: There is no fstab editing, "only" /etc/cgconfig.conf and /etc/cgrules.conf. The /etc/init.d/cgconfig service reads these files and mount whatever is necessary. | |||
---- | |||
The way this is started via an init script is all wrong, if it's needed for putting daemons into groups, given the currently proposed initscript patches. You'd have to dynamically discover at runtime that you want to set a control group for a service, and then adjust start priorities on the fly. -- notting | The way this is started via an init script is all wrong, if it's needed for putting daemons into groups, given the currently proposed initscript patches. You'd have to dynamically discover at runtime that you want to set a control group for a service, and then adjust start priorities on the fly. -- notting | ||
jsafrane: we didn't find any better way at the moment. Upstream is thinking about marking executables with a flag, determining in which group it should be started. But how the flag(s) should look like and where it will be stored (fs attribute? config file?) is being discussed. This is long time run, init stripts just for the meantime. But I know, temporary solutions last the longest - the proposed init script hack is not *that* dirty. |
Latest revision as of 17:25, 20 February 2009
For real integration, this shouldn't require manual fstab editing -- notting
jsafrane: There is no fstab editing, "only" /etc/cgconfig.conf and /etc/cgrules.conf. The /etc/init.d/cgconfig service reads these files and mount whatever is necessary.
The way this is started via an init script is all wrong, if it's needed for putting daemons into groups, given the currently proposed initscript patches. You'd have to dynamically discover at runtime that you want to set a control group for a service, and then adjust start priorities on the fly. -- notting
jsafrane: we didn't find any better way at the moment. Upstream is thinking about marking executables with a flag, determining in which group it should be started. But how the flag(s) should look like and where it will be stored (fs attribute? config file?) is being discussed. This is long time run, init stripts just for the meantime. But I know, temporary solutions last the longest - the proposed init script hack is not *that* dirty.