Anyone have a summary of what kernel option RSS does ? / netisr oddness .

2018-06-22 Thread Mark Saad
Hi all
 On a recount 11-STABLE I see that the interaction with netisr and rss has 
changed. Forgive me if this is clumsy but I don’t quite get what changes were.

On 10-Stable when I have a solarflare or intel Ixgbe card I would get a kernel 
thread per rss queue per card and a netirs queue:bucket thread per cpu ( or 
tuned to a value I define < ncpus ) . However on recent 11-STABLE about when 
the RSS kernel option was imported or added; I now get one netisr queue:bucket 
for the whole system and no tuning effects how many threads are created.  

Second part I started looking into the kernel rss option and I wanted the 
better understand what it was doing ?  Enabling it and the associate protocol 
block ? Option gave me 64 queues and no clear way to tune them or constrain 
them to the numa domain of the card companies consuming them I could not find 
options_rss.h either .  So is there a commit anyone can direct me to to for 
more insight? Is there a write up on it somewhere? 

Thanks again . 

---
Mark Saad | nones...@longcount.org
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: ATI video problem - slow desktop - 100% cpu load [semi-solved]

2018-06-22 Thread Mark Saad
Vincent
  I used the scfb driver in openbsd land for a work project . Currently I am 
using 11-STABLE with the Radeon driver but at one point I had a different card 
under 11.0 that didn’t work unless I used the scfb driver . 

---
Mark Saad | nones...@longcount.org

> On Jun 21, 2018, at 11:41 PM, Carl Johnson  wrote:
> 
> Vincent Stemen  writes:
> 
>> You must load radeonkms.ko after the system is fully booted.
>> 
>># kldload radeonkms
>> 
>> That automatically loads the other 3 modules and initializes the console 
>> where
>> the console text goes into higher resolution mode.  Then X and the desktop
>> environments work and seem to be fully functional, including transparency, 
>> etc.
>> 
>> So I can either put it in /etc/rc.local, to be run at boot time, or put it in
>> an X startup script wrapper.  Note that it must be run prior to startx 
>> because
>> it must be loaded before launching the X server.  So it cannot be put in
>> ~/.xinitrc.
> 
> Have you tried loading it with kld_list in /etc/rc.conf?  Those get
> loaded during boot, but it might be late enough to work.  That would be
> automated, so it might be a little more convenient.
> -- 
> Carl Johnsonca...@peak.org
> 
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: jail related inconsistencies in FreeBSD tools parameters

2018-06-22 Thread Miroslav Lachman

Chris H wrote on 2018/06/22 23:46:
On Fri, 22 Jun 2018 23:13:17 +0200 "Miroslav Lachman" <000.f...@quip.cz> 
said


I don't know if it is better to discuss it in jail@ or stable@ list so 
a do cross-post.


FreeBSD has many jail aware utilities but they are inconsistent in 
taking JID as parameter.


For example "sockstat" takes -j JID "Show only sockets belonging to 
the specified jail ID" and it means numeric ID only.
On the other hand "ps" takes -J JID "This may be either the jid or 
name of the jail.  Use -J 0 to display only host processes."
The same apply for "top", it understands jid as a number or name of 
the jail too.

Then again "cpuset" takes only numerical ID of the jail...

Shouldn't it be consistent across all FreeBSD base utilities so all of 
them can use numerical ID and name?

Good idea! Are you offering to create a patch? ;-)
It'd be my guess that given they weren't all created at the same time, nor
the same individual; that (quite probably?) the "jail" additions were also
added at different times, and by different people. So I'd imagine that
unless someone with a commit bit decides one day they'd like to take that
on. Someone(tm) maybe you? will need to propose a patch. :-)


If I can understand C sources I will create the patch by myself instead 
of just posting here. Unfortunately I am able to code in sh, php and a 
bit of javascript and perl but no C. :)


Miroslav Lachman
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: jail related inconsistencies in FreeBSD tools parameters

2018-06-22 Thread Chris H

On Fri, 22 Jun 2018 23:13:17 +0200 "Miroslav Lachman" <000.f...@quip.cz> said

I don't know if it is better to discuss it in jail@ or stable@ list so a 
do cross-post.


FreeBSD has many jail aware utilities but they are inconsistent in 
taking JID as parameter.


For example "sockstat" takes -j JID "Show only sockets belonging to the 
specified jail ID" and it means numeric ID only.
On the other hand "ps" takes -J JID "This may be either the jid or name 
of the jail.  Use -J 0 to display only host processes."
The same apply for "top", it understands jid as a number or name of the 
jail too.

Then again "cpuset" takes only numerical ID of the jail...

Shouldn't it be consistent across all FreeBSD base utilities so all of 
them can use numerical ID and name?

Good idea! Are you offering to create a patch? ;-)
It'd be my guess that given they weren't all created at the same time, nor
the same individual; that (quite probably?) the "jail" additions were also
added at different times, and by different people. So I'd imagine that
unless someone with a commit bit decides one day they'd like to take that
on. Someone(tm) maybe you? will need to propose a patch. :-)

--Chris


Should I file a PR for it?

Miroslav Lachman

PS: I am on FreeBSD 10.4 so I don't know if something is different in 
newer branches

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"



___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


jail related inconsistencies in FreeBSD tools parameters

2018-06-22 Thread Miroslav Lachman
I don't know if it is better to discuss it in jail@ or stable@ list so a 
do cross-post.


FreeBSD has many jail aware utilities but they are inconsistent in 
taking JID as parameter.


For example "sockstat" takes -j JID "Show only sockets belonging to the 
specified jail ID" and it means numeric ID only.
On the other hand "ps" takes -J JID "This may be either the jid or name 
of the jail.  Use -J 0 to display only host processes."
The same apply for "top", it understands jid as a number or name of the 
jail too.

Then again "cpuset" takes only numerical ID of the jail...

Shouldn't it be consistent across all FreeBSD base utilities so all of 
them can use numerical ID and name?


Should I file a PR for it?

Miroslav Lachman

PS: I am on FreeBSD 10.4 so I don't know if something is different in 
newer branches

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: py-fail2ban turned silent after syslogd rollout (r335059, stable/11)

2018-06-22 Thread Ed Schouten
Hi Michael, Marek,

2018-06-22 22:48 GMT+02:00 Marek Zarychta :
> Patch compiles fine and I can confirm, that it resolves the issue.

Thanks for testing to both of you. Really appreciated.

I've just committed this patch as r335565. As it is a bit more
intrusive than the previous patch I wrote, let's give this a week to
settle in HEAD before merging it to 11-STABLE. I'll close PR 229236
once it's been merged.

-- 
Ed Schouten 
Nuxi, 's-Hertogenbosch, the Netherlands
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: Console is broken after updating to 11.2-RELEASE

2018-06-22 Thread Rick Macklem
Chris H wrote:
[stuff snipped]
>>
>> Thank you for information. I added above lines to /boot/loader.conf
>> and rebooted system. Then all boot messages are displayed and console
>> works fine!
>
>WooHoo! :-)
>
>I could make further observations based on *why* that worked. But several
>are likely, and I don't have enough info on your hardware. But now that
>you are no longer "blind". You should have little trouble sorting out the
>cause.
I have no idea if this helps, but running a fairly recent head kernel, when I 
would
switch virtual consoles, the screen would go blank until I power cycled the SVGA
monitor.
I switched to "sc" and the problem went away.
(This is an old Pentium 4 with what dmesg calls a "Generic VGA display".)

I don't see the same problem with a laptop of the same era.

Just in case it gives you a hint w.r.t. the problem, rick
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: py-fail2ban turned silent after syslogd rollout (r335059, stable/11)

2018-06-22 Thread Marek Zarychta
On Fri, Jun 22, 2018 at 09:11:06PM +0200, Ed Schouten wrote:
> Hi Marek,
> 
> [ +glebius ]
> 
> Thanks for reporting this!
> 
> 2018-06-22 18:54 GMT+02:00 Michael Grimm :
> >> Failed to parse TIMESTAMP from x.x.x.x: 12403: Jun 22 17:31:38 CEST:
> >> %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/17,
> >> changed state to down
> >
> > Ah, yes! Haven't thought about running syslogd in debugging mode:
> >
> > Failed to parse TIMESTAMP from x.x.x.x: fail2ban.filter [79598]: 
> > INFO […]
> 
> This is interesting. As fail2ban uses Python's logging framework, I
> managed to reproduce this with the following script:
> 
> #!/usr/bin/env python3
> import logging.handlers
> logging.basicConfig(handlers=[
> logging.handlers.SysLogHandler(
> '/var/run/log', facility=logging.handlers.SysLogHandler.LOG_LOCAL7)
> ])
> logging.warning('Hi')
> 
> This will write the following message to syslogd:
> 
> sendto(3,"<188>WARNING:root:Hi\0",21,0,NULL,0)   = 21 (0x15)
> 
> This message gets rejected by syslogd, due to the change made in
> r326573, which later got adjusted by me and subsequently MFCed:
> 
> https://svnweb.freebsd.org/base?view=revision=326573
> 
> Gleb, what are your thoughts on the attached patch? It alters syslogd
> to let the 'legacy' RFC 3164 parser also accept messages without a
> timestamp. The time on the syslogd server will be used instead.
> 
> Michael, Marek, could you please give this patch a try? Thanks!
> 
Hi Ed,

Thank you for expedited effort.
Patch compiles fine and I can confirm, that it resolves the issue.

-- 
Marek Zarychta


signature.asc
Description: PGP signature


Re: py-fail2ban turned silent after syslogd rollout (r335059, stable/11)

2018-06-22 Thread Michael Grimm
On 22. Jun 2018, at 22:28, Ed Schouten  wrote:
> 2018-06-22 22:06 GMT+02:00 Michael Grimm :

>> After applying your patch:
>>Jun 22 21:22:01 HOSTNAME  [31033]: NOTICE [JAILNAME] 
>> Unban x.x.x.x
>> 
>> Watch: 'fail2ban.actions' -the service- is missing.
> 
> That's likely due to the fact that it now interprets the first word in
> the message as the remote hostname, which gets discarded.
> 
> Attached is a somewhat refined patch that only tries to parse the
> hostname in remote messages if they are preceded by a timestamp. If
> the timestamp is missing, it assumes the entire payload is the
> message. Can you give this one a try? Thanks!

Great, you fixed it again in very short time, and I really do appreciate this!

Now with patch v2:
Jun 22 22:39:59 HOSTNAME  fail2ban.actions [72605]: 
NOTICE [JAILNAME] Restore Ban x.x.x.x

Thank you very, very much,
Michael

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: py-fail2ban turned silent after syslogd rollout (r335059, stable/11)

2018-06-22 Thread Ed Schouten
Hi Michael,

2018-06-22 22:06 GMT+02:00 Michael Grimm :
> After applying your patch:
> Jun 22 21:22:01 HOSTNAME  [31033]: NOTICE [JAILNAME] 
> Unban x.x.x.x
>
> Watch: 'fail2ban.actions' -the service- is missing.

That's likely due to the fact that it now interprets the first word in
the message as the remote hostname, which gets discarded.

Attached is a somewhat refined patch that only tries to parse the
hostname in remote messages if they are preceded by a timestamp. If
the timestamp is missing, it assumes the entire payload is the
message. Can you give this one a try? Thanks!

-- 
Ed Schouten 
Nuxi, 's-Hertogenbosch, the Netherlands


syslogd-optional-timestamp-v2.diff
Description: Binary data
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: py-fail2ban turned silent after syslogd rollout (r335059, stable/11)

2018-06-22 Thread Gleb Smirnoff
  Hi Ed,

On Fri, Jun 22, 2018 at 09:11:06PM +0200, Ed Schouten wrote:
E> > Ah, yes! Haven't thought about running syslogd in debugging mode:
E> >
E> > Failed to parse TIMESTAMP from x.x.x.x: fail2ban.filter [79598]: 
INFO […]
E> 
E> This is interesting. As fail2ban uses Python's logging framework, I
E> managed to reproduce this with the following script:
E> 
E> #!/usr/bin/env python3
E> import logging.handlers
E> logging.basicConfig(handlers=[
E> logging.handlers.SysLogHandler(
E> '/var/run/log', facility=logging.handlers.SysLogHandler.LOG_LOCAL7)
E> ])
E> logging.warning('Hi')
E> 
E> This will write the following message to syslogd:
E> 
E> sendto(3,"<188>WARNING:root:Hi\0",21,0,NULL,0)   = 21 (0x15)
E> 
E> This message gets rejected by syslogd, due to the change made in
E> r326573, which later got adjusted by me and subsequently MFCed:
E> 
E> https://svnweb.freebsd.org/base?view=revision=326573
E> 
E> Gleb, what are your thoughts on the attached patch? It alters syslogd
E> to let the 'legacy' RFC 3164 parser also accept messages without a
E> timestamp. The time on the syslogd server will be used instead.
E> 
E> Michael, Marek, could you please give this patch a try? Thanks!

I didn't examine the patch thoroughly, but I agree that looks like
we have no other choice as to support the legacy and normal messages
at the same time.

-- 
Gleb Smirnoff
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: py-fail2ban turned silent after syslogd rollout (r335059, stable/11)

2018-06-22 Thread Michael Grimm
On 22. Jun 2018, at 21:26, Michael Grimm  wrote:
> On 22. Jun 2018, at 21:11, Ed Schouten  wrote:

>> Michael, Marek, could you please give this patch a try? Thanks!
> 
> Recompiled world (FreeBSD 11.2-STABLE r335532), substituted syslogd with the 
> re-compiled one, and:
> 
> Thank you! Your patch is working w.r.t. fail2ban logging to SYSLOG. Perfect!

Now I realised that there is a minor glitch:

logfile+logger:
Jun 22 19:01:48 HOSTNAME  fail2ban.filter: 2018-06-22 
19:01:48,637 fail2ban.actions[85544]: NOTICE  [JAILNAME] Unban x.x.x.x

Old syslogd before MFC:
May 30 15:39:41  HOSTNAME fail2ban.actions [929]: NOTICE 
[JAILNAME] Unban x.x.x.x

After applying your patch:
Jun 22 21:22:01 HOSTNAME  [31033]: NOTICE [JAILNAME] 
Unban x.x.x.x

Watch: 'fail2ban.actions' -the service- is missing.

Regards,
Michael

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: py-fail2ban turned silent after syslogd rollout (r335059, stable/11)

2018-06-22 Thread Michael Grimm
On 22. Jun 2018, at 21:11, Ed Schouten  wrote:

> Gleb, what are your thoughts on the attached patch? It alters syslogd
> to let the 'legacy' RFC 3164 parser also accept messages without a
> timestamp. The time on the syslogd server will be used instead.
> 
> Michael, Marek, could you please give this patch a try? Thanks!

Recompiled world (FreeBSD 11.2-STABLE r335532), substituted syslogd with the 
re-compiled one, and:

Thank you! Your patch is working w.r.t. fail2ban logging to SYSLOG. Perfect!

Thank you very much for this fast fix, and regards,
Michael


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: py-fail2ban turned silent after syslogd rollout (r335059, stable/11)

2018-06-22 Thread Ed Schouten
Hi Marek,

[ +glebius ]

Thanks for reporting this!

2018-06-22 18:54 GMT+02:00 Michael Grimm :
>> Failed to parse TIMESTAMP from x.x.x.x: 12403: Jun 22 17:31:38 CEST:
>> %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/17,
>> changed state to down
>
> Ah, yes! Haven't thought about running syslogd in debugging mode:
>
> Failed to parse TIMESTAMP from x.x.x.x: fail2ban.filter [79598]: INFO 
> […]

This is interesting. As fail2ban uses Python's logging framework, I
managed to reproduce this with the following script:

#!/usr/bin/env python3
import logging.handlers
logging.basicConfig(handlers=[
logging.handlers.SysLogHandler(
'/var/run/log', facility=logging.handlers.SysLogHandler.LOG_LOCAL7)
])
logging.warning('Hi')

This will write the following message to syslogd:

sendto(3,"<188>WARNING:root:Hi\0",21,0,NULL,0)   = 21 (0x15)

This message gets rejected by syslogd, due to the change made in
r326573, which later got adjusted by me and subsequently MFCed:

https://svnweb.freebsd.org/base?view=revision=326573

Gleb, what are your thoughts on the attached patch? It alters syslogd
to let the 'legacy' RFC 3164 parser also accept messages without a
timestamp. The time on the syslogd server will be used instead.

Michael, Marek, could you please give this patch a try? Thanks!

-- 
Ed Schouten 
Nuxi, 's-Hertogenbosch, the Netherlands
Index: usr.sbin/syslogd/syslogd.c
===
--- usr.sbin/syslogd/syslogd.c	(revision 335314)
+++ usr.sbin/syslogd/syslogd.c	(working copy)
@@ -1172,45 +1172,43 @@
 	size_t i, msglen;
 	char line[MAXLINE + 1];
 
-	/* Parse the timestamp provided by the remote side. */
-	if (strptime(msg, RFC3164_DATEFMT, _parsed) !=
-	msg + RFC3164_DATELEN || msg[RFC3164_DATELEN] != ' ') {
-		dprintf("Failed to parse TIMESTAMP from %s: %s\n", from, msg);
-		return;
-	}
-	msg += RFC3164_DATELEN + 1;
+	/* Parse the timestamp provided by the remote side, if any. */
+	timestamp = NULL;
+	if (strptime(msg, RFC3164_DATEFMT, _parsed) ==
+	msg + RFC3164_DATELEN && msg[RFC3164_DATELEN] == ' ') {
+		msg += RFC3164_DATELEN + 1;
+		if (!RemoteAddDate) {
+			struct tm tm_now;
+			time_t t_now;
+			int year;
 
-	if (!RemoteAddDate) {
-		struct tm tm_now;
-		time_t t_now;
-		int year;
-
-		/*
-		 * As the timestamp does not contain the year number,
-		 * daylight saving time information, nor a time zone,
-		 * attempt to infer it. Due to clock skews, the
-		 * timestamp may even be part of the next year. Use the
-		 * last year for which the timestamp is at most one week
-		 * in the future.
-		 *
-		 * This loop can only run for at most three iterations
-		 * before terminating.
-		 */
-		t_now = time(NULL);
-		localtime_r(_now, _now);
-		for (year = tm_now.tm_year + 1;; --year) {
-			assert(year >= tm_now.tm_year - 1);
-			timestamp_remote.tm = tm_parsed;
-			timestamp_remote.tm.tm_year = year;
-			timestamp_remote.tm.tm_isdst = -1;
-			timestamp_remote.usec = 0;
-			if (mktime(_remote.tm) <
-			t_now + 7 * 24 * 60 * 60)
-break;
+			/*
+			 * As the timestamp does not contain the year
+			 * number, daylight saving time information, nor
+			 * a time zone, attempt to infer it. Due to
+			 * clock skews, the timestamp may even be part
+			 * of the next year. Use the last year for which
+			 * the timestamp is at most one week in the
+			 * future.
+			 *
+			 * This loop can only run for at most three
+			 * iterations before terminating.
+			 */
+			t_now = time(NULL);
+			localtime_r(_now, _now);
+			for (year = tm_now.tm_year + 1;; --year) {
+assert(year >= tm_now.tm_year - 1);
+timestamp_remote.tm = tm_parsed;
+timestamp_remote.tm.tm_year = year;
+timestamp_remote.tm.tm_isdst = -1;
+timestamp_remote.usec = 0;
+if (mktime(_remote.tm) <
+t_now + 7 * 24 * 60 * 60)
+	break;
+			}
+			timestamp = _remote;
 		}
-		timestamp = _remote;
-	} else
-		timestamp = NULL;
+	}
 
 	/*
 	 * A single space character MUST also follow the HOSTNAME field.
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: py-fail2ban turned silent after syslogd rollout (r335059, stable/11)

2018-06-22 Thread Marek Zarychta
On Fri, Jun 22, 2018 at 08:13:59PM +0200, Kurt Jaeger wrote:
> > I have rolled back to r334835. The issue has gone. Should a PR be
> > created about this regression ?
> 
> Yes, please.
> 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229236

-- 
Marek Zarychta


signature.asc
Description: PGP signature


Re: Console is broken after updating to 11.2-RELEASE

2018-06-22 Thread Yasuhiro KIMURA
I submitted this problem as following bug report.

Bug 229235 - vt(4) of 11.2-RELEASE is broken with hardware dependent problem.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229235

Just FYI.

---
Yasuhiro KIMURA
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: py-fail2ban turned silent after syslogd rollout (r335059, stable/11)

2018-06-22 Thread Kurt Jaeger
Hi!

> >> Could you please give any advice or workaround for this issue?
> > I switched to a workaround for the time being which you might use as well 
> > in a similar way:
> >
> > #) configure fail2ban to use /var/log/faillog
> > #) run something like that in the background:
> >
> > nohup tail -q -F /var/log/fail2ban.log | logger -t fail2ban.filter -p 
> > daemon.notice &
> >
> > #) to let this workaround survive a reboot you need to use a script fired 
> > up from /etc/rc.d
> >
> >
> 
> I have rolled back to r334835. The issue has gone. Should a PR be
> created about this regression ?

Yes, please.

> BTW a few decent syslog daemons are available in /usr/ports/sysutils.

-- 
p...@opsec.eu+49 171 31013722 years to go !
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: py-fail2ban turned silent after syslogd rollout (r335059, stable/11)

2018-06-22 Thread Marek Zarychta


W dniu 2018.06.22 o 19:14, Michael Grimm pisze:
> On 22. Jun 2018, at 17:59, Marek Zarychta  
> wrote:
>
>> Could you please give any advice or workaround for this issue?
> I switched to a workaround for the time being which you might use as well in 
> a similar way:
>
> #) configure fail2ban to use /var/log/faillog
> #) run something like that in the background:
>
>   nohup tail -q -F /var/log/fail2ban.log | logger -t fail2ban.filter -p 
> daemon.notice &
>
> #) to let this workaround survive a reboot you need to use a script fired up 
> from /etc/rc.d
>
>

I have rolled back to r334835. The issue has gone. Should a PR be
created about this regression ?

BTW a few decent syslog daemons are available in /usr/ports/sysutils.
-- 

Marek Zarychta




signature.asc
Description: OpenPGP digital signature


Re: Console is broken after updating to 11.2-RELEASE

2018-06-22 Thread Yasuhiro KIMURA
From: "Chris H" 
Subject: Re: Console is broken after updating to 11.2-RELEASE
Date: Fri, 22 Jun 2018 06:13:39 -0700

> Try adding the following to your loader.conf(5) file
> (/boot/loader.conf):
> 
> # Load SysCons driver
> kern.vty=sc
> # noisy boot
> boot_verbose="YES"
> 
> Hope this helps!

Thank you for information. I added above lines to /boot/loader.conf
and rebooted system. Then all boot messages are displayed and console
works fine!

---
Yasuhiro KIMURA
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: py-fail2ban turned silent after syslogd rollout (r335059, stable/11)

2018-06-22 Thread Michael Grimm
On 22. Jun 2018, at 17:59, Marek Zarychta  wrote:

> Could you please give any advice or workaround for this issue?

I switched to a workaround for the time being which you might use as well in a 
similar way:

#) configure fail2ban to use /var/log/faillog
#) run something like that in the background:

nohup tail -q -F /var/log/fail2ban.log | logger -t fail2ban.filter -p 
daemon.notice &

#) to let this workaround survive a reboot you need to use a script fired up 
from /etc/rc.d

Regards,
Michael

___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: py-fail2ban turned silent after syslogd rollout (r335059, stable/11)

2018-06-22 Thread Michael Grimm
Marek Zarychta  wrote:
> On Fri, Jun 22, 2018 at 03:12:05PM +0200, Michael Grimm wrote:

>> Hi,
>> 
>> this is 11.2-STABLE (r335532), and I am referring to the recent MFC of 
>> syslogd modifications [1]. 
>> 
>> Because I cannot judge whether fail2ban lacks support for the renewed 
>> syslogd or syslogd has an issue in receiving fail2ban messages I do 
>> crosspost this mail to ports and stable.
>> 
>> I do have fail2ban configured to report to SYSLOG:
>> 
>>  logtarget = SYSLOG
>>  syslogsocket = auto
>> 
>> But now, after upgrading to the new syslogd fail2ban refuses to report to 
>> syslogd; no single message gets recorded [2].
>> 
>> I did try to modify the syslogsocket setting to /var/run/log without 
>> success. Pointing logtarget to a regular files tells me that fail2ban is 
>> running as expected, it only lacks reporting to SYSLOG.
>> 
>> #) Does anyone else has running py-fail2ban at >= r335059 and can confirm my 
>> observations? 
>> #) Any ideas how to debug this issue?
>> 
>> Thank you in advance and regards,
>> Michael
>> 
>> 
>> [1] 
>> https://svnweb.freebsd.org/base/stable/11/usr.sbin/syslogd/Makefile?revision=335059=markup=file
>> [2] both syslogd and fail2ban are running at the host, thus another issue 
>> with syslogd fixed in 
>>https://svnweb.freebsd.org/base?view=revision=file=335314 
>> does not apply
>> 
> 
> This is probably connected with the lack of handling of non-RFC
> compliant timestamps. 
> 
> My syslog server also suffers from this issue. It stopped logging
> messages from old Cisco equipment and some newer Netgear switches.
> Running it in debug mode gives some clue:
> 
> Failed to parse TIMESTAMP from x.x.x.x: 12403: Jun 22 17:31:38 CEST:
> %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/17,
> changed state to down

Ah, yes! Haven't thought about running syslogd in debugging mode:

Failed to parse TIMESTAMP from x.x.x.x: fail2ban.filter [79598]: INFO 
[…]

> Could you please give any advice or workaround for this issue?

I cannot answer whether it might be possible to either tell syslogd to accept 
legacy timestamps [1] or configure fail2ban (or your applications) to switch to 
using RFC5424 compliant timestamps.

[1] I did try to set '-O rfc3164' starting syslogd to no avail

Anyone?

Regards,
Michael



___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: py-fail2ban turned silent after syslogd rollout (r335059, stable/11)

2018-06-22 Thread Marek Zarychta
On Fri, Jun 22, 2018 at 03:12:05PM +0200, Michael Grimm wrote:
> Hi,
> 
> this is 11.2-STABLE (r335532), and I am referring to the recent MFC of 
> syslogd modifications [1]. 
> 
> Because I cannot judge whether fail2ban lacks support for the renewed syslogd 
> or syslogd has an issue in receiving fail2ban messages I do crosspost this 
> mail to ports and stable.
> 
> I do have fail2ban configured to report to SYSLOG:
> 
>   logtarget = SYSLOG
>   syslogsocket = auto
> 
> But now, after upgrading to the new syslogd fail2ban refuses to report to 
> syslogd; no single message gets recorded [2].
> 
> I did try to modify the syslogsocket setting to /var/run/log without success. 
> Pointing logtarget to a regular files tells me that fail2ban is running as 
> expected, it only lacks reporting to SYSLOG.
> 
> #) Does anyone else has running py-fail2ban at >= r335059 and can confirm my 
> observations? 
> #) Any ideas how to debug this issue?
> 
> Thank you in advance and regards,
> Michael
> 
> 
> [1] 
> https://svnweb.freebsd.org/base/stable/11/usr.sbin/syslogd/Makefile?revision=335059=markup=file
> [2] both syslogd and fail2ban are running at the host, thus another issue 
> with syslogd fixed in 
> https://svnweb.freebsd.org/base?view=revision=file=335314 
> does not apply
> 

This is probably connected with the lack of handling of non-RFC
compliant timestamps. 

My syslog server also suffers from this issue. It stopped logging
messages from old Cisco equipment and some newer Netgear switches.
Running it in debug mode gives some clue:

Failed to parse TIMESTAMP from x.x.x.x: 12403: Jun 22 17:31:38 CEST:
%LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/17,
changed state to down

Could you please give any advice or workaround for this issue?


-- 
Marek Zarychta


signature.asc
Description: PGP signature


Re: iostat busy value calculation

2018-06-22 Thread Slawa Olhovchenkov
On Wed, Jun 20, 2018 at 07:37:20PM +0200, Miroslav Lachman wrote:

> > %busy comes from the devstat layer. It's defined as the percent of the 
> > time over the polling interval in which at least one transaction was 
> > awaiting completion by the lower layers. It's an imperfect measure of 
> > how busy the drives are (in ye-olden days, before tagged queuing and 
> > NCQ, it was OK because you had THE transaction pending and it was a good 
> > measure of how utilized things were. Now with concurrent I/O in flash 
> > devices, it's only an imperfect approximation).
> 
> Yes, I am aware of this issue. This percentage is just  "is it slightly 
> loaded or heavily loaded" indicator.

for "heavily loaded" use average transaction time and average queue
length
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: Console is broken after updating to 11.2-RELEASE

2018-06-22 Thread Chris H

On Fri, 22 Jun 2018 20:42:18 +0900 (JST) "Yasuhiro KIMURA"  
said


From: Warner Losh 
Subject: Re: Console is broken after updating to 11.2-RELEASE
Date: Fri, 22 Jun 2018 05:03:43 -0600

> UEFI or legacy boot? Is a BMC involved?

Legacy boot. And BMC is not involved.

Try adding the following to your loader.conf(5) file (/boot/loader.conf):

# Load SysCons driver
kern.vty=sc
# noisy boot
boot_verbose="YES"

Hope this helps!

--Chris


---
Yasuhiro KIMURA
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"



___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


py-fail2ban turned silent after syslogd rollout (r335059, stable/11)

2018-06-22 Thread Michael Grimm
Hi,

this is 11.2-STABLE (r335532), and I am referring to the recent MFC of syslogd 
modifications [1]. 

Because I cannot judge whether fail2ban lacks support for the renewed syslogd 
or syslogd has an issue in receiving fail2ban messages I do crosspost this mail 
to ports and stable.

I do have fail2ban configured to report to SYSLOG:

logtarget = SYSLOG
syslogsocket = auto

But now, after upgrading to the new syslogd fail2ban refuses to report to 
syslogd; no single message gets recorded [2].

I did try to modify the syslogsocket setting to /var/run/log without success. 
Pointing logtarget to a regular files tells me that fail2ban is running as 
expected, it only lacks reporting to SYSLOG.

#) Does anyone else has running py-fail2ban at >= r335059 and can confirm my 
observations? 
#) Any ideas how to debug this issue?

Thank you in advance and regards,
Michael


[1] 
https://svnweb.freebsd.org/base/stable/11/usr.sbin/syslogd/Makefile?revision=335059=markup=file
[2] both syslogd and fail2ban are running at the host, thus another issue with 
syslogd fixed in 
https://svnweb.freebsd.org/base?view=revision=file=335314 
does not apply


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: Console is broken after updating to 11.2-RELEASE

2018-06-22 Thread Yasuhiro KIMURA
From: Warner Losh 
Subject: Re: Console is broken after updating to 11.2-RELEASE
Date: Fri, 22 Jun 2018 05:03:43 -0600

> UEFI or legacy boot? Is a BMC involved?

Legacy boot. And BMC is not involved.

---
Yasuhiro KIMURA
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: Console is broken after updating to 11.2-RELEASE

2018-06-22 Thread Yasuhiro KIMURA
From: tech-lists 
Subject: Re: Console is broken after updating to 11.2-RELEASE
Date: Fri, 22 Jun 2018 11:44:29 +0100

> I've seen this effect elsewhere. Not exactly the same, but it's been
> happening with me on some systems since 11.1. The context I see it is
> when spinning up a bhyve instance in screen. I see a bit more than
> just booting, something like "unreferenced ps/2 interrupt" after
> "Booting...".
> 
> The bhyve instance itself is fully functional. Logging into the bhyve
> instance through ssh I can see its dmesg and it all looks OK. However,
> if in syslogd.conf I enable console logging via console.log and
> reboot, *nothing gets written to it*.

Thank you for information. I created /etc/syslog.d/console.log.conf as
below and rebooted system.

yasu@maybe[2012]% cat /etc/syslog.d/console.log.conf
   ~
# Log all writes to /dev/console to a separate file.
!*
console.*   /var/log/console.log
!*
yasu@maybe[2013]%

Then boot messages are written in /var/log/console.log

yasu@maybe[2016]% LANG=C ls -l /var/log/console.log 
   ~
-rw-r--r--  1 root  wheel  9568 Jun 22 20:29 /var/log/console.log
yasu@maybe[2016]%

So my case seems to be different from yours.

---
Yasuhiro KIMURA
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: Console is broken after updating to 11.2-RELEASE

2018-06-22 Thread Warner Losh
UEFI or legacy boot? Is a BMC involved?

Warner

On Fri, Jun 22, 2018, 2:09 AM Yasuhiro KIMURA  wrote:

> Hello.
>
> With the commit of r335510 releng/11.2 switched to -RELEASE. So I
> updated one of my home server from 11.1-RELEASE-p11 to 11.2-RELEASE.
>
> But when I rebooted I found OS boot messages are not displayed on
> console while OS itself has booted successfully. To be exact,
>
> 1. BIOS message are displayed.
> 2. Boot menu of FreeBSD is displayed.
> 3. Kernel boot starts but after 'Booting...' no following messages
>are displayed.
> 4. After OS has booted console stays unusable.
>
> Kernel configuration is as follwing.
>
> --
> yasu@maybe[2006]% uname -a
>  ~
> FreeBSD maybe.home.utahime.org 11.2-RELEASE FreeBSD 11.2-RELEASE #0
> r335513: Fri Jun 22 16:12:12 JST 2018 
> ro...@maybe.home.utahime.org:/usr0/freebsd/base/obj/usr0/freebsd/base/releng/11.2/sys/MAYBE
> amd64
> yasu@maybe[2007]% cat /usr/src/sys/amd64/conf/MAYBE
>   ~
> #
> # MAYBE -- Local kernel configuration file of maybe for FreeBSD/amd64
> #
> # For more information on this file, please read the config(5) manual page,
> # and/or the handbook section on Kernel Configuration Files:
> #
> #
> http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
> #
> # The handbook is also available locally in /usr/share/doc/handbook
> # if you've installed the doc distribution, otherwise always see the
> # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
> # latest information.
> #
> # An exhaustive list of options and more detailed explanations of the
> # device lines is also present in the ../../conf/NOTES and NOTES files.
> # If you are in doubt as to the purpose or necessity of a line, check first
> # in NOTES.
> #
> # $FreeBSD$
>
> include GENERIC
>
> ident   MAYBE
>
> # ZFS support
> options ZFS
>
> # PF support
> device  pf  #PF OpenBSD packet-filter firewall
> device  pflog   #logging support interface for PF
>
> #
> # Temperature sensors:
> #
> # coretemp: on-die sensor on Intel Core and newer CPUs
> #
> device  coretemp
> yasu@maybe[2008]%
> --
>
> I tried GENERIC kernel but the problem still happened.
>
> HWs are,
>
> M/B: ASUS N3150I-C
>  (https://www.asus.com/us/Motherboards/N3150IC/)
> Display: EIZO FlexScan L565
>  (http://www.eizoglobal.com/support/db/products/model/L565)
>
> M/B and display are connected with analog VGA.
>
> Does anyone experiences same problem? Are there any solution or
> workaound?
>
> Best Regards.
>
> ---
> Yasuhiro KIMURA
> ___
> freebsd-stable@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
>
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: Console is broken after updating to 11.2-RELEASE

2018-06-22 Thread tech-lists

Hi,

On 22/06/2018 09:07, Yasuhiro KIMURA wrote:

1. BIOS message are displayed.
2. Boot menu of FreeBSD is displayed.
3. Kernel boot starts but after 'Booting...' no following messages
are displayed.
4. After OS has booted console stays unusable.


I've seen this effect elsewhere. Not exactly the same, but it's been 
happening with me on some systems since 11.1. The context I see it is 
when spinning up a bhyve instance in screen. I see a bit more than just 
booting, something like "unreferenced ps/2 interrupt" after "Booting...".


The bhyve instance itself is fully functional. Logging into the bhyve 
instance through ssh I can see its dmesg and it all looks OK. However, 
if in syslogd.conf I enable console logging via console.log and reboot, 
*nothing gets written to it*.


Have had this issue for about a year now, not been able to fix it. 
Frustratingly, it doesn't happen with all VMs. I've not seen it happen 
with a 12-current VM, just 11-stable. And even then, not *all* 11-stable 
VMs.


--
J.


___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: Console is broken after updating to 11.2-RELEASE

2018-06-22 Thread Yasuhiro KIMURA
From: Yasuhiro KIMURA 
Subject: Console is broken after updating to 11.2-RELEASE
Date: Fri, 22 Jun 2018 17:07:20 +0900 (JST)

> With the commit of r335510 releng/11.2 switched to -RELEASE. So I
> updated one of my home server from 11.1-RELEASE-p11 to 11.2-RELEASE.
> 
> But when I rebooted I found OS boot messages are not displayed on
> console while OS itself has booted successfully. To be exact,
> 
> 1. BIOS message are displayed.
> 2. Boot menu of FreeBSD is displayed.
> 3. Kernel boot starts but after 'Booting...' no following messages
>are displayed.
> 4. After OS has booted console stays unusable.

I have another 11.1-RELEASE-p11 amd64 environment working as guest of
VirtualBox whose host is 64bit Windows 10. So I updated it to
11.2-RELEASE like my home server in question. But in this case console
worked fine just as it was 11.1-RELEASE-p11. So the problem seems to
be hardwear dependent.

---
Yasuhiro KIMURA
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: Console is broken after updating to 11.2-RELEASE,Re: Console is broken after updating to 11.2-RELEASE

2018-06-22 Thread Yasuhiro KIMURA
From: "Andrey V. Elsukov" 
Subject: Re: Console is broken after updating to 11.2-RELEASE,Re: Console is 
broken after updating to 11.2-RELEASE
Date: Fri, 22 Jun 2018 11:47:24 +0300

> Do you have some tweaks for serial console in your loader.conf?

No. I don't use serial console at all. Folloging is loader.conf of my
home server in question.

yasu@maybe[2019]% cat /boot/loader.conf
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
#zfs_load="YES"
yasu@maybe[2020]%

---
Yasuhiro KIMURA
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"


Re: Console is broken after updating to 11.2-RELEASE

2018-06-22 Thread Andrey V. Elsukov
On 22.06.2018 11:07, Yasuhiro KIMURA wrote:
> Hello.
> 
> With the commit of r335510 releng/11.2 switched to -RELEASE. So I
> updated one of my home server from 11.1-RELEASE-p11 to 11.2-RELEASE.
> 
> But when I rebooted I found OS boot messages are not displayed on
> console while OS itself has booted successfully. To be exact,
> 
> 1. BIOS message are displayed.
> 2. Boot menu of FreeBSD is displayed.
> 3. Kernel boot starts but after 'Booting...' no following messages
>are displayed.
> 4. After OS has booted console stays unusable.

Do you have some tweaks for serial console in your loader.conf?

-- 
WBR, Andrey V. Elsukov



signature.asc
Description: OpenPGP digital signature


Console is broken after updating to 11.2-RELEASE

2018-06-22 Thread Yasuhiro KIMURA
Hello.

With the commit of r335510 releng/11.2 switched to -RELEASE. So I
updated one of my home server from 11.1-RELEASE-p11 to 11.2-RELEASE.

But when I rebooted I found OS boot messages are not displayed on
console while OS itself has booted successfully. To be exact,

1. BIOS message are displayed.
2. Boot menu of FreeBSD is displayed.
3. Kernel boot starts but after 'Booting...' no following messages
   are displayed.
4. After OS has booted console stays unusable.

Kernel configuration is as follwing.

--
yasu@maybe[2006]% uname -a  
   ~
FreeBSD maybe.home.utahime.org 11.2-RELEASE FreeBSD 11.2-RELEASE #0 r335513: 
Fri Jun 22 16:12:12 JST 2018 
ro...@maybe.home.utahime.org:/usr0/freebsd/base/obj/usr0/freebsd/base/releng/11.2/sys/MAYBE
  amd64
yasu@maybe[2007]% cat /usr/src/sys/amd64/conf/MAYBE 
   ~
#
# MAYBE -- Local kernel configuration file of maybe for FreeBSD/amd64
#
# For more information on this file, please read the config(5) manual page,
# and/or the handbook section on Kernel Configuration Files:
#
#
http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the ../../conf/NOTES and NOTES files.
# If you are in doubt as to the purpose or necessity of a line, check first
# in NOTES.
#
# $FreeBSD$

include GENERIC

ident   MAYBE

# ZFS support
options ZFS

# PF support
device  pf  #PF OpenBSD packet-filter firewall
device  pflog   #logging support interface for PF

#
# Temperature sensors:
#
# coretemp: on-die sensor on Intel Core and newer CPUs
#
device  coretemp
yasu@maybe[2008]%
--

I tried GENERIC kernel but the problem still happened.

HWs are,

M/B: ASUS N3150I-C
 (https://www.asus.com/us/Motherboards/N3150IC/)
Display: EIZO FlexScan L565
 (http://www.eizoglobal.com/support/db/products/model/L565)

M/B and display are connected with analog VGA.

Does anyone experiences same problem? Are there any solution or
workaound?

Best Regards.

---
Yasuhiro KIMURA
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"