Quando eu reiniciar, um trabalho de impressão na fila será impresso, depois que os trabalhos não forem impressos com a seguinte mensagem: processamento desde "Aguardando a impressora ficar disponível".
Além disso, quando executo o kernel do Ubuntu, a impressão funciona bem.
Nenhuma ideia de onde começar este - Tentei fazer o óbvio como google, cups depurar logs, syslog. Leia os bugs arquivados contra este pacote e não viu nada provável, mas poderia ter perdido. Precisa de alguma direção sobre como proceder / qual subsistema focar: cupd config ou usb ou ppds ou kernel ou ...?
Eu acidentalmente descobri que quando eu executo o kernel do ubuntu mais recente, a impressão funciona bem. ( link ) Devido a isso, hesitei em começar a testar diferentes drivers de impressão, configurações de xícaras, etc., já que correções de kernel diferentes o problema. Eu prefiro manter o kernel do Ubuntu no lugar, já que rolar meu próprio kernel vai quebrar muitas coisas aleatórias.
Eu passei pelas etapas no link nada mudou.
Cups sempre foi um pouco de caixa preta para mim, então com algumas indicações sobre quais diagnósticos executar, eu deveria ser capaz de resolver isso. Eu defino o loglevel de cups para depurar, e ele vomita muita coisa. Uma linha parecia interessante, pois continha a string "failed": FindDeviceById falhou: org.freedesktop.ColorManager.NotFound: o id do dispositivo 'cups-HL-2040-series' não existe
Não tenho certeza do que isso significa ou como isso está relacionado ao meu problema intermitente.
# uname -r
3.16.0-28-lowlatency
Informação da impressora:
HL-2040-series Brother HL-2040 series Brother HL-2040 Foomatic/hl1250 (recommended)
# lsmod | grep usb
usblp 18756 0
btusb 32448 0
bluetooth 446374 22 bnep,btusb,rfcomm
# lpinfo -v
network socket
direct parallel:/dev/lp0
network ipp
network lpd
network http
network https
direct hp
network ipps
direct usb://Unknown/Printer
network ipp14
serial serial:/dev/ttyS0?baud=115200
serial serial:/dev/ttyS1?baud=115200
network smb
direct hpfax
Atualização: Eu encontrei o fracasso, e porque o grepping para "falhou" não funcionou. Deveria ter grepped para "Falhou". Job 61 imprimiu bem, mas o google mostra que há outros por aí que resolveram isso, alguns já em 2010, então talvez seja uma regressão recente de bug do kernel.
D [19/Dec/2014:09:57:57 -0800] [Job 62] Switching USB device configuration: 0 -> 1
D [19/Dec/2014:09:57:57 -0800] cupsd is not idle any more, canceling shutdown.
D [19/Dec/2014:09:57:57 -0800] [Job 62] Failed to set configuration 1 for 04f9:0028
D [19/Dec/2014:09:57:57 -0800] [Job 62] STATE: -connecting-to-device
D [19/Dec/2014:09:57:57 -0800] cupsdMarkDirty(---J-)
D [19/Dec/2014:09:57:57 -0800] cupsdSetBusyState: newbusy="Printing jobs and dirty files", busy="Dirty files"
D [19/Dec/2014:09:57:57 -0800] Discarding unused printer-state-changed event...
D [19/Dec/2014:09:57:57 -0800] cupsd is not idle any more, canceling shutdown.
D [19/Dec/2014:09:57:57 -0800] cupsd is not idle any more, canceling shutdown.
D [19/Dec/2014:09:57:57 -0800] [Job 62] Failed to re-attach "usblp" kernel module to 04f9:0028
Parece ter sido um cabo flakey. Por que imprimir de forma confiável uma vez, depois sufocar após um ciclo de energia, parece ilógico. Mas uma troca de cabos resolveu esse problema.
Espero que isso ajude a lembrar a próxima pessoa a verificar o hardware antes de ficar medieval nos registros de erros ...