Date: Mon, 09 Mar 2015 20:52:51 -0600 From: James Gritton <jamie@freebsd.org> To: freebsd-jail@freebsd.org Subject: Re: ftasv and ScoreBoardFile on FreeBSD 10 with jails Message-ID: <88a082c0bbf3a1bae7e5a6864f73884d@gritton.org> In-Reply-To: <e95ffe6d7185958b305b825ef6084691@mail.electricembers.net> References: <e95ffe6d7185958b305b825ef6084691@mail.electricembers.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2015-03-09 13:23, Benjamin Connelly wrote: > We recently upgraded some FreeBSD 9.1 servers to FreeBSD 10.1 and > found it broke the scoreboard viewing utility we were using, the > "ftasv" port (ftss). > > For that tool to work apache is supposed to be configured to use 'a > "name based" shared memory segment' (from their README) by the > directive > > ScoreBoardFile /var/run/apache_status > > That used to (on FreeBSD 9.1) create that "file". Then we could > execute 'ftasv /var/run/apache_status' to interpret it and see what > requests apache was working to serve. > > This even worked with many different apache instances running each in > their own jail, where all the jails actually share the same basejail > /usr/local/sbin/httpd binary. Inside each jail we could see just the > requests that instance of apache was working on. > > But after the FreeBSD upgrade to 10.1 we no longer see the > apache_status file in the filesystem, and ftasv seems to actually > report the most recent hits from the most recently restarted instance > of apache, even if that's in another jail!? (On a system with no jails > and just the one instance of apache, it's not actually a problem!) > > Can anybody point me toward the right dials to turn if it's still > possible to do this scoreboard viewing of each independent apache > instance? (Like I think I may need security.jail.param.allow.sysvipc=1 > in the jails, but I'm also finding with ezjail I'm not actually able > to get that set because it's creating the /var/run/jail.JAILNAME.conf > file with both these lines in it: > allow.sysvipc = 0; > allow.sysvipc=1; > > Ben You definitely don't want to try setting anything under security.jail.param.* - those are just informational, used by jail(8) to know the identities and formats of the currently available parameters. One of the two lines that is ending up in /var/run/jail.JAILNAME.conf is correct, though it's not immediately obvious which one. ftss claims you need name-based shared memory, i.e. memory-mapped files. This has nothing to do with SYSV-style shared memory, except that it's the modern (i.e. right) way to do shared memory and SYSV IPC is the old (i.e. wrong) way. So that would make me think it doesn't matter what you do with allow.sysvipc. Maybe ftss first tries SYSV, and if that works it goes with that, and if it doesn't then it tries the memory-mapped file (which isn't what it says it does, but that's neither here nor there). Jails that allow SYSV IPC don't segregate it into per-jail namespaces, which is IMHO a bug and which would explain it seeing some other jail's status. Memory-mapped files on the other hand depend on the file being the same (and not just the same name), so a typical jail will not be able to share another jail's memory-mapped files because it can't see another jail's filesystem namespace. This is making me think you want allow.syscipc=0. I'm not sure how you would set that in ezjail, but I would assume it's ... well ... easy. - Jamie
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?88a082c0bbf3a1bae7e5a6864f73884d>