Date: Tue, 08 Sep 2015 20:06:57 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 202978] After upgrade of net/syncthing 0.11.18 -> 0.11.23 in jail, the jail causes entire host to crash Message-ID: <bug-202978-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
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@FreeBSD.org Reporter: niklaas@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@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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-202978-8>