У меня вопрос к тем у кого есть опыт настройки бондинга на ESX. Как я понял варианта есть два:

1) Добавить в vSwitch два аплинка и сконфигурировать NIC teaming в конфигах vSwitch'а. При этом в VM'ке у нас допустим один (виртуальный) интерфейс подключенный к этому vSwitch'у.

2) Пробросить физические интерфейсы с ESX'а напрямую (pass-through) в VM'ку с Linux и сделать бонд с помощью bonding драйвера. При этом, как и в первом случае, в VM'ке всего один интерфейс, в этом случае bond0.

Собственно вопрос в том, какой вариант более производительный - бондинг средствами ESX и хождение через vSwitch или бондинг средствами Linux прямо на физических интерфейсах? Кто-нибудь сравнивал такие конфигурации? Существенная ли разница по скорости?

P.S. У меня нет сейчас доступа к железу на котором я бы мог сам это проверить.

Есть стандартная KVM сеть через bridge:

$ brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.00601656b439       no              eth3
                                                        tap0
$

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

ebtables –t broute –A BROUTING -p IPv4 -i tap0 --ip-dst <eth3 IP> -j redirect  --redirect-target DROP

То есть мы говорим не бриджить фреймы которые предназначаются IP eth3 интерфейса в роутить их.

После добавления "-j arpreply " правила в ebtables я стал видеть мои icmp request пакеты в логах iptables вплоть до nat/PREROUTING. Далее пакет дропается.

Подскажите как правильно реализовать такую схему через ebtables/iptables/ip...

Спасибо!

Есть большое количество прожорливых процессов по которым необходимо периодически сохранять информацию из /proc/<pid>/smaps для последующего анализа.

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

Небольшая оптимизация - все еще делаем polling, но уже /proc/<pid>/stat файлов и сохраняем большой smaps файл только в случае если в stat файле для процесса изменились RSS или VSS.
Не очень надежно, так как smaps может измениться даже если RSS/VSS остались неизменны по сравнению с предыдущей итерацией опроса, но более или менее работоспособно.

Вопрос собственно вот какой - можно ли каким-либо образом мониторить изменение RSS/VSS произвольно процесса не используя polling файлов в /proc?
Есть ли подобные механизмы в ядре?

P.S.
Это можно сделать через SystemTAP, но пока ищу другие альтернативы.

Привет!
Есть модуль ядра который отлично компилируется со всеми ванильными ядрами с 2.6.0 до 3.3.
Проблема в том, что если собирать его в пропатченном ядре SLES-11 SP2 (типа 3.0, но с фичами бэкпортированными из 3.1), то ломается логика определения версии ядра (она расходится с ванильной).

Есть ли какой-нибудь макрос, специфичный для ядер SLES, который бы я мог проверить в своем модуле и немного изменить логику если он определен?
В гугле ответ не нашел, но возможно плохо искал.

Спасибо!

Есть сложный скрипт на bash, который вызывает кучу разных скиптов, из которых в свою очередь вызывается куча различных программ. Хочется по результатам выполнения скрипта получить информацию по тому, какие программы были запущены и сколько времени заняло их выполнение.

Результат должен быть в виде дерева, например:

my_script.sh (10 sec)
|
|---> another_script.sh (2 sec)
|
|---> yet_another_script.sh (5 sec)
       |
       |---> make (3 sec)
              |
              |---> gcc (1 sec)

Долго гуглил, но не нашел готового решения для данной задачи. Может кто знает готовый тул?

Спасибо!

Пытаюсь разобраться с багом в ядре (где куча разных самописных модулей). Сначала попробовал прописать «console=ttyS0,115200 console=tty0» в grub, но желаемого не получил - на другом конце при чтении из сериал консоли просто увидел:

[  131.745495] #:K:( 0:1):00000000000007be:00000:0000000131-743:Unspec :: Registering setup function 0xffffffffa0787890 for test 'device_unnamed'.

[  131.745515] #:K:( 0:1):00000000000007be:00000:0000000131-743:Unspec :: Registering teardown function 0xffffffffa0787962 for test 'device_unnamed'.

[  131.745540] #:K:( 0:1):00000000000007be:00000:0000000131-743:Unspec :: Registering setup function 0xffffffffa0787890 for test 'device_by_id'.

[    0.000000] Initializing cgroup subsys cpuset

[    0.000000] Initializing cgroup subsys cpu

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

Следующая идея была попробовать kexec/kdump. Пересобрал ядро, которое сразу выполняет роль и system kernel и dump-capture kernel. Для начала проверил так:

# kexec -l /boot/linux-3.0.0 --initrd=/boot/initrd-3.0.0 --append="root=/dev/mapper/myvg-root 1 irqpoll maxcpus=1 reset_devices"
# kexec -e

и успешно загрузился в single-user mode.

Потом попробовал поставить panic-hook и симулировать panic:

# kexec -p /boot/linux-3.0.0 --initrd=/boot/initrd-3.0.0 --append="root=/dev/mapper/myvg-root 1 irqpoll maxcpus=1 reset_devices"
# echo c > /proc/sysrq-trigger

Вот тут-то и началить не совсем понятные для меня чудеса. Dump-capture ядро грузится очень медленно, на консоль выдает много сообщений типа «ata2: lost interrupt» и не работает клавиатура. То есть если грузиться в ядро через «kexec -e», то оно работает, а при kernel panic нет.

Собственно вопроса два

• При каких ошибках ядро просто ребутится без вывода на консоль сообщения о критической ошибке (см. вывод в начале сообщения)?
• Что я делаю не так с kexec/kdump?

Спасибо!

P.S. Использую Arch Linux с ванильными ядрами 2.6.39.3 и 3.0.0. Оба линукса - виртуальные машины на VmWare ESX сервере, а serial порты естественно тоже виртуальные (через pipe).

Есть проблема с простым Perl-скриптом:
---------------------------------------------------------------------
use strict;
use warnings;
use threads;
use threads::shared;
use POSIX;

my $print_mutex : shared;

#####################################################################

sub _print($)
{
my $str = shift;
lock($print_mutex);
my $id = threads->tid();
my $time = strftime('%H:%M:%S', localtime time);
print «$time [$id] $str»;
return;
}

#####################################################################

sub run()
{
for my $i (1 .. 3)
{
_print(«Begin $i\n»);
sleep 1;
_print(«End $i\n»);
}
return threads->tid();
}

#####################################################################

_print «Starting test.\n»;
my @threads;
for my $thr_num (1 .. 2)
{
my $thr = threads->create('run');
push @threads, $thr;
_print «Thread created.\n»;
}
foreach (@threads)
{
my $id = $_->join;
_print «Thread '$id' finished.\n»;
}
_print «Test finished.\n»;

#####################################################################
---------------------------------------------------------------------

Когда запускаю его на Linux с Perl-5.10 все работает корректно:

$ perl /tmp/a.pl
14:25:54 [0] Starting test.
14:25:54 [0] Thread created.
14:25:54 [1] Begin 1
14:25:54 [0] Thread created.
14:25:54 [2] Begin 1
14:25:55 [1] End 1
14:25:55 [1] Begin 2
14:25:55 [2] End 1
14:25:55 [2] Begin 2
14:25:56 [1] End 2
14:25:56 [1] Begin 3
14:25:56 [2] End 2
14:25:56 [2] Begin 3
14:25:57 [1] End 3
14:25:57 [0] Thread '1' finished.
14:25:57 [2] End 3
14:25:57 [0] Thread '2' finished.
14:25:57 [0] Test finished.
$

А вот когда я запускаю этот же скрипт через SSH, то вижу какой-то бред (смотрите на таймстампы и ID потоков):

$ ssh localhost 'perl /tmp/a.pl'
14:26:11 [0] Starting test.
14:26:11 [0] Thread created.
14:26:11 [1] Begin 1
14:26:12 [1] End 1
14:26:12 [1] Begin 2
14:26:13 [1] End 2
14:26:13 [1] Begin 3
14:26:14 [1] End 3
14:26:11 [2] Begin 1
14:26:12 [2] End 1
14:26:12 [2] Begin 2
14:26:13 [2] End 2
14:26:13 [2] Begin 3
14:26:14 [2] End 3
14:26:11 [0] Thread created.
14:26:14 [0] Thread '1' finished.
14:26:14 [0] Thread '2' finished.
14:26:14 [0] Test finished.
$

Никогда не видел ничего подобного на однопоточных Perl-скриптах и заметил что проблема с I/O начинается после создания первого потока.

Проверял этот же скрипт на Windows с Perl-5.12 и получил те же результаты. Так что похоже что проблема не с конкретной версией Perl или OS.

В чем тут дело?

Привет!
Есть ли адаптер, позволяющий воткнуть 68-pin CardBus карту в 26-pin/54mm ExpressCard слот?
Сходу не нагуглил ничего подходящего.
Спасибо!

Hi!

Так получилось что у меня сейчас закрыт nntp и я не могу использовать обычные ридеры (например thunderbird).
Никак не могу нагуглить нормальный онлайновый ридер для
comp.unix.programmer и comp.programming.threads
Количество спама при чтении через Google Groups просто зашкаливает, что делает его совершенно неюзабельным.
Вообщем нужет онлайновый ридер для этих групп с фильтрацией спама и доступом к полному архиву.
То есть что-то типа http://news.gmane.org/gmane.linux.file-systems.
Знает кто-нибудь такие?

Спасибо!

Всем привет!

Я пользовался услугами ADSL от Питерского СЗ Телекома больше двух лет.
Все работало вполне сносно. У меня стоял Wifi-ADSL router Dlink 2640 через который настраивался LAN, DHCP, port forwarding, WiFi, MAC filtering для WiFi, DynDNS и т.д.
Вообщем все работало отлично и я имел полный контроль над железкой и ее
конфигурацией.

Однако недавно мне позвонили из СЗ Телекома и сообщили что пока в
добровольном (а впоследствие в принудительном) порядке всех переводят
на оптику. Для телефонии действительно есть свои полюсы (реально стало лучше качество, появился бестплантый АОН).
Однако по телефону мне не сказали (а сам я идиот поленился в нете проверить), что инет будет приходить не по ADSL, а по PON.
Короче пришли 2 монтажника и пославили мне девайс Huawei EchoLife 850g.
На входе у него оптика, а на выходе 2 розетки RJ-11 (работает только одна) и 4 розетки RJ-45 (работает только первая - LAN1).

Когда стал разбираться с железкой увидел, что она сама поднимает внешний интерфейс, прописывает свой локальный интерфейс как 192.168.100.1, разруливает маршрутизацию и отдает DHCP в диапазоне начиная с 192.168.100.2.
Проблема в том, что она все натит сама и порты на мои внутненние сервера естественно не прокидывает.

Думал что переконфигурирую ее и все настрою.
Не тут-то было - все порты у нее закрыты (включая 22 и 80):

# nmap 192.168.100.1

Starting Nmap 5.21 ( http://nmap.org ) at 2010-03-23 08:44 MSK
Nmap scan report for 192.168.100.1
Host is up (0.046s latency).
Not shown: 994 closed ports
PORT STATE SERVICE
21/tcp filtered ftp
22/tcp filtered ssh
23/tcp filtered telnet
53/tcp open domain
80/tcp filtered http
8011/tcp open unknown
MAC Address: 00:25:9E:7C:46:3E (Huawei Technologies Co.)

Nmap done: 1 IP address (1 host up) scanned in 2.13 seconds
#

Кнопки hard reset для сброса настроек в дефалтовые на девайсе нет!
Похоже что эти ур@ды специально так законфигурировали девайс чтобы никто не лазил и не менял ничего.
Инфы по девайсу крайне мало.

Есть ли у кого опыт работы с девайсом и его «взлома» для переконфигурации.

Заранее спасибо!

Hi!

Жил у меня дома DLink-2640U.
Почти 2 года все работало как часы, но недавно начались проблемы.
Такое ощущение что он стал делать постоянный up/down по всем Ethernet
портам.
Сделал ему hard reset, но и это не помогло. На управляющий адрес не зайти.

Вообщем забил и купил новый DLink-2640U (точнее его модификацию
DLink-2640BRUC).
Восстановиться из забэкапленной конфиги не получилось (видимо между модемами есть разница), поэтому настроил все с нуля.


У меня в wireless сети 4 компа:
1) Dell Inspiron 1501 с broadcom'овским Wi-Fi.
2) Dell Latitude D620 с intel'овским Wi-Fi.
3) КПК acer n300.
4) Обычный виндовый комп с USB модемом ASUS WL-167g (выглядит как флэшка :))


На старой конфигурации первые 3 компа работали отлично, а с 4-м периодически случались проблемы.
Коннект терялся и переустановить его без передергивания модема из
USB-порта было невозможно.
Это не большая проблема т.к. комп юзается не часто.

Теперь о проблеме.
На новой конфигурации при включении 4-го компа в сеть через несколько секунд нормальной работы на _всех_ подключенных к роутеру хостах
(даже подключенных через LAN) пропадает инет.
Как минимум не работает http и ssh на любые внешние хосты.
Повторяется это стабильно.
Если не включать WL-167g в сеть, то все работает долго и стабильно.

Вопрос простой - чем объяснить подобное поведение?

P.S. Можно конечно выбросить этот ASUS и купить нормальный PCI WiFi
модем. Но я на 100% не уверен что проблема в нем.

Hi!

Очевидно, что произвольный процесс может "навечно" заблокироваться
на выполнении системного вызова при определенных условиях.
Простейшие примеры - read, select, epoll_wait, futex.

Возникла очень просто формулируемая задача, простое решение которой
в голову не приходит.
Имеем процесс с определенным PID'ом.
Требуется определить, висит ли данный процесс на каком-либо системном
вызове или нет.
Критерием зависания будем считать выполнение системного вызова более
некоторого таймаута (например T=30 секунд).

Таким образом, если процесс закончил выполнение хотя бы одного
системного вызова, то считаем, что он не висит.
Если же за время наблюдения T процесс так и не завершил выполнение
системного вызова, то считаем, что он висит.

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

Есть идеи как решить данную проблему?

P.S.

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

Привет!

Есть команда:
rsh -l <USER> <CISCO_IP> "sh subscriber session"

Выдает она вот что:

Uniq ID Interface State Service Identifier Up-time
34432 IP unauthen Local Term xxxxyyyyzzzzwwww 02:13:05
7701 IP authen Local Term xxxxyyyyzzz 04:33:54
35934 IP authen Local Term xxxxyyyyzzzzww 04:33:11
...
...
...

Я заметил, что если значение в колонке Identifier длинное, то оно
обрезается (до 20 символов).

Можно ли отключить обрезание?
Или хотя бы переносить на следующую строку?

Спасибо!

Привет!

Есть довольно большой проект на C++, в котором ни с того, ни с сего
перестали работать семафоры (используем обертку ACE_Thread_Semaphore).
Долго сидел и искал ошибку. В итоге написал маленький пример на
полстраницы, который демонстрирует проблему:

////////////////////////////////////////////////////////////////////

#include <iostream>
#include <cassert>

#include <ace/Thread_Semaphore.h>

extern "C"
{
#include <time.h>
}

int main(int argc, char** argv)
{
if(argc > 1)
{
const time_t current_unix_time = ::time(NULL);
assert(current_unix_time != -1);

struct tm tm_, *ptm;
ptm = ::localtime_r(&current_unix_time, &tm_);
assert(ptm);
assert(ptm == &tm_);

std::cout << "UNIX time = " << current_unix_time << ", Local time = "
<< 1900 + ptm->tm_year << "-" << 1 + ptm->tm_mon << "-" << ptm->tm_mday
<< " " << ptm->tm_hour << ":" << ptm->tm_min << ":" << ptm->tm_sec << std::endl;
}

ACE_Thread_Semaphore sem(0);
std::cout << "Before acquiring the semaphore. We must hang here since current value of semaphore is 0." << std::endl;
int r = sem.acquire();
std::cout << "After acquiring the semaphore. r = " << r << ". " << strerror(errno) << std::endl;

return 0;
}

////////////////////////////////////////////////////////////////////

Собираю следующей командой:

g++-4.3.2 -g -I /usr/local/dev/ace-5.6.7/include/ -L /usr/local/dev/ace-5.6.7/lib/ -pthread -lACE main.cpp

Итак, в чем же проблема (точнее как она проявляется).
1) Сначала запустим программу без параметров:

krivenok@develop2 13:29:32 /tmp/strange $ ./a.out
Before acquiring the semaphore. We must hang here since current value of semaphore is 0.
^C
krivenok@develop2 13:30:24 /tmp/strange $

Как и ожидалось мы блокируемся на семафоре.

2) Теперь запустим программу с параметрами (argc > 1):

krivenok@develop2 13:30:24 /tmp/strange $ ./a.out 1
UNIX time = 1238405487, Local time = 2009-3-30 13:31:27
Before acquiring the semaphore. We must hang here since current value of semaphore is 0.
After acquiring the semaphore. r = -1. Function not implemented
krivenok@develop2 13:31:27 /tmp/strange $


Если в первом случае в выводе strace видим:

write(1, "Before acquiring the semaphore. W"..., 89Before acquiring the semaphore. We must hang here since current value of semaphore is 0.
) = 89
futex(0x804f750, FUTEX_WAIT, 0, NULL^C <unfinished ...>


То во втором:

write(1, "Before acquiring the semaphore. W"..., 89Before acquiring the semaphore. We must hang here since current value of semaphore is 0.
) = 89
futex(0x804f7e8, 0xb7cbb170 /* FUTEX_??? */, 0) = -1 ENOSYS (Function not implemented)
write(1, "After acquiring the semaphore. r "..., 64After acquiring the semaphore. r = -1. Function not implemented
) = 64

То есть в вызов futex передается мусор.

Есть идеи в чем проблема?
Может я где-то сильно туплю и не вижу очевидного?

Мои эксперименты показывают, что причина проблемы - вызов
функции localtime_r (пробовал и localtime, и gmtime[_r]).
Если ее убрать, что все работает как ожидалось.

Кстати, обнаружилась проблема после обновления glibc
с версии 2.6.1 до 2.8.

Параметры системы:
1) gcc

krivenok@develop2 13:37:34 /tmp/strange $ g++-4.3.2 --version
g++-4.3.2 (GCC) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

krivenok@develop2 13:37:39 /tmp/strange $

2) glibc

krivenok@develop2 13:37:39 /tmp/strange $ ls -al /lib/libc.so.6
lrwxrwxrwx 1 root root 11 Мар 28 15:31 /lib/libc.so.6 -> libc-2.8.so
krivenok@develop2 13:38:30 /tmp/strange $

3) ACE

5.6.7

Всем заранее спасибо за помощь!

Привет!

Перед DROP'ом входящих TCP-соединений в конфиге
iptables прописал LOG с префиксом 'BAD TCP CONNECTION'.

Вот собранная за сегодня статистика:

dmesg | grep 'BAD TCP CONNECTION' | perl -ne 's/^.*SRC=(\S+).*DST=(\S+).*SPT=(\S+).*DPT=(\S+).*$/$1:$3 -> $2:$4/ && print' | sort -u

195.189.47.22:1224 -> 192.168.1.2:56510
195.189.47.22:1855 -> 192.168.1.2:56510
195.189.47.22:1904 -> 192.168.1.2:56510
195.189.47.22:2650 -> 192.168.1.2:56510
195.189.47.22:2666 -> 192.168.1.2:56510
195.189.47.22:3401 -> 192.168.1.2:56510
195.189.47.22:3890 -> 192.168.1.2:56510
195.189.47.22:4631 -> 192.168.1.2:56510
212.106.37.189:58969 -> 192.168.1.2:56510
212.106.37.189:59353 -> 192.168.1.2:56510
213.41.92.4:3187 -> 192.168.1.2:80
217.8.236.212:10045 -> 192.168.1.2:56510
217.8.236.212:13325 -> 192.168.1.2:56510
217.8.236.212:13383 -> 192.168.1.2:56510
217.8.236.212:15873 -> 192.168.1.2:56510
217.8.236.212:16684 -> 192.168.1.2:56510
217.8.236.212:16832 -> 192.168.1.2:56510
217.8.236.212:45153 -> 192.168.1.2:56510
217.8.236.212:56601 -> 192.168.1.2:56510
217.8.236.212:57197 -> 192.168.1.2:56510
217.8.236.212:57930 -> 192.168.1.2:56510
217.8.236.212:63987 -> 192.168.1.2:56510
217.8.236.212:9204 -> 192.168.1.2:56510
217.8.236.212:9297 -> 192.168.1.2:56510
77.239.239.145:4436 -> 192.168.1.2:56510
77.51.21.134:4195 -> 192.168.1.2:56510
77.51.21.134:4256 -> 192.168.1.2:56510
77.51.21.134:4490 -> 192.168.1.2:56510
78.137.49.65:1176 -> 192.168.1.2:56510
78.137.49.65:3290 -> 192.168.1.2:56510
78.137.49.65:3313 -> 192.168.1.2:56510
78.138.191.44:1168 -> 192.168.1.2:56510
78.138.191.44:1681 -> 192.168.1.2:56510
78.138.191.44:2007 -> 192.168.1.2:56510
78.138.191.44:2290 -> 192.168.1.2:56510
78.138.191.44:2530 -> 192.168.1.2:56510
78.138.191.44:2567 -> 192.168.1.2:56510
78.138.191.44:2827 -> 192.168.1.2:56510
78.138.191.44:3878 -> 192.168.1.2:56510
78.138.191.44:3934 -> 192.168.1.2:56510
78.138.191.44:4226 -> 192.168.1.2:56510
78.138.191.44:4239 -> 192.168.1.2:56510
78.138.191.44:4661 -> 192.168.1.2:56510
78.63.142.12:1306 -> 192.168.1.2:40336
78.63.142.12:2603 -> 192.168.1.2:40336
78.63.142.12:2627 -> 192.168.1.2:40336
78.63.142.12:3926 -> 192.168.1.2:40336
78.63.142.12:3944 -> 192.168.1.2:40336
...
...
...
94.179.114.52:2941 -> 192.168.1.2:56510
94.179.114.52:2987 -> 192.168.1.2:56510
94.179.114.52:3145 -> 192.168.1.2:56510
94.179.114.52:3225 -> 192.168.1.2:56510
94.179.114.52:3457 -> 192.168.1.2:56510
94.180.16.168:1655 -> 192.168.1.2:56510
94.180.16.168:4118 -> 192.168.1.2:56510
94.180.16.168:4910 -> 192.168.1.2:56510
95.24.45.118:63875 -> 192.168.1.2:56510
95.24.45.118:63939 -> 192.168.1.2:56510
95.24.45.118:63985 -> 192.168.1.2:56510
95.24.45.118:64347 -> 192.168.1.2:56510
95.24.68.89:2971 -> 192.168.1.2:56510
95.24.68.89:3083 -> 192.168.1.2:56510
95.24.68.89:3283 -> 192.168.1.2:56510
95.24.68.89:3359 -> 192.168.1.2:56510
95.24.68.89:3438 -> 192.168.1.2:56510
95.24.68.89:3671 -> 192.168.1.2:56510
95.24.68.89:3739 -> 192.168.1.2:56510
95.24.68.89:3887 -> 192.168.1.2:56510
95.24.68.89:4070 -> 192.168.1.2:56510
95.54.69.115:1642 -> 192.168.1.2:56510
95.54.69.115:2628 -> 192.168.1.2:56510
95.54.69.115:2774 -> 192.168.1.2:56510
95.54.69.115:3046 -> 192.168.1.2:56510
95.54.69.115:3742 -> 192.168.1.2:56510
95.54.69.115:4368 -> 192.168.1.2:56510
95.54.69.115:4392 -> 192.168.1.2:56510


Удивляют попытки установления соединения на порт 56510.
Причем с разных хостов и в разное время.
Что за порт такой (в google не нашел)?
Кто ломится?

Спасибо!

Привет!

Есть проект с поддиректорией tests, где лежит скрипт
fds_by_process.sh, нужный только для тестов.

В tests/Makefile.am прописываю:

dist_bin_SCRIPTS = fds_by_process.sh
noinst_SCRIPTS = fds_by_process.sh
check_SCRIPTS = fds_by_process.sh

При этом скрипт начинает включаться в дистрибутив, но к
сожалению инсталлируется в ${prefix}/bin.

Короче кладет он на noinst_SCRIPTS.

Как исключить скрипт из числа файлов подлежащих инсталляции?

Спасибо!

Привет!

Примерно год назад настроил VPN до работы.
Все работало как часы.

3 дня назад возникла проблема.
Почту по IMAP'у я получал нормально, а как только пытался передать
файл по scp интерфейс ppp0 падал.
Нарыл вот это:
https://bugs.launchpad.net/ubuntu/+source/network-manager-pptp/+bug/294564
Проблема решилась просто понижением mtu:
ifconfig ppp0 mtu 1412

Вчера же VPN перестал работать полностью.
Соединение успешно устанавливается, а затем сразу рвется:

Nov 21 16:57:14 olimpico_home pppd[11338]: pppd 2.4.4 started by root, uid 0
Nov 21 16:57:14 olimpico_home pppd[11338]: Using interface ppp0
Nov 21 16:57:14 olimpico_home pppd[11338]: Connect: ppp0 <--> /dev/pts/3
Nov 21 16:57:14 olimpico_home pptp[11339]: anon log[main:pptp.c:272]: The synchronous pptp option is NOT activated
Nov 21 16:57:14 olimpico_home pptp[11343]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
Nov 21 16:57:14 olimpico_home pptp[11343]: anon log[ctrlp_disp:pptp_ctrl.c:738]: Received Start Control Connection Reply
Nov 21 16:57:14 olimpico_home pptp[11343]: anon log[ctrlp_disp:pptp_ctrl.c:772]: Client connection established.
Nov 21 16:57:15 olimpico_home pptp[11343]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
Nov 21 16:57:15 olimpico_home pptp[11343]: anon log[ctrlp_disp:pptp_ctrl.c:857]: Received Outgoing Call Reply.
Nov 21 16:57:15 olimpico_home pptp[11343]: anon log[ctrlp_disp:pptp_ctrl.c:896]: Outgoing call established (call ID 0, peer's call ID 205).
Nov 21 16:57:16 olimpico_home pppd[11338]: CHAP authentication succeeded
Nov 21 16:57:16 olimpico_home pppd[11338]: CHAP authentication succeeded
Nov 21 16:57:16 olimpico_home pppd[11338]: MPPE 128-bit stateless compression enabled
Nov 21 16:57:18 olimpico_home pppd[11338]: local IP address 192.168.2.5
Nov 21 16:57:18 olimpico_home pppd[11338]: remote IP address 192.168.2.1
Nov 21 16:57:18 olimpico_home pppd[11338]: Connect time 0.0 minutes.
Nov 21 16:57:18 olimpico_home pppd[11338]: Sent 0 bytes, received 10 bytes.
Nov 21 16:57:21 olimpico_home pppd[11338]: Connection terminated.
Nov 21 16:57:21 olimpico_home pptp[11339]: anon warn[decaps_hdlc:pptp_gre.c:197]: short read (-1): Input/output error
Nov 21 16:57:21 olimpico_home pptp[11339]: anon warn[decaps_hdlc:pptp_gre.c:209]: pppd may have shutdown, see pppd log
Nov 21 16:57:21 olimpico_home pptp[11343]: anon log[callmgr_main:pptp_callmgr.c:231]: Closing connection (unhandled)
Nov 21 16:57:21 olimpico_home pptp[11343]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request'
Nov 21 16:57:21 olimpico_home pptp[11343]: anon log[call_callback:pptp_callmgr.c:78]: Closing connection (call state)
Nov 21 16:57:21 olimpico_home pppd[11338]: Exit.

Смотрели на циске - все что видно это установление и разрыв
VPN сессии.

Есть идеи в чем трабла?

P.S.
На работе пробовали поднять VPN через SkyLink-модем (т.е. из
другой внешней сети).
Все работает, но поднимали из винды.

У коллеги есть предположение, что провайдер (Авангард, СПб)
может рубить VPN сессии.

Привет!

Допустим, что имеется N регулярных выражений.
Для простоты:
1) Не рассматриваем multi-line mode.
2) Считаем, что все регулярные выражения начинаются с 
маркера начала строки (^) и заканчиваются маркером
конца строки ($).

То есть рассматриваются выражения вида:
^abc.*(tcp|udp)[5-8].+$

Очевидно, что регулярные выражения 
^a.*$
и
^b.*$
порождают непересекающиеся множества строк.

Очевидно также, что регулярные выражения 
^a.*$
^aa.*$
^.*b$
задают множества строк, пересечение которых не пусто.
Например, строка "aaXXXb".

Задача заключается в том, чтобы имея N регулярных выражений:
1) Определить, пересекаются ли порождаемые ими множества строк.
2) Если пересекаются, то определить какие именно регулярные
выражения "конфликтуют" (результат можно представить в виде 
треугольной матрицы).

Есть ли готовые алгоритмы решения данной задачи?

Спасибо!

>>>

Привет!

Кто-нибудь может объяснить вот это:

host root@host[~]#netstat -na | head -n 2 | tail -n 1
Proto Recv-Q Send-Q Local Address               Foreign Address             State      
host root@host[~]#netstat -na | grep 9997
tcp        0      0 127.0.0.1:9997              127.0.0.1:9997              ESTABLISHED 
host root@host[~]#netstat -na | grep 9997
tcp        0     89 127.0.0.1:9997              127.0.0.1:9997              ESTABLISHED 
host root@host[~]#netstat -na | grep 9997
tcp        0    180 127.0.0.1:9997              127.0.0.1:9997              ESTABLISHED 
host root@host[~]#lsof | grep 9997
host root@host[~]#

Вообще ничего не понимаю.
Какое-то "циклическое" соединение, которое не пренадлежит
ни одному процессу.


Вот динамика изменения Send-Q:

host root@host[~]#for((i=0;i<15;i++)) do netstat -na | grep 9997 | awk '{print $3}' ; sleep 1 ; done
178
178
178
0
178
178
0
178
178
178
0
178
178
89
178
host root@host[~]#

То есть что-то явно происходит.

P.S.
Как мне рассказал коллега, проблему он увидел, когда наш демон
при старте грохнулся с сегфолтом.
Демон как раз и слушает на порту 9997.
Дальше к проблеме подключился я и увидел описанную выше картину.

>>>

На сервере develop у меня стоит apache.
Делаю telnet на 80 порт, немного жду и закрываю соединение 
вообще без передачи каких-либо данных.

olimpico_work ~ # telnet develop 80
Trying 192.168.70.201...
Connected to develop.
Escape character is '^]'.
^]quit

telnet> quit
Connection closed.
olimpico_work ~ # 


Вот что показывает при этом tcpdump на клиентской стороне:

olimpico_work ~ # tcpdump -i eth1 host develop and port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
11:23:44.187263 IP krivenok.41234 > develop.http: S 2779819717:2779819717(0) win 5840 <mss 1460,sackOK,timestamp 1348338 0,nop,wscale 7>
11:23:44.187387 IP develop.http > krivenok.41234: S 107518013:107518013(0) ack 2779819718 win 5792 <mss 1460,sackOK,timestamp 15521524 1348338,nop,wscale 2>
11:23:44.187423 IP krivenok.41234 > develop.http: . ack 1 win 46 <nop,nop,timestamp 1348338 15521524>


11:23:57.346185 IP krivenok.41234 > develop.http: F 1:1(0) ack 1 win 46 <nop,nop,timestamp 1349652 15521524>
11:23:57.346368 IP develop.http > krivenok.41234: F 1:1(0) ack 2 win 1448 <nop,nop,timestamp 15524815 1349652>
11:23:57.346405 IP krivenok.41234 > develop.http: . ack 2 win 46 <nop,nop,timestamp 1349652 15524815>

6 packets captured
6 packets received by filter
0 packets dropped by kernel
olimpico_work ~ # 


Вроде все правильно и логично - сначала 3-этапное установление
соединения, а затем его завершение.

При этом на сервере develop видел, что соединение установлено:

develop ~ # netstat -na | grep "70.198" | grep 80 
tcp        0      0 192.168.70.201:80       192.168.70.198:41234    ESTABLISHED 
develop ~ # 

Пока все хорошо.


А теперь делаем то же самое с сервером develop2 на котором тоже
стоит apache.

olimpico_work ~ # telnet develop2 80
Trying 192.168.70.205...
Connected to develop2.
Escape character is '^]'.
^]quit

telnet> quit
Connection closed.
olimpico_work ~ # 

Вот что показывает tcpdump:

olimpico_work ~ # tcpdump -i eth1 host develop2 and port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
11:30:53.644916 IP krivenok.49819 > develop2.http: S 2776473031:2776473031(0) win 5840 <mss 1460,sackOK,timestamp 1391155 0,nop,wscale 7>
11:30:53.645069 IP develop2.http > krivenok.49819: S 874752337:874752337(0) ack 2776473032 win 5792 <mss 1460,sackOK,timestamp 6177317 1391155,nop,wscale 7>
11:30:53.645104 IP krivenok.49819 > develop2.http: . ack 1 win 46 <nop,nop,timestamp 1391155 6177317>
11:30:57.245167 IP develop2.http > krivenok.49819: S 874752337:874752337(0) ack 2776473032 win 5792 <mss 1460,sackOK,timestamp 6177677 1391155,nop,wscale 7>
11:30:57.245214 IP krivenok.49819 > develop2.http: . ack 1 win 46 <nop,nop,timestamp 1391515 6177677,nop,nop,sack 1 {0:1}>
11:31:03.247796 IP develop2.http > krivenok.49819: S 874752337:874752337(0) ack 2776473032 win 5792 <mss 1460,sackOK,timestamp 6178277 1391515,nop,wscale 7>
11:31:03.247837 IP krivenok.49819 > develop2.http: . ack 1 win 46 <nop,nop,timestamp 1392114 6178277,nop,nop,sack 1 {0:1}>
11:31:15.255559 IP develop2.http > krivenok.49819: S 874752337:874752337(0) ack 2776473032 win 5792 <mss 1460,sackOK,timestamp 6179477 1392114,nop,wscale 7>
11:31:15.255603 IP krivenok.49819 > develop2.http: . ack 1 win 46 <nop,nop,timestamp 1393312 6179477,nop,nop,sack 1 {0:1}>
11:31:39.466169 IP develop2.http > krivenok.49819: S 874752337:874752337(0) ack 2776473032 win 5792 <mss 1460,sackOK,timestamp 6181897 1393312,nop,wscale 7>
11:31:39.466216 IP krivenok.49819 > develop2.http: . ack 1 win 46 <nop,nop,timestamp 1395728 6181897,nop,nop,sack 1 {0:1}>


11:31:46.678079 IP krivenok.49819 > develop2.http: F 1:1(0) ack 1 win 46 <nop,nop,timestamp 1396448 6181897>
11:31:46.678314 IP develop2.http > krivenok.49819: F 1:1(0) ack 2 win 46 <nop,nop,timestamp 6182618 1396448>
11:31:46.678353 IP krivenok.49819 > develop2.http: . ack 2 win 46 <nop,nop,timestamp 1396448 6182618>

14 packets captured
14 packets received by filter
0 packets dropped by kernel
olimpico_work ~ # 


При этом если смотреть на сервере, то соединение находится 
в состоянии SYNC_RECV:

develop2 EQ-scripts # netstat -na | grep "70.198" | grep 80
tcp        0      0 192.168.70.205:80       192.168.70.198:49819    SYN_RECV   
develop2 EQ-scripts # 


То есть обмен пакетов следующий:
-> SYN  
<- SYN/ACK
-> ACK
<- SYN/ACK
-> ACK
<- SYN/ACK
-> ACK
...
...

Насколько я понимаю состояние SYN_RECV говорит о том, что
получен SYN и отправлен SYN/ACK.
После получения ACK на SYN/ACK соединение должно перейти
из SYN_RECV в ESTABLISHED.
Но этого не происходит.
Такое ощущение, что TCP сервера вообще не получает последний
ACK и поэтому постоянно перепосылает SYN/ACK клиенту.
На что клиент честно отвечает ACK'ом как показано выше.

В чем может быть проблема?

P.S.

Я запустил tcpdump и на сервере (все то же самое, только
номера эфемерных портов другие):

develop2 EQ-scripts # tcpdump -i eth0 host 192.168.70.198 and port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
11:44:40.458868 IP krivenok.internal.44560 > develop2.http: S 896196718:896196718(0) win 5840 <mss 1460,sackOK,timestamp 1473788 0,nop,wscale 7>
11:44:40.461384 IP develop2.http > krivenok.internal.44560: S 959167485:959167485(0) ack 896196719 win 5792 <mss 1460,sackOK,timestamp 6260093 1473788,nop,wscale 7>
11:44:40.459054 IP krivenok.internal.44560 > develop2.http: . ack 1 win 46 <nop,nop,timestamp 1473788 6260093>
11:44:44.255015 IP develop2.http > krivenok.internal.44560: S 959167485:959167485(0) ack 896196719 win 5792 <mss 1460,sackOK,timestamp 6260473 1473788,nop,wscale 7>
11:44:44.255231 IP krivenok.internal.44560 > develop2.http: . ack 1 win 46 <nop,nop,timestamp 1474167 6260473,nop,nop,sack 1 {0:1}>
11:44:50.257519 IP develop2.http > krivenok.internal.44560: S 959167485:959167485(0) ack 896196719 win 5792 <mss 1460,sackOK,timestamp 6261073 1474167,nop,wscale 7>
11:44:50.257738 IP krivenok.internal.44560 > develop2.http: . ack 1 win 46 <nop,nop,timestamp 1474766 6261073,nop,nop,sack 1 {0:1}>
11:45:03.592464 IP develop2.http > krivenok.internal.44560: S 959167485:959167485(0) ack 896196719 win 5792 <mss 1460,sackOK,timestamp 6262273 1474766,nop,wscale 7>
11:45:03.592679 IP krivenok.internal.44560 > develop2.http: . ack 1 win 46 <nop,nop,timestamp 1475963 6262273,nop,nop,sack 1 {0:1}>
11:45:27.794962 IP develop2.http > krivenok.internal.44560: S 959167485:959167485(0) ack 896196719 win 5792 <mss 1460,sackOK,timestamp 6264693 1475963,nop,wscale 7>
11:45:27.795178 IP krivenok.internal.44560 > develop2.http: . ack 1 win 46 <nop,nop,timestamp 1478379 6264693,nop,nop,sack 1 {0:1}>
11:45:38.087399 IP krivenok.internal.44560 > develop2.http: F 1:1(0) ack 1 win 46 <nop,nop,timestamp 1479406 6264693>
11:45:38.087487 IP develop2.http > krivenok.internal.44560: F 1:1(0) ack 2 win 46 <nop,nop,timestamp 6265722 1479406>
11:45:38.087688 IP krivenok.internal.44560 > develop2.http: . ack 2 win 46 <nop,nop,timestamp 1479406 6265722>
^C
14 packets captured
38 packets received by filter
0 packets dropped by kernel
develop2 EQ-scripts # 


Видно, что ACK приходит.

>>>