two issues with the new ASR code in libc
Hi, I recently upgraded two servers at work from OpenBSD 5.2 to 5.4 and got problems on both of the machines that are related to the new asynchronous resolver in libc. 1. this machnie is SMTP server for a subpart of our domains, running sendmail. It receives the mail from the outside (and runs spamd) and delivers the messages to internal mail box servers, according to the alias map which has entries in the form joe: joe@servera This setup has worked perfectly for years under various OSs and also worked under 5.2. Under 5.4 I get errors like this one from sendmail: Jan 13 13:00:02 smtp sm-mta[12261]: s0DC02FV014174: to=joe@servera, delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=32928, relay=servera, dsn=5.1.2, stat=Host unknown (Name server: servera: host not found) And looking at DNS requests I see that sendmail is only emitting MX queries for 'servera' and 'servera.mydomain.fr' but no or A queries. 2. the second issue is with the dhcpd server. We assign static IPv4 addresses to about 2000 machines based on their MAC address. For historical reasons the dhcpd.conf file has host names, not IP addresses, so dhcpd has to resolve all names before starting. Again in 5.2 this was working. (dhcpd startup is a bit slow but that's ok). Now in 5.4 in only starts once over 2 or 3 attempts, and the other cases fail because it randomly can't resolve one of the names. Jan 13 15:39:35 dhcp dhcpd[9242]: /etc/dhcpd.conf line 4553: fr (265): could not resolve hostname Jan 13 15:39:35 dhcp dhcpd[9242]: fixed-address foo.mydomain.fr; Jan 13 15:51:19 nairobi dhcpd[15375]: ^ Jan 13 15:51:26 nairobi dhcpd[15375]: Configuration file errors encountered Jan 13 15:51:26 nairobi dhcpd[15375]: exiting. I guess a timeout in the new ASR code is shorter than in the old code or something, causing those random failures. I know I can fix both issues by changing the way things are handled, but in both cases what I do is legal (even if not optimal) and I'd rather see those issues fixed in OpenBSD. I'm willing to test patches... -- Matthieu Herrb
top(1) interactive commands after SIGWINCH
If anyone is interested in looking at a signal problem in top, here's a small but annoying bug.. - run top in an xterm - resize the window - try to use an interactive command that takes an argument, e.g. s or g (doesn't happen with commands like S or H that work immediately) Often, pressing the command key just refreshes the screen, it takes multiple attempts for the command to take effect (sometimes just a couple, sometimes loads of attempts).
Re: top(1) interactive commands after SIGWINCH
On Mon, Jan 13, 2014 at 05:04:28PM +, Stuart Henderson wrote:
If anyone is interested in looking at a signal problem in top,
here's a small but annoying bug..
- run top in an xterm
- resize the window
- try to use an interactive command that takes an argument, e.g. s
or g (doesn't happen with commands like S or H that work immediately)
Often, pressing the command key just refreshes the screen, it takes
multiple attempts for the command to take effect (sometimes just a
couple, sometimes loads of attempts).
[...]
The patch below seems to fix that for me. resizeterm() does a
putchar(KEY_RESIZE), part of which then gets interpreted as a command parameter
in rundisplay().
I'm not too sure on the cast to char, but since isascii() makes sure the
value passed is below 0177, i figured that would be okay.
--
Gregor Best
--- top.c.old Mon Jan 13 20:49:28 2014
+++ top.c Mon Jan 13 20:49:11 2014
@@ -39,6 +39,7 @@
#include stdlib.h
#include limits.h
#include unistd.h
+#include ctype.h
/* includes specific to top */
#include display.h /* interface to display package */
@@ -548,7 +549,7 @@
static char tempbuf[TEMPBUFSIZE];
sigset_t mask;
char ch, *iptr;
- int change, i;
+ int change, i, cch;
struct pollfd pfd[1];
uid_t uid, huid;
static char command_chars[] = \f qh?en#sdkriIuSopCHg+P1;
@@ -612,14 +613,12 @@
* now read it and convert to
* command strchr
*/
- while (1) {
- len = read(STDIN_FILENO, ch, 1);
- if (len == -1 errno == EINTR)
- continue;
- if (len == 0)
- exit(1);
- break;
- }
+ cch = getch();
+ /* If the terminal is resized, curses does putchar(KEY_RESIZE)
*/
+ if (!isascii(cch))
+ return 0;
+ ch = (char) cch;
+
if ((iptr = strchr(command_chars, ch)) == NULL) {
/* illegal command */
new_message(MT_standout, Command not understood);
Re: top(1) interactive commands after SIGWINCH
On 13/01/14 12:04 PM, Stuart Henderson wrote: If anyone is interested in looking at a signal problem in top, here's a small but annoying bug.. - run top in an xterm - resize the window - try to use an interactive command that takes an argument, e.g. s or g (doesn't happen with commands like S or H that work immediately) Often, pressing the command key just refreshes the screen, it takes multiple attempts for the command to take effect (sometimes just a couple, sometimes loads of attempts). This happens whether you resize the window or not. Seemingly the longer top is running the longer I have to hold down the key to have top respond. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Add spi-inc.org CA root?
Any comments on adding this to cert.pem? It is for SPI, non-profit org which was originally created as a 501c(3) for Debian, this cert is used to sign keys for alioth.debian.org which affects as it's a site hosting distfiles for various ports, it's also used to sign certificates for OFTC.net IRC servers. http://en.wikipedia.org/wiki/Software_in_the_Public_Interest OK? Index: cert.pem === RCS file: /cvs/src/lib/libssl/cert.pem,v retrieving revision 1.22 diff -u -p -r1.22 cert.pem --- cert.pem3 Dec 2012 10:19:09 - 1.22 +++ cert.pem13 Jan 2014 20:17:40 - @@ -5032,3 +5032,154 @@ rfafnoOTHh1CuEava2bwm3/q4wMC5QJRwarVNZ1y eOZTT7Hot9MUnpOmw2TjrH5xzbyf6QMbzPvprDHBr3wVdAKZw7JHpsIyYdfHb0gk USeh1YdV8nuPmD0Wnu51tvjQjvLzxq4oW6fw8zYX/MMF08oDSlQ= -END CERTIFICATE- +Certificate: +Data: +Version: 3 (0x2) +Serial Number: 16757532242060383272 (0xe88eb6c9f82a1428) +Signature Algorithm: sha1WithRSAEncryption +Issuer: C=US, ST=Indiana, L=Indianapolis, O=Software in the Public Interest, OU=hostmaster, CN=Certificate Authority/emailAddress=hostmas...@spi-inc.org +Validity +Not Before: May 13 08:07:56 2008 GMT +Not After : May 11 08:07:56 2018 GMT +Subject: C=US, ST=Indiana, L=Indianapolis, O=Software in the Public Interest, OU=hostmaster, CN=Certificate Authority/emailAddress=hostmas...@spi-inc.org +Subject Public Key Info: +Public Key Algorithm: rsaEncryption +Public-Key: (4096 bit) +Modulus: +00:dc:36:e6:47:42:c2:c4:51:75:29:87:40:c3:d8: +8e:21:06:d2:18:4e:eb:ef:20:bd:90:3c:85:10:13: +8c:29:5b:94:63:f6:f4:2d:f1:06:42:91:b9:19:c4: +42:69:08:bf:8b:36:45:ea:28:05:33:49:48:a0:27: +43:93:35:8a:41:d8:78:b3:f0:ef:b3:6e:2d:dd:d1: +cb:7d:ea:f4:75:26:d3:3e:90:3a:ee:d7:e7:2c:04: +b5:7c:e1:f5:7c:c5:4e:ef:77:bd:5c:a2:93:33:92: +ce:7d:81:48:cf:6b:b5:22:2c:08:83:fd:d3:d5:cf: +3b:2d:fd:b5:49:90:5b:f6:ad:4d:13:ca:de:d3:a6: +9d:53:51:71:63:46:f8:4a:16:5c:98:ee:2d:6d:9a: +16:a1:76:90:e2:60:43:99:d6:89:d6:6c:2e:7a:98: +b2:0b:03:2c:e3:7a:4f:c7:dd:e3:cc:e3:4a:6a:8d: +79:52:fa:f4:c1:af:2e:8f:2a:08:cb:1b:29:82:92: +72:43:bc:ce:88:a9:aa:a7:8a:51:43:55:85:9a:37: +03:78:93:c8:f0:bd:b4:41:c8:07:42:9a:cb:35:97: +7a:8a:81:65:de:1d:54:08:01:f1:64:5c:b7:17:1a: +51:bc:1e:c3:59:87:76:18:16:98:ee:bf:f6:67:81: +8b:06:35:c5:4b:6d:59:19:c7:d2:c6:48:be:6e:14: +28:83:4a:10:9c:1b:f5:6f:bc:a9:8e:f5:69:fe:b2: +c1:55:cc:e7:14:c9:f9:5b:14:53:51:07:ea:ce:3d: +e4:4f:28:1f:3c:61:09:d7:33:d2:6e:a7:6e:d4:c7: +13:09:6f:6b:5d:14:ee:9d:89:1b:a5:6a:f2:f6:f8: +d0:72:8e:ea:72:1f:2f:34:6a:29:0a:c5:0a:ec:1c: +40:85:12:f7:a6:a5:d3:4f:ad:c0:85:8c:4c:7c:73: +20:cc:53:18:f1:b2:58:4c:01:f5:bf:ea:64:d5:5c: +39:c5:ce:6c:cc:53:5a:56:ba:41:0f:25:df:6b:50: +b6:c7:8a:a0:bd:02:c2:c5:3b:55:a5:b2:64:22:84: +51:28:56:ae:31:ee:5e:fb:0b:16:4d:46:05:91:80: +44:ed:ac:6d:f0:57:a8:fa:eb:61:48:a0:cb:1b:b3: +1f:8e:cd:c5:21:77:03:84:1e:fc:ac:a3:43:08:63: +8c:ed:f9:27:ef:b4:b0:5d:67:d6:4f:ed:d0:8b:3e: +5d:5b:c9:91:bd:96:02:84:3d:c5:4d:bc:42:3f:74: +fd:3c:5d:ac:5c:48:36:5e:87:31:2f:18:6c:c4:68: +ee:a1:8b:c9:59:d0:18:e3:00:80:b3:54:27:2e:99: +f0:15:53 +Exponent: 65537 (0x10001) +X509v3 extensions: +X509v3 Subject Key Identifier: +34:71:D1:38:D7:15:36:83:47:6B:D7:37:64:42:3B:8E:8D:52:9D:AB +X509v3 Authority Key Identifier: + keyid:34:71:D1:38:D7:15:36:83:47:6B:D7:37:64:42:3B:8E:8D:52:9D:AB +DirName:/C=US/ST=Indiana/L=Indianapolis/O=Software in the Public Interest/OU=hostmaster/CN=Certificate Authority/emailAddress=hostmas...@spi-inc.org +serial:E8:8E:B6:C9:F8:2A:14:28 + +X509v3 Basic Constraints: critical +CA:TRUE +Netscape Cert Type: +SSL CA, S/MIME CA, Object Signing CA +X509v3 Issuer Alternative Name: +EMPTY + +Netscape Comment: +Software in the Public Interest +Netscape CA Revocation Url: +https://ca.spi-inc.org/ca-crl.pem +Netscape Revocation Url: +https://ca.spi-inc.org/cert-crl.pem +X509v3 Subject
Re: top(1) interactive commands after SIGWINCH
On Mon, 13 Jan 2014, Gregor Best wrote:
On Mon, Jan 13, 2014 at 05:04:28PM +, Stuart Henderson wrote:
If anyone is interested in looking at a signal problem in top,
here's a small but annoying bug..
- run top in an xterm
- resize the window
- try to use an interactive command that takes an argument, e.g. s
or g (doesn't happen with commands like S or H that work immediately)
Often, pressing the command key just refreshes the screen, it takes
multiple attempts for the command to take effect (sometimes just a
couple, sometimes loads of attempts).
[...]
The patch below seems to fix that for me. resizeterm() does a
putchar(KEY_RESIZE), part of which then gets interpreted as a command
parameter in rundisplay().
I think you meant ungetch(KEY_RESIZE), but that pointed me at the
getnstr() manpage, which notes that it returns KEY_RESIZE if there was a
pending resize event. Changing readline() to loop on getnstr() while it
returns that, resetting the cursor position each time, seems to fix the
problem in my testing.
Philip Guenther
Index: display.c
===
RCS file: /cvs/src/usr.bin/top/display.c,v
retrieving revision 1.46
diff -u -p -r1.46 display.c
--- display.c 28 Nov 2013 18:24:55 - 1.46
+++ display.c 13 Jan 2014 20:37:38 -
@@ -641,9 +641,12 @@ readline(char *buffer, int size)
/* allow room for null terminator */
size -= 1;
- if (smart_terminal)
- getnstr(buffer, size);
- else
+ if (smart_terminal) {
+ int y, x;
+ getyx(stdscr, y, x);
+ while (getnstr(buffer, size) == KEY_RESIZE)
+ move(y, x);
+ } else
return readlinedumb(buffer, size);
cnt = strlen(buffer);
Re: top(1) interactive commands after SIGWINCH
On Mon, Jan 13, 2014 at 12:41:19PM -0800, Philip Guenther wrote: [...] I think you meant ungetch(KEY_RESIZE), [...] You're right. [...] seems to fix the problem in my testing. [...] Works for me too. -- Gregor Best
Re: top(1) interactive commands after SIGWINCH
On 2014/01/13 12:41, Philip Guenther wrote:
On Mon, 13 Jan 2014, Gregor Best wrote:
The patch below seems to fix that for me. resizeterm() does a
putchar(KEY_RESIZE), part of which then gets interpreted as a command
parameter in rundisplay().
I think you meant ungetch(KEY_RESIZE), but that pointed me at the
getnstr() manpage, which notes that it returns KEY_RESIZE if there was a
pending resize event. Changing readline() to loop on getnstr() while it
returns that, resetting the cursor position each time, seems to fix the
problem in my testing.
Thanks, both diffs fix things for me, but this one is clearer and more
precise - OK.
Philip Guenther
Index: display.c
===
RCS file: /cvs/src/usr.bin/top/display.c,v
retrieving revision 1.46
diff -u -p -r1.46 display.c
--- display.c 28 Nov 2013 18:24:55 - 1.46
+++ display.c 13 Jan 2014 20:37:38 -
@@ -641,9 +641,12 @@ readline(char *buffer, int size)
/* allow room for null terminator */
size -= 1;
- if (smart_terminal)
- getnstr(buffer, size);
- else
+ if (smart_terminal) {
+ int y, x;
+ getyx(stdscr, y, x);
+ while (getnstr(buffer, size) == KEY_RESIZE)
+ move(y, x);
+ } else
return readlinedumb(buffer, size);
cnt = strlen(buffer);
Re: two issues with the new ASR code in libc
On Mon, Jan 13, 2014 at 05:03:53PM +0100, Matthieu Herrb wrote: Hi, I recently upgraded two servers at work from OpenBSD 5.2 to 5.4 and got problems on both of the machines that are related to the new asynchronous resolver in libc. 1. this machnie is SMTP server for a subpart of our domains, running sendmail. It receives the mail from the outside (and runs spamd) and delivers the messages to internal mail box servers, according to the alias map which has entries in the form joe: joe@servera This setup has worked perfectly for years under various OSs and also worked under 5.2. Under 5.4 I get errors like this one from sendmail: Jan 13 13:00:02 smtp sm-mta[12261]: s0DC02FV014174: to=joe@servera, delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=32928, relay=servera, dsn=5.1.2, stat=Host unknown (Name server: servera: host not found) And looking at DNS requests I see that sendmail is only emitting MX queries for 'servera' and 'servera.mydomain.fr' but no or A queries. One data point: reverting libc to the 5.3 resolver code makes my setup work again. So this confirms that the new asr code is responsible for the behaviour change. OTOH, tracing what's happening in sendmail is a pain. So I've not yet been able to explain why it's behaving this way. -- Matthieu Herrb
Re: Add spi-inc.org CA root?
On 2014/01/13 20:24, Stuart Henderson wrote: Any comments on adding this to cert.pem? It is for SPI, non-profit org which was originally created as a 501c(3) for Debian, this cert is used to sign keys for alioth.debian.org which affects as it's a site hosting distfiles for various ports, it's also used to sign certificates for OFTC.net IRC servers. Another way we could handle this for ports distfiles, is to change ports infrastructure to allow a port to provide its own cafile and pick that up and pass to ftp -S cafile=... (overriding /etc/ssl/cert.pem) if present..
