Bugzilla – Bug 595612
yast2-printer: add initial responsive test if CUPS server is accessible
Last modified: 2016-04-15 11:00:20 UTC
User-Agent: Mozilla/5.0 (compatible; Konqueror/4.4; Linux) KHTML/4.4.2 (like Gecko) SUSE Printer dialog should use background thread for long-running networking operations and should be fail-safe and user-friendly on the rainy-day scenarios - not only when everything is fine (all remote servers are running and accessible). Reproducible: Always Steps to Reproduce: 1. Configure the system to make all printing to remote cups server 2. Switch off computer running this cups server (or disconnect it from network or change ip address or stop cups server running on it) 3. Open yast printer configuration dialog Actual Results: I can see the busy cursor for 1 or 2 minutes, then receive dialog "cups server not accessible" with ok button - click ok and get access to the config dialog, but once I click somewhere on it I again receive busy cursor for 1/2 mins and can do nothing with this. Expected Results: I must be able to interact with the config dialog while it is trying to connect to remote cups server, see the connection progress info and be able to cancel it before it finish.
First and foremost: There is no such thing as (background) threads in YCP (YaST's own programming language). For the actual root cause in this particular case see https://bugzilla.novell.com/show_bug.cgi?id=577936#c8 In general it is a duplicate of bug #489077 which I reported to find a solution in YaST but in the end it was merely re-assigned back to me. But I cannot fix it because my printer module can only use the lower-level YaST machinery via YCP but I am not at all a YaST-internals programmer to implement something in the low-level YaST machinery. What I might do in this particular case while it tests if the cupsd is accessible is to show some kind of busy popup notification so that the user is at least informed what goes on, compare item c) at https://bugzilla.novell.com/show_bug.cgi?id=489077#c0 *** This bug has been marked as a duplicate of bug 489077 ***
Thank's for the responce. Want to add some additional comments. I still think this particular issue might have simple workaround. The bad thing is that when I start the dialog 1st time, see the busy cursor for few minutes; even the worst thing is that when it a last allowes me to interact with window - I click on any place in the printer table and I receive this busy cursor again and again. This can be avoided with the following workflow: - wait busy cursor when the dialog opens the 1st time - on error do not pop up the error dialog - instead show the error panel right on the configuration window (probably instead of printer table) - with error message "cups server at 192.168.1.1 is not accessible" and "retry" button below. - the user will be able to click on any place on the window and the busy cursor will not be back until the user clicks on "retry".
When you configure your system to make all printing via one single remote cups server, there is already a mandatory test if this server is accessible because it is crucial that this server is accessible. What is missing is that initially when the module starts up, the same test should be run and if it fails you could decide what to do (cancel or choose another CUPS server). But it might happen that even for this test, you have to wait until the low-level DNS timeouts have passed. I need to check this on my own system... If DNS timeouts delay even this test, I don't have a good idea what to do because in the YaST printer module I cannot do anything against low-level DNS timeouts...
>I cannot do anything against low-level DNS timeouts... I think it is ok if printer list check/cups server test can take visible amount of time - this is network operation and there are many things that can make it to take a long time. For current issue I think there could be made an improvement in UI, so this long-running operation would not launched by accident - it should be only when the users knows what he is doing. So, for example I have configured the system to use remote cups server and this worked ok, then switched off yast, switched off remote cups server and try to start yast printer config again. 1. Yast opens on "Printer configurations" page and locks with busy cursor while trying to load printer list from unavailable server - for now this is ok (though background threading could make much improvements here if it were available). 2. When the printer list check operation finishes, it shows me error window, I close it and receive "Printer configurations" page without busy cursor - for now this also ok. 3. I click anywhere on the printer table with the mouse and receive busy cursor for minute or 2 again - this is not ok and can be changed - printer list check operation should not be launched when I click on the printer table. 4. Ater busy cursor is gone again and "Printer configurations" page is again available, intuitevely I click on the "Remote" checkbox (my intuitive idea was that if I exclude remote devices from the list, the long-running remote cups server check will be triggered) - and receive busy cursor for minute or 2 again - this is not ok and can be changed in the ui. 5. Only after few tries I realized that when the busy cursor is gone I can click on the "Print via Network" page and disable remote cups server there - after that the "busy cursor for 2 minutes on any random click hell" was gone. So, the suggestion is to add "remote cups server not available" mode to the configuration UI - in this mode the config dialog would not try to deal with remote cups server on random user action and for example would show panel built-in the config window (not on separate popup dialog) with warning message like "remote cups server xxx not available" and 2 buttons: "reconnect" and "disable printing via this server".
Fixed in YaST SVN revision 61839 In overview.ycp added an initial responsive test if CUPS server is accessible by using the TestClientOnlyServer function which was moved from printingvianetwork.ycp to Printer.ycp and adapted so that it can be used both for overview.ycp and printingvianetwork.ycp. If the TestClientOnlyServer function fails in overview.ycp there is a popup question "Do no longer use the inaccessible CUPS server 'name.domain'?" with the recommendation text "To proceed, you should agree that 'name.domain' will be no longer used." If the user isists to still use an inaccessible CUPS server there is a popup warning "A non-accessible server leads to an endless sequence of delays and failures." The crucial enhancement is the option to no longer use an inaccessible CUPS server. Such an option was missing. The "The CUPS server 'name.domain' is not accessible" popup with only the OK button was insufficient because the user could not do anything else than to click the OK button which led to the endless sequence of delays and failures.
Submitted to openSUSE:Factory via submitrequest 38582 YaST:Head/yast2-printer -> openSUSE:Factory 'Fixed bnc#595612 and bnc#596526 and two testpage printing issues.'
The above fix needs an improvement to avoid needless popups: Do no longer show positive feedback in TestClientOnlyServer because this would cause annoying popups for the user because in most cases TestClientOnlyServer is called implicitely without a button click. Only show positive feedback in printingvianetwork.ycp when TestClientOnlyServer is called by the user when clicking the [Test Server] button. Submitted yast2-printer version 2.19.9 to openSUSE:Factory via submitrequest 39128: "Improved fix for bnc#595612".
This is an autogenerated message for OBS integration: This bug (595612) was mentioned in https://build.opensuse.org/request/show/38582 Factory / yast2-printer https://build.opensuse.org/request/show/39128 Factory / yast2-printer