Jamie Nguyen
jamie****@tomoy*****
Thu Jun 16 22:57:27 JST 2011
Tetsuo Handa wrote: > How is $MAINPID determined? > Don't we need to do > > killall -HUP ccs-auditd > > or > > /bin/kill -HUP `pidof ccs-auditd` > > because $MAINPID is not the PID of exec()ed process? If a service has "Type=forking", then $MAINPID can either be determined from a PID file provided by the program, or systemd does some kind of magic to guess what $MAINPID is. The default is to guess. I'm running revision 5131 and it is working fine. Thanks for implementing. In case you are interested, this is what querying the status of the service looks like: # systemctl status ccs-auditd.service ccs-auditd.service - TOMOYO Linux Auditing Daemon Loaded: loaded (/lib/systemd/system/ccs-auditd.service) Active: active (running) since Thu, 16 Jun 2011 14:29:20 +0100; 798ms ago Process: 1130 ExecStart=/usr/sbin/ccs-auditd (code=exited, status=0/SUCCESS) Main PID: 1132 (ccs-auditd) CGroup: name=systemd:/system/ccs-auditd.service └ 1132 /usr/sbin/ccs-auditd # ps -e | grep ccs 1132 ? 00:00:00 ccs-auditd I have restarted the service several times and it appears that systemd is able to guess $MAINPID correctly every time. >From http://0pointer.de/public/systemd-man/systemd.service.html ===================== GuessMainPID= Takes a boolean value that specifies whether systemd should try to guess the main PID of a service should if it cannot be determined reliably. This option is ignored unless Type=forking is set and PIDFile= is unset because for the other types or with an explicitly configured PID file the main PID is always known. The guessing algorithm might come to incorrect conclusions if a daemon consists of more than one process. If the main PID cannot be determined failure detection and automatic restarting of a service will not work reliably. Defaults to yes. PIDFile= Takes an absolute file name pointing to the PID file of this daemon. Use of this option is recommended for services where Type= is set to forking. systemd will read the PID of the main process of the daemon after start-up of the service. systemd will not write to the file configured here. ===================== This is part of a service file that uses PIDFile: ===================== [Service] Type=forking PIDFile=/run/dnsmasq.pid ExecStartPre=/usr/sbin/dnsmasq --test ExecStart=/usr/sbin/dnsmasq --pid-file=/run/dnsmasq.pid ExecReload=/bin/kill -HUP $MAINPID ===================== It's up to you if you want to implement a PID file. It doesn't seem to be strictly necessary and things are working fine without PIDFile. On an unrelated note, I think I've spotted a bug. Creating a second namespace works fine, but creating a third namespace seems to cause some issue with profiles. The policy within "/etc/ccs/policy/" directory is correct, but "/etc/ccs/profile.conf" is not updated to reflect the third namespace. On bootup I got an error saying that "Profile 1 is not defined" or similar. The profiles for the third namespace are visible within ccs-editpolicy and inside "/etc/ccs/profile/current/profile.conf", but not within "/etc/ccs/profile.conf". # ccs-savepolicy # grep PROFILE_VERSION /etc/ccs/policy/current/profile.conf <kernel> PROFILE_VERSION=20100903 </usr/bin/firefox> PROFILE_VERSION=20100903 </usr/bin/evince> PROFILE_VERSION=20100903 # grep PROFILE_VERSION /etc/ccs/profile.conf <kernel> PROFILE_VERSION=20100903 </usr/bin/firefox> PROFILE_VERSION=20100903
TOMOYO
Fork