Hi Sebastian, On 11/15/17 12:22 PM, Sebastian Benoit wrote: > Harald Dunkel(harald.dun...@aixigo.de) on 2017.11.14 07:48:01 +0100: >> >> Do you think the request to distinguish between the "usual" command >> line flags and the information whether a service should be started >> at boot time is unreasonable? > > Thats only one solution to your problem, but not the only one. > > Possible solutions that change the way rc.conf variables work are difficult, > and i dont see why they are needed. >
They are needed to keep the command line flags separate from the information whether a service should be run at all. Some tools like openvpn and dnsmasq support a pretty complex set of command line flags. If you disable such a service for the next reboot, then all these flags are lost. > Going to a rc.conf.local format where you have > > daemon=YES|NO > daemon_flags=-foo > > does not help you much. Then the next problem becomes how you switch from NO > to YES. > You could use "rcctl enable", as documented. My suggestion was to change the rc script internals, keeping rcctl as it is. Did you notice that rcctl(8) seems to imply that the flags can be set inde- pendently from enable/disable? Sample session: bash-4.4# rcctl get apmd flags -C bash-4.4# rcctl disable apmd bash-4.4# rcctl enable apmd bash-4.4# rcctl get apmd flags bash-4.4# Sorry to say, but this is not as documented. To me the lost command line flags look like an unwanted side effect, i.e. a bug. > So here is one way to store your flags and switch your configs > automatically, with no changes to how rc.d works: > > * run ifstated (or something else) to monitor your state > * use a script thats run on promotion/demotion of a machine, that script runs > rcctl(8) as > needed > * on state change, have ifstated (or something else) run the script > > Now you have the flags of your programms in the arguments > of "rcctl set <service> flags ...", all in one file that you can keep in > sync over multiple machines. > You mean I should write a wrapper for each service and put all knowledge about the command line arguments into this script? Actually I thought thats what rcctl is good for. Please check https://www.openbsd.org/faq/faq10.html. It says "Do not alter rc.conf(8) directly. Instead, use the rcctl(8) utility to maintain the /etc/rc.conf.local file. This makes future upgrades easier -- all the changes are in the one file that isn't touched during upgrade." Your suggestion is to put the command line flags somewhere else. Wouldn't you agree that this is a conflict? Not to mention that according to the quote rcctl has been provided as a command line interface to the rc internals, which means changes to the internals *are* possible. Regards Harri
