Create log entries with command-line client?

Question

I am getting an error message that seems to indicate that it's impossible to create log entries with the command-line client. Can I ask one of you FCS gurus to advise me?
Note the disturbing error message below: *Entity /log doesn't know how to do create*
root# ./fcsvr_client create /log --xml < /tmp/logentry.xml
<?xml version="1.0"?>
<session>
<values>
<value id="CODE">
<atom>E_NOTSUPP</atom>
</value>
<value id="DESC">
<string xml:space="preserve">Entity /log doesn't know how to do create</string>
</value>
<value id="SRC_FILE">
<string xml:space="preserve">PmdEntity.C</string>
</value>
<value id="SRC_LINE">
<int>2017</int>
</value>
<value id="ERROR_TYPE">
<atom>ET_PERM</atom>
</value>
<value id="ADDRESS">
<string xml:space="preserve">/log</string>
</value>
</values>
</session>
root# cat /tmp/logentry.xml
<?xml version="1.0"?>
<session>
<values>
<value id="LOGASSETID">
<string xml:space="preserve">26</string>
</value>
<value id="LOG_DETAIL">
<string xml:space="preserve">I am your log entry detail.</string>
</value>
<value id="LOG_STATUS">
<string xml:space="preserve">OK</string>
</value>
<value id="LOG_TYPE">
<atom>response</atom>
</value>
<value id="LOG_USER">
<string xml:space="preserve">admin</string>
</value>
<value id="LOG_SUMMARY">
<string xml:space="preserve">Log Summary from Command-Line</string>
</value>
</values>
</session>
Message was edited by: dpotter-ntc

Answer 1

Hmm, no, my 1.5.2 instance logs script responses twice- once to say it is executing and again after the process terminates to say that it ran. The second entry is where any stdout is printed. I don't know of any setting that would turn this off, it has always been there for me.
A typical script response log entry looks like this:
Summary
"response \[Response Title] script triggered by Subscription \[Subscription Title] complete"
Detail
"response complete, completed command /fcsvrbin/\[scriptname.sh] with arguments { 43, 8 } "
"stdout would print here, if there is any"
You probably already tried it, but try filtering your log search for "script triggered" since it can be easy to miss spotting entries on a busy system, and they don't necessarily show up side by side in the logs with the other responses in their respective stack.