Hello, Den mån 21 sep. 2020 kl 11:30 skrev Lennard Klein <[email protected]>:
> From what I remember the most feasible way of doing this is taking journald > out of the equation entirely, although this will means /dev/log stuff won't > go into journald at all. > I don't have the exact instructions ready to go, but the basic idea would be > to tell systemd/journald to stop being the owner of /dev/log, and telling > rsyslog to start being so. > For the journald part it probably involves disabling/stopping/masking the > 'systemd-journald-dev-log.socket' unit, although disclaimer: there might be > horrible side-effects. It looks like that it is a bad idea to disable journald completely: https://askbot.fedoraproject.org/en/question/63985/how-to-correctly-disable-journald/: "This is simply not supported. All services systems starts have their stdout/stderr connected to journald, thus journald really needs to run." And in general, my distro (CentOS) is designed to deliver all the messages sent to /dev/log to land in the journald first. And only after that they become readable by rsyslogd (if journald does not drop them in its infinite wisdom) making it a second-class citizen in the system. I do not want to challenge this design of the distro. Expect to face a lot of unpredictable issues if I go this way. > For the rsyslog part I don't remember the method by which rsyslog determines > it's in a systemd/journald system and decides not to open /dev/log itself. > Last disclaimer/warning: if you do get it to a state that seems working, keep > in mind there's logging that exists *only* within journald as it is never > written to /dev/log but delivered through other mechanisms. Yes. I am very well aware of this. In fact I have several processes developed in-house which generate tons of logs. they log through syslog and use glibc functions to access syslog. I want their messages to be logged efficiently and without drops. When I tested logging through /run/systemd/journal/syslog with "loggen" utility from syslog-ng suite, it demonstrated very promising results (around 18K msg of size 512 bytes per second) while the same test through /dev/log started to show dropped messages already at 50 msg/second (Storage=none was set in journald.conf and I validated with journalctl that nothing has been written to journald). I do not blame journald too much as I tested quite an ancient version (included in systemd 219, more than 5 years old). I hope this issue is fixed in the more recent systemd. Unfortunately I do not have an option to upgrade systemd in the environment our software is run. It looks like that the best option in my case is to modify in-house apps to log directly through rsyslogd's /run/systemd/journal/syslog. And let the rest of the logging go through journald and /dev/log. > On 20/09/2020, 18:14, "rsyslog on behalf of Vitaly Repin via rsyslog" > <[email protected] on behalf of [email protected]> > wrote: > > Hello, > > I have a system with systemd which forwards log messages from /dev/log > to /run/systemd/journal/syslog . Unfortunately journald drops log > messages quite often and they do not reach rsyslogd. > > I want to log to rsyslog directly from my application but glibc does > not allow to select the unix socket to send messages to. Path /dev/log > is hardcoded in bits/syslog-path.h and later used in misc/syslog.c > > What options do I have to log to rsyslog directly without having > journald in between? > > I consider cherry picking syslog logging implementation from glibc to > a separate library which will have a function to set a path to the > unix socket where syslog daemon listens. > May be such library already exists? > > Thanks in advance for all the advices. > -- > WBR & WBW, Vitaly > ______________________________________________ > > > This email is from Equinix (EMEA) B.V. or one of its associated companies in > the territory from where this email has been sent. This email, and any files > transmitted with it, contains information which is confidential, is solely > for the use of the intended recipient and may be legally privileged. If you > have received this email in error, please notify the sender and delete this > email immediately. Equinix (EMEA) B.V.. Registered Office: Amstelplein 1, > 1096 HA Amsterdam, The Netherlands. Registered in The Netherlands No. > 57577889. -- WBR & WBW, Vitaly _______________________________________________ rsyslog mailing list https://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com/professional-services/ What's up with rsyslog? Follow https://twitter.com/rgerhards NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
