Назад | Перейти на главную страницу

CouchDB / xulrunner зависает в Ubuntu 10.04 LTS

У меня есть установка Ubuntu 10.04 LTS в качестве сервера Chef. Все работало нормально до первой перезагрузки компьютера, после чего произошли следующие три (возможно, не связанные) вещи:

Я считаю, что проблема с обновлением была вызвана этой ошибкой: https://bugs.launchpad.net/ubuntu/+source/xulrunner-1.9.2/+bug/680570, где обновление xulrunner вызывает зависание. Мне удалось обойти это, восстановив приставку из более ранней резервной копии (которую мы назовем резервной A), остановив весь процесс Chef и couchdb, установив xulrunner-dev; установка всех оставшихся обновлений, а затем запуск все заново. В этот момент и Шеф-повар, и Кушетка работали нормально. В этом «рабочем» состоянии я сделал резервную копию коробки, которую мы назовем резервной B.

Однако, несмотря на то, что коробка работала, попытка запустить status / restart / stop через. служба couchdb снова вызвала зависание - нет вывода. Когда я перезагрузил ящик, CouchDB не запустился, и снова service couchdb start просто зависает. Затем я восстановил ящик из резервной копии B, но при загрузке CouchDB не запускается - те же проблемы. Ничего не добавляется в файл журнала couchdb и не выводится, если я запускаю команду вручную.

В текущем состоянии у меня есть:

Если я сбегу strace /usr/bin/couchdb последние несколько строк вывода:

stat("/var/lib/couchdb", {st_mode=S_IFDIR|0770, st_size=4096, ...}) = 0
stat(".", {st_mode=S_IFDIR|0770, st_size=4096, ...}) = 0
open("/usr/bin/couchdb", O_RDONLY)      = 3
fcntl(3, F_DUPFD, 10)                   = 10
close(3)                                = 0
fcntl(10, F_SETFD, FD_CLOEXEC)          = 0
rt_sigaction(SIGINT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGINT, {0x408189, ~[RTMIN RT_1], SA_RESTORER, 0x7f2a7ba7caf0}, NULL, 8) = 0
rt_sigaction(SIGQUIT, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER, 0x7f2a7ba7caf0}, NULL, 8) = 0
rt_sigaction(SIGTERM, NULL, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGTERM, {SIG_DFL, ~[RTMIN RT_1], SA_RESTORER, 0x7f2a7ba7caf0}, NULL, 8) = 0
read(10, "#! /bin/sh -e\n\n# Licensed under "..., 8192) = 8192
pipe([3, 4])                            = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,  child_tidptr=0x7f2a7c2069d0) = 1463
close(4)                                = 0
read(3,

... а потом зависает.

Если я сбегу strace xulrunner --gre-version последние несколько строк вывода:

open("/proc/cpuinfo", O_RDONLY)         = 3
mmap(NULL, 16384, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =     0x7feeee879000
open("/etc/ld.so.cache", O_RDONLY)      = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=33168, ...}) = 0
mmap(NULL, 33168, PROT_READ, MAP_PRIVATE, 4, 0) = 0x7feeee84b000
munmap(0x7feeee84b000, 33168)           = 0
close(4)                                = 0
futex(0x7feeec0760ec, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0x7feeeea980a0, FUTEX_WAIT_PRIVATE, 2, NULL

... а потом зависает.

Я также пробовал:

Любая помощь приветствуется.

В конце концов я понял, что это был другой пакет в этой системе, вызывающий конфликт с xulrunner. Восстановление коробки без конфликтующего пакета решило проблему.

Несколько месяцев назад у меня была странная проблема с сервером шеф-повара, которая была решена путем проверки разрешений на / var / log / chef и / var / run / chef или что-то в этом роде, чтобы убедиться, что различные процессы шеф-повара действительно могут писать в этих каталоги. При запуске службы было очевидное зависание на несколько минут, а затем произошла ошибка.