Date: Thu, 08 Jun 2006 16:51:30 -0700 From: Sean McNeil <sean@mcneil.com> To: current@freebsd.org Subject: bugus rc.conf.d locations recently committed to -STABLE? Message-ID: <1149810690.2642.11.camel@triton.mcneil.com>
next in thread | raw e-mail | index | archive | help
I am now having difficulty with bringup on my -STABLE system. I get what looks like bogus warnings: root: /etc/rc: WARNING: Warning: /etc/rc.conf.d/ntpdate is deprecated, please use /etc/rc/etc/rc.conf.d/ntpdate instead. and root: /etc/rc: WARNING: Warning: /etc/rc.conf.d/sendmail is deprecated, please use /etc/rc/etc/rc.conf.d/sendmail instead. but this doesn't make sense and is impossible as /etc/rc is a regular file, not a directory. There were warnings for /usr/local and /usr/X11R6 to go into /usr/local/etc/rc.conf.d and /usr/X11R6/etc/rc.conf.d. These make sense. They correspond to /etc/rc.d and /etc/rc.conf.d. Also, I have port cyrus-imapd-2.2.13_2 and it installs /usr/local/etc/rc.d/imap. This script has an internal name of "cyrus_imap", but instead of wanting /usr/local/etc/rc.conf.d/cyrus_imap as would be the completely logical place for it, I have to place it in /usr/local/cyrus/etc/rc.conf.d/cyrus_imapd. Seems like it bases the location upon where the binary is as opposed to where the rc script is. Same thing happens with slapd. I told it to put the rc script in /etc/rc.d/slapd when I configured the port. But it warns me that it wants the rc.conf.d in /usr/local/libexec/slapd/etc/rc.conf.d/slapd. This is very counter intuitive to me. What is the logic behind this and why was it MFCd in a non-working condition? Like I said, many of my daemons did not start even though I could start them by running the script by hand. So I'm guessing that maybe rcorder isn't working with this new configuration.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1149810690.2642.11.camel>