On 01/31/2017 06:05 PM, L A Walsh wrote:
Hope you find it -- am sorta at the end of my ideas since I don't run wireless. Though, as for the 10+15 coincidence -- I've seen things like that turn out to be red-herrings about 35-40% of the time with the numbers just happened to be the same as ones used somewhere else. So I wouldn't be too overfocused on the source for those 2 numbers. It would be useful if you could trace what the chain of actions was from the time you plugged it in, through 'what' actions in udev, and if it is really calling out the dhcp the way we think it is--... If nothing else, would resort to inserting print's or adding something like:
[[ -n ${DEBUG:-} || -O /tmp/debug_local ]] && { echo "(${#BASH_LINENO[@]})entering $BASH_SOURCE..." >&2; [[ -O /tmp/debug_local ]] && source /tmp/debug_local ; }
to spots in the script(s) that drive things, That way you could toggle debugging by creating a tmp file that has to be owned by you... ;-)
Sprinkled statements like that throughout my login scripts to find where hang-ups/problems were.
If you can't see stderr, append it to a tmpfile (>>/tmp/log )...
Thanks, You have been wonderful with the links and possibilities. I just haven't had a spare hour to tear it apart and pick through the logs. That will take a couple of reboots, and at present: $ uptime 19:40pm up 5 days 7:39, 2 users, load average: 0.21, 0.16, 0.24 No time for that.... ** Moment of Silence Please ** We should also take a moment of silence for 'nemesis' my trusty old AMD Athlon TBird on a Abit KT7 board w/1G that began life with SuSE 7.0 (Air), which has served as my fax server (hylafax/Avantfax) since 10.0 days and currently sports a flashy install of 11.0. Linux-raid has been through 1/2 dozen disks over the decade and a half without a data hiccup. $ cat /proc/mdstat Personalities : [raid1] [raid0] [raid6] [raid5] [raid4] md2 : active raid1 sda7[0] sdb7[2] 221929772 blocks super 1.0 [2/2] [UU] bitmap: 0/424 pages [0KB], 256KB chunk md0 : active raid1 sda1[0] sdb1[2] 104376 blocks super 1.0 [2/2] [UU] bitmap: 0/7 pages [0KB], 8KB chunk md1 : active raid1 sda5[0] sdb5[2] 20972752 blocks super 1.0 [2/2] [UU] bitmap: 6/161 pages [24KB], 64KB chunk unused devices: <none> Though it had been bandaided with new openssl, and xz integration, bash, and other forward-ported updates, it has always kept ticking. It has experiences 2 dirty page kernel faults in the past 2 weeks indicating that a cap somewhere is beginning to fail. (I hope it is a cap on the old USR internal fax-modem and not the board itself -- which would explain the mgetty error on the first crash) They just don't make-em like they used to. Only 16 years out of service with that rig (original Antec case and power-supply as well). (proverbial handful of dirt along with a flower tossed on top of the case...) -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org