Re: [systemd-devel] A way to better integrate rsyslog into systemd?
El vie, 3 de oct 2014 a las 10:55 , Aleksei Besogonov alex.besogo...@gmail.com escribió: With all the recent noise about systemd abusing its position with the way it takes over logging I’ve been thinking about a way to solve it. As far as I understand the following holds: - Systemd takes over /dev/log socket which is normally served by rsyslog (or other syslog daemon). - That’s really required to make journald-based logging transparent and coherent for most use-cases. However, it creates a problem for log-heavy applications, because of additional roundtrips between processes. So far I’ve heard people actually using LD_PRELOAD tricks to hack around applications opening the /dev/log file inside the syslog(2). As far as I understand, it’s also not really configurable - the '/dev/log’ string is hardcoded into various libcs (e.g.: http://git.musl-libc.org/cgit/musl/tree/src/misc/syslog.c). Recent versions of rsyslog can directly read journald files. But that’s still suboptimal solution, because it introduces an unnecessary layer. Namespacing each daemon to provide its own /dev tree with custom /dev/log sockets is possible, but impractical. So I propose the following solution: 1) Add an option to systemd units to allow passing opened /dev/log sockets to rsyslog (using the usual SOL_SOCKET mechanism). This seems annoyingly roundabout. A more straightforward method would be to just have rsyslog listen on /dev/log. Obviously that is the original method, and journald changed it, and there are reasons for that. I am pretty sure one of the main selling points of journald is the extreme catch all nature: from syslog messages, to daemon stdout/in, to X.Org logs, etc. You can easily access those logs from one place and with one set of tools. If the authors wanted syslog messages to not be intercepted by journald, I do not think they would have had journald listen on /dev/log. Of course, I can not speak for them, it just seems reasonable that that is their feelings about. An alternate reason for how journald works is so that all syslogs do not have to re-implement the forwarding logic. 2) Add the corresponding functionality to rsyslog. It should listen on a special socket (perhaps /run/rsyslog/socket_server ?) and treat all the incoming sockets as if they were accepted from /dev/log. Well it already is supposed to listen on /run/systemd/journal/syslog like that is /dev/log; that is how the messages are forwarded. It would also solve the problems with rsyslog using its own SCM_CREDENTIALS lookups. Can it not simply recognize it is listening on /run/systemd/journal/syslog and skip any kind of extra steps? Or would that cause sec issues (e.g. easier to overflow the logs by faking the PID / user then writing to the private socket directly)? Cheers, -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A way to better integrate rsyslog into systemd?
On 04 Oct 2014, at 00:17, Cameron Norman camerontnor...@gmail.com wrote: El vie, 3 de oct 2014 a las 10:55 , Aleksei Besogonov alex.besogo...@gmail.com escribió: With all the recent noise about systemd abusing its position with the way it takes over logging I’ve been thinking about a way to solve it. As far as I understand the following holds: - Systemd takes over /dev/log socket which is normally served by rsyslog (or other syslog daemon). - That’s really required to make journald-based logging transparent and coherent for most use-cases. However, it creates a problem for log-heavy applications, because of additional roundtrips between processes. So far I’ve heard people actually using LD_PRELOAD tricks to hack around applications opening the /dev/log file inside the syslog(2). As far as I understand, it’s also not really configurable - the '/dev/log’ string is hardcoded into various libcs (e.g.: http://git.musl-libc.org/cgit/musl/tree/src/misc/syslog.c). Recent versions of rsyslog can directly read journald files. But that’s still suboptimal solution, because it introduces an unnecessary layer. Namespacing each daemon to provide its own /dev tree with custom /dev/log sockets is possible, but impractical. So I propose the following solution: 1) Add an option to systemd units to allow passing opened /dev/log sockets to rsyslog (using the usual SOL_SOCKET mechanism). This seems annoyingly roundabout. A more straightforward method would be to just have rsyslog listen on /dev/log. Obviously that is the original method, and journald changed it, and there are reasons for that. I am pretty sure one of the main selling points of journald is the extreme catch all nature: from syslog messages, to daemon stdout/in, to X.Org logs, etc. You can easily access those logs from one place and with one set of tools. As I understand, systemd developers indicated that they don’t want to add this option. Not in the least because affects the whole system, not just one service. If the authors wanted syslog messages to not be intercepted by journald, I do not think they would have had journald listen on /dev/log. Journald is desirable and it can forward log messages to rsyslog as it is. However, one of our clients raised an a question about forwarding overhead. It turns out that it’s definitely non-trivial and can in some cases cause significant slowdowns during log-heavy events. Think about 400Mb/s of logs - most of them are filtered out by rsyslog locally and some are transmitted over the network for permanent storage. So they would like to turn off the journald intercepting /dev/log, but only for specific services. I think that socket forwarding seems to be the easiest way to implement it. I’m going to actually do it and send patches for approval, if systemd developers don't object in principle or unless somebody proposes a better alternative. Can it not simply recognize it is listening on /run/systemd/journal/syslog and skip any kind of extra steps? Or would that cause sec issues (e.g. easier to overflow the logs by faking the PID / user then writing to the private socket directly)? That also. And it’ll still be nice to be as transparent as possible, if required. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Question/bug] Timeout after bus_event_loop_with_idle() change.
dbuch@dbuch-laptop ~ % systemctl status systemd-hostnamed.service -l ● systemd-hostnamed.service - Hostname Service Loaded: loaded (/usr/lib/systemd/system/systemd-hostnamed.service; static) Active: failed (Result: timeout) since lør 2014-10-04 08:14:52 CEST; 5h 7min ago Docs: man:systemd-hostnamed.service(8) man:hostname(5) man:machine-info(5) http://www.freedesktop.org/wiki/Software/systemd/hostnamed Process: 17795 ExecStart=/usr/lib/systemd/systemd-hostnamed (code=exited, status=0/SUCCESS) Main PID: 17795 (code=exited, status=0/SUCCESS) okt 04 08:12:52 dbuch-laptop systemd[1]: Started Hostname Service. okt 04 08:14:52 dbuch-laptop systemd[1]: systemd-hostnamed.service stopping timed out. Terminating. okt 04 08:14:52 dbuch-laptop systemd[1]: Unit systemd-hostnamed.service entered failed state. okt 04 08:14:52 dbuch-laptop systemd[1]: systemd-hostnamed.service failed. 2014-10-04 7:12 GMT+02:00 Andrei Borzenkov arvidj...@gmail.com: В Fri, 3 Oct 2014 22:00:50 +0200 Daniel Buch boogiewasth...@gmail.com пишет: Hi, With current git and since 430e21c2f7e77d600257ead56419f51 i keep on getting timeout on these units dbuch@dbuch-laptop ~/dev/systemd (git)-[master] % systemctl --failed UNIT LOAD ACTIVE SUBDESCRIPTION ● systemd-hostnamed.service loaded failed failed Hostname Service ● systemd-localed.service loaded failed failed Locale Service ● systemd-timedated.service loaded failed failed Time Date Service Show systemctl status systemd-hostnamed.service systemd-localed.service systemd-timedated.service My build config looks like this: --libexecdir=/usr/lib \ --localstatedir=/var \ --sysconfdir=/etc \ --enable-introspection \ --enable-gtk-doc \ --enable-kdbus \ --enable-compat-libs \ --enable-timesyncd \ --enable-lz4 \ --enable-terminal \ --enable-resolved \ --disable-audit \ --disable-ima \ --disable-multi-seat-x \ --disable-smack \ --with-sysvinit-path= \ --with-sysvrcnd-path= \ --with-firmware-path=/usr/lib/firmware/updates:/usr/lib/firmware \ Am i missing something? I havn't yet found any solution yet, and journal isn't helping me much here. Best regards, Daniel. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Question/bug] Timeout after bus_event_loop_with_idle() change.
Hi On Fri, Oct 3, 2014 at 10:00 PM, Daniel Buch boogiewasth...@gmail.com wrote: Hi, With current git and since 430e21c2f7e77d600257ead56419f51 i keep on getting timeout on these units I also occasionally get timeouts on bus-activated systemd services with -git. I haven't been able to reproduce it consistently. Maybe Lennart has an idea what's going wrong, otherwise I will spend some time pinning this down. Thanks David dbuch@dbuch-laptop ~/dev/systemd (git)-[master] % systemctl --failed UNIT LOAD ACTIVE SUBDESCRIPTION ● systemd-hostnamed.service loaded failed failed Hostname Service ● systemd-localed.service loaded failed failed Locale Service ● systemd-timedated.service loaded failed failed Time Date Service My build config looks like this: --libexecdir=/usr/lib \ --localstatedir=/var \ --sysconfdir=/etc \ --enable-introspection \ --enable-gtk-doc \ --enable-kdbus \ --enable-compat-libs \ --enable-timesyncd \ --enable-lz4 \ --enable-terminal \ --enable-resolved \ --disable-audit \ --disable-ima \ --disable-multi-seat-x \ --disable-smack \ --with-sysvinit-path= \ --with-sysvrcnd-path= \ --with-firmware-path=/usr/lib/firmware/updates:/usr/lib/firmware \ Am i missing something? I havn't yet found any solution yet, and journal isn't helping me much here. Best regards, Daniel. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] variable expansion in ExecStart
Hi,
Environment=X='Y' Z
ExecStart=/bin/echo $X ${X}
results in echo[31266]: Y Z 'Y' Z
i.e., $X not only splits at whitespace, as documented, but also strips quotes.
Is this by design, or is it an implementation accident? Should this behaviour
be changed?
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] variable expansion in ExecStart
On Sat, 2014-10-04 at 21:24 +0200, Zbigniew Jędrzejewski-Szmek wrote:
Environment=X='Y' Z
ExecStart=/bin/echo $X ${X}
results in echo[31266]: Y Z 'Y' Z
i.e., $X not only splits at whitespace, as documented, but also strips quotes.
Is this by design, or is it an implementation accident? Should this behaviour
be changed?
Isn't the current behavior with quotes the only way to pass an arbitrary
number of arguments that possibly contain whitespace? If you want $FOO
to expand to the argument list [a, b c] you can currently express
that as a 'b c'. If you remove unquoting, there is no alternative
syntax, is there?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] variable expansion in ExecStart
On Sun, Oct 05, 2014 at 02:30:42AM +0300, Uoti Urpala wrote:
On Sat, 2014-10-04 at 21:24 +0200, Zbigniew Jędrzejewski-Szmek wrote:
Environment=X='Y' Z
ExecStart=/bin/echo $X ${X}
results in echo[31266]: Y Z 'Y' Z
i.e., $X not only splits at whitespace, as documented, but also strips
quotes.
Is this by design, or is it an implementation accident? Should this
behaviour
be changed?
Isn't the current behavior with quotes the only way to pass an arbitrary
number of arguments that possibly contain whitespace? If you want $FOO
to expand to the argument list [a, b c] you can currently express
that as a 'b c'. If you remove unquoting, there is no alternative
syntax, is there?
Yeah, I guess that this is useful. The fact that nobody complained about current
behaviour suggests that either people are happy with it or that it simply
doesn't
matter. Needs to be documented though.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Added test for unit file state returned by unit_file_get_state and unit_file_get_list.
It would be good if the test units were more basic, not things including Crash recovery kernel arming. This makes it seems like the contents are substantial to the tests, when they're not. Just run something like ExecStart=/usr/bin/echo to make it clear that the units are stubs. Then, anything but the Type=oneshot and ExecStart=/usr/bin/echo will be clearly for the sake of the tests. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
