tcsh# ls -Al | more

dixx @ 2006-04-29T03:26:00

2006-04-28T23:26:47Z

Давеча titov скинул линк с утверждением Торвальдса о том, что copy-on-write при fork()'ах- это плохо. В частности потому, что игры тормозят. Ну мудак, подумал я, и вроде забыл.

А тут вот какая мысль пришла. Copy-on-write не просто резко облегчает fork() как единственный способ создания нового процесса в UNIX (в особенности с учётом того, что чаще всего после fork'а дочерний процесс выполняет совсем другой код и часть кода/данных родительского процесса оказывается невостребованной), таки его отсутствие категоричестки утяжеляет exec() и, как следствие, например, может сильно замедлять шелл. Так, при вызове /bin/ls из bash придётся скопировать при fork'е весь большой bash вместо небольшого куска кода, отвечающего за запуск маленького ls. Расходы на загрузку и запуск самого ls, понятно, сохраняются в обоих случаях.

Single UNIX Specification

2006-04-23T12:31:20Z

Полезная ссылка. Читать и вкуривать до просветления
The Open Group Base Specification Issue 6 (IEEE Std 1003.1, 2004 Edition) - Single UNIX Specification

Вывод ошибок и сопутствующей информации

2006-04-23T01:33:25Z

Никогда не выводите ошибки в stdout! Для этого есть stderr. Если вам необходимо это сделать в шелле, то проще всего сказать echo "an error occured" 1>&2.

Причина тому достаточно проста и кроется в группе стандартных утилит, именуемых в Single UNIX Specification фильтрами. К их числу относятся grep, sed, awk, sort и т.п. Если ваша программа вернёт пустой вывод, то последующие фильтры будут работать предсказуемо - они тоже ничего не вернут. А вот если вы захерачите ошибки в stdout - то результат работы фильтров будет произвольным.

Кроме того, существует добрая традиция информацию об использовании программы (номер версии, список ключей и т.д., т.е. то, что обычно получается по ключам -h/-v) также запихивать в stderr. По тем же причинам (например, если существует несколько вариантов реализации утилиты, то на неправильный ключик в командной строке она вполне может ругнуться кратким списком ключиков).

Теперь непосредственно о том, как правильно выводить ошибки, не изобретая велосипед.

Во-первых, существует функция perror() (определена в <stdio.h>. Выводит как положено (имя процесса: сообщение: текстовый вариант errno). Неудобна тем, что не понимает printf()-like аргументов и всегда выводит текстовый вариант errno, даже когда это не нужно.

Во-вторых, существует целая группа функций, определённых в <err.h>, состоящая из err(), verr(), errx(), verrx() и аналогичных вариантов warn(). Выводят тоже в стандартном формате. Варианты с префиксом v принимают va_list вместо списка аргументов, с постфиксом x - не выводят текстовый вариант errno. Группа функций [v]err[x]() при этом не возвращает управление назад, а внутри себя вызывает exit() с переданным ей кодом завершения, что на мой взгляд не совсем правильно - я предпочитаю полноценную корректную финализацию.

Исходя из удобства, наиболее полезными можно считать [v]warn[x]().

В-третьих, есть ручной вариант, если хочется собственного формата (что есть зло - не изобретайте велосипед, ибо наверняка предыдущие изобретатели, принимая во внимание то, сколько API UNIX прожило, учитывали кучу факторов, о которых вы можете не догадываться). Заключается в определении функции или макроса, которые дёргают fprintf(stderr).

Для получения имени процесса в таком варианте можно воспользоваться классикой (basename(argv[0]), либо специфичным для ОС функциями (getprogname() в BSD). Так как все они возвращают указатель на статический буфер, лучше сразу сделать от их результата strdup().

Также следует учитывать, что если вы пишете демона и он уже освободил управляющий терминал или просто fork()'анулся - не надо на оный терминал кидать ошибки. Ничего хорошего из этого не выйдет. В лучшем случае вы огребёте некрасивый вывод, в худшем - SIGPIPE. Есть более правильный, удобный, универсальный и быстрый (да-да) стандартный способ - syslog. Заодно он избавляет вас в большинстве случаев от написания собственного вывода в логи.

Пример:

#include <sys/types.h>
#include <syslog.h>
#include <string.h>
#include <stdlib.h>
#include <libgen.h>

int
main(int argc, char *argv[])
{
  pid_t pid;

  pid = fork();
  if (pid < 0)
    err(EXIT_FAILURE, "fork() failed");
  if (pid > 0)
    return EXIT_SUCCESS;

  openlog(basename(argv[0]), LOG_CONS | LOG_NDELAY, LOG_DAEMON);

  if (myfunc() < 0)
    syslog(LOG_ERR, "myfunc() failed: %s", strerror(errno));

  return EXIT_SUCCESS;
}

И в данном случае сделать удобный макрос для дописывания strerror(errno) последним аргументом в вызов syslog() сам бог велел. А ещё есть vsyslog(), который, понятно из названия, принимает va_list.

PID-файлы

2006-04-22T22:47:34Z

Актуальность темы подтвердил сегодня titov. Так вот, PID-файлы - очень полезная штука, не только в случае демонов, но и в случае всяких скриптов, запускаемых из cron'а.

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

Кроме того, pid-файлы крайне удобны в случае, когда процесс надо прибить. Чем делать ps | grep myprocess | grep -v grep, куда проще сделать cat /var/run/myproc.pid. В принципе, есть ещё pidof, но есть он не везде.

Также существует заблуждение, что работа с PID-файлами - это как два пальца обоссать. Это не так, тут есть тоже куча хитростей. Собственно...

Жить правильно надо примерно так (некоторые комментарии будут даны после кода):

#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <fcntl.h>
#include <errno.h>
#include <err.h>

static int initialize(void);
static void finalize(void);

static char *pid_fname = "/var/run/myproc.pid";
static int   pid_fd    = -1;

int
main(int argc, char *argv[])
{
  if (initialize() < 0)
    return EXIT_FAILURE;

  /* здесь мы что-нибудь делаем */

  finalize();

  return EXIT_SUCCESS;
}

static int
initialize(void)
{
  int   ok      = 0;
  char *pid_buf = NULL;
  int   pid_len;

  do {
    /* собственно, открываем файл */
    pid_fd = open(pid_fname, O_CREAT | O_WRONLY);
    if (pid_fd < 0) {
      warn("can't open pid file: %s", pid_fname);
      break;
    }

    /* пытаемся его заблокировать - собственно проверка наличия копий процесса */
    if (flock(pid_fd, LOCK_EX | LOCK_NB) < 0) {
      if (errno == EWOULDBLOCK)
        warnx("already running?");
      else
        warn("flock() failed: %s", pid_fname);
      break;
    }

    /* файл заблокирован - всё хорошо, надо записать туда наш pid */

    /* получаем строковое представление идентификатора (getpid() не может вернуть ошибку) */
    pid_len = asprintf(&pid_buf, "%ll\n", (long long)getpid());
    if (!pid_buf) {
      warn("asprintf() failed");
      break;
    }

    /* теперь надо обрезать pid-файл до нужного размера, иначе после записи там может остаться лишнее */
    if (ftruncate(pid_fd, (off_t)pid_len) < 0) {
      warn("ftruncate() failed");
      break;
    }

    /* собственно, записываем pid. ввод/вывод блокирующий, поэтому достаточно одного вызова */
    if (write(pid_fd, (void *)pid_buf, (size_t)pid_len) < (ssize_t)pid_len) {
      warn("write() failed");
      break;
    }

    /* вот теперь всё чики-пуки */
    ok = 1;
  } while (0);

  /* корректно завершаемся при ошибках */
  if (!ok) {
    /* закрываем и удаляем pid-файл, если мы его таки открыли */
    if (pid_fd >= 0) {
      unlink(pid_fname);
      close(pid_fd);
    }
  }

  /* освобождаем память */
  if (pid_buf)
    free(pid_buf);

  return ok ? 0 : -1;
}

static void
finalize()
{
  /* закрываем и удаляем pid-файл */
  if (pid_fd >= 0) {
    unlink(pid_fname);
    close(pid_fd);
  }
}

Теперь немного комментариев к коду.

1) Почему flock(), а не fcntl()?

В прицнипе, похрену, какой из вариантов блокировок использовать. Но у flock() есть ряд преимуществ:

а) он проще (так как не требует заполнения struct flock).
б) он наследуется при fork()'е (да-да, если кто не знает - блокировки fcntl() не наследуются при разветвлении процесса, а в каком-то из мануалов BSD это было законно названо System V stupidity :).

Последнее особенно важно. Ибо в случае демона по моему мнению всю возможную инициализацию следует делать до освобождения управляющего терминала, чтобы иметь возможность кинуть юзеру мессаг в консоль, а не в лог.

2) asprintf()?

Можно обойтись и статическим буфером. Но с asprintf() не надо париться с его размером (ведь никто не обещал 32-битность pid_t).

3) unlink() до close()?

Так и только так. Потому что только в таком случае гарантируется отсутствие одновременного доступа к файлу двух экземпляров процесса. Так мы удаляем сначала ссылку на inode (после чего второй процесс просто создаст другой inode), а только потом закрываем файл (в результате чего, собственно, снимается блокировка).

4) BSD-specific?

Есть в BSD-системах маленькая удобная мулька, которая позволяет избавиться от вызова flock(). Но она есть только в BSD, посему её лучше не использовать. Мулька заключается в атомарной блокировке файла при его открытии (т.е. атомарность пары операций). Выглядит так:


pid_fd = open(pid_fname, O_CREAT | O_EXLOCK | O_NONBLOCK | O_WRONLY);

Если файл не получится одновременно с открытием заблокировать - он просто не откроется и open() вернёт ошибку.

---

Вот где-то так :)

Эмуляция обработки исключений в C

2006-04-22T20:23:57Z

Итак, приступим. Я по многим причинам не люблю C++, предпочитая ему обычный C. Почему - вопрос отдельный. Тем не менее, в C++ есть много полезных вещей, и одна из них - обработка исключений. Понятно, что простыни вложенных if'ов с обработкой ошибок очень сильно напрягают. Лечится, на самом деле, просто:

int
myfunc1()
{
  int ok = 0;

  do {
    /* тут делаем что нам надо */
    fp = fopen("myfile.txt", "r");
    if (!fp)
      break;

    /* и ещё что-нибудь */
    if (myfunc2() < 0)
      break;

    ok = 1;
  } while (0);

  if (!ok) {
    /* а тут обрабатываем ошибки */
  }

  return ok ? 0 : -1;
}

Disclaimer

2006-04-22T16:54:41Z

Таки данный журнал возобновляет свою работу, но уже в контексте чисто программерских заметок. Всё остальное по-прежнему останется в основном ЖЖ dnovikoff.

%)

2004-02-13T17:14:30Z

Всё ж таки, до чего ебанутый у нас народ. Пятница, вечер, 20:00. Я сижу, таки жду, когда же все к чертям собачьим уйдут с работы, чтобы можно было нормально поработать самому. И тут выясняется, что ни одна сволочь и не думает сваливать. Засада просто. Полная.

dixx @ 2004-02-12T18:27:00

2004-02-12T15:30:32Z

Странный день. Даже музыка не помогает прийти в нужное для работы состояние. Или вокруг просто слишком много людей. Пересчитал - вроде пятеро. Слишком много.

О как!

2004-02-08T21:20:26Z

Со мной очередной раз случился приступ экстремального минимализма, выражающийся в снесении с ноутбука всей графики вообще. Был приятно удивлён, когда выяснил, что при помощи lynx можно вполне адекватным образом шариться в инете (собственно сей пост пишется именно из-под lynx 2.8.5). Поставил себе старый добрый MP3Blaster заместо XMMS, настроил 16 pty на syscons'е и сижу тащусь. ВОТ.
Причиной же тому, судя по всему, стали тяжёлые роды FreeBSD 5.2.1-RC (никому не пожелаю). Началось с того, что ента сволочь с GENERIC-ядром при первой загрузке рухнула в kernel panic. Немного удивившись, пробутался с FreeBSD 5.1 Live filesystem и пересобрал ядро. Чего глюкало - хз, но после пересборки оно пришло в себя и даже загрузилось. Далее выяснилось, что хруники из BSD за каким-то поменяли номера syscall'ов, в результате чего половина софта (включая тот же mergemaster падала по SIGSEGV с воплями invalid system call number). В итоге угробил день.
Кстати, на удивление, в 5.2.1 на моём ноуте наконец-то нормально заработало ACPI + APM, хотя, по свидетельствам очевидцев :-) именно ACPI в 5.2.1 более всего нерабочее. Сплошные парадоксы, блин.

dixx @ 2003-12-31T13:55:00

2003-12-31T11:01:34Z

Я спецназовец ГРУ!

Вы – ужас, летящий на крыльях ночи. Вас втихаря боится вся Европа, а остальным крупно повезло что они про вас не знают. Остальные спецназы мира услышав про вас, нервно курят и поминают вас матерным словом. Для вас нет такого понятия – невыполнимая задача. Единственное что вас может остановить – направленный ядерный взрыв, и то не факт... Вы можете захватить АЭС, убить любого президента, обесточить Брюссель, проехать по Парижу на танке, устроить кошмар в тылу бундесвера и уйти непойманым. Вы – суперсолдат, вы – элита, ваш голубой берет – это круче всех орденов!

Какой вы спецназовец?

dixx @ 2003-12-30T18:51:00

2003-12-30T15:58:00Z

Коньяк, лимончик, наблюдение за коллегами, режущимися в преферанс... Плюс ремиксы на Delerium из колонок... Что ещё надо для хорошего настроения? :)

Merry Christmas, мать его %)

2003-12-26T17:37:56Z

Странный новый год выходит, очень странный. Пожалуй, по прошествии некоторых событий как на работе, так и в прочих местах, единственное, что остаётся - сходить в магазин, купить бутылку какого-нить Bowen или Courvoiser XO и тихо заснуть в обнимку с оной бутылкой и баальшой плюшевой собакой.

Удивительно, что подобные перспективы не вызывают никаких отрицательных эмоций. Ровно так же, как и положительных. Ровно так же, как не вызывают вообще никаких эмоций. Они просто есть. И есть усталость на пару с кучей предновогодних геморроев, не имеющих к самому новому году никакого отношения.

Ещё можно провести новый год на рабочем месте. Тоже весело. Учитывая, что планов всё равно никаких. В сравнении со всем остальным получается однохуйственно. Или монопенисуально, если выражаться несколько изящнее.

Интересно, почему-то мурлыкание Гилмора на гитаре, датируемое 1971-м годом, вызывает у меня эмоций на порядок больше, нежели общение с людьми.

dixx @ 2003-12-25T14:05:00

2003-12-25T11:15:03Z

Люди, а что по-вашему время? И зачем его считать? :)

%))

2003-12-25T10:11:52Z

Сегодня всю ночь пытался уснуть мордой в подушку так, чтобы ещё при этом и не задохнуться. Обычно сплю на боку. На спине совсем не получается - не знаю, почему. А тут мешались свежекупленные Beyerdynamic DT990. Музыки, в общем, хотелось. В итоге я-таки умудрился улечься на бок, посредством помещения головы в щель между подушкой и подлокотником дивана - щель как раз примерно с ухо размером.

dixx @ 2003-12-24T12:56:00

2003-12-24T10:03:07Z

Решил, что хочется чего-то позитивного и весёлого. Новый год-таки на дворе. Ну или почти на дворе. Перед работой купил mp3-диск Linkin Park + Papa Roach. И ХДЕ МОЙ ЛЮБИМЫЙ Reanimation? Сволочи, одним словом. А ещё полное собрание называется :(

P.S. Или я чего-то путаю?

Kill'em all!

2003-12-22T14:04:26Z

Бля, ну почему из-за какого-то ленивого мудака приходится разгребать кучи говна вместо того, чтобы пить в красивом ресторане на халяву коктейли?! Что за педерастия такая? Почему за две с лишним недели (если не больше) нельзя проставить мониторинг количества inodes через snmp?! даже скрипт уже готов, ток проставить осталось. И в результате такая вот ХУЙНЯ. С большой буквы капсом.

userpic

2003-12-21T14:24:28Z

А у меня наконец-то появился юзерпик! %)

dixx @ 2003-12-11T14:29:00

2003-12-11T11:33:13Z

БЛЯ! Ну что ж за неделя такая ебанутая?! Ещё и пятница обломалась. Пиздец просто какой-то.

dixx @ 2003-12-11T11:26:00

2003-12-11T08:45:56Z

Час X наступил. Здоровый пофигизм перерос в нездоровый и отныне на неопределённый срок девиз мой - "а ебись оно всё конём". Все недовольные же могут идти лесом. Сие заявление прошу считать официальным %)

Позавчера morigan вскользь бросила фразу: "Димк, а у тебя руки трясутся". Вчера посмотрел и удивился - реально трясутся. Плюс ко всему ещё и повышение зарплаты оказалось премией. Блин, я могу понять повышение зарплаты на 12,5%, но премия в виде 12,5% от зарплаты - imho, издевательство.

Тут ишшо начальник выдал "так как тасков будет много всегда, надо делать какие-то шаги для плавного перехода к топу2". Какой в жопу плавный переход?!!! Да это говно выкинуть надо и новое написать. Короче, нет счастья в жизни. Ещё приходить вовремя надо.

Да и после зарплаты в альфе работать на сии копейки... В общем, ЗАЕБАЛО гробить своё здоровье без всякого оргазма от работы, будь то оргазм финансовый либо творческий.

Итог прост: сей мессаг можно считать заявлением о начале поиска работы. Так что, кто готов предложить з/п от 1500EUR (именно ОТ без всяких там приколов на испытательный срок и именно EUR) программеру C/C++/Perl/Java/Asm(x86/x51/x48/21xx(x)) с опытом разработки крупных информационных систем (в частности, веб-ориентированных) как на Unix(FreeBSD,Solaris,QNX)/Linux, так и на виндах - обращайтесь за резюме на cprog@rambler.ru.

P.S. Ибо нехуй.

dixx @ 2003-11-27T20:31:00

2003-11-27T13:08:33Z

Точно день ебанутый. Написал предыдущий пост. Посмотрел на код. И увидел баг. 2 минуты. Херь какая-то просто...

dixx @ 2003-11-27T20:21:00

2003-11-27T13:02:10Z

Бля, ну что ж за день сегодня ебанутый такой?! Час смотрю на 15 строчек кода и не могу найти баг. Ладно б, еще segfault'ы какие-нить плавающие, так ни хуя - цикл с двумя переменными. Жопа. Которая вездесуща. Ещё и не выспался, к тому же.

dixx @ 2003-11-23T19:02:00

2003-11-23T16:23:35Z

Наконец-таки купил себе давно потерянный диск Орфа... Слушал и тащился. Заебал всех. Но это их проблемы.

А потом дома выключили электричество. Преимущества ноута стали явно видны. ))

... %))))

2003-11-20T17:02:29Z

Оно.... РАБОТАЕТ! %) Мать его в ..., но оно работает! %) Конечно, остались ещё баги, осталось ещё достаточно много рутины... но! %)

Когда был установлен сей факт, я понял, что хочу нажраться. И настучать кому-нить по физиономии. От души так... И под хорошую музыку. А потом лечь спать. На сутки.

dixx @ 2003-11-20T14:50:00

2003-11-20T11:52:20Z

Всё-таки возможность пить пиво на работе открывает потрясающие горизонты для развития сей привычки ;)))) Надо с этим как-то бороться %)

dixx @ 2003-11-19T12:01:00

2003-11-19T09:03:06Z

Опять опоздал на работу - всю ночь отрывались с lekar'ем и morigan. Результаты позитивные - снятие псих.усталости %) Но вот с сонливостью всё иначе... С утра поймал себя на том, что пофигизм начинает вновь приобретать нездоровые формы :)