Thanks for the follow-up Jody. I guess I have no choice but to do so... Dave
On 2/24/17, Jody Bruchon <[email protected]> wrote: > On 2017-02-24 08:49, David Henderson wrote: >> Thanks for the tip Rob! So it looks like my only resolution to this >> problem is the dmesg silencing? The only issue I see with that is >> that perhaps something I need to see won't get shown. > Setting the level higher will restrict immediate console output to more > and more critical messages only; since I administer all of my machines > remotely, I tend to see zero console logging and find that the rare > instances I have console logging going on, the messages tend to mangle > program output or the command I'm typing when I least expect it. > Increasing the urgency threshold for console logging will allow truly > severe problems like a disk command failure to still be logged to the > console while preventing simple warnings from polluting the console. I > prefer to run dmesg manually to read these warnings. > > I look at it this way: if there's a problem then someone will go out of > the way to read the logs and see what warning messages are present, but > if there's not really a problem (as in this case) they'll never see the > messages because the operation succeeded. > > An example I run into a lot: if you mount a journaled HFS+ filesystem it > will force it to be read-only unless you pass '-o rw,force' and a kernel > warning will be logged saying so. I don't see that on my console, but > when I try to write to the filesystem I'll get an error and see the > warning message when I run dmesg. Then I know to umount, mount -o > rw,force, and resume working as usual. > _______________________________________________ > busybox mailing list > [email protected] > http://lists.busybox.net/mailman/listinfo/busybox > _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
