support to view rc(8) startup skript output via dmesg -c
Hi,
something that has often bothered me, is that once you hook up a
console to a headless server, you've missed all the output.
This makes it harder to diagnose bugs in rc(8) startup skripts
from remote. Another thing i've missed is that fsck(8) output
will just scroll by and is usually lost.
Why not dump the initial output from /dev/console into
a share of the system message buffer and make it readable
via dmesg -c?
Things like the fixed 16k size and bumping the message buffer
on various platforms need still to be discussed, but how's the
idea in general?
Index: sbin/dmesg/dmesg.8
===
RCS file: /cvs/src/sbin/dmesg/dmesg.8,v
retrieving revision 1.14
diff -u -p -p -u -r1.14 dmesg.8
--- sbin/dmesg/dmesg.8 14 Aug 2013 06:32:35 - 1.14
+++ sbin/dmesg/dmesg.8 7 Dec 2014 12:47:40 -
@@ -38,6 +38,7 @@
.Nd display the system message buffer
.Sh SYNOPSIS
.Nm dmesg
+.Op Fl c
.Op Fl M Ar core
.Op Fl N Ar system
.Sh DESCRIPTION
@@ -57,6 +58,11 @@ Extract the name list from the specified
.Ar system
instead of the default
.Pa /bsd .
+.It Fl c
+Display the contents of the console message buffer instead.
+This can be used to review
+.Xr rc 8
+system startup messages.
.El
.Sh FILES
.Bl -tag -width /var/run/dmesg.boot -compact
Index: sbin/dmesg/dmesg.c
===
RCS file: /cvs/src/sbin/dmesg/dmesg.c,v
retrieving revision 1.23
diff -u -p -p -u -r1.23 dmesg.c
--- sbin/dmesg/dmesg.c 22 Apr 2014 20:43:12 - 1.23
+++ sbin/dmesg/dmesg.c 7 Dec 2014 12:47:40 -
@@ -66,11 +66,15 @@ main(int argc, char *argv[])
char *p;
struct msgbuf cur;
char *memf, *nlistf, *bufdata = NULL;
+ int readconsolemsgs = 0;
char buf[5];
memf = nlistf = NULL;
- while ((ch = getopt(argc, argv, M:N:)) != -1)
+ while ((ch = getopt(argc, argv, cM:N:)) != -1)
switch(ch) {
+ case 'c':
+ readconsolemsgs = 1;
+ break;
case 'M':
memf = optarg;
break;
@@ -89,7 +93,7 @@ main(int argc, char *argv[])
size_t len;
mib[0] = CTL_KERN;
- mib[1] = KERN_MSGBUFSIZE;
+ mib[1] = readconsolemsgs ? KERN_CMSGBUFSIZE : KERN_MSGBUFSIZE;
len = sizeof(msgbufsize);
if (sysctl(mib, 2, msgbufsize, len, NULL, 0))
err(1, sysctl: KERN_MSGBUFSIZE);
@@ -99,7 +103,7 @@ main(int argc, char *argv[])
if (bufdata == NULL)
errx(1, couldn't allocate space for buffer data);
- mib[1] = KERN_MSGBUF;
+ mib[1] = readconsolemsgs ? KERN_CMSGBUF : KERN_MSGBUF;
len = msgbufsize;
if (sysctl(mib, 2, bufdata, len, NULL, 0))
err(1, sysctl: KERN_MSGBUF);
@@ -179,6 +183,6 @@ usage(void)
{
extern char *__progname;
- fprintf(stderr, usage: %s [-M core] [-N system]\n, __progname);
+ fprintf(stderr, usage: %s [-c] [-M core] [-N system]\n, __progname);
exit(1);
}
Index: sys/kern/kern_sysctl.c
===
RCS file: /cvs/src/sys/kern/kern_sysctl.c,v
retrieving revision 1.274
diff -u -p -p -u -r1.274 kern_sysctl.c
--- sys/kern/kern_sysctl.c 5 Dec 2014 04:35:08 - 1.274
+++ sys/kern/kern_sysctl.c 7 Dec 2014 12:47:40 -
@@ -444,19 +444,27 @@ kern_sysctl(int *name, u_int namelen, vo
return (sysctl_rdint(oldp, oldlenp, newp, 0));
#endif
case KERN_MSGBUFSIZE:
+ case KERN_CMSGBUFSIZE: {
+ struct msgbuf *mp;
+ mp = (name[0] == KERN_MSGBUFSIZE) ? msgbufp : cmsgbufp;
/*
* deal with cases where the message buffer has
* become corrupted.
*/
- if (!msgbufp || msgbufp-msg_magic != MSG_MAGIC)
+ if (!mp || mp-msg_magic != MSG_MAGIC)
return (ENXIO);
- return (sysctl_rdint(oldp, oldlenp, newp, msgbufp-msg_bufs));
+ return (sysctl_rdint(oldp, oldlenp, newp, mp-msg_bufs));
+ }
case KERN_MSGBUF:
+ case KERN_CMSGBUF: {
+ struct msgbuf *mp;
+ mp = (name[0] == KERN_MSGBUF) ? msgbufp : cmsgbufp;
/* see note above */
- if (!msgbufp || msgbufp-msg_magic != MSG_MAGIC)
+ if (!mp || mp-msg_magic != MSG_MAGIC)
return (ENXIO);
- return (sysctl_rdstruct(oldp, oldlenp, newp, msgbufp,
- msgbufp-msg_bufs + offsetof(struct msgbuf, msg_bufc)));
+ return (sysctl_rdstruct(oldp, oldlenp, newp, mp,
+ mp-msg_bufs + offsetof(struct msgbuf, msg_bufc)));
+ }
case
Re: support to view rc(8) startup skript output via dmesg -c
On 2014-12-07 14:03, Marco Pfatschbacher wrote: Hi, something that has often bothered me, is that once you hook up a console to a headless server, you've missed all the output. This makes it harder to diagnose bugs in rc(8) startup skripts from remote. Another thing i've missed is that fsck(8) output will just scroll by and is usually lost. Why not dump the initial output from /dev/console into a share of the system message buffer and make it readable via dmesg -c? Things like the fixed 16k size and bumping the message buffer on various platforms need still to be discussed, but how's the idea in general? Index: sbin/dmesg/dmesg.8 === RCS file: /cvs/src/sbin/dmesg/dmesg.8,v retrieving revision 1.14 diff -u -p -p -u -r1.14 dmesg.8 --- sbin/dmesg/dmesg.814 Aug 2013 06:32:35 - 1.14 +++ sbin/dmesg/dmesg.87 Dec 2014 12:47:40 - @@ -38,6 +38,7 @@ .Nd display the system message buffer .Sh SYNOPSIS .Nm dmesg +.Op Fl c .Op Fl M Ar core .Op Fl N Ar system .Sh DESCRIPTION @@ -57,6 +58,11 @@ Extract the name list from the specified .Ar system instead of the default .Pa /bsd . +.It Fl c +Display the contents of the console message buffer instead. +This can be used to review +.Xr rc 8 +system startup messages. Hm, perhaps -c is not the best choice FreeBSD: Clear the kernel buffer after printing. SuSE:Clear the ring buffer contents after printing. RHEL:Clear the ring buffer contents after printing. NetBSD: - not used On FreeBSD there is a param '-a' for this. -a Show all data in the message buffer. This includes any syslog records and /dev/console output. -- olli
Re: patch: Support long lines in Plan B
Anyone?
On Sat, Nov 29, 2014 at 05:40:31PM +0100, Tobias Stoeckmann wrote:
Hi,
this diff doesn't just fix the division by zero for input files with
lines longer than 1023 chars in Plan B mode, it actually removes this
line limit!
Before:
$ dd if=/dev/zero bs=1 count=1024 | tr '\0' a a
$ dd if=/dev/zero bs=1 count=1024 | tr '\0' b b
$ diff -u a b a.diff
$ patch -x 8 a a.diff
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--
|--- a Sat Nov 29 17:34:15 2014
|+++ b Sat Nov 29 17:34:19 2014
--
Floating point exception (core dumped)
$_
After:
$ patch -x 8 a a.diff
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--
|--- a Sat Nov 29 17:34:15 2014
|+++ b Sat Nov 29 17:34:19 2014
--
Patching file a using Plan B...
Hunk #1 succeeded at 1.
done
With this diff, patch uses fgetln to read very long lines. One could argue
that this limits patch to the amount of RAM it has available -- but
that will happen anyway because at least twice as much memory as the
longest line has to be allocated. fgetln is therefore a good choice to
easily parse the file.
If you want to regress-test, you can supply -x 8 in PATCHOPTIONS to
enforce Plan B. Keep in mind that test5 will fail because this debug
option skips a check if the input file is available.
Tobias
Index: inp.c
===
RCS file: /cvs/src/usr.bin/patch/inp.c,v
retrieving revision 1.41
diff -u -p -u -p -r1.41 inp.c
--- inp.c 25 Nov 2014 10:22:08 - 1.41
+++ inp.c 29 Nov 2014 16:14:45 -
@@ -55,8 +55,9 @@ static char **i_ptr;/* pointers to line
static int tifd = -1; /* plan b virtual string array */
static char *tibuf[2]; /* plan b buffers */
static LINENUM tiline[2] = {-1, -1}; /* 1st line in each buffer */
-static LINENUM lines_per_buf; /* how many lines per buffer */
-static int tireclen; /* length of records in tmp file */
+static size_tlines_per_buf; /* how many lines per buffer */
+static size_ttibuflen; /* plan b buffer length */
+static size_ttireclen; /* length of records in tmp file */
static bool rev_in_string(const char *);
static bool reallocate_lines(size_t *);
@@ -333,8 +334,8 @@ static void
plan_b(const char *filename)
{
FILE*ifp;
- size_t i = 0, j, maxlen = 1;
- char*p;
+ size_t i = 0, j, len, maxlen = 1;
+ char*lbuf = NULL, *p;
boolfound_revision = (revision == NULL);
using_plan_a = false;
@@ -343,15 +344,28 @@ plan_b(const char *filename)
(void) unlink(TMPINNAME);
if ((tifd = open(TMPINNAME, O_EXCL | O_CREAT | O_WRONLY, 0666)) 0)
pfatal(can't open file %s, TMPINNAME);
- while (fgets(buf, sizeof buf, ifp) != NULL) {
- if (revision != NULL !found_revision rev_in_string(buf))
+ while ((p = fgetln(ifp, len)) != NULL) {
+ if (p[len - 1] == '\n')
+ p[len - 1] = '\0';
+ else {
+ /* EOF without EOL, copy and add the NUL */
+ if ((lbuf = malloc(len + 1)) == NULL)
+ fatal(out of memory\n);
+ memcpy(lbuf, p, len);
+ lbuf[len] = '\0';
+ p = lbuf;
+
+ last_line_missing_eol = true;
+ len++;
+ }
+ if (revision != NULL !found_revision rev_in_string(p))
found_revision = true;
- if ((i = strlen(buf)) maxlen)
- maxlen = i; /* find longest line */
+ if (len maxlen)
+ maxlen = len; /* find longest line */
}
- last_line_missing_eol = i 0 buf[i - 1] != '\n';
- if (last_line_missing_eol maxlen == i)
- maxlen++;
+ free(lbuf);
+ if (ferror(ifp))
+ pfatal(can't read file %s, filename);
if (revision != NULL) {
if (!found_revision) {
@@ -376,23 +390,26 @@ plan_b(const char *filename)
revision);
}
fseek(ifp, 0L, SEEK_SET); /* rewind file */
- lines_per_buf = BUFFERSIZE / maxlen;
tireclen = maxlen;
- tibuf[0] = malloc(BUFFERSIZE + 1);
+ tibuflen = maxlen BUFFERSIZE ? maxlen : BUFFERSIZE;
+ lines_per_buf = tibuflen / maxlen;
+ tibuf[0] = malloc(tibuflen + 1);
if (tibuf[0] == NULL)
fatal(out of memory\n);
- tibuf[1] = malloc(BUFFERSIZE + 1);
+ tibuf[1] = malloc(tibuflen + 1);
if (tibuf[1] == NULL)
fatal(out of memory\n);
for (i = 1;; i++) {
p = tibuf[0] + maxlen * (i % lines_per_buf);
Re: assert(3) manpage tweaks
On Sun, Dec 07, 2014 at 02:33:29AM +0100, Ingo Schwarze wrote: By the way, i just grepped v6 for assert and came up empty-handed. Anybody knows whether the statement is even correct? Didn't it rather first appear in v7? If we can rely on the files that we get from tuhs, yes - it's not in v6, I couldn't find any trace of it either. And it's definately present in v7.
Re: stdarg(3) manpage tweaks
Hi Kaspars, Kaspars Bankovskis wrote on Sat, Dec 06, 2014 at 11:00:35PM +0200: I'm proposing the following changes to stdarg(3). Moved description of return values to its own section + macro cleanup. Committed, thanks. Ingo Index: stdarg.3 === RCS file: /cvs/src/share/man/man3/stdarg.3,v retrieving revision 1.18 diff -u -p -r1.18 stdarg.3 --- stdarg.3 30 Nov 2014 21:21:59 - 1.18 +++ stdarg.3 6 Dec 2014 20:43:31 - @@ -57,15 +57,15 @@ A function may be called with a varying number of arguments of varying types. The include file -.Aq Pa stdarg.h +.In stdarg.h declares a type -.Pq Li va_list +.Vt va_list and defines three macros for stepping through a list of arguments whose number and types are not known to the called function. .Pp The called function must declare an object of type -.Li va_list +.Vt va_list which is used by the macros .Fn va_start , .Fn va_arg , @@ -95,17 +95,13 @@ macro, it should not be declared as a re function, nor an array type. .Pp The -.Fn va_start -macro returns no value. -.Pp -The .Fn va_arg macro expands to an expression that has the type and value of the next argument in the call. The parameter .Fa ap is the -.Li va_list Fa ap +.Va va_list ap initialized by .Fn va_start . Each call to @@ -134,33 +130,24 @@ promoted type should be used as the argu The following describes which types should be promoted (and to what): .Bl -dash -compact .It -.Va short +.Vt short is promoted to -.Va int +.Vt int .It -.Va float +.Vt float is promoted to -.Va double +.Vt double .It -.Va char +.Vt char is promoted to -.Va int +.Vt int .El .Pp The same rules apply to unsigned versions of the above types, as well as their bit-type equivalents (e.g.\ -.Dv int8_t +.Vt int8_t and -.Dv int16_t ) . -.Pp -The first use of the -.Fn va_arg -macro after that of the -.Fn va_start -macro returns the argument after -.Fa last . -Successive invocations return the values of the remaining -arguments. +.Vt int16_t ) . .Pp The .Fn va_copy @@ -176,20 +163,28 @@ macro as had previously been used to rea .Fa src . .Pp The -.Fn va_copy -macro returns no value. -.Pp -The .Fn va_end macro handles a normal return from the function whose variable argument list was initialized by .Fn va_start or .Fn va_copy . +.Sh RETURN VALUES +The first use of the +.Fn va_arg +macro after that of the +.Fn va_start +macro returns the argument after +.Fa last . +Successive invocations return the values of the remaining +arguments. .Pp The +.Fn va_start , +.Fn va_copy +and .Fn va_end -macro returns no value. +macros return no value. .Sh EXAMPLES The function .Fn foo @@ -232,7 +227,7 @@ These macros are compatible with the historic macros they replace. A backward compatible version can be found in the include file -.Aq Pa varargs.h . +.In varargs.h . .Pp The .Fn va_start , @@ -248,7 +243,7 @@ The and .Fn va_end macros were introduced in -.St -ansiC-89 . +.St -ansiC . The .Fn va_copy macro was introduced in @@ -267,7 +262,7 @@ code to code, but it also creates difficulties for variadic functions that wish to pass all of their arguments on to a function -that takes a -.Li va_list -argument, such as +that takes an argument of type +.Vt va_list , +such as .Xr vfprintf 3 .
gomoku debug regression
Hi, I noticed revision 1.25 of games/gomoku/main.c was faulty: if (!debug) -#ifdef SVR4 - srand(time(0)); -#endif if (interactive) cursinit(); /* initialize curses */ The if (!debug) line should've been removed as well. Now curses isn't initialized in debug mode. Jonas
Re: current smtpd: auth failed when username = 31 chars, Syntax error when username 31
ping On Wed, Dec 3, 2014 at 9:10 AM, Abel Abraham Camarillo Ojeda acam...@verlet.org wrote: Hi Gilles, On Wed, Dec 3, 2014 at 8:27 AM, Gilles Chehade gil...@poolp.org wrote: Nope it shouldn't because: listen on egress tls pki test.verlet.org auth This will authenticate users against the system and will use the username you provide in the SMTP session as the login to search credentials for. Therefore, when you configure your MUA to send an email address as the username: longemailabcde@abcdef.ghijklmno , the user lookup on the system fails which causes your auth to fail. Yes, in my case where I found this we use auth creds to use an external credential table: pki test.verlet.org certificate /etc/ssl/localhost.pem pki test.verlet.org key /etc/ssl/private/localhost.key table cred file:/etc/mail/tbl/cred listen on egress tls pki test.verlet.org auth cred reject in /etc/mail/tbl/cred (password: example): correo-voz-010@abcdef.ghijklmno $2a$06$qHGSfIa9aAgzjWqO1t.ffOhaR9XG1MNI/tQ0jLKB6uxP5.lMfQtZe correo-voz-010@abcdef.ghijklmnop $2a$06$qHGSfIa9aAgzjWqO1t.ffOhaR9XG1MNI/tQ0jLKB6uxP5.lMfQtZe The user does exist on the auth table. Authenticating the first user works: -- AUTH PLAIN AGNvcnJlby12b3otMDEwQGFiY2RlZi5naGlqa2xtbm8AZXhhbXBsZQ== -- 235 2.0.0: Authentication succeeded but the second fails: -- AUTH PLAIN AGNvcnJlby12b3otMDEwQGFiY2RlZi5naGlqa2xtbm9wAGV4YW1wbGU= -- 501 5.5.2 Syntax error: Syntax error Are usernames on auth tables with length larger than 31 chars allowed? (this usernames do work on our current mail systems) if they are not allowed, shouldn't smtpd complain when loading such table? As for the Syntax Error on large usernames, I'll think of a better way to phrase it, this is the default Enhanced Status Code message for this kind of errors, we should probably override with a more descriptive error. I'm ok with the syntax error message, but should large usernames work? Thank you very much. On Mon, Dec 01, 2014 at 08:49:36PM -0600, Abel Abraham Camarillo Ojeda wrote: Any ideas, should this work? On Mon, Dec 1, 2014 at 5:39 AM, Abel Abraham Camarillo Ojeda acam...@verlet.org wrote: Hi Found on OpenBSD/5.5, reproduced in OpenBSD-current: I have a problem when authenticating a user whose username is bigger than 31 chars: expected - auth longemailabcde@abcdef.ghijklmno: smtp-in: Authentication failed for user longemailabcde@abcdef.ghijklmno on session 9b03fc72ca051521 got - auth longemailabcde@abcdef.ghijklmnop: smtp-in: Failed command on session fd98324226959da6: AUTH [...] = 501 5.5.2 Syntax error: Syntax error expected: # smtpd -dv debug: init ssl-tree info: loading pki information for test.verlet.org info: OpenSMTPD 5.4.3 starting debug: bounce warning after 4h debug: using fs queue backend debug: using ramqueue scheduler backend debug: using ram stat backend info: startup [debug mode] debug: parent_send_config_ruleset: reloading debug: parent_send_config: configuring pony process debug: parent_send_config: configuring ca process debug: queue: done loading queue into scheduler debug: init ssl-tree info: loading pki keys for test.verlet.org debug: ca_engine_init: using RSAX engine support debug: smtp: listen on 172.16.0.2 port 25 flags 0x449 pki test.verlet.org debug: smtp: listen on 127.0.0.1 port 25 flags 0x400 pki debug: smtp: listen on IPv6:fe80::1%lo0 port 25 flags 0x400 pki debug: smtp: listen on IPv6:::1 port 25 flags 0x400 pki debug: pony: rsae_init debug: pony: rsae_init debug: init private ssl-tree debug: smtp: will accept at most 500 clients debug: smtpd: scanning offline queue... debug: smtpd: offline scanning done debug: smtp: new client on listener: 0x1659acf84000 smtp: 0x1658f9739000: STATE_NEW - STATE_CONNECTED smtp-in: New session 9b03fc72ca051521 from host maetel.00z [172.16.0.2] smtp: 0x1658f9739000: 220 maetel.00z ESMTP OpenSMTPD smtp: 0x1658f9739000: EHLO localhost smtp: 0x1658f9739000: STATE_CONNECTED - STATE_HELO smtp: 0x1658f9739000: 250-maetel.00z Hello localhost [172.16.0.2], pleased to meet you smtp: 0x1658f9739000: 250-8BITMIME smtp: 0x1658f9739000: 250-ENHANCEDSTATUSCODES smtp: 0x1658f9739000: 250-SIZE 36700160 smtp: 0x1658f9739000: 250-DSN smtp: 0x1658f9739000: 250-STARTTLS smtp: 0x1658f9739000: 250 HELP smtp: 0x1658f9739000: STARTTLS smtp: 0x1658f9739000: 220 2.0.0: Ready to start TLS smtp: 0x1658f9739000: STATE_HELO - STATE_TLS debug: lka: looking up pki test.verlet.org debug: session_start_ssl: switching to SSL debug: pony: rsae_priv_enc smtp-in: Started TLS on session 9b03fc72ca051521: version=TLSv1/SSLv3, cipher=ECDHE-RSA-CHACHA20-POLY1305, bits=256 smtp: 0x1658f9739000: STATE_TLS - STATE_HELO smtp: 0x1658f9739000: EHLO localhost smtp: 0x1658f9739000: STATE_HELO - STATE_HELO smtp: 0x1658f9739000: 250-maetel.00z Hello localhost [172.16.0.2],
Re: gomoku debug regression
I just realized SVR4 wasn't defined in the first place, so this isn't a regression. It was always broken.
small acpiac(4) update
This is a small documentation update for acpiac(4). The implmentation no longer seems to poll every 10 seconds, so I've removed it from the manpage. Index: share/man/man4/acpiac.4 === RCS file: /cvs/src/share/man/man4/acpiac.4,v retrieving revision 1.6 diff -u -p -r1.6 acpiac.4 --- share/man/man4/acpiac.4 16 Jul 2013 16:05:48 - 1.6 +++ share/man/man4/acpiac.4 8 Dec 2014 06:28:20 - @@ -28,9 +28,9 @@ The driver supports ACPI AC Adapters. Information about AC power source status (connected or disconnected) is available through this driver as a sensor. -AC power source status is updated every 10 seconds or, -if the implementation supports it, -via an event when a change happens. +AC power source status is updated +via an event when a change happens, +if the implementation supports it. The sensors provided by .Nm can be monitored using
