Bug 747759

Looks like crond is run with -n in Fedora 15 but not in 14.  I wonder if this is related?

What do you see in /var/log/cron when you reboot the computer?

Nothing, until the next cron job runs.

I cannot reproduce the problem on Fedora 16 beta. Are you sure that the @reboot job is correctly set in a crontab?

Can you attach the crontab you have the @reboot job in?

I cannot reproduce it on Fedora 15 either.

Here is the exact entry I am putting in my crontab:
@reboot /bin/touch /tmp/foo

So, it looks like it works fine for local users but fails for users with accounts served via NIS.

Could it be that crond is starting before NIS?  I'm not quite sure how to tell... I'm still getting used to systemd.

Yes, that's possible. Do you see any ORPHAN messages in /var/log/cron?

I do not see any ORPHAN messages.

I did, however, try creating a crontab in /var/spool/cron with a non-existant UID and GID and also don't see any ORPHAN messages during reboot, regardless of whether it is an @reboot or ordinary cron entry.

I do see ORPHAN messages when cron is manually restarted though.  Looks like ORPHAN messages are only generated when the crontab is manually reloaded, not at reboot?

More likely, crond is also starting before syslog.

I was able to generate a systemd dependency graph with

systemctl --order dot | dot -Tsvg > /tmp/systemd.svg

but it is too complex to really read.  I wonder if there is an easy way to just tell if one service starts before another... systemd is pretty cool but I kinda miss rc scripts right now.

Hmm that looks like the messages from startup of crond on reboot are lost or more probably redirected to /var/log/messages. Unfortunately this logging problem is caused by migration to systemd and I do not think the solution is in crond. Either the problem is in systemd itself or in the rsyslog.

Also to me it seems the crond service should be put at the latest end of the boot process but due to the parallel nature of the systemd boot it would be really hard to ensure that it is always started after the nis/ldap/ipa or whatever else network account service is started. The problem with orphaned regular jobs was solved by the orphan adoptions, but the @reboot jobs cannot be run this way because the orphans can be adopted in some cases very late when running eventual @reboot jobs would not be desirable.

The only solution I see for now is to document this problem at the same place the special @reboot keyword is documented.

It may be a good idea to document this problem in the man page but can't we also start crond later in the boot process?  That's why systemd has targets right?

Is there a systemd guru we can run this by?

After modifying the following in 

[Unit]
Description=Command Scheduler
After=syslog.target network.target

I now see the ORPHANED messages at reboot.  Not sure why this is, the After=syslog.target was already in there, so why do we need After=network.target to log messages?

This does not, however, fix my NIS problem.  Unfortunately ypbind is still started with SysV scripts so I'm not sure how to force crond to start after it.

And what happens if it takes a second for ypbind to start working?

Oh, the file I am playing with is /lib/systemd/system/crond.service which does belong to the cronie package.

It does belong to the cronie package. I see it in the spec file of the F15 package and I verified it on my F16 install.

I'd just say do not use @reboot for non-local users at least until someone comes up with some clever way how to distinguish orphans from not-yet-running network account services and orphans of other kind (network down on reboot because a laptop is started disconnected and then connected a hour or two later).

Of course we could say if orphan comes up less than ??? minutes after the startup then run @reboot jobs for him. But this seems to be too vague to me.

Thanks, I agree.

I might mention again, however, that it works fine for me in Fedora 14, even if there are no guarantees that network accounts will be available.  I'm pretty sure that the integration of systemd started the problems and that starting cron after NIS would fix the particular problem that I am seeing.

Is ypbind in systemd in Fedora 16 or is it still a legacy script?

It was migrated to a native systemd unit in F16.

We could probably add After=ypbind.service sssd.service to the crond unit file as a workaround. Does it help for you?

Yes, actually, that solves the problem for me.  Thanks!

In fact, just ypbind.service seems to be enough.  Since After=network.service solves the problem of not seeing the ORPHAN messages at reboot I would recommend

After=syslog.target network.service ypbind.service

Although I still don't get why syslog.target isn't enough.

cronie-1.4.8-4.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/FEDORA-2011-14523

cronie-1.4.8-9.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/cronie-1.4.8-9.fc16

Package cronie-1.4.8-9.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing cronie-1.4.8-9.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-14947
then log in and leave karma (feedback).

This solved the problem for us.  I'm not sure, however, that this will solve the issue for other nameservices, e.g. ldap.  Thanks!

cronie-1.4.8-4.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.