Tại sao các nhóm được ánh xạ khác nhau trên hai hệ thống này bởi systemd

Tôi có hai hệ thống, cả hai đều chạy các biến thể tùy chỉnh của OpenSuSE 12.2 (Thần chú), cả hai đều chạy chính xác cùng một hạt nhân. Tôi nhận được hai đầu ra rất khác nhau của /proc/self/cgrouphoặc /proc/$$/cgrouptrên hai hệ thống:

Hệ thống A (hoặc cổ phiếu OpenSuSE 12.1):

cat /proc/self/cgroup 
9:perf_event:/
8:blkio:/
7:net_cls:/
6:freezer:/
5:devices:/
4:memory:/
3:cpuacct,cpu:/
2:cpuset:/
1:name=systemd:/user/root/6

Hệ thống B:

root@msx:/sys/fs/cgroup> cat /proc/self/cgroup 
9:perf_event:/
8:blkio:/
7:net_cls:/
6:freezer:/
5:devices:/
4:memory:/
3:cpuacct,cpu:/system/serial-getty@.service/ttyS0
2:cpuset:/
1:name=systemd:/system/serial-getty@.service/ttyS0

Tại sao dòng 1 khác nhau và tại sao dòng 3 hiện diện trong một và vắng mặt trong dòng khác? Tôi không thể tìm thấy sự khác biệt về cấu hình giữa hai hệ thống. Họ chạy cùng một phiên bản systemd ( systemd-44-10.1.1.x86_64). Nếu tôi nhân đôi các giá trị sysctl thì nó không có hiệu lực. Các tùy chọn khởi động là như nhau. Tôi đã so sánh tất cả mọi thứ trong /etc, /usrvà /libđể xem nếu có bất kỳ sự khác biệt cấu hình có liên quan. (Có các RPM được cài đặt khác nhau nhưng không có RPM nào nằm trong bất kỳ tệp cấu hình hệ thống nào và tôi nghĩ rằng tôi đã xóa tất cả các RPM tùy chỉnh.)

Đây không chỉ là một yếu tố gây tò mò bởi vì trên Hệ thống B, chúng tôi không thể tạo một SCHED_RRluồng, nhưng trên Hệ thống A, chúng tôi có thể. Nếu tôi đặt DefaultControllerđể NULLở /etc/systemd/system.conf, nó hoạt động, và dòng 3 biến mất (dòng 1 vẫn khác nhau). Nó cũng hoạt động nếu tôi viết ID tiến trình của shell gọi vào /sys/fs/cgroup/cpu,cpuacct:

root@msx:/root> ./a.out
Creation of real-time thread FAILED - Operation not permitted
root@msx:/root> cat /proc/$$/cgroup
9:perf_event:/
8:blkio:/
7:net_cls:/
6:freezer:/
5:devices:/
4:memory:/
3:cpuacct,cpu:/system/sshd.service
2:cpuset:/
1:name=systemd:/system/sshd.service
root@msx:/root> echo $$ > /sys/fs/cgroup/cpu,cpuacct/tasks
root@msx:/root> ./a.out
root@msx:/root> cat /proc/$$/cgroup
9:perf_event:/
8:blkio:/
7:net_cls:/
6:freezer:/
5:devices:/
4:memory:/
3:cpuacct,cpu:/
2:cpuset:/
1:name=systemd:/system/sshd.service

Không chắc chắn tại sao điều này hoạt động. Các đồng nghiệp của tôi không hài lòng rằng vấn đề được hiểu, vì nó không yêu cầu thay đổi cấu hình này.

Kernel là 3.4.47, CONFIG_RT_GROUP_SCHEDđược bật, CONFIG_AUTOGROUPđược bật (vô hiệu hóa vẫn không hoạt động nhưng nó không hoạt động khác nhau)

Đây là một spinoff của /programming/20412336/how-to-check-for-permissions-for-sched-setscheduler .

linux-kernel systemd cgroups

— eewanco
nguồn

Làm thế nào để bạn đăng nhập?

— Hauke Laging

@Hauke - Đăng nhập hoạt động tốt; thông thường tôi đăng nhập thông qua bảng điều khiển nối tiếp như trong ví dụ này, nhưng ssh cũng hoạt động (và có hành vi tương tự).

— eewanco

@Hauke - ok Tôi thấy một sự bất thường trong ví dụ cuối cùng; Tôi đã vô tình cắt và dán từ hai lần chạy khác nhau. Tôi vừa thực hiện một lần chạy và viết lại ví dụ để phương thức đăng nhập phù hợp trước và sau khi kiểm tra!

— eewanco

Đầu ra của mount | grep cgroupmỗi hệ thống là gì?

— dị

mèo / Proc / cgroups

— c4f4t0r

Có một tùy chọn cấu hình system.conf, DefaultControllers, điều khiển phân cấp cgroup nào được đính kèm. Theo mặc định, đó là cpu. Tôi đặt nó thành null và / Proc / $$$ / cgroup không còn liệt kê quy trình getty theo cpuacct, cpu và chương trình thử nghiệm hoạt động. Tại sao cùng một tệp cấu hình - Tôi đang sử dụng mặc định được sử dụng trên cả hai hệ thống - tôi đã biết hai kết quả khác nhau. Tôi không chắc đây là cách tốt nhất để giải quyết vấn đề hay tại sao nó hoạt động. Vì vậy, tôi đã thay đổi

#DefaultControllers=cpu

đến

DefaultControllers=

trong /etc/systemd/system.confvà nó hoạt động.

— eewanco
nguồn