Re: where to start troubleshooting pfsync?
On 2015-02-13, Adam Thompson athom...@athompso.net wrote: I've got two OpenBSD 5.6-STABLE (courtesy of M:Tier packages, thanks guys!) BGP routers running carp pfsync between them for some of the internal interfaces. Yes, I probably should have done this using two routers, two firewalls ECMP, but I didn't have enough hardware, so I collapsed the firewall function onto the routers and used CARP instead of ECMP for outbound traffic. That should work - I'm doing exactly this (though not 5.6-stable) on the routers in front of a machine that I have long-running connections to and I'd definitely notice problems like this. Some differences compared to your setup, though I don't see why they would change anything: my syncdev is a directly cabled connection, I'm using the default multicast setup not syncpeer, I'm not using pflow. So... at this point, what problem indicators (counters? log messages?) should I be looking at or monitoring? pfctl -si might give some clues. One common problem: is your state limit sufficiently high? (will show as memory iirc). You might either need to set the defer flag on the pfsync(4) interface, or use flags any on your pf rules, to cope with incoming and outgoing traffic taking different paths.
Installing OpenBSD 5.6 using a USB Flash drive
Hi all, I used the following command to create a USB flash drive installation media (with all file sets included): # dd if=/location/install56.fs of=/dev/rsd0c bs=1m The USB flash drive was created successfully. The boot process from the USB was done. However, when we came to installing file sets, the following prompt was displayed: Location of sets? (disk http or 'done') [http] Now, what can I do to direct the installation process to look for the file sets in the USB flash drive? The documentation says: Once the install kernel is booted, you have several options of where to get the install file sets: CD-ROM, HTTP, Local disk partition, NFS (no mention to USB) Thank you
Re: postgresql-server exiting abnormally after upgrade to -snapshot
On 2015-02-14 02:28, Abel Abraham Camarillo Ojeda wrote: On Sat, Feb 14, 2015 at 2:12 AM, Hugo Osvaldo Barrera h...@barrera.io wrote: On 2015-02-13 13:20, Stuart Henderson wrote: On 2015-02-12, Hugo Osvaldo Barrera h...@barrera.io wrote: On 2015-02-12 10:18, Stuart Henderson wrote: On 2015-02-11, Hugo Osvaldo Barrera h...@barrera.io wrote: Can someone else confirm postgres9.4 work fine on the latest -snapshot? (the confirmation would be helpful to reafirm that it's not an issue with some dependency or library). Works fine on my bacula box, running 9.4.1 (and previously 9.4.0) on amd64. Ok, so now I know that the issue is on my end. Which leaves me even more confused. You're running the latest snapshots too, right? (eg: the ones from feb 10th?). Aside from a clean install, do you have any more changes? Perhaps login.conf? I have the login.conf section from the example in the pkg-readme, postgresql:\ :openfiles-cur=768:\ :tc=daemon: and this in sysctl.conf # postgresql kern.seminfo.semmni=256 kern.seminfo.semmns=2048 kern.shminfo.shmmax=50331648 sthen@hutch:~:532$ ls -l /bin/ls /usr/local/bin/postgres -r-xr-xr-x 1 root bin 267968 Feb 10 23:19 /bin/ls* -r-xr-xr-x 1 root bin 6508711 Feb 9 03:21 /usr/local/bin/postgres* sthen@hutch:~:533$ sysctl kern.version kern.version=OpenBSD 5.7-beta (GENERIC) #797: Tue Feb 10 16:26:12 MST 2015 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC Thanks for all the details. It looks like almost everything is identical except our kernels (I had a few extra fields in sysctl.conf edited for pg, but reverted them just to make sure they weren't screwing up). # sysctl kern.version kern.version=OpenBSD 5.7-beta (GENERIC.MP) #852: Tue Feb 10 16:31:16 MST 2015 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP I switched to the SP kernel just to discard any possible regressions that might be affecting this scenario, but no change. It looks like the issue is elsewhere, but I've no idea where to look. I've so far failed to build postgresql-server with debug symbols enabled too, but that's just lack of knowledge on my part. -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? [demime 1.01d removed an attachment of type application/pgp-signature] you should give more information about how to reproduce this problem, how accurately can you reproduce it, are you sending just a given query and it always crashes? It always crashes extremely frequently. I haven't noticed a pattern, and the server never lives more than a few senconds. No particular query seems to trigger it, and adding log_statement showed that it may even crash *before* any queries are executed (see below as well). you should get more error context, maybe try log_statement into postgresql.conf and try to log all statements and see which one crashes it... http://www.postgresql.org/docs/9.4/static/runtime-config-logging.html are you using any custom C extension? Nope, this is a plain default install from snapshots with nothing extra. did you dump and restore database ? did you use 'custom format' or 'plain format' ? My latest tests reproduce the same issue on a clean out-of-the-box db (eg: not importing any data). there where any errors on import? - postgres just warns about some import errors, which in my opinion are severe... This is a log with log_statement and a most logging turned on. I'd only run the server *once* post-initialization before this. The database was completely empty: http://sprunge.us/UVGj While a query managed to get through once, the server usually crashed before that happens. Here's another, finer-grained log, with nothing useful (apperently) either: http://sprunge.us/FQaJ Thanks, -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? [demime 1.01d removed an attachment of type application/pgp-signature]
Re: postgresql-server exiting abnormally after upgrade to -snapshot
On Saturday 14 February 2015, Hugo Osvaldo Barrera wrote: On 2015-02-14 02:28, Abel Abraham Camarillo Ojeda wrote: On Sat, Feb 14, 2015 at 2:12 AM, Hugo Osvaldo Barrera h...@barrera.io wrote: On 2015-02-13 13:20, Stuart Henderson wrote: On 2015-02-12, Hugo Osvaldo Barrera h...@barrera.io wrote: On 2015-02-12 10:18, Stuart Henderson wrote: On 2015-02-11, Hugo Osvaldo Barrera h...@barrera.io wrote: Can someone else confirm postgres9.4 work fine on the latest -snapshot? (the confirmation would be helpful to reafirm that it's not an issue with some dependency or library). Works fine on my bacula box, running 9.4.1 (and previously 9.4.0) on amd64. Ok, so now I know that the issue is on my end. Which leaves me even more confused. You're running the latest snapshots too, right? (eg: the ones from feb 10th?). Aside from a clean install, do you have any more changes? Perhaps login.conf? I have the login.conf section from the example in the pkg-readme, postgresql:\ :openfiles-cur=768:\ :tc=daemon: and this in sysctl.conf # postgresql kern.seminfo.semmni=256 kern.seminfo.semmns=2048 kern.shminfo.shmmax=50331648 sthen@hutch:~:532$ ls -l /bin/ls /usr/local/bin/postgres -r-xr-xr-x 1 root bin 267968 Feb 10 23:19 /bin/ls* -r-xr-xr-x 1 root bin 6508711 Feb 9 03:21 /usr/local/bin/postgres* sthen@hutch:~:533$ sysctl kern.version kern.version=OpenBSD 5.7-beta (GENERIC) #797: Tue Feb 10 16:26:12 MST 2015 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC Thanks for all the details. It looks like almost everything is identical except our kernels (I had a few extra fields in sysctl.conf edited for pg, but reverted them just to make sure they weren't screwing up). # sysctl kern.version kern.version=OpenBSD 5.7-beta (GENERIC.MP) #852: Tue Feb 10 16:31:16 MST 2015 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP I switched to the SP kernel just to discard any possible regressions that might be affecting this scenario, but no change. It looks like the issue is elsewhere, but I've no idea where to look. I've so far failed to build postgresql-server with debug symbols enabled too, but that's just lack of knowledge on my part. -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? [demime 1.01d removed an attachment of type application/pgp-signature] you should give more information about how to reproduce this problem, how accurately can you reproduce it, are you sending just a given query and it always crashes? It always crashes extremely frequently. I haven't noticed a pattern, and the server never lives more than a few senconds. No particular query seems to trigger it, and adding log_statement showed that it may even crash *before* any queries are executed (see below as well). you should get more error context, maybe try log_statement into postgresql.conf and try to log all statements and see which one crashes it... http://www.postgresql.org/docs/9.4/static/runtime-config-logging.html are you using any custom C extension? Nope, this is a plain default install from snapshots with nothing extra. did you dump and restore database ? did you use 'custom format' or 'plain format' ? My latest tests reproduce the same issue on a clean out-of-the-box db (eg: not importing any data). there where any errors on import? - postgres just warns about some import errors, which in my opinion are severe... This is a log with log_statement and a most logging turned on. I'd only run the server *once* post-initialization before this. The database was completely empty: http://sprunge.us/UVGj While a query managed to get through once, the server usually crashed before that happens. The interesting/useful part is: LOG: statement: SELECT ... ORDER BY c.oid LOG: server process (PID 11531) was terminated by signal 6: Abort trap So the server process is being sent a SIGABRT, which is causing it to terminate. There is a good chance this this is coming from the stack protector, which sends a SIGABRT if the stack is smashed. Is there anything in dmesg or syslog that correlates? Failing that your next step is likely to run it under gdb and get a backtrace from the point where the SIGABRT occurs. You can also bisect by rolling back to an older snapshot to see if you can locate the change that has triggered the issue. Here's another, finer-grained log, with nothing useful (apperently) either: http://sprunge.us/FQaJ Thanks, -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? [demime 1.01d
Re: postgresql-server exiting abnormally after upgrade to -snapshot
On 2015-02-14, Joel Sing j...@sing.id.au wrote: The interesting/useful part is: LOG: statement: SELECT ... ORDER BY c.oid LOG: server process (PID 11531) was terminated by signal 6: Abort trap So the server process is being sent a SIGABRT, which is causing it to terminate. There is a good chance this this is coming from the stack protector, which sends a SIGABRT if the stack is smashed. Oh, good call. It could also be a backwards memcpy which would show up in /var/log/messages (assuming usual config). If it were another program, our strict mutex checks can also cause SIGABRT, but that won't apply to pgsql as it's not threaded.
Re: root partition full; /dev taking up all the space?
On Fri, Feb 13, 2015 at 11:46 PM, Martin Brandenburg mar...@martinbrandenburg.com wrote: My guess is you typoed a dd command and ended up creating some huge file in there. That's exactly what happened; I recall dd'ing an image to a USB stick and using /dev/rsd2 instead of /dev/rsd2c. And sure enough that was the culprit. Problem solved. Thanks!
Re: Installing OpenBSD 5.6 using a USB Flash drive
On 2015-02-14, A Y afyous...@hotmail.com wrote: Hi all, I used the following command to create a USB flash drive installation media (with all file sets included): # dd if=/location/install56.fs of=/dev/rsd0c bs=1m The USB flash drive was created successfully. The boot process from the USB was done. However, when we came to installing file sets, the following prompt was displayed: Location of sets? (disk http or 'done') [http] Now, what can I do to direct the installation process to look for the file sets in the USB flash drive? The documentation says: Once the install kernel is booted, you have several options of where to get the install file sets: CD-ROM, HTTP, Local disk partition, NFS (no mention to USB) Thank you You need Disk here; I haven't done a USB install but I'm guessing that you probably need to shell out and mount the USB stick manually (something like mount /dev/sdXa /mnt2 where X is the correct number for the USB stick).
Re: Installing OpenBSD 5.6 using a USB Flash drive
Stuart Henderson s...@spacehopper.org writes: You need Disk here; I haven't done a USB install but I'm guessing that you probably need to shell out and mount the USB stick manually (something like mount /dev/sdXa /mnt2 where X is the correct number for the USB stick). IIRC it's choose disk, choose not mounted, then choose device. The installer will do the magic without you needing to escape to a shell. - Peter -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
support new
0 C Czech Republic P Prague T Prague Z 11000 O CORE ZONE s.r.o. I Gabriel Medon A Rybna 716/24 M i...@corezone.cz U http://corezone.cz/ B +420 607 577 677 X NONE N CORE ZONE s.r.o. is an IT outsourcing and consultancy company which provides installations, administration and support for systems based on FreeBSD, OpenBSD, Linux (CentOS, Debian, Ubuntu).
Re: Installing OpenBSD 5.6 using a USB Flash drive
Ok, I did. Please let me know if it works. To: afyous...@hotmail.com Subject: Re: Installing OpenBSD 5.6 using a USB Flash drive From: pe...@bsdly.net Date: Sat, 14 Feb 2015 20:15:04 +0100 A Y afyous...@hotmail.com writes: I only click on the 'reply' tab, in outlook.com, to reply. Isn't this what I am supposed to do? This is my very first email, so, I guess, there is much to learn. See if there isn't a Cc: field or something similar. Or simply type misc@openbsd.org in place of my address. - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
Re: postgresql-server exiting abnormally after upgrade to -snapshot
On 2015-02-13 13:20, Stuart Henderson wrote: On 2015-02-12, Hugo Osvaldo Barrera h...@barrera.io wrote: On 2015-02-12 10:18, Stuart Henderson wrote: On 2015-02-11, Hugo Osvaldo Barrera h...@barrera.io wrote: Can someone else confirm postgres9.4 work fine on the latest -snapshot? (the confirmation would be helpful to reafirm that it's not an issue with some dependency or library). Works fine on my bacula box, running 9.4.1 (and previously 9.4.0) on amd64. Ok, so now I know that the issue is on my end. Which leaves me even more confused. You're running the latest snapshots too, right? (eg: the ones from feb 10th?). Aside from a clean install, do you have any more changes? Perhaps login.conf? I have the login.conf section from the example in the pkg-readme, postgresql:\ :openfiles-cur=768:\ :tc=daemon: and this in sysctl.conf # postgresql kern.seminfo.semmni=256 kern.seminfo.semmns=2048 kern.shminfo.shmmax=50331648 sthen@hutch:~:532$ ls -l /bin/ls /usr/local/bin/postgres -r-xr-xr-x 1 root bin 267968 Feb 10 23:19 /bin/ls* -r-xr-xr-x 1 root bin 6508711 Feb 9 03:21 /usr/local/bin/postgres* sthen@hutch:~:533$ sysctl kern.version kern.version=OpenBSD 5.7-beta (GENERIC) #797: Tue Feb 10 16:26:12 MST 2015 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC Thanks for all the details. It looks like almost everything is identical except our kernels (I had a few extra fields in sysctl.conf edited for pg, but reverted them just to make sure they weren't screwing up). # sysctl kern.version kern.version=OpenBSD 5.7-beta (GENERIC.MP) #852: Tue Feb 10 16:31:16 MST 2015 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP I switched to the SP kernel just to discard any possible regressions that might be affecting this scenario, but no change. It looks like the issue is elsewhere, but I've no idea where to look. I've so far failed to build postgresql-server with debug symbols enabled too, but that's just lack of knowledge on my part. -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? [demime 1.01d removed an attachment of type application/pgp-signature]
Re: postgresql-server exiting abnormally after upgrade to -snapshot
On Sat, Feb 14, 2015 at 2:12 AM, Hugo Osvaldo Barrera h...@barrera.io wrote: On 2015-02-13 13:20, Stuart Henderson wrote: On 2015-02-12, Hugo Osvaldo Barrera h...@barrera.io wrote: On 2015-02-12 10:18, Stuart Henderson wrote: On 2015-02-11, Hugo Osvaldo Barrera h...@barrera.io wrote: Can someone else confirm postgres9.4 work fine on the latest -snapshot? (the confirmation would be helpful to reafirm that it's not an issue with some dependency or library). Works fine on my bacula box, running 9.4.1 (and previously 9.4.0) on amd64. Ok, so now I know that the issue is on my end. Which leaves me even more confused. You're running the latest snapshots too, right? (eg: the ones from feb 10th?). Aside from a clean install, do you have any more changes? Perhaps login.conf? I have the login.conf section from the example in the pkg-readme, postgresql:\ :openfiles-cur=768:\ :tc=daemon: and this in sysctl.conf # postgresql kern.seminfo.semmni=256 kern.seminfo.semmns=2048 kern.shminfo.shmmax=50331648 sthen@hutch:~:532$ ls -l /bin/ls /usr/local/bin/postgres -r-xr-xr-x 1 root bin 267968 Feb 10 23:19 /bin/ls* -r-xr-xr-x 1 root bin 6508711 Feb 9 03:21 /usr/local/bin/postgres* sthen@hutch:~:533$ sysctl kern.version kern.version=OpenBSD 5.7-beta (GENERIC) #797: Tue Feb 10 16:26:12 MST 2015 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC Thanks for all the details. It looks like almost everything is identical except our kernels (I had a few extra fields in sysctl.conf edited for pg, but reverted them just to make sure they weren't screwing up). # sysctl kern.version kern.version=OpenBSD 5.7-beta (GENERIC.MP) #852: Tue Feb 10 16:31:16 MST 2015 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP I switched to the SP kernel just to discard any possible regressions that might be affecting this scenario, but no change. It looks like the issue is elsewhere, but I've no idea where to look. I've so far failed to build postgresql-server with debug symbols enabled too, but that's just lack of knowledge on my part. -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? [demime 1.01d removed an attachment of type application/pgp-signature] you should give more information about how to reproduce this problem, how accurately can you reproduce it, are you sending just a given query and it always crashes? you should get more error context, maybe try log_statement into postgresql.conf and try to log all statements and see which one crashes it... http://www.postgresql.org/docs/9.4/static/runtime-config-logging.html are you using any custom C extension? did you dump and restore database ? did you use 'custom format' or 'plain format' ? there where any errors on import? - postgres just warns about some import errors, which in my opinion are severe...
Re: postgresql-server exiting abnormally after upgrade to -snapshot
On 2015-02-14 13:29, Stuart Henderson wrote: On 2015-02-14, Joel Sing j...@sing.id.au wrote: The interesting/useful part is: LOG: statement: SELECT ... ORDER BY c.oid LOG: server process (PID 11531) was terminated by signal 6: Abort trap So the server process is being sent a SIGABRT, which is causing it to terminate. There is a good chance this this is coming from the stack protector, which sends a SIGABRT if the stack is smashed. Oh, good call. It could also be a backwards memcpy which would show up in /var/log/messages (assuming usual config). Yup, backward memcpy it is (from /var/log/messages): Feb 14 12:27:34 elysion postgres: backwards memcpy Feb 14 12:28:10 elysion last message repeated 8 times Feb 14 12:30:19 elysion last message repeated 28 times Feb 14 12:40:28 elysion last message repeated 128 times Feb 14 12:50:40 elysion last message repeated 128 times Feb 14 13:00:41 elysion last message repeated 126 times Feb 14 13:10:42 elysion last message repeated 128 times Feb 14 13:20:49 elysion last message repeated 126 times Feb 14 13:30:55 elysion last message repeated 128 times Feb 14 13:41:06 elysion last message repeated 132 times Feb 14 13:51:10 elysion last message repeated 128 times Feb 14 14:01:18 elysion last message repeated 128 times Feb 14 14:08:18 elysion last message repeated 91 times Am I mistaken in understanding that this is an issue with postgresql itself, and not a local configuration error? I tried building postgres with debug symbols (I added the flags described here[1] to the ports Makefile), but the backtrace is still useless: # sudo -u _postgresql gdb -q -c postgres.core /usr/local/bin/postgres Core was generated by `postgres'. Program terminated with signal 6, Aborted. Loaded symbols for /usr/local/bin/postgres #0 0x0bd73424292a in ?? () (gdb) bt #0 0x0bd73424292a in ?? () #1 0x in ?? () Do I need any further OpenBSD-specific changes to get a useful backtrace? (I've to admit that I'm too familiar with debuging with gdb on any platform). Thanks for all the feedback so far! [1]: https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQ L_backend_on_Linux/BSD#Debugging_the_core_dump_-_example -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
