Страниц: [1]
  Печать  
Автор Тема: Разработчику: Утилита on  (Прочитано 17131 раз)
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« : Ноября 01, 2002, 07:04:00 pm »

Автор Дмитрий Алексеев [dmi]. Статья с неброским названием, но посвящена и детально описывает уникальную возможность QNX, отсутствующую в любых других OS - запуск задачи на удалённом узле сети (конечно, нечто подобное можно сделать и в Linux, и в Windows, но ... с гораздо большим трудом, и "через задницу").

Возможности удалённого запуска задач - это открытый путь к коллегиальному использованию ресурсов процессоров в сети, т.е. построению многомашинных комплексов, кластеров и т.д.

Чем ещё хороша статья? Тем что параллельно с возможностями, осуществляемыми из командного языка (утилита on), рассматриваются её аналоги из API. Чем хотите - тем и пользуйтесь!

Что ещё актуально? То, что во всех редакциях QNX 6.X до сих пор (6.0, 6.1), команда on работала "горбато", т.е. скорее не работала, чем работала. Поэтому информация эта - очень новая, свежая (в HELP о возможностях on сказано очень "куцо", да и что можно сказать об "неработающей" команде - HELP то писался не вчера ). Я нигде больше не встречал (кроме этой статьи) обстоятельного описания on.

Очень хорошая статья!

P.S. Ссылки на статью в .html & .pdf форматах:
http://qnx.org.ru/docs-devel/on.html
http://ftp://ftp.qnx.org.ru/pub/articles/on.pdf


[ Это Сообщение было отредактировано: Olej в 2002-11-01 16:10 ]
Записан
zeus
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #1 : Ноября 05, 2002, 10:29:00 am »


Olej пишет:
Автор Дмитрий Алексеев [dmi]. Статья с неброским названием,...
...

Очень хорошая статья!


Ухх.
Только зачем писать скрипт на перле для вызова шелла для вызова on??


#!/usr/bin/perl

opendir(DIR, "/net") || die "No qnet running
";
while(defined($node=readdir(DIR))) {
   system( "on -f $node chkfsys /" );
}


Не лучше ли будет что-то типа такого:

#!/bin/sh
if test -r /net/*; then for Node in /net/*; do on -f `basename $Node` chkfsys /; done; fi



Записан
Landy
Jr. Member
**
Offline Offline

Сообщений: 65


Просмотр профиля WWW
« Ответ #2 : Ноября 05, 2002, 11:20:00 am »


zeus пишет:

Olej пишет:
Автор Дмитрий Алексеев [dmi]. Статья с неброским названием,...
...

Очень хорошая статья!


Ухх.
Только зачем писать скрипт на перле для вызова шелла для вызова on??


#!/usr/bin/perl

opendir(DIR, "/net") || die "No qnet runningn";
while(defined($node=readdir(DIR))) {
   system( "on -f $node chkfsys /" );
}


Не лучше ли будет что-то типа такого:

#!/bin/sh
if test -r /net/*; then for Node in /net/*; do on -f `basename $Node` chkfsys /; done; fi





Писать можно на чем угодно - это же статья, для иллюстрации и чтобы понятнее было
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #3 : Ноября 05, 2002, 03:26:00 pm »


Landy пишет:
Писать можно на чем угодно - это же статья, для иллюстрации и чтобы понятнее было

Писать можно на чём угодно, даже если это не статья, а реальная боевая "программа", пусть даже самого критического предназначения - критерием и целью любого написанного (программы) является только то, что оно работает так, как предусмотрено спецификациями. Всё остальное - от лукавого... Но об этом в другой раз.

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

- там ближе к концу есть фраза: "Дескриптор локального узла определяется макросом ND_NODE_LOCAL...". Я как раз с этим работал и "подсел":

1.не ND_NODE_LOCAL, а - ND_LOCAL_NODE;
2.ND_LOCAL_NODE - не макрос, а константа.

Мне подумалось, что правильнее всего замеченные опечатки описывать именно здесь, в разделе "Статьи":
- кто-то, работая с имеющимся текстом, не "напорется" вновь на это место;
- ещё более полезно - автору, который исправит недоделки в следующей редакции, что сделает текст лучше.

P.S.Именно в этой связи, я просил бы по моим текстам (а их там есть в некотором колличестве) вписывать замечания и пожелания именно в темы, описывающие статьи (мне, по крайней мере, это удобнее, чем по мэйлу).

P.P.S.

zeus пишет:
Не лучше ли будет что-то типа такого:
#!/bin/sh
if test -r /net/*; then for Node in /net/*; do on -f `basename $Node` chkfsys /; done; fi

Вполне может быть, что и лучше . Но, в связи именно с этой фразой я хотел бы напомнить об другом:

- Мы находимся в разделе обсуждения конкретной статьи. И, если вы предлагаете улучшение текста, то должны понимать, что автор этой статьи может свободно использовать предложенные в обсуждении изменения (если сочтёт нужным) не ссылаясь на происхождения изменений. Это - чтоб сразу и наперёд избежать в будущем кривотолков типа "я вот такой умный ... , а он меня не любит" .


[ Это Сообщение было отредактировано: Olej в 2002-11-05 12:35 ]
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 470



Просмотр профиля
« Ответ #4 : Ноября 05, 2002, 05:13:00 pm »


zeus пишет:
Ухх.
Только зачем писать скрипт на перле для вызова шелла для вызова on??
Не лучше ли будет что-то типа такого:

#!/bin/sh
if test -r /net/*; then for Node in /net/*; do on -f `basename $Node` chkfsys /; done; fi




Ага, спасибо.
Однако я просто приводил пример, и на перле он только потому, что два дня перед этим я ковырял перловые скрипты.
Впрочем, примеры просто должны быть наглядными. Для меня скрипт на perl выглядит куда более наглядным, чем на shell.
Сразу хочется сказать, что тексты из статьи напрямую использвать не стоит.
Их надо перерабатывать, причем серьезно, под каждую конкретную ситуацию.
В примере с setuid/setgid - установка gid вообще делается некорректно (надо использовать initgroups(), а уже потом setgid(). Ну и т.д.
В какой-то мере это даже не статья, а небольшой набросок на тему "как это делается".
Записан
zeus
Участник
*
Offline Offline

Сообщений: 0


Просмотр профиля
« Ответ #5 : Ноября 05, 2002, 05:57:00 pm »


Olej пишет:
Писать можно на чём угодно, даже если это не статья, а реальная боевая "программа", пусть даже самого критического предназначения - критерием и целью любого написанного (программы) является только то, что оно работает так, как предусмотрено спецификациями. Всё остальное - от лукавого... Но об этом в другой раз.

При критическом исполнении дополнительные расходы на перл (время и память) нежелательны...


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

- там ближе к концу есть фраза: "Дескриптор локального узла определяется макросом ND_NODE_LOCAL...". Я как раз с этим работал и "подсел":

1.не ND_NODE_LOCAL, а - ND_LOCAL_NODE;
2.ND_LOCAL_NODE - не макрос, а константа.

Мне подумалось, что правильнее всего замеченные опечатки описывать именно здесь, в разделе "Статьи":
- кто-то, работая с имеющимся текстом, не "напорется" вновь на это место;
- ещё более полезно - автору, который исправит недоделки в следующей редакции, что сделает текст лучше.
**1

P.S.Именно в этой связи, я просил бы по моим текстам (а их там есть в некотором колличестве) вписывать замечания и пожелания именно в темы, описывающие статьи (мне, по крайней мере, это удобнее, чем по мэйлу).

P.P.S.
...
Вполне может быть, что и лучше . Но, в связи именно с этой фразой я хотел бы напомнить об другом:

- Мы находимся в разделе обсуждения конкретной статьи. И, если вы предлагаете улучшение текста, то должны понимать, что автор этой статьи может свободно использовать предложенные в обсуждении изменения (если сочтёт нужным) не ссылаясь на происхождения изменений. Это - чтоб сразу и наперёд избежать в будущем кривотолков типа "я вот такой умный ... , а он меня не любит" .

Авторство того или иного замечания/дополнения не столь уж для меня и важны, тем более, что см. **1 Ведь именно для это и указываю - в критичных местах тратиься еще и на перл, пхп,... расточительно

// Будем проще!
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #6 : Ноября 05, 2002, 06:35:00 pm »


zeus пишет:
Авторство того или иного замечания/дополнения не столь уж для меня и важны, тем более, что см. **1 Ведь именно для это и указываю - в критичных местах тратиься еще и на перл, пхп,... расточительно
// Будем проще!

Это и было сказано - для простоты, если уж совсем строго, то как-то должны были бы отмечаться позже те, чьи замечания были учтены при редактурах. Но если следовать таким строгостям, то работа по "вычистке" материала на сайте очень замедляется. А на нём ещё ... ох как много нужно бы было сделать!

Но все детали "взаимного сосуществования" - всегда должны быть заранее оговорены!
Записан
Evgeniy
Jr. Member
**
Offline Offline

Сообщений: 73


Просмотр профиля
« Ответ #7 : Ноября 05, 2002, 09:12:00 pm »


zeus пишет:

Olej пишет:
...........
...........
...........

При критическом исполнении дополнительные расходы на перл (время и память) нежелательны...


При критическом исполнении не стоит связываться и с shell тоже...
А при запуске системы возможно что и без разницы

[ Это Сообщение было отредактировано: Evgeniy в 2002-11-05 18:13 ]
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #8 : Ноября 05, 2002, 09:58:00 pm »


zeus пишет:
При критическом исполнении дополнительные расходы на перл (время и память) нежелательны...


Evgeniy пишет:
При критическом исполнении не стоит связываться и с shell тоже...
А при запуске системы возможно что и без разницы

Это вполне могло бы быть предметом обмена мнениями ("могут быть варианты"), но только же, естественно, не здесь. Где-нибудь в http://qnx.org.ru/forum/viewforum.php?forum=10&261
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #9 : Ноября 05, 2002, 10:14:00 pm »

А здесь - у меня есть головоломка, по-случаю, для dmi:

- есть у меня ресурс менеджер, назовём его agent (т.е., пусть тебя не смущает РМ - это не чисто РМ, который никогда не завершается, а такой fork-ающий процесс, который запускает РМ, регистрирующий имя /dev/agent, а сам благополучно завершается);
- и есть QNET сетка, скажем для простоты, из 2-х узлов: rtp - локальный (т.е. на нём я это буду делать), и lynx - удалённый (их, естественно, узлов может быть сколь угодно, и в такой ситуации я и проверял что описываю, но на них полностью воспроизводится ситуация lynx);
- естественно /net имеет вид: rtp lynx ...

Теперь я на rtp делаю для всех узлов (находясь в дирректории, где agent):
on -frtp agent
on -flynx agent
....
(или что то-же самое - spawn в цикле по всем хостам в /net). Смотрим - на lynx (и всех других хостах сетки кроме rtp) присутствует /dev/agent, на всех, кроме локального!

Сделаем то-же самое (slay-ив предварительно везде /dev/agent), но:
on -nrtp agent
on -nlynx agent
....
ОК, на rtp - /dev/agent, но ... только на нём одном!

Мистификасьён! Что-то с тасовкой рабочих дирректорий...
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 470



Просмотр профиля
« Ответ #10 : Ноября 06, 2002, 02:59:00 pm »


Olej пишет:
Мистификасьён! Что-то с тасовкой рабочих дирректорий...


Смотри статью, последние абзацы, про chroot().
При аттаче имени ресурса берется текущий корневой каталог, к нему добавляется префикс.
Так что это не головоломка, это даже не интересно
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 470



Просмотр профиля
« Ответ #11 : Ноября 06, 2002, 03:01:00 pm »


zeus пишет:

При критическом исполнении дополнительные расходы на перл (время и память) нежелательны...


Пример в статье - не есть критическое исполнение
Зато пример на Perl для меня на порядок нагляднее, чем паример на shell.
Кажется, уже повторяюсь...
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #12 : Ноября 08, 2002, 02:56:00 pm »


dmi пишет:
Смотри статью, последние абзацы, про chroot().
При аттаче имени ресурса берется текущий корневой каталог, к нему добавляется префикс.

dmi, и прочие кого это может заинтересовать, смотрел, пробовал... Там всё совсем не так очевидно. Если мы РМ попробуем запустить на локальном хосте (как одном из сетевых), средствами команда on, то команда on, независимо от того, выполним ли мы её в локальном или корневом каталоге:
/root/CaServ # on -frtp agent
или
cd /
/ # on -frtp /root/CaServ/agent
- завершится вроде как "нормально", но регистрируемый РМ префикс пути - не появится!

Сделаем:
/root/CaServ # on -nrtp agent
- всё ОК!

Интересно проделать то-же с простейшей консольной программой типа "Hello word", у меня не было "Hello word" под рукой, но была рабочая консольная программка ... выполняется, вывод ОК.

Похоже, что наблюдаемый эффект: запуск приложения on -f... на локальном хосте как на сетевом - это из области артефактов поведения on ... ?

Но совсем меня озадачил shell-скриптик cd0-2 (это фрагмент работы, поэтому на SYSOUT не обращайте внимания), это даже не скрипт, а командная строка:

/root/QNET/Cluster # cd0-2
key = <31,32>
key = <31,32>

/root/QNET/Cluster # on -frtp cd0-2
on: Exec format error (cd0-2)

/ # on -frtp /root/QNET/Cluster/cd0-2
on: Exec format error (/root/QNET/Cluster/cd0-2)

Huh? ... т.е. on пытается запускать скрипт не средствами стандартного shell, работающего в системе (он то распознаёт и запускает), а своими собственными!

Добавляю в заголовок скрипта cd0-2 строчку:
#!/bin/ksh

...
/root/QNET/Cluster # on -frtp cd0-2
key = <31,32>
key = <31,32>

т.е. on - не знает в системе shell по умолчанию?
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 470



Просмотр профиля
« Ответ #13 : Ноября 08, 2002, 07:03:00 pm »


Olej пишет:

dmi, и прочие кого это может заинтересовать, смотрел, пробовал... Там всё совсем не так очевидно. Если мы РМ попробуем запустить на локальном хосте (как одном из сетевых), средствами команда on, то команда on, независимо от того, выполним ли мы её в локальном или корневом каталоге:
/root/CaServ # on -frtp agent
или
cd /
/ # on -frtp /root/CaServ/agent
- завершится вроде как "нормально", но регистрируемый РМ префикс пути - не появится!

Т.е. ошибка монтирования в /net/localhost/dev ? Интересно... Возможно, это ошибка. Я попробую позже.


Сделаем:
/root/CaServ # on -nrtp agent
- всё ОК!


Конечно все ОК!! Ведь chroot() не делает, следовательно программа отрабатывает на локальном узле.


Похоже, что наблюдаемый эффект: запуск приложения on -f... на локальном хосте как на сетевом - это из области артефактов поведения on ... ?

Скорее всего он просто не расчитан на такое применение.
А может ветка с ND_NODE_CMP работает неверно, делается spawn() вместо exec(), т.е. процесс при старте получает неверное окружение (терминал, группу,  и т.д.).


т.е. on - не знает в системе shell по умолчанию?

Такого понятик, как "shell по умолчанию" не существует. пользователь всегда должен указывать интрерпретатор для исполняемого файла, если это не ELF.
То, что это выполняется локально - скорее поблажка, но никак не стандартное поведение.
Записан
Страниц: [1]
  Печать  
 
Перейти в: