Description of problem: Cups does not generate /etc/printcap file on start. No, there are no error messages in /var/log/cups/{access,error,page}_log. But sometimes (rarely) it does regenerate it. I have failed to find out under what circumstances that had happened. Version-Release number of selected component (if applicable): 1.2.7-1.3.fc6 previous versions had the same bug How reproducible: 90% Steps to Reproduce: 1. Change /etc/printers.conf, e.g. add new printer (or just remove the /etc/printcap). 2. restart cups service Actual results: /etc/printcap remains the same (or is not recreated, if absent). Expected results: Should update (or regenerate) printcap in accordance with the printers.conf. Additional info: Maybe cupsd is confused by the /etc/cups/cupsd.conf being a symlink? I have several printers.comf files for different locations (that's a notebook) and switch between them using symlink. I believe cupsd shouldn't care about it and must get info about the file using stat() function which does follow symlinks.
CUPS will only generate /etc/printcap when it believes it needs to. If you are changing the printers.conf file by hand CUPS won't know the printcap file is out of date. Use 'lpadmin' to add printers, or else use the CUPS web interface or the system-config-printer tool provided in Fedora.
THIS IS A BUG!!! 1. Cups MUST regenerate printcap if it is absent on start/restart. 2. I haven't said that I had edited printers.conf by hand. I had tried both ways: delete/readd and change printer via cups web interface, as well as to edit printers.cups by hand. None had led to printcap update or creation if it had been earlier deleted. This can be selinux-dealt problem as cups-related messages appear in audit.log.
On start and reload it looks like cupsd does indeed generated a printcap file. What does 'ls -Z /etc/printcap' say? And what cups-related messages appear in audit.log?
Created attachment 143047 [details] cups related messages from /var/log/audit/audit.log created by `grep -i 'cups' /var/log/audit/audit.log'
ls -Z /etc/printcap -rw-r--r-- root root system_u:object_r:cupsd_rw_etc_t /etc/printcap cat /var/log/audit/audit.log | audit2allow | grep -i 'cups' | sort allow cupsd_t cupsd_etc_t:lnk_file rename; allow cupsd_t etc_runtime_t:file write; allow cupsd_t etc_t:dir write; allow cupsd_t etc_t:file setattr; allow cupsd_t user_home_t:file write;
Your printers.conf file seems to have label root:object_r:etc_runtime_t:s0 which is incorrect. Perhaps this is as a result of the way you are installing the link. I don't think it can ever really work to have symbolic links for cupsd_rw_etc_t files such as cupsd.conf and printers.conf, simply because CUPS will use atomic rename() when writing changes to them. I've reported this upstream to see if there is any desire to support this mode of operation.
So the upstream reply is that you should use a symlink for /etc/cups -- or else have /etc/cups.profile1, /etc/cups.profile2 etc -- rather than symlinks for the individual configuration files.
That's very strange (not to say stupid) idea to copy the whole /etc/cups tree (contains lots of standard stuff) in order to make changes to a couple of files. Looks like cups team resides in the redmond (WA) vicinity... :-/