date:20110909

2011/9/10 Victor Wagner :

> Поэтому вполне сработает такая конструкция
>
> LIST=`cat /dev/cpuset/tasks`
> for pid in $LIST; do
>        echo $pid > /dev/cpyset/syscpuset/tasks
> done

Спасибо. Вот как раз того, что шелловский for умеет итерировать по
строке, разделяя newlines, я и не знал.

(Это подойдёт - там просто числа, разделённые newline).

>> Если шеллом можно сделать _это_, может им можно и конфиг разобрать? В
>
> Да, естественно.
>
> Я очень часто делаю конфиги скриптами на том же языке, что и основной
> продукт, и промом просто делаю им source/require и т.д.

Всё что тут надо конфигурировать, по максимуму:

CPUSETNAME=name
CPUS=cpus
MEMS=mems
MOVE_KERNEL_PROCESSES=[true|false]

В первой версии хватит CPUS и MEMS (имя "прибить гвоздиком", имеющиеся
процессы всегда перегонять). Для 80-90% случаев этого IMHO достаточно.

Ну, вообще это _можно_ сделать исполняемым. И вроде бы при ошибке,
если новых строк не добавлять, оно как максимум не сработает, но
система загрузится. Потому что если cpus/mems невалидно, система
просто не позволяет записать задачи в новый cpuset.

> Как мне кажется, куда более прямым решением будет не /sbin/kprint а
> /dev/kprint - маленький такой ядерный модуль, предоставляющий character
> devices, и передающий все, что туда пишется, в буфер сообщений ядра.

Я просто не верю, что готовое решение для логгинга userland процессов
до RW монтирования /var/log отсутствует. Ну сам-то /sbin/init должен
куда-то сообщить об ошибке в /etc/inittab .

> Дело в том, что для /sbin/kprint тебе все равно понадобится какой-то
> интерфейс с ядром - просто так внутреннюю ядерную функцию ты из
> userspace не позовешь.

Вот это и вопрос - позовёшь или нет. Если нет, то для работы решения
требуется собрать ядерный модуль. Значит, чтобы оно работало нормально
при штатном обновлении ядра (подъём версии - тоже штука штатная), мне
ещё и dkms прикручивать придётся. Как-то оно явно того не стоит. Уж
проще этот скрипт выпустить без лога.

(А создавать больше одного cpuset ему не нужно в принципе. Куда более
продвинутая система управления cpuset для sysv init уже есть. А этот
скрипт - для параноидального выгоняния всей системной шушеры _сразу_,
чтобы даже sysv init не дожидаться).

-- 
Yours, Mikhail Ramendik

Unless explicitly stated, all opinions in my mail are my own and do
not reflect the views of any organization

nice -n - только от рута?

Всем привет!

Гуглил, но что-то не нагуглил. Я хочу запустить юзерский процесс с
nice -2 или -5 - это mplayer, ему надо весь процессор, а там всякие
iceweasel мешаются. Их просто забыли закрыть.

Есть ли способ это сделать, _кроме_ как renice `pidof mplayer` от
рута? Можно ли как-то дать данному юзеру нужную привилегию?

-- 
Yours, Mikhail Ramendik

Unless explicitly stated, all opinions in my mail are my own and do
not reflect the views of any organization

Re: Динамически включать-выключать CPU

On 2011.09.10 at 05:29:03 +0100, Mikhail Ramendik wrote:

> 2011/9/10 Victor Wagner :
> 
> > Ну и то, что ты делаешь на python тоже прекрасно делается на shell.
> >
> > Есть в нем и read и for, и while
> 
> Мне нужно следующее:
> 
> - Считать содержимое /dev/cpuset/tasks в массив, по строчкам. И больше
> этот файл не трогать совсем. Массив должен быть в памяит (больше
> негде, файлова система read only)

Зачем тебе именно массив? Тебе нужна любая структура данных, по которой
можно итерировать. 

Насколько я понимаю, строчки в /dev/cpu/tasks пробелов и прочих
специсиволов не содержат.

Поэтому вполне сработает такая конструкция

LIST=`cat /dev/cpuset/tasks`
for pid in $LIST; do
echo $pid > /dev/cpyset/syscpuset/tasks
done

Командная строка с итерированием по аргументом - одна из самых
естественных конструкций для shell.

Если же в /dev/cpuset/tasks  в строчках встречаются специсимволы 
шелла (пробелы, кавычки и прочая фигня, которая помешает при
многократной подстановке, любимой шеллом)

то никто не мешает засунуть файл в переменную AS IS

LIST="`cat /dev/cpuset/tasks`"

а потом читать его из пайпа

echo "$LIST" | while read line; do 
echo $line >/dev/cpuset/syscpyset/tasks
done

Обрати внимание на кавычки вокруг бэктиков и подстановки $LIST в
аргументы echo.

> - Каждой строке массива отдельно сделать echo $string
> >/dev/cpuset/syscpuset/tasks . Ошибки игнорировать.
> 
> Я не смог нагуглить, как сделать это шеллом. Поэтому и сделал питоном.

А не надо такие вещи гуглить. Их надо головой думать. В смысле пытаться
разобрать операцию на элементарные составляющие, и пытаться выразить
их на требуемом языке. 

При этом всячески избегать использования ложных паттернов. Таких,
например, как "массив".

Потому что, хотя я даже не исключаю, что в том шелле, который работает
/bin/sh  на твоей конкретной машине, массивы есть (я, кстати, так за
десять лет существования шелловских массивов не научился ими
пользоваться), зарекаться на то, что в любом наугад взятом /bin/sh они
есть, не стоит.

> Если шеллом можно сделать _это_, может им можно и конфиг разобрать? В

Да, естественно.

Я очень часто делаю конфиги скриптами на том же языке, что и основной
продукт, и промом просто делаю им source/require и т.д.

Некоторые считатют, что тьюринг-полный язык конфигов да еще с
возможностью доступа в namespace основной программы - это vulnerability,
но я полагаю, что в большинстве случаев то, кто имеет право править
конфиг, имеет право править и программу. 

> этом случае даже production решение (для публикации) можно делать на
> шелле. Особенно если независимо от того сделать /sbin/kprint для
> выкидывания чего-нибудь в dmesg.

Как мне кажется, куда более прямым решением будет не /sbin/kprint а 
/dev/kprint - маленький такой ядерный модуль, предоставляющий character
devices, и передающий все, что туда пишется, в буфер сообщений ядра.

Дело в том, что для /sbin/kprint тебе все равно понадобится какой-то
интерфейс с ядром - просто так внутреннюю ядерную функцию ты из
userspace не позовешь. 

А если этот интерфейс сделать в виде character device (а это -
совершенно стандартный, документированный и снабженный кучей примеров
способ приделывания интерфесов к ядерным модулям), то в юзерспейсе тебе
ничего специального не понадобится - обычного echo хватит.

> 
> -- 
> Yours, Mikhail Ramendik
> 
> Unless explicitly stated, all opinions in my mail are my own and do
> not reflect the views of any organization

-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110910061311.ga1...@wagner.pp.ru

Re: Динамически включать-выключать CPU

2011-09-09 Пенетрантность Вячеслав Комаров

2011/9/10 Victor Wagner :

> Не слушай ты темных и необразованных людей. Я тоже, когда был молодой и
> глупый, пытался ядро патчить для решения задач, к которым существуют
> userspace решения.

Вот сейчас я хочу найти, надеюсь, пока что последнее решение для тго
конкретного набора (дальше - тестирование).

А именно - как мне произвести нужную операцию для процесса, который
породит все _юзерские_ процессы после логина. Но не рутовые, например
не X сервер.

В Xsession что ли, и если да - какой у дебиановского kdm Xsession?

Я хочу попробовать дать этому процессу оба процессора ( грубо говоря,
sudo echo $$ >/dev/cpuset/tasks - реально это будет вызываемый по sudo
скрипт с pid в качестве $1). Оставив при этом все системные/рутовые
процессы на одном СPU 0.

Если систему завешивает какой-то конкретный кривой процесс, а не
scheduler, то этого должно быть достаточно для борьбы с зависанием.
Более того, если CPU 1 битое аппаратно - насколько я понимаю тоже,
поскольку нерутовое приложение систему не вешает, а из проблем умеет
либо процессор загружать, либо падать.

(А что касается mplayer - так ему я ещё и nice -2 хочу дать, если с
безопасностью справлюсь. Чтобы он успешно играл фильмы, требующие
всего процессора, когда загружен iceweasel и отжирает процентов 40-50
одного ядра).

-- 
Yours, Mikhail Ramendik

Unless explicitly stated, all opinions in my mail are my own and do
not reflect the views of any organization

Испания ближе чем Вы думаете

 Испания - замечательная страна. У нее есть и море, и солнце, много вкусных 
фруктов и морепродуктов, здесь сосредоточены известные памятники истории и 
архитектуры. А что касается покупки недвижимости в Испании, то это своеобразный 
пропуск в еврозону, что, согласитесь, весьма заманчивая перспектива. 
Недвижимость - повод для получения мультивизы на пребывание в стране в течение 
180 дней по 90 дней в полгода. А также возможность обретения вида на жительство 
при условии, если собственник открывает свой бизнес в Испании или инвестирует 
средства в какой-либо проект на ее территории.
 
Предлагаем купить недвижимость в Испании - это престижно и выгодно!
  
Почему это лучше сделать именно с нами? 

Вы не платите комиссионные. С вами будет работать рускоговорящий  сотрудник 
крупной испанской фирмы, как на этапе ознакомления, так и непосредственно при 
показе объектов.
  
Мы полностью оформим пакет документов на покупку недвижимости в Испании , а 
также поможем получить кредит в испанском банке. 
  
Мы всегда в Вашем распоряжении, и до и после заключения сделки проконсультируем 
по юридическим и бытовым вопросам, посоветуем, где и как интересно провести 
время, поможем решить любые проблемы во время Вашего пребывания в Испании, 
связанные с покупкой недвижимости
   
Тел: 8 9O6 727 66 41
 


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/11p5sq-3jzey0...@wonderware.com

Re: Динамически включать-выключать CPU

2011-09-09 Пенетрантность Artem Chuprina

> #!/usr/bin/python
> f=open("/dev/cpuset/tasks")
> tasks=f.readlines()
> f.close()
> 
> for task in tasks:
>   try:
> f=open("/dev/cpuset/syscpuset/tasks","w")
> f.write(task)
> f.close()
>   except IOError:
> pass
> 
> Я конечно вижу, что это грязно, в общем случае на /usr нельзя
> рассчитывать и надо на Си писать, но влом. Или этот же эффект как-то
> достигается на shell+busybox?
>

for task in `cat /dev/cpuset/tasks`
do
echo $task > /dev/cpuset/syscpuset/tasks
done

Правда, я не смог посмотреть, что там пишется - у меня такого файла нет.  Если
в /dev/cpuset/tasks больше одного слова на задачу, то надо более тщательно
строить цикл.

> А теперь вопрос - как бы мне выяснить, что это у меня за 20 задач,
> которые не переносятся? Проверил у нескольких /proc/$pid/cmdline -
> пусто. Но там и у kswapd0 пусто, а top как-то знает, что это именно
> он. Как мне-то узнать?

/proc/$PID/stat

> Гугль не помог :( Особенно это будет важно,
> если выяснится что весь этот хак не работает, а isolcpus работает.

Скорее всего, треды ядра.  К которым, собственно, относится и kswapd.

-- 
Если ты не боишься синего экрана, то почему боишься черного?
 -- Д.Белявский


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ty8lng8l.wl%...@ran.pp.ru

Re: Динамически включать-выключать CPU

2011/9/10 Victor Wagner :
> On 2011.09.10 at 03:14:57 +0100, Mikhail Ramendik wrote:
>
>> Можно, но так как получилось - явно проще. (А что грязно - так
>> переписать с shell+python на pure C будет быстреею чем библиотеку
>> сочинять).
>
> Совершенно не факт. Библиотек это ни разу не rocket science. Это такой
> же исходник на pure C.

Ага, но там придётся алгоритм для load balancing придумывать. Этот
тред туда, а этот сюда. А зачем, когда оно в ядре уже есть? Ты же сам
против того чтобы делать работу, которая уже сделана.

Решение через cpuset позволяет обойтись _тривиальным_ кодом. То есть,
если бы не моя отсталость от нынешнего C, то проблем бы не было вовсе,
а так - ну, грязновато вышло, но для проверки сойдёт. Может ведь и не
помочь.

-- 
Yours, Mikhail Ramendik

Unless explicitly stated, all opinions in my mail are my own and do
not reflect the views of any organization

Re: Динамически включать-выключать CPU

2011/9/10 Victor Wagner :

> Ну и то, что ты делаешь на python тоже прекрасно делается на shell.
>
> Есть в нем и read и for, и while

Мне нужно следующее:

- Считать содержимое /dev/cpuset/tasks в массив, по строчкам. И больше
этот файл не трогать совсем. Массив должен быть в памяит (больше
негде, файлова система read only)

- Каждой строке массива отдельно сделать echo $string
>/dev/cpuset/syscpuset/tasks . Ошибки игнорировать.

Я не смог нагуглить, как сделать это шеллом. Поэтому и сделал питоном.

Если шеллом можно сделать _это_, может им можно и конфиг разобрать? В
этом случае даже production решение (для публикации) можно делать на
шелле. Особенно если независимо от того сделать /sbin/kprint для
выкидывания чего-нибудь в dmesg.

-- 
Yours, Mikhail Ramendik

Unless explicitly stated, all opinions in my mail are my own and do
not reflect the views of any organization

Re: Динамически включать-выключать CPU

2011/9/10 Victor Wagner :
> Всего-то что тебе надо - это где-то прикопать некоторое количество
> информации до тех пор, пока не появится возможность тем или иным
> способом записать его в файловую систему. Совершенно необязательно,
> кстати, это делать через syslog. Можно просто файлик в /var/log открыть,
> после того как /var будет смонтирован read-write.

Так мой процесс, маленький совсем, запускается _до_ монтирования чего-либо RW.

Я пока без логгинга обойдусь, но неприятно.

-- 
Yours, Mikhail Ramendik

Unless explicitly stated, all opinions in my mail are my own and do
not reflect the views of any organization

Re: Динамически включать-выключать CPU

On 2011.09.10 at 03:14:57 +0100, Mikhail Ramendik wrote:

> Можно, но так как получилось - явно проще. (А что грязно - так
> переписать с shell+python на pure C будет быстреею чем библиотеку
> сочинять).

Совершенно не факт. Библиотек это ни разу не rocket science. Это такой
же исходник на pure C.

Ну и то, что ты делаешь на python тоже прекрасно делается на shell.

Есть в нем и read и for, и while

-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110910042432.gb32...@wagner.pp.ru

Re: Динамически включать-выключать CPU

On 2011.09.10 at 02:28:26 +0100, Mikhail Ramendik wrote:

> 2011/9/10 Иван Лох :
> 
> >> И узнать, какой процесс как называется, никак нельзя? А то kswapd0
> >> вроде тоже в контексте ядра должен быть, а top знает как его зовут.
> >
> > ps aux -- те, что в квадратных скобках
> 
> Нагуглил другой способ - спасибо за ключевые слова, без них не нагуглилось.
> 
> cat /proc/$pid/status | grep name
> 
> > Пока syslog не запущен то printk только так. А потом можно logger
> 
> У меня "вместо init", значит printk. Значит Си. Я пока пытаюсь Сей

Не слушай ты темных и необразованных людей. Я тоже, когда был молодой и
глупый, пытался ядро патчить для решения задач, к которым существуют
userspace решения.

Всего-то что тебе надо - это где-то прикопать некоторое количество
информации до тех пор, пока не появится возможность тем или иным
способом записать его в файловую систему. Совершенно необязательно,
кстати, это делать через syslog. Можно просто файлик в /var/log открыть,
после того как /var будет смонтирован read-write.

-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110910042250.ga32...@wagner.pp.ru

Re: Динамически включать-выключать CPU

2011/9/10 Mikhail Ramendik :
> Можно, но так как получилось - явно проще.

Кажется, можно совсем красиво сделать. Но нужна подсказка по деталям.

А именно - через некоторое время после логина (производимого при
помощи kdm) юзерский процесс сразу отправить в /dev/cpuset/tasks,
чтобы всем юзерским задачам дать два процессора.

При этом, сам X сервер должен остаться где был, на одном процессоре.
Но я посмотрел в top - он от рута работает.

Вопрос в том, куда это поставить. Чьими детьми будут все процессы,
запускаемые самим юзером (именно при логине через kdm, консоль/ssh не
рассматриваем)? И в какой скрипт это, соответственно, вставить?

Сам вроде бы догадываюсь до Xsession (положить скрипт в
/etc/X11/Xsesson.d - они вроде бы выполняются не exec, а source, и
потому в $$ там толжен быть pid как раз сессии). Но - сработает ли? И
точно ли это выполняется уже от юзера и не имеет отношения к запуску
самого сервера? Я попросту не понял этого из манов.

Кроме того, гугль вроде бы подсказывает, что поскольку используется
kdm - править придётся /etc/kde4/kdm/Xsession. Или всё-таки
/etc/X11/Xsession.d сработает?

А то получается шанс "прозрачно" решить проблему. Хотя и не факт, что
получится, но уж больно приятный выходит вариант. Вообще без потери
удобства и производительности - просто загнали всю систему на CPU0.

--
Yours, Mikhail Ramendik

Unless explicitly stated, all opinions in my mail are my own and do
not reflect the views of any organization

Re: Динамически включать-выключать CPU

2011/9/10 Иван Лох :
> On Sat, Sep 10, 2011 at 02:55:45AM +0100, Mikhail Ramendik wrote:
>> 2011/9/10 Иван Лох :
>> >
>> > Но все-таки. А почему нельзя поменять affinity у одной из нитей mplayer??
>>
>> Нет такой опции в командной строке. Это в исходник лезть. А там
>> непростой исходник. К тому же он регулярно обновляется и я не хотел бы
>> устраивать личный форк.
>>
>> (А сделать настоящий патч, с новой опцией и её разбором, я пожалуй что
>> не потяну).
>
> Это скорее надо с LD_PRELOAD загружать библиотеку, которая fork() и clone()
> слегка модифицирует.

Можно, но так как получилось - явно проще. (А что грязно - так
переписать с shell+python на pure C будет быстреею чем библиотеку
сочинять).


-- 
Yours, Mikhail Ramendik

Unless explicitly stated, all opinions in my mail are my own and do
not reflect the views of any organization

Re: Динамически включать-выключать CPU

On Sat, Sep 10, 2011 at 02:55:45AM +0100, Mikhail Ramendik wrote:
> 2011/9/10 Иван Лох :
> >
> > Но все-таки. А почему нельзя поменять affinity у одной из нитей mplayer??
> 
> Нет такой опции в командной строке. Это в исходник лезть. А там
> непростой исходник. К тому же он регулярно обновляется и я не хотел бы
> устраивать личный форк.
> 
> (А сделать настоящий патч, с новой опцией и её разбором, я пожалуй что
> не потяну).

Это скорее надо с LD_PRELOAD загружать библиотеку, которая fork() и clone()
слегка модифицирует.


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110910020354.gg6...@nano.ioffe.rssi.ru

Re: Динамически включать-выключать CPU

2011/9/10 Иван Лох :

>> Прикол в том, что на эту тему нагуглился разговор в LKML, там isolcpus
>> хотели отменить, но нашлись юзеры, его применяющие. Вот переписать моё
>> решение на Сях, уонфиг ему сделать - и закинуть в LKML как
>> уж-совсем-полный аналог isolcpus?
>
> Но все-таки. А почему нельзя поменять affinity у одной из нитей mplayer??

Нет такой опции в командной строке. Это в исходник лезть. А там
непростой исходник. К тому же он регулярно обновляется и я не хотел бы
устраивать личный форк.

(А сделать настоящий патч, с новой опцией и её разбором, я пожалуй что
не потяну).

Установка affinity на два СPU для процесса mplayer - не помогает. Либо
на один, либо на другой, но не на оба. Вот такая неприятная штука
isolcpus.

Я гуглил, у людей была похожая задача. Примерно так: isolcpus 1-3,
надо было сделать процесс load balanced между CPU 2 и CPU 3. Ответ был
- не используйте isolcpus, используйте cpuset.

Однако, это уже решили. При использовании cpuset проблемы просто нет.
Ну, sudo требуется, но это дело штатное. (Хотя более корректно было бы
играть с правами доступа на файл tasks, но какая уж тут корректность
если я на /usr/bin/python рассчитываю при запуске init).

-- 
Yours, Mikhail Ramendik

Unless explicitly stated, all opinions in my mail are my own and do
not reflect the views of any organization

Re: Динамически включать-выключать CPU

On Sat, Sep 10, 2011 at 02:28:26AM +0100, Mikhail Ramendik wrote:
> 
> Прикол в том, что на эту тему нагуглился разговор в LKML, там isolcpus
> хотели отменить, но нашлись юзеры, его применяющие. Вот переписать моё
> решение на Сях, уонфиг ему сделать - и закинуть в LKML как
> уж-совсем-полный аналог isolcpus?

Но все-таки. А почему нельзя поменять affinity у одной из нитей mplayer??


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110910014419.gf6...@nano.ioffe.rssi.ru

Re: Динамически включать-выключать CPU

2011/9/10 Иван Лох :

>> И узнать, какой процесс как называется, никак нельзя? А то kswapd0
>> вроде тоже в контексте ядра должен быть, а top знает как его зовут.
>
> ps aux -- те, что в квадратных скобках

Нагуглил другой способ - спасибо за ключевые слова, без них не нагуглилось.

cat /proc/$pid/status | grep name

> Пока syslog не запущен то printk только так. А потом можно logger

У меня "вместо init", значит printk. Значит Си. Я пока пытаюсь Сей
избежать, так что обойдусь :) Хотя если где-нибудь есть исходник, из
коего можно сделать /bin/printk...

При помощи простенького питонного скрипта с os.system() я узнал, какие
же процессы у меня остались не в новом cpuset:

Name: migration/0
Name: ksoftirqd/0
Name: watchdog/0
Name: migration/1
Name: ksoftirqd/1
Name: watchdog/1
Name: events/0
Name: events/1
Name: kintegrityd/0
Name: kintegrityd/1
Name: kblockd/0
Name: kblockd/1
Name: kondemand/0
Name: kondemand/1
Name: aio/0
Name: aio/1
Name: crypto/0
Name: crypto/1
Name: ata/0
Name: ata/1

Для сравнения:

$ cat /proc/31/status | grep Name
Name: kswapd0

Таким образом, /0 или /1 это такие CPU affinity. Это подтверждается
просмотром полного /proc/$pid/status - там есть пункт
Cpus_allowed_list и в нём для данных процессов указан 0 или 1.

Более того. Точно такие же процессы имеются при isolcpus=1 - и для CPU
1 тоже. Значит, мне удалось полностью реплицировать isolcpus на
cpusets.

Прикол в том, что на эту тему нагуглился разговор в LKML, там isolcpus
хотели отменить, но нашлись юзеры, его применяющие. Вот переписать моё
решение на Сях, уонфиг ему сделать - и закинуть в LKML как
уж-совсем-полный аналог isolcpus?

Ладно, это потом, сначала узнаем, пропадут ли зависы. Пока погонял
сколько-то с no_hz=off - не зависло, а обычно с ним висло быстро...

(И кстати, если пропадут - стоит ли пытаться искать баг, возвращая
задачи на оба процессора? Или заработало - и ладно? Или можно так:
заработало - и ладно, но написать в ЖЖ на английском и русском
решение, чтобы следующие напоровшиеся смогли его найти?)

Кстати, всем огромное спасибо - я бы не добрался до столь странного
решения без КУЧИ подсказок.

--
Yours, Mikhail Ramendik

Unless explicitly stated, all opinions in my mail are my own and do
not reflect the views of any organization

Re: Динамически включать-выключать CPU

On Sat, Sep 10, 2011 at 05:11:22AM +0400, Иван Лох wrote:
> On Sat, Sep 10, 2011 at 05:04:04AM +0400, Иван Лох wrote:
> > 

/proc/*/comm


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110910011546.ge6...@nano.ioffe.rssi.ru

Re: Динамически включать-выключать CPU

On Sat, Sep 10, 2011 at 05:04:04AM +0400, Иван Лох wrote:
> 
> ps aux -- те, что в квадратных скобках

То есть, конечно, в скобках все те у которых нет args...
Это могут и процессы запущенные через pipe быть, например

-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110910011122.gd6...@nano.ioffe.rssi.ru

Re: Динамически включать-выключать CPU

On Sat, Sep 10, 2011 at 01:58:27AM +0100, Mikhail Ramendik wrote:
> 2011/9/10 Иван Лох :
> 
> >> А теперь вопрос - как бы мне выяснить, что это у меня за 20 задач,
> >> которые не переносятся? Проверил у нескольких /proc/$pid/cmdline -
> >> пусто. Но там и у kswapd0 пусто, а top как-то знает, что это именно
> >> он. Как мне-то узнать? Гугль не помог :( Особенно это будет важно,
> >> если выяснится что весь этот хак не работает, а isolcpus работает.
> >
> > Это процессы в контексте ядра. Типично у них используемая память равна 0
> 
> И узнать, какой процесс как называется, никак нельзя? А то kswapd0
> вроде тоже в контексте ядра должен быть, а top знает как его зовут.

ps aux -- те, что в квадратных скобках

> > #include 
> > #include 
> 
> Стоп, это модуль для ядра? А то у меня-то userland процесс, пусть и

Пока syslog не запущен то printk только так. А потом можно logger


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110910010404.gc6...@nano.ioffe.rssi.ru

Re: Динамически включать-выключать CPU

2011/9/10 Иван Лох :

>> А теперь вопрос - как бы мне выяснить, что это у меня за 20 задач,
>> которые не переносятся? Проверил у нескольких /proc/$pid/cmdline -
>> пусто. Но там и у kswapd0 пусто, а top как-то знает, что это именно
>> он. Как мне-то узнать? Гугль не помог :( Особенно это будет важно,
>> если выяснится что весь этот хак не работает, а isolcpus работает.
>
> Это процессы в контексте ядра. Типично у них используемая память равна 0

И узнать, какой процесс как называется, никак нельзя? А то kswapd0
вроде тоже в контексте ядра должен быть, а top знает как его зовут.

>>
>> И ещё вопрос - а как мне в dmesg вякнуть? А то в лог не попишешь,
>> подмонтирован только корень и тот read only.
>
> hello.c:
>
> #include 
> #include 

Стоп, это модуль для ядра? А то у меня-то userland процесс, пусть и
"вместо init". Не хочу в ядерный контекст, без него страшно. Но
оставить след хоть в каких-то логах (не dmesg так ещё что-нибудь)
хотелось бы.



-- 
Yours, Mikhail Ramendik

Unless explicitly stated, all opinions in my mail are my own and do
not reflect the views of any organization

Re: Динамически включать-выключать CPU

On Sat, Sep 10, 2011 at 01:32:24AM +0100, Mikhail Ramendik wrote:
> 
> А теперь вопрос - как бы мне выяснить, что это у меня за 20 задач,
> которые не переносятся? Проверил у нескольких /proc/$pid/cmdline -
> пусто. Но там и у kswapd0 пусто, а top как-то знает, что это именно
> он. Как мне-то узнать? Гугль не помог :( Особенно это будет важно,
> если выяснится что весь этот хак не работает, а isolcpus работает.

Это процессы в контексте ядра. Типично у них используемая память равна 0

> 
> И ещё вопрос - а как мне в dmesg вякнуть? А то в лог не попишешь,
> подмонтирован только корень и тот read only.

hello.c:

#include 
#include 

int init_module(void)
{
printk(KERN_INFO "Hello world\n");
return 0;
}

void cleanup_module(void)
{
printk(KERN_INFO "Goodbye world\n");

}

Makefile:

obj-m += hello.o

all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules



-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110910005307.gb6...@nano.ioffe.rssi.ru

Re: Динамически включать-выключать CPU

2011-09-09 Пенетрантность Andrey Rahmatullin

2011/9/9 Victor Wagner :

>> На шелле то, что я хочу, пишется без проблем. Вот оно:
> Последняя строчка должна быть exec /sbin/init
> Чтобы процесс не форкался, а замещал шелл инитом.

Ага. И ещё потребовалось echo 0 >/dev/cpuset/syscpuset/mems . После
этого оно заработало. Но куча задач осталась неперекинутой, поскольку
запускаются помимо init (включая kswapd0, в котором у меня oops'ы
были).

Я обнаружил, что лишнее перекинуть просто нельзя - на некоторые задачи
echo $pid >/dev/cpuset/syscpuset/tasks даёт write error. Но поскольку
перекидывать надо по одной строке, я не смог сделать это на шелле.
Сейчас у меня работает такое решение:

в ядре init=/sbin/cpuset-hack

файл /sbin/cpuset-hack , permissions 744 чтобы случайно не запустить:

#!/bin/sh
/bin/mkdir /dev/cpuset
/bin/mount -t cpuset - /dev/cpuset
/bin/mkdir /dev/cpuset/syscpuset
echo 0 >/dev/cpuset/syscpuset/cpus
echo 0 >/dev/cpuset/syscpuset/mems
echo $$ >/dev/cpuset/syscpuset/tasks
/sbin/cpuset-hack-python.py
exec /sbin/init

файл /sbin/cpuset-hack-python.py , permissions 744 по той же причине:

#!/usr/bin/python
f=open("/dev/cpuset/tasks")
tasks=f.readlines()
f.close()

for task in tasks:
try:
f=open("/dev/cpuset/syscpuset/tasks","w")
f.write(task)
f.close()
except IOError:
pass

Я конечно вижу, что это грязно, в общем случае на /usr нельзя
рассчитывать и надо на Си писать, но влом. Или этот же эффект как-то
достигается на shell+busybox?

И запуск mplayer нашёлся способ сделать (чуть хитрее чем я тут писал -
сначала отдать PID шелла в /dev/cpuset/tasks через sudo-скрипт, а
потом запустить из этого шелла mplayer).

А теперь вопрос - как бы мне выяснить, что это у меня за 20 задач,
которые не переносятся? Проверил у нескольких /proc/$pid/cmdline -
пусто. Но там и у kswapd0 пусто, а top как-то знает, что это именно
он. Как мне-то узнать? Гугль не помог :( Особенно это будет важно,
если выяснится что весь этот хак не работает, а isolcpus работает.

И ещё вопрос - а как мне в dmesg вякнуть? А то в лог не попишешь,
подмонтирован только корень и тот read only.

--
Yours, Mikhail Ramendik

Unless explicitly stated, all opinions in my mail are my own and do
not reflect the views of any organization

udisks и права на монтирование\

2011-09-09 Пенетрантность 375gnu


Предистория. Нет у меня новомодных ДЕ, а вот юсб-флешки есть, и стало мне
лениво всякий раз в терминале писать pmount /dev/то-что-надо, захотел
автоматически. 

Apt-cache рассказал о таком звере, как udisks-glue. Поставил, настроил и
возрадовался, ибо всё работало как надо, и, в отличие от pmount, можно задавать
опции для mount.

Но прошло пару дней, и огорчился я зело, ибо перестала шайтан-программа
работать, непозволено, говорит мне такими делами заниматься. Вот, например:

$ udisks-glue -sf
Running within session context: /org/freedesktop/ConsoleKit/Session1
Device file /dev/sdc inserted
Device file /dev/sdc1 inserted
Trying to automount /dev/sdc1...
Failed to automount /dev/sdc1: Not Authorized

Ключик -s на ситуацию не влияет.

Посмотрел я мудрость волхвов из udisks-doc, policykit-1-doc и наваял такой вот
файлик (/etc/polkit-1/localauthority.conf.d/99-udisks.conf):

[Configuration]
Identity=unix-group:plugdev
Action=org.freedesktop.udisks.filesystem-mount
ResultAny=no
ResultInactive=no
ResultActive=yes


Но ничего не поменялось.

Поможите, люди добрые, шайтана новомодного одужать!

-- 
 http://375gnu.wordpress.com


-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110909193201.GA22594@deneb

Re: Апдейт предлагает удалить гном О_о

On Fri, Sep 09, 2011 at 09:35:35PM +0300, Lord wrote:
> >>такая вот беда
> >>http://paste.org.ru/?9sk9c2
> >>это я туплю или что-то не так? :)
> >>буду благодарен за адекватность и помощь
> >apt-cache policy
> http://paste.org.ru/?8vwbwg
зачем стейбл и сид одновременно?

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Помогите настроить GRUB2!

2011-09-09 Пенетрантность Andrey Rahmatullin

On Wed, Sep 07, 2011 at 03:24:19AM +0300, Paul Carroty wrote:
> >  aptitude install os-prober && update-grub
> # update-grub2
Нет, всё верно.

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Re: Апдейт предлагает удалить гном О_о

2011-09-09 Пенетрантность Paul Carroty

Fri, 09 Sep 2011 20:25:22 +0300
Тоха  написав:

> такая вот беда
> http://paste.org.ru/?9sk9c2
> это я туплю или что-то не так? :)
> буду благодарен за адекватность и помощь
> 
> 

Сегодня сломали зависимости upower в sid`е, может и не только в нем.


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110907033308.75097...@debian.beeline.ua

Re: Апдейт предлагает удалить гном О_о

2011-09-09 Пенетрантность Lord


09/09/2011 10:09 PM, Sergei Golovan пишет:

2011/9/9 Тоха:

такая вот беда
http://paste.org.ru/?9sk9c2
это я туплю или что-то не так? :)
буду благодарен за адекватность и помощь

Новая версия пакета upower не ставится (зависимости сломаны, см.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641015). apt-get
отказался обновлять, aptitude изо всех сил пытается удовлетворить твое
пожелание (об апгрейде). Но после обновления upower появляются
неразрешенная жесткая зависимость. Вот и приходится сносить пакеты до
тех пор, пока зависимости не удовлетворятся.

В багтрекер хорошо бы заглядывать до того, как спрашивать у кого попало...

Cheers!

Спасибо большое.
На багтрекер не глядел, ибо таких проблем еще не было, познаний в этой 
области нет.

Вот будет теперь экспирианс :)


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e6a665b.3060...@gmail.com

Re: Помогите настроить GRUB2!

2011-09-09 Пенетрантность Paul Carroty

Mon, 5 Sep 2011 15:32:33 +0600
Sergey Korobitsin  написав:

> ultra.rapid ☫ → To debian-russian@lists.debian.org @ Mon, Sep 05,
> 2011 13:06 +0400
> 
> > Совершенно непонятная ерунда! Когда устанавливал Debian 6.0.2, то в
> > конце установки, как обычно, появилось сообщение с вопросом о том,
> > куда нужно установить загрузчик системы. Было написано, что на
> > компьютере была найдена еще одна система - Windows. "Если это все
> > системы, установленные на компьютере, можете смело устанавливать
> > загрузчик в MBR. При загрузке сможете выбрать нужную операционную
> > систему". Что я и сделал.
> > Вот только одна проблема.. :) При загрузке теперь кроме Debian
> > ничего нет. В Debian 6.0.2 нет файла /boot/grub/menu.list, который
> > я собрался уже редактировать. Винда стоит на /dev/sda1. 
> > Как добавить её в загрузку???
> 
> Как-то так:
> 
>  aptitude install os-prober && update-grub
> 

# update-grub2


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110907032419.7a393...@debian.beeline.ua

Re: Апдейт предлагает удалить гном О_о

2011-09-09 Пенетрантность Sergei Golovan

2011/9/9 Тоха :
> такая вот беда
> http://paste.org.ru/?9sk9c2
> это я туплю или что-то не так? :)
> буду благодарен за адекватность и помощь

Новая версия пакета upower не ставится (зависимости сломаны, см.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641015). apt-get
отказался обновлять, aptitude изо всех сил пытается удовлетворить твое
пожелание (об апгрейде). Но после обновления upower появляются
неразрешенная жесткая зависимость. Вот и приходится сносить пакеты до
тех пор, пока зависимости не удовлетворятся.

В багтрекер хорошо бы заглядывать до того, как спрашивать у кого попало...

Cheers!
-- 
Sergei Golovan

Re: Апдейт предлагает удалить гном О_о

2011-09-09 Пенетрантность Lord


09/09/2011 09:12 PM, Andrey Rahmatullin пишет:

On Fri, Sep 09, 2011 at 08:25:22PM +0300, Тоха wrote:

такая вот беда
http://paste.org.ru/?9sk9c2
это я туплю или что-то не так? :)
буду благодарен за адекватность и помощь

apt-cache policy


http://paste.org.ru/?8vwbwg
или нужно было посмотреть какой-то пакет конкретно ?


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e6a5c77.40...@gmail.com

Re: Апдейт предлагает удалить гном О_о

2011-09-09 Пенетрантность Andrey Rahmatullin

On Fri, Sep 09, 2011 at 08:25:22PM +0300, Тоха wrote:
> такая вот беда
> http://paste.org.ru/?9sk9c2
> это я туплю или что-то не так? :)
> буду благодарен за адекватность и помощь
apt-cache policy

-- 
WBR, wRAR


signature.asc
Description: Digital signature

Апдейт предлагает удалить гном О_о

2011-09-09 Пенетрантность Тоха


такая вот беда
http://paste.org.ru/?9sk9c2
это я туплю или что-то не так? :)
буду благодарен за адекватность и помощь


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e6a4c02.9010...@ukr.net

Re: openvpn и replay

2011-09-09 Пенетрантность Ed

On 09/09/11 17:00, Victor Wagner wrote:

On 2011.09.09 at 16:05:13 +0400, Ed wrote:

как я понимаю, клиентский openvpn был перезапущен, поэтому он заново
послал пакет с #1, чего сервер испугался "replay наверное".

Абсолютно неверное представление. OpenVPN достаточно хитрая софтина,
чтобы для идентификаторов пакетов использовать нечто отличное от
простого порядкового номера.

Скорее всего действительно прилетает дубль пакета. Из-за каких-нибудь
сетевых проблем. Или пакеты по дороге перепутываются и приходят не в том
порядке (что вполне нормально. Ненормально то, что за заданное по
умолчанию количество пакетов и секунд не удается собрать правильную
цепочку).

такое объяснение первым приходит в голову, но нет же - проверил логи,
проблемы начинаются с #1.

сейчас заметил такую приписку в man:
In Static Key mode or when using an CFB or OFB mode cipher, OpenVPN uses
a 64 bit unique identifier that combines a time stamp with an
incrementing sequence number.

у меня как раз static key mode.

возможно что-то с таймштампом на виндовых клиентах? (такое ощущение, что
проблемы только с ними)

например служба перезапскается два раза за одну секунду.

--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e6a1221.5060...@yandex.ru

Re: openvpn и replay

On 2011.09.09 at 16:05:13 +0400, Ed wrote:

> стоит у меня openvpn сервер и периодически в логах появляются
> подобные сообщения:
> 
>  Authenticate/Decrypt packet error: bad packet ID (may be a replay):
> [ #1 / time = (1315567947) Fri Sep  9 15:32:27 2011 ] -- see the man
> page entry for --no-replay and --replay-window for more info or
> silence this warning with --mute-replay-warnings
> 
> (дальше идут такие же предупреждения с #2, #3, ...)
> 
> при этом клиент "отваливается".
> перезапуск сервера решает проблему.
> 
> 
> вопрос: что происходит и как бороться?

В сообщении написано "прочитайте раздел  man-страницы про опции
--no-replay и --replay-window.

> 
> как я понимаю, клиентский openvpn был перезапущен, поэтому он заново
> послал пакет с #1, чего сервер испугался "replay наверное".

Абсолютно неверное представление. OpenVPN достаточно хитрая софтина,
чтобы для идентификаторов пакетов использовать нечто отличное от
простого порядкового номера.

Скорее всего действительно прилетает дубль пакета. Из-за каких-нибудь
сетевых проблем. Или пакеты по дороге перепутываются и приходят не в том
порядке (что вполне нормально. Ненормально то, что за заданное по
умолчанию количество пакетов и секунд не удается собрать правильную
цепочку).

Если игры с --replay-window не приведут к успеху, можно
попробовать использовать openvpn в tcp-режиме вместо udp. Тогда
сборкой пакетов в правильной последовательности будет заниматься ядро, а
не openvpn. Но это приведет к потерям производительности.

Впрочем, лучше работающий медленно, чем зависающий канал.

-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110909130033.gb12...@wagner.pp.ru

Re: Динамически включать-выключать CPU

On 2011.09.09 at 13:37:30 +0100, Mikhail Ramendik wrote:

> 2011/9/9 Victor Wagner :
> 
> > Я вообще на своих X-терминалах shell-овский скрипт в качестве init
> > использую. Прекрасно работаает.
> 
> Хочу подробностей. ОЧЕНЬ хочу.

Нет никаких подробностей. Просто работает.

> На шелле то, что я хочу, пишется без проблем. Вот оно:
> 
> #!/bin/sh
> /bin/mkdir /dev/cpuset
> /bin/mount -t cpuset - /dev/cpuset
> /bin/mkdir /dev/cpuset/syscpuset
> /bin/echo 0 >/dev/cpuset/syscpuset/cpus
> /bin/echo $$ >/dev/cpuset/syscpuset/tasks
> /sbin/init

Последняя строчка должна быть exec /sbin/init
Чтобы процесс не форкался, а замещал шелл инитом.

> Специально указал полные пути, исходя из того, что у нас ещё нет $HOME
> и поэтому шелл не инициализируется вообще никак.

Оно от рута работает. А /root у нас уже есть. И /etc уже есть.
А вообще можно в начале скрипта написать PATH=/bin:/sbin

Далее, /bin/echo ты используешь зря. В большинстве шеллов есть
встроенная команда echo. 

> Но. Как в параметре ядра init указать нечто с параметрами?
> "init=/bin/sh /bin/cpuset-hack", что ли?

Да не нужно тебе /bin/sh. Просто объяви cpuset-hack исполняемым.

#!/bin/sh 

отрабатывается ядром, и оно вполне справится с поиском интерпретатора и
в данном случае.

И лучше все-таки эту штуку держать не в /bin, а в /sbin

-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110909125318.ga12...@wagner.pp.ru

Re: Динамически включать-выключать CPU

2011/9/9 Victor Wagner :

> Я вообще на своих X-терминалах shell-овский скрипт в качестве init
> использую. Прекрасно работаает.

Хочу подробностей. ОЧЕНЬ хочу.

На шелле то, что я хочу, пишется без проблем. Вот оно:

#!/bin/sh
/bin/mkdir /dev/cpuset
/bin/mount -t cpuset - /dev/cpuset
/bin/mkdir /dev/cpuset/syscpuset
/bin/echo 0 >/dev/cpuset/syscpuset/cpus
/bin/echo $$ >/dev/cpuset/syscpuset/tasks
/sbin/init

Специально указал полные пути, исходя из того, что у нас ещё нет $HOME
и поэтому шелл не инициализируется вообще никак.

Но. Как в параметре ядра init указать нечто с параметрами?
"init=/bin/sh /bin/cpuset-hack", что ли?

Запуск mplayer после этого я, если я правильно понял, сделаю просто...

#!/bin/sh
rxvt -e mplayer -lavdopts=2 ... &
sudo echo `pidof mplayer` > /dev/cpuset/tasks

(Ну, реально ради безопасности вторая строка будет запуском отдельного
скрипта, чтобы именно его прописать в SUDOERS, но это уже не к той
теме).

--
Yours, Mikhail Ramendik

Unless explicitly stated, all opinions in my mail are my own and do
not reflect the views of any organization

Re: Есть ли в Linux/Debian генераторы сканов российских паспортов?

2011-09-09 Пенетрантность Ed


On 09/06/11 14:05, Anton Kovalenko wrote:

..Кроме того, есть идея заняться софтиной, чтобы отличала фальшивые
сканы от настоящих.


любопытно - как?


--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e6a05b1.3010...@yandex.ru

openvpn и replay

2011-09-09 Пенетрантность Ed

стоит у меня openvpn сервер и периодически в логах появляются подобные 
сообщения:


 Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ 
#1 / time = (1315567947) Fri Sep  9 15:32:27 2011 ] -- see the man page 
entry for --no-replay and --replay-window for more info or silence this 
warning with --mute-replay-warnings


(дальше идут такие же предупреждения с #2, #3, ...)

при этом клиент "отваливается".
перезапуск сервера решает проблему.


вопрос: что происходит и как бороться?

как я понимаю, клиентский openvpn был перезапущен, поэтому он заново 
послал пакет с #1, чего сервер испугался "replay наверное".


но при этом перезапуск клиента в общем-то штатная ситуация и обычно не 
приносит проблем. специально воспроизвести проблему не получается.



--
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e6a00f9.3020...@yandex.ru

Re: Динамически включать-выключать CPU

On 2011.09.09 at 11:17:08 +0100, Mikhail Ramendik wrote:

> > PID init'а равен 1.
> 
> создавать cpuset и запихивать в него настоящий init. Но я уже понял,
> что ей достаточно сначала запихнуть в этот cpuset себя, а потом -
> вызывать init. Для запмуска самой штуки используется параметр ядра
> init=...

Ага - вызвать init посредством exec, заместив им себя в текущем
процессе.

> 
> Но я категорически не представляю себе, что можно, а что нельзя
> делать, будучи на месте init. Главный вопрос - у меня есть libc6 или у

Все что угодно.

> меня её нет? Если есть - то эта штука собирается более-менее обычно и

Сделай ldd /sbin/init

> работает более-менее обычно.

Я вообще на своих X-терминалах shell-овский скрипт в качестве init
использую. Прекрасно работаает. А все потому что мне лень было busybox
пересобирать, а в той версии debian-а на которой я терминал собирал, 
в busybox init не собрали (хотя вообще-то он там есть).

-- 
To UNSUBSCRIBE, email to debian-russian-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110909111740.ga10...@wagner.pp.ru

Re: Динамически включать-выключать CPU