Re: Browser is getting slower?
> Hello! > i have the impression that my browser is getting slower compared with > a fresh openbsd install. > Any ideas? Global climate is getting warmer, too. > ps. Im using iridium What OpenBSD flavour is that? Bye!
Browser is getting slower?
Hello! i have the impression that my browser is getting slower compared with a fresh openbsd install. Any ideas? ps. Im using iridium
Re: alternative method for "gtar --delete"
Your best bet is to generate a list and use it to build your archive - save a bit of effort and create your omit list: # cd /site1/omit # find . > /tmp/siteXX-omit.lst Then use this list to filter out any unwanted files from /share and /append: # cd /share # find . | grep -v -f /tmp/siteXX-omit.lst | xargs tar -czpvf /site1/siteXX.tgz # cd /append # find . | grep -v -f /tmp/xiteXX-omit.lst | xargs tar -rzpvf /site1/siteXX.tgz Then, for cleanliness' sake: # rm /tmp/siteXX-omit.lst Hope this helps On Sat, Nov 19, 2016 at 3:44 AM, BSDwrote: > On Fri, 18 Nov 2016 14:07:45 +1100 > Aaron Mason wrote: > >> It's a bit long winded, but here's a possibility: >> >> # cd / >> # tar zcpvf siteXX.tgz /share/* /siteX/* >> >> # tar ztf siteXX.tgz | grep '^/share' | xargs rm -f >> >> Though I'm not entirely sure what you mean by "on a per site basis" in >> this context, can you elaborate please, especially if the above >> solution is not what you need. >> >> On Fri, Nov 18, 2016 at 10:20 AM, BSD wrote: >> > Does misc@ have an alternative method for "gtar --delete"? > > Sorry for any vagueness! I don't wish to delete any files from /share, > but have a subset of /share in siteXX.tgz. Also should have mentioned > that /share, /append, and /omit cannot be in the path because > siteXX.tgz is plopped on / during an install. > > What I have so far is to first create an archive using files in /share. > > # cd /share > # tar -cpvf /site1/siteXX.tgz * > > > Then I append to that archive using files in /site1/append. > > # cd /site1/append/ > # tar -rpvf /site1/siteXX.tgz * > > > Next is where I am stuck. Removing files from the archive that are > FROM /share that are not wanted in /site1/siteXX.tgz. I planned to have > an empty file of the same name in /site1/omit for each file to delete > from the archive. > > # cd /site1/omit/ > # tar --delete /site1/siteXX.tgz * > > invalid flag > > Or perhaps I need to have a list of the files that gets appended and > redacted before ever creating the archive. > > Hope this picture got clearer... > -- Aaron Mason - Programmer, open source addict I've taken my software vows - for beta or for worse
Re: Kernel panic on 6.0-stable
On Sun, Nov 20, 2016 at 03:21:32PM +0100, Martin Pieuchot wrote: > On 20/11/16(Sun) 13:58, Frank Groeneveld wrote: > > A few week back there was an outage at my ISP. Afterwards, I kept > > getting crashed on igmpproxy after changing channels on the tv a few > > times: > > This has been fixed in -current. Thanks for the pointer. Does it fix both the igmpproxy crash and the kernel crash? Or just the igmpproxy crash? Frank
Re: Kernel panic on 6.0-stable
On 20/11/16(Sun) 13:58, Frank Groeneveld wrote: > A few week back there was an outage at my ISP. Afterwards, I kept > getting crashed on igmpproxy after changing channels on the tv a few > times: This has been fixed in -current.
Odd slowcgi parsing behavior
Does slowcgi somehow interfere with normal Perl parsing ? (OpenBSD 6) I have a simple Perl Script as follows : === #!/usr/bin/perl use 5.014; use strict; use warnings; use autodie; my $header = << 'END_HEADER'; Test END_HEADER print $header; == Running this on the CLI yields the result as expected : Test = However running this via slowcgi, the first line gets stripped out : == Wifi Incorrect parameters What's going on ???
Kernel panic on 6.0-stable
A few week back there was an outage at my ISP. Afterwards, I kept getting crashed on igmpproxy after changing channels on the tv a few times: - Note: RECV Leave message from 192.168.1.2 to 224.0.0.2 (ip_hl 24, data 8) Debu: Got leave message from 192.168.1.2 to 224.0.251.136. Starting last member detection. Debu: Leaving group 224.0.251.136 upstream on IF address 10.36.229.63 Note: leaveMcGroup: 224.0.251.136 on vlan4 Debu: SENT Membership query from 192.168.1.1 to 224.0.251.136 Debu: Sent membership query from 192.168.1.1 to 224.0.251.136. Delay: 10 Debu: Created timeout 18 (#6) - delay 5 secs Debu: (Id:12, Time:1) Debu: (Id:13, Time:0) Debu: (Id:14, Time:1) Debu: (Id:15, Time:1) Debu: (Id:16, Time:1) Debu: (Id:17, Time:1) Debu: (Id:18, Time:5) Debu: (Id:10, Time:7) Debu: About to call timeout 12 (#0) Debu: Aging Origin 213.75.167.6 Dst 224.0.251.126 PktCnt 1022 -> 1022 Debu: Origin 213.75.167.6 Vif bits : 0x0002 Debu: Setting TTL for Vif 1 to 1 Debu: Identified VIF #2 as upstream. Note: Removing MFC: 213.75.167.6 -> 224.0.251.126, InpVIf: 2 igmpproxy(18177) in free(): error: use after free 0x1116efc3b400 Abort trap (core dumped) - Because I didn't have time to debug it, I started igmpproxy in a while true loop and was able to watch television with some minor hickups now and then. Today I finally had time to have a go at it, but wasn't able to figure out the cause. Still being on 5.9-stable I decided to first upgrade to 6.0-stable and see whether that helped. This made my problem worse, because now as soon as igmpproxy was running it would panic (full dmeg attached with the panic at the bottom). I found mention of said panic in plus60.html: > In pf(4), don't panic if an mbuf(9) already has a statekey. This should > help finding the remaining corner cases of packets looped back in the > stack. This leads me to believe that my panic should not occur, but it still is. Does anybody have a clue how I can work around this? Is there maybe something wrong with my pf rules? I've attached them and the igmpproxy.conf as well. For now I've downgraded to 5.9-stable again. Thanks in advance, Frank booting hd0a:/bsd: 6893364+2179280+267272+0+663552 [72+726864+483332]=0xab3a20 entry point at 0x1001000 [7205c766, 3404, 24448b12, 3be0a304] [ using 1210912 bytes of bsd ELF symbol table ] Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. Copyright (c) 1995-2016 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 6.0-stable (GENERIC.MP) #6: Sun Nov 20 10:16:50 CET 2016 frank@phenom.local:/usr/src/sys/arch/amd64/compile/GENERIC.MP RTC BIOS diagnostic error ffreal mem = 4246003712 (4049MB) avail mem = 4112846848 (3922MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xdf16d820 (7 entries) bios0: vendor coreboot version "4.0" date 09/08/2014 bios0: PC Engines APU acpi0 at bios0: rev 0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD G-T40E Processor, 1000.14 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 199MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD G-T40E Processor, 1000.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins acpiprt0 at acpi0: bus -1 (AGPB) acpiprt1 at acpi0: bus -1 (HDMI) acpiprt2 at acpi0: bus 1 (PBR4) acpiprt3 at acpi0: bus 2
Re: pkg_add: signify broken pipe when running from script
Hi, On Sat, 19 Nov 2016 19:58:59 +0100 Patrik Lundinwrote: > On Sat, Nov 19, 2016 at 06:27:16PM +0100, Marc Espie wrote: > > Wondering if your script isn't passing some weird signal handling > > (such as ignoring some signals) through. > > > > Seems like you are on to something :). > > Some googling led me here: > https://blog.nelhage.com/2010/02/a-very-subtle-bug/ > > It talks about how python ignores SIGPIPE and shows how it can be > worked around when using subprocess.Popen. > > I can solve the problem by adding the following line > in /usr/sbin/pkg_add: > === > $SIG{PIPE} = 'DEFAULT'; > === > thank you Patrik. I just wanted to report that this solved the problem I am having with this since 1.5 months as well. Please read http://marc.info/?l=openbsd-misc=147544336719598=2 for details. I know this is not a final solution but you seem to have a deeper understanding of this than I have. regards Lars