LINUX.ORG.RU

Как получить информацию о завершении печати через cups-pdf, либо узнать что формируемый им pdf-файл не занят никаким процессом?

 , ,


0

1

Доброго дня, Подскажите, как получить информацию о завершении печати при печати в файл через cups-pdf, либо узнать о завершении печати когда формируемый pdf-файл «освобождается», т.е. он больше не занят никаким процессом?

Пояснение к вопросу:

Есть терминальный сервер с CentOS и клиенты с разными ОС: debian, windows XP, windows 7. Подключение через NX-Client. Чтобы печатать из ПО, запускаемого на сервере, на клиент с windows, требуется либо установить драйвера принтеров на сервер либо искать альтернативу. Выбранный нами альтернативный способ заключается в следующем.

1) на сервере установлен cups-pdf. 2) монтируем общесетевой ресурс на windows-машине 10...IP/wprinter в /mnt/wprint (Используем имеющийся сервер с windows. Здесь конечно возможны варианты с монтированием либо можно сделать общедоступным в сети каталог CentOS и т.п. но это уже вопросы оптимизации за рамками темы.) 3) создаём каталог /mnt/wprint/USERx/PDF для каждого пользователя, где USERx - имя пользователя (пользователей около 100, одновременно могут работать до 50-60). 4) в настройках cups-pdf прописано помещать создаваемые файлы в каталог /mnt/wprint/USERx/PDF 5) тот же каталог находящийся на windows-сервере монтируется на каждом windows-клиенте таким образом: Подключаем сетевой диск как P: с адресом в сети 10...IPwprinterUSERx 6) в 10...IP/wprinterUSERx помещаем скрипт pdf-print.bat (о нём ниже) 7) на каждом windows-клиенте запускаем скрипт P:\pdf-print.bat 8) на каждом клиенте установлен foxit -reader, который может выводить на печать pdf из командной строки, а значит, есть возможность просто вывести на печать любой pdf-файл из скрипта. 9) скрипт делает следующее: раз в секунду проверяет наличие файла в каталоге P:PDF, при его наличии делает паузу 3 секунды, выводит на печать, удаляет файл. (варианты и возможные проблемы печати пока пропускаем, они решаемые все кроме задержки). Итог) Как это работает: при выводе документа на печать cups-pdf формирует pdf-файл, который автоматически попадает в нужный каталог на windows-сервере, а соответствующий данному USERx клиент имеет на борту запущенный скрипт, который раз в секунду проверяет наличие файлов в этом каталоге, и выводит на печать при его наличии.

Вот здесь возникает проблема: linux никаким образом не резервирует файл, не ставит какую-то отметку что файл занят и т.п. Поэтому скрипт не знает, когда файл готов к печати а когда нет. Если вывести на печать неготовый файл, он не распечатается, foxit выдаст ошибку типа 'pdf повреждён'. Такое может случиться в случае печати многостраничного документа, когда его формирование занимает какое-то продолжительное время, или если момент создания файла совпадает с моментом его поиска скриптом, или просто при большой нагруженности сети или сервера. Чтобы исключить эту проблему, искусственно вводится задержка в скрипте, эта задержка резко снижает процен ошибок, но она проблему не решает, и вообще это неправильный способ. Если документ имеет 1-2 страницы, это работает. если 20-30 - приходится увеличивать задержку, если больше- это вообще нереально. величина 3 секунды подобрано экспериментально и с запасом, чтобы система работала без сбоев для документов менее 3 страниц.

Прошу подсказать решение проблемы. Решением проблемы было бы сообщение от cups что печать задания такого-то завершена, либо чёткое указание того, что файл ещё занят, чтобы не печатать его пока его формирование не закончится. Информацию о завершении печати можно попробовать получить, например, если включить режим лога cups «разработка», тогда в лог пишется абсолютно вся информация, и вытаскивать её оттуда ещё каким-то скриптом в CentOS, например через tail искать появление сообщений о завершении печати, и определять пользователя к которому оно относится, и т.п.... но этот вариант- это костыли похлеще всей этой системы вцелом. Ещё вариант, проверять каким-то образом, что файл занят, скриптом на CentOS. Подскажите, как это сделать. Я вообще сомневаюсь что cups как-то это указывает, файл может открываться на дополнение, чтобы кусками добавлять в него информацию, т.е. не будет занят постоянно.


В Windows есть команда 'net', а точнее

net file
Так вот эта команда выдаст список открытых по сети файлов. По сути в момент записи на сетевой ресурс pdf файла, созданного в cups-pdf файл открыт и будет виден в выводе указанной команды.

Т.к. скрипт всё равно запускается в фоне, если я правильно понял, на клиентах, т.е. есть смысл сделать по другому: запускать скрипт на windows сервере, пусть он ищет новые pdf файла и проверяет открыты они по сети или нет, если не открыты, то печатает. На windows сервер ставите foxitreader.

Либо можете предоставить каким-либо способом доступ к логам cups по сети и уже из скриптов на клиентах просматривать эти логи и искать в них информацию о заверешении печати в pdf принтере cups.

Как-то так.

Но лучше всё же попробуйте не костылять, а настроить нормальную печать на терминальном сервере, т.е. сразу на принтер.

kostik87 ★★★★★ ()
Ответ на: комментарий от kostik87

В данном варианте проверить что файл «не занят» не получается: поставил очень большой файл на несколько сотен страниц, чтобы подольше, и «печатал» через cups-pdf. Из-под винды в этот момент появившийся файл могу без проблем переименовать или даже удалить. Т.е. винда не видит, что файл кем-то открыт. А почему так, я не знаю. Возникают вопросы: Может ли CentOS видеть что файл занят? тогда можно скрипт запускать там или монтировать как-то по-другому чтобы винда видела. И вообще занимает ли cups-pdf формируемый им файл на всё время его формирования или просто периодически пачками дописывает в него информацию? Если не занимает, тогда никто не увидит что файл занят. Тогда только брать данные из CUPS каким-то образом.

Не костылять не получается, все принтера разные и пока не все удалось завести под CentOS или вообще под линуксом. и времени отнимает много. Если ного одинаковых принтеров- можно потратить 1 раз время и решить, но с каждой моделью отдельно возиться затруднительно.

Был вариант через протокол LPD (и на винде доустановить «печать UNIX») , на тестовом Debian работает, но не идёт почему-то на нашем сервере. Даже какой-то спец грамотный подключался смотрел дня 2 но не нашёл причину. Тогда и стали костыли искать. И с PDF по сути вроде тоже просто должно быть а вот нет.

BP ()

«Печатай» на сервере во временную директорию, а в пользовательскую переноси уже сформированный файл. Man inotify пригодится. Клиентскую часть можно будет оставить без изменений.

P.S.: у тебя велосипед из костылей, смотанных синей изолентой)))

dhameoelin ★★★★★ ()
Ответ на: комментарий от dhameoelin

Хотел написать, что cups-pdf тоже так умеет, но потом вспомнил, что он (gs) читает задание из одного места, а pdf пишет сразу в другое.

Хотя там есть такое:

### Key: GSCall
## command line for calling GhostScript (!!! DO NOT USE NEWLINES !!!)
По идее туда можно дописать
&& mv %s /my/cool/dir/`basename %s`

Radjah ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.