sysrc -- a sysctl(8)-like utility for managing /etc/rc.conf et. al.

Devin Teske dteske at vicor.com
Mon Oct 11 05:57:43 UTC 2010


On Oct 10, 2010, at 5:15 PM, Garrett Cooper wrote:

> On Sun, Oct 10, 2010 at 3:49 PM, Devin Teske <dteske at vicor.com> wrote:
> 
>> Hmmm, sysctl(9) is lock-free, which might imply that both sysctl(8) and
>> sysctl(3) are also lock-free, and proposed sysrc(8) is lock-free, so might
>> that imply that the atomicity tests would fare the same for all of the
>> above?
> 
> .../sys/kern/kern_sysctl.c says otherwise (look for the comment above
> the sysctllock declaration). The locking is just hidden from the
> developer/end-user.
> 
>> Here's what I'm thinking we should do to solve this...
>> Since the atomicity of the write operation is anything-but singular
>> (meaning, it takes incrementally larger blocks of time to write larger
>> amounts of data, increasing the risk-curve for failure to occur by two
>> operations coinciding at the same time -- I'm truly sorry, my wife has me
>> helping her with her business statistics II course, forgive me, I'll
>> clarify).
> 
> ...
> 
> I think I said it before, but yes.. I completely agree with the
> atomicity approach. I prefer `mktemp /tmp/XXXXXX' because it would do
> nothing more than potentially clutter up /tmp if the operation fails
> for whatever reason (instead of /etc), and it's less of a security
> concern. I suppose that's less of a problem though, because if someone
> has the ability to write to /etc, then all bets are off, but the
> clutter part is a bit annoying..

I checked out mktemp(1)... just what the doctor ordered for preventing race-conditions. And it's in the base FreeBSD distribution even back as far as FreeBSD-4.11 (likely much further; but that's what I checked).



> ...
> 
> I would just hold to this statement in /etc/defaults/rc.conf:
> 
> # All arguments must be in double or single quotes.
> 
> and also state:
> 
> "this tool functions based on the idea that the rc.conf files are
> simply written, and can be evaluated as standalone configuration data.
> Anything that doesn't conform to these requirements isn't guaranteed
> to work with the tool in all cases"

Simpler is indeed better ^_^


> 
> Thanks!
> -Garrett
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"

--
Cheers,
Devin Teske

-> CONTACT INFORMATION <-
Business Solutions Consultant II
FIS - fisglobal.com
510-735-5650 Mobile
510-621-2038 Office
510-621-2020 Office Fax
909-477-4578 Home/Fax
devin.teske at fisglobal.com

-> LEGAL DISCLAIMER <-
This message  contains confidential  and proprietary  information
of the sender,  and is intended only for the person(s) to whom it
is addressed. Any use, distribution, copying or disclosure by any
other person  is strictly prohibited.  If you have  received this
message in error,  please notify  the e-mail sender  immediately,
and delete the original message without making a copy.

-> FUN STUFF <-
-----BEGIN GEEK CODE BLOCK-----
Version 3.1
GAT/CS d(+) s: a- C++(++++) UB++++$ P++(++++) L++(++++) !E--- W++ N? o? K- w O
M+ V- PS+ PE Y+ PGP- t(+) 5? X+(++) R>++ tv(+) b+(++) DI+(++) D(+) G+>++ e>+ h
r>++ y+ 
------END GEEK CODE BLOCK------
http://www.geekcode.com/

-> END TRANSMISSION <-



More information about the freebsd-hackers mailing list