Liane Praza wrote: > I just did: > > # svccfg -s network/physical:default setenv DLPI_DEVONLY 1 > # svcadm refresh network/physical:default > # svcprop network/physical:default | grep DLPI_DEVONLY > start/environment astring DLPI_DEVONLY=1 > > # svccfg -s network/physical:default unsetenv DLPI_DEVONLY > # svcadm refresh network/physical:default > # svcprop network/physical:default | grep DLPI_DEVONLY > # > > So it seemed to work for me.
Ah, I was missing the refresh step. > The interesting difference is that yours > got set in method_context rather than in the start method. > > It seems from the documentation (no, I didn't write this feature) that > you must have gotten there using setenv with either the -i or -s > options. Thus, I'd expect that one of -i or -s will work with unsetenv. > I'm a bit shocked that it didn't. There were a bunch of strange and confusing missteps in play. I think I did use -i or -s to set the variable at one point in the past while playing around with svccfg, which is why I _thought_ that my setenv invocation without any options worked the way it did (this was compounded by the fact that I didn't use svcadm refresh). The key is that without doing svcadm refresh, I can't observe the results of the commands I type. > I vaguely remember discussion of this feature in a haze of sleepless > nights, but can't remember why we didn't just have unsetenv attempt to > be more helpful and remove the setting from method_context as well even > if no options were specified. > > An RFE might be in order. Maybe. I'm not sure that the semantics are clear. What happens when the variable is set in multiple property groups that might each be applicable if given different combinations of -i, -s, and neither? The behavior might be fine the way it is, and I was just thrown way off by the fact that without svcadm refresh, it didn't look like anything was being modified. Thanks! -Seb
