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

[Michael Sweet]

Steve,

On 2013-07-23, at 1:38 PM, Steve Bergman <sbergman27 at gmail.com> wrote:
> On 07/23/2013 11:40 AM, Michael Sweet wrote:
>> With due respect, having worked on everything from bare bones 8-bit controllers through high-end multi-CPU/core servers/workstations,  I am well aware of such "real world" situations and the (often unrealistic) expectations involved.
> 
> There is nothing "unrealistic" about expecting not to lose configuration info for 112 printers the majority of times that a server shuts down uncleanly. That's something I was able to take for granted for over a decade. Punting the issue by saying it's an "unrealistic expectation" is not very convincing.

In this case the unrealistic expectation is that if you pull the plug on a running system that you won't lose any data.  Systems that offer that level of assurance are designed accordingly and generally include some form of backup power that will allow pending writes to complete.

Even if we added fsync calls in cupsd, that still doesn't guarantee that the data will actually get on disk/flash.  For that we need to sync() and do some lower-level stuff to ensure that the hardware is told to write the data immediately, and then wait to hear back that the data has been written.

So, set your expectations accordingly - fsync might not fix this issue for you.

>> Good luck.  From our own experience, calling fsync on a file on a network file system resulted in sporadic, long-duration delays (up to 60 seconds in our testing) while local spinning disks tended to be in the 1-2 second range.  SSDs actually had slightly longer delays depending on how much data was buffered up...
> 
> I'm taking that to mean that you're not really interested in what my results show, and that you consider this to be a RH problem and not a general CUPS problem. So I'll be posting the results to the RH Bugzilla ticket.

Take this to mean that we have operational experience that makes us both leery of enabling fsync and recognize that fsync isn't a magic bullet for the problem you are experiencing.

> FWIW, PostgreSQL makes the fsync a configurable option. Not fsync'ing by default is, in my opinion irresponsible of cupsd.

Your opinion might be different if you were one of the millions affected by the fsync issues we previously had.

> An option should at least be provided to allow responsible administrators to tell it to handle its configuration file updates properly. (Yes, I understand that you probably try to keep the number of options down. But this is a very basic and important issue.)

I don't agree with your wording, but as I mentioned in a separate message I have filed a bug to track adding a SyncOnClose directive in 1.7.0.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair