[Bug 202978] After upgrade of net/syncthing 0.11.18 -> 0.11.23 in jail, the jail causes entire host to crash

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=202978

            Bug ID: 202978
           Summary: After upgrade of net/syncthing 0.11.18 -> 0.11.23 in
                    jail, the jail causes entire host to crash
           Product: Base System
           Version: 10.1-RELEASE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: niklaas at kulturflatrate.net

Created attachment 160845
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=160845&action=edit
/var/log/messages of the jail and its host with comments

In reference to the thread related to this issue in
freebsd-questions at freebsd.org, see
http://docs.freebsd.org/cgi/getmsg.cgi?fetch=130033+0+current/freebsd-questions.

After upgrading a package (net/syncthing) in a jail I experienced that
the host system rebooted. It seems because the jail starts at each boot
running net/syncthing again, the host system rebooted each time it started
the jail. A vicious circle. Because of this, I was nearly unable to
connect to the server.

By continuously pinging the server and sending a

    ssh <server> ezjail-admin config -r norun <jailname>

once I knew the server is online again, I could stop the circle and
finally log into the server again.

I guess that something's wrong with net/syncthing (or its configuration)
but what worries me more is how a userspace program in a malfunctioning jail
can cause an
entire host system to reboot? (Please also see the discussion in the
mailinglist.)

The upgrade of net/syncthing was 0.11.18 -> 0.11.23

$ uname -a
FreeBSD tank.<server> 10.1-RELEASE-p19 FreeBSD 10.1-RELEASE-p19 #0: Sat Aug 22
03:55:09 UTC 2015    
root at amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  amd64

I am able to reproduce the behaviour by simply starting the jail. Shortly after
that the system crashes. This made it possible for me to get some coredumps:

$ ls -hl /var/crash
total 11552056
-rw-r--r--  1 root  wheel     2B Sep  8 21:15 bounds
-rw-------  1 root  wheel   357K Sep  8 21:09 core.txt.0
-rw-------  1 root  wheel   176K Sep  8 21:12 core.txt.1
-rw-------  1 root  wheel   193K Sep  8 21:16 core.txt.2
-rw-------  1 root  wheel   502B Sep  8 21:08 info.0
-rw-------  1 root  wheel   502B Sep  8 21:11 info.1
-rw-------  1 root  wheel   501B Sep  8 21:15 info.2
lrwxr-xr-x  1 root  wheel     6B Sep  8 21:15 info.last -> info.2
-rw-r--r--  1 root  wheel     5B Jan 16  2014 minfree
-rw-------  1 root  wheel   2.0G Sep  8 21:09 vmcore.0
-rw-------  1 root  wheel   1.9G Sep  8 21:12 vmcore.1
-rw-------  1 root  wheel   1.9G Sep  8 21:15 vmcore.2
lrwxr-xr-x  1 root  wheel     8B Sep  8 21:15 vmcore.last -> vmcore.2

Please find attached `/var/log/messages` of the jail and its host. These are
extracted from the very first failure. I have also a backup of
`/var/log/messages` of the crash that I just "forced" this evening.

I can also share the coredumps but would need some advice on how to do so
without disclosing sensitive information.

-- 
You are receiving this mail because:
You are the assignee for the bug.