Re: [systemd-devel] [PATCH] core: mount only 4 partition in mount_setup_early()
It was 2014-08-06 śro 14:53, when Sangjung Woo wrote:
systemd doesn't mount smackfs if systemd was compiled without Smack
support. However, the number of mount point entry in mount_setup_early()
(i.e. N_EARLY_MOUNT) is 5 since smackfs is included. N_EARLY_MOUNT
should be 4 because currently smackfs is optional.
Signed-off-by: Sangjung Woo sangjung@samsung.com
---
src/core/mount-setup.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
index 206f89a..f15647b 100644
--- a/src/core/mount-setup.c
+++ b/src/core/mount-setup.c
@@ -64,7 +64,7 @@ typedef struct MountPoint {
/* The first three entries we might need before SELinux is up. The
* fourth (securityfs) is needed by IMA to load a custom policy. The
* other ones we can delay until SELinux and IMA are loaded. */
-#define N_EARLY_MOUNT 5
+#define N_EARLY_MOUNT 4
AFAIR smackfs needs to be one of those early mounted. At least that is
what ffbd2c4d suggests.
static const MountPoint mount_table[] = {
{ sysfs, /sys, sysfs, NULL,
MS_NOSUID|MS_NOEXEC|MS_NODEV,
As strange as it may seem this is not a bug (at least it doesn't seem to
hurt). In the mount_setup_early() function there is this for() loop:
for (i = 0; i N_EARLY_MOUNT; i ++) {
which means when it iterates iterates the mount_table[]
static const MountPoint mount_table[] = {
{ sysfs, /sys, [...]},
{ proc, /proc, [...]},
{ devtmpfs, /dev, [...]},
{ securityfs, /sys/kernel/security, [...]},
#ifdef HAVE_SMACK,
{ smackfs,/sys/fs/smackfs, [...]},
{ tmpfs, /dev/shm, [...]},
#endif,
{ tmpfs, /dev/shm, [...]},
[...]
};
with Smack *enabled*, it attempts to mount: /sys (0), /proc (1), /dev
(2), /sys/kernel/security (3), /sys/fs/smackfs (4). Then it
stops. Without HAVE_SMACK and N_EARLY_MOUNT equal 5 the last filesystem
mounted is /dev/shm which wasn't mounted before ffbd2c4d but if it is it
doesn't cause any problems, does it? If you really do not want to mount
/dev/shm enclose the definition of N_EARLY_MOUNT as 5 in ifdef on
HAVE_SMACK and set it to 4 without Smack.
--
Łukasz Stelmach
Samsung RD Institute Poland
Samsung Electronics
pgpRRnxyi95HD.pgp
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Condition* options linked by AND if stated more than once
If one of these options gets stated more than once the different
instances seem to be linked by a logical AND, too. This prevents
overwriting these options via snippets in /etc, e. g.
systemd-timesyncd.service still won't run in KVM with a snippet
/etc/systemd/system/systemd-timesyncd.service.d/do-run-in-kvm.conf stating
[Unit]
ConditionVirtualization=kvm
Seen on Arch Linux, systemd 215-4, tested
Condition{Architecure,Host,Virtualization}.
Any thoughts?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Condition* options linked by AND if stated more than once
On 07/08/14 12:23, Peter Mattern wrote: If one of these options gets stated more than once the different instances seem to be linked by a logical AND, too. Yes. This is documented in systemd.unit(5), which also describes how a drop-in can reset the list of conditions and start from a clean slate. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Condition* options linked by AND if stated more than once
On Thu, Aug 07, 2014 at 01:23:34PM +0200, Peter Mattern wrote:
If one of these options gets stated more than once the different
instances seem to be linked by a logical AND, too. This prevents
overwriting these options via snippets in /etc, e. g.
systemd-timesyncd.service still won't run in KVM with a snippet
/etc/systemd/system/systemd-timesyncd.service.d/do-run-in-kvm.conf
stating
[Unit]
ConditionVirtualization=kvm
What you could do in a snippet is to cancel the previous assignment and define
new value for the key. Following should work
[Unit]
ConditionVirtualization=
ConditionVirtualization=kvm
Seen on Arch Linux, systemd 215-4, tested
Condition{Architecure,Host,Virtualization}.
Any thoughts?
___
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] right way to log to rsyslog/syslog only?
Hi, I just install Fedora 20 (with systemd 208) and want log, if possible, without journald, only to rsyslog. I have this configuration: 'systemd.log_target=syslog-or-kmsg' at kernel command line '/etc/systemd/system.conf': [Manager] LogTarget=syslog-or-kmsg DefaultStandardOutput=syslog '/etc/systemd/user.conf': [Manager] LogTarget=syslog-or-kmsg '/etc/systemd/journald.conf': [Journal] Storage=none It's good that I have no /var/log/journal/* files, but - journald is still runnig (this isn't too imporatant, but when it is possible work without it, it will be better) - fundamental problem seems be, that some daemons logs not appear in rsyslog files, for unknown reason. systemd/journald man pages are not clear how solve this, please can someone touch me to right direction? Thanks in advance, Franta Hanzlik ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] right way to log to rsyslog/syslog only?
On 08/07/2014 12:06 PM, Frantisek Hanzlik wrote: Hi, I just install Fedora 20 (with systemd 208) and want log, if possible, without journald, only to rsyslog. It's not possible. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] right way to log to rsyslog/syslog only?
On Thu, Aug 7, 2014 at 2:06 PM, Frantisek Hanzlik fra...@hanzlici.cz wrote: It's good that I have no /var/log/journal/* files, but - journald is still runnig (this isn't too imporatant, but when it is possible work without it, it will be better) Why do you want this? As Johann very tersely replied, it's not possible for a systemd-based system not to use the journal. There is nothing that says that the journal needs to be persistent as you found (however you'll be eating up RAM with the journal if it's not backed by disk - I'm not 100% sure what happens if there is a backing store, i.e. does it still store in memory?) Perhaps understanding why you're allergic to the journal would help in figuring out solutions to the actual underlying problem. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Condition* options linked by AND if stated more than once
First, thank you very much for your quick responses. I had missed the description in man systemd.unit (If any of these options is assigned the empty string, ... at the end of the paragraph about Condition*, right?) and a snippet as posted by Michal works (I had already checked this myself but not posted back yet). So sorry for the noise. What seems odd to me is that all Config* options of a unit in /usr have to appear in the snippet in /etc if it's intended to change only a part of them but leave the others unmodified. But this is for a reason, I guess? Regards ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] User sessions: limit the ability to migrate cgroups
Hi, Should unprivileged processes be allowed to change cgroup? As I understand it, it is not possible to block processes to leave a cgroup, but only to block processes to enter a cgroup. In the following example, session-c4.scope/tasks belongs to root:root with -rw-r--r-- and user@1000.service/tasks belongs to user:user with -rw-r--r--. So processes can freely move from session-c4.scope to user@1000.service. But not in the other direction. $ systemd-cgls Working Directory /sys/fs/cgroup/systemd/user.slice/user-1000.slice: ├─session-c4.scope │ ├─713 sshd: user [priv] │ ├─722 sshd: user@pts/2 │ ├─723 -bash │ ├─732 systemd-cgls │ └─733 pager ├─user@1000.service │ ├─406 /lib/systemd/systemd --user With user sessions managed by systemd, will it be possible to restrict unprivileged users from migrating to other cgroups? Best regards, Alban ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] tmpfilesdir should use rootprefix, otherwise units may fail in --enable-split-usr configurations
From: Dimitri John Ledkov x...@ubuntu.com tmpfiles.d files do not depend on /usr present, and in --enable-split-usr configuration there may be system units (e.g. shipped in /lib) that rely on tmpfiles.d to be configured e.g. tmpfiles.d/systemd.conf itself. Hence tmpfiles.d should use rootprefix. Signed-off-by: Dimitri John Ledkov x...@ubuntu.com --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index ce8f247..81a0cf9 100644 --- a/Makefile.am +++ b/Makefile.am @@ -87,7 +87,7 @@ catalogstatedir=$(systemdstatedir)/catalog pkgsysconfdir=$(sysconfdir)/systemd userunitdir=$(prefix)/lib/systemd/user userpresetdir=$(prefix)/lib/systemd/user-preset -tmpfilesdir=$(prefix)/lib/tmpfiles.d +tmpfilesdir=$(rootprefix)/lib/tmpfiles.d sysusersdir=$(prefix)/lib/sysusers.d sysctldir=$(prefix)/lib/sysctl.d binfmtdir=$(prefix)/lib/binfmt.d -- 2.0.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfilesdir should use rootprefix, otherwise units may fail in --enable-split-usr configurations
On 07/08/14 15:21, Dimitri John Ledkov wrote: tmpfiles.d files do not depend on /usr present, and in --enable-split-usr configuration there may be system units (e.g. shipped in /lib) that rely on tmpfiles.d to be configured e.g. tmpfiles.d/systemd.conf itself. Hence tmpfiles.d should use rootprefix. As I understand it, the desired solution here is mount /usr in the initramfs. If your platform of interest is Debian/Ubuntu you could help with getting the patches on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=652459 landed (and its dependencies resolved), and then we could stop caring about whether /usr is separate or not altogether? S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] right way to log to rsyslog/syslog only?
Hi, On Thu, Aug 07, 2014 at 02:06:07PM +0200, Frantisek Hanzlik wrote: '/etc/systemd/system.conf': [Manager] LogTarget=syslog-or-kmsg DefaultStandardOutput=syslog Leave 'LogTarget=' to its default value (journal-or-kmsg). It's good that I have no /var/log/journal/* files, but - journald is still runnig (this isn't too imporatant, but when it is possible work without it, it will be better) - fundamental problem seems be, that some daemons logs not appear in rsyslog files, for unknown reason. Could you be more specific about which daemons are affected? Many daemons that are started by systemd service run in foreground (don't ask me about the logic behind this). This means that all output is sent to stdout, not syslog. Journald collects this output and forwards it to syslog -- hence my recommendation above. For example, sshd(8) now runs with '-D'. Of course, some daemons might send their messages syslog even if run in foreground, but not all. A hard way to fix this is to modify service files for daemons you use to run in background and set 'Type=forking'. HTH, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpW64ANKNKmh.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] right way to log to rsyslog/syslog only?
On Thu, Aug 07, 2014 at 02:34:20PM +0200, Jon Stanley wrote: I'm not 100% sure what happens if there is a backing store, i.e. does it still store in memory? No. Perhaps understanding why you're allergic to the journal would help in figuring out solutions to the actual underlying problem. There is nothing wrong with the journald per se, but it's not a replacement for the classic syslog: journald offers only log storage, while syslog is a log processing tool. This distinction is dim on a desktop, but is very apparent even on a simple server machine. Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpj26XVDgpUh.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] right way to log to rsyslog/syslog only?
On 08/07/2014 04:12 PM, Leonid Isaev wrote:
Perhaps understanding why you're allergic to the journal would help in
figuring out solutions to the actual underlying problem.
There is nothing wrong with the journald per se, but it's not a replacement for
the classic syslog
Yes it is.
And there is a very much difference in using one of the traditional
message printing APIs like syslog for logging as in doing this
#include syslog.h
int main(int argc, char *argv[])
{ syslog(LOG_NOTICE, Hello World);
return 0;
}
Vs using the journal's native APIs as in this.
#include systemd/sd-journal.h
int main(int argc, char *argv[])
{ sd_journal_print(LOG_NOTICE, Hello World);
return 0;
}
Arguably one of journals major/only shortcoming compared to what's out
there is it's lack the ability to send syslog messages over the syslog
network protocol but I think it's just a matter of time until it does,
since it's arguably unavoidable ( think for example containers here and
I would be amazed if submitted patches would be rejected that would add
that )
But I guess you can hack yourself around that shortcoming by turning off
persistent storage ( that is if you dont want to store logs as well on
the host ) and run something like
journalctl -o short -f | nc ip -u 514 -w 1
that avoids the problem having two loggers running on the same host (
like using syslog-ng or rsyslog alongside journal ) to solve that
particular problem.
JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] right way to log to rsyslog/syslog only?
On Aug 7, 2014 9:11 PM, Jóhann B. Guðmundsson johan...@gmail.com wrote: Arguably one of journals major/only shortcoming compared to what's out there is it's lack the ability to send syslog messages over the syslog network protocol but I think it's just a matter of time until it does, since it's arguably unavoidable ( think for example containers here and I would be amazed if submitted patches would be rejected that would add that ) Yes, it has been mentioned a couple of times that dealing with the various syslog protocols is the job of a syslogd, not the journal. (That said, there already are some tools to push raw journal messages over the network...) But I guess you can hack yourself around that shortcoming by turning off persistent storage ( that is if you dont want to store logs as well on the host ) and run something like journalctl -o short -f | nc ip -u 514 -w 1 that avoids the problem having two loggers running on the same host ( like using syslog-ng or rsyslog alongside journal ) to solve that particular problem. I don't understand why running two programs that provide distinct functions is called a problem. I also don't understand why running *three* programs (journald, journalctl, netcat) that only do a halfassed job compared to rsyslog *isn't* a problem anymore... -- Mantas Mikulėnas graw...@gmail.com // sent from phone ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] right way to log to rsyslog/syslog only?
Hi, On Thu, Aug 07, 2014 at 06:11:39PM +, Jóhann B. Guðmundsson wrote: On 08/07/2014 04:12 PM, Leonid Isaev wrote: Perhaps understanding why you're allergic to the journal would help in figuring out solutions to the actual underlying problem. There is nothing wrong with the journald per se, but it's not a replacement for the classic syslog Yes it is. Hmm, reading my message above, I can see that it wasn't clear enough -- sorry. Perhaps an example can clarify things. Take dnsmasq which under normal operation logs _lots_ of DHCP-related messages, even on a tiny network of ~20 (crappy Android) devices. These messages fall into 2 categories: routine (log_level info -- DHCPREQUEST, DHCPACK, etc.) and security-related (log_level warn -- DNS rebind attacks e.g.). I want the former to be volatile (stored in /run/log), while the latter on-disk (in /var/log). While there are many ways to accomplish this with rsyslog/syslog-ng filters, I'd very much like to know how to do this with journald. Thanks, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpYQhD4Lmcgr.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] right way to log to rsyslog/syslog only?
On 08/07/2014 07:44 PM, Leonid Isaev wrote: Hi, On Thu, Aug 07, 2014 at 06:11:39PM +, Jóhann B. Guðmundsson wrote: On 08/07/2014 04:12 PM, Leonid Isaev wrote: Perhaps understanding why you're allergic to the journal would help in figuring out solutions to the actual underlying problem. There is nothing wrong with the journald per se, but it's not a replacement for the classic syslog Yes it is. Hmm, reading my message above, I can see that it wasn't clear enough -- sorry. Perhaps an example can clarify things. Take dnsmasq which under normal operation logs _lots_ of DHCP-related messages, even on a tiny network of ~20 (crappy Android) devices. These messages fall into 2 categories: routine (log_level info -- DHCPREQUEST, DHCPACK, etc.) and security-related (log_level warn -- DNS rebind attacks e.g.). I want the former to be volatile (stored in /run/log), while the latter on-disk (in /var/log). While there are many ways to accomplish this with rsyslog/syslog-ng filters, Give me an actual working example how this is solved using rsyslog/syslog-ng filters JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] right way to log to rsyslog/syslog only?
On 08/07/2014 07:32 PM, Mantas Mikulėnas wrote: On Aug 7, 2014 9:11 PM, Jóhann B. Guðmundsson johan...@gmail.com mailto:johan...@gmail.com wrote: Arguably one of journals major/only shortcoming compared to what's out there is it's lack the ability to send syslog messages over the syslog network protocol but I think it's just a matter of time until it does, since it's arguably unavoidable ( think for example containers here and I would be amazed if submitted patches would be rejected that would add that ) Yes, it has been mentioned a couple of times that dealing with the various syslog protocols is the job of a syslogd, not the journal. (That said, there already are some tools to push raw journal messages over the network...) Raw journals or journal only solution is not acceptable in large environment using mixed OS and or even just mixed Linux distributions and their releases ( think debian stable and centos7 for example ) so it's necessary for journal to be able to forward the logs over the syslog network protocol But I guess you can hack yourself around that shortcoming by turning off persistent storage ( that is if you dont want to store logs as well on the host ) and run something like journalctl -o short -f | nc ip -u 514 -w 1 that avoids the problem having two loggers running on the same host ( like using syslog-ng or rsyslog alongside journal ) to solve that particular problem. I don't understand why running two programs that provide distinct functions is called a problem. Host resources I also don't understand why running *three* programs (journald, journalctl, netcat) that only do a halfassed job compared to rsyslog *isn't* a problem anymore... You do realize what I proposed was a workaround right? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] right way to log to rsyslog/syslog only?
On Thu, Aug 07, 2014 at 08:01:31PM +, Jóhann B. Guðmundsson wrote:
Give me an actual working example how this is solved using rsyslog/syslog-ng
filters
A quick (and probably dirty) way with syslog-ng:
--
% grep dnsmasq /etc/syslog-ng/syslog-ng.conf
destination d_dnsmasq { file(/run/log/dnsmasq.log); };
filter f_daemon { facility(daemon) and not level(debug) and not program(hostap)
and not program(dnsmasq-dhcp); };
filter f_dnsmasq { program(dnsmasq-dhcp); };
log { source(src); filter(f_dnsmasq); destination(d_dnsmasq); };
--
So, dnsmasq-dhcp is the prefix (used by dnsmasq by default) for normal
messages, while dnsmasq -- for everything else. Here is some statistics:
--
% uptime
16:38:29 up 22 days, 22:05, 1 user, load average: 0.00, 0.01, 0.05
% wc -l /run/log/dnsmasq.log*
1212 /run/log/dnsmasq.log
972 /run/log/dnsmasq.log.1
2077 /run/log/dnsmasq.log.2
958 /run/log/dnsmasq.log.3
5219 total
% head -n 2 /run/log/dnsmasq.log
2014-08-03T00:05:42.00-04:00 metal-0 dnsmasq-dhcp[460]: DHCPREQUEST(br0)
10.0.0.4 30:39:26:e3:ec:4e
2014-08-03T00:05:42.00-04:00 metal-0 dnsmasq-dhcp[460]: DHCPACK(br0)
10.0.0.4 30:39:26:e3:ec:4e android-2f74c9ab3fa43caa
% for i in /var/log/daemon.log*; do echo $i; grep dnsmasq $i | wc -l; done
/var/log/daemon.log
0
/var/log/daemon.log.1
1
/var/log/daemon.log.2
2
/var/log/daemon.log.3
11
/var/log/daemon.log.4
11
/var/log/daemon.log.5
0
/var/log/daemon.log.6
0
/var/log/daemon.log.7
23
/var/log/daemon.log.8
30
% grep dnsmasq /var/log/daemon.log.1
2014-08-02T15:46:05.00-04:00 metal-0 dnsmasq[460]: possible DNS-rebind
attack detected: direct.stroyka.ru
--
Sorry for a long reply...
--
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4
C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
pgpAhca1Wxzhm.pgp
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] right way to log to rsyslog/syslog only?
On 08/07/2014 08:41 PM, Leonid Isaev wrote: Sorry for a long reply... No problem I needed to see how you were thinking/doing this. So basically you want to log everything to /run ( volatile ) and filter out everything above a certain log-level and store that persistent in it's own journal ( basically store the output from this journalctl -p err persistently ) Or you want to log everything to /run ( volatile ) and filter out everything above a certain log-level for a specific user,unit,command whatever and store that persistent in it's own journal. ( using your example store the output from this journalctl -p err _SYSTEMD_UNIT=dnsmasq.service persistently ) One of the Samsung guys proposed something similar to the former a while back ( and I think he signed himself up to it ) but as far as I can tell his work has not landed yet. ( afaikt requires changes to journald-server.c|||introduce something like SplitMode=priority-err |etc ). I would not expect anything like this soon since Andy NAK their SCM_PROCINFO stuff and they are probably to busy re-writing/re-implementing it as SCM_IDENTY together with him but one of the Samsung guys can comment if they had started working on or had otherwise looked into this but as things stand now this cannot be done afaikt. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] right way to log to rsyslog/syslog only?
Hi, On Thu, Aug 07, 2014 at 09:44:47PM +, Jóhann B. Guðmundsson wrote: So basically you want to log everything to /run ( volatile ) and filter out everything above a certain log-level and store that persistent in it's own journal ( basically store the output from this journalctl -p err persistently ) Or you want to log everything to /run ( volatile ) and filter out everything above a certain log-level for a specific user,unit,command whatever and store that persistent in it's own journal. ( using your example store the output from this journalctl -p err _SYSTEMD_UNIT=dnsmasq.service persistently ) My original motivation was to reduce HDD spin-ups (academic, I know). So I had to identify sources of frequent logging activity and figure out which log messages are actually valuable and which can be discarded on reboot. The same rationality applies to remote logging, e.g. only auth-level events and critical hardware telemetry should be sent to a log-server. One of the Samsung guys proposed something similar to the former a while back ( and I think he signed himself up to it ) but as far as I can tell his work has not landed yet. ( afaikt requires changes to journald-server.c|||introduce something like SplitMode=priority-err |etc ). Thanks for letting me know aboout this work, but from the above description it seems rather limited. I brought up the log-levels only as an example. In practice one needs to be able to filter using _any_ message attribute. For instance, message body (iptables traffic, output of frequently-run systemd timers -- drop the useless Start/Stop-type messages, HostAp logs) and facility (kernel/daemon/...). I would not expect anything like this soon since Andy NAK their SCM_PROCINFO stuff and they are probably to busy re-writing/re-implementing it as SCM_IDENTY together with him but one of the Samsung guys can comment if they had started working on or had otherwise looked into this but as things stand now this cannot be done afaikt. IMHO, the central technical problem (I am not going to argue about design principles) of journald is that it is an all or nothing solution. Unfortunately, this inflexibility makes it only useful as a supplimentary logger... Cheers, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpGkfWoCl5FC.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] right way to log to rsyslog/syslog only?
On 08/07/2014 10:42 PM, Leonid Isaev wrote: Thanks for letting me know aboout this work, but from the above description it seems rather limited. I brought up the log-levels only as an example. In practice one needs to be able to filter using_any_ message attribute. I just used the example to reply to your own so they are equally limited in that manner see systemd.journal-fields(7) For instance, message body (iptables traffic, output of frequently-run systemd timers -- drop the useless Start/Stop-type messages, HostAp logs) and facility (kernel/daemon/...). And you have configured syslog-ng and rsyslog to do that for you and how much time did it take? I can understand the need for very powerful filter capabilities which can be used when needed and the journalctl already possesses those. In the sample you showed me how you are doing things you did so in three steps 1 configure syslog-ng 2 parse through files with log level lower then error, parse through files with error But I myself am a lazy old fat admin that has been administrating server for what 10 years now and prefer to use this journalctl -p err _SYSTEMD_UNIT=dnsmasq.service which yields the same result in one step ( for each log level ) and I dont have to worry about installing or setting up anything basically I prefer I simply asking the journal to give me the information I need when I need it. But why do you need to log all of this into their own persistent journal files, what practical problem are you hoping to solve,achieve or gain by that? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
