Q about conf'd system's self-checking output

[C Gray]

So I have the .conf[ig] files (e.g., /usr/local/etc/security/pwquality.conf) set so that 
my mail-less FreeBSD system will allow root to send my mail-gateway Macmini 
with reports.

I had and fixed these warnings so the detailed reports are already very useful (for 
system operations' debugging) and will be even more so (for security) over time:

	Warning: Variable $daily_status_security_chksetuid_enable is deprecated, 
		use $security_status_chksetuid_enable instead.
	Warning: Variable $daily_status_security_neggrpperm_enable is deprecated, 
		use $security_status_neggrpperm_enable instead.
	Warning: Variable $daily_status_security_chkmounts_enable is deprecated, 
		use $security_status_chkmounts_enable instead.

My  changes w/r/t my soundbar issue seem to have partially self-resolved (maybe 
because a connection re-seated itself better) itself due to self-diagnoses a, upgrades, 
or rediscovery attempts therewith... a welcome surprise but one I wish I better 
understood and quasi-controlled.

Here's "lanserve1 daily security run output" from 3:14am:
--------------
Checking login.conf permissions:

lanserve1 kernel log messages:
+Calibrating TSC clock ... TSC clock: 2500051110 Hz
+LAPIC: ipi_wait() us multiplier 60 (r 4100692 tsc 2500051110)
+Timecounter "TSC-low" frequency 1250025555 Hz quality 1000
+usbus0: random: harvesting attach, 8 bytes (4 bits) from uhci0
+12Mbps Full Speed USB v1.0
+acpi0: wakeup code va 0xfffffe008b02c000 pa 0x99000
+atkbd: the current kbd controller command byte 0045
+ugen4.1: <Intel EHCI root HUB> at usbus4
+uhub0: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus3
+uhub1: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus1
+uhub2: <Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1> on usbus4
+ugen2.1: <Intel UHCI root HUB> at usbus2
+ugen0.1: <Intel UHCI root HUB> at usbus0
+uhub4: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus0
+uhub3: <Intel UHCI root HUB, class 9/0, rev 1.00/1.00, addr 1> on usbus2
+uhub0: 2 ports with 2 removable, self powered
+random: harvesting attach, 8 bytes (4 bits) from uhub0
+uhub3: 2 ports with 2 removable, self powered
+random: harvesting attach, 8 bytes (4 bits) from uhub3
+uhub2: 8 ports with 8 removable, self powered
+random: harvesting attach, 8 bytes (4 bits) from uhub2
+ugen4.2: <Microchip Tech USB2744> at usbus4
+uhub5 on uhub2
+uhub5: <Microchip Tech USB2744, class 9/0, rev 2.10/2.86, addr 2> on usbus4
+uhub5: MTT enabled
+uhub5: 4 ports with 4 removable, self powered
+ugen4.3: <Dell Dell AC511 USB SoundBar> at usbus4
+ugen4.4: <vendor 0x04b4 product 0x6560> at usbus4
+uhub6 on uhub2
+uhub6: <vendor 0x04b4 product 0x6560, class 9/0, rev 2.00/90.15, addr 4> on usbus4
+uhub6: 2 ports with 2 removable, self powered
+random: harvesting attach, 8 bytes (4 bits) from uhub6
+Trying to mount root from zfs:tank1/ROOT/12.0-CURRENT-up-20180124_175726 []...
+ugen1.2: <Dell Dell USB Keyboard> at usbus1
+ukbd0 on uhub1
+ukbd0: <EP1 Interrupt> on usbus1
+kbd2 at ukbd0
+kbd2: ukbd0, generic (0), config:0x0, flags:0x3d0000
+random: harvesting attach, 8 bytes (4 bits) from ukbd0
+ums0 on uhub3
+uaudio0 on uhub5
+uaudio0: <Dell Dell AC511 USB SoundBar, class 0/0, rev 1.10/1.10, addr 3> on usbus4
+uaudio0: Play: 48000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
+uaudio0: Play: 44100 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
+uaudio0: Record: 48000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
+uaudio0: Record: 44100 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
+uaudio0: No MIDI sequencer.
+pcm0: <USB audio> on uaudio0
+pcm0: Mixer "vol" -> "none": child=0x00000010
+pcm0: Mixer "pcm": parent="vol"
+pcm0: Mixer "line":
+random: harvesting attach, 8 bytes (4 bits) from pcm0
+uaudio0: HID volume keys found.
+random: harvesting attach, 8 bytes (4 bits) from uaudio0
+ugen4.2: <Microchip Tech USB2744> at usbus4 (disconnected)
+uhub5: at uhub2, port 6, addr 2 (disconnected)
+ugen4.3: <Dell Dell AC511 USB SoundBar> at usbus4 (disconnected)
+uaudio0: at uhub5, port 3, addr 3 (disconnected)
+pcm0: detached
+uaudio0: detached
+uhub5: detached
--------------
Here's the stdout which the process(es) sent to my screen early this morning 
appending directly just after my root csh-login-prompt. I imagine that the 
stderr and stdout are synchronized time-wise in the above rendition, however, 
I have included the screen output [again] in case it may offer a clue or two....

> 	[root at lanserve1] ~# ugen4.2: <Microchip Tech USB274> at usbus4 (disconnected)
> 	uhub5: at uhub2, port 6, addr 2 (disconnected)
> 	ugen4.3: <Dell AC511 USB Soundbar> at usbus4 (disconnected)
> 	uaudio0: at uhub5, port 3, addr 3 (disconnected)
> 	pcm0: detached
> 	uaudio0: detached
> 	uhub5: detached
> 	ugen4.2: <Microchip Tech USB2744> at usbus4
> 	uhub5 on uhub2
> 	uhub5: <Microchip Tech USB2744, class 9/0, rev 2.10/2.86, addr 2> on usbus4
> 	uhub5: MTT enabled
> 	uhub5: 4 ports with 4 removable, self powered
> 	random: harvesting attach, 8 bytes (4 bits) from uhub5
> 	ugen4.3: <Dell Dell AC511 USB Soundbar> at usbus4
> 	uaudio0 on uhub5
> 	uaudio0: <Dell Dell AC511 USB Soundbar, class 0/0, rev 1.10/1.10, addr 3> on usbus4
> 	uaudio0: Play: 48000Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
> 	uaudio0: Play: 44100Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
> 	uaudio0: Record: 48000Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
> 	uaudio0: Record: 44100Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
> 	uaudio0: No MIDI sequencer. 
> 	pcm0: <USB audio> on uaudio0
> 	pcm0: Mixer "vol" -> "none": child=0x00000010
> 	pcm0: Mixer "pcm": parent="vol"
> 	pcm0: Mixer "line":
> 	random: harvesting attach, 8 bytes (4 bits) from pcm0
> 	uaudio0: HID volume keys found.
> 	random: harvesting attach, 8 bytes (4 bits) from uaudio0

What I am interested in:
	(1) what actual call launched at 3-ish am?
	(2) what and where were conditionals met-or-not-met which 'decided' to vector off to
		(a) attempt to resolve?
		(b) attempt to discover new devices?
		(c) attempt to resolve newly-discovered device-configuration issues?
		(d) attempt to resolve previously-discovered but unresolved device-configuration issues?

I'm also getting an old issue again when I tried to vi/vim (view works) on /usr/local/etc/security/pwquality.conf:
	Shared object "libSM.so.6" not found, required by "vim".

After my base install and attempts to 'make' ports, I ran into a missing link from /usr/local/lib/ to /lib/
Now I have this 'base'-ic issue. 
I've found that certain base-ic install tools have dependencies  which when take ]n care of also have missing dependencies.
Is there a tool that will walk through all executables to list all runtime issues at once rather than over a piecemeal call-and-see scenario?
Whene I run whereis, locate, which, and find nothing, I'm stumped as to how I am supposed to fix the problem I expected to be configured at install time.
That I may have to start the install all over is a problem as well because re-doing every .conf file setenv, alias, and such -- or backing that all up -- is near monumental, so if there is a logical tree-top walkthrough of logs, in the topmost sequence, so that a fix trickles down and fixes sub-issues, then I can learn quite a bit just fixing the system rather than hoping it doesn't just reproduce itself. Make sense. So, a guide to system->module->function calls may be useful if anyone can recommend an approach.1

My stdout listed above suggests questions based only on my asynchronous observations at this point, and I need to better understand the calls that generate the basic setup taking place w/r/t terms, phrases, and processes like:

	"harvesting attach"?
	"detached"?
	the boot-time and login-time setting of buffer sizes and locations?
	the boot-time and login-time mounting of and/or linking to devices or volumes?
	if certain things are set at boot time, login time, or at the time of need by a port or base module?

Is there a 'most pertinent' section (in your manuals' travels you'd recommend?
Have you seen that one graphical depiction (as is often well done when describing the disk-track-sector relationship) which "hit the mark" for you w/r/t any of my questions? I will read all suggestions and appreciate you taking the time, making the effort.
I apologize for this flurry, and I will definitely share back whatever I can when an "aha!" opportunity arises. 
Thanks.

best wishes,
chris
 <frankfenderbender at council124.org>
'smart' devices are con[niving]s and 'dumb' users are man-made