Одно решение, которое работало на меня, состояло в том, чтобы понизить systemd
к более старой версии, systemd 207-5.
Для других:
$ sudo yum history summary
предоставляет список обновлений и установок за различные периоды времени. Ссылка .
$ sudo yum history summary
Loaded plugins: fastestmirror, langpacks, refresh-packagekit, tsflags
Login user | Time | Action(s) | Altered
-------------------------------------------------------------------------------
Sam Mingo <slm> | Last day | Install | 1
Sam Mingo <slm> | Last week | I, U | 58
Sam Mingo <slm> | Last 2 weeks | Install | 22
Sam Mingo <slm> | Last 3 months | E, I, O, U | 2487
System <unset> | Last 3 months | Install | 1
Sam Mingo <slm> | Last 6 months | E, I, O, U | 1435
System <unset> | Last year | Install | 1169
history summary
-121--186804- На основании имени файла RecvRawEth.c
, которое вы разместили в своем комментарии выше, я предполагаю, что вы пытаетесь использовать необработанные сокеты ( SOCK _ RAW
). Это всегда требует, чтобы программа выполнялась как root, поскольку необработанные сокеты могут позволить обойти другие механизмы безопасности, такие как ограничение привилегированных портов .
Вам действительно следует переосмыслить это приложение. Очень немногие программы правомерно требуют необработанных сокетов. Почти всегда есть лучший способ.
Вы выбрасываете в смесь по крайней мере две дополнительные проблемы, которые на самом деле не кошерны на сайтах типа Stack Exchange, но я решу их в любом случае:
setuid root
Вы пытаетесь обойти ограничение на необработанные сокеты, пометив его как root
независимо от того, кто на самом деле его начал. Это может привести к открытию одной или нескольких брешей в системе безопасности. Поверьте: десятилетия истории Unix говорят нам, что сложные программы setuid root
, скорее всего, будут иметь эксплуатируемые проблемы. На их поиск и акциз может уйти много лет.
Если вы абсолютно должны использовать необработанные сокеты и, таким образом, нужно, чтобы какой-то элемент программы запускался как root, лучше всего записать его как демон с ограниченной областью . То есть сделать программу как можно меньше, делая только абсолютный минимум необходимо сделать как root
, плюс все, что необходимо для экспорта результирующей информации в программу, работающую с обычными привилегиями.
Запуск при загрузке
При создании демона настройка его для запуска при загрузке системы является тривиальной задачей. Любой приличный учебник, показывающий, как создать демон, перейдет в это. На Ubuntu, я считаю, что это означает иметь дело с systemd
.
Что касается части графического интерфейса пользователя, необходимо просто добавить ее к запуску сеанса .
По ссылке, которую я предоставил о полностью справедливом планировщике, мы видим, что в ядре 2.6.24 есть то, что называется групповым планированием.
Цитируем Чандандипа Сингха Паблу:
Например, допустим, в системе имеется в общей сложности 25 выполняемых процессов. CFS старается быть справедливым, выделяя 4% ЦП всем им. Однако допустим, что из этих 25 процессов 20 принадлежат пользователю A, а 5 принадлежат пользователю B. Пользователь B имеет собственный недостаток, поскольку A получает больше мощности ЦП, чем B. Групповое планирование пытается устранить эту проблему. Сначала он пытается быть справедливым к группе, а затем к отдельным задачам внутри этой группы. Таким образом, CFS с включенным групповым планированием выделит 50% CPU каждому пользователю A и B. Выделенная 50% доля A будет разделена между 20 задачами A, в то время как другие 50% времени CPU будут справедливо распределены между 5 тактами B.
Теперь,это относится к вышеуказанному вопросу, поскольку, когда процесс порождает новый поток, он будет находиться в этой группе планирования процессов. Это не позволяет программе, создающей 1000 потоков, использовать все время ЦП, поскольку она получит только 1/1001-ю (1000 потоков плюс исходная программа) времени выполнения данной группы процессов.
Таким образом, замедляя, сколько времени поток получает по сравнению со всей системой, это должным образом наказывает многопоточные приложения.