Bug 253429

Summary:	Failed invocation of /usr/sbin/service when going multi-user
Product:	Base System	Reporter:	Stefan Eßer <se>
Component:	conf	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed Overcome By Events
Severity:	Affects Some People
Priority:	---
Version:	CURRENT
Hardware:	Any
OS:	Any

Description Stefan Eßer freebsd_committer

2021-02-11 09:27:46 UTC

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).

Comment 1 Andriy Gapon freebsd_committer

2021-02-11 10:59:52 UTC

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.

Comment 2 Stefan Eßer freebsd_committer

2021-02-15 10:14:28 UTC

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).