Is ~/.cups/client.conf reloaded when it is changed?

[karl runge]

> Something you could do is make a SSH tunnel from localhost to the
> actual server, and just put:
>
>      ServerName localhost:port
>
> in the client.conf file - then you just change the tunnel when
> changing servers, independent from CUPS...

Yes, that is exactly what my VNC application:

        http://www.karlrunge.com/x11vnc/ssvnc.html
        http://www.karlrunge.com/x11vnc/#faq-cups

currently does.

BTW, I posted this question not regarding my own personal use
of CUPS and VNC--for which I think your suggestion would work
well--but rather for the general deployment of the above app.

In any event, the problem arises because the most common use
of the VNC application is to connect to an _already existing_
X11 or MacOS X desktop session.  At that point it is too late to
interpose on CUPS for the running desktop apps: some will have
already had CUPS print dialogs via libcups.

So when my VNC application disconnects and the SSH tunnel is
torn down, the most it can do is restore client.conf to its
previous state.  This will leave some of the printing apps in a
state of limbo since they do not reread client.conf.  They need
to be restarted for normal printing to work again.

As an aside, there is a less used 'Terminal Services' mode of
my VNC app.  In this case it actually starts a virtual X-server
(Xvfb) and the user's desktop session.  In this mode I simply
have it set CUPS_SERVER for the entire desktop session so CUPS
can interposed at will.

I can understand your desire to not want to stat(2) these client
config files regularly.  I don't believe there would be any
significant performance hit (and one could cache the result for
5-15 seconds just to be sure).  However, I do believe there is an
increased risk of getting hung-up with, say, overloaded or down
NFS servers.  With that and similarly increased risks, I would
be reluctant to add it to widespread infrastructure like CUPS,
except perhaps if it were off by default.

I'm guessing users and admins would be pleased if any changes
to /etc/cups/client.conf and ~/.cups/client.conf were picked up
without having to restart apps (I know I typically keep firefox
running for 1-2 months between restarts.)  But, I could be
completely wrong about that and most actually prefer the
current behavior.

Thanks for your time responding.  I have documented in my app
a workaround where they disable the client.conf management
and instead manually add an ipp network printer (that uses the
tunnel port) to their "real" CUPS server's queue if they have the
permissions to do that.  Although this is less "magical" than how I
initially thought client.conf worked, it seems to work fairly well.

Best regards,

Karl