Re: Cron running at 99% CPU for seemingly no reason
Hi,
it crashed again.
Here is the dmesg, this time the kernel had debugging symbols enabled.
[...]
ic0 at ichiic0
spdmem0 at iic0 addr 0x50: 2GB DDR3 SDRAM PC3-12800 SO-DIMM
isa0 at pcib0
isadma0 at isa0
vga0 at isa0 port 0x3b0/48 iomem 0xa/131072
wsdisplay at vga0 not configured
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
wbsio0 at isa0 port 0x2e/2: NCT5104D rev 0x53
wbsio0 port 0xa10/2 not configured
vmm0 at mainbus0: VMX/EPT
run0 at uhub0 port 4 configuration 1 interface 0 "Ralink 802.11 n WLAN" rev 2.0
0/1.01 addr 2
run0: MAC/BBP RT5592 (rev 0x0222), RF RT5592 (MIMO 2T2R), address d8:61:62:37:5
6:c8
uhub2 at uhub1 port 1 configuration 1 interface 0 "Intel Rate Matching Hub" rev
2.00/0.04 addr 2
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (7ec83d15890e2a71.a) swap on sd0b dump on sd0b
inteldrm0: 1024x768, 32bpp
wsdisplay0 at inteldrm0 mux 1
wsdisplay0: screen 0-5 added (std, vt100 emulation)
kernel: protection fault trap, code=0
Stopped at icmp_mtudisc_timeout+0x77 [/usr/src/sys/netinet/ip_icmp.c:1072]
: movq0(%rax),%rcx
ddb{0}> ddb{0}>
ddb{0}> bt
icmp_mtudisc_timeout(fd807a4e0620,0) at icmp_mtudisc_timeout+0x77 [/usr/src
/sys/netinet/ip_icmp.c:1072]
rt_timer_timer(82324248) at rt_timer_timer+0x1cc [/usr/src/sys/net/rout
e.c:1551]
softclock_thread(8000f260) at softclock_thread+0x13b [/usr/src/sys/kern
/kern_timeout.c:681]
end trace frame: 0x0, count: -3
ddb{0}> call db_show_rtentry(fd807a4e0620, 0, 0)
Symbol not found
I'd love to know whats going wrong here.
Best regards,
Stephan
Re: Cron running at 99% CPU for seemingly no reason
>From l...@md5collisions.eu Thu May 26 19:51:47 2022
Date: Thu, 26 May 2022 19:51:47 +0200
From: Stephan Mending
To: misc@openbsd.org
Subject: Re: Cron running at 99% CPU for seemingly no reason
Message-ID:
Mail-Followup-To: Stephan Mending , misc@openbsd.org
References:
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To:
X-Operating-System: not-disclosed
Status: RO
Content-Length: 10166
Lines: 244
On Sun, May 15, 2022 at 12:25:24PM +0200, Claudio Jeker wrote:
> On Sun, May 15, 2022 at 12:06:33PM +0200, Stephan Mending wrote:
> > Hi *,
> > I've got a system running -current that keeps crashing on me every couple
> > of days.
> > Output of ddb:
> >
> > Connected to /dev/cuaU0 (speed 115200)
> >
> > ddb{0}> show panic
> > the kernel did not panic
> > ddb{0}> show uvm
> > Current UVM status:
> > pagesize=4096 (0x1000), pagemask=0xfff, pageshift=12
> > 482451 VM pages: 43158 active, 132795 inactive, 35 wired, 192336 free
> > (24054 z
> > ero)
> > min 10% (25) anon, 10% (25) vnode, 5% (12) vtext
> > freemin=16081, free-target=21441, inactive-target=0, wired-max=160817
> > faults=2487210, traps=2404140, intrs=211883, ctxswitch=1960560 fpuswitch=0
> > softint=3499069, syscalls=2015497, kmapent=9
> > fault counts:
> > noram=0, noanon=0, noamap=0, pgwait=0, pgrele=0
> > ok relocks(total)=192470(193514), anget(retries)=603205(0),
> > amapcopy=177151
> >
> > neighbor anon/obj pg=82033/639788, gets(lock/unlock)=415897/193548
> > cases: anon=570367, anoncow=32838, obj=347149, prcopy=67670,
> > przero=1469152
> >
> > daemon and swap counts:
> > woke=0, revs=0, scans=0, obscans=0, anscans=0
> > busy=0, freed=0, reactivate=0, deactivate=0
> > pageouts=0, pending=0, nswget=0
> > nswapdev=1
> > swpages=526020, swpginuse=0, swpgonly=0 paging=0
> > kernel pointers:
> > objs(kern)=0x8238a038
> > ddb{0}> show trace
> > No such command
> > ddb{0}> trace
> > icmp_mtudisc_timeout(fd807a50b070,0) at icmp_mtudisc_timeout+0x77
> > rt_timer_timer(8235d668) at rt_timer_timer+0x1cc
> > softclock_thread(8000f260) at softclock_thread+0x13b
> > end trace frame: 0x0, count: -3
> > ddb{0}>
> >
>
> This looks like some bad memory access. This is a fault and not really a
> panic this is why 'show panic' returns 'the kernel did not panic'.
>
> The crash in icmp_mtudisc_timeout() points to some error in the rttimer
> code refactor I made. Please try a newer snapshot and include the dmesg.
>
> If it happens again a call to db_show_rtentry in ddb may help better
> understand what is going on:
>
> call db_show_rtentry(fd807a50b070, 0, 0)
> Where the first argument is derived from the first argument of
> icmp_mtudisc_timeout from the trace.
>
> --
> :wq Claudio
@Claudio
The error seems to persist as attached occurred a couple of days back. (This
time I've got the full dmesg for you)
I tried your "call db_show_rtentry<...>". That somehow returned an error.
Just reporting right here. I'll try and run a kernel with symbols and wait for
the next crash.
'Til then.
Best regards,
Stephan
dmesg:
OpenBSD 7.1-current (GENERIC.MP) #525: Sat May 14 23:04:32 MDT 2022
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 2046992384 (1952MB)
avail mem = 1967644672 (1876MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 2.8 @ 0x7bef9000 (81 entries)
bios0: vendor American Megatrends Inc. version "5.011" date 10/10/2016
bios0: INTEL Corporation CRESCENTBAY
acpi0 at bios0: ACPI 5.0
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT UEFI SSDT ASF! SSDT SSDT
acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) RP0
1(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(S4) RP05(S4) P
XSX(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Pentium(R) 3558U @ 1.70GHz, 1696.36 MHz, 06-45-01
cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,C
FLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,V
MX,EST,TM2,SSSE3,SDBG,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,DEADLINE,X
SAVE,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,PERF,ITSC,FSGSBASE,TSC_ADJUST,ERMS
,INVPCID,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,MEL
TDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
Cron running at 99% CPU for seemingly no reason
Hi *,
I've got a system running -current that keeps crashing on me every couple of
days.
Output of ddb:
Connected to /dev/cuaU0 (speed 115200)
ddb{0}> show panic
the kernel did not panic
ddb{0}> show uvm
Current UVM status:
pagesize=4096 (0x1000), pagemask=0xfff, pageshift=12
482451 VM pages: 43158 active, 132795 inactive, 35 wired, 192336 free (24054 z
ero)
min 10% (25) anon, 10% (25) vnode, 5% (12) vtext
freemin=16081, free-target=21441, inactive-target=0, wired-max=160817
faults=2487210, traps=2404140, intrs=211883, ctxswitch=1960560 fpuswitch=0
softint=3499069, syscalls=2015497, kmapent=9
fault counts:
noram=0, noanon=0, noamap=0, pgwait=0, pgrele=0
ok relocks(total)=192470(193514), anget(retries)=603205(0), amapcopy=177151
neighbor anon/obj pg=82033/639788, gets(lock/unlock)=415897/193548
cases: anon=570367, anoncow=32838, obj=347149, prcopy=67670, przero=1469152
daemon and swap counts:
woke=0, revs=0, scans=0, obscans=0, anscans=0
busy=0, freed=0, reactivate=0, deactivate=0
pageouts=0, pending=0, nswget=0
nswapdev=1
swpages=526020, swpginuse=0, swpgonly=0 paging=0
kernel pointers:
objs(kern)=0x8238a038
ddb{0}> show trace
No such command
ddb{0}> trace
icmp_mtudisc_timeout(fd807a50b070,0) at icmp_mtudisc_timeout+0x77
rt_timer_timer(8235d668) at rt_timer_timer+0x1cc
softclock_thread(8000f260) at softclock_thread+0x13b
end trace frame: 0x0, count: -3
ddb{0}>
Output of a second crash:
ddb{0}> show panic
the kernel did not panic
ddb{0}> trace
icmp_mtudisc_timeout(fd8069f9f700,0) at icmp_mtudisc_timeout+0x77
rt_timer_timer(8231bfc8) at rt_timer_timer+0x1cc
softclock_thread(8000f500) at softclock_thread+0x13b
end trace frame: 0x0, count: -3
ddb{0}> show uvm
Current UVM status:
pagesize=4096 (0x1000), pagemask=0xfff, pageshift=12
482457 VM pages: 29240 active, 133535 inactive, 35 wired, 205028 free (25630 z
ero)
min 10% (25) anon, 10% (25) vnode, 5% (12) vtext
freemin=16081, free-target=21441, inactive-target=0, wired-max=160819
faults=687274, traps=693441, intrs=75204, ctxswitch=381252 fpuswitch=0
softint=615411, syscalls=607703, kmapent=9
fault counts:
noram=0, noanon=0, noamap=0, pgwait=0, pgrele=0
ok relocks(total)=185433(186477), anget(retries)=141598(0), amapcopy=75047
neighbor anon/obj pg=69895/201703, gets(lock/unlock)=256502/186509
cases: anon=114948, anoncow=26650, obj=237702, prcopy=17724, przero=290216
daemon and swap counts:
woke=0, revs=0, scans=0, obscans=0, anscans=0
busy=0, freed=0, reactivate=0, deactivate=0
pageouts=0, pending=0, nswget=0
nswapdev=1
swpages=526020, swpginuse=0, swpgonly=0 paging=0
kernel pointers:
objs(kern)=0x82317458
ddb{0}> show bcstats
Current Buffer Cache status:
numbufs 24114 busymapped 0, delwri 5
kvaslots 6030 avail kva slots 6030
bufpages 96426, dmapages 96426, dirtypages 20
pendingreads 0, pendingwrites 0
highflips 0, highflops 0, dmaflips 0
ddb{0}> mount
No such command
ddb{0}> trace
icmp_mtudisc_timeout(fd8069f9f700,0) at icmp_mtudisc_timeout+0x77
rt_timer_timer(8231bfc8) at rt_timer_timer+0x1cc
softclock_thread(8000f500) at softclock_thread+0x13b
end trace frame: 0x0, count: -3
Especially the line stating "the kernel did not panic" surprises me, as I am
greeted by the kernel debugger. Not sure how to interpret that.
While looking for the reason behind these "crashes", I noticed that cron is
constantly running at 99% cpu.
As a first measure I commented out all cronjobs in place (except for daily
weekly monthly as I figured these shouldnt
pose a problem). But that did not remedy the problem. Right after startup cron
starts eating away at the cpu. Does
anybody have an idea how to further analyze the issue (apart from giving it a
go by recompiling cron and using gdb) ?
Best regards,
Stephan
Re: TLS library problme: tlsv1 alert protocol
Hi Tom, Hm.. I am on the receiving end of this TLS Handshake. I am running -release on one and -current on another. Problem and error messages are the same. Excerpt of the running postfix main.cf: smtpd_tls_mandatory_ciphers = high smtpd_tls_ciphers = high smtp_tls_mandatory_ciphers = high smtp_tls_ciphers = high tls_ssl_options = NO_COMPRESSION, NO_RENEGOTIATION, PRIORITIZE_CHACHA tls_high_cipherlist = HIGH:+aRSA:+SHA384:+SHA256:+DH:+SHA:+kRSA:!eNULL:!aNULL:!PSK:!SRP:!AESCCM:!DSS:!ARIA smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3 smtpd_tls_protocols = !SSLv2, !SSLv3 smtp_tls_mandatory_protocols = !SSLv2, !SSLv3 smtp_tls_protocols = !SSLv2, !SSLv3 smtpd_tls_security_level = maytfix/smtpd[97536]: mout.web.de[212.227.17.12]:52515: TLS cipher list "HIGH:+aRSA:+SHA384:+SHA256:+DH:+SHA:+kRSA:!eNULL:!aNULL:!PSK:!SRP:!AESCCM:!DSS:!ARIA:!aNULL" Set the tls debug level to 2. The output: postfix/smtpd[97536]: SSL_accept error from mout.web.de[212.227.17.12]:52515: -1 postfix/smtpd[97536]: warning: TLS library problem: error:1404A42E:SSL routines:ST_ACCEPT:tlsv1 alert protocol version:/usr/src/lib/libssl/tls13_lib.c:150: postfix/smtpd[97536]: lost connection after STARTTLS from mout.web.de[212.227.17.12]:52515 postfix/smtpd[97536]: disconnect from mout.web.de[212.227.17.12]:52515 ehlo=1 starttls=0/1 commands=1/2 Best regards, Stephan On Wed, Apr 06, 2022 at 11:41:41PM +0100, Tom Smyth wrote: > Hi Stephan, > at a guess I would say that there is no overlap between supported TLS > protool versions and ciphers > available on the client vs the server. > if your system is using a recent version of an Os and you are trying > to relay to an older legacy system, > ideally ask the older system to uprade / enable higher ciphers > or you can be more permissive on your tls configuration... > I hope this is helpful > > On Wed, 6 Apr 2022 at 23:32, Stephan Mending wrote: > > > > Hi *, > > I've noticed on my mail relays, that tls handshake with one certain email > > relay keep failing. I was wondering what the > > reason for that may be. > > > > Following error from postfix: > > > > connect from mout.web.de[ IP ]:44003 > > SSL_accept error from mout.web.de[ IP ]:44003: -1 > > warning: TLS library problem: error:1404A42E:SSL > > routines:ST_ACCEPT:tlsv1 alert protocol > > version:/usr/src/lib/libssl/tls13_lib.c:150: > > lost connection after STARTTLS from mout.web.de > > > > Can anybody with more knowledge of libressl and it's error messages tell by > > this error what is wrong? > > > > Best regards, > > Stephan > > > > > -- > Kindest regards, u Tom Smyth.
TLS library problme: tlsv1 alert protocol
Hi *, I've noticed on my mail relays, that tls handshake with one certain email relay keep failing. I was wondering what the reason for that may be. Following error from postfix: connect from mout.web.de[ IP ]:44003 SSL_accept error from mout.web.de[ IP ]:44003: -1 warning: TLS library problem: error:1404A42E:SSL routines:ST_ACCEPT:tlsv1 alert protocol version:/usr/src/lib/libssl/tls13_lib.c:150: lost connection after STARTTLS from mout.web.de Can anybody with more knowledge of libressl and it's error messages tell by this error what is wrong? Best regards, Stephan
Re: pkg_add and an authenticating proxy
I'm a dork. I actually tried that but forgot to set "keepenv" in doas.conf. :| Thank you anyway for pointing me at it ! Best regards ! On Thu, Feb 11, 2021 at 05:03:59PM -0300, Fabio Martins wrote: > > Works here for me: > > export http_proxy="http://user:password@127.0.0.1:/; && pkg_add -nu > > > Hi, > > I was wondering if there was any way on how to allow pkg_add to use an > > authenticating http-proxy ? Unluckily I cannot > > find any documentation on the matter. > > > > Thanks alot so far. > > > > Best regards, > > Stephan > > > > > > > -- > Fabio Martins > PHOSPHORUS NETWORKS > https://phosphorusnetworks.com/ >
pkg_add and an authenticating proxy
Hi, I was wondering if there was any way on how to allow pkg_add to use an authenticating http-proxy ? Unluckily I cannot find any documentation on the matter. Thanks alot so far. Best regards, Stephan
Iked <-> Strongswan
Hi *, I've been trying to a longer time now to setup a connection between a strongswan server and an openbsd client. Which as turns out isn't as straightforward as I thought. Doesn't matter how I setup the strongswan config I'm running into the same problem. The connection is successfully established. When pinging the endpoint behinde the strongswan router I see icmp packets entering enc0. When listening for packets exiting the tunnel on the strongswan side it seems like there aren't any. And I don't see a trace of what could have happend to these packets. Neither in the firewall logs nor in the IPS logfiles. It's driving me nuts. I've put you in CC tobias@ because I know you're successfully running such a setup. My configs: $ cat /etc/iked.conf set fragmentation ikev2 'randomID' active esp \ from 0.0.0.0/0 to 10.0.3.100/32 \ local peer \ ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group curve25519 \ childsa enc aes-256-gcm prf hmac-sha2-512 group curve25519 \ srcid dstid \ ikelifetime 7200 lifetime 3600 $ cat ipsec.conf conn randomID left=%defaultroute leftsubnet=10.0.3.100/32 leftfirewall=yes lefthostaccess=yes right=185.165.169.190 leftcert=/var/storage/certs/hostcert.pem rightcert=/var/storage/certs/.pem leftid="" rightid=""" type=tunnel
sysupgrade is constantly failing
Hi *, I've been experiencing issues upgrading my -current machines to the next snapshots by upgrading via `sysupgrade -ns`. I receive the following output: Fetching from https://ftp.spline.de/pub/OpenBSD/snapshots/amd64/ SHA256.sig 100% |**| 2141 00:00 Signature Verified INSTALL.amd64 100% |*| 43512 00:00 base66.tgz 100% |**| 238 MB 01:07 bsd 100% |**| 18099 KB 00:05 bsd.mp 100% |**| 18184 KB 00:06 bsd.rd 100% |**| 10100 KB 00:04 comp66.tgz 100% |**| 74360 KB 00:21 game66.tgz 100% |**| 2745 KB 00:01 man66.tgz100% |**| 7453 KB 00:03 xbase66.tgz 100% |**| 22912 KB 00:07 xfont66.tgz 100% |**| 39342 KB 00:16 xserv66.tgz 100% |**| 16766 KB 00:07 xshare66.tgz 100% |**| 4499 KB 00:02 Verifying sets. (SHA256) man66.tgz: FAILED (SHA256) xbase66.tgz: FAILED (SHA256) xfont66.tgz: FAILED (SHA256) xserv66.tgz: FAILED (SHA256) xshare66.tgz: FAILED And that's not even an issue with the specific mirror. I've tried several. I'd appreciate your help ? Being unable to upgrade kind of sucks. Thanks for your time ! Best regards, Stephan signature.asc Description: PGP signature
