Как получить информацию о завершении печати через cups-pdf, либо узнать что формируемый им pdf-файл не занят никаким процессом?
Доброго дня,
Подскажите, как получить информацию о завершении печати при печати в файл через cups-pdf, либо узнать о завершении печати когда формируемый pdf-файл "освобождается", т.е. он больше не занят никаким процессом?
Пояснение к вопросу:
Есть терминальный сервер с CentOS и клиенты с разными ОС: debian, windows XP, windows 7. Подключение через NX-Client. Чтобы печатать из ПО, запускаемого на сервере, на клиент с windows, требуется либо установить драйвера принтеров на сервер либо искать альтернативу.
Выбранный нами альтернативный способ заключается в следующем.
- на сервере установлен cups-pdf,
- монтируем общесетевой ресурс на windows-машине 10.*.*.IPwprinter в /mnt/wprint (Используем имеющийся сервер с windows. Здесь конечно возможны варианты с монтированием либо можно сделать общедоступным в сети каталог CentOS и т.п. но это уже вопросы оптимизации за рамками темы.)
- создаём каталог /mnt/wprint/[user]/PDF для каждого пользователя, где [user] - имя пользователя (пользователей около 100, одновременно могут работать до 50-60).
- в настройках cups-pdf прописано помещать создаваемые файлы в каталог /mnt/wprint/[user]/PDF
- тот же каталог находящийся на windows-сервере монтируется на каждом windows-клиенте таким образом: Подключаем сетевой диск как P: с адресом в сети 10.*.*.IPwprinter[user]
- в 10.*.*.IPwprinter[user] помещаем скрипт pdf-print.bat (о нём ниже)
- на каждом windows-клиенте запускаем скрипт P:pdf-print.bat
- на каждом клиенте установлен foxit -reader, который может выводить на печать pdf из командной строки, а значит, есть возможность просто вывести на печать любой pdf-файл из скрипта.
- скрипт делает следующее: раз в секунду проверяет наличие файла в каталоге P:PDF, при его наличии делает паузу 3 секунды, выводит на печать, удаляет файл. (варианты и возможные проблемы печати пока пропускаем, они решаемые все кроме задержки).
Как это работает: при выводе документа на печать cups-pdf формирует pdf-файл, который автоматически попадает в нужный каталог на windows-сервере, а соответствующий данному [user] клиент имеет на борту запущенный скрипт, который раз в секунду проверяет наличие файлов в этом каталоге, и выводит на печать при его наличии.
Вот здесь возникает проблема: linux никаким образом не резервирует файл, не ставит какую-то отметку что файл занят и т.п. Поэтому скрипт не знает, когда файл готов к печати а когда нет. Если вывести на печать неготовый файл, он не распечатается, foxit выдаст ошибку типа 'pdf повреждён'. Такое может случиться в случае печати многостраничного документа, когда его формирование занимает какое-то продолжительное время, или если момент создания файла совпадает с моментом его поиска скриптом, или просто при большой нагруженности сети или сервера.
Чтобы исключить эту проблему, искусственно вводится задержка в скрипте, эта задержка резко снижает процен ошибок, но она проблему не решает, и вообще это неправильный способ.
Если документ имеет 1-2 страницы, это работает. если 20-30 - приходится увеличивать задержку, если больше- это вообще нереально. величина 3 секунды подобрано экспериментально и с запасом, чтобы система работала без сбоев для документов менее 3 страниц.
Прошу подсказать решение проблемы.
Решением проблемы было бы сообщение от cups что печать задания такого-то завершена, либо чёткое указание того, что файл ещё занят, чтобы не печатать его пока его формирование не закончится.
Информацию о завершении печати можно попробовать получить, например, если включить режим лога cups "разработка", тогда в лог пишется абсолютно вся информация, и вытаскивать её оттуда ещё каким-то скриптом в CentOS, например через tail искать появление сообщений о завершении печати, и определять пользователя к которому оно относится, и т.п.... но этот вариант- это костыли похлеще всей этой системы вцелом.
Ещё вариант, проверять каким-то образом, что файл занят, скриптом на CentOS. Подскажите, как это сделать. Я вообще сомневаюсь что cups как-то это указывает, файл может открываться на дополнение, чтобы кусками добавлять в него информацию, т.е. не будет занят постоянно.
Подскажите, как получить информацию о завершении печати при печати в файл через cups-pdf, либо узнать о завершении печати когда формируемый pdf-файл "освобождается", т.е. он больше не занят никаким процессом?
Пояснение к вопросу:
Есть терминальный сервер с CentOS и клиенты с разными ОС: debian, windows XP, windows 7. Подключение через NX-Client. Чтобы печатать из ПО, запускаемого на сервере, на клиент с windows, требуется либо установить драйвера принтеров на сервер либо искать альтернативу.
Выбранный нами альтернативный способ заключается в следующем.
- на сервере установлен cups-pdf,
- монтируем общесетевой ресурс на windows-машине 10.*.*.IPwprinter в /mnt/wprint (Используем имеющийся сервер с windows. Здесь конечно возможны варианты с монтированием либо можно сделать общедоступным в сети каталог CentOS и т.п. но это уже вопросы оптимизации за рамками темы.)
- создаём каталог /mnt/wprint/[user]/PDF для каждого пользователя, где [user] - имя пользователя (пользователей около 100, одновременно могут работать до 50-60).
- в настройках cups-pdf прописано помещать создаваемые файлы в каталог /mnt/wprint/[user]/PDF
- тот же каталог находящийся на windows-сервере монтируется на каждом windows-клиенте таким образом: Подключаем сетевой диск как P: с адресом в сети 10.*.*.IPwprinter[user]
- в 10.*.*.IPwprinter[user] помещаем скрипт pdf-print.bat (о нём ниже)
- на каждом windows-клиенте запускаем скрипт P:pdf-print.bat
- на каждом клиенте установлен foxit -reader, который может выводить на печать pdf из командной строки, а значит, есть возможность просто вывести на печать любой pdf-файл из скрипта.
- скрипт делает следующее: раз в секунду проверяет наличие файла в каталоге P:PDF, при его наличии делает паузу 3 секунды, выводит на печать, удаляет файл. (варианты и возможные проблемы печати пока пропускаем, они решаемые все кроме задержки).
Как это работает: при выводе документа на печать cups-pdf формирует pdf-файл, который автоматически попадает в нужный каталог на windows-сервере, а соответствующий данному [user] клиент имеет на борту запущенный скрипт, который раз в секунду проверяет наличие файлов в этом каталоге, и выводит на печать при его наличии.
Вот здесь возникает проблема: linux никаким образом не резервирует файл, не ставит какую-то отметку что файл занят и т.п. Поэтому скрипт не знает, когда файл готов к печати а когда нет. Если вывести на печать неготовый файл, он не распечатается, foxit выдаст ошибку типа 'pdf повреждён'. Такое может случиться в случае печати многостраничного документа, когда его формирование занимает какое-то продолжительное время, или если момент создания файла совпадает с моментом его поиска скриптом, или просто при большой нагруженности сети или сервера.
Чтобы исключить эту проблему, искусственно вводится задержка в скрипте, эта задержка резко снижает процен ошибок, но она проблему не решает, и вообще это неправильный способ.
Если документ имеет 1-2 страницы, это работает. если 20-30 - приходится увеличивать задержку, если больше- это вообще нереально. величина 3 секунды подобрано экспериментально и с запасом, чтобы система работала без сбоев для документов менее 3 страниц.
Прошу подсказать решение проблемы.
Решением проблемы было бы сообщение от cups что печать задания такого-то завершена, либо чёткое указание того, что файл ещё занят, чтобы не печатать его пока его формирование не закончится.
Информацию о завершении печати можно попробовать получить, например, если включить режим лога cups "разработка", тогда в лог пишется абсолютно вся информация, и вытаскивать её оттуда ещё каким-то скриптом в CentOS, например через tail искать появление сообщений о завершении печати, и определять пользователя к которому оно относится, и т.п.... но этот вариант- это костыли похлеще всей этой системы вцелом.
Ещё вариант, проверять каким-то образом, что файл занят, скриптом на CentOS. Подскажите, как это сделать. Я вообще сомневаюсь что cups как-то это указывает, файл может открываться на дополнение, чтобы кусками добавлять в него информацию, т.е. не будет занят постоянно.