Log file names

[Dimitar Misev]

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

3c1bb3ad-f89a-4533-878a-2fbc99f4bb50.026737.log
3e34023a-c39e-4a1d-943c-0f36966e9b44.026738.log
408a8ea9-9033-4a18-a168-d77c979f92fc.026730.log
583cec65-a4e6-47a6-a9e0-409d9af8469d.026736.log
645a6898-a003-4d05-a71d-9ca4d90a2ce3.026731.log
6edd0118-b6c9-4680-b6c2-bd6ff27f2203.026734.log
6ef4a634-4d75-4c9a-94df-9b4ccd374028.026735.log
77974850-a34d-464d-9219-f7d08a7efe8c.026732.log
91bfca84-0b25-43f0-8d92-29fc2c4dc527.026733.log
c49bb7bf-ffc7-495b-8e13-1a5c4d8f96dc.029071.log
nohup.out
rasmgr.26561.log

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:

rasserver.3c1bb3ad-f89a-4533-878a-2fbc99f4bb50.026737.log
rasserver.3e34023a-c39e-4a1d-943c-0f36966e9b44.026738.log
...

[Alex Dumitru]

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.

[Dimitar Misev]

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.

[Alex Dumitru]

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.

[Peter Baumann]

friendly amendment (as discussed by Alex):

rasserver.<server_id>.pid.log

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.

[Alex Toader]

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?

[Peter Baumann]

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.

[Dimitar Misev]

Sulav has submitted a patch to change the server logs from

<server_id>.<pid>.log

to

rasserver.<server_id>.<pid>.log

[Peter Baumann]

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

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

[Dimitar Misev]

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.

[Peter Baumann]

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

[Bang Pham Huu]

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