You chopped up part of the log line, which would provide more context about what this means.
It would be something like:
syslog:Mar 12 10:17:01 hostname CRON[4154]: (root) CMD ( [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete)
The fact that it says CRON indicates it was generated by the cron periodic execution daemon. After the colon, you see it executed a command as the root user. The command was the thing in the parentheses after CMD.
When you install PHP it adds a crontab entry to clean up stale sessions, which is run by the crontab daemon. Other than the cron-related information I mentioned, the command itself verifies that /usr/lib/php5/maxlifetime and /var/lib/php5 exist, then uses the find command to locate session files under /var/lib/php5 older than the number contained in /usr/lib/php5/maxlifetime, which it then deletes.
This is the command itself:
[ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete
If you want to understand it better, I suggest reading this for the conditions at the beginning:
http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html
then this answer for basics of find:
How can I use find command more efficiently?
If your question is about whether this command is safe, then yes, it's not a security risk of any kind and is perfectly safe to see this run periodically.
Best Answer
The term "canary" as used here comes from coal mining originally. Coal miners used canaries to detect dangerous gases (if the canary they carried with them died, they knew they had to get out of the shaft/mine ASAP). As a result the term "canary" is now often used for anything that you use to get an (early) warning about a dangerous situation.
In this case it seems like 'rtkit' starts a "normal" thread to test if the threads that get "real time" priorities are "starving" other threads (& processes), where "starving" means that they get too little processor time. This is a safety measure to make sure that processes/threads that have access to real time priorities don't use up so much CPU time that other tasks get none anymore.
So apparently some thread(s) that got real-time priorities from rtkit is/are misbehaving, and trying to monopolize the CPU, rtkit detects this with its "canary thread", and thus rtkit takes away the real-time priorities.