1) "runlevels" with arbitrary names. runlevel change would start and stop
right services.
With a couple of additions:
- it should be easy to see which services are on at a given runlevel.
already proposed in rc.conf
- it should be easy to see which runlevels a service is on at.
same.
service2_enable="NO"
service3_enable="foolevel maintenance"
service4_enable="YES -foolevel" (or ALL -funkyrunlevel)
Using two symbols to indicate negation - one to start, and then one on
each runlevel - is overkill. There's not a use case where you have a
better method already proposed by
jhellent...@dataix.net
But each line has become more complicated, going from a simple on/off
setting to a small language that can even have errors (like "foolevel
-barlevel"). This violates the second thing on your list of things we
see above.
The downside is that it adding a service now becomes harder - you have
to edit each runlevel script instead of just one.
i unable to understand this sentence. rc.d scripts would be exactly as
they currently are.
extra data in rc.conf would define "runlevels" at which they are active.
doing this as currently (_enable=YES) would mean every "runlevel".
my point is that if you put new startup system in place of old, nothing
will change with your existing rc.conf!
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
