[Printing-architecture] printers.conf frequently gets truncated to zero length after unclean shutdowns
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