ports/83135: sysutils/smartmontools -- Does not work with alternate config location

Jeremy Chadwick freebsd at jdc.parodius.com
Fri Jul 8 09:50:21 UTC 2005


>Number:         83135
>Category:       ports
>Synopsis:       sysutils/smartmontools -- Does not work with alternate config location
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-ports-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Fri Jul 08 09:50:19 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator:     Jeremy Chadwick
>Release:        FreeBSD 4.11-STABLE i386
>Organization:
Parodius Networking
>Environment:
System: FreeBSD pentarou.parodius.com 4.11-STABLE FreeBSD 4.11-STABLE #0: Thu May 12 04:37:52 PDT 2005 root at pentarou.parodius.com:/usr/obj/usr/src/sys/PENTAROU i386
>Description:
	PREFIX/etc/rc.d/smartd.sh allows for users to set 'smartd_flags'
	to whatever they want.  However, when using your own configuration
	file (instead of /usr/local/etc/smartd.conf), via

	smartd_flags="--configfile=/some/place/smartd.conf"

	...the following warning is output and smartd does not start:

	# /usr/local/etc/rc.d/smartd.sh start
	/usr/local/etc/rc.d/smartd.sh: WARNING: /usr/local/etc/smartd.conf is not readable.

	This is due to the required_files="/usr/local/etc/smartd.conf"
	line in smartd.sh.

>How-To-Repeat:
	Set smartd_flags="/some/other/smartd.conf" in rc.conf.
	Attempt to start smartd via smartd.sh start.
>Fix:
	I've two solutions for this (the latter being recommended);

	1.  Remove the 'required_files' directive from smartd.sh.
	My assumption is that if smartd can't find a config file,
	it'll abort.  This is an assumption on my part though.
	If this is the case, 'required_files' seems superfluous.

	2.  Add a 'smartd_config' variable to smartd.sh.  Set
	required_files to the value of that, which allows
	people to use their own configuration file via

	smartd_config="/some/place/smartd.conf"

	I think this would be a better solution in the long-run.

	If the port maintainer does not want/cannot do the work
	for this, I can submit a patch if asked.  I'm being
	lazy right now.  :-) Let me know.
>Release-Note:
>Audit-Trail:
>Unformatted:



More information about the freebsd-ports-bugs mailing list