Project

General

Profile

Bug #27968

Add method to handle logs for jobs that produce huge logging output

Added by Vladimir Vinogradenko over 1 year ago. Updated about 1 year ago.

Status:
Done
Priority:
Nice to have
Assignee:
Vladimir Vinogradenko
Category:
Middleware
Target version:
Severity:
New
Reason for Closing:
Reason for Blocked:
Dependent on a related task to be completed
Needs QA:
Yes
Needs Doc:
No
Needs Merging:
No
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

There are a few bugs when rsync does not work properly and user can't understand what's going on because we redirect rsync logs to /dev/null because they are huge. E.g.:

It's not good to store them in RAM (as job result) and it's not appropriate to dump them through websocket API and hang user's browser.

I propose to:
  • Store output of jobs like these in some temporary file (where? I am sadly still not familiar with how FreeNAS filesystem is set up)
  • Return first 5 and last 5 lines of these logs with "..." between them and comment like See the rest at /var/log/jobs/6.log as job result

If agreed, please assign back to me


Related issues

Related to FreeNAS - Bug #35797: Fix args error when adding Cloud Sync Task in new UIDone

Associated revisions

Revision eb9ecc9e (diff)
Added by Vladimir Vinogradenko over 1 year ago

Logs for jobs that produce huge logging output

@job(logs=True)

Use `job.logs_fd` inside job to write logs

Inspect `logs_path` in job and `logs_excerpt` in finished job

Ticket: #27968

History

#1 Updated by William Grzybowski over 1 year ago

  • Assignee changed from William Grzybowski to Vladimir Vinogradenko

Its not clear to me if you want to do that in general or in a job-by-job basis.

I have the feeling that telling people to read a file somewhere is not going to be the best solution, I think if at all possible we should have in mind that the user do not know how to access system files (or how to SSH in).

Perhaps we should come up with a way to raise an error with a specific code that will tell which files should be shown? Then the client (UI) could potentially decide what to do with it (stat it then show it all, or just part of it).

Thats just an idea, I am not convinced of either. Thoughts?

#2 Updated by Dru Lavigne over 1 year ago

  • Category set to Middleware
  • Target version set to 11.3

#3 Updated by Vladimir Vinogradenko over 1 year ago

Its not clear to me if you want to do that in general or in a job-by-job basis.

I want to mark specific jobs like job(logs=True) and then use job.logs_fd to write logs inside job.

I have the feeling that telling people to read a file somewhere is not going to be the best solution, I think if at all possible we should have in mind that the user do not know how to access system files (or how to SSH in).

Perhaps we should come up with a way to raise an error with a specific code that will tell which files should be shown? Then the client (UI) could potentially decide what to do with it (stat it then show it all, or just part of it).

I agree with you. But files still seem to be the only appropriate mechanism. We can store file path in logs_path field of the running/completed job and offer user to download it through browser.

I still wonder what is the appropriate filesystem location for these files.

#4 Updated by Vladimir Vinogradenko over 1 year ago

  • Status changed from Not Started to Blocked
  • Reason for Blocked set to Waiting for feedback

#5 Updated by William Grzybowski over 1 year ago

  • Status changed from Blocked to Not Started
  • Reason for Blocked deleted (Waiting for feedback)

Ok, sounds reasonable to me.

As far as the file location, perhaps we can store them in /tmp/middlewared/ for now, since the jobs are currently not persistent.

Note that we do not keep more than 1000 jobs in memory so we should take care of remove these files when they are removed from the queue.

#6 Updated by Vladimir Vinogradenko over 1 year ago

  • Status changed from Not Started to In Progress

#7 Updated by Vladimir Vinogradenko over 1 year ago

  • Status changed from In Progress to Done

#8 Updated by Dru Lavigne over 1 year ago

  • Subject changed from Logs for jobs that produce huge logging output to Add method to handle logs for jobs that produce huge logging output
  • Target version changed from 11.3 to 11.2-BETA1
  • Needs Doc changed from Yes to No
  • Needs Merging changed from Yes to No

#9 Updated by Dru Lavigne about 1 year ago

  • Status changed from Done to Ready for Testing

#12 Avatar?id=55038&size=24x24 Updated by Zackary Welch about 1 year ago

  • Status changed from Ready for Testing to Blocked

#13 Avatar?id=55038&size=24x24 Updated by Zackary Welch about 1 year ago

  • Related to Bug #35797: Fix args error when adding Cloud Sync Task in new UI added

#14 Updated by Dru Lavigne about 1 year ago

  • Status changed from Blocked to Done

Also available in: Atom PDF