Usage of logging - TANGO Controls

# 1 year ago
philippeg	Hello tangoers, reading the tango doc on Logging, I made a few tests and have a few questions: 1. Logging properties for Starter should be set in jive in Device tab, and then in `dserver/Starter/COMPUTERNAME` and not in `Starter/COMPUTERNAME/Starter then tango/admin/COMPUTERNAME` Am I right ? If not, when should we add Logging properties into dserver or Starter (and more generally, into DeviceServerName) ? If yes, this could be confusing, but I did not find anything on it into the doc 2. I did not really find anything on `Current logging level` and `Current logging target` properties. Did I miss something into the doc? Regards - Philippe Edited 1 year ago

# 1 year ago

Hello tangoers,
reading the tango doc on Logging, I made a few tests and have a few questions:

1. Logging properties for Starter should be set in jive in Device tab, and then in `dserver/Starter/COMPUTERNAME` and not in `Starter/COMPUTERNAME/Starter then tango/admin/COMPUTERNAME`

Am I right ?
If not, when should we add Logging properties into dserver or Starter (and more generally, into DeviceServerName) ?
If yes, this could be confusing, but I did not find anything on it into the doc

2. I did not really find anything on `Current logging level` and `Current logging target` properties.

Did I miss something into the doc?
Regards

- Philippe

Edited 1 year ago

# 1 year ago
Reynald	philippeg Hello tangoers, reading the tango doc on Logging, I made a few tests and have a few questions: 1. Logging properties for Starter should be set in jive in Device tab, and then in `dserver/Starter/COMPUTERNAME` and not in `Starter/COMPUTERNAME/Starter then tango/admin/COMPUTERNAME` Am I right ? That does not sound right to me. How did you come to this conclusion from your tests? If you want to get some logging about what's going on in the cppTango library, you indeed need to enable the logs in DEBUG level on the admin device, this is where you'll get the logs coming from the cpptango library. The logs specific to the device of the Starter class (logs from the Starter class code) should be in the logs configured for tango/admin/COMPUTERNAME device. philippeg If not, when should we add Logging properties into dserver or Starter (and more generally, into DeviceServerName) ? You add logging properties for the dserver (admin) device if you want to see what's going on with the admin device or if you want to see the logs coming from the cppTango library (you have to be in DEBUG mode to see these logs and they will be associated to dserver/Starter/COMPUTERNAME device). You add logging properties for the Starter device (tango/admin/COMPUTERNAME) if you want to see the logs coming from the Starter class code. philippeg 2. I did not really find anything on `Current logging level` and `Current logging target` properties. Did I miss something into the doc? Regards Maybe it's not in the doc. The doc can always be improved. Many thanks for all the doc improvements suggestions you made by the way. The Current logging level corresponds to the current logging level (Surprise! ). If you change it, it will change the current logging level for the associated device but if the device (or device server) is restarted, the current logging level will be reset to the value in logging level property. Same principle for the `Current logging target`, this affects only the current logging target for the current session. If you restart your device or device server, this will be lost and the `logging target` property will be used to set the logging target during the device server initialization. So basically, as far as I have understood, the `Current logging xxx` properties are just temporary properties which will be lost/overwritten at the next restart of the device or device server. I think they are not even real properties but jive provide this as a way to change the current logging level and current logging target but the ` Current logging xxx` are not saved in the Tango Database. ` logging target` and `logging level` properties are the ones used to configure the logging during the device initialization in a persistent way. Rosenberg's Law: Software is easy to make, except when you want it to do something new. Corollary: The only software that's worth making is software that does something new.

# 1 year ago

Reynald

philippeg
Hello tangoers,
reading the tango doc on Logging, I made a few tests and have a few questions:

1. Logging properties for Starter should be set in jive in Device tab, and then in `dserver/Starter/COMPUTERNAME` and not in `Starter/COMPUTERNAME/Starter then tango/admin/COMPUTERNAME`

Am I right ?

That does not sound right to me. How did you come to this conclusion from your tests?
If you want to get some logging about what's going on in the cppTango library, you indeed need to enable the logs in DEBUG level on the admin device, this is where you'll get the logs coming from the cpptango library. The logs specific to the device of the Starter class (logs from the Starter class code) should be in the logs configured for tango/admin/COMPUTERNAME device.

philippeg
If not, when should we add Logging properties into dserver or Starter (and more generally, into DeviceServerName) ?

You add logging properties for the dserver (admin) device if you want to see what's going on with the admin device or if you want to see the logs coming from the cppTango library (you have to be in DEBUG mode to see these logs and they will be associated to dserver/Starter/COMPUTERNAME device).

You add logging properties for the Starter device (tango/admin/COMPUTERNAME) if you want to see the logs coming from the Starter class code.

philippeg
2. I did not really find anything on `Current logging level` and `Current logging target` properties.

Did I miss something into the doc?
Regards

Maybe it's not in the doc. The doc can always be improved. Many thanks for all the doc improvements suggestions you made by the way.
The Current logging level corresponds to the current logging level (Surprise! smile

). If you change it, it will change the current logging level for the associated device but if the device (or device server) is restarted, the current logging level will be reset to the value in logging level property.
Same principle for the `Current logging target`, this affects only the current logging target for the current session. If you restart your device or device server, this will be lost and the `logging target` property will be used to set the logging target during the device server initialization.

So basically, as far as I have understood, the `Current logging xxx` properties are just temporary properties which will be lost/overwritten at the next restart of the device or device server.
I think they are not even real properties but jive provide this as a way to change the current logging level and current logging target but the ` Current logging xxx` are not saved in the Tango Database.
` logging target` and `logging level` properties are the ones used to configure the logging during the device initialization in a persistent way.

Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.

# 1 year ago
philippeg	Reynald That does not sound right to me. How did you come to this conclusion from your tests? If you want to get some logging about what's going on in the cppTango library, you indeed need to enable the logs in DEBUG level on the admin device, this is where you'll get the logs coming from the cpptango library. The logs specific to the device of the Starter class (logs from the Starter class code) should be in the logs configured for tango/admin/COMPUTERNAME device. Sorry, I probably misunderstood the behaviour while looking at the upcase bug. Reynald So basically, as far as I have understood, the `Current logging xxx` properties are just temporary properties which will be lost/overwritten at the next restart of the device or device server. I think they are not even real properties but jive provide this as a way to change the current logging level and current logging target but the ` Current logging xxx` are not saved in the Tango Database. ` logging target` and `logging level` properties are the ones used to configure the logging during the device initialization in a persistent way. It's interesting, thank you for those details. I understand that "Current logging…" is more a read-only property for information, and that if it is modified while the device is running, it will not modify the way logging will be done for this session. Am I right? - Philippe

# 1 year ago

philippeg

Reynald
That does not sound right to me. How did you come to this conclusion from your tests?
If you want to get some logging about what's going on in the cppTango library, you indeed need to enable the logs in DEBUG level on the admin device, this is where you'll get the logs coming from the cpptango library. The logs specific to the device of the Starter class (logs from the Starter class code) should be in the logs configured for tango/admin/COMPUTERNAME device.

Sorry, I probably misunderstood the behaviour while looking at the upcase bug.

Reynald
So basically, as far as I have understood, the `Current logging xxx` properties are just temporary properties which will be lost/overwritten at the next restart of the device or device server.
I think they are not even real properties but jive provide this as a way to change the current logging level and current logging target but the ` Current logging xxx` are not saved in the Tango Database.
` logging target` and `logging level` properties are the ones used to configure the logging during the device initialization in a persistent way.

It's interesting, thank you for those details.

I understand that "Current logging…" is more a read-only property for information, and that if it is modified while the device is running, it will not modify the way logging will be done for this session.

Am I right?

- Philippe

# 1 year ago
Reynald	philippeg I understand that "Current logging…" is more a read-only property for information, and that if it is modified while the device is running, it will not modify the way logging will be done for this session. Am I right? No. Sorry. If you modify the current logging … properties in jive, it will modify the logging for the current session but these new logging parameters will be lost if the device server/device is restarted. Rosenberg's Law: Software is easy to make, except when you want it to do something new. Corollary: The only software that's worth making is software that does something new.

# 1 year ago

Reynald

philippeg
I understand that "Current logging…" is more a read-only property for information, and that if it is modified while the device is running, it will not modify the way logging will be done for this session.

Am I right?

No. Sorry. If you modify the current logging … properties in jive, it will modify the logging for the current session but these new logging parameters will be lost if the device server/device is restarted.

Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.

# 1 year ago
philippeg	Reynald philippeg I understand that "Current logging…" is more a read-only property for information, and that if it is modified while the device is running, it will not modify the way logging will be done for this session. Am I right? No. Sorry. If you modify the current logging … properties in jive, it will modify the logging for the current session but these new logging parameters will be lost if the device server/device is restarted. Don't be sorry, it allows me to better understand. So it allows to dynamically modify the logging behaviour for current session, even better Will try to add some details into the doc on this topic. Thank you again Reynald! - Philippe

# 1 year ago

philippeg

Reynald
philippeg
I understand that "Current logging…" is more a read-only property for information, and that if it is modified while the device is running, it will not modify the way logging will be done for this session.

Am I right?

No. Sorry. If you modify the current logging … properties in jive, it will modify the logging for the current session but these new logging parameters will be lost if the device server/device is restarted.

Don't be sorry, it allows me to better understand.
So it allows to dynamically modify the logging behaviour for current session, even better smile

Will try to add some details into the doc on this topic.

Thank you again Reynald!

- Philippe

# 1 year ago
philippeg	I noticed another behaviour I do not understand: sys/databaseds/2 is configured with Logging level=ERROR and has been restarted with `/usr/sbin/service tango-db restart` However, Current logging level is set to WARNING. I set it manually to ERROR but I wonder how to restart this device. - Philippe

# 1 year ago
Reynald	Hi Philippe, I cannot explain what you're seeing but I can see the same behaviour with the first tests I've done with the DatabaseDS. This device server is really special so there might be some hard coded values for the logging of this DS? If you consider this as an issue that you would like to be solved, please create an issue on the TangoDatabase gitlab repository. Kind regards, Reynald Rosenberg's Law: Software is easy to make, except when you want it to do something new. Corollary: The only software that's worth making is software that does something new.

# 1 year ago

Reynald

Hi Philippe,

I cannot explain what you're seeing but I can see the same behaviour with the first tests I've done with the DatabaseDS.
This device server is really special so there might be some hard coded values for the logging of this DS?
If you consider this as an issue that you would like to be solved, please create an issue on the TangoDatabase gitlab repository.

Kind regards,
Reynald

Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.

# 1 year ago
Reynald	Hi Philippe, I had a deeper look at what you observed. What you observed is really a specificity of the Tango Database server which is different than the other devices. What you are seeing is coming from the fact that the Tango Database server is using the Tango C++ library as if there was no Tango Database: See https://gitlab.com/tango-controls/TangoDatabase/-/blob/Database-Release-5.16/main.cpp#L70 So it is not looking in the Tango Database for the logging configuration of its Tango device. So if the '-v' option was not used at the command line, DeviceImpl::init_logger returns without having set any logging level (See https://gitlab.com/tango-controls/cppTango/-/blob/9.4.0/cppapi/server/devicelog.cpp#L186-192). So it's using the default logging level in this use case, which is set to WARNING (See https://gitlab.com/tango-controls/cppTango/-/blob/9.4.0/cppapi/server/devicelog.cpp#L135-136) All the other devices (when configured to use the Tango DB) will try to get their logging configuration from the Tango Database and if no logging config is present in the Tango DB and -v option was not use at the command line, the logging level is set to OFF in this use case (See https://gitlab.com/tango-controls/cppTango/-/blob/9.4.0/cppapi/server/devicelog.cpp#L174 and https://gitlab.com/tango-controls/cppTango/-/blob/9.4.0/cppapi/server/devicelog.cpp#L226). If you consider this Tango Database server specificity is an issue, please create an issue in the TangoDatabase Gitlab repository. Kind regards, Reynald Rosenberg's Law: Software is easy to make, except when you want it to do something new. Corollary: The only software that's worth making is software that does something new. Edited 1 year ago

# 1 year ago

Reynald

Hi Philippe,

I had a deeper look at what you observed.

What you observed is really a specificity of the Tango Database server which is different than the other devices.

What you are seeing is coming from the fact that the Tango Database server is using the Tango C++ library as if there was no Tango Database: See https://gitlab.com/tango-controls/TangoDatabase/-/blob/Database-Release-5.16/main.cpp#L70

So it is not looking in the Tango Database for the logging configuration of its Tango device.
So if the '-v' option was not used at the command line, DeviceImpl::init_logger returns without having set any logging level (See https://gitlab.com/tango-controls/cppTango/-/blob/9.4.0/cppapi/server/devicelog.cpp#L186-192).
So it's using the default logging level in this use case, which is set to WARNING (See https://gitlab.com/tango-controls/cppTango/-/blob/9.4.0/cppapi/server/devicelog.cpp#L135-136)

All the other devices (when configured to use the Tango DB) will try to get their logging configuration from the Tango Database and if no logging config is present in the Tango DB and -v option was not use at the command line, the logging level is set to OFF in this use case (See https://gitlab.com/tango-controls/cppTango/-/blob/9.4.0/cppapi/server/devicelog.cpp#L174 and https://gitlab.com/tango-controls/cppTango/-/blob/9.4.0/cppapi/server/devicelog.cpp#L226).

If you consider this Tango Database server specificity is an issue, please create an issue in the TangoDatabase Gitlab repository.

Kind regards,
Reynald

Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.

Edited 1 year ago

# 1 year ago
philippeg	Hi Reynald, thank you for this detailed answer. It's interesting to understand the behaviour and it does not need an issue in my opinion. I'll thnik about it if it needs a doc evolve and if I can make a merge request. Regards. - Philippe

# 1 year ago
philippeg	Hello, I have another question: in TdbArchiver (ArchivingRoot device), I defined `Logging_target` to `file::/tmp/tango-tango/tdbarchiver/01/01.log`. However, it writes its login another directory (`/var/archivage/tdb/01` defined in dsPath, dbPath and diaryPath). Is it a normal behaviour? Regards - Philippe Edited 1 year ago