[systemd-devel] running systemd in a cgroup: future compatibility
Hi all, I'm working on a use-case where I want to impose memory limits on the system in aggregate, with one process (e.g. memcached) opted-out of the limit. With a typical distribution's setup (Ubuntu, in my case), I would be able to impose a memory limit on each systemd slice (viz. user, machine, system) separately, but not in aggregate. I've found a solution for this by launching systemd in a cgroup of its own. In the initramfs, I have a script (snippet included below) which mounts the cgroupfs, puts all of the extant processes into a new cgroup, and then umounts the cgroupfs. This works for my needs: all of the processes in the system live in one cgroup, except memcached in a separate cgroup. systemd seems perfectly happy to boot in this configuration, correctly sensing that it's operating in a cgroup and nesting the processes it is responsible for under the existing cgroup. With memcached running separately, the resulting hierarchy looks like: /sys/fs/cgroup/ ├── memcached └── root ├── init.scope ├── system.slice ... And /proc/1/cgroup shows that the systemd (and more importantly, its descendants) lives in the memory cgroup: 11:net_cls,net_prio:/ 10:cpuset:/ 9:freezer:/ 8:hugetlb:/ 7:perf_event:/ 6:pids:/root/init.scope 5:devices:/root/init.scope 4:cpu,cpuacct:/ 3:blkio:/ 2:memory:/root 1:name=systemd:/root/init.scope I've tested against both legacy and unified cgroup hierarchies. The functionality to detect the current cgroups and nest processes underneath them appears to be in manager_setup_cgroup (src/core/cgroup.c:2033). My question for the list is what motivated adding this awesome feature to systemd in the first place, and (more importantly to me) is it likely to continue to exist in the future? Josh --- #!/bin/sh move_tasks() { cd "${MOUNTPOINT}" mkdir root exec 3< "${CGROUP_FILE}" set +e while read task; do echo $task > "root/${CGROUP_FILE}" 2>/dev/null done <&3 exec 3<&- set -e cd / umount "${MOUNTPOINT}" } MOUNTPOINT=/sys/fs/cgroup CGROUP_FILE=tasks mount -t cgroup -o none,name=systemd none "${MOUNTPOINT}" move_tasks mount -t cgroup -o memory none "${MOUNTPOINT}" cd "${MOUNTPOINT}" echo 1 > memory.use_hierarchy move_tasks mount -t cgroup2 none "${MOUNTPOINT}" CGROUP_FILE=cgroup.procs move_tasks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] running systemd in a cgroup: future compatibility
On Wed, Feb 14, 2018 at 3:06 AM, Josh Snyderwrote: > Hi all, > > I'm working on a use-case where I want to impose memory limits on the > system in > aggregate, with one process (e.g. memcached) opted-out of the limit. With a > typical distribution's setup (Ubuntu, in my case), I would be able to > impose a > memory limit on each systemd slice (viz. user, machine, system) > separately, but > not in aggregate. > > I've found a solution for this by launching systemd in a cgroup of its > own. In > the initramfs, I have a script (snippet included below) which mounts the > cgroupfs, puts all of the extant processes into a new cgroup, and then > umounts > the cgroupfs. > > This works for my needs: all of the processes in the system live in one > cgroup, > except memcached in a separate cgroup. systemd seems perfectly happy to > boot in > this configuration, correctly sensing that it's operating in a cgroup and > nesting the processes it is responsible for under the existing cgroup. With > memcached running separately, the resulting hierarchy looks like: > > /sys/fs/cgroup/ > ├── memcached > └── root > ├── init.scope > ├── system.slice > ... > > And /proc/1/cgroup shows that the systemd (and more importantly, its > descendants) lives in the memory cgroup: > > 11:net_cls,net_prio:/ > 10:cpuset:/ > 9:freezer:/ > 8:hugetlb:/ > 7:perf_event:/ > 6:pids:/root/init.scope > 5:devices:/root/init.scope > 4:cpu,cpuacct:/ > 3:blkio:/ > 2:memory:/root > 1:name=systemd:/root/init.scope > > I've tested against both legacy and unified cgroup hierarchies. The > functionality to detect the current cgroups and nest processes underneath > them > appears to be in manager_setup_cgroup (src/core/cgroup.c:2033). My > question for > the list is what motivated adding this awesome feature to systemd in the > first > place, and (more importantly to me) is it likely to continue to exist in > the > future? > I'm assuming it happens to work because the unprivileged `systemd --user` instances require the same kind of autodetection. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Journal statistics
I am interesting in getting some statistics information from journal, for eg., 1) number of logs 2) number of logs per severity 3) number of logs per daemon 4) time when log rotate happen ... Currently I am generating these data using journalctl and wc (journalctl | wc -l) Is there any other better/native way to get these statistics? Regards, Dinesh ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel