| 14 Jul 2023 |
 bazsi77 | The same happens if you use a disk buffer. | 07:13:42 |
| bazsi77 | You can change that timestamp though by using a custom template on output, or even with date-parser() | 07:16:03 |
 vostrelt | Thanks! I will try using the file destination. | 07:22:49 |
| vostrelt | So the timestamp can be part of message text then? | 07:23:36 |
| bazsi77 | The timestamp is part of the default formatting syslog-ng sends out messages with. The timestamp there is coming from the message timestamp being sent. | 07:24:30 |
| bazsi77 | The default template is: template("$DATE $HOST $MSGHDR$MSG\n") | 07:25:10 |
| bazsi77 | $DATE expands to either a simplified BSD style timestamp or an ISO 8601 timestamp, but can be customized. | 07:25:58 |
| bazsi77 | * $DATE expands to either a simplified BSD style timestamp or an ISO 8601 timestamp, but can be customized using the ts-format() option | 07:26:12 |
| bazsi77 | Syslog-ng always parses the incoming message and then regenerates it on output. You can change any of the fields and then have syslog-ng sent a changed message | 07:26:53 |
| bazsi77 | But as I understand you don't want to change the message, rather there's this timing issue, where during early boot you don't yet know where you want to deliver messages, this comes somewhat later in the boot process. | 07:28:02 |
| bazsi77 | You just have to store the messages in this interim period. If you have journald you could just leave them there and only establish the reading of the journal once the boot up is complete. If you don't have journal, just a plain /dev/log socket, you need to read that during bootup and store the messages somewhere. This could be a syslog-ng disk based buffer file or as I wrote earlier a simple text file where we dump the bootup messages. | 07:30:12 |
| bazsi77 | The disk based buffer is less applicable as for that you'd need to know the final destination, it just isn't available yet. | 07:30:43 |
| bazsi77 | The file destination/file source combination fits this case better imho, as you can establish the sending of the messages any time after the boot is complete. You will just have to install the appropriate source/destination/log rules into your syslog-ng config and reload syslog-ng | 07:32:06 |
| bazsi77 | Btw, you can include directories from syslog-ng.conf so you could just drop a file in that directory, without having to sed/change config files. | 07:32:52 |
| vostrelt | Thanks for detailed reply! How can it be done so the syslog reads contents of the file source with bootup messages? It sends only messages that are new in the file. | 08:17:27 |
| bazsi77 | I'd start up the host with just a system() source that writes the output to /var/log/boot.log. once you are ready to send messages to the final destination, I would remove the log path from the system() source to boot.log and have that sent to the real destination and add a source that reads boot.log and sends it to the same destination. E.g. replace the old rule with the new ones. | 08:45:57 |
| vostrelt | add a source that reads boot.log and sends it to the same destination | 09:07:08 |
| vostrelt | That's what I do not know how to achieve. | 09:07:32 |
| vostrelt | What source reads file with messages and correctly parses it (priority, timestamp)? If I use file source it only reads new messages. | 09:08:47 |
| bazsi77 | True, it only reads new messages. But if you remove it first it will start from the beginning | 09:19:06 |
| vostrelt | OK, thanks. And for the parsing - what should be the format of stored messages? I guess the best would be to use flags(no-parse) for the system source and write them to the file as they arrive? | 09:26:03 |
| bazsi77 | I'd think that you could just specify a template on the destination to include the <$PRI> prefix for lines in that file
The file source should be able to parse that | 09:28:42 |
| vostrelt | I got it working, thanks a lot for your time - and work on the syslog-ng! | 09:39:15 |
| 16 Jul 2023 |
|  Helber Maciel Guerra joined the room. | 01:04:38 |
| 17 Jul 2023 |
|  Stroker joined the room. | 07:17:01 |
| vostrelt | bazsi77 Just for your information I used the pipe driver in the end. It seems to work well and I don't have to take care of the file. | 10:48:05 |
| bazsi77 | Named pipes have a limited capacity though. So you might be storing those messages in the syslog-ng memory queue at the end. | 10:56:22 |
| vostrelt | That's true, I'm using log-fifo-size, thinking about the disk-buffer. | 11:54:21 |
| bazsi77 | do you retain this log path even after the final destination becomes available? | 11:56:52 |
| bazsi77 | e.g. do you keep sending all local messages through the pipe? | 11:57:06 |
