Bonjour,
 
je possède deux imprimantes usb sur un serveur debian dans un placard spoolées par CUPSd.
Comme vous l'avez peut-être remarqué, l'usb "Universal Serial Bus" ou "bus série" ne permet pas de différencier les périphériques dans /dev/usb/lp* autrement que dans l'ordre de mise sous tension des imprimantes (premier allumé = premier numéro attribué).
 
Afin de reconnaître une imprimante d'une autre sans avoir à se préoccuper du numéro de /dev/usb/lp* attribué, il est possible de renseigner à la configuration de l'imprimante le champs DeviceURI avec usb://<NomFabricant>/<ModeleImprimante>, très pratique me direz-vous?
Certes, mais dans ce cas là si l'imprimante est hors-tension le usb://<NomFabricant>/<ModeleImprimante> n'existe pas et qu'un travail est lancé sur celle-ci, CUPSd la met automatiquement en arrêt, ce qui reste le cas lors de la remise sous tension..
 
Peut-être y aurait-il une option que j'ai mal/pas configuré qui permet de palier à ceci.
Peut-être également que quelqu'un pourra éclairer ma lanterne..
 
Merci à ceux qui proposeront des solutions (ou tenteront   )
++

Mince! Je pensais que j'aurai plein de réponses en très peu de temps mais apparemment ....

Compte tenu de la qualité de ce forum, je pensais que toutes mes questions trouveraient réponse .. Faut croire que non..
C'est la troisième fois de suite que je n'obtiens pas de réponse, est ce que mes questions sont si tordues que ça??
++

c'est un "bug" de CUPS au niveau du backend qui fait que l'imprimante est automatiquement désactivée si on essaie d'imprimer dessus si elle est éteinte.
 
Ce bug a justement été "corrigé" sous Mandriva 2006 gràce à till qui a mis en place un wrapper qui réactive l'imprimante automatiquement lorsque tu relances CUPS ou que tu branches l'imprimante.
 
cf http://qa.mandriva.com/show_bug.cgi?id=15819
 

Je suis allé voir sur le site de CUPS pour voir les solutions  
http://www.cups.org/str.php?L666+P0+S0+C0+I10+E0+Qoff
et apparemment la dernière version (1.2) implémente des possibilités de configuration du backend afin de contourner le problème.
 
Ils disent que la version 1.1.21 inclue des changements :
 "CUPS 1.1.21 includes some changes to the USB backend that will retry printing if the printer is turned off or disconnected".
Pour ma part, cela réessaie quelques temps pour finalement désactiver la queue d'impression.
Si je ne trouve pas de solution, je passerai en 1.2 .
En tt cas,je te remercie de ta réponse elle m'a beaucoup aidé.
 

Bonjour, j'ai un problème du même genre mais je n'arrive pas à savoir s'il est identique... J'ai aussi une imprimante usb, mais moi je la laisse toujours allumer (elle se met en veille..). Bref sauf que quand je lance une impression rien ne se passe (il la met en file d'attente)  et il faut que j'aille dans le navigateur pour "démarrer" l'imprimante.
Est-ce la même chose?
et donc si j'ai bien compris il suffit de faire une upgrade de cups?
merci d'avance

euh je ne pense pas que ce soit le mm probleme  
ca doit etre un probleme de mauvaise config
mon probleme etait à la base que lorsque je lance une impression sur une imprimante eteinte cups la met sur pause et elle le reste mm si on allume l imprimante entre tps
n ayons aujourd hui tjrs pas trouvé de solution
j ai choisi la facilité:
crond les re-enable toutes les minutes  
pas tres brillant comme solution je vous l accorde... enfin si qqun a qqchose de mieux a proposer je susi tjrs preneur  
+

Merci c'est quoi la commande exacte de cron des fois que ça marche chez moi.
merci d'avance..

Tu ajoutes ca ds un fichier que t appelle ce que tu veux "CupsBug" par exemple et que tu places ds /etc/cron.d  
le fichier contiendra une seule ligne
* * * * * root /usr/bin/enable Imprimante1 && /usr/bin/enable Imprimante2
ms je le repetes ce n est qu une methode de dépannage c est pas super joli....
 
Le mieux ce serait que le bug soit corrigé ds les versions posterieures de cups
a suivre...;

Le bug n'ayant toujours pas été corrigé officiellement, la meilleure solution que j'ai trouvé à ce jour est de ré-enabler les imprimantes à chaque allumage d'une imprimante.
 
Sous debian il suffit de rajouter
 /usr/bin/enable Imprimante
en haut du fichier /etc/hotplug/usb.agent
 
De cette maniere mm si on lance une impression sur une imprimante offline ,(ce qui engendrerait la mise en pause de cette dernière), elles seront dé-pausées dès que l'on rallumera l'imprimante.
 
Voilà c'est un peu mieux que la solution cron toutes les minutes ci-dessus et ça dépannera en attendant la correction du bug ds le backend

sous Mandriva 2006 c'est corrigé. Avec printerdrake tu peux spécifier si tu veux qu'il réactive automatiquement les imprimante au démarrage ou lorsque le service cups est lancé/relancé

 
J'ai le même souci avec des imprimantes réseaux. Il suffit qu'un utilisateur ouvre le bac pour mettre du papier, mette l'imprimante hors-ligne où autre pour que ce devienne vite un cauchemar. Évidemment, il est hors de question de donner les droits d'administration aux utilisateurs.
 
J'ai pondu un script perl à l'arrache qui permet d'éviter de faire un enable de toutes les imprimantes (et qui m'évite de me pourrir mes logs ). C'est à lancer de la même manière qu'au dessus.
 
À adapter suivant votre configuration (lpstat ou enable ne se trouvent pas forcemment dans /usr/local/bin).
 
Voici le bout de code :

Je ne peux pas me résoudre à installer mandriva sur un serveur..
 
Il est vrai que ton script est plus propre que mon bourrin dans le cron..
Entretemps, j'ai pensé qu'en se servant de hald, (qui permet par exemple de spécifier une action à effectuer lors d'un branchage usb) cela serait pas mal non plus
C'est plutôt efficace, mais là encore, la correction du bug dépasserait toutes les solutions
 
+

c'est corrigé dans Mandriva ou dans les version 1.2 de CUPS.
 
or aucune distro stable n'inclut encore cups 1.2.

oui sinon on ne serait pas là en train d'essayer de contourner le problème avec des scripts vu que les serveurs nécessites des distributions dites-stables.

tu peux récupérer le fix de la 2006. en fait ils remplacent le backend habituel

Pour qu'une distribution soit dite stable, il faut avant tout que les paquets installés sur celle-ci soit marqués stables;
modifier des éléments composants ce paquet, c'est risquer de compromettre son équilibre, donc sa stabilité donc la stabilité du système général.  
 
Si je voulais "juste que ça marche", je me téléchargerais les source et je compilerai le tout mais tu l'as compris c'est pas le but.
Je suis donc contraint d'improviser avec des scripts qui contournent le problème en attendant la release stable..
 
Tu dois te dire que je me complique la vie, mais un serveur, c'est un serveur.. pas un poste de travail où tu peux t'amuser ceci-dit, j'ai rien contre le fait de s'amuser à installer/tester/ désinstaller/bidouiller/.. c'est ce que je fais à longueur de temps sur ma station de travail fedora ..
 
++