rmustacc: re: the heads-up ==> ship it.

I think I have a grip on what it will take to migrate SMF to sqlite3. I've started writing an IPD to discuss some of the options (not quite ready to circulate).

Early in boot, the repository database can ping-pong back and forth between /etc/svc/repository.db and /etc/svc/volatile/fast_repository.db to enable early manifest import and r/w smf db access before root is r/w. so we could potentially build a conversion tool run by svc.startd early in boot which creates a sqlite3 version in /etc/svc/volatile from the sqlite2 database in /etc/svc/repository.db before starting a sqlite3-only svc.configd.

danmcd: looks like I missed pgrep/pkill(1) when I added history sections to most of the other proc tool man pages in gist.github.com/alanc/9bb7337ee5e6a2aa641a6a0e5b0d8901 but looking in the old teamware gates, the first to have pgrep/pkill is on998-gate, aka S7

Wow... thank you for that. Given you pasted this here on IRC, I may share this link with others.

I've shared the link on twitter before, and possibly even here

Even better then (and sorry for missing those earlier ones).

It's certainly not secret - any user with the boot environments for the two SRU's could generate the diff - I just share those each quarter so people can more easily see the changes in the man pages they might not notice on their own

gist.github.com/alanc has a them for a bunch of prior quarterly feature releases too

I know it makes rich sad that I can't put them under any license other than "Feel free to read these" so you can't just apply the diffs

(Makes me sad too, FTR, but I understand.)

github.com/illumos/illumos-gate/blo…bdladm/common/libdlaggr.c#L539-L544 <-- I don't see any way this can be called without DLADM_OPT_ACTIVE set, so this seems superfluous

toasterson: also check MTU between connect server/client

igork: I managed to fix it. it was a missing ipfilter package in the zone. Dependency entries are missing, bug is opened for that

toasterson: yes, nfs service depend on ipfilter binaries and service

igork no, nfs/server does not depend on ipfilter (nor should it).

danmcd: unfortunately it has to otherwise it goes to maintenance with a svcprop command failing

milestone/network *does* apparently, and that blocks nfs/server.

danmcd: take a look nfs server service - /lib/svc/method/nfs-server

# Handling a corner case here. If we were in offline state due to an

# unsatisfied dependency, the ipf_method process wouldn't have generated

# the ipfilter configuration. When we transition to online because the

# dependency is satisfied, the start method will have to generate the

# ipfilter configuration. To avoid all possible deadlock scenarios,

# we restart ipfilter which will regenerate the ipfilter configuration

# for the entire system.

and also

. /lib/svc/share/ipf_include.sh

i'm not crazy :)

probably a little ? :)

there is also an svcprop call in there which looks for ipfilter service see #15560

tsoome: can you ping me when you need another pass through NFS?

sure

thanks

[illumos-gate] 15553 dlmgmtd asserts on processing NGZ persistent configuration file -- Andy Fiddaman <illumos⊙fn>

[illumos-gate] 14577 ESX offline disk resize prevents growing zpool -- Jason King <jason.brian.king⊙gc>