ntpd setting date incorrectly
Not sure what has changed in the last couple of days but apparently I need to get back from the future. This is an OpenBSD VM running under VMWare Fusion Professional Version 8.0.2 (3164312) Mac OS X 10.11.2 Dec 14 17:22:44 ianm-openbsd ntpd[13773]: peer 121.0.0.41 now valid Dec 14 17:22:46 ianm-openbsd ntpd[13773]: peer 192.189.54.17 now valid Dec 14 17:22:49 ianm-openbsd ntpd[13773]: peer 54.252.165.245 now valid Dec 14 17:22:49 ianm-openbsd ntpd[13773]: peer 54.252.129.186 now valid Dec 14 17:23:44 ianm-openbsd ntpd[19417]: adjusting local clock by 45.252476s Machine shutdown Machine rebooted next day Dec 15 09:26:00 ianm-openbsd ntpd[1991]: ntp engine ready time correct until Nov 27 07:52:36 ianm-openbsd ntpd[21778]: set local clock to Sun Nov 27 07:52:36 AEDT 2061 (offset 1450131996.187864s) Nov 27 07:52:36 ianm-openbsd savecore: no core dump Nov 27 07:52:37 ianm-openbsd apmd: battery status: absent. external power status: connected. estimated battery life 0% Nov 27 07:53:56 ianm-openbsd ntpd[11805]: adjusting local clock by -1450131950.806132s Nov 27 07:55:26 ianm-openbsd ntpd[11805]: adjusting local clock by -1450131950.410569s Nov 27 07:56:56 ianm-openbsd ntpd[11805]: adjusting local clock by -1450131949.960758s Nov 27 07:58:26 ianm-openbsd ntpd[11805]: adjusting local clock by -1450131949.511029s Nov 27 07:59:56 ianm-openbsd ntpd[11805]: adjusting local clock by -1450131949.061268s Nov 27 08:01:26 ianm-openbsd ntpd[11805]: adjusting local clock by -1450131948.611426s Nov 27 08:02:56 ianm-openbsd ntpd[11805]: adjusting local clock by -1450131948.161660s Nov 27 08:04:26 ianm-openbsd ntpd[11805]: adjusting local clock by -1450131947.711849s Nov 27 08:05:56 ianm-openbsd ntpd[11805]: adjusting local clock by -1450131947.262024s Nov 27 08:07:26 ianm-openbsd ntpd[11805]: adjusting local clock by -1450131946.812191s Nov 27 08:07:32 ianm-openbsd dhclient[21622]: DHCPDISCOVER on em0 - interval 1 Nov 27 08:07:33 ianm-openbsd dhclient[21622]: DHCPDISCOVER on em0 - interval 1 Nov 27 08:07:33 ianm-openbsd dhclient[21622]: DHCPOFFER from 172.16.28.254 (00:50:56:f1:c4:f7) Nov 27 08:07:33 ianm-openbsd dhclient[21622]: DHCPREQUEST on em0 to 255.255.255.255 Nov 27 08:07:33 ianm-openbsd dhclient[21622]: DHCPACK from 172.16.28.254 (00:50:56:f1:c4:f7) Nov 27 08:07:33 ianm-openbsd dhclient[21622]: bound to 172.16.28.141 -- renewal in 900 seconds. Nov 27 08:08:56 ianm-openbsd ntpd[11805]: adjusting local clock by -1450131946.362273s manually setting the date/time shows that things appear fine until next reboot. Nov 27 08:57:27 ianm-openbsd ntpd[11805]: adjusting local clock by -1450131932.766352s Nov 27 08:58:57 ianm-openbsd ntpd[11805]: adjusting local clock by -1450131932.316650s Dec 15 10:34:21 ianm-openbsd ntpd[11805]: adjusting local clock by 33.548572s Dec 15 10:34:21 ianm-openbsd ntpd[1991]: clock is now synced Dec 15 10:35:52 ianm-openbsd ntpd[11805]: adjusting local clock by 33.107247s Dec 15 10:35:52 ianm-openbsd ntpd[1991]: clock is now unsynced Dec 15 10:37:21 ianm-openbsd ntpd[11805]: adjusting local clock by 32.662256s Dec 15 10:38:51 ianm-openbsd ntpd[11805]: adjusting local clock by 32.212314s Dec 15 10:40:21 ianm-openbsd ntpd[11805]: adjusting local clock by 31.762446s Dec 15 10:41:38 ianm-openbsd ntpd[1991]: constraint reply from 74.125.237.17: offset 30.905949 Dec 15 10:41:38 ianm-openbsd ntpd[1991]: constraint reply from 74.125.237.20: offset 30.905572 Dec 15 10:41:38 ianm-openbsd ntpd[1991]: constraint reply from 74.125.237.19: offset 30.903128 Dec 15 10:41:38 ianm-openbsd ntpd[1991]: constraint reply from 74.125.237.18: offset 30.900721 Dec 15 10:41:38 ianm-openbsd ntpd[1991]: constraint reply from 74.125.237.16: offset 30.823298 Dec 15 10:41:51 ianm-openbsd ntpd[11805]: adjusting local clock by 31.312487s Dec 15 10:41:55 ianm-openbsd ntpd[1991]: peer 121.0.0.42 now valid Dec 15 10:41:57 ianm-openbsd ntpd[1991]: peer 110.21.107.139 now valid Dec 15 10:41:58 ianm-openbsd ntpd[1991]: peer 202.60.94.11 now valid Dec 15 10:41:58 ianm-openbsd ntpd[1991]: peer 60.241.92.80 now valid Dec 15 10:42:54 ianm-openbsd ntpd[11805]: adjusting local clock by 30.997486s ntpd_flags="-s" ntpd.conf #servers pool.ntp.org #servers 0.au.pool.ntp.org servers au.pool.ntp.org sensor * constraints from "https://www.google.com"; OpenBSD 5.8-current (GENERIC.MP) #0: Mon Dec 14 10:37:32 AEDT 2015 r...@ianm-openbsd..edu.au:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3141468160 (2995MB) avail mem = 3042197504 (2901MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (242 entries) bios0: vendor Phoenix Technologies LTD version "6.00" date 07/02/2015 bios0: VMware, Inc. VMware Virtual Platform acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP BOOT APIC MCFG SRAT HPET WAET acpi0: wakeup devices PCI0(S3) USB_(S1) P2P0(S3) S1F0(S3) S2F0(S3) S3F0(S3) S4F0(S3) S5F0(S3) S6F0(S3) S7F0(S3) S8F
Re: [patch v3] cwm: Preserve stacking order during cycling
On 14 December 2015 at 22:37, Okan Demirmen wrote: > Hi - I haven't had spare cycles to look into this, nor the other recent > patches yet, but they have not been ignored. Oh no worries, and thanks to you! I was just wondering because they change cwm's behaviour, which might catch users off guard. But I have no idea how many people use it or how many would agree with the changes. And adding more options doesn't seem to be the OpenBSD way. Anyway, I don't really mind using it like I am now, I was simply interested. Thanks!
Re: [patch v3] cwm: Preserve stacking order during cycling
On Mon 2015.12.14 at 20:06 +0100, Matej Nanut wrote: > On 6 December 2015 at 15:15, Vadim Vygonets wrote: > > Even when cycling in group, all visible windows should be > > restacked. Patch version 3. > > Hello, > > will these patches eventually be commited to CVS? > > I really like this one. Hi - I haven't had spare cycles to look into this, nor the other recent patches yet, but they have not been ignored. Thanks.
relayd HTTP PATCH not handled.
Hey, HTTP_METHOD_PATCH is not handled by relayd at all. Well, actually in fals under default in switch(). PATCH is like PUT, eg. data is expected. One-liner below fixes this. Tested in production. --- relay_http.cMon Dec 14 16:16:07 2015 +++ relay_http.c.my Mon Dec 14 21:18:50 2015 @@ -371,6 +371,7 @@ break; case HTTP_METHOD_POST: case HTTP_METHOD_PUT: + case HTTP_METHOD_PATCH: case HTTP_METHOD_RESPONSE: /* HTTP request payload */ if (cre->toread > 0)
Re: Use off_t for lineno in csplit
Mark Kettenis wrote: > > Date: Sat, 12 Dec 2015 16:26:30 -0500 > > From: Michael McConville > > > > Mark Kettenis wrote: > > > It really is confusing to use off_t for something that's not a byte > > > offset. If integer overflow really is an issue you care about, use > > > "long long". > > > > ok for the below diff to update my grep change? > > Fine with me. Thanks. And how about this for csplit? Index: csplit.c === RCS file: /cvs/src/usr.bin/csplit/csplit.c,v retrieving revision 1.8 diff -u -p -r1.8 csplit.c --- csplit.c11 Oct 2015 17:43:03 - 1.8 +++ csplit.c14 Dec 2015 20:03:43 - @@ -80,7 +80,7 @@ intkflag; /* Keep output if error oc /* * Other miscellaneous globals (XXX too many) */ -longlineno;/* Current line number in input file */ +long long lineno; /* Current line number in input file */ longreps; /* Number of repetitions for this pattern */ longnfiles;/* Number of files output so far */ longmaxfiles; /* Maximum number of files we can create */ @@ -439,7 +439,7 @@ do_rexp(const char *expr) void do_lineno(const char *expr) { - long lastline, tgtline; + long long lastline, tgtline; char *ep, *p; FILE *ofp; @@ -455,7 +455,7 @@ do_lineno(const char *expr) ofp = newfile(); while (lineno + 1 != lastline) { if ((p = get_line()) == NULL) - errx(1, "%ld: out of range", lastline); + errx(1, "%lld: out of range", lastline); if (fputs(p, ofp) != 0) break; }
Re: SQLite 3.9.2 update
On Mon, Dec 14, 2015 at 01:09:38PM -0500, James Turner wrote: > SQLite 3.9.2 updated. Tested on amd64. I've included the json extension > but haven't enabled it yet. I can leave it out if know thinks it will be > usful at this time and can always at it later. oks? I havent tested this yet, but i'll just say that firefox 44 (due in 6 weeks) relies/integrates 3.9.1.. just the same story all over :) So i'll put it on my buildboxes as soon as i'll start working on 44beta next weekend.. I'll also welcome getting this in before the next lock. Thanks for working on this ! Landry
Re: [patch v3] cwm: Preserve stacking order during cycling
On 6 December 2015 at 15:15, Vadim Vygonets wrote: > Even when cycling in group, all visible windows should be > restacked. Patch version 3. Hello, will these patches eventually be commited to CVS? I really like this one. Matej
[patch] mailwrapper(8): remove unneeded argument in addarg
This patch removes the copy argument to addarg, which is unneeded. No functional change. Index: mailwrapper.c === RCS file: /cvs/src/usr.sbin/mailwrapper/mailwrapper.c,v retrieving revision 1.21 diff -u -p -r1.21 mailwrapper.c --- mailwrapper.c 14 Dec 2015 02:56:07 - 1.21 +++ mailwrapper.c 14 Dec 2015 16:42:14 - @@ -51,7 +51,7 @@ struct arglist { int main(int, char *[], char *[]); static void initarg(struct arglist *); -static void addarg(struct arglist *, const char *, int); +static void addarg(struct arglist *, const char *); extern const char *__progname; /* from crt0.o */ @@ -65,7 +65,7 @@ initarg(struct arglist *al) } static void -addarg(struct arglist *al, const char *arg, int copy) +addarg(struct arglist *al, const char *arg) { if (al->argc == al->maxc) { al->maxc <<= 1; @@ -73,11 +73,8 @@ addarg(struct arglist *al, const char *a if (al->argv == NULL) err(1, "realloc"); } - if (copy) { - if ((al->argv[al->argc++] = strdup(arg)) == NULL) - err(1, "strdup"); - } else - al->argv[al->argc++] = (char *)arg; + + al->argv[al->argc++] = (char *)arg; } int @@ -98,7 +95,7 @@ main(int argc, char *argv[], char *envp[ initarg(&al); for (len = 0; len < argc; len++) - addarg(&al, argv[len], 0); + addarg(&al, argv[len]); config = fopen(_PATH_MAILERCONF, "r"); @@ -106,7 +103,7 @@ main(int argc, char *argv[], char *envp[ err(1, "pledge"); if (config == NULL) { - addarg(&al, NULL, 0); + addarg(&al, NULL); openlog(__progname, LOG_PID, LOG_MAIL); syslog(LOG_INFO, "cannot open %s, using %s as default MTA", _PATH_MAILERCONF, _PATH_DEFAULTMTA); @@ -145,7 +142,7 @@ main(int argc, char *argv[], char *envp[ for (ap = strsep(&cp, WS); ap != NULL; ap = strsep(&cp, WS)) if (*ap) - addarg(&al, ap, 0); + addarg(&al, ap); break; } @@ -154,7 +151,7 @@ main(int argc, char *argv[], char *envp[ (void)fclose(config); - addarg(&al, NULL, 0); + addarg(&al, NULL); execve(to, al.argv, envp); err(1, "cannot exec %s", to);
Allocation type in kern/exec_elf.c
Hey all, I'm wondering, why an allocation type in kern/exec_elf.c is equal to M_TEMP? For instance, kern/exec_script.c and kern/kern_exec.c allocate memory as M_EXEC, and it looks more reasonable to me. What's the reason for this? Thanks in advance.
Re: umass: size for free
Mathieu - wrote: > Mathieu - wrote: > > > > Hello, > > > > Martin Pieuchot wrote: > > > Hello, > > > > > > On 07/12/15(Mon) 16:48, Mathieu - wrote: > > > > Hello, > > > > > > > > I worked a bit on umass(4) recently and had a diff to pass the > > > > umassbus_softc's real size to free so here it is. At some point I > > > > pondered about deleting the whole abstraction, as it would simplify the > > > > free'ing, for we only have one implementation (umass_scsi_softc, as > > > > atapi > > > > uses it too). But I figured it would be against the whole design of the > > > > umass driver, thoughts? > > > > > > I'd rather create a umass_scsi_detach() function symmetrical to > > > umass_scsi_attach(). This way you don't need an extra variable > > > for the size, keep the autoconf(9) glue inside umass_scsi.c and > > > can turn "struct umassbus_softc" into an opaque type. > > > > Please find a patch implementing the suggested approach below. > > Oups I left a debugging printf in there. Here is the clean patch, sorry > again for the noise. Anyone?