Проблема с переходом из ai в ui

[GoogleCodeExporter]

Обновил до XVB - VirtualPBX v.3, build: 8645
до этого проблемы не наблюдалось.
Захожу в ai хочу перейти в Tenants в меню 
пользователя, как раньше жму на ссылку она 
же Access code а он мне входит через раз, то пишет 
что
  Incorrect access code/password pair, try again

Original issue reported on code.google.com by ad...@elgorsk.ru on 11 Oct 2014 at 9:29

[GoogleCodeExporter]

/opt/VirtualPBX/contrib/utils/Memcached.pl 
и 
xvb-ctl reload

сказать.

Original comment by igor.oku...@gmail.com on 11 Oct 2014 at 9:35

[GoogleCodeExporter]

либо совсем кардинально в xvb.conf
CACHE_WEB_AUTH=0

и апачь рестартовать

Original comment by igor.oku...@gmail.com on 11 Oct 2014 at 9:38

[GoogleCodeExporter]

перезагрузка точно не помогает, если и 
помогает то только на 1 раз, потом опять 
ошибка.
поставил 
CACHE_WEB_AUTH=0
в xvb.cfg
Не помогло, теперь переходит, открывает 
ифрейм на две части, и в каждом пишет логин 
и пасс

Original comment by ad...@elgorsk.ru on 11 Oct 2014 at 9:50

[GoogleCodeExporter]

tail -10 /var/log/VirtualPBX/XVB.stderr что то говорит ?

Original comment by igor.oku...@gmail.com on 11 Oct 2014 at 9:53

[GoogleCodeExporter]

база вообще работает ?

Original comment by igor.oku...@gmail.com on 11 Oct 2014 at 9:57

[GoogleCodeExporter]

база работает, но почему то стала падать 
она и сам астериск...

Original comment by ad...@elgorsk.ru on 11 Oct 2014 at 10:08

[GoogleCodeExporter]

 OOM ?

Original comment by igor.oku...@gmail.com on 11 Oct 2014 at 10:19

[GoogleCodeExporter]

в логе том
Sat Oct 11 06:04:53 EDT 2014
Unable to connect to remote asterisk (does /var/run/asterisk.ctl exist?)
ended with exit status 137
XVB perl worker exited on signal EXITSTATUS-128.
Automatically restarting XVB perl worker.
Sat Oct 11 06:05:01 EDT 2014
Unable to connect to remote asterisk (does /var/run/asterisk.ctl exist?)
ended with exit status 137
XVB perl worker exited on signal EXITSTATUS-128.
Automatically restarting XVB perl worker.

база с такими записямы падает
1011 05:49:16 mysqld_safe mysqld from pid file /var/run/mysqld/mysqld.pid ended
141011 05:52:01 mysqld_safe Starting mysqld daemon with databases from 
/var/lib/mysql
141011  5:52:01  InnoDB: Initializing buffer pool, size = 8.0M
141011  5:52:01  InnoDB: Completed initialization of buffer pool
InnoDB: Log scan progressed past the checkpoint lsn 0 89974705
141011  5:52:01  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Doing recovery: scanned up to log sequence number 0 89974715
141011  5:52:01  InnoDB: Started; log sequence number 0 89974715
141011  5:52:01 [Note] Event Scheduler: Loaded 0 events
141011  5:52:01 [Note] /usr/libexec/mysqld: ready for connections.
Version: '5.1.73'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  Source 
distribution
141011  6:07:32 [Note] /usr/libexec/mysqld: Normal shutdown

Original comment by ad...@elgorsk.ru on 11 Oct 2014 at 11:04

[GoogleCodeExporter]

наврядли это связано с апдейтом. надо 
смотреть что происходит в системе.

Original comment by igor.oku...@gmail.com on 11 Oct 2014 at 4:11

[GoogleCodeExporter]

да, что то с БД, почему то начала падать, 
буду разбиратся, но началось как я и сказал, 
после обновления и изменения параметров 
виртуалки (с 1МБ рам и 4 своп, на 128мб рам и 64 
своп) Сейчас проверяю на 128рам и 256своп

Original comment by ad...@elgorsk.ru on 12 Oct 2014 at 6:11

[GoogleCodeExporter]

128 mb рама это ОЧЕНЬ мало.

Original comment by igor.oku...@gmail.com on 12 Oct 2014 at 9:17

[GoogleCodeExporter]

Original comment by igor.oku...@gmail.com on 14 Oct 2014 at 1:34

• Changed state: Invalid