Новые комментарии

    -да, ознакомление должно быть последовательным, т.е. дирректор допустим создает движения документа:

зам.дирректора->главный менеджер->менеджер->рабочий

после ознакомления зам.дирректора и отметки об ознакомлении документ поступает к главному менеджеру, далее от него к менеджеру, а от менеджера к рабочему

    -число участников постоянно

   -не важно, чтобы описанный маршрут был реализован только при помощи одного workflow

 Здравствуйте. У меня есть несколько вопросов по вашей задаче:

• ознакомление обязательно должно проходить последовательно?
• число участников процесса постоянно или меняется?
• важно, чтобы описанный выше маршрут был реализован при помощи только одного workflow?

Ничего не надо делать. Только перелогиниться. Максимум в конфиги pam'а один раз вписать то самое session required pam_limits.so, хотя оно и так должно быть по умолчанию (по крайней мере это так в Fedora/RHEL и их клонах).

Немного смущает "при входе как суперпользователь zenoss" - все-таки как root или как zenoss?

P.S. Первую строчку (* hard nofile 65000) лучше бы убрать - нет смысла ломать умолчания для всей системы.

 https://github.com/aviriel/Alfresco-Russian-Localization/

Есть установленная версия. Если лениво или негде поднять свою, можно смотреть здесь:

http://alfresco2.itd-systems.ru:8080/share

Логин: test

Пароль: test

А где же можно сказать бету?

Дайте пожалуйста ссылку...(и может есть инструкция по применению)))

Спасибо большущее за разъяснения.

С первым вариантом решения я пока маюсь, я изменила конфиг /etc/security/limits.conf:

* hard nofile 65000
zenoss soft nofile 60000
zenoss hard nofile 60000

Добавила строчку session required pam_limits.so в несколько файлов в каталоге /etc/pam.d/

А при входе как суперпользователь zenoss все равно имею лимит 1024.

Может что-то надо перерестартовать?

Если в двух словах - все нормально, не обращайте внимания. Минорный баг при переходе на MySQL 5.1 - на работе не сказывается, ругань в логах поправят в следующем обновлении. Ссылки на багзиллу MySQL - http://bugs.mysql.com/bug.php?id=30487 и http://bugs.mysql.com/bug.php?id=43829.

Ровно с вашей проблемой не сталкивался. Но вообще при ситуации вида "Too many open files" есть два варианта развития событий - или вам повезет, или нет. ) Если повезет - приложению (в данном случае Zenoss) нужно больше чем 1024 открытых дескрипторов, но это число какое-то разумное и конечное. В этом случае после увеличения лимита все будет работать хорошо. Такая ситуация встречается на самом деле часто. Если не повезет - в приложении (вряд ли Zenoss вообще, скорее отдельный сторонний Zenpack) действительно есть баг из-за которого файлы открываются, но потом не закрываются. В этом случае увеличение лимита поможет ненадолго, а для решения проблемы придется найти баг и думать что с ним делать.