Rudder

It looks like the actual command that is run is used as the component Key in reporting on this Technique. So the logs will contain something along the lines of:

@@jobScheduler@@result_success@@$(job_scheduler_uuids[$(iterator)])@@Job@@/bin/echo "This is a test" >> /tmp/my_own_log.log 2>&1@@$(g.execRun)##$(g.uuid)@#Job returned a success return code after the last completed execution (/bin/echo "This is a test" >> /tmp/my_own_log.log 2>&1)

I'm unsure which character breaks reporting, but I'm sure it's pretty easy to reproduce on one of our machines.

I can't exactly reproduice this error
I choosed the command

/bin/echo \"This is a test\" >> /tmp/my_own_log.log 2>&1

/bin/echo "This is a test" >> /tmp/my_own_log.log 2>&1

because the \" is converted to " within the cfengine code

I'm checking if the \" -> " exists also on rudder 2.3

Nicolas CHARLES wrote:

I can't exactly reproduice this error
I choosed the command
[...]
on CentOS
and it led to unknown reports with the key value
[...]

because the \" is converted to " within the cfengine code

Ok, the command to use was missing the tricky part: Use of CFEngine variable

Here is a command which turn to a "No Answer" state:

/bin/echo 'This is a test' >> /tmp/my_own_log_on_${sys.host}.log 2>&1

Ha, others bugs/details show that the logs are not sent to Rudder (or parsed by Rudder) for the line
R: @jobScheduler@log_info@f3cc8d3a-cdae-4e7b-9b43-d8bec3686537@4040600f-f01e-4471-93ec-fd03cf096d0d@17@Job@/bin/echo This is a test >> /tmp/my_own_log_on_centos-5-32.log 2>&1@2013-01-08 12:43:54+01:00##248c8e3d-1bf6-4bc1-9398-f8890b015a50@#The command will be run at a random time after 11:00 on this node (/bin/echo This is a test >> /tmp/my_own_log_on_centos-5-32.log 2>&1)

Nicolas CHARLES wrote:

Ha, others bugs/details show that the logs are not sent to Rudder (or parsed by Rudder) for the line
R: @jobScheduler@log_info@f3cc8d3a-cdae-4e7b-9b43-d8bec3686537@4040600f-f01e-4471-93ec-fd03cf096d0d@17@Job@/bin/echo This is a test >> /tmp/my_own_log_on_centos-5-32.log 2>&1@2013-01-08 12:43:54+01:00##248c8e3d-1bf6-4bc1-9398-f8890b015a50@#The command will be run at a random time after 11:00 on this node (/bin/echo This is a test >> /tmp/my_own_log_on_centos-5-32.log 2>&1)

To tell which case it is (not sent to Rudder or not parsed by Rudder), check the intermediate syslogs: /var/log/syslog on the node and /var/log/rudder/reports/ on the Rudder server. If they contain the line, the problem is in the parsing by rsyslog.

Ok, here the problem is our regexp for rsyslog, the component key is 64 character long max, and the key is 68 in this example