Re: mysql.sock location
Gilbert, Thanks very much for supplying the text of your readme. In mine, v5.1.68, which I am pretty sure was the latest version on i386 about tow weeks ago, all the text beginning with the heading chrooted daemons and MySQL socket = ...does not exist. SO thanks for that. And I agree with your point about multiple readings. I guess I've learnt bad habits of googling and skimming for quick tuutes on how to do things, with OpenBSD I need to spend the time to learn how it works, Guy On 24/08/2013 14:46, Gilbert Sanford wrote: chrooted daemons and MySQL socket
Re: mysql.sock location
You're welcome. Since the OpenBSD documentation is clear and precise, any cloud of confusion must be a product of my own defective thinking. So I keep going back to the documentation (I stay off Google for OpenBSD research) to push it in and push out the misunderstanding. I always figured @misc would not be interested in hearing about my struggles. As far as learning is concerned, I'm just hard-headed enough (or stubborn or persistent or tenacious or dense . . . pick one) to keep after something until I get it. After 5 years, I'm just now beginning to appreciate and understand enough to recognize the genius behind OpenBSD . . . Gilbert On Fri, Aug 23, 2013 at 11:53 PM, Guy Ferguson wrote: > Gilbert, > > Thanks very much for supplying the text of your readme. > > In mine, v5.1.68, which I am pretty sure was the latest version on i386 > about tow weeks ago, all the text beginning with the heading > > > chrooted daemons and MySQL socket > = > > ...does not exist. > > SO thanks for that. And I agree with your point about multiple readings. I > guess I've learnt bad habits of googling and skimming for quick tuutes on > how to do things, with OpenBSD I need to spend the time to learn how it > works, > > Guy > > > On 24/08/2013 14:46, Gilbert Sanford wrote: >> >> chrooted daemons and MySQL socket
Re: mysql.sock location
Since you said you were new to OpenBSD, I trust the length of this post is justified, and I'm not offending others on this list. I've been using OpenBSD around 5 years now, but I had not subscribed or ever posted anything to @misc until your post. Actually, I've never participated in any mailing list until now, so I hope my humble attempt is helpful in some small way. Please understand that I trust the documentation over which the developers have spent countless hours to make clear and precise, so I will only offer what much wiser and knowledgeable persons (the OpenBSD developers) have written. Speaking again only for myself, I have learned that in order to understand what the OpenBSD developers have so clearly and precisely written, I must read it multiple times before I grasp the concept well enough to achieve my objectives. In other words, pay very close attention to everything in the OpenBSD documentation. Also read references to man pages if mentioned for additional insight. I'm running -current with mysql-server-5.1.71v0 on amd64, and I am including the README for mysql-server on MY box below. The README file on YOUR box may be different. Please pay very careful attention to the section entitled "chrooted daemons and MySQL socket" and note that there are two things to do in order to place the MySQL socket in the chroot: 1) Create a directory for the MySQL socket, and 2) Adjust /etc/my.cnf to put and connect to the MySQL socket within the chroot. See below for full context and note the author :) $OpenBSD: README-server,v 1.7 2013/03/17 07:22:23 ajacoutot Exp $ +--- | Running mysql-server-5.1.71v0 on OpenBSD +--- Initial setup = If you are installing MySQL for the first time, you have to create a default database first. In order to create the database, please run /usr/local/bin/mysql_install_db You will need to tune the values in the my.cnf file (examples available in /usr/local/share/mysql). By default, the _mysql user, and so the MySQL processes run in the login(1) class of "daemon". On a busy server, it may be advisable to put the _mysql user and processes in their own login(1) class with tuned resources, such as more open file descriptors etc. For example, add this to the login.conf(5) file: mysqld:\ :openfiles-cur=1024:\ :openfiles-max=2048:\ :tc=daemon: Rebuild the login.conf.db file if necessary: # [ -f /etc/login.conf.db ] && cap_mkdb /etc/login.conf For larger servers and dedicated database servers, these numbers and memory limits (e.g. datasize and stacksize) may also need to be increased. Please report any changes and experiences to the package maintainers so that we can update this file for future versions. chrooted daemons and MySQL socket = For external program running under a chroot(8) to be able to access the MySQL server without using a network connection, the socket must be placed inside the chroot. e.g. httpd(8) or nginx(8): connecting to MySQL from PHP --- Create a directory for the MySQL socket: # install -d -m 0711 -o _mysql -g _mysql /var/www/var/run/mysql Adjust /etc/my.cnf to put and connect to the MySQL socket within the chroot: [client] socket = /var/www/var/run/mysql/mysql.sock [mysqld] socket = /var/www/var/run/mysql/mysql.sock I follow the directions above whenever I set up a new box, and I check that mysql-server is running in the chroot after I reboot the box. Output from my box is below: $ /usr/bin/sudo ls -l /var/www/var/run/mysql/ total 0 srwxrwxrwx 1 _mysql _mysql 0 Aug 23 22:10 mysql.sock Then I load up mysql-server. Now that I've done this a few thousand times, it's easy . . . Gilbert On Fri, Aug 23, 2013 at 10:06 PM, Guy Ferguson wrote: > Hmm - ok, I actually just went to that path > (/usr/local/share/doc/pkg-readmes/) and there are 4 files, one of which is a > mysql-server-5.x.xx..but it's only 1325 bytes, and certainly no > comments from users like ajacoutot@. I mean, there are maybe two or three > sugegstions about changing the login.conf and my.cnf, but it certainly > wouldn't have been any help with the issues i faced. > > Perhaps there are some other dox in another location? > > thanks, > > Guy > > On 23/08/2013 22:16, Gilbert Sanford wrote: >> >> The instructions in /usr/local/share/doc/pkg-readmes/mysql-server-5.1.xx >> have always worked for me . . . very handy reference with specific >> instructions from ajacoutot@ on "Running mysql-server-5.1.xx on >> OpenBSD." >> >> Gilbert
Re: mysql.sock location
Hmm - ok, I actually just went to that path (/usr/local/share/doc/pkg-readmes/) and there are 4 files, one of which is a mysql-server-5.x.xx..but it's only 1325 bytes, and certainly no comments from users like ajacoutot@. I mean, there are maybe two or three sugegstions about changing the login.conf and my.cnf, but it certainly wouldn't have been any help with the issues i faced. Perhaps there are some other dox in another location? thanks, Guy On 23/08/2013 22:16, Gilbert Sanford wrote: The instructions in /usr/local/share/doc/pkg-readmes/mysql-server-5.1.xx have always worked for me . . . very handy reference with specific instructions from ajacoutot@ on "Running mysql-server-5.1.xx on OpenBSD." Gilbert On Fri, Aug 23, 2013 at 4:34 AM, Guy Ferguson wrote: liviu, At last, I get your name right, if a little under-capitalised. Your help was the first step in maybe a dozen or so that got the site back up. So thank you kindly for that. Just some minor linking to outside the chroot and it'll be perfect. But thanks for the help. guy On 19/08/2013 02:54, Liviu Daia wrote: On 18 August 2013, Guy Ferguson wrote: Livia, If you want to address me by name, s/Livia/Liviu/ please. It might not be much, but it's my name, and I kind of became attached to it over the years. :) Thanks for your help. I modded the /etc/my.cnf to add in the extra "/run" directory. A few other tweaks here and there and i can now get a test.php to connect to the default host mysql ($conn=mysql_connect...) So now i'm confident that mysql is working and connectable...I just ahve to sort out why drupal is unhappy, which no doubt is a chroot issue. [...] Like I said, the easy solution to that is to use TCP connections. As others have pointed out, just set hostname to 127.0.0.1 in your Drupal config, and you should be fine. If you insist on using UNIX sockets, you probably want to set socket = /var/www/run/mysql.sock in the /etc/my.cnf, then copy /etc/my.cnf to /var/www/etc/my.cnf, and set socket = /run/mysql.sock in the client section in /var/www/etc/my.cnf. There is no advantage in doing things like this though, you'd be just looking for future trouble. Regards, Liviu Daia - No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3392 / Virus Database: 3211/6584 - Release Date: 08/16/13 - No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3392 / Virus Database: 3211/6603 - Release Date: 08/23/13
In some man pages Mb means MB, in others it means Mb/s
I was just reading some random man pages, and noticed a few places where "Mb" should probably be changed to "MB", since the intended meaning is Megabytes, not Megabits. In the base system, these are sort(1) and ld(1). I have only a few additional packages installed, but found it also in /usr/local/man/cat3/pcrestack.0 The "Mb" abbreviation is also used in pf-related pages: hostapd.conf(5), iked.conf(5), ipsec.conf(5), pf.conf(5), in the meaning Megabits per second. So it could be more correctly written as Mb/s (or at least Mbps). However, since the Mb word, in the meaning Mb/s, is already part of pf syntax, I suppose it is going to stay that way. :) Cheers, Zeljko Jovanovic
Re: how to "aggregate" a single TCP connection, is posible?
Not yet, will test. On Thu, Aug 22, 2013 at 7:05 AM, Stuart Henderson wrote: > On 2013-08-22, Abel Abraham Camarillo Ojeda wrote: >> Is there a way to duplicate the throughput of a single >> TCP connection using two servers having two gigabit NICs? >> >> I have tried using LACP but I cannot get more than >> 900MB of throughput... > > LACP uses a hash over IP addresses/vlan tags/flowlabel to avoid problems > with out-of-order packet delivery. (Similar for equal-cost multipath). > Have you tried a roundrobin trunk yet?
Unexpected results from boot(8) "machine memory" configuration
I expected "machine memory =1G" to reduce the memory size of this system from 8GB to 1GB. After the first invocation, free memory is reduced to ~6GB. The second invocation results in the expected ~1GB free memory. My intention is to limit the size of a subsequent crash dump. I'm surprised it took two invocations to get the expected results. Thanks in advance for helping me better understand this issue. syncing disks... done rebooting... >> OpenBSD/amd64 BOOT 3.23 boot> machine memory Region 0: type 1 at 0x0 for 630KB Region 1: type 2 at 0x9d800 for 10KB Region 2: type 2 at 0xe for 128KB Region 3: type 1 at 0x10 for 3135984KB Region 4: type 4 at 0xbf77c000 for 288KB Region 5: type 3 at 0xbf7c4000 for 32KB Region 6: type 2 at 0xbf7cc000 for 16KB Region 7: type 4 at 0xbf7d for 16KB Region 8: type 2 at 0xbf7d4000 for 2496KB Region 9: type 4 at 0xbfa44000 for 28KB Region 10: type 2 at 0xbfa4b000 for 160KB Region 11: type 4 at 0xbfa73000 for 2060KB Region 12: type 1 at 0xbfc76000 for 2600KB Region 13: type 1 at 0x11000 for 4964348KB Region 14: type 2 at 0xe000 for 262144KB Region 15: type 2 at 0xfec0 for 4KB Region 16: type 2 at 0xfec1 for 4KB Region 17: type 2 at 0xfed0 for 4KB Region 18: type 2 at 0xfed61000 for 64KB Region 19: type 2 at 0xfed8 for 64KB Region 20: type 2 at 0xff00 for 16384KB Low ram: 630KB High ram: 3135984KB Total free memory: 8103562KB boot> machine memory =1G Region 0: type 1 at 0x0 for 630KB Region 1: type 2 at 0x9d800 for 10KB Region 2: type 2 at 0xe for 128KB Region 3: type 1 at 0x10 for 1047552KB Region 4: type 4 at 0xbf77c000 for 288KB Region 5: type 3 at 0xbf7c4000 for 32KB Region 6: type 2 at 0xbf7cc000 for 16KB Region 7: type 4 at 0xbf7d for 16KB Region 8: type 2 at 0xbf7d4000 for 2496KB Region 9: type 4 at 0xbfa44000 for 28KB Region 10: type 2 at 0xbfa4b000 for 160KB Region 11: type 4 at 0xbfa73000 for 2060KB Region 12: type 1 at 0x11000 for 4964348KB Region 13: type 2 at 0xe000 for 262144KB Region 14: type 2 at 0xfec0 for 4KB Region 15: type 2 at 0xfec1 for 4KB Region 16: type 2 at 0xfed0 for 4KB Region 17: type 2 at 0xfed61000 for 64KB Region 18: type 2 at 0xfed8 for 64KB Region 19: type 2 at 0xff00 for 16384KB Low ram: 630KB High ram: 3135984KB Total free memory: 6012530KB boot> machine memory =1G Region 0: type 1 at 0x0 for 630KB Region 1: type 2 at 0x9d800 for 10KB Region 2: type 2 at 0xe for 128KB Region 3: type 1 at 0x10 for 1047552KB Region 4: type 4 at 0xbf77c000 for 288KB Region 5: type 3 at 0xbf7c4000 for 32KB Region 6: type 2 at 0xbf7cc000 for 16KB Region 7: type 4 at 0xbf7d for 16KB Region 8: type 2 at 0xbf7d4000 for 2496KB Region 9: type 4 at 0xbfa44000 for 28KB Region 10: type 2 at 0xbfa4b000 for 160KB Region 11: type 4 at 0xbfa73000 for 2060KB Region 12: type 2 at 0xe000 for 262144KB Region 13: type 2 at 0xfec0 for 4KB Region 14: type 2 at 0xfec1 for 4KB Region 15: type 2 at 0xfed0 for 4KB Region 16: type 2 at 0xfed61000 for 64KB Region 17: type 2 at 0xfed8 for 64KB Region 18: type 2 at 0xff00 for 16384KB Low ram: 630KB High ram: 3135984KB Total free memory: 1048182KB boot> boot booting hd0a:/bsd: 6503036+1639852+1076056+0+623264 [80+552312+368725]=0xe453c0 entry point at 0x10001e0 [7205c766, 3404, 24448b12, b958a304] [ using 921888 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-2013 OpenBSD. All rights reserved. http://www.OpenBSD.org OpenBSD 5.4-current (GENERIC.MP) #44: Mon Aug 19 17:02:07 MDT 2013 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 1056964608 (1008MB) avail mem = 1020780544 (973MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0xeb0c0 (17 entries) bios0: vendor American Megatrends Inc. version "P1.60" date 05/29/2012 bios0: ASRock A75M-ITX acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG AAFT HPET SSDT SSDT acpi0: wakeup devices SBAZ(S4) CIR_(S3) PS2K(S4) PS2M(S4) UAR1(S4) P0PC(S4) GEC_(S4) UHC1(S4) UHC2(S4) USB3(S4) UHC4(S4) USB5(S4) UHC6(S4) UHC7(S4) XHC0(S4) XHC1(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD A6-3500 APU with Radeon(tm) HD Graphics, 2096.45 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,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 1MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu0: AMD erratum 721 detected and fixed cpu0: smt 0, core 0, packag
Re: Broken output from serial console
On 2013-08-23, Hugo Osvaldo Barrera wrote:
> On 2013-08-23 17:43, Stuart Henderson wrote:
>> On 2013-08-23, Hugo Osvaldo Barrera wrote:
>> > When I conect my PC to the server, I see BIOS and POST output properly,
>> > I then see the OpenBSD bootloader properly, and all the kernel messages
>> > come
>> > out fine (ie: the white-on-blue text), however, AFTER the kernel messages,
>> > I only see the following sixteen characters and nothing else (though
>> > later kernel messages like plugging in a USB are shown properly).
>> >
>> > In single user mode, this would be:
>> > "Enter pathname o"
>> >
>> > In non-single user mode, this would be
>> > "Automatic boot i"
>> >
>> > It's extremely odd. I'm cleary not having cable issues, wrong rates,
>> > or anything alike, because I'm seeing kernel output just fine.
>>
>> This is exactly what you would see if the IRQ assignment is wrong.
>> There are other possibilities too, but this is easy to check in the
>> BIOS, and is a somewhat likely problem.
>>
>> The first port (known as com0 in OpenBSD, com1 in MSDOS) should be at
>> 0x3f8 irq 4, the second should be 0x2f8 irq 3. Sometimes vendors
>> (I've seen it with Jetway) have been known to screw up and reverse
>> the irq assignments.
>
> Ah, thanks! I had checked that 0x3f8 was being used, but the irqs were
> mixed up (ie: they were swapped).
>
> Oddly I'm not seeing the first bit of the bootloader any more ("Using
> drive 0, partition 3..."), but I *am* seeing the important part which
> is the prompt for a boot commands.
>
> I'm curious though; why were kernel outputs being outputted
> properly? Shouldn't those have failed to display as well?
This may not be 100% correct but I think it's not far off (corrections
welcome): interrupts are off during the earlier printfs so the serial
port is driven in polling mode instead. When interrupts are enabled we
start sending a buffer full at once and wait for a completion interrupt,
which never comes (or at least never comes on the correct irq line).
When I first ran into this, I discovered what the problem was after
noticing that input on the *other* serial port made it start printing
more...
> > Some other OS take these from ISAPNP but OpenBSD hardcodes the
> > standard values for a PC-compatible machine and expects the port to
> > be there.
hmm, sorry, think-o: that should be s/ISAPNP/ACPI/...
> Why doesn't OpenBSD attempt to do this as well? Is there some reason to
> avoid that, or is it simply because nobody's gotten around to it?
Not really my area but my take on it is that it's overcomplicated, and
it's not going to be fully useful for the system console anyway because
we need to know at least the address of the uart well before acpi tables
are read.
Re: Broken output from serial console
On 2013-08-23 17:43, Stuart Henderson wrote:
> On 2013-08-23, Hugo Osvaldo Barrera wrote:
> > Hi!
> > I've started managing a serial server through a serial console, and have
> > come into some unusual issues.
> > I followed the instrucitons on faq 7.7, and also configured by BIOS
> > accordingly.
> >
> > When I conect my PC to the server, I see BIOS and POST output properly,
> > I then see the OpenBSD bootloader properly, and all the kernel messages
come
> > out fine (ie: the white-on-blue text), however, AFTER the kernel
messages,
> > I only see the following sixteen characters and nothing else (though
> > later kernel messages like plugging in a USB are shown properly).
> >
> > In single user mode, this would be:
> > "Enter pathname o"
> >
> > In non-single user mode, this would be
> > "Automatic boot i"
> >
> > It's extremely odd. I'm cleary not having cable issues, wrong rates,
> > or anything alike, because I'm seeing kernel output just fine.
>
> This is exactly what you would see if the IRQ assignment is wrong.
> There are other possibilities too, but this is easy to check in the
> BIOS, and is a somewhat likely problem.
>
> The first port (known as com0 in OpenBSD, com1 in MSDOS) should be at
> 0x3f8 irq 4, the second should be 0x2f8 irq 3. Sometimes vendors
> (I've seen it with Jetway) have been known to screw up and reverse
> the irq assignments.
Ah, thanks! I had checked that 0x3f8 was being used, but the irqs were
mixed up (ie: they were swapped).
Oddly I'm not seeing the first bit of the bootloader any more ("Using
drive 0, partition 3..."), but I *am* seeing the important part which
is the prompt for a boot commands.
I'm curious though; why were kernel outputs being outputted
properly? Shouldn't those have failed to display as well?
>
> Some other OS take these from ISAPNP but OpenBSD hardcodes the
> standard values for a PC-compatible machine and expects the port to
> be there.
Why doesn't OpenBSD attempt to do this as well? Is there some reason to
avoid that, or is it simply because nobody's gotten around to it?
>
> > com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> > com0: console
> > com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
>
The rebooting issue is now gone too. I had assumed they were related,
and they are.
Thanks,
--
Hugo Osvaldo Barrera
[demime 1.01d removed an attachment of type application/pgp-signature]
Re: mutt: clear your cache (time_t)
Alexander Polakov sdf.org> writes: > > I haven't seen this mentioned in current.html, so.. > If you're using mutt's caching options (set header_cache, > set message_cachedir), clear the cache before upgrading > to newer snapshot if you're not a fan of 1.4G core files > lying around. This will no longer be needed as of the mutt-1.5.21p4v0 packages.
Re: Broken output from serial console
On 2013-08-23, Hugo Osvaldo Barrera wrote: > Hi! > I've started managing a serial server through a serial console, and have > come into some unusual issues. > I followed the instrucitons on faq 7.7, and also configured by BIOS > accordingly. > > When I conect my PC to the server, I see BIOS and POST output properly, > I then see the OpenBSD bootloader properly, and all the kernel messages come > out fine (ie: the white-on-blue text), however, AFTER the kernel messages, > I only see the following sixteen characters and nothing else (though > later kernel messages like plugging in a USB are shown properly). > > In single user mode, this would be: > "Enter pathname o" > > In non-single user mode, this would be > "Automatic boot i" > > It's extremely odd. I'm cleary not having cable issues, wrong rates, > or anything alike, because I'm seeing kernel output just fine. This is exactly what you would see if the IRQ assignment is wrong. There are other possibilities too, but this is easy to check in the BIOS, and is a somewhat likely problem. The first port (known as com0 in OpenBSD, com1 in MSDOS) should be at 0x3f8 irq 4, the second should be 0x2f8 irq 3. Sometimes vendors (I've seen it with Jetway) have been known to screw up and reverse the irq assignments. Some other OS take these from ISAPNP but OpenBSD hardcodes the standard values for a PC-compatible machine and expects the port to be there. > com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo > com0: console > com1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
Re: mysql.sock location
On 2013-08-23, Guy Ferguson wrote: > liviu, > At last, I get your name right, if a little under-capitalised. Your > help was the first step in maybe a dozen or so that got the site back > up. So thank you kindly for that. Just some minor linking to outside > the chroot and it'll be perfect. If you have set paths in /etc/my.cnf, then you shouldn't need additional linking outside the chroot.
Re: EuroBSDCon 2013
On Thu, Aug 15, 2013 at 08:07:58PM +0400, Loganaden Velvindron wrote: > I would be great if someone could record the OpenBSD videos for > EuroBSDCon 2013 and post > them on youtube. > > I'm particularly interested in the Y2038: Going long long on time_t > to cope with 2,147,483,647+1 talk. > > No offence meant to the VM/VFS hackers out there :-) AFAIK, it will happen in an official manner, like for last years. Speakers have been asked if they're okay with it (to which I replied, sure as long as it's under a bsd-stye licence)
Re: relayd crash
Hello, Here are the results of relayd debug: Version: relayd --current OS: OpenBSD 5.3/amd64 pwd: /usr/src/usr.sbin/relayd $ sudo ./relayd $ ps aux|grep relay _relayd 10140 0.0 0.1 1180 2984 ?? S 11:37AM 0:00.01 relayd: relay (relayd) _relayd 32389 0.0 0.1 1184 2996 ?? S 11:37AM 0:00.01 relayd: relay (relayd) root 17108 0.0 0.1 1336 3252 ?? Ss 11:37AM 0:00.02 relayd: parent (relayd) _relayd 29445 0.0 0.1 1136 2744 ?? S 11:37AM 0:00.01 relayd: pfe (relayd) _relayd 10876 0.0 0.1 940 2496 ?? S 11:37AM 0:00.01 relayd: hce (relayd) andu 5868 0.0 0.0 228 124 p0 R+/0 11:37AM 0:00.00 grep relay PFE: $ sudo gdb ./relayd GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-unknown-openbsd5.3"... (gdb) (gdb) attach 29445 Attaching to program: /usr/src/usr.sbin/relayd-current/relayd, process 29445 Loaded symbols for /usr/src/usr.sbin/relayd-current/relayd Reading symbols from /usr/lib/libevent.so.3.1...done. Loaded symbols for /usr/lib/libevent.so.3.1 Reading symbols from /usr/lib/libssl.so.19.0...done. Loaded symbols for /usr/lib/libssl.so.19.0 Reading symbols from /usr/lib/libcrypto.so.22.0...done. Loaded symbols for /usr/lib/libcrypto.so.22.0 Reading symbols from /usr/lib/libutil.so.11.4...done. Loaded symbols for /usr/lib/libutil.so.11.4 Reading symbols from /usr/lib/libc.so.66.2...done. Loaded symbols for /usr/lib/libc.so.66.2 Reading symbols from /usr/libexec/ld.so...done. Loaded symbols for /usr/libexec/ld.so [Switching to thread 1029445] 0x05462804581a in kevent () at :2 2 : No such file or directory. in Current language: auto; currently asm (gdb) continue Continuing. Program exited normally. (gdb) The program is not being run. (gdb) HCE: $ sudo gdb ./relayd GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-unknown-openbsd5.3"... (gdb) attach 10876 Attaching to program: /usr/src/usr.sbin/relayd-current/relayd, process 10876 Loaded symbols for /usr/src/usr.sbin/relayd-current/relayd Reading symbols from /usr/lib/libevent.so.3.1...done. Loaded symbols for /usr/lib/libevent.so.3.1 Reading symbols from /usr/lib/libssl.so.19.0...done. Loaded symbols for /usr/lib/libssl.so.19.0 Reading symbols from /usr/lib/libcrypto.so.22.0...done. Loaded symbols for /usr/lib/libcrypto.so.22.0 Reading symbols from /usr/lib/libutil.so.11.4...done. Loaded symbols for /usr/lib/libutil.so.11.4 Reading symbols from /usr/lib/libc.so.66.2...done. Loaded symbols for /usr/lib/libc.so.66.2 Reading symbols from /usr/libexec/ld.so...done. Loaded symbols for /usr/libexec/ld.so [Switching to thread 1010876] 0x05462804581a in kevent () at :2 2 : No such file or directory. in Current language: auto; currently asm (gdb) (gdb) continue Continuing. Program exited normally. (gdb) The program is not being run. (gdb) The program is not being run. PARENT: $ sudo gdb ./relayd GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-unknown-openbsd5.3"... (gdb) (gdb) attach 17108 Attaching to program: /usr/src/usr.sbin/relayd-current/relayd, process 17108 Loaded symbols for /usr/src/usr.sbin/relayd-current/relayd Reading symbols from /usr/lib/libevent.so.3.1...done. Loaded symbols for /usr/lib/libevent.so.3.1 Reading symbols from /usr/lib/libssl.so.19.0...done. Loaded symbols for /usr/lib/libssl.so.19.0 Reading symbols from /usr/lib/libcrypto.so.22.0...done. Loaded symbols for /usr/lib/libcrypto.so.22.0 Reading symbols from /usr/lib/libutil.so.11.4...done. Loaded symbols for /usr/lib/libutil.so.11.4 Reading symbols from /usr/lib/libc.so.66.2...done. Loaded symbols for /usr/lib/libc.so.66.2 Reading symbols from /usr/libexec/ld.so...done. Loaded symbols for /usr/libexec/ld.so [Switching to thread 1017108] 0x05462804581a in kevent () at :2 2 : No such file or directory. in Current language: auto; currently asm (gdb) (gdb) continue Continuing. Program received signal SIGTERM, Terminated. 0x05462805feea in kill () at :2 2 : No such file or directory. in (gdb) Conti
Re: mysql.sock location
The instructions in /usr/local/share/doc/pkg-readmes/mysql-server-5.1.xx have always worked for me . . . very handy reference with specific instructions from ajacoutot@ on "Running mysql-server-5.1.xx on OpenBSD." Gilbert On Fri, Aug 23, 2013 at 4:34 AM, Guy Ferguson wrote: > liviu, > At last, I get your name right, if a little under-capitalised. Your help > was the first step in maybe a dozen or so that got the site back up. So > thank you kindly for that. Just some minor linking to outside the chroot > and it'll be perfect. > > But thanks for the help. > guy > > On 19/08/2013 02:54, Liviu Daia wrote: >> >> On 18 August 2013, Guy Ferguson wrote: >>> >>> Livia, >> >> If you want to address me by name, s/Livia/Liviu/ please. It might >> not be much, but it's my name, and I kind of became attached to it over >> the years. :) >> >>> Thanks for your help. >>> >>> I modded the /etc/my.cnf to add in the extra "/run" directory. >>> >>> A few other tweaks here and there and i can now get a test.php to >>> connect to the >>> default host mysql ($conn=mysql_connect...) >>> >>> So now i'm confident that mysql is working and connectable...I just >>> ahve to sort out why drupal is >>> unhappy, which no doubt is a chroot issue. >> >> [...] >> >> Like I said, the easy solution to that is to use TCP connections. >> As others have pointed out, just set hostname to 127.0.0.1 in your >> Drupal config, and you should be fine. >> >> If you insist on using UNIX sockets, you probably want to set >> >> socket = /var/www/run/mysql.sock >> >> in the /etc/my.cnf, then copy /etc/my.cnf to /var/www/etc/my.cnf, and >> set >> >> socket = /run/mysql.sock >> >> in the client section in /var/www/etc/my.cnf. There is no advantage in >> doing things like this though, you'd be just looking for future trouble. >> >> Regards, >> >> Liviu Daia >> >> >> >> - >> No virus found in this message. >> Checked by AVG - www.avg.com >> Version: 2013.0.3392 / Virus Database: 3211/6584 - Release Date: 08/16/13
Re: relayd crash
On 2013/08/23 04:03, Bogdan Andu wrote: > $ sudo gdb ./relayd > GNU gdb 6.3 > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and > you are > welcome to change it and/or distribute copies of it under certain > conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for > details. > This GDB was configured as "amd64-unknown-openbsd5.3"... > (gdb) attach 32389 > Attaching to program: /usr/src/usr.sbin/relayd-current/relayd, process > 32389 > Loaded symbols for /usr/src/usr.sbin/relayd-current/relayd > Reading symbols from /usr/lib/libevent.so.3.1...done. > Loaded symbols for /usr/lib/libevent.so.3.1 > Reading symbols from /usr/lib/libssl.so.19.0...done. > Loaded symbols for /usr/lib/libssl.so.19.0 > Reading symbols from /usr/lib/libcrypto.so.22.0...done. > Loaded symbols for /usr/lib/libcrypto.so.22.0 > Reading symbols from /usr/lib/libutil.so.11.4...done. > Loaded symbols for /usr/lib/libutil.so.11.4 > Reading symbols from /usr/lib/libc.so.66.2...done. > Loaded symbols for /usr/lib/libc.so.66.2 > Reading symbols from /usr/libexec/ld.so...done. > Loaded symbols for /usr/libexec/ld.so > [Switching to thread 1032389] > 0x05462804581a in kevent () at :2 > 2 : No such file or directory. > in > Current language: auto; currently asm > (gdb) continue > Continuing. > Program received signal SIGSEGV, Segmentation fault. A backtrace from this one would be helpful, that will hopefully show the chain of functions which called event_queue_insert().. > event_queue_insert (base=0x0, ev=0x54621afd208, queue=8) at /usr/src/ > lib/libevent/event.c:997 > 997 base->event_count++; > Current language: auto; currently c > (gdb) > Continuing. > But why this child crashes in /usr/src/lib/libevent/event.c, line 997 ? It is attempting to dereference a null pointer. > event_queue_insert (base=0x0, ev=0x54621afd208, queue=8) at > /usr/src/lib/libevent/event.c:997 > 997 base->event_count++; ^^
Re: mysql.sock location
liviu, At last, I get your name right, if a little under-capitalised. Your help was the first step in maybe a dozen or so that got the site back up. So thank you kindly for that. Just some minor linking to outside the chroot and it'll be perfect. But thanks for the help. guy On 19/08/2013 02:54, Liviu Daia wrote: On 18 August 2013, Guy Ferguson wrote: Livia, If you want to address me by name, s/Livia/Liviu/ please. It might not be much, but it's my name, and I kind of became attached to it over the years. :) Thanks for your help. I modded the /etc/my.cnf to add in the extra "/run" directory. A few other tweaks here and there and i can now get a test.php to connect to the default host mysql ($conn=mysql_connect...) So now i'm confident that mysql is working and connectable...I just ahve to sort out why drupal is unhappy, which no doubt is a chroot issue. [...] Like I said, the easy solution to that is to use TCP connections. As others have pointed out, just set hostname to 127.0.0.1 in your Drupal config, and you should be fine. If you insist on using UNIX sockets, you probably want to set socket = /var/www/run/mysql.sock in the /etc/my.cnf, then copy /etc/my.cnf to /var/www/etc/my.cnf, and set socket = /run/mysql.sock in the client section in /var/www/etc/my.cnf. There is no advantage in doing things like this though, you'd be just looking for future trouble. Regards, Liviu Daia - No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3392 / Virus Database: 3211/6584 - Release Date: 08/16/13
