[INSTRM-113] Archiver log is saturating /tmp/ Created: 17/May/17  Updated: 30/May/18  Resolved: 30/May/18

Status: Done
Project: Instrument control development
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: arnaud.lefur Assignee: arnaud.lefur
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates INSTRM-42 [ics_archiver] Write log files elsewh... Won't Fix

 Description   

Until now archiver log was created on mhs machine under /tmp/ (default parameters)
However there is only 10 Gb available on this partition.
As a result after a month, the folder is saturated and causes the archiver to crash.

Firstly, do we want to keep those logs ? To be honest we haven't done it so far.
Secondly, is there different level of logging ? Because, currently the logfile size is growing really quickly, even quicker than the database itself.

For now, it's save locally under another partition(500GB), but we could also use our NFS mount.

Any thoughts ?

 Comments   
Comment by cloomis [ 17/May/17 ]

I think the logs are basically worthless.

Comment by arnaud.lefur [ 23/May/17 ]

committed https://github.com/Subaru-PFS/ics_archiver/commit/dd464817909a79c3321c539b9c39470a4cd6d64b

Comment by shimono [ 23/May/17 ]

why not to have ticket specific branch??

Comment by arnaud.lefur [ 23/May/17 ]

Yes, I could have done it that way cloomis ?
To be clear you mean :

  • create a branch named 'INSTRM-113'
  • make my local change
  • merge with master whenever the problem is solved
Comment by cloomis [ 23/May/17 ]

Yes. Specifically:

  • git checkout -b tickets/INSTRM-113
  • work work work, all checked in.
  • git checkout master
  • git merge --no-ff tickets/INSTRM-113
Comment by shimono [ 27/May/17 ]

I believe, we'd better

  • to make things possible to be tracked, especially for records at later phase including after delivery to Subaru. (somehow detailed) records of development history is a key for people working on maintenance to understand how/why code is organized as it is
  • not to make multiple working versions in different branches, both for reducing maintenance load of codes and making people easy to install/use
  • to have one PR per one modification, for getting clear review on both code and planning/functionality in quality and consistency point of view
Comment by hassan [ 30/May/18 ]

Changes long since merged. Considered resolved.

Generated at Sat Feb 10 16:21:40 JST 2024 using Jira 8.3.4#803005-sha1:1f96e09b3c60279a408a2ae47be3c745f571388b.