Description of problem: Adding or setting job-hold-until using lpoptions correctly changes the printers job hold setting, and the change is reflected in /etc/cups/lpoptions, but system-config-printer doesn't show that the option was added or set fhr the printer in question. Conversely, adding or setting the job-hold-until option from system-config-printer does not affect the options for that printer displayed by lpoptions, nor does system-config-printer change /etc/cups/lpoptions Settings such as Accepting Jobs configured through system-config-printer seem to be correctly reflected in lpoptions. Pairing a change to the Accepting Jobs setting from system-config-printer with a change to job-hold-until results in only the Accepting Jobs setting being changed as far as lpoptions is concerned. Restarting cups or the system does not help. Steps to Reproduce: 1. as root, create a new printer called "printer" with system-config-printer using default values 2. run lpoptions -p printer -o job-hold-until=indefinate 3. add and change the job-hold-until option to indefinite in system-config-printer 4. run lpoptions -p printer Actual results: No changes to the job-hold-until option in the "lpoptions -p" printer output Expected results: job-hold-until should have the value of indefinate in the "lpoptions -p" printer output Additional info: Attempting to remove the job-hold-until option from a configured pritner causes system-config-printer to crash. A dump follows: *** glibc detected *** python: free(): invalid next size (normal): 0x08933e48 *** ======= Backtrace: ========= /lib/libc.so.6[0x16709d] /lib/libc.so.6[0x1688c6] /lib/libc.so.6(realloc+0xfe)[0x16a94e] /usr/lib/libcups.so.2(ippReadIO+0x75e)[0xcd729e] /usr/lib/libcups.so.2(ippRead+0x59)[0xcd7549] /usr/lib/libcups.so.2(cupsDoFileRequest+0x2a2)[0xce3872] /usr/lib/libcups.so.2(cupsDoRequest+0x3e)[0xce3e0e] /usr/lib/python2.4/site-packages/cups.so[0xec9137] /usr/lib/libpython2.4.so.1.0(PyCFunction_Call+0x14d)[0x4698ed] /usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x4c2c)[0x4a41ac] /usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x4d5d)[0x4a42dd] /usr/lib/libpython2.4.so.1.0(PyEval_EvalCodeEx+0x845)[0x4a51b5] /usr/lib/libpython2.4.so.1.0[0x457080] /usr/lib/libpython2.4.so.1.0(PyObject_Call+0x37)[0x43eec7] /usr/lib/libpython2.4.so.1.0[0x445538] /usr/lib/libpython2.4.so.1.0(PyObject_Call+0x37)[0x43eec7] /usr/lib/libpython2.4.so.1.0(PyEval_CallObjectWithKeywords+0x7c)[0x49e9dc] /usr/lib/libpython2.4.so.1.0(PyInstance_New+0x6d)[0x44939d] /usr/lib/libpython2.4.so.1.0(PyObject_Call+0x37)[0x43eec7] /usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x3182)[0x4a2702] /usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x4d5d)[0x4a42dd] /usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x4d5d)[0x4a42dd] /usr/lib/libpython2.4.so.1.0(PyEval_EvalCodeEx+0x845)[0x4a51b5] /usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x42e5)[0x4a3865] /usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x4d5d)[0x4a42dd] /usr/lib/libpython2.4.so.1.0(PyEval_EvalCodeEx+0x845)[0x4a51b5] /usr/lib/libpython2.4.so.1.0[0x456faa] /usr/lib/libpython2.4.so.1.0(PyObject_Call+0x37)[0x43eec7] /usr/lib/libpython2.4.so.1.0[0x445538] /usr/lib/libpython2.4.so.1.0(PyObject_Call+0x37)[0x43eec7] /usr/lib/libpython2.4.so.1.0(PyEval_CallObjectWithKeywords+0x7c)[0x49e9dc] /usr/lib/libpython2.4.so.1.0(PyObject_CallObject+0x2c)[0x43fa4c] /usr/lib/python2.4/site-packages/gtk-2.0/gobject/_gobject.so[0x25dff7] /lib/libgobject-2.0.so.0(g_closure_invoke+0x12b)[0x36ed9b] /lib/libgobject-2.0.so.0[0x37f433] /lib/libgobject-2.0.so.0(g_signal_emit_valist+0x8c7)[0x380957] /lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0x380b19] /usr/lib/libgtk-x11-2.0.so.0(gtk_button_clicked+0x53)[0x5061cd3] /usr/lib/libgtk-x11-2.0.so.0[0x506391e] /lib/libgobject-2.0.so.0(g_cclosure_marshal_VOID__VOID+0x49)[0x37c0f9] /lib/libgobject-2.0.so.0[0x36d589] /lib/libgobject-2.0.so.0(g_closure_invoke+0x12b)[0x36ed9b] /lib/libgobject-2.0.so.0[0x37f8ca] /lib/libgobject-2.0.so.0(g_signal_emit_valist+0x8c7)[0x380957] /lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0x380b19] /usr/lib/libgtk-x11-2.0.so.0(gtk_button_released+0x53)[0x5061d63] /usr/lib/libgtk-x11-2.0.so.0[0x5061dc1] /usr/lib/libgtk-x11-2.0.so.0[0x5132b00] /lib/libgobject-2.0.so.0[0x36d589] /lib/libgobject-2.0.so.0(g_closure_invoke+0x12b)[0x36ed9b] /lib/libgobject-2.0.so.0[0x37fa83] /lib/libgobject-2.0.so.0(g_signal_emit_valist+0x68f)[0x38071f] /lib/libgobject-2.0.so.0(g_signal_emit+0x29)[0x380b19] /usr/lib/libgtk-x11-2.0.so.0[0x5247748] /usr/lib/libgtk-x11-2.0.so.0(gtk_propagate_event+0x183)[0x512bed3] /usr/lib/libgtk-x11-2.0.so.0(gtk_main_do_event+0x317)[0x512d0d7] /usr/lib/libgdk-x11-2.0.so.0[0x4fb214a] /lib/libglib-2.0.so.0(g_main_context_dispatch+0x182)[0x4e0c442] /lib/libglib-2.0.so.0[0x4e0f41f] /lib/libglib-2.0.so.0(g_main_loop_run+0x1a9)[0x4e0f7c9] /usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xb4)[0x512d554] /usr/lib/python2.4/site-packages/gtk-2.0/gtk/_gtk.so[0x6335b0] /usr/lib/libpython2.4.so.1.0(PyEval_EvalFrame+0x49a8)[0x4a3f28] ======= Memory map: ======== 00101000-00238000 r-xp 00000000 fd:00 10586678 /lib/libc-2.5.so 00238000-0023a000 r-xp 00137000 fd:00 10586678 /lib/libc-2.5.so 0023a000-0023b000 rwxp 00139000 fd:00 10586678 /lib/libc-2.5.so 0023b000-0023e000 rwxp 0023b000 00:00 0 0023e000-00241000 r-xp 00000000 fd:00 15503394 /usr/lib/python2.4/lib-dynload/fcntlmodule.so 00241000-00242000 rwxp 00003000 fd:00 15503394 /usr/lib/python2.4/lib-dynload/fcntlmodule.so
The real problem here is the crash. The rest is an unfortunate confusion caused by the two systems of providing job defaults. The older system, lpoptions, sets job defaults on *client* systems, the machines that the print jobs are sent from. /etc/cups/lpoptions is read by libcups when sending a job to a CUPS server. Yes, this may be on the same machine, but commonly the CUPS server is a separate machine altogether, and in this case the job defaults need to be set on all of the client machines. The newer system is network default options, and the options are stored in the *server* configuration. Incoming jobs have those default options applied if they are not already set by the client. To set a network default option from the command line you can use 'lpadmin [-h server] -p printer -o option=value'. The system-config-printer tool in Fedora Core 6 uses the network default options method exclusively, while in Fedora Core 5 and earlier the older lpoptions method was used (network default options are new to CUPS 1.2). I haven't been able to reproduce that crash though. Can you get it to happen again? If so, please make a note of exactly what steps you took. Thanks.
Created attachment 154576 [details] crash dump for system-config-printer when attempting to remove a printer option
Thanks for the insights about the changes. I suspected something like that was happening, although the fact that from one action some changes took, while others didn't, threw me off. Steps to reproduce the system-config-printer crash: 1. install FC6 from DVD 2. yum update cups* 3. yum update system-config-* 4. run system-config-printer as root 5. set up a new ipp printer 6. add job-hold-until option using job options tab, with value of indefinite 7. click apply 8. close system-config-printer 9. run system-config-printer 10. select printer set up in 5 11. click job options tab 12. click remove next to job-hold-until 13. click apply At this point, system-config-printer crashes with the attached dump.
Thanks for the detailed instructions. From the backtrace I got from a core-dump with MALLOC_CHECK_=2 set in the environment, I think this is to do with the table resizing on that screen. Fedora 7 will have a re-worked version of that screen, although the specific case of job-hold-until doesn't work there for a different reason. :-/ Is job-hold-until the option you need to set on that queue? I'm curious to know the reason you mention that particular option -- do you want queued jobs to be individually approved by an administrator or something?
Yes, we're using job-hold-until as part of our DiscoverStation multi-user public computing solution to enable staff to manually release print jobs through a web-based AJAX interface. Holding print jobs also enables us to do some neat tricks with dbus to notify users of print job size and cost to allow them to abort unwanted/broken/excessive print jobs before they hit the printer (in both the paid and the non-print cost recovery scenarios). Regarding the crash, we're currently advising customers to delete and recreate the printer instead of fiddling with the job options if they want to transition from gated printing to free printing.
(Wow, cool stuff!) My plan for fixing this is to implement the missing bits in the Fedora 7 package that will make it work, then upgrade the Fedora Core 6 package to match. Unfortunately it means that the "Job Options" screen layout will change in FC6, but it is much more robust and easier to understand.