A few weeks ago I noticed that cron is no longer started on my system after a reboot. This is caused by /usr being on a separate ZFS file system that has not been mounted at the time when the rc script tries to start cron, despite it having a REQUIRE: FILESYSTEMS condition: # PROVIDE: cron # REQUIRE: LOGIN FILESYSTEMS # BEFORE: securelevel # KEYWORD: shutdown According to "service -e", cron is one of the last few services to be started: $ service -e /etc/rc.d/rctl /etc/rc.d/hostid /etc/rc.d/zpool /etc/rc.d/zvol /etc/rc.d/hostid_save /usr/local/etc/rc.d/microcode_update /etc/rc.d/zfsbe /etc/rc.d/zfs ... /etc/rc.d/cron /usr/local/etc/rc.d/sa-spamd /usr/local/etc/rc.d/dovecot /usr/local/etc/rc.d/postfix /etc/rc.d/bgfsck But in fact, starting cron is the first action when going multi-user and before local file systems (beyond / and /dev) have been mounted: ... ugen0.6: <Logitech USB Keyboard> at usbus0 ukbd0 on uhub3 ukbd0: <USB Keyboard> on usbus0 kbd2 at ukbd0 hidraw1 on uhub3 hidraw1: <USB Keyboard> on usbus0 /etc/rc.d/cron: service: not found /etc/rc: WARNING: run_rc_command: cannot run /usr/sbin/cron Setting hostuuid: 1e0028e0-008c-4300-13a1-f46d04d87842. Setting hostid: 0x3c3b54d6. Starting file system checks: Mounting local filesystems:. The log shows, that the /usr/sbin/service command is not available, yet. The same is of course true for /usr/sbin/cron. Before mounting the essential file systems, commands like service are not available and I understand that this is a contradiction to file systems being mounted when going multi-user as directed by the output of "service -e". I'm not aware on any local modifications of my start-up scripts, but I guess that having a separate /usr partition is not common, anymore. Moving the "service" command to /sbin might fix this issue (to be verified).
You can try to use rcorder /etc/rc.d/* /usr/local/etc/rc.d/* to investigate why your system tries to start cron so early. Here, it is started much later, after LOGIN.
In have found that the cause of the pre-mature attempt to start cron has been caused by a dependency loop detected by rcorder. After breaking the cycle, cron is now started at the correct point in the startup process. I have found that there are optional packages that cause such loops (dnscrypt-proxy2, for example - the maintainer has been notified).