Recent

Author Topic: Some questions about TEventLog  (Read 3631 times)

Renat.Su

  • Full Member
  • ***
  • Posts: 230
    • Renat.Su
Some questions about TEventLog
« on: November 28, 2018, 02:18:21 pm »
1. When I leave the log type property of TEventLog as ltSystem, the Linux OS logs through the system logging daemon. Accordingly, I can see the log directly in the console via systemctl-l status my_app_daemon. All entries are physically stored in /var/log/user.log (and from all similar applications). To log was written to the folder /var/log /my_app_daemon.log through the system log, what should I do?
2. If I set the type of logging to ltFile whether it is thread-safe (is it possible to create a single instance TEventLog for multiple threads or each thread must use its own)? For example, the log in one file), and it does not use a critical section while log

Renat.Su

  • Full Member
  • ***
  • Posts: 230
    • Renat.Su
Re: Some questions about TEventLog
« Reply #1 on: December 12, 2018, 07:09:11 pm »
On the case, if someone will find in searching for this topic, then answers such:
1. With TEventLog in any way no. It is sewn in class and is not configurable (probably because it is not cross-platform)
Code: Pascal  [Select][+][-]
  1. Procedure TEventLog.ActivateSystemLog;
  2. begin
  3.   CheckIdentification;
  4.   OpenLog(Pchar(Identification),LOG_NOWAIT,LOG_USER); // LOG_USER - type of file log
  5. end;
2. As I understand it is not thread-safe. You must perform synchronization yourself
« Last Edit: December 12, 2018, 10:01:55 pm by Renat.Su »

sash

  • Sr. Member
  • ****
  • Posts: 366
Re: Some questions about TEventLog
« Reply #2 on: December 12, 2018, 09:30:51 pm »
To log was written to the folder /var/log /my_app_daemon.log through the system log, what should I do?

And what was the matter of question?
Lazarus 2.0.10 FPC 3.2.0 x86_64-linux-gtk2 @ Ubuntu 20.04 XFCE

Renat.Su

  • Full Member
  • ***
  • Posts: 230
    • Renat.Su
Re: Some questions about TEventLog
« Reply #3 on: December 12, 2018, 09:59:34 pm »
To log was written to the folder /var/log /my_app_daemon.log through the system log, what should I do?

And what was the matter of question?
Is it possible using TEventLog  to write in own app log (not /var/log/user.log but /var/log/my_app.log) (via system Linux log... that is LogType=ltSystem).
This question I solved for myself by looking at the code of TEventLog

sash

  • Sr. Member
  • ****
  • Posts: 366
Re: Some questions about TEventLog
« Reply #4 on: December 12, 2018, 10:13:51 pm »
Is it possible using TEventLog  to write in own app log (not /var/log/user.log but /var/log/my_app.log) (via system Linux log... that is LogType=ltSystem).

If you need your own file, isn't it logical to set LogType=ltFile then? Why do you need it to be routed through the daemon?
Lazarus 2.0.10 FPC 3.2.0 x86_64-linux-gtk2 @ Ubuntu 20.04 XFCE

Renat.Su

  • Full Member
  • ***
  • Posts: 230
    • Renat.Su
Re: Some questions about TEventLog
« Reply #5 on: December 13, 2018, 04:31:07 am »
If you need your own file, isn't it logical to set LogType=ltFile then? Why do you need it to be routed through the daemon?
That's what I'm doing now, but it's not thread safe, is it?

avra

  • Hero Member
  • *****
  • Posts: 2514
    • Additional info
Re: Some questions about TEventLog
« Reply #6 on: December 13, 2018, 11:01:16 am »
Quote
That's what I'm doing now, but it's not thread safe, is it?
If you want thread safe logging from a GUI application, then you might want to check out MultiLog. I have contributed thread safe TMemoChannel to it, and basic principle of work is explained here:
https://forum.lazarus.freepascal.org/index.php/topic,38851.msg265181.html#msg265181
It uses QueueAsyncCall() so all cals are serialized.
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9792
  • Debugger - SynEdit - and more
    • wiki
Re: Some questions about TEventLog
« Reply #7 on: December 13, 2018, 11:15:36 am »
You can also use LazLoggor: http://wiki.lazarus.freepascal.org/LazLogger
It is thread safe.

Renat.Su

  • Full Member
  • ***
  • Posts: 230
    • Renat.Su
Re: Some questions about TEventLog
« Reply #8 on: December 13, 2018, 04:05:06 pm »
Not a GUI application. And without the LCL. I use it in my libraries, which can also be used in multithreaded applications.

Thanks, I heard about the both mentioned classes for logging, but wanted to do something fpc native and without additional dependencies. I think in such cases it is necessary to add the onlog event, so that the user can make his own logging system

sash

  • Sr. Member
  • ****
  • Posts: 366
Re: Some questions about TEventLog
« Reply #9 on: December 13, 2018, 07:13:59 pm »
Quote
I think in such cases it is necessary to add the onlog event, so that the user can make his own logging system

For a similar purpose (treadsafe) I just made a wrapper with critical sections, though I'd prefer to have essential methods to be virtual, particularly a deepest one in the chain of overloaded calls.
Lazarus 2.0.10 FPC 3.2.0 x86_64-linux-gtk2 @ Ubuntu 20.04 XFCE

Renat.Su

  • Full Member
  • ***
  • Posts: 230
    • Renat.Su
Re: Some questions about TEventLog
« Reply #10 on: December 13, 2018, 07:21:57 pm »
Quote
I think in such cases it is necessary to add the onlog event, so that the user can make his own logging system

For a similar purpose (treadsafe) I just made a wrapper with critical sections, though I'd prefer to have essential methods to be virtual, particularly a deepest one in the chain of overloaded calls.

Yes, I would also do that. But not in this case. But it makes no sense to do this in a library that can be used in both single-threaded and multi-threaded applications. Moreover, even in multithreaded applications it is often possible to manage a simple EventLog in particular cases.

Therefore, in the library itself, I will write the class interface for logging or add OnLog events. In this case, any user, including me, will be able, among other things, to conclude a log procedure in a critical section or to make other synchronization methods

 

TinyPortal © 2005-2018