cron should reattempt loading crontabs of users that are not found

If a remote user (such as an LDAP user) has a crontab, it may not get loaded when the system is rebooted.

The cron log would say:

! crontab for <user> not loaded due to authentication error.

This is because at the time cron has started, the remote service may not be available yet, and cron is not able to resolve the username. In this situation, cron refuses to load the crontab, and will not run any cron jobs for this user.

Reordering inittab so that cron is started after secldapclntd (or other remote user service) may not help, since it may take time for the remote service to be up and running. Starting the remote service from inittab in 'wait' mode may not be useful either - for example, when the 'start-secldapclntd' script is done executing, there is no guarantee that secldapclntd is fully communicating with the LDAP server.

To work around this, once the user is able to be resolved - for example, secldapclntd is up and running and connected to the remote LDAP server - cron can be respawned, or the user's crontab can be modified with 'crontab -e' to get it to be loaded.

Another possible workaround is to create a script that runs at the end of inittab, which checks to see if remote users are resolvable, and if so, respawns cron.

This is all inconvenient, however. It would be better if cron could keep a list of crontabs that were not loaded at startup, and periodically re-check to see if the associated username is resolvable. If so, then it could load the crontab, write to the cron log saying the user's crontab is now active, and start running the user's jobs without any other intervention needed.