|
|
|
Bonjour,
Y a-t-il un moyen de déterminer, en ligne de commande, si une imprimante est allumée ou pas ? (J'ai regardé sans succès lpadmin, lpstat et cupsctl.) Merci pour vos pistes ! Seb. |
|
|
Peut-être une c? mais juste un ping ne suffirait-il pas ?
Ou alors une simple tentative sur un des ports de service de l?imprimante (LPD, IPP, ?) ? [..] |
|
|
Le lundi 30 septembre 2019 à 14:03 +0200, Pierre Malard a écrit :
> Ou alors une simple tentative sur un des ports de service de > l?imprimante (LPD, IPP, ?) ? vivi, mais quelque chose qui ne rallume pas l'imprimante en veille, non ? D'ailleurs en écrivant ça me rappelle que les imprimantes réseau ont maintenant toutes un serveur http à ma connaissance. Un ping me parait assez adapté pour quelque chose de très minimaliste. Et je me demande a quel point un bon vieux wakeonlan ne fonctionnerait pas en cas de besoin. Sinon il y a souvent un hplip ou équivalent qui fonctionne pour un constructeur donné. Voilà en vrac mes 4,85 secondes de réflexions. |
|
|
Bonjour,
> Peut-être une c? mais juste un ping ne suffirait-il pas ? Ah, j'aurais dû préciser que l'imprimante est connectée en USB. Pour détailler un peu: il y a une dizaine de jours j'avais envoyé un mail sur cette liste parce que le comportement du spooler d'impression semble avoir changé entre Debian 9 et Debian 10. Au lieu de réessayer d'imprimer jusqu'à ce que l'imprimante soit allumée, il abandonne au premier échec. Résultat, si je lance une impression avant d'allumer mon imprimante, je suis obligé de passer ensuite par l'interface web de CUPS pour débloquer le job. (Et je ne peux pas laisser l'imprimante allumée en permanence, parce qu'elle passe en mode soufflerie pendant une minute toutes les dix minutes.) Comme je n'ai pas trouvé comment régler le spooler (ce qui serait la bonne solution) et comme mon message n'avait pas inspiré la liste (aucune répnse), j'ai pensé à la solution de contournement « détecter si l'imprimante est allumée » pour qu'un script temporise l'envoi du fichier à CUPS jusqu'à ce qu'il ait le feu vert du système. Je note donc qu'une idée serait de connecter l'imprimante en Ethernet. Ce n'est pas si commode car elle n'a pas carte réseau, il faudrait que je trouver un boîtier externe pour la conversion Ethernet/USB. Peut-on faire plus simple, et idéalement régler le système plutôt que trafiquer le hardware ? Merci ! Seb. |
|
|
Le 01/10/2019 à 11:42, Seb a écrit :
> Bonjour, Bonjour [...] Peut-on > faire plus simple, et idéalement régler le système plutôt que trafiquer > le hardware ? Dans la configuration CUPS de ton imprimante as tu bien ErrorPolicy retry-job ? |
|
|
>> [...] Peut-on faire plus simple, et idéalement régler le système plutôt
>> que trafiquer le hardware ? > Dans la configuration CUPS de ton imprimante as tu bien ErrorPolicy > retry-job ? Oui: ~>sudo grep ErrorPolicy /etc/cups/printers.conf ErrorPolicy retry-job Seb. |
|
|
Bonjour à tous,
Salut Seb, Une idée me vient en quelques secondes, tu ne pourrait pas "connaître" l'état de ton imprimante via SNMP par exemple et ainsi "retarder" l'impression depuis la configuration de l'impression pilote, ppd. Afin de scripter le réveil, la vérification puis l'impression, "simplement" en lançant une impression "standard" (CTRL+P). Certains GET ou WALK SNMP don't meme "capables" de réveiller voire redémarrer une imprimante. Quel est ton modèle et as-tu déjà récupéré laMib SNMP ? Cordialement, Gwennhaël. Le mar. 1 oct. 2019 à 12:56, Seb <seb> a écrit : [..] |
|
|
Le 01/10/2019 à 12:56, Seb a écrit :
> Oui: > ~>sudo grep ErrorPolicy /etc/cups/printers.conf > ErrorPolicy retry-job Cela ne veut rien dire ! Si tu as plus d'une imprimante définie comment sais tu que ce paramètre s'applique bien à ce modèle ? |
|
|
Bonjour,
> Cela ne veut rien dire ! Si tu as plus d'une imprimante définie comment > sais tu que ce paramètre s'applique bien à ce modèle ? OK, je précise qu'il y a une seule imprimante branchée et que j'ai vérifié que la même information était bien cliquée sur l'interface web de CUPS. > Une idée me vient en quelques secondes, tu ne pourrait pas "connaître" > l'état de ton imprimante via SNMP par exemple Hou, ça fait longtemps que je n'ai pas regardé SNMP. Si ça marche avec une imprimante branchée en USB, je ne sais pas faire. > et ainsi "retarder" l'impression depuis la configuration de l'impression > pilote, ppd. Oui, c'est en gros ce que je proposais il me semble. Comme j'imprime pratiquement toujours via un script maison (qui redistribue le travail ensuite aux différents outils en fonction du type de fichier), retarder ne pose pas de problème *si* on sait déterminer si l'imprimante est allumée ou pas. > Certains GET ou WALK SNMP don't meme "capables" de réveiller voire > redémarrer une imprimante. Quel est ton modèle et as-tu déjà récupéré la > Mib SNMP ? C'est une imprimante HP assez ancienne, gros format (4250 laserjet), que l'on n'allume qu'avec un commutateur physique. (Je serais très preneur d'une commande pour l'arrêter sans toucher à ce bouton :-) Seb. |
|
|
Le 01/10/2019 à 11:42, Seb a écrit :
> Pour détailler un peu: il y a une dizaine de jours j'avais envoyé un > mail sur cette liste parce que le comportement du spooler d'impression > semble avoir changé entre Debian 9 et Debian 10. Au lieu de réessayer > d'imprimer jusqu'à ce que l'imprimante soit allumée, il abandonne au > premier échec. Résultat, si je lance une impression avant d'allumer mon > imprimante, je suis obligé de passer ensuite par l'interface web de CUPS > pour débloquer le job. (Et je ne peux pas laisser l'imprimante allumée Bonjour, peut-etre pourrais-tu trouver de l'aide sur <https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture> |
|
|
On Tuesday 01 October 2019 12:56:18 Seb wrote:
> ~>sudo grep ErrorPolicy /etc/cups/printers.conf > ErrorPolicy retry-job Mon imprimante est en WiFi. J'ai sans doute mal compris la ligne ci-dessous, excuses sinon. Imprimante allumée ou pas, # grep ErrorPolicy /etc/cups/printers.conf je reçois cette réponse : ErrorPolicy retry-job ErrorPolicy stop-printer Bonne journée. |