On Fri 25 May 2018 at 21:23:13 +0200, Francesco Poli wrote: > On Fri, 25 May 2018 19:23:20 +0100 Brian Potkin wrote: > > > 3. No IdleExitTimeout in cupsd.conf. The default is 60 seconds. > > I have instead: > > $ grep IdleExit /etc/cups/cupsd.conf > IdleExitTimeout 60 > > I can try without this option set, even though I would prefer to have > the opportunity to set a different timeout, should I decide so...
I also used IdleExitTimeout 20 in my tests. The outcome was the same. > > > > 4. 'systemctl daemon-reload' and 'systemctl restart cups'. > > That's what I did after enabling socket activation, too. > > > > > a) lpq, lpadmin and lpstat access cupsd and all lead to its becoming > > inactive after the 60 seconds timeout is over. The behaviour is > > reliable and consistent. > [...] > > OK, that's more or less consistent with what I saw. > > > > > b) Setting up a print queue: > > > > lpadmin -p testq -v file:/dev/null -E -m drv:///sample.drv/generic.ppd > > > > 'lp -d <file>' consistently fails to have cupsd closing the listening > > sockets. > > That's what I am currently reporting as bug, yes. We can agree on that. > [...] > > c) Using lpadmin or lpq after doing b) sees the scheduler never becoming > > inactive. The commands in c) above return the system to the state in > > a). > > > > My view is that the failure of cupsd to process a printing job and act > > on IdleExitTimeout is the important aspect. I have no explanation for > > cupsd not exiting but would be interested in whether the behaviour is > > widespread. > > > > Yves-Alexis Perez (cc'ed) has an interest in socket activation working. I > > wonder whether he observes the behaviour described in b) when printing? > > Yves-Alexis? > > Fine, I am looking forward to reading additional information from > people more knowledgeable than me! People's experiences will determine decisions. Did using socket activation on stretch ever work for you when printing? Cheers, Brian.
