Comment 0 for bug 177075

Binary package hint: cupsys

From CUPS 1.3.x, except at startup, network interfaces are not anymore polled for changes (appearance and disappearance of a network interface, and any IP address or mask change).

This means that in a CUPS configuration allowing local connection (sharing of local printer on local network), any connection from a local ip coming on an interface that appeared after CUPS startup (in my case a vpn one), is refused (403 error). And as a result, obviously, printer is not shared on the local network related to this interface.

The user has to restart cupsd in order to make cups accept connection on these new network interfaces.

Until recently this was difficult to see, because there was another problem affecting sharing in gutsy and hardy, that was necessitating a restart of cupsd (the late start of avahi, recently fixed in bug 173470 ).

I have tracked it down and in fact, the problem appeared with revision 6123 (pre 1.3.0) in cups svn trunk, that was landing a multiplatform management of poll (use of poll(), epoll(), or kqueue() depending of the platform). Part of this checkout moved the Mac OS X specific call to cupsdUpdateSystemMonitor in main.c to a select callback in sysman.c (we don't care), but in the same time it removed (inadvertantly) in main.c the set of NetIFUpdate to 1 every minute or so for all other OS (here, we care ;-) )

See:
svn diff -c 6123 http://svn.easysw.com/public/cups/trunk/scheduler/main.c (look for NetIFUpdate)
and more generally
svn diff -c 6123 http://svn.easysw.com/public/cups/trunk/scheduler/ (to check that this checkout did not reintroduced the code removed anywhere in the scheduler else (except for Mac OS X) )
svn log -r 6123 http://svn.easysw.com/public/cups/trunk/

I have reported the problem upstream on Sunday :
http://www.cups.org/str.php?L2631

with a patch :
http://www.cups.org/strfiles/2631/interface-update_v2.patch