[Printing-architecture] printers.conf frequently gets truncated to zero length after unclean shutdowns

Michael Sweet msweet at apple.com
Tue Jul 23 12:05:06 UTC 2013


On 2013-07-23, at 1:15 AM, Eric Sandeen <sandeen at redhat.com> wrote:
>> ...
>> The problem with fsync() is that it is a blocking API.  Blocking
>> cupsd (single-threaded daemon process) is *not* a good idea.
>> Future versions of cupsd will be multi-threaded where we can look at
>> calling fsync or fcntl(fd, F_FULLSYNC), but adding fsync calls now
>> will just cause more problems that it will solve.
> How often is the file rewritten?  TBH I didn't expect that the cups
> daemon would be terribly latency-sensitive, at least not to the point
> where losing it was better than taking the perf hit from an fsync...

printers.conf gets rewritten any time the state or configuration changes.  We *do* try to minimize the number of writes by coalescing them into 30 second snapshots, but that will still be often enough that I wouldn't want to chance adding a call that could block for a long time (if printers.conf is on a network filesystem, for example).

Michael Sweet, Senior Printing System Engineer, PWG Chair

More information about the Printing-architecture mailing list