CUPS – ວິທີແກ້ໄຂບັນຫາການພິມ

Brandon Nielsen, Zdenek Dohnal Version F35 onwards Last review: 2022-02-10

ຖ້າທ່ານກຳລັງປະສົບບັນຫາກັບການພິມ, ກະລຸນາເບິ່ງທີ່ໜ້າ common bugs ກ່ອນທີ່ຈະແຈ້ງ bug. ຖ້າບັນຫາທີ່ທ່ານພົບບໍ່ມີລາຍຊື່ຢູ່ໃນນັ້ນ ຫຼື ບໍ່ມີວິທີແກ້ໄຂໃດທີ່ຊ່ວຍໄດ້, ກະລຸນາພິຈາລະນາ ການແຈ້ງລາຍງານ bug ເພື່ອຊ່ວຍໃຫ້ພວກເຮົາເຮັດໃຫ້ Fedora ເຮັດວຽກໄດ້ດີຂຶ້ນໃນຮາດແວຂອງທ່ານ.

ການລະບຸພື້ນທີ່ຂອງບັນຫາ

ບັນຫາການພິມສາມາດມີຄວາມຊັບຊ້ອນສົມຄວນ ແລະ ຜູ້ດູແລອາດຈະຮ້ອງຂໍຄວາມຮ່ວມມືຢ່າງຫ້າວຫັນ ຫຼື ຂໍ້ມູນຈຳນວນຫຼາຍຈາກຜູ້ລາຍງານ ເພື່ອຊ່ວຍໃຫ້ຜູ້ດູແລຢ່າງໜ້ອຍກໍເຂົ້າໃຈ ແລະ (ຖ້າບໍ່ແມ່ນບັນຫາສະເພາະຂອງຮາດແວ) ສາມາດສ້າງບັນຫາຄືນໃໝ່ໄດ້, ດັ່ງນັ້ນ ກະລຸນາຈົ່ງມີຄວາມອົດທົນ ແລະ ພະຍາຍາມຈຳກັດຂອບເຂດຂອງບັນຫາໃຫ້ແຄບລົງເທົ່າທີ່ຈະເຮັດໄດ້ເພື່ອຜູ້ດູແລ.

ອາດຈະມີ:

ບັນຫາໃນການເບິ່ງເຫັນ ຫຼື ການເຊື່ອມຕໍ່ກັບເຄື່ອງພິມ (ອາດເປັນບັນຫາຂອງ cups backend, ບັນຫາ avahi, ບັນຫາ libusb, ຫຼື ບັນຫາ cups-browsed),
ບັນຫາການເຂົ້າເຖິງ (ການຕັ້ງຄ່າທີ່ຖືກຕ້ອງ/ຜິດພາດໃນ cupsd.conf ຫຼື ການຕີຄວາມໝາຍທີ່ບໍ່ດີໂດຍ cupsd daemon, ການເຮັດວຽກຮ່ວມກັບ NIS, SSSD ທີ່ບໍ່ດີ…),
ການພິມດ້ວຍການຊ່ວຍເຫຼືອຂອງ samba (ບັນຫາກັບ smb backend, ເຊິ່ງເປັນສ່ວນໜຶ່ງຂອງ samba) ຫຼື ກັບ samba ທີ່ຜ່ານການຢືນຢັນຕົວຕົນດ້ວຍ Kerberos (samba_krb5_printing),
ບັນຫາກັບຕົວຕອງ (filters) ທີ່ໃຊ້ໃນລະຫວ່າງການປ່ຽນຮູບແບບເອກະສານໃຫ້ເປັນຮູບແບບທີ່ເຄື່ອງພິມຮອງຮັບ, ເຊິ່ງມີຜົນຕໍ່ວິທີການ ຫຼື ການທີ່ເອກະສານຈະຖືກພິມອອກມາຫຼືບໍ່ (ບັນຫາກັບ filters - pdftops, pdftopdf, pstops, bannertopdf ແລະ ອື່ນໆ - ຫຼື ບັນຫາກັບໄຟລ໌ binary ຫຼື library ທີ່ filters ໃຊ້ - libgs, qpdf, poppler…),
ບັນຫາກັບໄຟລ໌ Postscript Printer Description (PPD), ເຊິ່ງເປັນວິທີເກົ່າໃນການກຳນົດຄວາມສາມາດຂອງເຄື່ອງພິມ ເຊັ່ນ: ຂະໜາດເຈ້ຍທີ່ຮອງຮັບ, ຂອບເຈ້ຍ ແລະ ອື່ນໆ…

ຍັງບໍ່ໄດ້ກ່າວເຖິງຂໍ້ຈຳກັດ ຫຼື ບັນຫາທີ່ອາດມີໃນເຟີມແວ (firmware) ຫຼື ຮາດແວຂອງເຄື່ອງພິມເອງ, ດັ່ງນັ້ນ ຂໍ້ມູນປະເພດໃດກໍຕາມ ຫຼື ການຈຳກັດຂອບເຂດບັນຫາແມ່ນເປັນປະໂຫຍດຫຼາຍ.

ການເລີ່ມຕົ້ນທີ່ດີທີ່ສຸດແມ່ນການແນບໄຟລ໌ບັນທຶກ (logs) ທີ່ອະທິບາຍໄວ້ຂ້າງລຸ່ມນີ້.

ການບັນທຶກ CUPS

ການບັນທຶກ CUPS ທັງໝົດຈະຖືກປ່ຽນທິດທາງໄປຫາ journal ໂດຍຄ່າເລີ່ມຕົ້ນຕັ້ງແຕ່ Fedora 28 ເປັນຕົ້ນມາ (ກ່ອນ Fedora 28 ແມ່ນມີການປ່ຽນທິດທາງຂອງ error_log ໄປຫາ journal ໂດຍຄ່າເລີ່ມຕົ້ນ).

ພວກເຮົາຈຳເປັນຕ້ອງກຳນົດສອງວິທີທີ່ແຕກຕ່າງກັນໃນການເກັບບັນທຶກ CUPS ທັງໝົດທີ່ກ່ຽວຂ້ອງກັບເຫດການ - ວິທີໜຶ່ງແມ່ນຖ້າຄິວການພິມທີ່ເສຍນັ້ນບໍ່ໄດ້ມາຈາກ HPLIP ແລະ ອີກວິທີໜຶ່ງແມ່ນຖ້າແມ່ນມາຈາກ HPLIP. ພວກມັນແຕກຕ່າງກັນໃນຕົວເລືອກ filter ຂອງ journald - ຖ້າທ່ານໃຊ້ຄິວທີ່ບໍ່ແມ່ນ HPLIP ສຳລັບການ debug, ມັນກໍເປັນການດີທີ່ຈະເກັບກຳບັນທຶກຈາກ cups systemd unit (ໂດຍໃຊ້ '-u cups'), ເພາະວ່າຂໍ້ຄວາມຜິດພາດທັງໝົດຈະຖືກປ່ຽນທິດທາງໄປຫາ cups systemd unit logging ຢ່າງຖືກຕ້ອງ ແລະ ສາມາດເຂົ້າເຖິງໄດ້ໃນ output ຫຼັງຈາກການກອງ unit. ສ່ວນ library ຂອງ HPLIP ບໍ່ໄດ້ຖືກອອກແບບມາໃຫ້ເຮັດແບບດຽວກັນ (ທາງຕົ້ນນ້ຳບໍ່ຕອບສະໜອງຕໍ່ການຮັບເອົາການແກ້ໄຂເຂົ້າໃນໂຄງການ ແລະ ບັນຫາກໍບໍ່ໄດ້ຮ້າຍແຮງພໍທີ່ຈະຕ້ອງໃຊ້ downstream patch ຕະຫຼອດໄປ), ດັ່ງນັ້ນຂໍ້ຄວາມຂອງພວກມັນຈຶ່ງບໍ່ໄດ້ຖືກໝາຍໄວ້ສຳລັບ cups systemd unit ແລະ ພວກມັນຈະຖືກກອງອອກຫຼັງຈາກເອີ້ນ journald ດ້ວຍ '-u cups'. ສຳລັບຄິວດັ່ງກ່າວ, ຈຳເປັນຕ້ອງໃຊ້ບັນທຶກ journald ແບບບໍ່ມີການກອງ.

ບັນທຶກ journald ທີ່ກ່ຽວຂ້ອງກັບເຫດການແບບບໍ່ມີການກອງແມ່ນຈຳເປັນສະເພາະສຳລັບຄິວການພິມ HPLIP (device uri ຂອງພວກມັນເລີ່ມຕົ້ນດ້ວຍ hp://) ແລະ ບໍ່ແນະນຳໃຫ້ໃຊ້ສຳລັບຄິວອື່ນໆ ເພາະມັນອາດຈະອ່ານຍາກໃນກໍລະນີທີ່ມີຂໍ້ມູນຫຼາຍ. ກະລຸນາແນບບັນທຶກ journald ທີ່ກ່ຽວຂ້ອງກັບເຫດການເມື່ອຈຳເປັນເທົ່ານັ້ນ.

ສະຖານທີ່ເກັບບັນທຶກ CUPS

ໂດຍຄ່າເລີ່ມຕົ້ນ ບັນທຶກ CUPS ຈະຢູ່ໃນ system journal, ແຕ່ສາມາດຕັ້ງຄ່າການບັນທຶກລົງໃນໄຟລ໌ໄດ້ໃນ /etc/cups/cups-files.conf ດ້ວຍຄຳສັ່ງ ErrorLog. ຖ້າທ່ານຕ້ອງການປ່ຽນການຕັ້ງຄ່າເລີ່ມຕົ້ນ, ຊື່ຂອງໄຟລ໌ບັນທຶກຈະເປັນແນວໃດກໍໄດ້, ແຕ່ແນະນຳໃຫ້ເກັບໄຟລ໌ໄວ້ໃນເສັ້ນທາງ /var/log/cups, ຖ້າບໍ່ດັ່ງນັ້ນ SELinux ຈະປິດກັ້ນບໍ່ໃຫ້ cupsd ເຂົ້າເຖິງມັນໄດ້.

ການຕັ້ງຄ່າການບັນທຶກລົງໃນໄຟລ໌ມີຂໍ້ເສຍດັ່ງນີ້ (ຖ້າບໍ່ມີການຈັດການເພີ່ມເຕີມ):

ບໍ່ສາມາດດຶງເອົາສະເພາະບັນທຶກທີ່ກ່ຽວຂ້ອງກັບວຽກໃດໜຶ່ງໄດ້ ໂດຍບໍ່ຕ້ອງໃຊ້ຫຼາຍຄຳສັ່ງຕໍ່ກັນ
ບໍ່ສາມາດດຶງເອົາບັນທຶກຕາມຊ່ວງເວລາທີ່ກຳນົດໄດ້ ໂດຍບໍ່ຕ້ອງໃຊ້ຫຼາຍຄຳສັ່ງຕໍ່ກັນ

ສຳລັບການເກັບບັນທຶກທີ່ກ່ຽວຂ້ອງກັບເຫດການ ສາມາດໃຊ້ tail -f ໄດ້ ເຊັ່ນ:

$ tail -f /var/log/cups/error_log

ເປີດໃຊ້ງານການບັນທຶກ debug ຂອງ CUPS

ເປີດໃຊ້ງານຂໍ້ມູນການແກ້ໄຂຈຸດບົກພ່ອງແບບເຕັມຮູບແບບດ້ວຍ:

$ cupsctl LogLevel=debug2

ບັນທຶກວຽກຂອງ CUPS

ຖ້າບັນຫາເກີດຂຶ້ນເມື່ອທ່ານສົ່ງເອກະສານໄປພິມ ຫຼື ໃນຂະນະທີ່ພະຍາຍາມຈະພິມ, ໃຫ້ເກັບບັນທຶກສຳລັບວຽກນີ້. ຖ້າມີບັນທຶກຂອງວຽກ (job log), ການແນບມັນແມ່ນ ຈຳເປັນຢ່າງຍິ່ງ.

ກຽມ CUPS ສຳລັບການບັນທຶກວຽກ

ເພື່ອໃຫ້ສາມາດເບິ່ງບັນທຶກຂອງວຽກສະເພາະໃດໜຶ່ງໄດ້, ກະລຸນາເປີດ:

PreserveJobFiles Yes

ໃນໄຟລ໌ /etc/cups/cupsd.conf ຂອງທ່ານ ແລະ ເລີ່ມຕົ້ນບໍລິການ cups ໃໝ່. ຢ່າລືມລຶບບັນທັດນີ້ອອກຫຼັງຈາກທີ່ທ່ານແກ້ໄຂບັນຫາສຳເລັດແລ້ວ. lpstat -W all ອາດຈະສະແດງເປັນຄ່າວ່າງຫຼັງຈາກການພິມ ຖ້າທ່ານບໍ່ໄດ້ເປີດໃຊ້ງານຄຳສັ່ງນີ້.

ດຶງຂໍ້ມູນບັນທຶກວຽກສຳລັບ Job ID ສະເພາະ

ເພື່ອເກັບບັນທຶກວຽກ ທ່ານຈຳເປັນຕ້ອງຮູ້ Job ID (JID) ຂອງວຽກນັ້ນ - ມັນຄືຕົວເລກທີ່ຢູ່ຫຼັງເຄື່ອງໝາຍຂີດໃນ request ID:

Request ID ຈະມີລັກສະນະແບບນີ້:

<print_queue_name>-<JID>

ແລະ ສາມາດເຫັນໄດ້ໃນ terminal ຖ້າທ່ານສົ່ງເອກະສານໄປພິມດ້ວຍຄຳສັ່ງ lp:

$ lp -d <print_queue_name> <file1> ... <fileN>
request id is <print_queue_name>-<JID> (N file(s))

ຫຼື ເມື່ອທ່ານສະແດງລາຍຊື່ວຽກ (ເບິ່ງ man lpstat) - ວຽກຫຼ້າສຸດຈະຢູ່ທ້າຍສຸດ:

$ lpstat -W all
...
<print_queue_name>-<JID>           <user>           1024   Wed 11 Jan 2017 05:52:19 PM CET

ທ່ານສາມາດດຶງບັນທຶກວຽກຫຼ້າສຸດໄດ້ໂດຍອັດຕະໂນມັດ (ຖ້າທ່ານໄດ້ຕິດຕັ້ງ awk ແລະ lpstat -W all ສົ່ງຄ່າວຽກອອກມາ) ດ້ວຍ:

$ journalctl -u cups JID=`lpstat -W all | awk '{print $1}' | awk -F '-' '{print $NF}' | tail -n 1` > cups_job_log

ຫຼື ດ້ວຍຕົນເອງ, ຖ້າທ່ານຮູ້ JID ແລ້ວ:

$ journalctl -u cups JID=<JID> > cups_job_log

ບັນທຶກ cupsd ທີ່ກ່ຽວຂ້ອງກັບເຫດການ (ກໍລະນີຄິວການພິມທີ່ບໍ່ຮອງຮັບ HPLIP)

ບາງຄັ້ງພວກເຮົາບໍ່ສາມາດລະບຸຄວາມຜິດພາດກັບວຽກພິມສະເພາະໃດໜຶ່ງໄດ້, ດັ່ງນັ້ນບັນທຶກວຽກຈຶ່ງບໍ່ມີປະສິດທິພາບ. ໃນກໍລະນີນັ້ນຈຳເປັນຕ້ອງໃຊ້ບັນທຶກ cupsd ທີ່ກ່ຽວຂ້ອງກັບເຫດການ.

ວິທີເລີ່ມເກັບບັນທຶກ cupsd ທີ່ກ່ຽວຂ້ອງກັບເຫດການ

ໃນ terminal ຫຼື tab ໃໝ່, ກະລຸນາໃຊ້ຄຳສັ່ງ:

$ journalctl -f -u cups > cups_whole_log

ວິທີການດຶງເອົາບັນທຶກ cupsd ທີ່ກ່ຽວຂ້ອງກັບເຫດການ

ຫຼັງຈາກທີ່ທ່ານເຮັດໃຫ້ເກີດຂໍ້ຜິດພາດທີ່ທ່ານກຳລັງກວດສອບ ເຊັ່ນ: ການພິມບາງຢ່າງ, ການຄົ້ນຫາເຄື່ອງພິມຜ່ານ lpinfo ແລະ ອື່ນໆ, ໃຫ້ທ່ານຢຸດການເກັບບັນທຶກ cupsd ຈາກ [ຂັ້ນຕອນຂ້າງເທິງ] ໂດຍການກົດ <ctrl>+<c>.

ບັນທຶກ cupsd ທີ່ກ່ຽວຂ້ອງກັບເຫດການ (ກໍລະນີຄິວການພິມທີ່ຮອງຮັບ HPLIP)

ໜ້າເສຍດາຍທີ່ library ຂອງ HPLIP ບໍ່ໄດ້ບັນທຶກລົງໃນ CUPS unit ໃນ journal, ດັ່ງນັ້ນຖ້າຄິວການພິມຂອງທ່ານຖືກຕິດຕັ້ງດ້ວຍໄດເວີ HPLIP (device uri ຂອງມັນເລີ່ມຕົ້ນດ້ວຍ hp://), ພວກເຮົາຈຳເປັນຕ້ອງໃຊ້ບັນທຶກ journal ທີ່ກ່ຽວຂ້ອງກັບເຫດການ.

ວິທີເລີ່ມເກັບບັນທຶກ journal ທີ່ກ່ຽວຂ້ອງກັບເຫດການ

ໃນ terminal ຫຼື tab ໃໝ່, ກະລຸນາໃຊ້ຄຳສັ່ງ:

$ journalctl -f > journal_whole_log

ວິທີການດຶງເອົາບັນທຶກ journal ທີ່ກ່ຽວຂ້ອງກັບເຫດການ

ຫຼັງຈາກທີ່ທ່ານເຮັດໃຫ້ເກີດຂໍ້ຜິດພາດທີ່ທ່ານກຳລັງກວດສອບ ເຊັ່ນ: ການພິມບາງຢ່າງ, ການລັນ HP script ແລະ ອື່ນໆ, ໃຫ້ທ່ານຢຸດການເກັບບັນທຶກ journal ຈາກ [ຂັ້ນຕອນຂ້າງເທິງ] ໂດຍການກົດ <ctrl>+<c>.

ການປິດການບັນທຶກ debug

ກະລຸນາແນບ cups_job_log ສຳລັບວຽກທີ່ມີບັນຫາ, cups_whole_log ຫຼື journal_log ຖ້າທ່ານໄດ້ເກັບບັນທຶກ cupsd ທັງໝົດໃນລະຫວ່າງທີ່ເກີດບັນຫາ ໄປຫາລາຍງານ bug.

ຈາກນັ້ນ, ເພື່ອປິດຂໍ້ມູນການແກ້ໄຂຈຸດບົກພ່ອງ, ໃຫ້ເຮັດດັ່ງນີ້:

$ sudo sed -i 's,LogLevel debug2,LogLevel warn,' /etc/cups/cupsd.conf
$ sudo systemctl restart cups

ຄຳສັ່ງເພີ່ມເຕີມສຳລັບການເຮັດວຽກກັບ systemd-journald

ເບິ່ງຂໍ້ຄວາມບັນທຶກດ້ວຍ:

$ journalctl -u cups -e

ຫຼື:

$ journalctl -u cups --since=...

ເພື່ອແຍກຂໍ້ຄວາມທີ່ກ່ຽວຂ້ອງກັບ Job ID ສະເພາະ, ໃຫ້ໃຊ້:

$ journalctl -u cups JID=...

(ການໃຊ້ tab completion ຈະສະແດງໃຫ້ເຫັນວ່າ Job ID ໃດທີ່ມີຂໍ້ຄວາມບັນທຶກ)

ການບັນທຶກ cups-browsed

daemon cups-browsed ຖືກນຳມາໃຊ້ໃນ Fedora ປະມານເວີຊັນ cups-1.5. ມັນສາມາດຄົ້ນຫາການຖ່າຍທອດ (broadcasts) ຂອງ Bonjour, CUPS (ເລີກໃຊ້ແລ້ວ) ແລະ LDAP servers ເພື່ອຊອກຫາເຄື່ອງພິມ ແລະ ສ້າງ ຫຼື ລຶບຄິວທ້ອງຖິ່ນທີ່ຊີ້ໄປຫາເຄື່ອງພິມເຫຼົ່ານັ້ນ. ມັນສາມາດສ້າງການຖ່າຍທອດຂອງຄິວ CUPS ທ້ອງຖິ່ນໄດ້, ແຕ່ມັນຖືກໝາຍວ່າເລີກໃຊ້ແລ້ວ.

ສຳລັບການຕັ້ງຄ່າການບັນທຶກ debug, ທ່ານຈຳເປັນຕ້ອງເພີ່ມ:

DebugLogging stderr

ລົງໃນ /etc/cups/cups-browsed.conf.

ບັນທຶກຈະມີໃຫ້ເບິ່ງໃນ system journal ຫຼັງຈາກເລີ່ມຕົ້ນ cups-browsed ໃໝ່.

ການບັນທຶກ debug ຂອງ HPLIP scripts

Python scripts ຈາກ HPLIP (ເຊັ່ນ: hp-setup, hp-clean, hp-scan) ມີການປ່ຽນທິດທາງການບັນທຶກ debug ໄປຫາ standard error file descriptor, ດັ່ງນັ້ນພວກມັນຈຶ່ງບໍ່ໄດ້ຖືກບັນທຶກໃນ journal. ເພື່ອດຶງຂໍ້ມູນການບັນທຶກ debug ຂອງພວກມັນ, ໃຫ້ລັນ script ດ້ວຍພາລາມິເຕີ -ldebug ເຊັ່ນ:

$ hp-setup -ldebug -i

ແລະ ເຮັດໃຫ້ເກີດບັນຫາຄືນໃໝ່. ຈາກນັ້ນກັອບປີ້ຂໍ້ຄວາມຈາກ terminal ລົງໃນ hp_script_log. ກະລຸນາແນບໄຟລ໌ດັ່ງກ່າວລົງໃນ bugzilla ticket ນຳ.

ຍີ່ຫໍ້ ແລະ ລຸ້ນຂອງເຄື່ອງພິມຂອງຂ້ອຍແມ່ນຫຍັງ?

ເຄື່ອງພິມແຕ່ລະລຸ້ນຈະມີ Device ID ສະເພາະຂອງຕົນເອງ. ທ່ານສາມາດກວດສອບໄດ້ດ້ວຍຄຳສັ່ງ lpinfo:

$ sudo lpinfo -l -v

ຄຳສັ່ງນີ້ຈະລັນ backend ແຕ່ລະໂຕໃນໂໝດຄົ້ນຫາ (discovery), ເພື່ອໃຫ້ພວກມັນລາຍງານອຸປະກອນທີ່ສາມາດກວດພົບໄດ້ໂດຍອັດຕະໂນມັດ. ມັນຈະສະແດງຜົນອອກມາເປັນຊຸດຂອງບລັອກຂໍ້ຄວາມດັ່ງນີ້:

Device: uri = usb://HP/DESKJET%20990C?serial=U123456789AB
        class = direct
        info = HP DESKJET 990C
        make-and-model = HP DESKJET 990C
        device-id = MFG:HEWLETT-PACKARD;MDL:DESKJET 990C;CMD:MLC,PCL,PML;CLS:PRI
NTER;DES:Hewlett-Packard DeskJet 990C;SN:U123456789AB;S:00808880800010032C100000
0C2000000;P:0800,FL,B0;J:                    ;
        location =

ບັນທັດທີ່ລະບຸປະເພດລຸ້ນສະເພາະນີ້ຄືບັນທັດຍາວໆທີ່ເລີ່ມຕົ້ນດ້ວຍ "device-id =" (ທີ່ສະແດງຢູ່ນີ້ແມ່ນແບ່ງອອກເປັນສາມບັນທັດ).

ໝາຍເຫດ: ຖ້າເຄື່ອງພິມຂອງທ່ານບໍ່ສາມາດກວດພົບໄດ້ໂດຍອັດຕະໂນມັດ, ທ່ານຍັງສາມາດຫາ Device ID ໄດ້ໂດຍການລັນ backend ທີ່ກ່ຽວຂ້ອງພ້ອມກັບລະບຸ hostname ຂອງເຄື່ອງພິມເປັນ argument. ໂດຍທີ່ backend ປະເພດ usb, parallel, snmp, ແລະ dnssd ທັງໝົດຈະພະຍາຍາມລາຍງານ Device ID ຕົວຈິງທີ່ສົ່ງມາຈາກເຄື່ອງພິມ.

$ /usr/lib/cups/backend/snmp 10.34.18.3

network socket://10.34.18.3 "HP Color LaserJet CP2025dn" "HP Color LaserJet CP2025dn"
"MFG:Hewlett-Packard;CMD:PJL,PML,PCLXL,POSTSCRIPT,PCL;MDL:HP Color LaserJet CP2025dn;
CLS:PRINTER;DES:Hewlett-Packard Color LaserJet CP2025dn;MEM:MEM=55MB;COMMENT:RES=600x8;" "HP Color LaserJet CP2025dn"

ໃນກໍລະນີນີ້ Device ID ແມ່ນ (ເບິ່ງ backend(7)) ຟິວທີສອງນັບຈາກທ້າຍສຸດ.

ມີຄິວການພິມໃດແດ່ທີ່ຂ້ອຍສາມາດໃຊ້ໄດ້?

ຄິວໃນເຄື່ອງຂອງທ່ານອາດເປັນແບບຖາວອນ ຫຼື ຊົ່ວຄາວ. CUPS ສາມາດສະແດງລາຍຊື່ຄິວການພິມທັງໝົດທີ່ມີຢູ່ໃນເຄືອຂ່າຍທ້ອງຖິ່ນ (ທັງແບບຖາວອນ ແລະ ຊົ່ວຄາວ) ດ້ວຍ:

$ lpstat -e

ສຳລັບຄິວແບບຖາວອນ ທ່ານສາມາດເບິ່ງຂໍ້ມູນເພີ່ມເຕີມໄດ້ດ້ວຍ:

$ lpstat -t

ຂ້ອຍກຳລັງໃຊ້ໄດເວີໂຕໃດ?

ໄຟລ໌ PPD ສຳລັບຄິວເຄື່ອງພິມສາມາດບອກທ່ານໄດ້ວ່າໄດເວີໂຕໃດກຳລັງຖືກໃຊ້ງານ. ທ່ານສາມາດໃຊ້ຄຳສັ່ງນີ້ເພື່ອຊອກຫາໄດເວີທີ່ກຳລັງໃຊ້ຢູ່:

$ grep -H '^*NickName:' /etc/cups/ppd/*.ppd

ທ່ານຍັງສາມາດກວດສອບໄດ້ໂດຍໃຊ້ແອັບພລິເຄຊັນ system-config-printer. ໂດຍດັບເບິນຄລິກທີ່ໄອຄອນຂອງຄິວ ແລະ ເບິ່ງທີ່ຟິວ Make and Model.

ເພື່ອເບິ່ງໄດເວີທີ່ມີໃຫ້ໃຊ້, ໃຫ້ຄລິກທີ່ປຸ່ມ Change… ຖັດຈາກຟິວນັ້ນ. ທ່ານອາດຈະລອງໃຊ້ໄດເວີອື່ນເພື່ອເບິ່ງວ່າບັນຫາເດີມຍັງເກີດຂຶ້ນຢູ່ຫຼືບໍ່.

ລຸ້ນທີ່ບໍ່ໃຊ້ໄດເວີ (Driverless)

ເຄື່ອງພິມສ່ວນໃຫຍ່ທີ່ວາງຈຳໜ່າຍຕັ້ງແຕ່ປີ 2010 ແມ່ນຮອງຮັບ AirPrint ຫຼື IPP Everywhere, ເຊິ່ງໝາຍຄວາມວ່າພວກມັນບໍ່ຈຳເປັນຕ້ອງຕິດຕັ້ງໄດເວີກໍສາມາດເຮັດວຽກໄດ້ - ໂດຍ Avahi ຈະຄົ້ນຫາອຸປະກອນ ແລະ ສື່ສານຄວາມສາມາດໃນການພິມຜ່ານໂປຣໂຕຄໍ IPP - ເຊິ່ງເອີ້ນວ່າອຸປະກອນແບບ driverless. ໃນ Fedora ມີສອງວິທີທີ່ຮອງຮັບ IPP everywhere:

ລຸ້ນ CUPS 'everywhere'
ໄດເວີ 'driverless' ຂອງ cups-filters

ລຸ້ນ CUPS 'everywhere'

ນີ້ແມ່ນການນຳໃຊ້ງານມາດຕະຖານ IPP everywhere ຂອງ CUPS, ເຊິ່ງມີໃຫ້ໃຊ້ໃນຮູບແບບລຸ້ນເຄື່ອງພິມພິເສດ. ລຸ້ນນີ້ຈະຖືກໃຊ້ເມື່ອທ່ານໃຊ້ຄິວຊົ່ວຄາວຂອງ CUPS ສຳລັບອຸປະກອນຂອງທ່ານ ຫຼື ຖ້າທ່ານຕິດຕັ້ງອຸປະກອນດ້ວຍລຸ້ນ IPP Everywhere ໃນ CUPS web ui ຫຼື ຜ່ານ lpadmin (ໂດຍໃຊ້ -m everywhere).

ເນື່ອງຈາກໄຟລ໌ PPD ທີ່ຖືກສ້າງຂຶ້ນນັ້ນຂຶ້ນກັບການສື່ສານ IPP ກັບເຄື່ອງພິມ, ພວກເຮົາຈຳເປັນຕ້ອງມີຂໍ້ມູນທີ່ເກັບມາຈາກອຸປະກອນ. ທ່ານສາມາດໃຊ້ ipptool ສຳລັບການນີ້ໄດ້:

$ ipptool --ippserver ipptool.attr <your_printer_device_uri> get-printer-attributes.test

ແນບໄຟລ໌ ipptool.attr ທີ່ສ້າງຂຶ້ນລົງໃນ bugzilla ticket ຖ້າຈຳເປັນ.

ໄດເວີ 'driverless' ຂອງ cups-filters

ໄດເວີພິເສດຂອງ Cups-filters ທີ່ໃຊ້ສຳລັບສ້າງ PPD ຕາມມາດຕະຖານ IPP Everywhere. ໄດເວີນີ້ຈະຖືກໃຊ້ຖ້າທ່ານເລືອກລຸ້ນ driverless ໃນລະຫວ່າງການຕິດຕັ້ງເຄື່ອງພິມ.

ພວກເຮົາຕ້ອງການຜົນລັນ (output) ຂອງຄຳຮ້ອງ get-printer-attributes ຄືກັນ:

$ ipptool --ippserver ipptool.attr <your_printer_device_uri> get-printer-attributes.test

ແລະ ບັນທຶກ debug ຈາກຕົວໄດເວີເອງເມື່ອມັນສ້າງ PPD ສຳລັບອຸປະກອນຂອງທ່ານ:

$ driverless -d cat <ipp_device_uri> 2> driverless_debug > created_ppd

ແນບໄຟລ໌ທີ່ສ້າງຂຶ້ນທັງໝົດລົງໃນ bugzilla ticket ຖ້າຈຳເປັນ.

ການຄົ້ນຫາວ່າບັນຫາຢູ່ໃສ

ເມື່ອວຽກພິມຖືກປະມວນຜົນ, ມັນຈະຖືກສົ່ງຜ່ານຊຸດຂອງ filters ເພື່ອແປງໄຟລ໌ໃຫ້ເປັນຮູບແບບທີ່ເຄື່ອງພິມເຂົ້າໃຈ, ແລະ ສຸດທ້າຍກໍຈະຖືກສົ່ງໄປຫາ backend ເຊິ່ງເປັນໂປຣແກຣມທີ່ນຳສົ່ງຂໍ້ມູນໄປຫາເຄື່ອງພິມ. ໂດຍການປ່ຽນວິທີການພິມເລັກນ້ອຍ, ທ່ານສາມາດລອງໃຊ້ເສັ້ນທາງການພິມທີ່ແຕກຕ່າງກັນເພື່ອເບິ່ງວ່າມັນມີຜົນຫຍັງບໍ່. ຖ້າວິທີນັ້ນສາມາດແກ້ໄຂບັນຫາໄດ້ຊົ່ວຄາວ, ທ່ານກໍຈະຮູ້ວ່າບັນຫາຢູ່ໃນສ່ວນໃດ — ໃຫ້ລະບຸຂໍ້ມູນນັ້ນໃນລາຍງານ bug ເພື່ອໃຫ້ພວກເຮົາສາມາດແກ້ໄຂມັນໄດ້.

ແອັບພລິເຄຊັນ

ລອງພິມຈາກແອັບພລິເຄຊັນອື່ນເພື່ອເບິ່ງວ່າບັນຫາຫາຍໄປຫຼືບໍ່ ຫຼື ມັນເກີດຂຶ້ນບໍ່ວ່າຈະພິມໄຟລ໌ດ້ວຍວິທີໃດກໍຕາມ. ລອງພິມເອກະສານຈາກ command line ໂດຍໃຊ້ຄຳສັ່ງ lp.

ຮູບແບບເອກະສານ

ຖ້າທ່ານມີບັນຫາໃນການພິມໄຟລ໌ PDF, ໃຫ້ລອງພິມໄຟລ໌ປະເພດອື່ນເພື່ອເບິ່ງວ່າບັນຫາເກີດຂຶ້ນກັບທຸກຢ່າງ ຫຼື ສະເພາະແຕ່ໄຟລ໌ PDF ເທົ່ານັ້ນ. ລອງແປງໄຟລ໌ເປັນຮູບແບບອື່ນແລ້ວລອງພິມໃໝ່.

ຖ້າບັນຫາແມ່ນການພິມໄຟລ໌ຂໍ້ຄວາມ (text files), ໃຫ້ລອງຖອນການຕິດຕັ້ງ ຫຼື ຕິດຕັ້ງແພັກເກດ paps ຄືນໃໝ່. ແພັກເກດນີ້ມີ filter ແປງຂໍ້ຄວາມເປັນ PostScript ທາງເລືອກອື່ນນອກເໜືອຈາກໂຕທີ່ມາພ້ອມກັບ CUPS.

ເພື່ອທົບທວນເອກະສານທີ່ຖືກສົ່ງໄປຫາ CUPS ເພື່ອພິມ, ໃຫ້ເປີດໃຊ້ງານຕົວເລືອກ PreserveJobFiles ດັ່ງນີ້:

cupsctl PreserveJobFiles=yes

ເອກະສານວຽກທີ່ສົ່ງໄປຈະຍັງຄົງຢູ່ໃນ /var/spool/cups. ໂດຍຈະມີໄຟລ໌ທີ່ມີຊື່ສອງແບບຄື - dXXXXX-YYY ແລະ cXXXXX. ໄຟລ໌ dXXXXX-YYY ແມ່ນໄຟລ໌ທີ່ສົ່ງເຂົ້າລະບົບ CUPS ແບບທີ່ຍັງບໍ່ຜ່ານ filter - ໂດຍ XXXXX ແມ່ນ Job ID ເຊິ່ງຈະຕື່ມເລກສູນໃຫ້ຄົບ 5 ຕົວອັກສອນ, ແລະ YYY ແມ່ນລຳດັບຂອງໄຟລ໌ໃນວຽກນັ້ນ. ສ່ວນ cXXXXX ແມ່ນໄຟລ໌ທີ່ເກັບຕົວເລືອກການພິມສຳລັບວຽກນັ້ນ. ກະລຸນາແນບໄຟລ໌ dXXXXX-YYY ໄປກັບ bug ເມື່ອທ່ານພົບບັນຫາ.

ການລັນ filters ດ້ວຍຕົນເອງ

ຜູ້ໃຊ້ລະດັບສູງອາດຈະຢາກລອງລັນ CUPS filters ດ້ວຍຕົນເອງ ແລະ ກວດສອບໄຟລ໌ຂໍ້ມູນໃນແຕ່ລະຂັ້ນຕອນທີ່ມີການແປງຮູບແບບ. ນີ້ແມ່ນຕົວຢ່າງການເຮັດແບບນີ້ສຳລັບຄິວ gutenprint ທີ່ຊື່ວ່າ pqueue ດ້ວຍ CUPS test page ເຊິ່ງມີ MIME type ພິເສດຄື application/vnd.cups-banner:

ທຳອິດທ່ານຕ້ອງຮູ້ filter pipeline ສຳລັບ application/vnd.cups-banner → printer/pqueue (output MIME type). ທ່ານສາມາດ [ເປີດໃຊ້ການ debug], ພິມໜ້າທົດສອບ, ເບິ່ງ [ບັນທຶກວຽກ CUPS] ແລະ ໃນ cups_job_log ທ່ານຈະເຫັນບາງຢ່າງທີ່ຄ້າຍຄືກັບ:

envp[29]="FINAL_CONTENT_TYPE=printer/pqueue"
Started filter /usr/lib/cups/filter/bannertopdf (PID 1111)
Started filter /usr/lib/cups/filter/pdftopdf (PID 1112)
Started filter /usr/lib/cups/filter/gstoraster (PID 1113)
Started filter /usr/lib/cups/filter/rastertogutenprint.5.2 (PID 1114)

ຫຼື ລັນຄຳສັ່ງ

$ /usr/lib/cups/filter/bannertopdf 1 me '' 1 '' </usr/share/cups/data/testprint >bannertopdf.pdf
$ cupsfilter -e -m printer/pqueue -p /etc/cups/ppd/pqueue.ppd bannertopdf.pdf > /dev/null

ແລະ ທ່ານຈະເຫັນ:

INFO: pdftopdf (PID 1111) started.
INFO: gstoraster (PID 1112) started.
INFO: rastertogutenprint.5.2 (PID 1113) started.

filter pipeline ນີ້ແມ່ນມາຈາກ cups-1.6. ໃນ cups ທີ່ຕໍ່າກວ່າ 1.6 ທ່ານອາດຈະເຫັນ bannertops → pstops → pstoraster ແທນ.

ຕອນນີ້ທ່ານສາມາດລັນ filters ດ້ວຍຕົນເອງໄດ້:

$ export PPD=/etc/cups/ppd/pqueue.ppd
$ /usr/lib/cups/filter/bannertopdf 1 me '' 1 '' </usr/share/cups/data/testprint >bannertopdf.pdf
$ /usr/lib/cups/filter/pdftopdf 1 me '' 1 '' <bannertopdf.pdf >pdftopdf.pdf
$ /usr/lib/cups/filter/pdftoraster 1 me '' 1 ''<pdftopdf.pdf >out.ras
$ /usr/lib/cups/filter/rastertogutenprint.5.2 1 me '' 1 ''<out.ras >out.prn

ໃນທີ່ນີ້, ສາມາດໃຊ້ evince ຫຼື okular ເພື່ອກວດສອບ output ຫຼັງຈາກຜ່ານສອງ filter ທຳອິດ, ໃຊ້ rasterview ເພື່ອກວດສອບ output ຂອງ filter ທີສາມ, ແລະ output ຂອງ filter ສຸດທ້າຍຕ້ອງຖືກກວດສອບດ້ວຍຕົນເອງ ຫຼື ສົ່ງໄປເຄື່ອງພິມໂດຍກົງ (lpr -oraw out.prn).

ໄດເວີ

ຖ້າທ່ານສາມາດເຂົ້າເຖິງເຄື່ອງພິມຍີ່ຫໍ້ ຫຼື ລຸ້ນອື່ນ, ມັນອາດຈະຄຸ້ມຄ່າທີ່ຈະລອງເບິ່ງວ່າບັນຫາເກີດຂຶ້ນກັບທັງສອງເຄື່ອງ ຫຼື ສະເພາະເຄື່ອງໃດເຄື່ອງໜຶ່ງ. ນີ້ສາມາດບົ່ງບອກໄດ້ວ່າມັນເປັນບັນຫາກັບໄດເວີສະເພາະ ຫຼື ເປັນບັນຫາທົ່ວໄປ.

ເຖິງແມ່ນວ່າທ່ານຈະເຂົ້າເຖິງເຄື່ອງພິມໄດ້ພຽງເຄື່ອງດຽວ, ແຕ່ປົກກະຕິແລ້ວກໍມັກຈະມີໄດເວີຫຼາຍໂຕໃຫ້ເລືອກໃຊ້ສຳລັບເຄື່ອງພິມລຸ້ນນັ້ນ, ແລະ ການລອງໃຊ້ແຕ່ລະໂຕກໍເປັນປະໂຫຍດໃນການຈຳກັດຂອບເຂດບັນຫາ. ເບິ່ງ [ຂ້າງເທິງ] ສຳລັບວິທີການເຮັດ.

Foomatic

ສຳລັບໄດເວີ Foomatic ທ່ານສາມາດລອງເປີດໃຊ້ການ debug ຂອງ Foomatic ໄດ້ໂດຍການແກ້ໄຂໄຟລ໌ /etc/foomatic/filter.conf ແລະ ເພີ່ມບັນທັດນີ້:

debug: 1

ໃນຄັ້ງຕໍ່ໄປທີ່ທ່ານພິມວຽກໄປຫາຄິວທີ່ໃຊ້ foomatic, ຂໍ້ມູນການ debug ຈະຖືກເກັບໄວ້ໃນ /tmp/foomatic-rip.log, ແລະ ໄຟລ໌ input ທີ່ foomatic-rip ໄດ້ຮັບຈະຢູ່ໃນ /tmp/foomatic-rip.ps.

Backend (ການນຳສົ່ງວຽກ)

ທ່ານອາດຈະລອງໃຊ້ backend ອື່ນໄດ້. ໂດຍໃຊ້ system-config-printer, ດັບເບິນຄລິກທີ່ໄອຄອນຄິວເຄື່ອງພິມ ແລະ ຄລິກປຸ່ມ Change… ຖັດຈາກຟິວ Device URI. ທ່ານອາດຈະເຫັນລູກສອນຂະຫຍາຍ Connection ຢູ່ໃກ້ກັບມຸມຂວາລຸ່ມຂອງປ່ອງຢ້ຽມ — ໃຫ້ຄລິກໃສ່ມັນເພື່ອເບິ່ງວ່າ backend ໃດແດ່ທີ່ມີໃຫ້ໃຊ້. ສຳລັບເຄື່ອງພິມ HP ທີ່ເຊື່ອມຕໍ່ດ້ວຍ USB, ໂດຍປົກກະຕິແລ້ວສາມາດໃຊ້ໄດ້ທັງ backend hp ແລະ usb.

ສຳລັບການເກັບຂໍ້ມູນການສື່ສານ USB:

ກວດສອບໝາຍເລກ bus ທີ່ອຸປະກອນ USB ເຊື່ອມຕໍ່ຢູ່, ຕົວຢ່າງ:

$ lsusb
Bus 002 Device 010: ID 03f0:012a HP, Inc HP LaserJet M1536dnf MFP

      =

ເລີ່ມການເກັບແພັກເກັດ USB:

$ sudo tcpdump -i usbmonN -s0 -w usb.pcap

ໂດຍທີ່ N ແມ່ນໝາຍເລກ bus.

ສຳລັບເຄື່ອງພິມເຄືອຂ່າຍ ທ່ານອາດຈະມີໂປຣໂຕຄໍອື່ນໆໃຫ້ລອງໃຊ້.

socket ແມ່ນສຳລັບ HP JetDirect (ປົກກະຕິແມ່ນພອດ 9100)
lpd ແມ່ນສຳລັບການແຊຣ໌ການພິມ UNIX ແບບເກົ່າ
smb ແມ່ນສຳລັບການແຊຣ໌ CIFS ຈາກລະບົບ Windows
ipp ແມ່ນສຳລັບອຸປະກອນທີ່ຮອງຮັບ Internet Printing Protocol ແລະ ສຳລັບ CUPS servers ອື່ນໆນຳ — ທ່ານສາມາດເກັບຂໍ້ມູນ IPP traffic ດ້ວຍ tcpdump ດັ່ງນີ້ (ຊື່ interface ອາດຈະແຕກຕ່າງຈາກ p4p1):

$ tcpdump -n -i p4p1 -U -s0 -w ipp.pcap port ipp

bjnp ແມ່ນສຳລັບໂປຣໂຕຄໍເຄືອຂ່າຍ bjnp ສະເພາະຂອງ Canon (ປົກກະຕິແມ່ນພອດ 8611)

ເຄື່ອງມືການຕັ້ງຄ່າ

ຖ້າບັນຫາຂອງທ່ານກ່ຽວຂ້ອງກັບການຕັ້ງຄ່າຄິວການພິມ, ໃຫ້ລອງໃຊ້ວິທີອື່ນທີ່ມີຢູ່. ເຊິ່ງມີ 4 ວິທີດັ່ງນີ້:

ແອັບພລິເຄຊັນ GNOME 3 System Settings (control-center), System Settings > Printers ຈາກ GNOME Shell
system-config-printer, System > Administration > Printing ຈາກເມນູ GNOME
ເວັບອິນເຕີເຟດຂອງ CUPS ທີ່ http://localhost:631/
ເຄື່ອງມື command line ເຊັ່ນ: lpadmin, lpoptions, cupsctl, cupsaccept, cupsenable ແລະ ອື່ນໆ.

ເລື່ອງລາວຈາກຜູ້ໃຊ້ (User stories)

ມີເລື່ອງລາວຈາກຜູ້ໃຊ້ທົ່ວໄປຫຼາຍຢ່າງໃນການແກ້ໄຂບັນຫາການພິມ. ຂ້ອຍຈະກ່າວເຖິງບາງຢ່າງພ້ອມກັບຂັ້ນຕອນວິທີການດຶງເອົາຂໍ້ມູນທີ່ຈຳເປັນ.