event jobs / sys jobs do not show stdout of commands executed but print massive amount of other info

[sebastianelsner]

Consider this output of the afanasy job id 1 events block dummy task

There is much debug output. Something that is making debugging custom commands very difficult. I think it comes from here:

https://github.com/CGRU/cgru/blob/73409312df3f71ed007aaa1afb18f882014193d1/afanasy/src/server/sysjob.cpp#L99

Additionally the output of custom commands to stdout is not visible here. stderr is visible tho.

I would wish for the debug output to go away and for the commands output to appear.

[timurhai]

Hi! System task has lots of starts (sessions) and the way that a commont task stores output is not suitable for it. But the logging way is more suitable. Latest info is stored, old info disappears, as logs has maximum lines limit. Yes, event tasks produces lots of info, this for done log ago for testing puroposes when events just appeared. I agree, now we can reduce its ouput - too much, not clear. As you are the last person, who testing events, what is your idea what to store?

[sebastianelsner]

Thanks!

Concerning the first issue of too much output: I am not 100% clear on this: the log is used as a temporary place to store the job info. if we just removed the job info from the log the sysjob would not work any more? Correct? Or is this just informational for debugging? Generally I would just be in favour of removing this very verbose log completely without replacement. The format of the json is well know as it is very similar to other places.

Concerning the second issue: The stdout of a sysjob is not added to the log. That would be great for debugging. Would that be possible?

[timurhai]

Hi! Log is for informational purposes only. If not in log, where it should be stored? It can't be stored as output, as each task session output server stores on disk, it will be disk space oferflow. And log is just stored in RAM and has maximum lines.

[sebastianelsner]

I am really not sure. I think the current state is the "Debug" output state one needs in 0.5% of cases. No? I would say you need these infos only very rarely, so having a config option would be best. Of course this is much work for little gain.... hm...

The best would be to have only these lines:

Wed 29 Mar 11:08.11 : #0: SESSION #1: Starting on "serviceclient": myuser: "AAA_389651_A_v01": the_command_executed The output here.

Maybe I just fix it in my repo.

[sebastianelsner]

When this is the part that adds to the log:

void SysTask::v_appendLog( const std::string & message)
{
    ((SysBlock*)(m_block))->appendTaskLog( std::string("#") + af::itos( getNumber()) + ": " + message + ": "
       + m_syscmd->user_name + ": \"" + m_syscmd->job_name + "\":\n"
       + m_syscmd->command);
}

What I dont understand: Why is the FULL job json stored in m_syscmd->command and not just the event's command like "emailsend -t ... -s..." ?

https://github.com/CGRU/cgru/blob/73409312df3f71ed007aaa1afb18f882014193d1/afanasy/src/server/sysjob.cpp#L99

[timurhai]

For system task incoming command contains all info. System service should use this info to construct command. But I agree, as i told before, it was done long ago, and do not needed any more.

[sebastianelsner]

Ah, I see, the command is done in the python service! I think you can always print the json in the service and see it in the afrender's shell output.

Do you think we can add the commands stdout somehow?

[timurhai]

No, we can't. This is not a usual task. We should not store it.

[timurhai]

We should just remove this + m_syscmd->command

[sebastianelsner]

No, we can't. This is not a usual task. We should not store it.

I dont want to store it. The output can be in the log and can be cut off like anything else.