Regarding the sendmail error in the jail startup screendump, shouldn't setting sendmail_enable="NONE" in the jail's /etc/rc.conf stop Sendmail from loading at all like a non-jailed system?

As far as detecting if the jail is already running, the man page provides a hint into finding the jail's PID.

Quotheth the man page:

The /proc/pid/status file contains, as its last field, the hostname of
the jail in which the process runs, or ``-'' to indicate that the process
is not running within a jail. The ps(1) command also shows a `J' flag
for processes in a jail.

We've been running jail successfully since FreeBSD-4.8 or even earlier.
The jail was "getting up" when ppp session started up and was killed when ppp went down (the IP was dynamically changing - so there was no other way) - all magic done by 2 simple scripts (called from /etc/ppp/ppp.linkup and ppp.linkdown) - one to determine an IP of the tun0 interface, check if the jail was running and if not - create jail startup script and launch it, and second to kill all jail's processes using `ps axw|grep J|awk '{print $1}'` as seems there was either no jailer in ports at that time or I knew nothing about it.
Running several jails at once requires a little more sophisticated approach - you need to check if the process belongs to some definite jail by checking entries in /proc for it.

Sendmail and bind run perfectly inside jail (other things like pop3/httpd do well as well ;) ).

There is no need to explicitely bind sshd to certain IP's on the host system - the jailed sshd takes over the TCP port - same thing about any application using TCP (so you may get connected to a host system if the jail is not running or has nothing listening on that port - causing some confusion ;) ). Not sure what was happening with UDP - seems such careless approach didn't work.

about "adjkerntz - Not sure about this." and other similiar things - all of that is in /etc/rc or called from it. I guess there's a need to finally create a separate set of startup scripts for the jail, the scripts may not try doing weird things like playing with kernel variables, video modes and other things that belong to the host system.

Also - each jail has its own loopback (127.0.0.1) that prooved to have nothing to do with the host system's one, so don't expect you'll get connected to a host system from the jail using 127.0.0.1 - add some alias IP to a host system's lo0, like 192.168.0.1 or anything else.

Summarizing all the experience of running (you surely googled for the name?) all the *beep* in a not so friendly Internet environment in a jail I must admit that it is a pretty robust solution, allowing pretty fast migration from one host system to another (just pack and unpack directory with the jailed environment), though not very straightforward when you need it to do strange things.

> Also - each jail has its own loopback (127.0.0.1) that prooved to have
> nothing to do with the host system's one, so don't expect you'll get
> connected to a host system from the jail using 127.0.0.1 - add some
> alias IP to a host system's lo0, like 192.168.0.1 or anything else.

I'm not sure If I understand you right, but each jail having it's OWN 127.0.0.1/loopback is a good thing (TM).

Hypothetically, why would I add 192.168.0.1 to my HOST's lo0? and not my GUEST's?