#1291 closed defect (fixed)

Log file names

Reported by: dmisev Owned by:
Priority: major Milestone: 9.3
Component: rasmgr Version: development
Keywords: Cc: pbaumann, bphamhuu, atoader, mdumitru, vmerticariu, gmerticariu
Complexity: Medium

Description (last modified by dmisev)

The logs in $RMANHOME/log look like this now:


The naming is a bit inconsistent, and at first sight it's not immediately clear what the c49bb7bf-ffc7-495b-8e13-1a5c4d8f96dc.029071.log files are.

The rasserver logs should be changed to have rasserver as prefix in the file names:


Change History (12)

comment:1 follow-up: Changed 16 months ago by mdumitru

Adding a timestamp to the name will only make matter worse. This will be the timestamp of the file creation, *not* of the last log entry, and will confuse users thinking that the last timestamp is where the log is which is almost never the case.

N*.log has some semantics behind it, so we can revert to that.

The initial problem with having N* in the log name was that with the new protocol you can specify in rasmgr.conf that you want a maximum of 50 servers and a minimum of 5 (which allows rasmgr to use minimal resources while being able to answer 50 queries at the same time) on port 7002-7052 without explicitly naming them, thus a name had to be generated.

comment:2 in reply to: ↑ 1 Changed 16 months ago by dmisev

The semantics of N*.log is just as confusing (and useless, especially with the new rasmgr), I'd really not revert to that.

At least we can have rasserver.<server_id>.log so that it's somewhat consistent with rasmgr.<pid>.log, if the consensus is against timestamps in the file name.

Yet another alternative could be to have static server names rasserver1, rasserver2, .., rasserver50, .., and correspondingly static log file names rasserver<N>.log, which are being continually appended on server restart. The easylogging rotation would work pretty well in this case I guess.

Last edited 16 months ago by dmisev (previous) (diff)

comment:3 Changed 16 months ago by mdumitru

rasserver.<server_id>.log sound like a good idea, +1 from my side.

Regarding static naming, that would be a bit complicated, with uuids or pids you don't care about the possibility of collision as would be with rasserver1,...50. With automatic load balancing, there are multiple threads that open and close servers (the load balancer, the server crash handler etc) and we would need to be very careful on locking and so on. Plus we need to make sure we don't override an existing log which makes it even worse.

comment:4 Changed 16 months ago by pbaumann

friendly amendment (as discussed by Alex):


that is close to what we had and makes sense.

Actually, earlier discussion was to define the dynamic servers through a user-chosen name containing a %d for number expansion. This has silently be replaced with a UUID which serves to achieve uniqueness, but for the price of something totally clumsy for human eyes.

also +1 for getting in sync with rasmgr log file naming.

comment:5 Changed 16 months ago by atoader

If we implement the option with the user-chosen name, what happens if the user defines an invalid name?
Let us say that rasserver.%d.log would be a correct name. What happens if the user defines "rasserver.log" and forgets the "%d"? Do we give an error at the time the servers are defined?

comment:6 Changed 16 months ago by pbaumann

hm, in my understanding no %d means: a single service. Hence, if there is an inconsistency (such as multiple ports) then an error should be issued and this line should be not executed. Comments/improvements welcome.

comment:7 Changed 16 months ago by dmisev

  • Description modified (diff)

comment:8 Changed 15 months ago by dmisev

Sulav has submitted a patch to change the server logs from




comment:9 Changed 15 months ago by pbaumann

a good move; this changed behavior should be explained on the lists.

PS: just out of principle: patch does not contain any test.

comment:10 Changed 15 months ago by dmisev

He tested it manually and showed me a screenshot of the new log filenames. It would be difficult to devise a reliable automated test and is not worth it in this case in my opinion.

comment:11 Changed 15 months ago by pbaumann

I agree in this case, just make sure it won't become habit ;-)

comment:12 Changed 13 months ago by bphamhuu

  • Milestone changed from 10.0 to 9.3
  • Resolution set to fixed
  • Status changed from new to closed

I pull the new update and see Sulav's patch, close ticket.

Note: See TracTickets for help on using tickets.