Slackware 14.2 64-bit. Intel 2.70GHz 4-core i5-6400 CPU, 16 GB RAM. System drive is Western Digital WD2003FZEX 2TB SATA III spinner.

When performing a fresh boot, rc.cups takes about 5-6 seconds to start. Performing an rc.cups restart any time after booting is almost instantaneous.

Only rc.cups has this long start. Other services start immediately.

The haveged entropy daemon is launched long before rc.cups.

Looking for ideas to resolve.

Thanks.

haveged , is not oart of 14.2 , you are on current ? or added from SBo ?

Added from SBo.

Have you tried moving rc.cups in rc.S or whatever it is that starts stuff? Justy from grokking the scripts on my own problems, I'm aware that Pat was fond of

wait 5

instructions to allow for stopped platters on lousy disks to slowly speed up and be recognized & do whatever he was thinking of. You could put in rc.cups instead of one of them ;-).

I commented out the background tasks in rc.M. Searching for boot issue discussions I found this old thread for the idea. Now there is a momentary pause when rc.cups launches but not the longer delay as previous. My guess is the background tasks cause disk I/O tension with booting, at least with spinners. I notice the overall boot is faster without the background tasks. I'll try to find time to run some simple stopwatch tests with and without the background tasks.

Once upon a time I asked Pat to reconsider those delays. I also tried to introduce a different way in my proposed Slackware rc.d Script Update Project, of which I notified Pat by email.

Interesting results. There is an 8 to 10 second difference in the execution time of rc.M. I ran the test several times.

With the rc.M snippets that launch processes into the background commented out, executing rc.cups from within rc.M occurs in less than 1 second. Otherwise about 5 to 6 seconds.

With the background processes enabled, there is a delay with the login process. With the background processes commented out, login responds normally.

On my system running these rc.M processes in the background affects my office system.

The problem does not exist on my laptop, which uses an SSD rather than a spinner. At this time, replacing the spinners with SSDs is not doable.

The best solution for me is keeping the rc.M background processes commented out and running the tasks as a daily cron job.

I'll presume others using spinners are affected. Perhaps the discussion could shift to how best run these processes.

Perhaps these tasks could be moved to a new rc.d script. If users want to run the tasks at boot then chmod +x. Otherwise chmod -x and let users run the same script as a daily cron job.

Why not run a script on log in? That's simple, as bash runs scripts anyhow.

I don't understand your question.

It seems your background tasks are slowing your login. I just suggested calling them from ~/.bash_profile or similar, so they would be run after you've logged in. sorry for confusion.

The background tasks are system tasks run from rc.M, not user tasks. As already shared in a previous post. I already offloaded those system tasks to a daily cron job.