Виртуальный X-server
Случается, что необходимо запустить программу, привязанную к использованию X-server. В подобных случаях может помочь пакет xvfb. Сценарий runit для запуска приведен ниже:
Есть один неприятный момент - иногда по необъяснимым причинам x-server перестает запускаться с указанным номером дисплея и удаление /tmp/.X11-unix не помогает.
Во избежание указанной проблемы предусмотрен "финт ушами", причем опции " -from localhost -nolisten tcp" уже не требуются, tcp-порт по умолчанию не открывается. В примере запускаю команды одновременно в двух разных консолях:
Как видим, теперь несколько экземпляров xvfb могут работать независимо, а автоматически назначенный номер дисплея мы получаем из переменной окружения DISPLAY.
Запуск иксов, даже виртуальных, занимает время порядка нескольких секунд, и потому неплохо будет сделать что-то вроде следующего:
И напоследок тест запуска openoffice.org на ноутбуке с процессором Core2Duo и 1 Gb RAM:
Кстати, в теории, используя cups-pdf принтер можно выводить любые документы "на печать" примерно вот так:
На практике не пробовал, поскольку лучше уж макрос на том самом встроенном бейсике написать, нежели CUPS на сервере ставить.
При необходимости см. документацию на опенофис здесь: Documents & files: Specifications
Upd.
При более внимательном чтении манов обнаружилось, что xvfb-run может запускаться практически мгновенно, используя ключик "-w 0", а по умолчанию стоит задержка 3 секунды (т.е. используется значение -w 3), что и было видно в тестах выше. Проверил "xvfb-run -w 0" - никаких проблем, все работает стабильно, и не очень понятно, зачем придумана эта задержка.
# cat /etc/sv/X/run
#!/bin/sh
export LANG="ru_RU.UTF8"
export HOME="/home/ooo"
exec 2>&1
exec chpst -u nobody:nogroup /usr/bin/Xvfb -screen 0 800x600x24 :10 \
-from localhost -nolisten tcp
Есть один неприятный момент - иногда по необъяснимым причинам x-server перестает запускаться с указанным номером дисплея и удаление /tmp/.X11-unix не помогает.
Во избежание указанной проблемы предусмотрен "финт ушами", причем опции " -from localhost -nolisten tcp" уже не требуются, tcp-порт по умолчанию не открывается. В примере запускаю команды одновременно в двух разных консолях:
$ xvfb-run --auto-servernum --server-args='-screen 0 640x480x8' sh -c "echo \$DISPLAY"
:99
$ xvfb-run --auto-servernum --server-args='-screen 0 640x480x8' sh -c "echo \$DISPLAY"
:100
Как видим, теперь несколько экземпляров xvfb могут работать независимо, а автоматически назначенный номер дисплея мы получаем из переменной окружения DISPLAY.
Запуск иксов, даже виртуальных, занимает время порядка нескольких секунд, и потому неплохо будет сделать что-то вроде следующего:
$ xvfb-run --auto-servernum --server-args='-screen 0 640x480x8' \
/usr/bin/tcpserver -R -H 127.0.0.1 3000 ./env@
$ http@ localhost /test 3000|grep DISPLAY
DISPLAY: :99
И напоследок тест запуска openoffice.org на ноутбуке с процессором Core2Duo и 1 Gb RAM:
$ time xvfb-run --auto-servernum --server-args='-screen 0 640x480x8' \
sh -c "soffice -invisible -headless -norestore \
\"macro:///MbgServer.Template.ConvertToPDF(/tmp/100.odt)\" \
-display \$DISPLAY -nologo"
real 0m6.021s
user 0m2.564s
sys 0m0.288s
Кстати, в теории, используя cups-pdf принтер можно выводить любые документы "на печать" примерно вот так:
soffice -invisible -headless -norestore -pt local /tmp/100.odt -nologo
На практике не пробовал, поскольку лучше уж макрос на том самом встроенном бейсике написать, нежели CUPS на сервере ставить.
При необходимости см. документацию на опенофис здесь: Documents & files: Specifications
Upd.
При более внимательном чтении манов обнаружилось, что xvfb-run может запускаться практически мгновенно, используя ключик "-w 0", а по умолчанию стоит задержка 3 секунды (т.е. используется значение -w 3), что и было видно в тестах выше. Проверил "xvfb-run -w 0" - никаких проблем, все работает стабильно, и не очень понятно, зачем придумана эта задержка.
Comments