Re: mfs reported full, but empty
On Wed, 19 Aug 2020 23:47:57 +0200, Vincent wrote: > After several days, I have to reboot my machine because of mfs full. This is > not the first time. > I have few mfs on this machine, but I observe that this is always a full > filesystem on /tmp after +40 days of uptime. > But on other mfs, I have very low filesystem activity. It is possible for a process to have a file open that doesn't have a directory entry. This can happen when a process opens a file, unlinks it, and continues to write to it. You can use the fstat utility to see what processes have files open on a file system. E.g. $ fstat -f /tmp This won't tell you how big those unlinked files are, but it will give you a list of suspects. You can restart them and see which one releases the space. - todd
Re: mfs reported full, but empty
On 2020-08-19 17:47, Vincent wrote: > Hello, > > > After several days, I have to reboot my machine because of mfs full. This is > not the first time. > I have few mfs on this machine, but I observe that this is always a full > filesystem on /tmp after +40 days of uptime. > But on other mfs, I have very low filesystem activity. > > > Am I the only one having such problem ? yes. and no. :) Normal Unix Behavior, and nothing to do with MFS. (I think) (for the record, I use mfs extensively some systems I run that get a significant benefit from it, have done so for many many years. Only problem I've ever run into is being that MFS systems shine when for with lots of tiny files, it's the ONLY time I've ever run out of i-nodes before running out of disk space. Not really an MFS problem, of course.) ... > obsd-fw/tmp# du -h /tmp > 1.0K /tmp/.X11-unix > 1.0K /tmp/.ICE-unix > 1.0K /tmp/vi.recover > 11.0K /tmp > obsd-fw/tmp# df -h /tmp > Filesystem Size Used Avail Capacity Mounted on > mfs:71474 991M 991M -49.5M 105% /tmp > obsd-fw/tmp# uptime > 7:22PM up 57 days, 17:58, 1 user, load averages: 0.08, 0.16, 0.15 > obsd-fw/tmp# ps aux | grep mfs > root 71474 0.0 12.4 1049016 1016980 ?? S 22Jun20 1:25.23 > /sbin/mount_mfs -o rw -s 1024m swap /tmp see... "du" and "df" show two different things. "df" shows how much unallocated space you have. It's very accurate. You can create a file as big as "df" shows you have available. "du" shows how much space normal files have taken up. It's also very accurate. It will show you how much space will be freed up if you delete those files. However, you can have Unix do some seemingly strange stuff, at least strange for those of us who cut our teeth on single-user systems. Unix lets programs do funny stuff, like delete an open file. That removes the file handle (what "du" looks at), but does not release disk space (what df looks at) until ALL tasks that have it open, close it. (man 3 unlink In fact, I'm pretty sure one task can create a file, open it, unlink (rm -- but the name there is wonderfully descriptive -- remove a link (the directory entry) from a file) it, and then write and read temp data to that file...and one can continue to do that until the task exits...look ma, self-cleaning tmp files! I'm pretty sure something like that is happening with you. I was able to reproduce your "problem" easily. I have a little machine here that has a 100MB /tmp, I created a 70MB text file, and tried to edit it with vi. Well...vi quickly discovered it couldn't create its vi.recover file, /tmp showed 100% utilization, but "du" could not show me where the last ~27mb of disk space went. As soon as I exited vi, the space came back. One big clue: since you are hitting 105%, that means the offending process is running as root -- I could only take /tmp to 100% as a non-root user, but if invoked as root, 105% (as expected). So the first lesson is, whatever you are doing, 1G /tmp is not big enough. Probably more scary, though -- you have a root process spewing lots of data into /tmp. I don't normally see that...so I'm inclined to think you are running something incorrectly or "solved a problem" by running it as root. Might be totally legit and just needs more tmp space, but my very first thought is "YOU ARE DOING SOMETHING WRONGLY!" Next time you see this happen, before rebooting, ps -aux and look at all your root processes and kill them one by one until you suddenly see your disk space come back. That was your offender. Nick.
Re: i386, parallel port permission error?
On Wed, Aug 19, 2020 at 3:09 AM Doug Moss wrote: > On 2020-08-17, Stuart Henderson wrote: > >On 2020-08-17, Doug Moss wrote: > >> > >> Did something change at OpenBSD i386 between 5.9 and 6.0 > >> related to parallel port / lpt hardware permissions? > >> > >> Up to OpenBSD i386 5.9, > >> I used to be able to have a working case-LCD-screen > >> with lcdproc-0.5.7, driver=hd44780, winamp wiring, with 'allowaperture'. > >> At OpenBSD i386 6.0 and after, it fails. > > > >I think this is due to kernel memory access restrictions that were added. > >Setting sysctl kern.allowkmem=1 before securelevel is raised bypasses them > >but of course weakens protections. > > I think the problem in lcdproc is in the code from this file (port.h) > https://github.com/lcdproc/lcdproc/blob/master/server/drivers/port.h > > I am out of my depth with this code. I have never even seen these > calls 'outb' and 'inb' > The code looks like it was begun in 1995. > Is that what you are talking about 'kernel memory access'? > Those are direct CPU instructions for I/O. To use them, the code must use i386_iopl(2) from libarch.a to enable it, which in turn requires the machdep.allowaperture sysctl to a non-zero value (per the manpage). > Any advice about this? Is this code amenable to being 'modernized'? > > If can't modernize the lcdproc code, can you give me specifics about: > Do I just put a line in /etc/rc.securelevel > kern.allowkmem=1 > Try machdep.allowaperture=1 instead. Philip Guenther
Re: httpd - bypass tls misconfig different ciphers, ecdhe
On Wed, August 19, 2020 3:33 am, Hisacro Root wrote: > On Tue, Aug 18, 2020 at 09:28:18PM -0400, trondd wrote: >> The bug here is in how additional listen lines interact with the >> remaining >> configuration. The first listen line in a server block gets the tls >> block >> and it doesn't get applied to the second listen line. Except for certs >> and keys which are handled differently for SNI. > > I rechecked, you're right. In TLS block except for key & certificate, > sub domain server (or the server defined at last) inherits config from > previously defined one (in example config, main server). > > Is it worthy of a bug or could be confusion on configs? > Yeah. I would. It's confusing. Clearly there is an inconsistency in tls parameter handling when there is both a new ip/port and an SNI host defined in the same server block. I'm not a C programmer so deciphering what's going on would take me a while.
mfs reported full, but empty
Hello, After several days, I have to reboot my machine because of mfs full. This is not the first time. I have few mfs on this machine, but I observe that this is always a full filesystem on /tmp after +40 days of uptime. But on other mfs, I have very low filesystem activity. Am I the only one having such problem ? Is there a tool to track this issue and define a more precise root cause ? I'm running 6.7 amd64. Many thanks obsd-fw/tmp# du -h /tmp 1.0K /tmp/.X11-unix 1.0K /tmp/.ICE-unix 1.0K /tmp/vi.recover 11.0K /tmp obsd-fw/tmp# df -h /tmp Filesystem Size Used Avail Capacity Mounted on mfs:71474 991M 991M -49.5M 105% /tmp obsd-fw/tmp# uptime 7:22PM up 57 days, 17:58, 1 user, load averages: 0.08, 0.16, 0.15 obsd-fw/tmp# ps aux | grep mfs root 71474 0.0 12.4 1049016 1016980 ?? S 22Jun20 1:25.23 /sbin/mount_mfs -o rw -s 1024m swap /tmp After a reboot, I have this: obsd-fw~# du -h /tmp 1.0K /tmp/.X11-unix 1.0K /tmp/.ICE-unix 1.0K /tmp/vi.recover 1.6M /tmp obsd-fw~# df -h /tmp Filesystem Size Used Avail Capacity Mounted on mfs:26153 991M 1.6M 940M 0% /tmp obsd-fw~# ps aux | grep mfs root 26153 0.0 0.0 1049016 2068 ?? S 7:30PM 0:00.11 /sbin/mount_mfs -o rw -s 1024m swap /tmp obsd-fw~# uptime 7:42PM up 12 mins, 1 user, load averages: 0.77, 0.59, 0.35 -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
No watchdog detected (IT8613)
Hello All, can someone tell me if the watchdog in IT8613 Super IO chip is supported. I'm trying to setup a router with openBSD 6.7 (stable) and I would love to have the watchdog up and running, yet I can't see the watchdog in dmesg(see below). When I activate the watchdog in bios, the system is reset on timer expiry - so it is definitely working. Best Regards, Strahil Nikolov OpenBSD 6.7 (GENERIC.MP) #5: Tue Jul 21 13:50:07 MDT 2020 r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8491597824 (8098MB) avail mem = 8221622272 (7840MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.8 @ 0xa4ef3000 (81 entries) bios0: vendor American Megatrends Inc. version "5.011" date 12/21/2018 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 LPIT SSDT ASF! SSDT SSDT SSDT DMAR acpi0: wakeup devices PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) PEGP(S4) SIO1(S3) PS2M(S4) RP01(S4) PXSX(S4) RP02(S4) PXSX(S4) RP03(S4) PXSX(S4) RP04(S4) PXSX(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) Core(TM) i3-5010U CPU @ 2.10GHz, 2095.51 MHz, 06-3d-04 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1.1.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz, 2095.15 MHz, 06-3d-04 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 1 (application processor) cpu2: Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz, 2095.15 MHz, 06-3d-04 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 1, core 0, package 0 cpu3 at mainbus0: apid 3 (application processor) cpu3: Intel(R) Core(TM) i3-5010U CPU @ 2.10GHz, 2095.15 MHz, 06-3d-04 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,PT,SENSOR,ARAT,XSAVEOPT,MELTDOWN cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 1, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 40 pins acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1 (PEG2) acpiprt4 at acpi0: bus 1 (RP01) acpiprt5 at acpi0: bus 7 (RP02) acpiprt6 at acpi0: bus 8 (RP03) acpiprt7 at acpi0: bus 9 (RP04) acpiprt8 at acpi0: bus -1 (RP05) acpiprt9 at acpi0: bus -1 (RP06) acpiprt10 at acpi0: bus -1 (RP07) acpiprt11 at acpi0: bus -1 (RP08) acpiec0 at acpi0: not present acpicpu0 at acpi0: C3(200@506 mwait.1@0x60), C2(200@230 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@506 mwait.1@0x60), C2(200@230 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(200@506 mwait.1@0x60), C2(200@230 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C3(200@506 mwait.1@0x60), C2(200@230 mwait.1@0x33), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PG00, resource for PEG0 acpipwrres1 at acpi0: PG01, resource for PEG1 acpipwrres2 at acpi0: PG02, resource for PEG2 acpipwrres3 at acpi0: WRST acpipwrres4 at acpi0: WRST
Re: i386, parallel port permission error?
On 2020-08-17, Stuart Henderson wrote: >On 2020-08-17, Doug Moss wrote: >> >> Did something change at OpenBSD i386 between 5.9 and 6.0 >> related to parallel port / lpt hardware permissions? >> >> Up to OpenBSD i386 5.9, >> I used to be able to have a working case-LCD-screen >> with lcdproc-0.5.7, driver=hd44780, winamp wiring, with 'allowaperture'. >> At OpenBSD i386 6.0 and after, it fails. > >I think this is due to kernel memory access restrictions that were added. >Setting sysctl kern.allowkmem=1 before securelevel is raised bypasses them >but of course weakens protections. I think the problem in lcdproc is in the code from this file (port.h) https://github.com/lcdproc/lcdproc/blob/master/server/drivers/port.h I am out of my depth with this code. I have never even seen these calls 'outb' and 'inb' The code looks like it was begun in 1995. Is that what you are talking about 'kernel memory access'? Any advice about this? Is this code amenable to being 'modernized'? If can't modernize the lcdproc code, can you give me specifics about: Do I just put a line in /etc/rc.securelevel kern.allowkmem=1 Thanks
Re: cwm without a mouse
On Tue, 18 Aug 2020, Jacqueline Jolicoeur wrote: > Hi, > > This may be a strange question, but does anyone use cwm without a mouse? > I use cwm and only use the mouse for the browser. -- Paco Esteban. 0x5818130B8A6DBC03
Re: httpd - bypass tls misconfig different ciphers, ecdhe
On Tue, Aug 18, 2020 at 09:28:18PM -0400, trondd wrote: > The bug here is in how additional listen lines interact with the remaining > configuration. The first listen line in a server block gets the tls block > and it doesn't get applied to the second listen line. Except for certs > and keys which are handled differently for SNI. I rechecked, you're right. In TLS block except for key & certificate, sub domain server (or the server defined at last) inherits config from previously defined one (in example config, main server). Is it worthy of a bug or could be confusion on configs?
cwm without a mouse
Hi, This may be a strange question, but does anyone use cwm without a mouse?
Re: anyone running a Thinkpad T15 Gen1 with 4k display
Hi Tom, I've been looking at the same machine. Note that for the last ~5 years all laptops with Intel CPUs and Nvidia GPUs have their external display adapters physically routed through the Nvidia GPU. I have not seen verofication for this model yet, please report if you see any proof on this. This means that with OpenBSD you can only use the laptops internal display and nothing else. Also note that the Comet lake CPUs (xeon/core i-9/7 models 10xxx) are brand new (launched in ~April 2020) and the drm might not yet be fully supported in OpenBSD. -T On Wed 19. Aug 2020 at 2.44, Tom Smyth wrote: > anyone running a Thinkpad T15 Gen1 with 4k display > > > > Im looking for a new laptop and I would like to Run OpenBSD on it also ... > > > > I was looking for the T series, and Im wondering is anyone running > > > > the T15 Ggen 1 with Nvidia NVIDIA GeForce MX330 GDDR5 2GB 64bits > > Intel Wi-Fi 6 AX201 2x2ax > > > > does anyone have experience with this Laptop... thanks > > Tom Smyth > > > > -- > > Kindest regards, > > Tom Smyth. > > > >
Re: smtpd returns 'TempFail' and 'No route to destination' when using localhost as source behind NAT
As I know, table sources is needed to bind smtpd to an interface while mail
sending, but table helonames is for session IP=name. sorces != helonames in my
particular configuration. So it doesn't work for me.
smtpd should bind to local interface like localhost or another interface on
local system, but smtpd should expose its external address in heloname of
remote system from which mail actually send.
Any ideas?
Martin
‐‐‐ Original Message ‐‐‐
On Saturday, August 15, 2020 2:27 PM, Kastus Shchuka wrote:
> On Sat, Aug 15, 2020 at 07:49:28AM +, Martin wrote:
>
> > It is worth to mention smtpd works absolutely fine for outgoing/incoming
> > mail if local machine has static IP address when:
> > ...
> > table sources {1.2.3.4} equivalent to
> > table helonames {1.2.3.4 = smtp.domain.tld}
> > ...
> > And yes, I have exactly the same action in /etc/mail/smtpd.conf
> > ...
> > table sources {127.0.0.1}
> > table helonames {1.2.3.4 = smtp.domain.tld}
>
> Your helonames table does not have an entry for 127.0.0.1, that is why it
> cannot find helo string for it.
