Re: FreeBSD 11.0: Installation of icingaweb2

[Dewayne Geraghty]

Thorsten,
This is a ports issue so should go to the freebsd-ports mailing list (if at
all)

Your best option is to file a PR so that the maintainer of the port can
update the plist file.  You'll occassionally see this sort of package-build
failure when the maintainer has missed a test package step.

If you're shy, you could write to the maintainer directly but then others
can't see that the issue has been raised (and presumably being
raised/addressed).

In the meantime - you could adjust the plist yourself to reflect the new
reality.  Though expedient this is not recommended.  Filing a PR is highly
recommended to benefit everyone and have a fix properly applied.
Regard.
___
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: FreeBSD 10.2-RELEASE #0 r286666: Panic and crash

[Karl Denninger]

On 2/6/2017 15:01, Shawn Bakhtiar wrote:
> Hi all!
>
> http://pastebin.com/niXrjF0D
>
> Please refer to full output from crash above.
>
> This morning our IMAP server decided to go belly up. I could not remote in, 
> and the machine would not respond to any pings.
>
> Checking the physical console I had the following worrisome messages on 
> screen:
>
> • g_vfs_done():da1p1[READ(offset=7265561772032, length=32768)]error = 5
> • g_vfs_done():da1p1[WRITE(offset=7267957735424, length=131072)]error = 16
> • /mnt/USBBD: got error 16 while accessing filesystem
> • panic: softdep_deallocate_dependencies: unrecovered I/O error
> • cpuid = 5
>
> /mnt/USBDB is a MyBook USB 8TB drive that we use for daily backups of the 
> IMAP data using rsync. Everything so far has worked without issue.
>
> I also noticed a bunch of:
>
> • fstat: can't read file 2 at 0x41f
> • fstat: can't read file 4 at 0x78
> • fstat: can't read file 5 at 0x6
> • fstat: can't read file 1 at 0x27f
> • fstat: can't read file 2 at 0x41f
> • fstat: can't read file 4 at 0x78
> • fstat: can't read file 5 at 0x6
>
>
> but I have no idea what these are from.
>
> df -h output:
> /dev/da0p21.8T226G1.5T13%/
> devfs 1.0K1.0K  0B   100%/dev
> /dev/da1p17.0T251G6.2T 4%/mnt/USBBD
>
>
> da0p2 is a RAID level 5 on an HP Smart Array
>
> Here is the output of dmsg after reboot:
> http://pastebin.com/rHVjgZ82
>
> Obviously both the RAID and USB drive did not walk away from the crash 
> cleaning. Should I be running a fsck at this point on both from single user 
> mode to verify and clean up. My concern is the:
> WARNING: /: mount pending error: blocks 0 files 26
> when mounting /dev/da0p2
>
> For some reason I was under the impression that fsck was run automatically on 
> reboot.
>
> Any help in this matter would be greatly appreciated. I'm a little concerned 
> that a backup strategy that has worked for us for many MANY years would so 
> easily throw the OS into panic. If an I/O error occurred on the USB Drive I 
> would frankly think it should just back out, without panic. Or am I missing 
> something?
>
> Any recommendations / insights would be most welcome.
> Shawn
>
>
The "mount pending error" is normal on a disk that has softupdates
turned on; fsck runs in the background after the boot, and this is
"safe" because of how the metadata and data writes are ordered.  In
other words the filesystem in this situation is missing uncommitted
data, but the state of the system is consistent.  As a result the system
can mount root read-write without having to fsck it first and the
background cleanup is safe from a disk consistency problem.

The panic itself appears to have resulted from an I/O error that
resulted in a failed operation.

I was part of a thread in 2016 on this you can find here:
https://lists.freebsd.org/pipermail/freebsd-stable/2016-July/084944.html

The basic problem is that the softupdates code cannot deal with a hard
I/O error on write because it no longer can guarantee filesystem
integrity if it continues.  I argued in that thread that the superior
solution would be forcibly detach the volume, which would leave you with
a "dirty" filesystem and a failed operation but not a panic.  The
file(s) involved in the write error might be lost, but the integrity of
the filesystem is recoverable (as it is in the panic case) -- at least
it is if the fsck doesn't require writing to a block that *also* errors out.

The decision in the code is to panic rather than detach the volume,
however, so panic it is.  This one has bit me with sd cards in small
embedded-style machines (where turning off softupdates makes things VERY
slow) and at some point I may look into developing a patch to
forcibly-detach the volume instead.  That obviously won't help you if
the system volume is the one the error happens on (now you just forcibly
detached the root filesystem which is going to get you an immediate
panic anyway) but in the event of a data disk it would prevent the
system from crashing.

-- 
Karl Denninger
k...@denninger.net 
/The Market Ticker/
/[S/MIME encrypted email preferred]/


smime.p7s
Description: S/MIME Cryptographic Signature

FreeBSD 10.2-RELEASE #0 r286666: Panic and crash

[Shawn Bakhtiar]

Hi all!

http://pastebin.com/niXrjF0D

Please refer to full output from crash above.

This morning our IMAP server decided to go belly up. I could not remote in, and 
the machine would not respond to any pings.

Checking the physical console I had the following worrisome messages on screen:

• g_vfs_done():da1p1[READ(offset=7265561772032, length=32768)]error = 5
• g_vfs_done():da1p1[WRITE(offset=7267957735424, length=131072)]error = 16
• /mnt/USBBD: got error 16 while accessing filesystem
• panic: softdep_deallocate_dependencies: unrecovered I/O error
• cpuid = 5

/mnt/USBDB is a MyBook USB 8TB drive that we use for daily backups of the IMAP 
data using rsync. Everything so far has worked without issue.

I also noticed a bunch of:

• fstat: can't read file 2 at 0x41f
• fstat: can't read file 4 at 0x78
• fstat: can't read file 5 at 0x6
• fstat: can't read file 1 at 0x27f
• fstat: can't read file 2 at 0x41f
• fstat: can't read file 4 at 0x78
• fstat: can't read file 5 at 0x6


but I have no idea what these are from.

df -h output:
/dev/da0p21.8T226G1.5T13%/
devfs 1.0K1.0K  0B   100%/dev
/dev/da1p17.0T251G6.2T 4%/mnt/USBBD


da0p2 is a RAID level 5 on an HP Smart Array

Here is the output of dmsg after reboot:
http://pastebin.com/rHVjgZ82

Obviously both the RAID and USB drive did not walk away from the crash 
cleaning. Should I be running a fsck at this point on both from single user 
mode to verify and clean up. My concern is the:
WARNING: /: mount pending error: blocks 0 files 26
when mounting /dev/da0p2

For some reason I was under the impression that fsck was run automatically on 
reboot.

Any help in this matter would be greatly appreciated. I'm a little concerned 
that a backup strategy that has worked for us for many MANY years would so 
easily throw the OS into panic. If an I/O error occurred on the USB Drive I 
would frankly think it should just back out, without panic. Or am I missing 
something?

Any recommendations / insights would be most welcome.
Shawn








___
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: FreeBSD 11.0: Installation of icingaweb2

[Kevin Oberman]

On Mon, Feb 6, 2017 at 8:48 AM, Thorsten Baumeister <
thorsten_baumeis...@gmx.de> wrote:

> Hi folks,
> last weekend I tried to install the port icingaweb2 on a patched FreeBSD
> 11.0 server. 'make' worked fine, but 'make install' failed. Has anyone seen
> / resolved this problem?
>
> Thorsten
>
> ===>  Checking if icingaweb2 already installed
> ===>   Registering installation for icingaweb2-2.4.1
> pkg-static: Unable to access file /usr/ports/net-mgmt/
> icingaweb2/work/stage/usr/local/share/example 
> s/icingaweb2/apache/icingaweb2.conf:
> No such file or directory
> pkg-static: Unable to access file /usr/ports/net-mgmt/
> icingaweb2/work/stage/usr/local/share/example
> s/icingaweb2/nginx/icingaweb2.conf: No such file or directory
> *** Error code 74
>
> Stop.
> make[1]: stopped in /usr/ports/net-mgmt/icingaweb2
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/net-mgmt/icingaweb2
> - mobile Mail -
>

To be literal, it means that icingaweb2.conf is in the pkg-plist for the
port but was not present in the staged port installation. This is often an
error in the pkg-plist file of the port, but may be an error in the make or
the stage sections of the port build. Since this is a sample configuration
file, if you have an immediate need to get the new version installed, you
can just delete it from pkg-plist.

It does appear that the nginx directory in the distribution is not there.
Only apache. Oddly, I don't find anything in the changelog or looking at
old releases to indicate that it has existed. Looks like a quick edit to
pkg-plist will fix it up for you.

Have you reported this issue to the maintainer? ("make maintainer" will
tell you the address.)
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: net.inet.udp.log_in_vain strange syslog reports

[Eric van Gyzen]

On 02/06/2017 10:19, Mark Martinec wrote:
> 
> One minor nit:
> instead of a hack:
> 
> char src[4*sizeof "123"];
> char dst[4*sizeof "123"];
> 
> it would be cleaner and in sync with the equivalent code in
> sys/netinet6/udp6_usrreq.c
> to use the INET_ADDRSTRLEN constant (from sys/netinet/in.h, value 16):
> 
> char src[INET_ADDRSTRLEN];
> char dst[INET_ADDRSTRLEN];

Agreed.

> Hope the fix finds its way into 11.1 (or better yet, as a patch level in
> 10.0).
> Should I open a bug report?

It will quite likely get into 11.1.  As for a 10.x patch, you would have
to ask re@ (I think), but I doubt it.  These messages are really just
informative and can't be used for any filtering, since the source
address could be spoofed.

Eric
___
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 11.0: Installation of icingaweb2

[Thorsten Baumeister]

Hi folks, 
last weekend I tried to install the port icingaweb2 on a patched FreeBSD 11.0 
server. 'make' worked fine, but 'make install' failed. Has anyone seen / 
resolved this problem? 

Thorsten

===>  Checking if icingaweb2 already installed
===>   Registering installation for icingaweb2-2.4.1
pkg-static: Unable to access file 
/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/share/example 
s/icingaweb2/apache/icingaweb2.conf: No such file or directory
pkg-static: Unable to access file 
/usr/ports/net-mgmt/icingaweb2/work/stage/usr/local/share/example 
s/icingaweb2/nginx/icingaweb2.conf: No such file or directory
*** Error code 74

Stop.
make[1]: stopped in /usr/ports/net-mgmt/icingaweb2
*** Error code 1

Stop.
make: stopped in /usr/ports/net-mgmt/icingaweb2
- mobile Mail -

___
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: net.inet.udp.log_in_vain strange syslog reports

[Mark Martinec]

On 2017-02-02 12:55, Mark Martinec wrote:

11.0-RELEASE-p7, net.inet.udp.log_in_vain=1

The following syslog entries seem to indicate some buffer overruns
in the reporting code (not all log lines are broken, just some).

(the actual failed connection attempts were indeed there,
it's just that the reported IP address is highly suspicious)

  Mark



2017-02-03 20:05, Eric van Gyzen wrote:

There is no buffer overrun, so no cause for alarm.  The problem is
concurrent usage of a single string buffer by multiple threads.  The
buffer is inside inet_ntoa(), defined in sys/libkern/inet_ntoa.c.  In
this case, it is called from udp_input().

Would you like to test the following patch?

Eric


diff --git a/sys/netinet/udp_usrreq.c b/sys/netinet/udp_usrreq.c
index 173c44c..ca2dda1 100644
--- a/sys/netinet/udp_usrreq.c
+++ b/sys/netinet/udp_usrreq.c
@@ -674,13 +674,13 @@ udp_input(struct mbuf **mp, int *offp, int proto)
INPLOOKUP_RLOCKPCB, ifp, m);
if (inp == NULL) {
if (udp_log_in_vain) {
-   char buf[4*sizeof "123"];
+   char src[4*sizeof "123"];
+   char dst[4*sizeof "123"];

-   strcpy(buf, inet_ntoa(ip->ip_dst));
log(LOG_INFO,
"Connection attempt to UDP %s:%d from 
%s:%d\n",
-   buf, ntohs(uh->uh_dport), 
inet_ntoa(ip->ip_src),

-   ntohs(uh->uh_sport));
+   inet_ntoa_r(ip->ip_dst, dst), 
ntohs(uh->uh_dport),
+   inet_ntoa_r(ip->ip_src, src), 
ntohs(uh->uh_sport));

}
UDPSTAT_INC(udps_noport);
if (m->m_flags & (M_BCAST | M_MCAST)) {



Thanks, the explanation makes sense and the patch looks good (mind the 
TABs).

Running it now, expecting no surprises there.


One minor nit:
instead of a hack:

char src[4*sizeof "123"];
char dst[4*sizeof "123"];

it would be cleaner and in sync with the equivalent code in 
sys/netinet6/udp6_usrreq.c

to use the INET_ADDRSTRLEN constant (from sys/netinet/in.h, value 16):

char src[INET_ADDRSTRLEN];
char dst[INET_ADDRSTRLEN];


Hope the fix finds its way into 11.1 (or better yet, as a patch level in 
10.0).

Should I open a bug report?

  Mark


___
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"