Re: cpu utilisation bars for top(1)
Hey,
thanks for the diff. I gave it a try and i really like it. On a server
with 32 cores this can be usefull to get a quick look at what is going
on. As long as this is not the default and just a toggle it is very
usefull for my usecase.
Your diff works well on my system.
Thanks and greeings
Leo
Am 13.04.2020 um 16:47 schrieb Edd Barrett:
Hi,
One thing I miss from our top(1) is the ability to see overall CPU
utilisation at a glance (I usually scan for the idle percentage and
invert it in my head).
This diff adds a way to toggle (using `B`) CPU utilisation bars, like this:
```
load averages: 0.92, 0.52, 1.26 arrakis.home
15:31:14
110 processes: 108 idle, 1 stopped, 1 on processorup 1 day,
2:15
[]
37.1%
[# ]
45.0%
[]
42.8%
[### ]
47.2%
Memory: Real: 4399M/12G act/tot Free: 11G Cache: 6204M Swap: 0K/1028M
```
The value reported is the inverse of the idle percentage and the bars
replace the 'user, nice, sys, ...' lines.
Can also be enabled from the command line with `-B`.
What do people think?
(I know htop from ports does utilisation bars, but I prefer pretty much
everything else about our in-base top.)
Index: display.c
===
RCS file: /cvs/src/usr.bin/top/display.c,v
retrieving revision 1.61
diff -u -p -r1.61 display.c
--- display.c 27 Oct 2019 13:52:26 - 1.61
+++ display.c 13 Apr 2020 14:43:10 -
@@ -105,6 +105,7 @@ extern int combine_cpus;
extern struct process_select ps;
int header_status = true;
+int cpu_bars = false;
static int
empty(void)
@@ -382,6 +383,13 @@ i_cpustates(int64_t *ostates, int *onlin
double value;
int64_t *states;
char **names, *thisname;
+ char cpu_bar[MAX_COLS];
+ int hash_space = screen_width - 8; /* space for hash chars in bars */
+
+ /* this is used as an offset into cpu_bar and must never be negative */
+ if (hash_space < 0) {
+ hash_space = 0;
+ }
if (combine_cpus) {
static double *values;
@@ -438,18 +446,30 @@ i_cpustates(int64_t *ostates, int *onlin
if (screen_length > 2 + cpu_line || !smart_terminal) {
move(2 + cpu_line, 0);
clrtoeol();
- addstrp(cpustates_tag(cpu));
-
- while ((thisname = *names++) != NULL) {
- if (*thisname != '\0') {
- /* retrieve the value and remember it */
- value = *states++;
-
- /* if percentage is >= 1000, print it
as 100% */
- printwp((value >= 1000 ? "%s%4.0f%% %s"
:
- "%s%4.1f%% %s"), first++ == 0 ? "" : ",
",
- value / 10., thisname);
+ if (!cpu_bars) {
+ addstrp(cpustates_tag(cpu));
+ while ((thisname = *names++) != NULL) {
+ if (*thisname != '\0') {
+ /* retrieve the value and
remember it */
+ value = *states++;
+
+ /* if percentage is >= 1000,
print it as 100% */
+ printwp((value >= 1000 ? "%s%4.0f%%
%s" :
+"%s%4.1f%% %s"), first++ == 0 ?
"" : ", ",
+ value / 10., thisname);
+ }
}
+ } else {
+ float idle_ratio = (states[5] >= 1000 ? 1000 :
states[5]) / 1000.;
+ int n_idle_chars = hash_space * idle_ratio;
+ int n_busy_chars = hash_space - n_idle_chars;
+
+ cpu_bar[0] = '[';
+ memset(cpu_bar + 1, '#', n_busy_chars);
+ memset(cpu_bar + 1 + n_busy_chars, ' ',
n_idle_chars);
+ snprintf(cpu_bar + hash_space, 9, "] %5.1f%%",
+ 100 - idle_ratio * 100);
+ printwp("%s", cpu_bar);
}
putn();
cpu_line++;
Index: top.1
===
RCS file: /cvs/src/usr.bin/top/top
Re: suggest to run rpki-client hourly
Bob Beck wrote: > On Mon, Apr 13, 2020 at 09:23:23PM -0600, Todd C. Miller wrote: > > On Mon, 13 Apr 2020 20:27:30 -0600, Bob Beck wrote: > > > > > In my hearts desire I'd love for "R" to be chosen for each line once at > > > start > > > up. (so in > > > the above example the things are randomly distributed). but not sure how > > > har > > > d that is.. > > > > > > If it saves code and effort I really think this is only useful for hours > > > and > > > minutes > > > > Here's a version that uses a suggestion from Theo to support ranges > > like "0~30" to mean a random number between 0 and 30 and just a > > bare "~" to mean a random value in the valid range for that field. > > > > The random values are chosen when the file is parsed which means > > that on reload due to crontab edit they will change. I was trying > > to avoid that initially but now I don't think it is a big deal. > > Like this one plenty. I think it's ok the values change on reload. The main benefit this brings is is slop within a region of an hour. For instance, randomly in the start or end of the hour, 0~29 or 39~59. Trashing is easier to avoid. I never liked cron starting a shell, which runs a random sleep before doing work. In particular, the "crontab -e" behaviour when such a sleeping process has already been started is just ugly. It will won't quite help the rpki-client situation. That may need some additional intelligence.
Re: tcpdump: print nhrp packets
> On 13 Apr 2020, at 19:03, Remi Locherer wrote: > > Hi, > > I recently looked into NHRP (RFC 2332) and noticed that our tcpdump does > not have a printer for it. So I added support for NHRP to tcpdump. > > Initially I was surprised: I expected a simpler protocol! But it is from > the 90's with all the protocols from then in mind (frame relay, ATM, ...). > > I tested with public available pcap files and compared the output with > wirshark. > https://packetlife.net/captures/protocol/nhrp/ > https://www.networkingwithfish.com/fun-in-the-lab-sniffer-tracing-a-dmvpn-tunnel-startup/ > > The output looks like this: > > 08:34:45.647483 172.16.25.2 > 172.16.15.2: gre NHRP: reg request, id 7 [tos > 0xc0] > 08:34:45.671422 172.16.15.2 > 172.16.25.2: gre NHRP: reg reply, id 7 [tos > 0xc0] > > 08:47:16.138679 172.16.15.2 > 172.16.25.2: gre NHRP: res request, id 6 [tos > 0xc0] > 08:47:16.148863 172.16.25.2 > 172.16.15.2: gre NHRP: res reply, id 6 [tos > 0xc0] > > With -v set: > > 08:34:45.647483 172.16.25.2 > 172.16.15.2: gre [] 2001 NHRP: reg request, id > 7, hopcnt 255, src nbma 172.16.25.2, 192.168.0.2 -> 192.168.0.1 (code 0, pl > 255, mtu 1514, htime 7200, pref 0) [tos 0xc0] (ttl 254, id 22, len 116) > 08:34:45.671422 172.16.15.2 > 172.16.25.2: gre [] 2001 NHRP: reg reply, id 7, > hopcnt 255, src nbma 172.16.25.2, 192.168.0.2 -> 192.168.0.1 (code 0, pl 255, > mtu 1514, htime 7200, pref 0) [tos 0xc0] (ttl 255, id 7, len 136) > > 08:47:16.138679 172.16.15.2 > 172.16.25.2: gre [] 2001 NHRP: res request, id > 6, hopcnt 254, src nbma 172.16.45.2, 192.168.0.4 -> 192.168.0.2 (code 0, pl > 0, mtu 1514, htime 7200, pref 0) [tos 0xc0] (ttl 254, id 20, len 116) > 08:47:16.148863 172.16.25.2 > 172.16.15.2: gre [] 2001 NHRP: res reply, id 6, > hopcnt 255, src nbma 172.16.45.2, 192.168.0.4 -> 192.168.0.2 (code 0, pl 32, > mtu 1514, htime 7199, pref 0, nbma 172.16.25.2, proto 192.168.0.2) [tos 0xc0] > (ttl 255, id 31, len 144) > > Extensions are not parsed and printed. > > It would be nice to get pcaps with expamles that use address or protocol > combinations other than GRE and IPv4. > > Comments, OKs? Can you print the addresses when -v is not set too? Otherwise I'm keen. > > Remi > > > Index: Makefile > === > RCS file: /cvs/src/usr.sbin/tcpdump/Makefile,v > retrieving revision 1.64 > diff -u -p -r1.64 Makefile > --- Makefile 3 Dec 2019 01:43:33 - 1.64 > +++ Makefile 28 Mar 2020 17:07:22 - > @@ -48,7 +48,7 @@ SRCS= tcpdump.c addrtoname.c privsep.c p > print-bgp.c print-ospf6.c print-ripng.c print-rt6.c print-stp.c \ > print-etherip.c print-lwres.c print-lldp.c print-cdp.c print-pflog.c \ > print-pfsync.c pf_print_state.c print-ofp.c ofp_map.c \ > - print-udpencap.c print-carp.c \ > + print-udpencap.c print-carp.c print-nhrp.c \ > print-802_11.c print-iapp.c print-mpls.c print-slow.c print-usbpcap.c \ > gmt2local.c savestr.c setsignal.c in_cksum.c > > Index: interface.h > === > RCS file: /cvs/src/usr.sbin/tcpdump/interface.h,v > retrieving revision 1.83 > diff -u -p -r1.83 interface.h > --- interface.h 3 Dec 2019 01:43:33 - 1.83 > +++ interface.h 28 Mar 2020 17:07:22 - > @@ -217,6 +217,7 @@ extern void ppp_ether_if_print(u_char *, > extern void gre_print(const u_char *, u_int); > extern void vxlan_print(const u_char *, u_int); > extern void nsh_print(const u_char *, u_int); > +extern void nhrp_print(const u_char *, u_int); > extern void icmp_print(const u_char *, u_int, const u_char *); > extern void ieee802_11_if_print(u_char *, const struct pcap_pkthdr *, > const u_char *); > Index: print-ether.c > === > RCS file: /cvs/src/usr.sbin/tcpdump/print-ether.c,v > retrieving revision 1.37 > diff -u -p -r1.37 print-ether.c > --- print-ether.c 24 Jan 2020 22:46:36 - 1.37 > +++ print-ether.c 28 Mar 2020 17:07:22 - > @@ -303,6 +303,13 @@ recurse: > ether_pbb_print(p, length, caplen); > return (1); > > +#ifndef ETHERTYPE_NHRP > +#define ETHERTYPE_NHRP 0x2001 > +#endif > + case ETHERTYPE_NHRP: > + nhrp_print(p, length); > + return (1); > + > #ifdef PPP > case ETHERTYPE_PPPOEDISC: > case ETHERTYPE_PPPOE: > Index: print-gre.c > === > RCS file: /cvs/src/usr.sbin/tcpdump/print-gre.c,v > retrieving revision 1.30 > diff -u -p -r1.30 print-gre.c > --- print-gre.c 24 Jan 2020 22:46:36 - 1.30 > +++ print-gre.c 28 Mar 2020 17:07:22 - > @@ -289,6 +289,12 @@ gre_print_0(const u_char *p, u_int lengt > case 0x2000: > cdp_print(p, length, l, 0); > break; > +#ifndef ETHERTYPE_NHRP > +#define ETHERTYPE_NHRP 0x2001 > +#endif > + cas
Re: suggest to run rpki-client hourly
On Mon, Apr 13, 2020 at 09:23:23PM -0600, Todd C. Miller wrote:
> On Mon, 13 Apr 2020 20:27:30 -0600, Bob Beck wrote:
>
> > In my hearts desire I'd love for "R" to be chosen for each line once at
> > start
> > up. (so in
> > the above example the things are randomly distributed). but not sure how
> > har
> > d that is..
> >
> > If it saves code and effort I really think this is only useful for hours
> > and
> > minutes
>
> Here's a version that uses a suggestion from Theo to support ranges
> like "0~30" to mean a random number between 0 and 30 and just a
> bare "~" to mean a random value in the valid range for that field.
>
> The random values are chosen when the file is parsed which means
> that on reload due to crontab edit they will change. I was trying
> to avoid that initially but now I don't think it is a big deal.
Like this one plenty. I think it's ok the values change on reload.
>
> - todd
>
> Index: usr.sbin/cron/entry.c
> ===
> RCS file: /cvs/src/usr.sbin/cron/entry.c,v
> retrieving revision 1.49
> diff -u -p -u -r1.49 entry.c
> --- usr.sbin/cron/entry.c 13 Jun 2018 11:27:30 - 1.49
> +++ usr.sbin/cron/entry.c 14 Apr 2020 01:52:13 -
> @@ -450,13 +450,30 @@ static int
> get_range(bitstr_t *bits, int low, int high, const char *names[],
> int ch, FILE *file)
> {
> - /* range = number | number "-" number [ "/" number ]
> + /* range = number | number* "~" number* | number "-" number ["/" number]
>*/
>
> int i, num1, num2, num3;
>
> + /* XXX - parse ~, X~Y, X~ and ~Y */
> +
> + if (ch == '~') {
> + /* '~' means a random number [high, low]
> + */
> + num1 = arc4random_uniform(high - low + 1) + low;
> + ch = get_char(file);
> + if (ch == EOF)
> + return (EOF);
> +
> + if (EOF == set_element(bits, low, high, num1)) {
> + unget_char(ch, file);
> + return (EOF);
> + }
> + return (ch);
> + }
> +
> if (ch == '*') {
> - /* '*' means "first-last" but can still be modified by /step
> + /* '*' means "high-low" but can still be modified by /step
>*/
> num1 = low;
> num2 = high;
> @@ -464,30 +481,45 @@ get_range(bitstr_t *bits, int low, int h
> if (ch == EOF)
> return (EOF);
> } else {
> - ch = get_number(&num1, low, names, ch, file, ",- \t\n");
> + ch = get_number(&num1, low, names, ch, file, ",-~ \t\n");
> if (ch == EOF)
> return (EOF);
>
> - if (ch != '-') {
> - /* not a range, it's a single number.
> - */
> - if (EOF == set_element(bits, low, high, num1)) {
> - unget_char(ch, file);
> - return (EOF);
> - }
> - return (ch);
> - } else {
> - /* eat the dash
> + switch (ch) {
> + case '-':
> + case '~':
> + num3 = ch;
> +
> + /* eat the dash/tilde
>*/
> ch = get_char(file);
> if (ch == EOF)
> return (EOF);
>
> - /* get the number following the dash
> + /* get the number following the dash/tilde
>*/
> ch = get_number(&num2, low, names, ch, file, "/, \t\n");
> if (ch == EOF || num1 > num2)
> return (EOF);
> +
> + /* if it's a standard range, we're done here.
> + */
> + if (num3 == '-')
> + break;
> +
> + /* get a random number in the range [num1, num2]
> + */
> + num3 = num1;
> + num1 = arc4random_uniform(num2 - num3 + 1) + num3;
> + /* FALLTHROUGH */
> + default:
> + /* not a range, it's a single number.
> + */
> + if (EOF == set_element(bits, low, high, num1)) {
> + unget_char(ch, file);
> + return (EOF);
> + }
> + return (ch);
> }
> }
>
>
Re: suggest to run rpki-client hourly
On Mon, 13 Apr 2020 20:27:30 -0600, Bob Beck wrote:
> In my hearts desire I'd love for "R" to be chosen for each line once at start
> up. (so in
> the above example the things are randomly distributed). but not sure how har
> d that is..
>
> If it saves code and effort I really think this is only useful for hours and
> minutes
Here's a version that uses a suggestion from Theo to support ranges
like "0~30" to mean a random number between 0 and 30 and just a
bare "~" to mean a random value in the valid range for that field.
The random values are chosen when the file is parsed which means
that on reload due to crontab edit they will change. I was trying
to avoid that initially but now I don't think it is a big deal.
- todd
Index: usr.sbin/cron/entry.c
===
RCS file: /cvs/src/usr.sbin/cron/entry.c,v
retrieving revision 1.49
diff -u -p -u -r1.49 entry.c
--- usr.sbin/cron/entry.c 13 Jun 2018 11:27:30 - 1.49
+++ usr.sbin/cron/entry.c 14 Apr 2020 01:52:13 -
@@ -450,13 +450,30 @@ static int
get_range(bitstr_t *bits, int low, int high, const char *names[],
int ch, FILE *file)
{
- /* range = number | number "-" number [ "/" number ]
+ /* range = number | number* "~" number* | number "-" number ["/" number]
*/
int i, num1, num2, num3;
+ /* XXX - parse ~, X~Y, X~ and ~Y */
+
+ if (ch == '~') {
+ /* '~' means a random number [high, low]
+*/
+ num1 = arc4random_uniform(high - low + 1) + low;
+ ch = get_char(file);
+ if (ch == EOF)
+ return (EOF);
+
+ if (EOF == set_element(bits, low, high, num1)) {
+ unget_char(ch, file);
+ return (EOF);
+ }
+ return (ch);
+ }
+
if (ch == '*') {
- /* '*' means "first-last" but can still be modified by /step
+ /* '*' means "high-low" but can still be modified by /step
*/
num1 = low;
num2 = high;
@@ -464,30 +481,45 @@ get_range(bitstr_t *bits, int low, int h
if (ch == EOF)
return (EOF);
} else {
- ch = get_number(&num1, low, names, ch, file, ",- \t\n");
+ ch = get_number(&num1, low, names, ch, file, ",-~ \t\n");
if (ch == EOF)
return (EOF);
- if (ch != '-') {
- /* not a range, it's a single number.
-*/
- if (EOF == set_element(bits, low, high, num1)) {
- unget_char(ch, file);
- return (EOF);
- }
- return (ch);
- } else {
- /* eat the dash
+ switch (ch) {
+ case '-':
+ case '~':
+ num3 = ch;
+
+ /* eat the dash/tilde
*/
ch = get_char(file);
if (ch == EOF)
return (EOF);
- /* get the number following the dash
+ /* get the number following the dash/tilde
*/
ch = get_number(&num2, low, names, ch, file, "/, \t\n");
if (ch == EOF || num1 > num2)
return (EOF);
+
+ /* if it's a standard range, we're done here.
+*/
+ if (num3 == '-')
+ break;
+
+ /* get a random number in the range [num1, num2]
+*/
+ num3 = num1;
+ num1 = arc4random_uniform(num2 - num3 + 1) + num3;
+ /* FALLTHROUGH */
+ default:
+ /* not a range, it's a single number.
+*/
+ if (EOF == set_element(bits, low, high, num1)) {
+ unget_char(ch, file);
+ return (EOF);
+ }
+ return (ch);
}
}
Re: suggest to run rpki-client hourly
A couple thoughts:
1) I'm not sure how useful random months or days of the week are, but for
consistency maybe?
2) if I do something like
R * * * * /usr/local/bin/thing1
R * * * * /usr/local/bin/thing2
R * * * * /usr/local/bin/thing3
...
R * * * * /usr/local/bin/thing1000
I still have the thundering herd problem a bit, in that all my things fire at
the same R.
In my hearts desire I'd love for "R" to be chosen for each line once at
startup. (so in
the above example the things are randomly distributed). but not sure how hard
that is..
If it saves code and effort I really think this is only useful for hours and
minutes
On Mon, Apr 13, 2020 at 12:54:34PM -0600, Todd C. Miller wrote:
> On Mon, 13 Apr 2020 10:00:52 -0600, Bob Beck wrote:
>
> > +1000. a new random time chosen at cron start.
> >
> > We see this all the time, and it would be a lot better than the hacks for
> > all
> > the things
> >
> > "R" for random sounds good to me
>
> How about this? If you guys like it I'll update the man page too.
> So far only tested with a crontab entry like:
>
> R * * * * date
>
> - todd
>
> Index: usr.sbin/cron/cron.c
> ===
> RCS file: /cvs/src/usr.sbin/cron/cron.c,v
> retrieving revision 1.78
> diff -u -p -u -r1.78 cron.c
> --- usr.sbin/cron/cron.c 11 Feb 2020 12:42:01 - 1.78
> +++ usr.sbin/cron/cron.c 13 Apr 2020 16:25:44 -
> @@ -129,6 +129,7 @@ main(int argc, char *argv[])
> syslog(LOG_INFO, "(CRON) STARTUP (%s)", CRON_VERSION);
> }
>
> + init_random();
> load_database(&database);
> scan_atjobs(&at_database, NULL);
> set_time(TRUE);
> Index: usr.sbin/cron/entry.c
> ===
> RCS file: /cvs/src/usr.sbin/cron/entry.c,v
> retrieving revision 1.49
> diff -u -p -u -r1.49 entry.c
> --- usr.sbin/cron/entry.c 13 Jun 2018 11:27:30 - 1.49
> +++ usr.sbin/cron/entry.c 13 Apr 2020 18:49:56 -
> @@ -54,6 +54,12 @@ static const char *ecodes[] = {
> "out of memory"
> };
>
> +typedef enum r_type {
> + r_minute, r_hour, r_dom, r_month, r_dow
> +} rtype_e;
> +
> +static int rand_vals[5];
> +
> static const char *MonthNames[] = {
> "Jan", "Feb", "Mar", "Apr", "May", "Jun",
> "Jul", "Aug", "Sep", "Oct", "Nov", "Dec",
> @@ -70,6 +76,8 @@ static int get_list(bitstr_t *, int, int
> get_number(int *, int, const char *[], int, FILE *, const char
> *),
> set_element(bitstr_t *, int, int, int);
>
> +static int set_random(bitstr_t *, int, int, FILE *);
> +
> void
> free_entry(entry *e)
> {
> @@ -187,10 +195,15 @@ load_entry(FILE *file, void (*error_func
> goto eof;
> }
> } else {
> - if (ch == '*')
> - e->flags |= MIN_STAR;
> - ch = get_list(e->minute, FIRST_MINUTE, LAST_MINUTE,
> - NULL, ch, file);
> + if (ch == 'R') {
> + ch = set_random(e->minute, rand_vals[r_minute], ch,
> + file);
> + } else {
> + if (ch == '*')
> + e->flags |= MIN_STAR;
> + ch = get_list(e->minute, FIRST_MINUTE, LAST_MINUTE,
> + NULL, ch, file);
> + }
> if (ch == EOF) {
> ecode = e_minute;
> goto eof;
> @@ -199,10 +212,14 @@ load_entry(FILE *file, void (*error_func
> /* hours
>*/
>
> - if (ch == '*')
> - e->flags |= HR_STAR;
> - ch = get_list(e->hour, FIRST_HOUR, LAST_HOUR,
> - NULL, ch, file);
> + if (ch == 'R') {
> + ch = set_random(e->hour, rand_vals[r_hour], ch, file);
> + } else {
> + if (ch == '*')
> + e->flags |= HR_STAR;
> + ch = get_list(e->hour, FIRST_HOUR, LAST_HOUR,
> + NULL, ch, file);
> + }
> if (ch == EOF) {
> ecode = e_hour;
> goto eof;
> @@ -211,10 +228,15 @@ load_entry(FILE *file, void (*error_func
> /* DOM (days of month)
>*/
>
> - if (ch == '*')
> - e->flags |= DOM_STAR;
> - ch = get_list(e->dom, FIRST_DOM, LAST_DOM,
> - NULL, ch, file);
> + if (ch == 'R') {
> + /* Note: the DOM value may not exist in this month. */
> + ch = set_random(e->dom, rand_vals[r_dom], ch, file);
> + } else {
> + if (ch == '*')
> + e->flags |= DOM_STAR;
> + ch = get_list(e->dom, F
Maintenance: (man|cvsweb).openbsd.org, (openbsd|obsdacvs).cs.toronto.edu
hi. The following servers will likely be inaccessible at times or completely, April 14, from 7am to 8pm Eastern Daylight Time (UTC-4) (yes -- 13 hour window) for site network maintenance. * man.openbsd.org * cvsweb.openbsd.org * obsdacvs.cs.toronto.edu * openbsd.cs.toronto.edu Nick.
mips64 bus_space fixes
patrick@ pointed out that the arm64 bus_space implementation was
(partly) copied from mips64. Therefore th fixes should probably be
applied there as well.
Untested so far.
Index: arch/loongson/include/bus.h
===
RCS file: /cvs/src/sys/arch/loongson/include/bus.h,v
retrieving revision 1.7
diff -u -p -r1.7 bus.h
--- arch/loongson/include/bus.h 8 May 2017 00:27:45 - 1.7
+++ arch/loongson/include/bus.h 13 Apr 2020 21:42:14 -
@@ -144,8 +144,10 @@ static __inline void
\
CAT(bus_space_read_region_,n)(bus_space_tag_t bst, bus_space_handle_t bsh,\
bus_addr_t ba, CAT3(u_int,m,_t) *x, size_t cnt) \
{\
- while (cnt--) \
- *x++ = CAT(bus_space_read_,n)(bst, bsh, ba++);\
+ while (cnt--) { \
+ *x++ = CAT(bus_space_read_,n)(bst, bsh, ba); \
+ ba += (n);\
+ } \
}
bus_space_read_region(1,8)
@@ -178,9 +180,8 @@ static __inline void
\
CAT(bus_space_write_multi_,n)(bus_space_tag_t bst, bus_space_handle_t bsh,\
bus_size_t o, const CAT3(u_int,m,_t) *x, size_t cnt)\
{\
- while (cnt--) { \
+ while (cnt--) \
CAT(bus_space_write_,n)(bst, bsh, o, *x++); \
- } \
}
bus_space_write_multi(1,8)
@@ -196,7 +197,7 @@ CAT(bus_space_write_region_,n)(bus_space
{\
while (cnt--) { \
CAT(bus_space_write_,n)(bst, bsh, ba, *x++); \
- ba += sizeof(x); \
+ ba += (n);\
} \
}
@@ -232,7 +233,7 @@ CAT(bus_space_set_region_,n)(bus_space_t
{\
while (cnt--) { \
CAT(bus_space_write_,n)(bst, bsh, ba, x); \
- ba += sizeof(x); \
+ ba += (n);\
} \
}
Index: arch/octeon/include/bus.h
===
RCS file: /cvs/src/sys/arch/octeon/include/bus.h,v
retrieving revision 1.7
diff -u -p -r1.7 bus.h
--- arch/octeon/include/bus.h 8 May 2017 00:27:45 - 1.7
+++ arch/octeon/include/bus.h 13 Apr 2020 21:42:15 -
@@ -142,8 +142,10 @@ static __inline void
\
CAT(bus_space_read_region_,n)(bus_space_tag_t bst, bus_space_handle_t bsh,\
bus_addr_t ba, CAT3(u_int,m,_t) *x, size_t cnt) \
{\
- while (cnt--) \
- *x++ = CAT(bus_space_read_,n)(bst, bsh, ba++);\
+ while (cnt--) { \
+ *x++ = CAT(bus_space_read_,n)(bst, bsh, ba); \
+ ba += (n);\
+ } \
}
bus_space_read_region(1,8)
@@ -176,9 +178,8 @@ static __inline void
\
CAT(bus_space_write_multi_,n)(bus_space_tag_t bst, bus_space_handle_t bsh,\
bus_size_t o, const CAT3(u_int,m,_t) *x, size_t cnt)\
{\
- while (cnt--) { \
+ while (cnt--) \
CAT(bus_space_write_,n)(bst, bsh, o, *x++); \
- }
Re: suggest to run rpki-client hourly
On Mon, 13 Apr 2020 10:00:52 -0600, Bob Beck wrote:
> +1000. a new random time chosen at cron start.
>
> We see this all the time, and it would be a lot better than the hacks for all
> the things
>
> "R" for random sounds good to me
How about this? If you guys like it I'll update the man page too.
So far only tested with a crontab entry like:
R * * * * date
- todd
Index: usr.sbin/cron/cron.c
===
RCS file: /cvs/src/usr.sbin/cron/cron.c,v
retrieving revision 1.78
diff -u -p -u -r1.78 cron.c
--- usr.sbin/cron/cron.c11 Feb 2020 12:42:01 - 1.78
+++ usr.sbin/cron/cron.c13 Apr 2020 16:25:44 -
@@ -129,6 +129,7 @@ main(int argc, char *argv[])
syslog(LOG_INFO, "(CRON) STARTUP (%s)", CRON_VERSION);
}
+ init_random();
load_database(&database);
scan_atjobs(&at_database, NULL);
set_time(TRUE);
Index: usr.sbin/cron/entry.c
===
RCS file: /cvs/src/usr.sbin/cron/entry.c,v
retrieving revision 1.49
diff -u -p -u -r1.49 entry.c
--- usr.sbin/cron/entry.c 13 Jun 2018 11:27:30 - 1.49
+++ usr.sbin/cron/entry.c 13 Apr 2020 18:49:56 -
@@ -54,6 +54,12 @@ static const char *ecodes[] = {
"out of memory"
};
+typedefenum r_type {
+ r_minute, r_hour, r_dom, r_month, r_dow
+} rtype_e;
+
+static int rand_vals[5];
+
static const char *MonthNames[] = {
"Jan", "Feb", "Mar", "Apr", "May", "Jun",
"Jul", "Aug", "Sep", "Oct", "Nov", "Dec",
@@ -70,6 +76,8 @@ static intget_list(bitstr_t *, int, int
get_number(int *, int, const char *[], int, FILE *, const char
*),
set_element(bitstr_t *, int, int, int);
+static int set_random(bitstr_t *, int, int, FILE *);
+
void
free_entry(entry *e)
{
@@ -187,10 +195,15 @@ load_entry(FILE *file, void (*error_func
goto eof;
}
} else {
- if (ch == '*')
- e->flags |= MIN_STAR;
- ch = get_list(e->minute, FIRST_MINUTE, LAST_MINUTE,
- NULL, ch, file);
+ if (ch == 'R') {
+ ch = set_random(e->minute, rand_vals[r_minute], ch,
+ file);
+ } else {
+ if (ch == '*')
+ e->flags |= MIN_STAR;
+ ch = get_list(e->minute, FIRST_MINUTE, LAST_MINUTE,
+ NULL, ch, file);
+ }
if (ch == EOF) {
ecode = e_minute;
goto eof;
@@ -199,10 +212,14 @@ load_entry(FILE *file, void (*error_func
/* hours
*/
- if (ch == '*')
- e->flags |= HR_STAR;
- ch = get_list(e->hour, FIRST_HOUR, LAST_HOUR,
- NULL, ch, file);
+ if (ch == 'R') {
+ ch = set_random(e->hour, rand_vals[r_hour], ch, file);
+ } else {
+ if (ch == '*')
+ e->flags |= HR_STAR;
+ ch = get_list(e->hour, FIRST_HOUR, LAST_HOUR,
+ NULL, ch, file);
+ }
if (ch == EOF) {
ecode = e_hour;
goto eof;
@@ -211,10 +228,15 @@ load_entry(FILE *file, void (*error_func
/* DOM (days of month)
*/
- if (ch == '*')
- e->flags |= DOM_STAR;
- ch = get_list(e->dom, FIRST_DOM, LAST_DOM,
- NULL, ch, file);
+ if (ch == 'R') {
+ /* Note: the DOM value may not exist in this month. */
+ ch = set_random(e->dom, rand_vals[r_dom], ch, file);
+ } else {
+ if (ch == '*')
+ e->flags |= DOM_STAR;
+ ch = get_list(e->dom, FIRST_DOM, LAST_DOM,
+ NULL, ch, file);
+ }
if (ch == EOF) {
ecode = e_dom;
goto eof;
@@ -223,8 +245,12 @@ load_entry(FILE *file, void (*error_func
/* month
*/
- ch = get_list(e->month, FIRST_MONTH, LAST_MONTH,
- MonthNames, ch, file);
+ if (ch == 'R') {
+ ch = set_random(e->month, rand_vals[r_month], ch, file);
+ } else {
+ ch = get_list(e->month, FIRST_MONTH, LAST_MONTH,
+ MonthNames, ch, file);
+ }
if (ch == EOF) {
ecode = e_month;
Re: cpu utilisation bars for top(1)
On 2020/04/13 18:27, Edd Barrett wrote: > On Mon, Apr 13, 2020 at 11:12:46AM -0600, Theo de Raadt wrote: > > > If this is going to be done, it should look the same. I'm not talking > > about the markers above it, but about your arbitrary use of #. > > So you mean the first proposal is good, just change # to >? > > Note that systat(1) uses both chevrons (first screen) and hashes (second > screen) for CPU bar graphs. It would make better use of the screen space if it worked like systat vm - multiple characters | (interrupt), @ (spin), = (sys), > (user) ... this fits a lot more information into the same space than just using a single char to represent any type of cpu use.
Re: cpu utilisation bars for top(1)
Edd Barrett wrote: > On Mon, Apr 13, 2020 at 11:40:21AM -0600, Theo de Raadt wrote: > > I don't like it. > > > > CPU00 states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 18.2% intr, > > 81.8% idle > > CPU01 states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, > > 100% idle > > > > versus > > > > [] > > 37.1% > > [# ] > > 45.0% > > > > You have thrown information away. > > Just to be clear, I'm not proposing we change the default display. > > The bar graphs I'm proposing are only displayed when toggled on by > pressing `B` (or by invoking top(1) with `-B`). > > Otherwise the display remains exactly as it was before. An option which I believe approximately noone will use.
Re: cpu utilisation bars for top(1)
On Mon, Apr 13, 2020 at 11:40:21AM -0600, Theo de Raadt wrote: > I don't like it. > > CPU00 states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 18.2% intr, > 81.8% idle > CPU01 states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, > 100% idle > > versus > > [] > 37.1% > [# ] > 45.0% > > You have thrown information away. Just to be clear, I'm not proposing we change the default display. The bar graphs I'm proposing are only displayed when toggled on by pressing `B` (or by invoking top(1) with `-B`). Otherwise the display remains exactly as it was before. -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: cpu utilisation bars for top(1)
Edd Barrett wrote: > On Mon, Apr 13, 2020 at 11:12:46AM -0600, Theo de Raadt wrote: > > > If this is going to be done, it should look the same. I'm not talking > > about the markers above it, but about your arbitrary use of #. > > So you mean the first proposal is good, just change # to >? I don't like it. CPU00 states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 18.2% intr, 81.8% idle CPU01 states: 0.0% user, 0.0% nice, 0.0% sys, 0.0% spin, 0.0% intr, 100% idle versus [] 37.1% [# ] 45.0% You have thrown information away. I don't think any of this makes sense.
Re: cpu utilisation bars for top(1)
On Mon, Apr 13, 2020 at 11:15:59AM -0600, Theo de Raadt wrote: > I think your bar-graph removes detailed information and replaces it > with a visual which wastes screen real-estate. I agree, that's why I made it a toggle. -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: cpu utilisation bars for top(1)
On Mon, Apr 13, 2020 at 11:12:46AM -0600, Theo de Raadt wrote: > If this is going to be done, it should look the same. I'm not talking > about the markers above it, but about your arbitrary use of #. So you mean the first proposal is good, just change # to >? Note that systat(1) uses both chevrons (first screen) and hashes (second screen) for CPU bar graphs. -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: cpu utilisation bars for top(1)
Theo de Raadt wrote: > Edd Barrett wrote: > > > On Mon, Apr 13, 2020 at 06:26:53PM +0200, Sebastian Benoit wrote: > > > If you make them look like the display in systat, you still get the user, > > > ... nice, sys information. Also i like my bikeshed green. > > > > So looking at the bar in `systat vmstat`, we have: > > ``` > >0.0%Int 0.0%Spn 0.1%Sys 25.5%Usr 74.4%Idle > > ||||||||||| > > > > > ``` > > > > To replicate that exactly per-processor, we'd need 3 lines per-cpu. > > That is not what I am talking about. > > I am pointing out you were not aware of a previous display format, and > chose to make your own. > > If this is going to be done, it should look the same. I'm not talking > about the markers above it, but about your arbitrary use of #. > > Frankly I don't see any value in a bar-graph when the number is still > present. And I don't see value in a bar-graph without numbers. I think your bar-graph removes detailed information and replaces it with a visual which wastes screen real-estate.
Re: cpu utilisation bars for top(1)
Edd Barrett wrote: > On Mon, Apr 13, 2020 at 06:26:53PM +0200, Sebastian Benoit wrote: > > If you make them look like the display in systat, you still get the user, > > ... nice, sys information. Also i like my bikeshed green. > > So looking at the bar in `systat vmstat`, we have: > ``` >0.0%Int 0.0%Spn 0.1%Sys 25.5%Usr 74.4%Idle > ||||||||||| > > > ``` > > To replicate that exactly per-processor, we'd need 3 lines per-cpu. That is not what I am talking about. I am pointing out you were not aware of a previous display format, and chose to make your own. If this is going to be done, it should look the same. I'm not talking about the markers above it, but about your arbitrary use of #. Frankly I don't see any value in a bar-graph when the number is still present. And I don't see value in a bar-graph without numbers.
Re: cpu utilisation bars for top(1)
On Mon, Apr 13, 2020 at 06:26:53PM +0200, Sebastian Benoit wrote: > If you make them look like the display in systat, you still get the user, > ... nice, sys information. Also i like my bikeshed green. So looking at the bar in `systat vmstat`, we have: ``` 0.0%Int 0.0%Spn 0.1%Sys 25.5%Usr 74.4%Idle ||||||||||| > ``` To replicate that exactly per-processor, we'd need 3 lines per-cpu. I don't think we want to steal too much screen real-estate from the actual process listing, but we could try some middle-ground like: - No 'int, spn, sys, ...' line. You can toggle the bars off to see those. - One shared line for the hatchings, either an additional line or perhaps replacing the process counts line. - No enclosing square braces on the bars. - No numeric percentage display. - Use > instead of #. So that might look like: ``` load averages: 1.13, 1.03, 0.65 arrakis.home 17:51:51 118 processes: 114 idle, 1 stopped, 3 on processorup 1 day, 4:36 | | | | | | | | | | | >> >>> >>> > Memory: Real: 3931M/12G act/tot Free: 11G Cache: 6507M Swap: 0K/1028M PID USERNAME PRI NICE SIZE RES STATE WAIT TIMECPU COMMAND ... ``` Something like that? -- Best Regards Edd Barrett http://www.theunixzoo.co.uk
Re: cpu utilisation bars for top(1)
Sebastian Benoit wrote: > Edd Barrett(e...@theunixzoo.co.uk) on 2020.04.13 15:47:03 +0100: > > Hi, > > > > One thing I miss from our top(1) is the ability to see overall CPU > > utilisation at a glance (I usually scan for the idle percentage and > > invert it in my head). > > > > This diff adds a way to toggle (using `B`) CPU utilisation bars, like this: > > > > ``` > > load averages: 0.92, 0.52, 1.26 arrakis.home > > 15:31:14 > > 110 processes: 108 idle, 1 stopped, 1 on processorup 1 day, > > 2:15 > > [] > > 37.1% > > [# ] > > 45.0% > > [] > > 42.8% > > [### ] > > 47.2% > > Memory: Real: 4399M/12G act/tot Free: 11G Cache: 6204M Swap: 0K/1028M > > ``` > > > > The value reported is the inverse of the idle percentage and the bars > > replace the 'user, nice, sys, ...' lines. > > > > Can also be enabled from the command line with `-B`. > > > > What do people think? > > If you make them look like the display in systat, you still get the user, > ... nice, sys information. Also i like my bikeshed green. But it is different from the display in systat vm 1. If this is going to be done, it should be as close as possible. And this isn't.
Re: cpu utilisation bars for top(1)
Edd Barrett(e...@theunixzoo.co.uk) on 2020.04.13 15:47:03 +0100: > Hi, > > One thing I miss from our top(1) is the ability to see overall CPU > utilisation at a glance (I usually scan for the idle percentage and > invert it in my head). > > This diff adds a way to toggle (using `B`) CPU utilisation bars, like this: > > ``` > load averages: 0.92, 0.52, 1.26 arrakis.home > 15:31:14 > 110 processes: 108 idle, 1 stopped, 1 on processorup 1 day, > 2:15 > [] > 37.1% > [# ] > 45.0% > [] > 42.8% > [### ] > 47.2% > Memory: Real: 4399M/12G act/tot Free: 11G Cache: 6204M Swap: 0K/1028M > ``` > > The value reported is the inverse of the idle percentage and the bars > replace the 'user, nice, sys, ...' lines. > > Can also be enabled from the command line with `-B`. > > What do people think? If you make them look like the display in systat, you still get the user, ... nice, sys information. Also i like my bikeshed green.
Re: suggest to run rpki-client hourly
On Mon, Apr 13, 2020 at 09:56:52AM -0600, Todd C. Miller wrote: > On Mon, 13 Apr 2020 09:37:14 -0600, "Theo de Raadt" wrote: > > > While I understand what RANDOM is trying to do, I am not a fan. I've > > thought often of an improvement, where the minute marker in a crontab > > file could be a letter 'R', which indicates the specific random value > > for this cron start. That value would be selected at cron start, and > > remain constant for the runtime of cron. > > I was thinking the same thing, but using '?' as the character. It > doesn't really matter what we choose, the implementation should be > straight-forward. +1000. a new random time chosen at cron start. We see this all the time, and it would be a lot better than the hacks for all the things "R" for random sounds good to me > > - todd >
Re: suggest to run rpki-client hourly
On Mon, 13 Apr 2020 09:37:14 -0600, "Theo de Raadt" wrote: > While I understand what RANDOM is trying to do, I am not a fan. I've > thought often of an improvement, where the minute marker in a crontab > file could be a letter 'R', which indicates the specific random value > for this cron start. That value would be selected at cron start, and > remain constant for the runtime of cron. I was thinking the same thing, but using '?' as the character. It doesn't really matter what we choose, the implementation should be straight-forward. - todd
Re: suggest to run rpki-client hourly
Reason I don't like 2048 is, 34.1 minutes, why why why. Should it not be 2047 or 2049? *cough* What's going on is here, is it should be 3600 - the maximum plausible runtime. But I'm still not thrilled changing the value there on it's own either. rpki-client itself shold probably self-protect to cope with 'long runtime', or lockups. This framework is simple, and probably too simple. In an large userbase, I suspect it becomes likely someone will eventually hit a multi-hour routing glitch, which will reuslt in multiple rpki-client stuck doing DNS resolution (and failing DNS resolutions, so they end up at different stages of syncronization) and partial downloads. The cache directory will be inconsistant. Then I think the multiple processes will all complete as a thundering horde. The file generation is designed to be atomic, but the parallel completion computation might be a problem. I think we should consider building some sort of self-watchdog mode into the rpki-client frontend.
Re: suggest to run rpki-client hourly
I also don't like 2048 value. Why 2048? Why a power of 2. A value passed on from ancestors? I think it should be picked more carefully to look like a 'safe window'.
Re: suggest to run rpki-client hourly
Claudio Jeker wrote: > I do not use the sleep RANDOM thing because I prefer to have rpki-client > run always at the same interval (1h) and I just selected a random minute > in the hour. While I understand what RANDOM is trying to do, I am not a fan. I've thought often of an improvement, where the minute marker in a crontab file could be a letter 'R', which indicates the specific random value for this cron start. That value would be selected at cron start, and remain constant for the runtime of cron. That provides the load-sharing benefits against the services. But it does not jitter all over the place, and also avoids this locking issue.
Re: suggest to run rpki-client hourly
On Mon, Apr 13, 2020 at 02:43:27PM +, Job Snijders wrote: > Hi, > > I'm reviewing some of the timers associated with the workings of the > end-to-end propagation from ROA to VRP. I think suggesting to run > rpki-client only once a day can make for needless brittleness. > > Running rpki-client just once a day also results in only making a rsync > fetch attempt once a day. If the connection can't be established because > of a transient network issue, the RP can easily end up going without > contact with the CA Publication Point for close to 48 hours. A lot of > CRLs appear to have expiration dates in the range of '24 hours'. > > I think attempting to contact a CA PP at least once an hour is more > appropriate for the various 24-48h sliding windows that are in play. > > Thoughts? OK? > > Kind regards, > > Job > > Index: crontab > === > RCS file: /cvs/src/etc/crontab,v > retrieving revision 1.25 > diff -u -p -r1.25 crontab > --- crontab 4 Dec 2019 15:07:51 - 1.25 > +++ crontab 13 Apr 2020 14:34:45 - > @@ -19,4 +19,4 @@ HOME=/var/log > 30 5 1 * * /bin/sh /etc/monthly > #0 * * * * sleep $((RANDOM \% 2048)) && > /usr/libexec/spamd-setup > > -#0 9 * * * -n sleep $((RANDOM \% 4096)) && > rpki-client -v && bgpctl reload > +#0 * * * * -n sleep $((RANDOM \% 4096)) && > rpki-client -v && bgpctl reload > I personally run rpki-client every hour and that works very well for me. I do not use the sleep RANDOM thing because I prefer to have rpki-client run always at the same interval (1h) and I just selected a random minute in the hour. -- :wq Claudio
Re: suggest to run rpki-client hourly
Stuart Henderson wrote: > > 30 5 1 * * /bin/sh /etc/monthly > > #0 * * * * sleep $((RANDOM \% 2048)) && > > /usr/libexec/spamd-setup > > > > -#0 9 * * * -n sleep $((RANDOM \% 4096)) && > > rpki-client -v && bgpctl reload > > +#0 * * * * -n sleep $((RANDOM \% 4096)) && > > rpki-client -v && bgpctl reload > > > > The max sleep value will definitely need to be lowered (4096 > 1 hour), > but it might also be necessary to add some locking to prevent multiple copies > running .. I hate it. I've always hated the sleep thing in cron also. It is so horrific. It sounds like rpki-client needs a long-running mode where it makes it's own decisions, without having to use cron in this way.
Re: suggest to run rpki-client hourly
> 30 5 1 * * /bin/sh /etc/monthly > #0 * * * * sleep $((RANDOM \% 2048)) && > /usr/libexec/spamd-setup > > -#0 9 * * * -n sleep $((RANDOM \% 4096)) && > rpki-client -v && bgpctl reload > +#0 * * * * -n sleep $((RANDOM \% 4096)) && > rpki-client -v && bgpctl reload > The max sleep value will definitely need to be lowered (4096 > 1 hour), but it might also be necessary to add some locking to prevent multiple copies running ..
Re: suggest to run rpki-client hourly
On Mon, Apr 13, 2020 at 02:43:27PM +, Job Snijders wrote: > I'm reviewing some of the timers associated with the workings of the > end-to-end propagation from ROA to VRP. I think suggesting to run > rpki-client only once a day can make for needless brittleness. > > Running rpki-client just once a day also results in only making a rsync > fetch attempt once a day. If the connection can't be established because > of a transient network issue, the RP can easily end up going without > contact with the CA Publication Point for close to 48 hours. A lot of > CRLs appear to have expiration dates in the range of '24 hours'. > > I think attempting to contact a CA PP at least once an hour is more > appropriate for the various 24-48h sliding windows that are in play. > > Thoughts? OK? Small update: if we go hourly we should jiggle RANDOM accordingly OK? Index: crontab === RCS file: /cvs/src/etc/crontab,v retrieving revision 1.25 diff -u -p -r1.25 crontab --- crontab 4 Dec 2019 15:07:51 - 1.25 +++ crontab 13 Apr 2020 14:48:06 - @@ -19,4 +19,4 @@ HOME=/var/log 30 5 1 * * /bin/sh /etc/monthly #0 * * * * sleep $((RANDOM \% 2048)) && /usr/libexec/spamd-setup -#0 9 * * * -n sleep $((RANDOM \% 4096)) && rpki-client -v && bgpctl reload +#0 * * * * -n sleep $((RANDOM \% 2048)) && rpki-client -v && bgpctl reload
cpu utilisation bars for top(1)
Hi,
One thing I miss from our top(1) is the ability to see overall CPU
utilisation at a glance (I usually scan for the idle percentage and
invert it in my head).
This diff adds a way to toggle (using `B`) CPU utilisation bars, like this:
```
load averages: 0.92, 0.52, 1.26 arrakis.home
15:31:14
110 processes: 108 idle, 1 stopped, 1 on processorup 1 day,
2:15
[]
37.1%
[# ]
45.0%
[]
42.8%
[### ]
47.2%
Memory: Real: 4399M/12G act/tot Free: 11G Cache: 6204M Swap: 0K/1028M
```
The value reported is the inverse of the idle percentage and the bars
replace the 'user, nice, sys, ...' lines.
Can also be enabled from the command line with `-B`.
What do people think?
(I know htop from ports does utilisation bars, but I prefer pretty much
everything else about our in-base top.)
Index: display.c
===
RCS file: /cvs/src/usr.bin/top/display.c,v
retrieving revision 1.61
diff -u -p -r1.61 display.c
--- display.c 27 Oct 2019 13:52:26 - 1.61
+++ display.c 13 Apr 2020 14:43:10 -
@@ -105,6 +105,7 @@ extern int combine_cpus;
extern struct process_select ps;
int header_status = true;
+int cpu_bars = false;
static int
empty(void)
@@ -382,6 +383,13 @@ i_cpustates(int64_t *ostates, int *onlin
double value;
int64_t *states;
char **names, *thisname;
+ char cpu_bar[MAX_COLS];
+ int hash_space = screen_width - 8; /* space for hash chars in bars */
+
+ /* this is used as an offset into cpu_bar and must never be negative */
+ if (hash_space < 0) {
+ hash_space = 0;
+ }
if (combine_cpus) {
static double *values;
@@ -438,18 +446,30 @@ i_cpustates(int64_t *ostates, int *onlin
if (screen_length > 2 + cpu_line || !smart_terminal) {
move(2 + cpu_line, 0);
clrtoeol();
- addstrp(cpustates_tag(cpu));
-
- while ((thisname = *names++) != NULL) {
- if (*thisname != '\0') {
- /* retrieve the value and remember it */
- value = *states++;
-
- /* if percentage is >= 1000, print it
as 100% */
- printwp((value >= 1000 ? "%s%4.0f%% %s"
:
- "%s%4.1f%% %s"), first++ == 0 ? ""
: ", ",
- value / 10., thisname);
+ if (!cpu_bars) {
+ addstrp(cpustates_tag(cpu));
+ while ((thisname = *names++) != NULL) {
+ if (*thisname != '\0') {
+ /* retrieve the value and
remember it */
+ value = *states++;
+
+ /* if percentage is >= 1000,
print it as 100% */
+ printwp((value >= 1000 ?
"%s%4.0f%% %s" :
+"%s%4.1f%% %s"),
first++ == 0 ? "" : ", ",
+ value / 10., thisname);
+ }
}
+ } else {
+ float idle_ratio = (states[5] >= 1000 ? 1000 :
states[5]) / 1000.;
+ int n_idle_chars = hash_space * idle_ratio;
+ int n_busy_chars = hash_space - n_idle_chars;
+
+ cpu_bar[0] = '[';
+ memset(cpu_bar + 1, '#', n_busy_chars);
+ memset(cpu_bar + 1 + n_busy_chars, ' ',
n_idle_chars);
+ snprintf(cpu_bar + hash_space, 9, "] %5.1f%%",
+ 100 - idle_ratio * 100);
+ printwp("%s", cpu_bar);
}
putn();
cpu_line++;
Index: top.1
===
RCS file: /cvs/src/usr.bin/top/top.1,v
retrieving revision 1.73
diff -u -p -r1.73 top.1
--- top.1 7 Jan 2020 13:30:43 - 1.73
+++ top.1 13 Apr 2020 14:43:10 -
@@ -90,6 +90,8 @@ and
.Ql ^\e )
still have an effect.
This is the default on a dumb terminal, or when the output is not a terminal.
+.It Fl B
+Show CPU utilisation bars instead of CPU states.
.It Fl C
suggest to run rpki-client hourly
Hi, I'm reviewing some of the timers associated with the workings of the end-to-end propagation from ROA to VRP. I think suggesting to run rpki-client only once a day can make for needless brittleness. Running rpki-client just once a day also results in only making a rsync fetch attempt once a day. If the connection can't be established because of a transient network issue, the RP can easily end up going without contact with the CA Publication Point for close to 48 hours. A lot of CRLs appear to have expiration dates in the range of '24 hours'. I think attempting to contact a CA PP at least once an hour is more appropriate for the various 24-48h sliding windows that are in play. Thoughts? OK? Kind regards, Job Index: crontab === RCS file: /cvs/src/etc/crontab,v retrieving revision 1.25 diff -u -p -r1.25 crontab --- crontab 4 Dec 2019 15:07:51 - 1.25 +++ crontab 13 Apr 2020 14:34:45 - @@ -19,4 +19,4 @@ HOME=/var/log 30 5 1 * * /bin/sh /etc/monthly #0 * * * * sleep $((RANDOM \% 2048)) && /usr/libexec/spamd-setup -#0 9 * * * -n sleep $((RANDOM \% 4096)) && rpki-client -v && bgpctl reload +#0 * * * * -n sleep $((RANDOM \% 4096)) && rpki-client -v && bgpctl reload
Re: [PATCH] dired-jump for mg
George Koehler writes:
> In emacs, if I visit /tmp/nowhere/new, but /tmp/nowhere doesn't exist,
> then C-x C-j shows an error:
> | Setting current directory: No such file or directory, /tmp/nowhere/
>
> In mg with your diff, if I do the same, then C-x C-j does nothing, and
> doesn't show an error. I would like to see an error. I don't need the
> exact same error message as emacs; but I want to know that mg got my
> command, and the command failed. (For people trying emacs, C-x C-j
> doesn't work until you load dired-x. An easy way to load dired-x is
> to visit any dir, then M-x dired-jump.)
Good catch, didn't think about that. Added an error message using
dobeep_msgs. See patch below.
--
Philip K.
? dired-jump.patch
cvs server: Diffing .
Index: def.h
===
RCS file: /cvs/src/usr.bin/mg/def.h,v
retrieving revision 1.166
diff -u -r1.166 def.h
--- def.h 9 Feb 2020 10:13:13 - 1.166
+++ def.h 13 Apr 2020 11:34:18 -
@@ -361,6 +361,7 @@
/* dired.c */
struct buffer *dired_(char *);
+int dired_jump(int, int);
int do_dired(char *);
/* file.c X */
Index: dired.c
===
RCS file: /cvs/src/usr.bin/mg/dired.c,v
retrieving revision 1.93
diff -u -r1.93 dired.c
--- dired.c 11 Jul 2019 18:20:18 - 1.93
+++ dired.c 13 Apr 2020 11:34:18 -
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -53,6 +54,7 @@
static int d_filevisitalt(int, int);
static int d_gotofile(int, int);
static void reaper(int);
+static int gotofile(char*);
static struct buffer *refreshbuffer(struct buffer *);
static int createlist(struct buffer *);
static void redelete(struct buffer *);
@@ -205,6 +207,7 @@
dired_init(void)
{
funmap_add(dired, "dired", 1);
+ funmap_add(dired_jump, "dired-jump", 1);
funmap_add(d_create_directory, "dired-create-directory", 1);
funmap_add(d_copy, "dired-do-copy", 1);
funmap_add(d_expunge, "dired-do-flagged-delete", 0);
@@ -257,6 +260,40 @@
/* ARGSUSED */
int
+dired_jump(int f, int n)
+{
+ char dname[NFILEN], base[NFILEN], *fname;
+ struct buffer *bp;
+ intlen, ret;
+
+ if (getbufcwd(dname, sizeof(dname)) != TRUE)
+ return (FALSE);
+
+ fname = curbp->b_fname;
+
+ if ((bp = dired_(dname)) == FALSE) {
+ ewprintf("Cannot find directory: %s", dname);
+ return (FALSE);
+ }
+ curbp = bp;
+
+ ret = showbuffer(bp, curwp, WFFULL | WFMODE);
+ if (ret != (TRUE))
+ return ret;
+
+ if (fname[0]) {
+ len = strlen(fname);
+ if (fname[len-1] != '/') {
+ (void) xbasename(base, fname, NFILEN);
+ gotofile(base);
+ }
+ }
+
+ return (TRUE);
+}
+
+/* ARGSUSED */
+int
d_otherwindow(int f, int n)
{
char dname[NFILEN], *bufp, *slash;
@@ -1079,35 +1116,15 @@
}
int
-d_gotofile(int f, int n)
+gotofile(char *fname)
{
struct line *lp, *nlp;
- struct buffer *curbp;
- size_t lenfpath;
- char fpath[NFILEN], fname[NFILEN];
- char *p, *fpth, *fnp = NULL;
+ char *p;
int tmp;
- if (getbufcwd(fpath, sizeof(fpath)) != TRUE)
- fpath[0] = '\0';
- lenfpath = strlen(fpath);
- fnp = eread("Goto file: ", fpath, NFILEN,
- EFNEW | EFCR | EFFILE | EFDEF);
- if (fnp == NULL)
- return (ABORT);
- else if (fnp[0] == '\0')
- return (FALSE);
-
- fpth = adjustname(fpath, TRUE); /* Removes last '/' if */
- if (strlen(fpth) == lenfpath - 1) { /* directory, hence -1. */
- ewprintf("No file to find"); /* Current directory given so */
- return (TRUE); /* return at present location. */
- }
- (void)xbasename(fname, fpth, NFILEN);
- curbp = curwp->w_bufp;
tmp = 0;
- for (lp = bfirstlp(curbp); lp != curbp->b_headp; lp = nlp) {
- tmp++;
+ for (lp = bfirstlp(curbp); lp != curbp->b_headp; lp = nlp) {
+ tmp++;
if ((p = findfname(lp, p)) == NULL) {
nlp = lforw(lp);
continue;
@@ -1128,6 +1145,34 @@
ewprintf("");
return (TRUE);
}
+}
+
+int
+d_gotofile(int f, int n)
+{
+ size_t lenfpath;
+ char fpath[NFILEN], fname[NFILEN];
+ char *fpth, *fnp = NULL;
+
+ if (getbufcwd(fpath, sizeof(fpath)) != TRUE)
+ fpath[0] = '\0';
+ lenfpath = strlen(fpath);
+ fnp = eread("Goto file: ", fpath, NFILEN,
+ EFNEW | EFCR | EFFILE | EFDEF);
+ if (fnp == NULL)
+ return (ABORT);
+ else if (fnp[0] == '\0')
+ return (FALSE);
+
+ fpth = adjustname(fpath, TRUE); /* Removes last '/' if */
+ if (strlen(fpth) == lenfpath - 1) { /* directory, hence -1. */
+ ewprintf("No file to find"); /* Current directory given so */
+ return (TRUE); /* return at present location. */
+ }
+ (void)xbasename(fname, fpth, NFILEN);
+ curbp = curwp->w_bufp;
+
+ return gotofile(fname);
}
/*
Index: keymap.c
===
RCS file: /cvs/src/usr.bin/mg/keymap.c,v
retrieving revision 1.58
diff -u -r1.58 keymap.c
--- keymap.c 29 Dec 2015 19:44:32 - 1.58
+++ keymap.c 13 Apr 2020 11:34:18 -
@@ -129,6 +129,10 @@
ctrlg /* ^G */
};
+static PF cXcJ[] =
Re: simplepanel(4) man page stub
On Sun, Apr 05, 2020 at 03:24:30PM +0200, Marcus MERIGHI wrote: > Hello, > > reading plus.html I noticed that the link to simplepanel(4) was a dead > end. > > below is my attempt at a stub man page with what I could gather from > plus.html and the commit log. > > Marcus > hi. thanks for the diff - i've committed a tweaked version. jmc > --- /dev/null Sun Apr 5 15:13:10 2020 > +++ src/share/man/man4/simplepanel.4 Sun Apr 5 15:08:52 2020 > @@ -0,0 +1,38 @@ > +.\" Copyright (c) 2020 Patrick Wildt > +.\" > +.\" Permission to use, copy, modify, and distribute this software for any > +.\" purpose with or without fee is hereby granted, provided that the above > +.\" copyright notice and this permission notice appear in all copies. > +.\" > +.\" THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES > +.\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF > +.\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR > +.\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES > +.\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN > +.\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF > +.\" OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. > +.\" > +.Dd $Mdocdate: April 5 2020 $ > +.Dt SIMPLEPANEL 4 > +.Os > +.Sh NAME > +.Nm simplepanel > +.Nd simple panel display > +.Sh SYNOPSIS > +.Cd "simplepanel* at mainbus?" > +.Sh DESCRIPTION > +The > +.Nm > +driver enables the Pinebook Pro display panel. > +.Sh SEE ALSO > +.Xr mainbus 4 > +.Sh HISTORY > +The > +.Nm > +driver first appeared in > +.Ox 6.7 > +.Sh AUTHORS > +The > +.Nm > +driver was written by > +.An Patrick Wildt Aq Mt patr...@openbsd.org . >
ipsec(4)/iked(8): separate rdomains for encrypted/unecrypted traffic
Hi,
the diff below adds a new feature that allows the use of separate rdomains
for the encrypted and unencrypted side of ipsec(4) flows.
The idea is that an edge router that controls access to a private network
via ipsec can have its uplink in one rdomain and the private network in
another. The kernel automatically moves successfully encrypted/decrypted
packets to the respective rdomain. The outer (uplink) rdomain only ever sees
encrypted packets, which could add another layer of protection against side
channel leak attacks that we have seen in the past.
The feature can be configured in iked(8) with the new 'rdomain $NUMBER'
option (see iked.conf(5)). Only the inner (unencrypted) rdomain has to
be configured, the outer rdomain is always the one the iked instance
is running in. For this to work, the inner rdomain must exist
(have at least one interface assigned) and have an enc(4) interface
assigned before starting iked.
The resulting flows and the outgoing SA are visible from the inner
rdomain only, so don't forget to 'route -T $ID exec' ipsecctl.
The incoming SA is visible from the outer rdomain. tcpdump works
as usual on the enc(4) interface of the inner rdomain.
Thanks to markus@ who did a lot of the work on this.
Comments and tests welcome ;)
diff --git a/sbin/iked/iked.conf.5 b/sbin/iked/iked.conf.5
index b0128610c81..980fa66952c 100644
--- a/sbin/iked/iked.conf.5
+++ b/sbin/iked/iked.conf.5
@@ -311,6 +311,18 @@ For a list of all the protocol name to number mappings
used by
.Xr iked 8 ,
see the file
.Pa /etc/protocols .
+.It Ic rdomain Ar number
+Specify a different routing domain for unencrypted traffic.
+The resulting IPsec SAs will match outgoing packets in the specified
+.Ic rdomain Ar number
+and move the encrypted packets to the rdomain the
+.Xr iked 8
+instance is running in.
+Vice versa, incoming
+.Xr ipsec 4
+traffic is moved to
+.Ic rdomain Ar number
+after decryption.
.It Xo
.Ic from Ar src
.Op Ic port Ar sport
diff --git a/sbin/iked/iked.h b/sbin/iked/iked.h
index 598e82d0157..203f34d637c 100644
--- a/sbin/iked/iked.h
+++ b/sbin/iked/iked.h
@@ -151,6 +151,7 @@ struct iked_flow {
struct iked_addr flow_src;
struct iked_addr flow_dst;
unsigned int flow_dir; /* in/out */
+ int flow_rdomain;
struct iked_addr flow_prenat;
unsigned int flow_loaded; /* pfkey done */
@@ -261,6 +262,7 @@ struct iked_policy {
uint8_t pol_certreqtype;
int pol_af;
+ int pol_rdomain;
uint8_t pol_saproto;
unsigned int pol_ipproto;
diff --git a/sbin/iked/ikev2.c b/sbin/iked/ikev2.c
index 4074ea549b8..4d960a60342 100644
--- a/sbin/iked/ikev2.c
+++ b/sbin/iked/ikev2.c
@@ -5371,6 +5371,7 @@ ikev2_childsa_negotiate(struct iked *env, struct iked_sa
*sa,
flowa->flow_dir = IPSP_DIRECTION_OUT;
flowa->flow_saproto = ic ? IKEV2_SAPROTO_IPCOMP :
prop->prop_protoid;
+ flowa->flow_rdomain = sa->sa_policy->pol_rdomain;
flowa->flow_local = &sa->sa_local;
flowa->flow_peer = &sa->sa_peer;
flowa->flow_ikesa = sa;
@@ -6440,7 +6441,7 @@ ikev2_info_flow(struct iked *env, int dolog, const char
*msg, struct iked_flow *
int buflen;
buflen = asprintf(&buf,
- "%s: %p %s %s %s/%d -> %s/%d [%u] (%s) @%p\n", msg, flow,
+ "%s: %p %s %s %s/%d -> %s/%d [%u]@%d (%s) @%p\n", msg, flow,
print_map(flow->flow_saproto, ikev2_saproto_map),
flow->flow_dir == IPSP_DIRECTION_IN ? "in" : "out",
print_host((struct sockaddr *)&flow->flow_src.addr, NULL, 0),
@@ -6448,6 +6449,7 @@ ikev2_info_flow(struct iked *env, int dolog, const char
*msg, struct iked_flow *
print_host((struct sockaddr *)&flow->flow_dst.addr, NULL, 0),
flow->flow_dst.addr_mask,
flow->flow_ipproto,
+ flow->flow_rdomain,
flow->flow_loaded ? "L" : "",
flow->flow_ikesa);
diff --git a/sbin/iked/parse.y b/sbin/iked/parse.y
index 38c07b95de2..bb578d45399 100644
--- a/sbin/iked/parse.y
+++ b/sbin/iked/parse.y
@@ -351,7 +351,8 @@ void copy_transforms(unsigned int,
const struct ipsec_xf **, unsigned int,
struct iked_transform **, unsigned int *,
struct iked_transform *, size_t);
-int create_ike(char *, int, uint8_t, struct ipsec_hosts *,
+int create_ike(char *, int, uint8_t,
+ int, struct ipsec_hosts *,
struct ipsec_hosts *, struct ips
tcpdump: print nhrp packets
Hi,
I recently looked into NHRP (RFC 2332) and noticed that our tcpdump does
not have a printer for it. So I added support for NHRP to tcpdump.
Initially I was surprised: I expected a simpler protocol! But it is from
the 90's with all the protocols from then in mind (frame relay, ATM, ...).
I tested with public available pcap files and compared the output with
wirshark.
https://packetlife.net/captures/protocol/nhrp/
https://www.networkingwithfish.com/fun-in-the-lab-sniffer-tracing-a-dmvpn-tunnel-startup/
The output looks like this:
08:34:45.647483 172.16.25.2 > 172.16.15.2: gre NHRP: reg request, id 7 [tos
0xc0]
08:34:45.671422 172.16.15.2 > 172.16.25.2: gre NHRP: reg reply, id 7 [tos 0xc0]
08:47:16.138679 172.16.15.2 > 172.16.25.2: gre NHRP: res request, id 6 [tos
0xc0]
08:47:16.148863 172.16.25.2 > 172.16.15.2: gre NHRP: res reply, id 6 [tos 0xc0]
With -v set:
08:34:45.647483 172.16.25.2 > 172.16.15.2: gre [] 2001 NHRP: reg request, id 7,
hopcnt 255, src nbma 172.16.25.2, 192.168.0.2 -> 192.168.0.1 (code 0, pl 255,
mtu 1514, htime 7200, pref 0) [tos 0xc0] (ttl 254, id 22, len 116)
08:34:45.671422 172.16.15.2 > 172.16.25.2: gre [] 2001 NHRP: reg reply, id 7,
hopcnt 255, src nbma 172.16.25.2, 192.168.0.2 -> 192.168.0.1 (code 0, pl 255,
mtu 1514, htime 7200, pref 0) [tos 0xc0] (ttl 255, id 7, len 136)
08:47:16.138679 172.16.15.2 > 172.16.25.2: gre [] 2001 NHRP: res request, id 6,
hopcnt 254, src nbma 172.16.45.2, 192.168.0.4 -> 192.168.0.2 (code 0, pl 0, mtu
1514, htime 7200, pref 0) [tos 0xc0] (ttl 254, id 20, len 116)
08:47:16.148863 172.16.25.2 > 172.16.15.2: gre [] 2001 NHRP: res reply, id 6,
hopcnt 255, src nbma 172.16.45.2, 192.168.0.4 -> 192.168.0.2 (code 0, pl 32,
mtu 1514, htime 7199, pref 0, nbma 172.16.25.2, proto 192.168.0.2) [tos 0xc0]
(ttl 255, id 31, len 144)
Extensions are not parsed and printed.
It would be nice to get pcaps with expamles that use address or protocol
combinations other than GRE and IPv4.
Comments, OKs?
Remi
Index: Makefile
===
RCS file: /cvs/src/usr.sbin/tcpdump/Makefile,v
retrieving revision 1.64
diff -u -p -r1.64 Makefile
--- Makefile3 Dec 2019 01:43:33 - 1.64
+++ Makefile28 Mar 2020 17:07:22 -
@@ -48,7 +48,7 @@ SRCS= tcpdump.c addrtoname.c privsep.c p
print-bgp.c print-ospf6.c print-ripng.c print-rt6.c print-stp.c \
print-etherip.c print-lwres.c print-lldp.c print-cdp.c print-pflog.c \
print-pfsync.c pf_print_state.c print-ofp.c ofp_map.c \
- print-udpencap.c print-carp.c \
+ print-udpencap.c print-carp.c print-nhrp.c \
print-802_11.c print-iapp.c print-mpls.c print-slow.c print-usbpcap.c \
gmt2local.c savestr.c setsignal.c in_cksum.c
Index: interface.h
===
RCS file: /cvs/src/usr.sbin/tcpdump/interface.h,v
retrieving revision 1.83
diff -u -p -r1.83 interface.h
--- interface.h 3 Dec 2019 01:43:33 - 1.83
+++ interface.h 28 Mar 2020 17:07:22 -
@@ -217,6 +217,7 @@ extern void ppp_ether_if_print(u_char *,
extern void gre_print(const u_char *, u_int);
extern void vxlan_print(const u_char *, u_int);
extern void nsh_print(const u_char *, u_int);
+extern void nhrp_print(const u_char *, u_int);
extern void icmp_print(const u_char *, u_int, const u_char *);
extern void ieee802_11_if_print(u_char *, const struct pcap_pkthdr *,
const u_char *);
Index: print-ether.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/print-ether.c,v
retrieving revision 1.37
diff -u -p -r1.37 print-ether.c
--- print-ether.c 24 Jan 2020 22:46:36 - 1.37
+++ print-ether.c 28 Mar 2020 17:07:22 -
@@ -303,6 +303,13 @@ recurse:
ether_pbb_print(p, length, caplen);
return (1);
+#ifndef ETHERTYPE_NHRP
+#define ETHERTYPE_NHRP 0x2001
+#endif
+ case ETHERTYPE_NHRP:
+ nhrp_print(p, length);
+ return (1);
+
#ifdef PPP
case ETHERTYPE_PPPOEDISC:
case ETHERTYPE_PPPOE:
Index: print-gre.c
===
RCS file: /cvs/src/usr.sbin/tcpdump/print-gre.c,v
retrieving revision 1.30
diff -u -p -r1.30 print-gre.c
--- print-gre.c 24 Jan 2020 22:46:36 - 1.30
+++ print-gre.c 28 Mar 2020 17:07:22 -
@@ -289,6 +289,12 @@ gre_print_0(const u_char *p, u_int lengt
case 0x2000:
cdp_print(p, length, l, 0);
break;
+#ifndef ETHERTYPE_NHRP
+#define ETHERTYPE_NHRP 0x2001
+#endif
+ case ETHERTYPE_NHRP:
+ nhrp_print(p, length);
+ break;
default:
printf("unknown-proto-%04x", proto);
}
Index: print-nhrp.c
===
RCS file: print-nhrp.c
diff -N print-nhrp.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ print-nhrp
Re: sysupgrade: add BUILDINFO file to fetched files
Hi, Would below be okay? On Tue, Apr 07, 2020 at 04:46:38AM +, Mikolaj Kucharski wrote: > Hi, > > When I'm upgrading my machines, I find it useful to have BUILDINFO > file around. Tested on RPi3. > > Please carbon-copy me in any replies. Thank you. > > openbsd-rpi# sysupgrade -s -n > Fetching from https://cdn.openbsd.org/pub/OpenBSD/snapshots/arm64/ > SHA256.sig 100% |**| 1453 00:00 > Signature Verified > Verifying old sets. > BUILDINFO100% |**|54 00:00 > Verifying sets. > Fetching updated firmware. > Will upgrade on next reboot > > openbsd-rpi# reboot > ... [successfull upgrade] > openbsd-rpi# ls -1A /home/_sysupgrade/ | wc -l >0 > > > OpenBSD 6.6-current (GENERIC.MP) #513: Wed Mar 18 16:41:35 MDT 2020 > dera...@arm64.openbsd.org:/usr/src/sys/arch/arm64/compile/GENERIC.MP > > > Index: sysupgrade.sh > === > RCS file: /cvs/src/usr.sbin/sysupgrade/sysupgrade.sh,v > retrieving revision 1.37 > diff -u -p -u -r1.37 sysupgrade.sh > --- sysupgrade.sh 26 Jan 2020 22:08:36 - 1.37 > +++ sysupgrade.sh 20 Mar 2020 06:30:51 - > @@ -152,9 +152,9 @@ if cmp -s /var/db/installed.SHA256 SHA25 > exit 0 > fi > > -# INSTALL.*, bsd*, *.tgz > +# BUILDINFO, INSTALL.*, bsd*, *.tgz > SETS=$(sed -n -e 's/^SHA256 (\(.*\)) .*/\1/' \ > --e '/^INSTALL\./p;/^bsd/p;/\.tgz$/p' SHA256) > +-e '/^BUILDINFO$/p;/^INSTALL\./p;/^bsd/p;/\.tgz$/p' SHA256) > > OLD_FILES=$(ls) > OLD_FILES=$(rmel SHA256 $OLD_FILES) > -- Regards, Mikolaj
