Rodney Baker wrote:

On Fri, 6 Nov 2009 04:46:43 Marc Chamberlin wrote:

...

So I have a question - When I configure a printer via YaST, and get all done, is not YaST suppose to restart the CUP'S daemon? I should think so! The fact that it doesn't cost me a LOT of debugging time. I finally gave up on trying to use YaST and configured the CUP's server by hand. Once I got CUP'S up an running I discovered that YaST was NOT starting up the CUP's server daemon, by finally realizing that something was terribly unexpected was happening after using YaST, and by subsequently checking with an "rccups status". So, I am having to do an "rccups start" each and every time after I use YaST to configure my printer! (which starts the CUP's daemon without any problem) Why should I have to do this? Am running SuSE 11.0. x86_64 architecture.

Marc,

Open System-> System Services (Runlevel) in Yast Control Centre and see if the cups service is set to enabled.

Yes it was one of the first things I checked. It was not running initially when I was trying to first set up my laptop to print. So I was trying to use YaST to configure the printer and EXPECTING upon correct configuration of the printer that the CUPs daemon would start up because everything was "correct".

...

If this was the way YaST was designed, then someone needs to have their head examined! The pattern for configuring any other server, that I use, has been to restart the daemon for it automatically, when finished. And if YaST is suppose to restart the CUP'S daemon, why doesn't it check to verify that the daemon did indeed successfully restart, and report to the user, via a clear warning message, that the restart failed?

Bugs have been known to creep in without the developers realising ;-)

...

I looked at the y2log file, which is about as clear and understandable as mud, and see several messages generated by something called Crash.ycp.. Are these failure messages? Such as -

2009-11-05 09:41:29 <1> marcslaptop(13748) [YCP] Crash.ycp:51 Read settings: $["all_failed":["printer.ycp"], "last_done":"printer_detection", "last_failed":["printer.ycp"]] 2009-11-05 09:41:29 <1> marcslaptop(13748) [YCP] Crash.ycp:68 Written settings: $["all_failed":[], "last_done":"printer.ycp", "last_failed":[]]

What desktop are you using (Gnome, KDE or any others)? What versions of yast2, yast2-control-center, yast-2-control-centre-[gnome|qt] and yast2-printer are you running?

Please do rpm -qa | grep 'yast' and post the output.

I am using KDE 3.5. Here is the output from the rpm query that you requested. marcslaptop:/var/log/cups # rpm -qa | grep 'yast' yast2-update-2.16.10-4.1 yast2-irda-2.16.1-25.1 yast2-runlevel-2.16.5-15.1 yast2-security-2.16.1-16.1 yast2-iscsi-client-2.16.14-6.1 yast2-users-2.16.33-6.1 autoyast2-installation-2.16.19-0.1 yast2-pam-2.16.2-17.1 yast2-scanner-2.16.10-13.1 yast2-support-2.16.1-6.1 yast2-tv-2.16.6-7.1 yast2-network-2.16.48-3.1 yast2-printer-2.16.32-3.1 yast2-qt-2.16.53-5.1 yast2-libyui-2.16.48-3.1 yast2-ncurses-2.16.27-8.1 yast2-xml-2.16.1-14.1 yast2-ntp-client-2.16.9-11.1 yast2-mouse-2.16.1-26.1 yast2-sysconfig-2.16.0-28.1 yast2-nis-client-2.16.3-6.1 yast2-repair-2.16.12-4.1 yast2-online-update-frontend-2.16.15-6.1 yast2-inetd-2.16.0-27.1 yast2-trans-stats-2.15.0-87.1 yast2-core-2.16.51-6.1 yast2-ycp-ui-bindings-2.16.47-5.1 yast2-slp-2.16.0-25.1 yast2-hardware-detection-2.16.1-49.1 yast2-2.16.71-6.1 yast2-apparmor-2.16.4-4.1 yast2-vm-2.16.5-7.1 yast2-x11-2.15.12-15.1 yast2-ldap-2.16.0-52.1 yast2-restore-2.16.2-26.1 yast2-packager-2.16.53-3.1 yast2-metapackage-handler-0.8.5-16.1 yast2-ldap-client-2.16.16-6.1 yast2-mail-2.16.6-2.1 yast2-pkg-bindings-2.16.42-0.2 yast2-qt-pkg-2.16.49-0.1 yast2-backup-2.16.7-0.1 yast2-country-data-2.16.26-6.1 yast2-storage-lib-2.16.26-0.1 yast2-sound-2.16.11-6.1 yast2-firewall-2.16.2-25.1 yast2-country-2.16.26-6.1 yast2-bootloader-2.16.20-0.1 yast2-installation-2.16.50-3.1 yast2-add-on-2.16.8-6.1 yast2-profile-manager-2.16.1-27.1 yast2-control-center-2.16.2-11.1 yast2-control-center-qt-2.16.2-11.1 yast2-theme-openSUSE-2.16.38-2.1 yast2-perl-bindings-2.16.7-14.1 yast2-nfs-client-2.16.1-26.1 yast2-tune-2.16.2-2.1 yast2-online-update-2.16.15-6.1 yast2-sudo-2.16.1-27.1 yast2-transfer-2.16.1-76.1 yast2-storage-2.16.26-0.1 yast2-kerberos-client-2.16.11-9.1 yast2-samba-client-2.16.9-3.1 yast2-registration-2.16.7-4.1 yast2-samba-server-2.16.3-15.1 yast2-trans-en_US-2.16.9-1.1 yast2-ncurses-pkg-2.16.14-0.4

...

If so, this is an ugly way to report a problem to a user! IMHO. I usually grep such log files for words like "Error" or "Warning" or even "[E]" and "[W]" with is sometimes used. And if these are error messages, then they give no guidance to a user has to how to fix such the problem...

Marc...

Check bugzilla and see if someone has already logged a report on it. If not (and it isn't resolved by fixing any issues that might turn up by checking and if necessary fixing what I mentioned above), file a bug report there.

Thanks Rodney.. OK I will look into bugzilla.... Marc..

Regards, Rodney.

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Patrick Shanahan wrote:

* Marc Chamberlin [01-01-70 12:34]:

...

So I have a question - When I configure a printer via YaST, and get all done, is not YaST suppose to restart the CUP'S daemon? I should think so! The fact that it doesn't cost me a LOT of debugging time. I finally gave up on trying to use YaST and configured the CUP's server by hand.

I believe that I saw recently that cups via a web browser, localhost:631, is the preferred way to setup a printer in openSUSE, rather than YaST.

And it is still required to restart the cups daemon by hand.

UGH! The problem with using the web browser is that if the server is not running, because an improper configuration file is preventing it from running, the user has no clue as to what the problem is and therefore cannot use the web browser as a guide to properly set up and configure CUPs! And because YaST is apparently buggy or mis-designed, the poor user falls into a trap because it is the only other obvious tool available to graphically guide him/her to a solution. (which any lazy user will try an use, rather than dig into tons of documentation on how to configure CUPs at a lower level) It therefore becomes a Catch22 with no indication being given to the user as to what might be wrong, if and when he cannot get the server running. Therefore, if YaST is going to provide a GUI to help setup and configure printers, it is imperative that YaST also automatically attempt to start the cups daemon and report the results to the user. I EXPECT YaST to be a well tested guide and this is a very disappointing failure! For YaST to silently not start CUPs, and report no problems, leaves the user in the dark. That is why I had to spend so much time debugging this mess, and after hours and hours of digging (and requesting help here and with several other groups) I finally came to realize that YaST was not behaving as I expected it to... Especially in my case where I am using a CUPs server on a different machine to handle the actual printing for all my Linux clients, and just wanted my laptop to forward print requests to it.. (That central server then forwards the print jobs on to a Windoz machine where my printer is actually connected to!) I had NO IDEA where, in all these layers the problem laid. Marc.. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Patrick Shanahan wrote:

* Marc Chamberlin [11-05-09 21:35]:

...

Therefore, if YaST is going to provide a GUI to help setup and configure printers, it is imperative that YaST also automatically attempt to start the cups daemon and report the results to the user. I EXPECT YaST to be a well tested guide and this is a very disappointing failure!

What is the bug report # that you filed?

Bug #553147 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Johannes Meixner wrote:

Hello,

On Nov 5 21:34 Marc Chamberlin wrote (shortened):

...

Bug #553147

To avoid possible further confusion:

The issue here is about openSUSE 11.0!

I.e. with the old YaST printer module yast2-printer-2.16.32 which is known to destroy sometimes /etc/cups/cupsd.conf because it uses the YaST "INI" agent to manipulate cupsd.conf but the "INI" agent is either insufficient for config files like cupsd.conf or nobody can tame the "INI" agent beast to work even for cupsd.conf ;-)

But as far as I remember the "INI" agent did not crash YaST. I.e. the crash here seems to have another reason.

Regardless what the reason was in this case:

When the cupsd config file /etc/cups/cupsd.conf is broken there is a /etc/cups/cupsd.conf.default installed which you can copy to /etc/cups/cupsd.conf as root with cp /etc/cups/cupsd.conf.default /etc/cups/cupsd.conf to start cupsd with a clean default cupsd config file.

If even this does not help (e.g. when the CUPS spool files are totally messed up), see http://en.opensuse.org/SDB:CUPS_-_Reinstalling_the_Printing_System regarding "Reinstalling the Printing System"

Kind Regards Johannes Meixner

Johannes - I updated the bug report because I think you are confused about my point. The issue I am reporting is not about whether the cupsd.conf file is mis-configured or not. The issue of the bug report is about the fact the the printer setup module of YaST is not (apparently) starting up the CUPs daemon, or testing its status, when the user completes the process of setting up a printer. This leads to a great deal of confusion if the user is not aware of this fact, because he/she will expect to be able to print something once the process of setting up the printer is complete. If the CUP's daemon is not running, and the user is unaware of this fact, then the user will be unable to print anything, and left in the dark wondering why... Marc Chamberlin.... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org