Re: Browser is getting slower?

[Mihai Popescu]

> 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?

[George Pediaditis]

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"

[Aaron Mason]

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, BSD  wrote:
> 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

[Frank Groeneveld]

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

[Martin Pieuchot]

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

[Bob Jones]

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

[Frank Groeneveld]

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 
ff
real 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

[lvdd]

Hi,

On Sat, 19 Nov 2016 19:58:59 +0100
Patrik Lundin  wrote:

> 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