|
Bugzilla – Full Text Bug Listing |
| Summary: | yast2-printer crashes with SIGPIPE | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 10.3 | Reporter: | Petr Danecek <petr.danecek> |
| Component: | YaST2 | Assignee: | Michal Zugec <mzugec> |
| Status: | RESOLVED FIXED | QA Contact: | Johannes Meixner <jsmeix> |
| Severity: | Major | ||
| Priority: | P3 - Medium | ||
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE 10.3 | ||
| Whiteboard: | |||
| Found By: | Customer | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: | /var/log/YaST2/y2log | ||
|
Description
Petr Danecek
2008-01-17 15:12:40 UTC
It is no blocker bug because there are several other printer setup tools available (i.e. a workaround exists). Michal, I don't know if the reason is in yast2-printer, in YaST or somewhere in the underlying base system. please attach also YaST log Created attachment 191000 [details]
/var/log/YaST2/y2log
Last 3 lines are: 2008-01-18 08:16:26 <0> mylap(6968) [agent-cups] scr/Y2AgentComponent.h(evaluate):99 Going to evaluate `Read (.printers) 2008-01-18 08:16:26 <0> mylap(6968) [agent-cups] scr/Y2AgentComponent.h(evaluate):120 After code evaluation: `Read (.printers) 2008-01-18 08:16:33 <3> mylap(6968) [liby2] genericfrontend.cc(signal_handler):59 got signal 2 at YCP file Printer.ycp:3 that means: 1 - try "hwinfo --printer" 2 - echo '`Read(.probe.printer)' | /usr/lib/YaST2/bin/y2base stdio scr 3 - it's SIGINT, not SIGPIPE (is log file really corresponding to backtrace?) Sorry for not giving an information detailed enough: There is not printer connected directly to my computer, I want to use a network printer. The hwinfo gives no output and so does not the command 2. The program "y2base printer qt" does not crash, it comes to "Load current settings" and never ends. I have to CTRL+c it. However, when it is run in gdb, it gives the above backtrace. I was told that the problem is probably in the cups library..? Klaus, seems to be CUPS problem, right? Michal: sorry, but I'm not sure if so. Reason is that we switched to cups-1.3.x meanwhile (remember my e-mails regarding this), and it might have happened a change in the library calls. Please tell me, if you changed yast2 to the new library. Klaus, this bugreport is against 10.3, means related to CUPS-1.2 Umpf. Sorry, didn't realized this (maybe a Monday morning effect? :-) Petr Danecek: I need more information... How long did you wait for program to terminate? Reason: if network is not setup properly, it takes 5 minutes till the queries time out. This is not possible to change, as these values are set in the SSL/HTTP protocol and are given by some standardization organizations. Fix for this: setup a correct network: DNS, IP adresses, etc. Disable firewalls at server and on host, which drop TCP packets. set needinfo to reporter, Peter try above, please I waited certainly for more than 5 minutes. Also, the program does not seem to just wait for a time out. It exhibits some quite activity, see the output from top: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 3251 root 15 0 43520 2064 1416 S 50 0.2 11:05.02 cupsd 4148 root 25 0 284m 49m 19m R 40 4.9 9:54.19 y2base Also, in the backtrace above it can be seen that the program recieves SIGPIPE. I tried to reproduce it, but failed. Well the chances that we find the cause of the problem are not very high, :( but I'll try my test. The last related thing I saw in the yast logfile was: "/usr/bin/lpstat -r 2>/dev/null" This program terminates on my machine in <1 second. How about your machine? So, I need this information: - cups version. Output of: rpm -q --changelog cups | head - cups logfiles: remove current ones: rm -f /var/log/cups/error_log start program again attache to this bug: /var/log/cups/error_log - cups configuration files: attache to this bug /etc/cups/* (and subdirs) Please note that there might be confidential data stored there (passwords) -> make a copy and remove those data before attaching them - I saw that you'd chosen x86_64 (e.g. AMD64) as architecture is this correct? Voila! Problem solved!! Thanks for the tip to look in /var/log/cups/error_log. It was full of messages that tcpwrappers deny access from 127.0.0.1: tcp_wrappers refused connection from 127.0.0.1, ip=127.0.0.1 Adding the line "cupsd: 127.0.0.1" in /etc/hosts.allow solved the problem. Too bad that the scripts gave no hint about the cause of the problem. Thanks very much for your help!! *smile* as said before: a network issue. :-) Nevertheless, I think you should consider, if its not a good idea allow *all* services connection to localhost. Add a line "ALL: 127.0.0.1" in /etc/hosts.allow then. Well, that will be definitely the first thing which I will try before commiting any other problems to bugzilla. :-) Thanks again for your time & help. |