Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 30 Mar 2015 08:42:11 -0700
From:      Benjamin Connelly <ben@electricembers.coop>
To:        freebsd-jail@freebsd.org
Subject:   Re: ftasv and ScoreBoardFile on FreeBSD 10 with jails
Message-ID:  <16C8A490-722C-464D-AFA5-6E3CED4B2EDD@electricembers.coop>
In-Reply-To: <88a082c0bbf3a1bae7e5a6864f73884d@gritton.org>
References:  <e95ffe6d7185958b305b825ef6084691@mail.electricembers.net> <88a082c0bbf3a1bae7e5a6864f73884d@gritton.org>

next in thread | previous in thread | raw e-mail | index | archive | help

>> 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=3D1
>> 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 =3D 0;
>>        allow.sysvipc=3D1;
>> Ben
>=20
> 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.
>=20
> 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.
>=20
> This is making me think you want allow.syscipc=3D0.  I'm not sure how =
you would set that in ezjail, but I would assume it's ... well ... easy.
>=20
> - Jamie

Well I have heard back from the developers of ftss that it uses =
=E2=80=9Cwhatever apr uses=E2=80=9D for shared memory.=20

It sure seems like something changed here and that jails should each =
have their own apache scoreboard shared memory and not be able to see =
the others, like it was in the FreeBSD 9=E2=80=99s. . .=20

Does anybody know anything about this?

 Benjamin=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?16C8A490-722C-464D-AFA5-6E3CED4B2EDD>