Although according to your boot chart, you're not starting xinetd either ;)
Starting CUPS on demand isn't quite ideal sadly, if the user is using
network printers, then CUPS needs to have already been running for about
30s before they try and print otherwise the network printer won't be shown.
Sadly we can't "start CUPS 30s before the user needs it" ;)
Though I entirely agree in principle that CUPS is not part of the critical
path of the boot sequence, if the system is idle at some point, it's worth
starting -- even if that means the disk isn't entirely inactive after boot.
The most ideal way to deal with these kinds of services is to start them
after boot, when the system is idle - with low CPU and I/O scheduler
priority so that user activity takes precedence - or activate them on
demand by xinetd or D-Bus when the user actually needs them.
That way, if the user clicks print and cups wasn't running yet, it gets
brought up -- or if the user leaves their PC alone for a bit, we start cups
for the next time they click print.
Of course, even better would be if we could do network printer discovery
via other means like Avahi -- but then Avahi falls into the exact same
"start on idle or first demand, whichever is sooner" category
Posted Oct 2, 2008 8:36 UTC (Thu) by renox (subscriber, #23785)
[Link]
Agreed, I understand the desire to do 'booting in 5s' without cheating, but CUPS is probably one exception here where cheating is okay:
1) it's unlikely to take much CPU or IO load (if it does then it's a bug) so starting it in the background won't be felt as a slowdown for the user.
2) users are unlikely to print just after starting the computer so launching the desktop before CUPS is okay.
3) the critical part for the user here is the 'time to print' if having to find a network printer really slow downs printing then it make sense to have CUPS running all the time, not on demand.