Как изменить последовательность регистрации сетевых карт

    Привычные имена eth0, eth1, … в современной GNU/Linux системе не говорят ничего о том, в какой последовательности сетевые интерфейсы зарегистрированы в ядре. Название может привязываться к конкретной карте через системный демон udev, программой ifrename, изменяться через ip link set dev … name, et cetera.
    Однако в очень редких случаях требуется, чтобы функция if_nameindex() возвращала структуру if_nameindex в определенной упорядоченной последовательности. Например, закрытое программное обеспечение, которое имеет привязку к MAC адресу сетевого интерфейса, полученного вызовом ioctl с параметром SIOCGIFCONF. В качестве подходящего интерфейса для получения канального адреса оно выбирает первый активный не loopback интерфейс. Таким образом возникает ситуация, когда требуемый интерфейс с MAC-адресом указанным в лицензии к закрытому продукту может оказаться в списке вторым или третьим кандидатом, но никак не первым. В этом случае программа завершит свое выполнение с ошибкой.
    Чтобы убедиться в происходящем предложим простой пробник

/* ifacelist.c */
#include <stdio.h>
#include <unistd.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <netinet/in.h>
#include <net/if.h>
#include <arpa/inet.h>

int get_iface_list(struct ifconf *ifconf)
{
   int sock, rval;

   sock = socket(AF_INET,SOCK_STREAM,0);
   if(sock < 0)
   {
     perror("socket");
     return (-1);
   }

   if((rval = ioctl(sock, SIOCGIFCONF , (char*) ifconf  )) < 0 )
     perror("ioctl(SIOGIFCONF)");

   close(sock);

   return rval;
}


int main()
{
   static struct ifreq ifreqs[20];
   struct ifconf ifconf;
   int  nifaces, i;

   memset(&ifconf,0,sizeof(ifconf));
   ifconf.ifc_buf = (char*) (ifreqs);
   ifconf.ifc_len = sizeof(ifreqs);

   if(get_iface_list(&ifconf) < 0) return -1;

   nifaces =  ifconf.ifc_len/sizeof(struct ifreq);

   printf("Interfaces (count = %d)\n", nifaces);
   for(i = 0; i < nifaces; i++)
   {
     printf("\t%-10s\n", ifreqs[i].ifr_name);
   }
}

    Процесс сборки выполняется командой gcc -o ifacelist ifacelist.c. Первый запуск

~$ ./ifacelist 
Interfaces (count = 3)
        lo
        eth0        
        dummy0   
~$    

    Вымышленный сетевой интерфейс dummy0 значится в списке замыкающим. Требуется, чтобы он занимал место в списке следующее за интерфейсом lo. Добиться желаемого можно загрузкой модуля ядра dummy перед загрузкой модуля ядра сетевого адаптера eth0. В рассматриваемом примере драйвером сетевого интерфейса заведует модуль r8169. Наиболее элегантное решение для Debian/Ubuntu описано на unix.stackexchange.com (Second method) и заключается в размещении модуля ядра сетевого адаптера eth0 в blacklistе и последующая его загрузка с указанием явной последовательности через /etc/modules.

    Таким образом последовательность шагов заключается в создании файла /etc/modprobe.d/blacklist-net.conf с нижеследующим содержимым

# Disable automatic loading of kernel driver modules

blacklist r8169

    С последующим выполнением команд

update-initramfs -u

cat <<EOF >> /etc/modules
dummy
r8169
EOF

    Контрольный перезапуск системы и окончальная проверка подтвержают ожидаемый результат.

~$ ./ifacelist 
Interfaces (count = 3)
        lo        
        dummy0    
        eth0     
~$

Ошибка инициализации графической подсистемы в 1С v8.2

    Основной ответ на этот вопрос изложен здесь. Опишем отличия, который возникли при запуске на CentOS 5.x i386.

    Во-первых, сам скрипт при пробном запуске требует указания в качестве параметра директории со шрифтами.

# /opt/1C/v8.2/i386/utils/config_server 
Can not detect font directory, please specify it!
# /opt/1C/v8.2/i386/utils/config_server --help
Usage: /opt/1C/v8.2/i386/utils/config_server [fontDir]

 fontDir - path to directory with truetype fonts. If this parameter
           is omitted, script will try to detect it automatically.

    По заверению разработчиков параметр fontDir является не обязательным. Однако заверений не достаточно. Исходный текст скрипта рассказывает нам о том, что он проверяет наличие директорий /usr/share/fonts/truetype/msttcorefonts и /usr/share/fonts/msttcorefonts. Обе отвечают за существование Microsoft True Type шрифтов в различных дистрибутивах. Стандартная поставка CentOS не включает в себя выше обозначенные шрифты. Самым правильным решением будет собрать собственный пакет. Для этого установим недостающие пакеты, подготовим окружение для сборки и установим собранный пакет следующим набором команд

sudo yum install rpm-build cabextract
cat <<'EOF' > $HOME/.rpmmacros
%_topdir        %(echo ${HOME})/build
%_buildroot     %{_tmppath}/%{name}-%{version}-root-%(%{__id_u} -n)
%_rpmdir        %{_topdir}/RPMS
%_srcrpmdir     %{_topdir}/SRPMS
%packager       %(echo ${USER}@)%(hostname)
%dist           .el5.local
EOF
cp -r /usr/src/redhat $HOME/build
wget -O $HOME/build/SPECS/msttcorefonts-2.0-1.spec http://corefonts.sourceforge.net/msttcorefonts-2.0-1.spec
rpmbuild -ba $HOME/build/SPECS/msttcorefonts-2.0-1.spec
sudo rpm -ivh $HOME/build/RPMS/noarch/msttcorefonts-2.0-1.noarch.rpm
rm -fr $HOME/build $HOME/.rpmmacros

    Последующий запуск /opt/1C/v8.2/i386/utils/config_server должен корректно завершиться. Результатом является создание файла /home/usr1cv82/.magick/type.xml. Если скрипт выдал сообщение об отсутствии пакета ttf2p1, для его установки можно воспользоваться репозиторием EPEL.

Глаза бояться — руки делают

    Интересная головоломка подвернулась на днях. Как ранее отмечалось в такие моменты перестаешь верить, что 2 + 2 = 4. Постановка задачи: есть закрытое программное обеспечение, необходимо обеспечить его работу на платформе Linux Ubuntu-1004-lucid-64-minimal 2.6.32-29-server #58-Ubuntu SMP Fri Feb 11 21:06:51 UTC 2011 x86_64 GNU/Linux
. Все предельно просто.
    Первый запуск.

# ls -l macaddr
-rwxr-xr-x 1 root root 6371 2011-04-12 10:52 macaddr
# ./macaddr
-bash: ./macaddr: No such file or directory
#

    Что же это получается файл существует, однако bash говорит нам об обратном?! Проверяем имеющимися средствами

# ldd macaddr
        not a dynamic executable
# file macaddr
macaddr: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, not stripped

# strace ./macaddr
execve("./macaddr", ["./macaddr"], [/* 20 vars */]) = -1 ENOENT (No such file or directory)
dup(2)                                  = 3
fcntl(3, F_GETFL)                       = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(3, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f97f71dd000
lseek(3, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
write(3, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory
) = 40
close(3)                                = 0
munmap(0x7f97f71dd000, 4096)            = 0
exit_group(1)                           = ?
#

    Вторая, третья, …, десятая попытка не дают никаких положительных результатов. Внимательный читатель мог заметить, что бинарный файл относится к 32 битной архитектуре и запускается на 64 битной. Но это утверждение было проверено при первых запусках, ldd отрапортовался not a dynamic executable. Как оказалось его результат ошибочен.

    Так как никакой зацепки не было, поиски, разумеется, возвращали все что угодно, только не ответ на вопрос. Дальнейшие анализ все таки дал результат. Файл на самом деле динамически слинкован! Это и есть долгожданная ниточка к развязке. Запуск

# strings macaddr | head -5
/lib/ld-linux.so.2
libstdc++.so.6
__gxx_personality_v0
_Jv_RegisterClasses
__gmon_start__
# 

    Указывает, что не хватает ключевой библиотеки /lib/ld-linux.so.2 (32х битная вариант). В этом мгновение и ответ от поисковика подтянулся. Установка libc6-i386 расставляет все на свои места:

# ldd macaddr 
        linux-gate.so.1 =>  (0xf7709000)
        libstdc++.so.6 => not found
        libm.so.6 => /lib32/libm.so.6 (0xf76dc000)
        libgcc_s.so.1 => not found
        libc.so.6 => /lib32/libc.so.6 (0xf7581000)
        /lib/ld-linux.so.2 (0xf770a000)
# 

    Недостающие библиотеки в данном случае мелочи, главное ldd начал выдавать ожидаемый от него результат.

Случайный пароль в Linux

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

head -c 6 /dev/urandom | openssl base64

Исследование влияния выравнивания операций записи на производительность файловой системы на SSD носителе

    После опубликования результатов тестирования Hardware 3ware RAID10 vs Linux Software RAID10 в кулуарах мы провели сравнительное тестирование массивов 6xSAS и 6xSSD, объединенных в программный RAID10. Однако результаты не были опубликованы. Публикация статьи соображения о SSD подсыпала пороха в пороховницы.

    В рассмотрении будут участвовать два SSD диска объемом 128GB с маркировкой Super Talent UltraDrive ME SSD FTM28GX25H. Нам было интересно рассмотреть как выравнивание и его отсутствие влияет на производительность файловых систем на программной RAID1 массиве. Четких сведений относительно размера Erase Block на этом носителе не удалось найти. Мы ориентировались на значение 128KB. Аппаратная часть 4е ядра Intel Core i7 930, 24 GB RAM. Операционная система Ubuntu 10.04.2 Server LTS. Версия ядра 2.6.32-28-server.

    Для тестирования с выравниванием создавалась следующая разметка диска:

echo '2048,,fd' | sfdisk -f -uS /dev/sdc
echo '2048,,fd' | sfdisk -f -uS /dev/sdd
mdadm --create /dev/md4 --raid-devices=2 --level=1 /dev/sdc1 /dev/sdd1

    Для случая без выравнивания ориентировались на стандартное поведение fdisk (смещение в 63 сектора)

echo '63,,fd' | sfdisk -f -uS /dev/sdc
echo '63,,fd' | sfdisk -f -uS /dev/sdd
mdadm --create /dev/md4 --raid-devices=2 --level=1 /dev/sdc1 /dev/sdd1

    Для случая с выравниванием мы рассмотрели три возможных варианта создания файловых систем

  • mkfs.xfs /dev/md4 (метка XFS_ALIGN_AUTO)
  • mkfs.xfs -d su=128k -d sw=1 /dev/md4 (метка XFS_ALIGN_MANUAL)
  • mkfs.ext4 -E stride=32,stripe-width=32 /dev/md4 (метка EXT4_ALIGN)

    Первая команда обусловлена тем, что согласно документации на mkfs.xfs

When a filesystem is created  on  a  logical  volume
device,  mkfs.xfs will automatically query the logical 
volume for appropriate sunit and swidth values.

    Однако в рассматриваемом нами случае запросить эту информацию попросту не у кого. Поэтому встроенная в mkfs.xfs автоматическая настройка параметров sunit и swidth в данном случае не работает. Информация полученная из xfs_info лишнее тому подтверждение

meta-data=/dev/md4               isize=256    agcount=4, agsize=7814608 blks
         =                       sectsz=512   attr=2
data     =                       bsize=4096   blocks=31258432, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=15262, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

    Для нас этот вариант интересен оценкой целесообразности указания параметров su и sw при выполнении второй команды (su и sw являются аналогами sunit и swidth, отличие заключается в том что они оперируют байтами, а не 512 байтовыми блоками). Оказывают они какой-нибудь эффект в данном случае на производительность по сути одного накопителя или нет? Имеет смысл помнить о них инженеру или можно просто положиться на встроенный интеллект mkfs.xfs?

    С вариантом без выравнивания мы рассмотрели два случая

  • mkfs.xfs /dev/md4 (метка XFS)
  • mkfs.ext4 /dev/md4 (метка EXT4)

    Во всех случаях использовались опции монтирования для ext4 -o barrier=0, для XFS -o nobarrier.

    В качестве верхней границы блочной операций записи выступает значение в 195 MB/s, полученное в результате использования dd

$ dd if=/dev/zero of=/dev/sdd bs=128K
976835+0 records in
976834+0 records out
128035676160 bytes (128 GB) copied, 656.573 s, 195 MB/s

    График #1 демонстрирует блочную запись, чтение и перезапись для пяти кандидатов.

График 1

График 1


    Во всех трех номинациях победитель XFS_ALIGN_MANUAL. В блочной записи он превзошел своего ближайшего оппонента на 15%, на 9% в блочном чтении и на 2% при перезаписи. Ранее мы озадачились вопросом необходимости ручного выравнивания XFS раздела путем явного указания параметров sunit/swidth (su/sw). Раздел с ручным указанием этих параметров XFS_ALIGN_MANUAL превзошел своего автоматического аналога XFS_ALIGN_AUTO на 15% (23 MB/s) в блочной записи, на 21% на блочном чтении (30 MB/s), на 3% на перезаписи. Мы рекомендуем забыть о автоматической настройке от mkfs.xfs и всегда явно задавать параметры sunit/swidth (su/sw), чтобы избежать путаницы в каких случаях автоматика работает, а в каких нет. Если вы не указали эти параметры при создании файловой системы еще не все потеряно. Их можно задать на этапе монтирования раздела.

    Для файловой системы ext4 наличие выравнивания дает прирост блочной записи на 3% и 4% при перезаписи.

    В сравнении с эталонным значением в 195 MB/s (верхней границей блочной записи на этом накопителе) накладные расходы на поддержание метаинформации файловой системы XFS с выравниванием составляют 16% (XFS_ALIGN_MANUAL), на файловую систему ext4 с выравниванием — 34% (EXT4_ALIGN).

    График #2 демонстрирует предельно допустимое количество операций смещения

График 2

График 2


    Вырезка из официальной документации к bonnie++ повествует

Random Seeks
This test runs SeekProcCount processes (default 3) in parallel, doing a total of 8000 lseek()s to locations in the file specified by random() in bsd systems, drand48() on sysV systems. In each case, the block is read with read(2). In 10% of cases, it is dirtied and written back with write(2).
The idea behind the SeekProcCount processes is to make sure there's always a seek queued up.
AXIOM: For any unix filesystem, the effective number of lseek(2) calls per second declines asymptotically to near 30, once the effect of caching is defeated.
...
Many Unix systems that have the memory available will make aggressive efforts to cache the whole thing, and report random I/O rates in the thousands per second, which is ridiculous...Some have argued that bypassing the cache is artificial since the cache is just doing what it's designed to.

    Так как тестирование рассматривалось в рамках одной системы и в рамках идентичных алгоритмов кеширования, мы решили включить его в заключение. На нем четко просматривается, что выравнивание дает выигрыш в 245% для файловой системы ext4 и в 238% для файловой системы XFS. В целом лидером номинации является EXT4_ALIGN, XFS_ALIGN_MANUAL отстает от нее на 6%. Худший результат показала EXT4 (невыровненная).

    Итог. Выравнивание раздела на SSD носителе положительно сказывается на его производительности. Наиболее ярко проявляется на файловой системе XFS.

Полученные данные

Дополнительные материалы

mdadm: WARNING /dev/sdd1 and /dev/sdd appear to have very similar superblocks.

    Каждый день преподносит новые сюрпризы. С нуля настроенная система после итоговой проверочной перезагрузки не взлетела. Проблему с запуском удалось быстро детектировать. Системы пыталась запустить md-устройство с физического носителя вместо партиции. Таким образом появлялось устройство

md4 : active raid1 sdd[1] sdc[0]

    Вообще требовалось взлететь с партиций sdd1 и sdc1, а не с блочных устройств sdd и sdc. Соответственно файловая система не смогла смонтироваться и процесс инициализации системы прерывался. Однако нигде не фигурировала ошибка, почему это происходит. Пляски вокруг /etc/mdadm/mdadm.conf, чтение init скриптов никаких мыслей не навеивало. Попытка воссоздать процесс инициализации привела к команде mdadm —assemble —scan, выполнение которой дало должный результат (ошибку)

    mdadm: WARNING /dev/sdd1 and /dev/sdd appear to have very similar
    superblocks. If they are really different, please --zero the superblock on
    one. If they are the same or overlap, please remove one from the DEVICE
    list in mdadm.conf.

    Таким образом получилось что партиция sdd1 и блочное устройство sdd поимели общий superblock на оконечной стороне устройства. Google нашептал несколько решений

  There are two ways to solve this:

  (a) recreate the arrays with version-1 superblocks, which is not always an
      option -- you cannot yet upgrade version-0 to version-1 superblocks for
      existing arrays.

  (b) instead of 'DEVICE partitions', list exactly those devices that are
      components of MD arrays on your system. So in the above example:

        - DEVICE partitions
        + DEVICE /dev/hd[ab]* /dev/hdc[123]

    Решено было использовать 3-ей вариант: просто уменьшить размер раздела. В нашем это

echo '2048,249561088,fd' | sfdisk -f -uS /dev/sdc
echo '2048,249561088,fd' | sfdisk -f -uS /dev/sdd

    С последующей переинициализацией md-устройства и созданием новой таблицы раздела.

Соображения о SSD

    Заметка представляет из себя сгруппированные факты из различных источников.

    Факт номер один. SSD оперирует Erase Blockами. Понятие близкое к chunkам из страйп-ориентированных RAID-массивов. Aligning an SSD on Linux:

SSDs always operate on entire blocks of memory. … this means that if you write 1 KB of data to an SSD with an erase block size of 128 KB, the SSD needs to read 127 KB from the target block, erase the block and write the old data plus the new data back into the block. That’s something one just has to accept when using an SSD. Modern SSD firmware will do its best to pre-erase blocks when it’s idle and try to write new data into these pre-erased blocks (by mapping data to other locations on the drive without the knowledge of the OS.)

    Факт номер два. Похоже, следует избегать указанной выше оптимизации с mappingом данных. Связано это с тем, что в этом случае возрастает фрагментация и падает производительность Aligning filesystems to an SSD’s erase block size:

This technique tends to work very well. However, over time, the table will get terribly fragmented, and depending on whether the internal block sector size is 512 or 4k (or something in between), there could be a situation where all but one or two of the internal sectors on the disks have been mapped away to other erase blocks, leading to fragmentation of the erase blocks. This is not just a theoretical problem; there are reports from the field that this happens relatively easy. For example, see Allyn Malventano’s Long-term performance analysis of Intel Mainstream SSDs and Marc Prieur’s report from BeHardware.com which includes an official response from Intel regarding this phenomenon. Laurent Gilson posted on the Linux-Thinkpad mailing list that when he tried using the X25-M to store commit journals for a database, that after writing 170% of the capacity of an Intel SSD, the small writes caused the write performance to go through the floor. More troubling, Allyn Malventano indicated that if the drive is abused for too long with a mixture of small and large writes, it can get into a state where the performance degredation is permanent, and even a series of large writes apparently does not restore the drive’s function — only an ATA SECURITY ERASE command to completely reset the mapping table seems to help.

    Чтобы не допустить этого рекомендуется…угадаете? Правильно, «Allyn’s review speculates that aligning writes to erase write boundaries can help — I’m not 100% sure this is true, but without detailed knowledge of what is going on under the covers in Intel’s SSD, we won’t know for sure». Таким образом в наших интересах выравнивать запись относительно Erase Blockа
    Компания Novel в продукте SLES предложила промежуточное решение

For SSDs, one thing that has been observed especially with the first generation of drives is that their write performance drops dramatically as soon as the drives run out of empty erase blocks, which happens after using them for a while.

More modern drives address this by recycling unused (zeroed-out) space automatically and allowing the OS to tell the SSD about unused blocks using the TRIM command. SLE11 SP1 ships with wiper.sh which will send down appropriate TRIM commands by analyzing a filesystem. Note that this should be only used after having done a backup. Also it has certain limitations, like e.g. not supporting LVM or RAID and not supporting some file systems at all (btrfs) or only supporting offline or read-only trimming for some filesystems.

    Факт номер три. К сожалению, ситуация вышла немного из под контроля. Для SSD нет достоверной информации о том, какой размер имеет Erase Block.

Before doing the work, a decision needs to be taken what alignment should be used. If the internal block size is known (like for disks with internal 4k sectors), that one could be chosen. For SSDs, it is generally not known.

    Во многих источниках фигурирует информация о том, что для Intel SSDs внутренний размер Erase Blockа составляет 128KiB. Официальной информации подтверждающей этот факт нет.

    Разные источники предлагают различное смещение. Какие-то смещение в 4KB (для обычных дисков с 4KB внутренними секторами), какие-то 128 KB. Более осмысленным мне показалось решение из Redmona

But the friends from Redmond provide guidance here — as Windows 7 by default uses 1M partition alignment, it is save to assume that most drives will be optimized to provide good performance with such alignment. So in case of doubt, it will never hurt to align partition starts to 1M boundaries.

    Оставим за кулуарами черную магию скрытую в расчетах секторов и головок для fdisk, воспользуемся простой командой

echo '2048,,' | sfdisk -f -uS /dev/SSD

    Которая создаст раздел с требуемым смещением в 2048 секторов 512 байт каждый (2048 * 512 byte / 1024 / 1024 = 1 MB).

    Оказывается современные версии fdisk при отключенном режиме совместимости предлагают смещение именно в 1MB:

 fdisk /dev/sdb 
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0x5310aa1b.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
         switch off the mode (command 'c') and change display units to
         sectors (command 'u').

Command (m for help): c
DOS Compatibility flag is not set

Command (m for help): u
Changing display/entry units to sectors

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First sector (2048-3842047, default 2048): 

Master privileges unavailable on UPS

    С таким сообщением довелось повоевать на прошлой неделе при подключении Network UPS Tools (NUT) к источнику бесперебойного питания. Первое впечатление было, что необходимые директивы конфигурационных файлов прописыны верно. В uspd.conf добавлен полноправный пользователь

[upsmaster]
  password = 123456
  allowfrom = 127.0.0.1
  actions = SET
  instcmds = ALL
  upsmon master

    Прописана соответствующая этому пользователю секция в upsmon.conf

MONITOR ups@localhost 1 upsmaster 123456 master

    Однако upsmon рапортовал

Master privileges unavailable on UPS

    Поиски приводили к рекомендациям добавить директиву upsmon master к описанию привилегий пользователя. К моему сожалению, этот совет не принес ничего нового. Поскольку с наскока не удалось разобраться, началось скрупулезное чтение документации. В одном из комментариев синим по черному (чтение проходило в vime, запущенном в терминале) обнаружились заветные строчки

#
# allowfrom: ACL names that this user may connect from.  ACLs are
#            defined in upsd.conf.
#

    По умолчанию для CentOS определены два ACL в конфигурационном файле upsd.conf

ACL all 0.0.0.0/0
ACL localhost 127.0.0.1/32

    Таким образом параграф описывающий полноправного пользователя должен выглядеть следующим образом (для машины localhost)

[upsmaster]
  password = 123456
  allowfrom = localhost
  actions = SET
  instcmds = ALL
  upsmon master

    Мое личное мнение allowfrom в данном случае не подходящие название для директивы, требующей в качестве значения имени ACL.

londiste statement_timeout

    Вероятно, каждому кто использовал londiste в нагруженном проекте сталкивался с проблемой добавления триггера pgq.logtriga на providerе. На экран при этом вываливается простыня (ключевой момент отмечен красным цветом)

$ londiste.py conf.ini provider add --all
2011-02-02 12:36:10,146 8356 INFO Adding public.tablename
Traceback (most recent call last):
  File "/usr/bin/londiste.py", line 134, in ?
    script.start()
  File "/usr/bin/londiste.py", line 97, in start
    self.script.start()
  File "/usr/lib64/python2.4/site-packages/skytools/scripting.py", line 379, in start
    run_single_process(self, self.go_daemon, self.pidfile)
  File "/usr/lib64/python2.4/site-packages/skytools/scripting.py", line 98, in run_single_process
    runnable.run()
  File "/usr/lib64/python2.4/site-packages/londiste/setup.py", line 73, in run
    self.admin()
  File "/usr/lib64/python2.4/site-packages/londiste/setup.py", line 168, in admin 
    self.provider_add_tables(self.args[3:])
  File "/usr/lib64/python2.4/site-packages/londiste/setup.py", line 258, in provider_add_tables
    self.provider_add_table(tbl)
  File "/usr/lib64/python2.4/site-packages/londiste/setup.py", line 282, in provider_add_table
    self.exec_provider(q, [self.pgq_queue_name, tbl])
  File "/usr/lib64/python2.4/site-packages/londiste/setup.py", line 339, in exec_provider
    src_curs.execute(sql, args)
  File "/usr/lib64/python2.4/site-packages/psycopg2/extras.py", line 88, in execute
    return _cursor.execute(self, query, vars, async)
psycopg2.extensions.QueryCanceledError: canceling statement due to statement timeout
CONTEXT:  SQL statement "create trigger "pg-1-switch-queue_logger" after insert or update or delete on public.tablename for each row execute procedure pgq.logtriga('pg-1-switch-queue', 'kvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv', 'public.tablename')"
PL/pgSQL function "provider_create_trigger" line 12 at EXECUTE statement
SQL statement "SELECT  londiste.provider_create_trigger(  $1 ,  $2 ,  $3 )"
PL/pgSQL function "provider_add_table" line 27 at PERFORM
PL/pgSQL function "provider_add_table" line 2 at RETURN
$

    Все очевидно. Создание триггера не укладывается в заданный интервал statement_timeout. Однако для пользователя явно задан statement_timeout в 0. Причина зарыта в самом londiste он вызывает SET LOCAL statement_timeout = %d перекрывая тем самым системные настройки.

    Более ранние версии требовали модификации исходного кода londiste. Начиная с 2.1.8, появилась штатная опция конфигурационного файла lock_timeout по умолчанию заданная 10 секундам. Соответственно установить statement_timeout в 100 секунд можно следующей директивой конфигурационного файла:

lock_timeout = 100

watchdog: cтоит игра свеч?!

    watchdog дословно переводится — как сторожевой пес. Нельзя недооценивать тот «полезный» функционал, который привнес с собой этот термин и все что с ним связано в ИТ индустрию. Сейчас на нем строятся не только аппаратные, но и программные решение. Позволю себе показать пальчиком, например, система АСР Билл-Мастер компании «Инлайн Телеком Солюшнс» в достаточно древней своей версии поставлялась с системой watchdogа для Radius. Которая шустро поднимала периодически падающий Radius. Т.е. менеджеры по продажам настолько наседали на программистов компании, что последние не успели до конца обкатать разработанные улучшений к FreeRadius и появилось «красивое» решение c watchdogом. Другой наглядный пример. Производители материнских плат с встроенной системой watchdog. Это, видимо, камень в огород (ведь когда-то я в этом слове сделал три ошибки!) Microsoft?

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

    Обо всем по порядку. Существуют отличные программные продукты nginx от Игоря Сысоева, apache и многие другие. Проверенные сообществом и надежные продукты. Однако существуют люди, которые не в состоянии банально их настроить или разобраться в проблемах собственноручно созданных конфигураций. В этом случае появляются на горизонте…верно, watchdogи. Маразм крепчает и появляются решения ежеминутно запускаемые службой cron вида

nc -w 3 localhost 80 || (killall -9 nginx; sleep 2; /etc/init.d/nginx start)

    Рассмотрим, когда это решение может выйти боком. Предположим, у нас в распоряжении ферма из nginx серверов, центральные сервера описывают нижележащие сервера через upstream. На одном из серверов возникает проблема и дежурный инженер принимает решение вывести один сервер с nginx из эксплуатации. Он выполняет команду service nginx stop и со спокойной душой отдает проблему дальше на эскалацию системным администраторам, будучи уверенным что директива upstream у вышестоящего nginx отключит неисправный узел по причине не доступности. Но! Приходит сторожевая собака и поднимает неисправный сервер. Итог: вместо решение проблемы пес ее воскресил. Получается watchdog, который призван решать проблемы , благополучно вставляет палки в колеса решившему проблему человеку.

    Ложечка меда. Соглашусь, что иногда без этих костылей просто никуда. Как правило это ситуации, когда в руки администратору попадает никудышный закрытый/коммерческий продукт. Как не прыгай вокруг службы технической поддержки с бубном, добиться какого-либо результата не всегда представляется возможным. Но! С открытыми продуктами в массе своей совершенно иная ситуация. Гораздо правильнее разобраться в проблеме, более того, зачастую она кроется в собственных ошибках. У меня все.