LogC issueshttps://gitlab.nic.cz/turris/logc/-/issues2022-06-06T14:04:06+02:00https://gitlab.nic.cz/turris/logc/-/issues/10Add journald support2022-06-06T14:04:06+02:00Karel KociAdd journald supportWe should add optional support for journald as that is not that hard and cover a lot of possible deployment. The inclusion should be optional but if host has systems we should allow usage of it.
The source for https://www.freedesktop.or...We should add optional support for journald as that is not that hard and cover a lot of possible deployment. The inclusion should be optional but if host has systems we should allow usage of it.
The source for https://www.freedesktop.org/software/systemd/man/sd_journal_print.html#https://gitlab.nic.cz/turris/logc/-/issues/9LogC to LogC pipe logging2021-06-04T16:07:45+02:00Karel KociLogC to LogC pipe loggingThis is supposed to be a logging target/format that can be read by different LogC instance and interpreted. The use of this is when we work in multiple programs we could redirect `stderr` to pipe after fork and read that pipe to propagat...This is supposed to be a logging target/format that can be read by different LogC instance and interpreted. The use of this is when we work in multiple programs we could redirect `stderr` to pipe after fork and read that pipe to propagate logs to terminal handled by top-level program and logger.https://gitlab.nic.cz/turris/logc/-/issues/8Stream to lines helper object2021-09-09T15:01:11+02:00Karel KociStream to lines helper objectIt turns out that it is a common task to accumulate read text until we reach the end of the line and then log that (or potentially handle it in another way). This is the case when we read text from a file, pipe from subprocess or even wh...It turns out that it is a common task to accumulate read text until we reach the end of the line and then log that (or potentially handle it in another way). This is the case when we read text from a file, pipe from subprocess or even when we integrate with some other logging method.
It might make sense to implement it as `fopencookie` handle as in general what we want is `write` function that accumulates text until we get the end of the line. It is a question if-then callback should happen or if a user should call a function that checks for a new line (I think that the first is preferable as that decreases the amount of stored data).
It might also be interesting to have mode when we keep last X number of bytes in buffer. This might be beneficial for applications that run subprocesses and want to receive end of their output on failure (where commonly error resides).https://gitlab.nic.cz/turris/logc/-/issues/6Add support for subprocess2020-11-09T11:34:56+01:00Karel KociAdd support for subprocessWe should somehow have primary process and allow subprocesses to print or to be suppressed. It should be also visible that output is from subprocess and which one (probably using PID).We should somehow have primary process and allow subprocesses to print or to be suppressed. It should be also visible that output is from subprocess and which one (probably using PID).https://gitlab.nic.cz/turris/logc/-/issues/2Make library thread safe2020-10-08T10:22:48+02:00Karel KociMake library thread safeLog handler has to be thread safe. This includes `log` structure fields access to be atomic and locking for outputs.
* [ ] make `struct log` members atomic
* [ ] lock output when writing message in to it (we should use both flock to pre...Log handler has to be thread safe. This includes `log` structure fields access to be atomic and locking for outputs.
* [ ] make `struct log` members atomic
* [ ] lock output when writing message in to it (we should use both flock to prevent collision with other outputs as well as internal lock if that fails)
* [ ] make that configurable to not add unnecessary load to single-thread apps