[Bug 191279] [jail] jail allow.sysvipc - doesn't work until jail is started TWICE after reboot

Sun Jul 6 08:08:20 UTC 2014

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

--- Comment #6 from dreamcat4 at gmail.com ---
(In reply to joeb1 from comment #5)
> When you say the allow.sysvipc parameter has no effect on a jails first
> start after system boot. Just how are you determining this? 

I was previously checking the log file of the program 'zabbix2-server'. Which
is unable to start, and logfile gives the reason:

zabbix_server [4414]: cannot create Semaphore: [78] Function not implemented
zabbix_server [4414]: unable to create mutex for log file

However now that someone else has reproduced it too, I will try more things!

> Do you see the "allow.sysvipc" listed by the "jls -name -j jailname" command.
> I installed 10.0 from disc1.iso to a empty hard drive and running qjail-3.4
> and after starting the jail "jls -name -j jailname" shows "allow.sysvipc"
> which means its enabled, and no error messages in the jails console log. 

This is on my host, after a fresh reboot:

freenas // root^> qjail list
STA JID  NIC IP              Jailname
--- ---- --- --------------- --------------------------------------------------
DR  1    re0 192.168.1.205   nas4free
DR  2    re0 192.168.1.81    nginx-webdav
DR  3    re0 192.168.1.206   openvpn
             lo0|127.0.0.1
DR  4    re0 192.168.1.38    ps3netsrv
DR  5    re0 192.168.1.207   tvheadend
             lo0|127.0.0.207
DR  6    re0 192.168.1.223   ums4
             lo0|127.0.0.223
DR  7    re0 192.168.1.41    virtualbox
             lo0|127.0.0.2
DR  8    re0 192.168.1.214   webcamd
             lo0|127.0.0.214
DR  9    re0 192.168.1.212   zabbix
             lo0|127.0.0.212

freenas // root^> jls -h -j zabbix allow.sysvipc
allow.sysvipc
0
freenas // root^> qjail restart zabbix
Jail successfully stopped  zabbix
Jail successfully started  zabbix
freenas // root^> jls -h -j zabbix allow.sysvipc
allow.sysvipc
1

Above we can see that jls will indeed report the problem if it occurs. Since I
can still reproduce the error, I am investigating more today. Please bear with
me...

> Seeing jls showing the "allow.sysvipc" instead of "allow.nosysvipc" is the
> only indicator I have available to verify its being set correctly. This

There is also the command 'ipcs', which can be run inside the jail. Here again
is my output after a another system reboot:

freenas // root^> qjail console zabbix
Last login: Sun Jul  6 08:05:03 on pts/0
FreeBSD 9.2-RELEASE-p3 (FREENAS.amd64) #0 r262572+7b72365: Fri Mar 14 15:50:04
PDT 2014

Welcome to your FreeBSD jail.
zabbix ~/ root~# ipcs
Message Queues:
T           ID          KEY MODE        OWNER    GROUP   

Shared Memory:
T           ID          KEY MODE        OWNER    GROUP   

Semaphores:
T           ID          KEY MODE        OWNER    GROUP   

zabbix ~/ root~# exit
logout
freenas // root^> qjail restart zabbix
Jail successfully stopped  zabbix
Jail successfully started  zabbix
freenas // root^> qjail console zabbix
Last login: Sun Jul  6 08:53:45 on pts/0
FreeBSD 9.2-RELEASE-p3 (FREENAS.amd64) #0 r262572+7b72365: Fri Mar 14 15:50:04
PDT 2014

Welcome to your FreeBSD jail.
zabbix ~/ root~# ipcs
Message Queues:
T           ID          KEY MODE        OWNER    GROUP   

Shared Memory:
T           ID          KEY MODE        OWNER    GROUP   
m        65536   1745323649 --rw------- zabbix   zabbix  
m        65537   2013759105 --rw------- zabbix   zabbix  
m        65538   1946650241 --rw------- zabbix   zabbix  
m        65539   1728546433 --rw------- zabbix   zabbix  
m        65540   1929873025 --rw------- zabbix   zabbix  
m        65541   1393002113 --rw------- zabbix   zabbix  
m        65542   1980204673 --rw------- zabbix   zabbix  
m        65543   1812431314 --rw------- zabbix   zabbix  

Semaphores:
T           ID          KEY MODE        OWNER    GROUP   
s        65536   2047313537 --rw------- zabbix   zabbix  
s        65537   2047312338 --rw------- zabbix   zabbix  

zabbix ~/ root~# 

> indicator does not really prove the sysvipc function for the jail is
> functional. As far as I know you need to run some application in the jail
> that requires sysvipc access as the only true test. This application may
> have to be started one time to set some application internal default setting
> before it knows sysvipc is enabled on its second start. Look for a

That would suggest be could just be restarting the zabbix_server application
(rather than the jail). However that is not the case here. 2nd, 3rd, 4th,
restart etc of zabbix_server rc.d script makes no difference. Wheras restarting
the jail once, zabbix did not repeat error message, and all was OK.

> application configure file to set sysvipc as the default instead of the tcp
> default setting. What application are you running in the jail and how does
> that application get started?

Unfortunately sysvipc / unix semaphores is always required for this particular
program (zabbix). It has no option to switch them off, or use some alternative
mechanism instead (such as TCP). Otherwise I would have disabled sysvipc usage
in the zabbix application a long time ago.

> Almost 99% sure your problem is caused by your jailed application and not
> qjail or jail(8).

Nah. I would be very surprised, given today's output from jls and ipcs
commands, that the problem is anything to do with the zabbix application
itself. It just seems some of us could reproduce this issue, and some of us
can't. We seem to have 2 reports of success. And equally 2 of fail.

What seems to be missing is better instructions to reproduce this (my fault).
There must be some other circumstances specific to my host, which is triggering
this to occur... I will find out today.

For one thing, we know that on startup, qjail is changing the same jail.conf
file. Then re-calling jail(8) program again on the next jail in the list. So
maybe that's got something to do with it. Please bear with me. I will look into
it further.

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