Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On Mon, 09.06.14 12:01, Mantas Mikulėnas (graw...@gmail.com) wrote: I think there's also another problem – logind starts the user manager instance for cronjobs while it shouldn't do so for batch stuff. Probably a PAM configuration issue. Nope. This is intentional. A session is a session is a session, and we should provide the same functionality to all session,s including all services on the bus and all services systemd manages... We shouldn't end up providing only half a session if the trigger for something was only time, instead of some other reason... That said, certain system-level cronjobs should probably not be PAM sessions... PAM sessions are really mostly for stuff that really is a session of some kind, and not just system services that just need some code executed by time. The same way as a daemon that drops priviliges shouldn't do so through PAM, a system cronjob shouldn't involve PAM. But that of course would require changes to cron, to understand what a system and what a user cronjob was... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On 10.06.2014 13:20, Lennart Poettering wrote: On Mon, 09.06.14 09:33, Leho Kraav (l...@kraav.com) wrote: After upgrading systemd 208 - 212, every single cron job creates this flood in systemd journal: Can I quiet this down somehow? The idea with the journal is that we log everything that happens on the system, without exceptions, without hiding anything. And filtering is then applied when you view things, based on the big pool of data you have. This can be annoying, of course, but I am so very sure we should't suppress these things, because soemtimes they are useful to know about. journalctl has powerful filtering capabilities, we have them to make this huge datase palatable... I'm actually all for getting the upstream i.e. cron/PAM acting more sane so we don't even arrive at the logging huge amounts of low-effectiveness information problem, but as you wrote in your other reply, that might be a whole separate project. In the meantime mgilbert's suggestion for using loginctl --linger parameter seems to accomplish the goal of quieting cron logging. Any side effects to consider? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On Monday 09 June 2014 at 23:32:28, Mike Gilbert wrote: On Mon, Jun 9, 2014 at 4:42 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 09.06.2014 22:32, schrieb Leonid Isaev: On Mon, Jun 09, 2014 at 09:19:20PM +0200, Reindl Harald wrote: [...] on our production infrastrcuture these messages would be *a lot* more than all other logs summarized *and* they are spitted to /var/log/messages to make things worst But why can't you write a syslog filter which uses facility as well as program name? So if you believe that systemd-generated messages are useless, drop them because you *can not* distinguish between *that* user messages and system message sbecause they have systemd as program name common, the PID changes and you don't want to drop *system messages* from systemd So, systemd starts certain things on _any_ user login: be it a real user, or a daemon. However * why do it need to do that much stuff * why can't it keep that stuff long-running you have already /usr/lib/systemd/systemd --user and (sd-pam) processes for every userid ever started a cronjob running all the time - so why flood the logs every minute again? Now that you mention it, you can cut down on a lot of the log spam by enabling linger for root and other users which run cron jobs. loginctl enable-linger user This will keep a systemd user instance running so that a new one is not spawned every time cron wakes up. It's more interesting, why a logind session is ever being created for the cron job... It shouldn't be that way, or do I misunderstand something? -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
Am 10.06.2014 12:20, schrieb Lennart Poettering: On Mon, 09.06.14 09:33, Leho Kraav (l...@kraav.com) wrote: After upgrading systemd 208 - 212, every single cron job creates this flood in systemd journal: Can I quiet this down somehow? The idea with the journal is that we log everything that happens on the system, without exceptions, without hiding anything. And filtering is then applied when you view things, based on the big pool of data you have. This can be annoying, of course, but I am so very sure we should't suppress these things, because soemtimes they are useful to know about if things are only *sometimes* useful that means most of the time they are not and for anybody who is not a systemd-developer or debugging something they are just noise at least the enable-linger should be default because you anyways have all the disturbing sd-pam processes long running which you need to kill after updates on libraries to get anything in listed with lsof | grep DEL | grep /usr clean so don't start a complete systemd session for a simple cronjob which did his job decades before systemd existed or just don't stop it all the time the started target... messages are in *any case* misleading signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Soliciting feedback for golang bindings to the systemd journal C API
- Original Message - From: David Timothy Strauss da...@davidstrauss.net To: Dan Mace dm...@redhat.com Cc: appinfra-l...@redhat.com, systemd Mailing List systemd-devel@lists.freedesktop.org Sent: Monday, June 9, 2014 8:29:11 PM Subject: Re: [systemd-devel] Soliciting feedback for golang bindings to the systemd journal C API The CoreOS crew has already done most of this work by writing a native Go implementation (rather than wrapping the C APIs). Can you please point me to the implementation? All I've seen is this: https://github.com/coreos/go-systemd/blob/master/journal/send.go Which only handles writes via the Unix socket. The implementation we're prototyping supports journal queries in ways that (to my knowledge) aren't possible without either forking to external tools (e.g. journalctl) or linking to sd-journal. If there's already code out there which satisfies the need, I'd be happy to use and contribute to it. -- Dan Mace OpenShift, PaaS by Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/1] udev: really exclude device-mapper from block device ownership event locking
Arguments were wrong order, no?
This fixes commits:
e918a1b5a94f270186dca59156354acd2a596494
3d06f4183470d42361303086ed9dedd29c0ffc1b
---
src/udev/udevd.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/udev/udevd.c b/src/udev/udevd.c
index 0f3f3f0..160360e 100644
--- a/src/udev/udevd.c
+++ b/src/udev/udevd.c
@@ -304,7 +304,7 @@ static void worker_new(struct event *event)
* kabi_ IMHO this sounds like a good plan for this
moment
*/
if (streq_ptr(block, udev_device_get_subsystem(dev))
-!startswith(dm-, udev_device_get_sysname(dev))) {
+!startswith(udev_device_get_sysname(dev), dm-)) {
struct udev_device *d = dev;
if (streq_ptr(partition,
udev_device_get_devtype(d)))
@@ -741,7 +741,7 @@ static int synthesize_change(struct udev_device *dev) {
if (streq_ptr(block, udev_device_get_subsystem(dev))
streq_ptr(disk, udev_device_get_devtype(dev))
-!startswith(dm-, udev_device_get_sysname(dev))) {
+!startswith(udev_device_get_sysname(dev), dm-)) {
bool part_table_read = false;
bool has_partitions = false;
int fd;
--
2.0.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/1] udev: really exclude device-mapper from block device ownership event locking
On Tue, Jun 10, 2014 at 3:51 PM, Christian Hesse m...@eworm.de wrote: Arguments were wrong order, no? Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Soliciting feedback for golang bindings to the systemd journal C API
On Tue, Jun 10, 2014 at 6:07 AM, Dan Mace dm...@redhat.com wrote: Which only handles writes via the Unix socket. The implementation we're prototyping supports journal queries in ways that (to my knowledge) aren't possible without either forking to external tools (e.g. journalctl) or linking to sd-journal. If there's already code out there which satisfies the need, I'd be happy to use and contribute to it. I just pinged someone from CoreOS to hopefully shed more light on this. What you linked on GitHub is what I remember from LinuxCon in New Orleans. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On Tue, 10.06.14 13:24, Leho Kraav (l...@kraav.com) wrote: On 10.06.2014 13:20, Lennart Poettering wrote: On Mon, 09.06.14 09:33, Leho Kraav (l...@kraav.com) wrote: After upgrading systemd 208 - 212, every single cron job creates this flood in systemd journal: Can I quiet this down somehow? The idea with the journal is that we log everything that happens on the system, without exceptions, without hiding anything. And filtering is then applied when you view things, based on the big pool of data you have. This can be annoying, of course, but I am so very sure we should't suppress these things, because soemtimes they are useful to know about. journalctl has powerful filtering capabilities, we have them to make this huge datase palatable... I'm actually all for getting the upstream i.e. cron/PAM acting more sane so we don't even arrive at the logging huge amounts of low-effectiveness information problem, but as you wrote in your other reply, that might be a whole separate project. In the meantime mgilbert's suggestion for using loginctl --linger parameter seems to accomplish the goal of quieting cron logging. Any side effects to consider? Well, you keep the systemd user instance running all the time then instead of just when it is used... Doing that for root is fine, but if you do that for all users, then well, you got an additional process running for each one of them... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On 10.06.2014 19:01, Lennart Poettering wrote: In the meantime mgilbert's suggestion for using EDIT **loginctl enable-linger** command seems to accomplish the goal of quieting cron logging. Any side effects to consider? Well, you keep the systemd user instance running all the time then instead of just when it is used... Doing that for root is fine, but if you do that for all users, then well, you got an additional process running for each one of them... Right. For time being, root cron jobs are the primary issue. I'll see what happens with the others. enable-linger persists across reboots? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On Tue, 10.06.14 14:31, Ivan Shapovalov (intelfx...@gmail.com) wrote: It's more interesting, why a logind session is ever being created for the cron job... It shouldn't be that way, or do I misunderstand something? We should create a logind session for all sessions of normal users. It doesn't matter if its just a background job or foreground, logind should know about it, we should set up its full environment (including the per-user systemd), and set all security limits and stuff. For system users (i.e. those with an uid 1000), for all that stuff that is just an implementation detail of the OS however there shouldn't really be any PAM or logind session created by cron. It should just setresuid() and invoke whatever it needs to invoke... Setting up a full PAM session is quite unnecessary then... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Systemd mount operations
Hi, I have an issue with the following systemd behavior (from manual): Mount points created at runtime (independently of unit files or /etc/fstab) will be monitored by systemd and appear like any other mount unit in systemd. See /proc/self/mountinfo description in proc(5). I need to manage mount operations directly without any systemd intervention, is it possible to disable such behavior? Thanks in advance for your support. BR,Nicholas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-network-wait-online symlinks to systemd-networkd
On Sun, 08.06.14 09:37, Dave Reisner (d...@falconindy.com) wrote: On a related topic, could we please stop shipping hardcoded symlinks in /etc in favor of documented reccomendations for downstream packagers? Hmm, well. The way automake currently works is that all config files are overwritten on make install. WHich is probably the right thing to do I think. People who use make install without DESTDIR= should be prepared to get their configured reset in one way or another... Creating a couple of symlinks in /etc, and dropping a number of configuration files in, doesn't appear to be so much of a difference to me. Can you explain to me why we should depart from automake's traditional behaviour here, and wh symlinks should be something different from configuration files? I mean, ideally we'd just invoke systemctl preset for these things, but for the sake of cross-compilation we can avoid this easily. We probably should ship make sure to ship the very same symlinks we create with make install with a preset file though... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix spelling mistake, proces - process
On Fri, 06.06.14 23:06, Colin King (colin.k...@canonical.com) wrote:
Applied by Zbigniew.
Thanks!
From: Colin Ian King colin.k...@canonical.com
Signed-off-by: Colin Ian King colin.k...@canonical.com
---
src/core/busname.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/busname.c b/src/core/busname.c
index 6be1b8b..2752415 100644
--- a/src/core/busname.c
+++ b/src/core/busname.c
@@ -446,7 +446,7 @@ static void busname_enter_signal(BusName *n, BusNameState
state, BusNameResult f
n-control_pid,
false);
if (r 0) {
-log_warning_unit(UNIT(n)-id, %s failed to kill control
proces: %s, UNIT(n)-id, strerror(-r));
+log_warning_unit(UNIT(n)-id, %s failed to kill control
process: %s, UNIT(n)-id, strerror(-r));
goto fail;
}
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
On Fri, 06.06.14 12:53, Rusty Bird (rustyb...@openmailbox.org) wrote: Humm. I can't say I particularly like the idea, but I can't dissmiss this either, I figure we have to do something like this. However, if we do this, then this needs to be a passive target, see systemd.special(7), under Special passive system units, and it should be documented in that section. Passive means it is pulled it by the units that implement a pre job, not by the units that implement the networking stack. This way it doesn't get added to the initial transaction unless there's actually some service that needs to be pulled in. See the man page for further discussion on this. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] backlight: Do not clamp brightness for LEDs
On Thu, 05.06.14 23:59, Denis Tikhomirov (dvtikhomi...@gmail.com) wrote:
Thanks!
Applied!
On Thu, Jun 05, 2014 at 08:37:20AM +0200, Lennart Poettering wrote:
The patch is line-broken, please send an uncorrupted patch!
I am very sorry, I forgot that my client limits line width. I will use
mutt now on.
clamp_brightness() clamps the brightness value to the range of the
actual device. This is a recent addition that was added to deal with
driver updates where the resolution is changed. I don't think this part
should be dropped for LED devices. The clamp_brightness() call hence
should be called unconditionally, however, internally it should use a
different min_brightness value if something is an !backlight devices...
Thank you for explanation, this sounds very reasonable to me. Please,
see updated patch:
---
src/backlight/backlight.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c
index 691472c..860cb22 100644
--- a/src/backlight/backlight.c
+++ b/src/backlight/backlight.c
@@ -225,11 +225,13 @@ static unsigned get_max_brightness(struct udev_device
*device) {
/* Some systems turn the backlight all the way off at the lowest levels.
* clamp_brightness clamps the saved brightness to at least 1 or 5% of
- * max_brightness. This avoids preserving an unreadably dim screen, which
- * would otherwise force the user to disable state restoration. */
+ * max_brightness in case of 'backlight' subsystem. This avoids preserving
+ * an unreadably dim screen, which would otherwise force the user to
+ * disable state restoration. */
static void clamp_brightness(struct udev_device *device, char **value,
unsigned max_brightness) {
int r;
unsigned brightness, new_brightness, min_brightness;
+const char *subsystem;
r = safe_atou(*value, brightness);
if (r 0) {
@@ -237,7 +239,12 @@ static void clamp_brightness(struct udev_device *device,
char **value, unsigned
return;
}
-min_brightness = MAX(1U, max_brightness/20);
+subsystem = udev_device_get_subsystem(device);
+if (streq(subsystem, backlight))
+min_brightness = MAX(1U, max_brightness/20);
+else
+min_brightness = 0;
+
new_brightness = CLAMP(brightness, min_brightness, max_brightness);
if (new_brightness != brightness) {
char *old_value = *value;
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] bus-proxy: fix misplaced s/system/session/
--- units/user/systemd-bus-pro...@.service.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/units/user/systemd-bus-pro...@.service.in b/units/user/systemd-bus-pro...@.service.in index 68f59f5..2f4df7c 100644 --- a/units/user/systemd-bus-pro...@.service.in +++ b/units/user/systemd-bus-pro...@.service.in @@ -12,5 +12,5 @@ Description=Legacy D-Bus Protocol Compatibility Daemon # The first argument will be replaced by the service by information on # the process requesting the proxy, we need a placeholder to keep the # space available for this. -ExecStart=@rootlibexecdir@/sessiond-bus-proxyd --address=kernel:path=/dev/kdbus/%U-user/bus --configuration=/etc/dbus-1/session.conf --configuration=/etc/dbus-1/session-local.conf --configuration=/etc/dbus-1/session.d/ +ExecStart=@rootlibexecdir@/systemd-bus-proxyd --address=kernel:path=/dev/kdbus/%U-user/bus --configuration=/etc/dbus-1/session.conf --configuration=/etc/dbus-1/session-local.conf --configuration=/etc/dbus-1/session.d/ NotifyAccess=main -- 2.0.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: fix references to sd_journal_cutoff_realtime_usec
On Mon, 02.06.14 16:47, Mantas Mikulėnas (graw...@gmail.com) wrote: I commited this one a while back. Thanks! --- man/sd-journal.xml | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/man/sd-journal.xml b/man/sd-journal.xml index 7a05aee..d3dc57f 100644 --- a/man/sd-journal.xml +++ b/man/sd-journal.xml @@ -79,7 +79,8 @@ citerefentryrefentrytitlesd_journal_add_match/refentrytitlemanvolnum3/manvolnum/citerefentry, citerefentryrefentrytitlesd_journal_seek_head/refentrytitlemanvolnum3/manvolnum/citerefentry, citerefentryrefentrytitlesd_journal_get_cursor/refentrytitlemanvolnum3/manvolnum/citerefentry, - citerefentryrefentrytitlesd_journal_cutoff_realtime_usec/refentrytitlemanvolnum3/manvolnum/citerefentry, + citerefentryrefentrytitlesd_journal_get_cutoff_realtime_usec/refentrytitlemanvolnum3/manvolnum/citerefentry, + citerefentryrefentrytitlesd_journal_get_cutoff_monotonic_usec/refentrytitlemanvolnum3/manvolnum/citerefentry, citerefentryrefentrytitlesd_journal_get_usage/refentrytitlemanvolnum3/manvolnum/citerefentry, citerefentryrefentrytitlesd_journal_get_catalog/refentrytitlemanvolnum3/manvolnum/citerefentry and @@ -111,7 +112,8 @@ citerefentryrefentrytitlesd_journal_add_match/refentrytitlemanvolnum3/manvolnum/citerefentry, citerefentryrefentrytitlesd_journal_seek_head/refentrytitlemanvolnum3/manvolnum/citerefentry, citerefentryrefentrytitlesd_journal_get_cursor/refentrytitlemanvolnum3/manvolnum/citerefentry, - citerefentryrefentrytitlesd_journal_cutoff_realtime_usec/refentrytitlemanvolnum3/manvolnum/citerefentry, + citerefentryrefentrytitlesd_journal_get_cutoff_realtime_usec/refentrytitlemanvolnum3/manvolnum/citerefentry, + citerefentryrefentrytitlesd_journal_get_cutoff_monotonic_usec/refentrytitlemanvolnum3/manvolnum/citerefentry, citerefentryrefentrytitlesd_journal_get_usage/refentrytitlemanvolnum3/manvolnum/citerefentry, citerefentryrefentrytitlesd_journal_get_fd/refentrytitlemanvolnum3/manvolnum/citerefentry, citerefentryrefentrytitlesd_journal_query_unique/refentrytitlemanvolnum3/manvolnum/citerefentry, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tests: do not use systemctl status --failed
On Sat, 31.05.14 22:28, Ronny Chevalier (chevalier.ro...@gmail.com) wrote: Thanks! Applied! since v212 calling systemctl status without arguments will show a overall system state --- test/TEST-01-BASIC/test.sh | 2 +- test/TEST-02-CRYPTSETUP/test.sh | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/test/TEST-01-BASIC/test.sh b/test/TEST-01-BASIC/test.sh index 84ccf26..d97fbe2 100755 --- a/test/TEST-01-BASIC/test.sh +++ b/test/TEST-01-BASIC/test.sh @@ -53,7 +53,7 @@ Description=Testsuite service After=multi-user.target [Service] -ExecStart=/bin/bash -c 'set -x; ( systemctl --failed --no-legend --no-pager; systemctl status --failed ) /failed ; echo OK /testok; while : ;do echo testsuite service waiting for journal to move to /var/log/journal /dev/console ; for i in /var/log/journal/*;do [ -d \$i ] echo \$i break 2; done; sleep 1; done; sleep 1; exit 0;' +ExecStart=/bin/bash -c 'set -x; systemctl --failed --no-legend --no-pager /failed ; echo OK /testok; while : ;do echo testsuite service waiting for journal to move to /var/log/journal /dev/console ; for i in /var/log/journal/*;do [ -d \$i ] echo \$i break 2; done; sleep 1; done; sleep 1; exit 0;' Type=oneshot EOF diff --git a/test/TEST-02-CRYPTSETUP/test.sh b/test/TEST-02-CRYPTSETUP/test.sh index b243254..4be2365 100755 --- a/test/TEST-02-CRYPTSETUP/test.sh +++ b/test/TEST-02-CRYPTSETUP/test.sh @@ -59,7 +59,7 @@ Description=Testsuite service After=multi-user.target [Service] -ExecStart=/bin/bash -c 'set -x; ( systemctl --failed --no-legend --no-pager; systemctl status --failed ) /failed ; echo OK /testok; while : ;do systemd-cat echo testsuite service waiting for /var/log/journal ; echo testsuite service waiting for journal to move to /var/log/journal /dev/console ; for i in /var/log/journal/*;do [ -d \$i ] echo \$i break 2; done; sleep 1; done; sleep 1; exit 0;' +ExecStart=/bin/bash -c 'set -x; systemctl --failed --no-legend --no-pager /failed ; echo OK /testok; while : ;do systemd-cat echo testsuite service waiting for /var/log/journal ; echo testsuite service waiting for journal to move to /var/log/journal /dev/console ; for i in /var/log/journal/*;do [ -d \$i ] echo \$i break 2; done; sleep 1; done; sleep 1; exit 0;' Type=oneshot EOF Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On 09.06.2014 09:33, Leho Kraav wrote: After upgrading systemd 208 - 212, every single cron job creates this flood in systemd journal: juuni 09 09:20:01 xps14 crond[15112]: pam_unix(crond:session): session opened for user root by (uid=0) juuni 09 09:20:01 xps14 systemd[15113]: pam_unix(systemd-user:session): session opened for user root by (uid=0) juuni 09 09:20:01 xps14 systemd[1]: Starting user-0.slice. ... juuni 09 09:20:02 xps14 systemd[1]: Started User Manager for UID 0. juuni 09 09:20:02 xps14 CROND[15116]: (root) CMD (test -x /usr/sbin/run-crons /usr/sbin/run-crons ) juuni 09 09:20:02 xps14 CROND[15112]: pam_unix(crond:session): session closed for user root juuni 09 09:20:02 xps14 systemd[1]: Stopping User Manager for UID 0... ... juuni 09 09:20:02 xps14 systemd[1]: Stopped User Manager for UID 0. juuni 09 09:20:02 xps14 systemd[1]: Stopping user-0.slice. juuni 09 09:20:02 xps14 systemd[1]: Removed slice user-0.slice. Another related question to trying to filter this output: why some lines are logged with program crond and some CROND? With loginctl linger-enable a shorter version of a cron run looks like this now: ... juuni 10 19:30:01 xps14 crond[21310]: pam_unix(crond:session): session opened for user root by (uid=0) juuni 10 19:30:01 xps14 CROND[21311]: (root) CMD (test -x /usr/sbin/run-crons /usr/sbin/run-crons ) juuni 10 19:30:01 xps14 systemd[1]: Starting Session 99 of user root. juuni 10 19:30:01 xps14 systemd[1]: Started Session 99 of user root. juuni 10 19:30:01 xps14 CROND[21310]: pam_unix(crond:session): session closed for user root ... I am considering filtering crond out of the human-visible status window and that's how the uppercase vs lowercase question arose. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: check the return value from udev_enumerate_scan_devices
On Wed, Jun 4, 2014 at 11:40 PM, Thomas H.P. Andersen pho...@gmail.com wrote: From: Thomas Hindoe Paaboel Andersen pho...@gmail.com The return value from udev_enumerate_scan_devices was stored but never used. I assume this was meant to be checked. Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Soliciting feedback for golang bindings to the systemd journal C API
On Mon, Jun 9, 2014 at 11:56 AM, Dan Mace dm...@redhat.com wrote: http://fpaste.org/107299/14019224/ Hrm, odd. Was it with the given tests? I will try it out and see if I can reproduce. I don't see anything immediately wrong in the code. Thanks, Brandon ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-network-wait-online symlinks to systemd-networkd
On Tue, Jun 10, 2014 at 06:26:47PM +0200, Lennart Poettering wrote: On Sun, 08.06.14 09:37, Dave Reisner (d...@falconindy.com) wrote: On a related topic, could we please stop shipping hardcoded symlinks in /etc in favor of documented reccomendations for downstream packagers? Hmm, well. The way automake currently works is that all config files are overwritten on make install. WHich is probably the right thing to do I think. People who use make install without DESTDIR= should be prepared to get their configured reset in one way or another... I guess I've been under the assumption that this was more of a you're on your own situation -- that the build sys was tailored towards the folks who are going to be doing the packaging for downstream. It sounds like this isn't really the case; that's fine with me. Perhaps there's a middle ground we can find. Tom mentioned the idea of a package mode during configuration. How about a simpler idea -- if DESTDIR is empty, add the symlinks. Otherwise, don't. Creating a couple of symlinks in /etc, and dropping a number of configuration files in, doesn't appear to be so much of a difference to me. Can you explain to me why we should depart from automake's traditional behaviour here, and wh symlinks should be something different from configuration files? Traditional configuration files have their own content. They can be hashed and tracked by your package manager. On upgrade, you can make an intelligent decision about what to do with the new file (replace, ignore, merge) based on the original and current hash of the existing file, and the has of the incoming file. Symlinks are more of a binary decision -- either they exist, or they don't. But, they're still configuration in this context. There's no way to track this on/off bit, so distros (well, speaking of Arch) simply nuke the symlinks and add back what they see as sane defaults during installation (explicitly leaving the symlinks untracked). I mean, ideally we'd just invoke systemctl preset for these things, but for the sake of cross-compilation we can avoid this easily. We probably should ship make sure to ship the very same symlinks we create with make install with a preset file though... Yeah, this sounds prone to drift unless it could be generated from some master list. d ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Soliciting feedback for golang bindings to the systemd journal C API
On Tue, Jun 10, 2014 at 6:07 AM, Dan Mace dm...@redhat.com wrote: Subject: Re: [systemd-devel] Soliciting feedback for golang bindings to the systemd journal C API The CoreOS crew has already done most of this work by writing a native Go implementation (rather than wrapping the C APIs). Can you please point me to the implementation? All I've seen is this: https://github.com/coreos/go-systemd/blob/master/journal/send.go Which only handles writes via the Unix socket. The implementation we're prototyping supports journal queries in ways that (to my knowledge) aren't possible without either forking to external tools (e.g. journalctl) or linking to sd-journal. The reason I didn't implement the sd-journal binding originally was because I thought that the journal DBus API would be coming sooner. I think adding this is great as-is and would happily merge it back upstream. We just have to be aware that eventually this API will need to expose a KDBus API too. Brandon ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
Am 10.06.2014 18:01, schrieb Lennart Poettering: On Tue, 10.06.14 13:24, Leho Kraav (l...@kraav.com) wrote: On 10.06.2014 13:20, Lennart Poettering wrote: On Mon, 09.06.14 09:33, Leho Kraav (l...@kraav.com) wrote: After upgrading systemd 208 - 212, every single cron job creates this flood in systemd journal: Can I quiet this down somehow? The idea with the journal is that we log everything that happens on the system, without exceptions, without hiding anything. And filtering is then applied when you view things, based on the big pool of data you have. This can be annoying, of course, but I am so very sure we should't suppress these things, because soemtimes they are useful to know about. journalctl has powerful filtering capabilities, we have them to make this huge datase palatable... I'm actually all for getting the upstream i.e. cron/PAM acting more sane so we don't even arrive at the logging huge amounts of low-effectiveness information problem, but as you wrote in your other reply, that might be a whole separate project. In the meantime mgilbert's suggestion for using loginctl --linger parameter seems to accomplish the goal of quieting cron logging. Any side effects to consider? Well, you keep the systemd user instance running all the time then instead of just when it is used... Doing that for root is fine, but if you do that for all users, then well, you got an additional process running for each one of them... which is cheaper than fire up a complete session again and again with all the logs recent systemd generates and you *already* have long running processes for each user ever started a cronjob also under Fedora 20 which don't flood the logs otherwise they already annoy me a lot because the last decades that all was not there and cronjobs where just fine vmware4030 0.0 0.0 74208 2064 ?SJun08 0:00 (sd-pam) harry 4351 0.0 0.0 74208 2132 ?SJun08 0:00 (sd-pam) root 9806 0.0 0.0 74208 2208 ?SJun08 0:00 (sd-pam) wwwcron 10894 0.0 0.0 74208 2224 ?SJun08 0:00 (sd-pam) apache 10918 0.0 0.0 74208 2236 ?SJun08 0:00 (sd-pam) signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Soliciting feedback for golang bindings to the systemd journal C API
- Original Message - From: Brandon Philips bran...@ifup.co To: Dan Mace dm...@redhat.com Cc: appinfra-l...@redhat.com, systemd-devel@lists.freedesktop.org Sent: Tuesday, June 10, 2014 1:08:59 PM Subject: Re: [systemd-devel] Soliciting feedback for golang bindings to the systemd journal C API On Mon, Jun 9, 2014 at 11:56 AM, Dan Mace dm...@redhat.com wrote: http://fpaste.org/107299/14019224/ Hrm, odd. Was it with the given tests? I will try it out and see if I can reproduce. I don't see anything immediately wrong in the code. Thanks, Brandon Brandon, The error was observed running this test: https://github.com/ironcladlou/go-systemd/blob/cgo-journal/journal/journal_test.go The test was executed in a Fedora 20 VirtualBox VM on a Fedora 20 host. I'm CC'ing Jhon Honce who is the only human who actually witnessed the panic. Thanks for looking into it, and sorry I don't have more information! -- Dan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] log: honour the kernel's quiet cmdline argument
On Tue, Jun 3, 2014 at 7:44 PM, Ronny Chevalier chevalier.ro...@gmail.com wrote: It was forgotten in b1e90ec515408aec2702522f6f68c4920b56375b See https://bugs.freedesktop.org/show_bug.cgi?id=79582 Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd mount operations
On Tue, Jun 10, 2014 at 7:25 PM, Nicholas Faustini n...@live.it wrote: Hi, I have an issue with the following systemd behavior (from manual): Mount points created at runtime (independently of unit files or /etc/fstab) will be monitored by systemd and appear like any other mount unit in systemd. See /proc/self/mountinfo description in proc(5). I need to manage mount operations directly without any systemd intervention, is it possible to disable such behavior? What behavior? systemd doesn't *prevent* you from mounting anything anywhere, it simply *monitors* the mounts, for purposes of unit dependencies. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shorten_uuid: use proper table size
On Wed, 28.05.14 11:24, Maciej Wereski (m.were...@partner.samsung.com) wrote: When the function is called the buffer is filled with 36 chars, and we then strip the non-hex-chars, so that 34 chars result. But the function signature should still indicate that we need 36 chars initially.. Lennart Well, i ( 36) is used for source and j ( 32) is used for destination. After the loop destination[32] and destination[33] is set. Also shorten_uuid() is used in two places, where id[34] is passed as destination. So it looked for me like destination should be 34. I am an idiot and you are right... I now merged a patch that turns both strings into arrays and we speciy both sizes. I hope that cleans up the confusion. Please check! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On Tue, 10.06.14 19:03, Leho Kraav (l...@kraav.com) wrote: On 10.06.2014 19:01, Lennart Poettering wrote: In the meantime mgilbert's suggestion for using EDIT **loginctl enable-linger** command seems to accomplish the goal of quieting cron logging. Any side effects to consider? Well, you keep the systemd user instance running all the time then instead of just when it is used... Doing that for root is fine, but if you do that for all users, then well, you got an additional process running for each one of them... Right. For time being, root cron jobs are the primary issue. I'll see what happens with the others. enable-linger persists across reboots? Yes. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On Tue, 10.06.14 20:05, Leho Kraav (l...@kraav.com) wrote: On 09.06.2014 09:33, Leho Kraav wrote: After upgrading systemd 208 - 212, every single cron job creates this flood in systemd journal: juuni 09 09:20:01 xps14 crond[15112]: pam_unix(crond:session): session opened for user root by (uid=0) juuni 09 09:20:01 xps14 systemd[15113]: pam_unix(systemd-user:session): session opened for user root by (uid=0) juuni 09 09:20:01 xps14 systemd[1]: Starting user-0.slice. ... juuni 09 09:20:02 xps14 systemd[1]: Started User Manager for UID 0. juuni 09 09:20:02 xps14 CROND[15116]: (root) CMD (test -x /usr/sbin/run-crons /usr/sbin/run-crons ) juuni 09 09:20:02 xps14 CROND[15112]: pam_unix(crond:session): session closed for user root juuni 09 09:20:02 xps14 systemd[1]: Stopping User Manager for UID 0... ... juuni 09 09:20:02 xps14 systemd[1]: Stopped User Manager for UID 0. juuni 09 09:20:02 xps14 systemd[1]: Stopping user-0.slice. juuni 09 09:20:02 xps14 systemd[1]: Removed slice user-0.slice. Another related question to trying to filter this output: why some lines are logged with program crond and some CROND? No idea. cron sends that string, we merely display it... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-network-wait-online symlinks to systemd-networkd
On Tue, 10.06.14 13:10, Dave Reisner (d...@falconindy.com) wrote: Perhaps there's a middle ground we can find. Tom mentioned the idea of a package mode during configuration. How about a simpler idea -- if DESTDIR is empty, add the symlinks. Otherwise, don't. This sounds fragile... people should get the same results if they avoid DESTDIR= or if they use it and then copy the result to /... I mean, that's how DESTDIR has been traditionally defined, and I don't think we should add any magic to that... Creating a couple of symlinks in /etc, and dropping a number of configuration files in, doesn't appear to be so much of a difference to me. Can you explain to me why we should depart from automake's traditional behaviour here, and wh symlinks should be something different from configuration files? Traditional configuration files have their own content. They can be hashed and tracked by your package manager. On upgrade, you can make an intelligent decision about what to do with the new file (replace, ignore, merge) based on the original and current hash of the existing file, and the has of the incoming file. Symlinks are more of a binary decision -- either they exist, or they don't. But, they're still configuration in this context. There's no way to track this on/off bit, so distros (well, speaking of Arch) simply nuke the symlinks and add back what they see as sane defaults during installation (explicitly leaving the symlinks untracked). Symlinks should probably just be considered different type of file, that have a contents and stuff. The contents is usually a file name, and there's a size limit, but other than that it's just a magic kind of file, where the symlink destination is the conents. That's how git handles this, for example. I have the suspicion that this is really something to fix in your package manager. It should learn to handle symlink upgrades the same way as configuration file upgrades I mean, ideally we'd just invoke systemctl preset for these things, but for the sake of cross-compilation we can avoid this easily. We probably should ship make sure to ship the very same symlinks we create with make install with a preset file though... Yeah, this sounds prone to drift unless it could be generated from some master list. Well, given that it's not a hundred symlinks, but just a few, I think having a list in the preset files and one in the makefile isn't too error-prone... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bus-proxy: fix misplaced s/system/session/
On Tue, 10.06.14 20:00, Mantas Mikulėnas (graw...@gmail.com) wrote: Ouch. Appears I hit replace a bit too eargerly... Applied! Thanks! --- units/user/systemd-bus-pro...@.service.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/units/user/systemd-bus-pro...@.service.in b/units/user/systemd-bus-pro...@.service.in index 68f59f5..2f4df7c 100644 --- a/units/user/systemd-bus-pro...@.service.in +++ b/units/user/systemd-bus-pro...@.service.in @@ -12,5 +12,5 @@ Description=Legacy D-Bus Protocol Compatibility Daemon # The first argument will be replaced by the service by information on # the process requesting the proxy, we need a placeholder to keep the # space available for this. -ExecStart=@rootlibexecdir@/sessiond-bus-proxyd --address=kernel:path=/dev/kdbus/%U-user/bus --configuration=/etc/dbus-1/session.conf --configuration=/etc/dbus-1/session-local.conf --configuration=/etc/dbus-1/session.d/ +ExecStart=@rootlibexecdir@/systemd-bus-proxyd --address=kernel:path=/dev/kdbus/%U-user/bus --configuration=/etc/dbus-1/session.conf --configuration=/etc/dbus-1/session-local.conf --configuration=/etc/dbus-1/session.d/ NotifyAccess=main Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-network-wait-online symlinks to systemd-networkd
On Tue, Jun 10, 2014 at 07:32:56PM +0200, Lennart Poettering wrote: Symlinks should probably just be considered different type of file, that have a contents and stuff. The contents is usually a file name, and there's a size limit, but other than that it's just a magic kind of file, where the symlink destination is the conents. That's how git handles this, for example. I have the suspicion that this is really something to fix in your package manager. It should learn to handle symlink upgrades the same way as configuration file upgrades Does rpm handle this exact case? Can anyone comment on dpkg handling of this case? I mean, ideally we'd just invoke systemctl preset for these things, but for the sake of cross-compilation we can avoid this easily. We probably should ship make sure to ship the very same symlinks we create with make install with a preset file though... Yeah, this sounds prone to drift unless it could be generated from some master list. Well, given that it's not a hundred symlinks, but just a few, I think having a list in the preset files and one in the makefile isn't too error-prone... But it still involves humans. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
On Tue, 10.06.14 18:53, Lennart Poettering (lenn...@poettering.net) wrote: On Fri, 06.06.14 12:53, Rusty Bird (rustyb...@openmailbox.org) wrote: Humm. I can't say I particularly like the idea, but I can't dissmiss this either, I figure we have to do something like this. However, if we do this, then this needs to be a passive target, see systemd.special(7), under Special passive system units, and it should be documented in that section. Passive means it is pulled it by the units that implement a pre job, not by the units that implement the networking stack. This way it doesn't get added to the initial transaction unless there's actually some service that needs to be pulled in. See the man page for further discussion on this. Hmm, after talking to Kay about this: I figure we don't really need network-pre.target, as units that want to run before the network is up should just use: Before=systemd-networkd.service basic.target THis is enough since network management services like NM are normal services, and networkd is the exception in being available from earliest boot on, including in the initrd. This means, that any firewall service that wants to cover this must be a early-boot service (i.e. DefaultDependencies=no), and thus ordering itself before networkd and basic.target should suffice... If one day there's another network management solution that is capable of running this early during boot, then we can revisit this, but otherwise, the ordering mentioned above should be above, and generic enough since it requires no explicit mentioning of units we wouldn't ship with systemd anyway. Hope that makes sense, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-network-wait-online symlinks to systemd-networkd
On Tue, Jun 10, 2014 at 1:32 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 10.06.14 13:10, Dave Reisner (d...@falconindy.com) wrote: Perhaps there's a middle ground we can find. Tom mentioned the idea of a package mode during configuration. How about a simpler idea -- if DESTDIR is empty, add the symlinks. Otherwise, don't. This sounds fragile... people should get the same results if they avoid DESTDIR= or if they use it and then copy the result to /... I mean, that's how DESTDIR has been traditionally defined, and I don't think we should add any magic to that... Creating a couple of symlinks in /etc, and dropping a number of configuration files in, doesn't appear to be so much of a difference to me. Can you explain to me why we should depart from automake's traditional behaviour here, and wh symlinks should be something different from configuration files? Traditional configuration files have their own content. They can be hashed and tracked by your package manager. On upgrade, you can make an intelligent decision about what to do with the new file (replace, ignore, merge) based on the original and current hash of the existing file, and the has of the incoming file. Symlinks are more of a binary decision -- either they exist, or they don't. But, they're still configuration in this context. There's no way to track this on/off bit, so distros (well, speaking of Arch) simply nuke the symlinks and add back what they see as sane defaults during installation (explicitly leaving the symlinks untracked). Symlinks should probably just be considered different type of file, that have a contents and stuff. The contents is usually a file name, and there's a size limit, but other than that it's just a magic kind of file, where the symlink destination is the conents. That's how git handles this, for example. I have the suspicion that this is really something to fix in your package manager. It should learn to handle symlink upgrades the same way as configuration file upgrades The problem with installing these symlinks as part of a package is that the user may have removed them from /etc/systemd using systemctl disable. The next time they install systemd, the package puts the symlinks right back. Gentoo's Portage package manager has functionality to protect modified config files under /etc from being overwritten during reinstalls and upgrades. However, this protection does not apply to files which have been removed entirely by the sysadmin. We can implement post-install logic to avoid this problem, but that means we either need to remove the symlinks from DESTDIR manually or we need the build system to not create them in the first place. If rpm or dpkg have a way to detect when the sysadmin has removed a file and will not replace that file, that's news to me. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-network-wait-online symlinks to systemd-networkd
On 10/06/14 18:58, Mike Gilbert wrote: The problem with installing these symlinks as part of a package is that the user may have removed them from /etc/systemd using systemctl disable. ... If rpm or dpkg have a way to detect when the sysadmin has removed a file and will not replace that file, that's news to me. dpkg does. I don't know whether it works for symlinks, but it certainly does for ordinary files: if they're marked as conffiles[1] (as all files in /etc that are present in the .deb should be) then removal is treated as a deliberate sysadmin change. On the other hand, it isn't rocket science to remove those symlinks from the DESTDIR just after make install. systemd's unit symlinks seem somewhat analogous to /etc/rc?.d symlinks, and those aren't included in .deb packages: they are created by a tool in the postinst (equivalent of RPM %post). [1] this is dpkg jargon, and means something specific: configuration files that are shipped in the .deb are conffiles, but configuration files that are created by the preinst/postinst aren't ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] no fsck at boot
On Jun 9, 2014, at 5:24 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Reindl Harald at 09/06/14 19:57 did gyre and gimble: what disturbs me is they warning about touch /forcefsck while it's currently the *only* option to trigger a recommended fsck at boot on a remote-server (and no add kernel params for that in the grub-config and remove them after is not a sane way for sysadmins maintaining 10,20,30 remote servers) As has been mentioned numerous times, these warnings are there because if you need to use something to force an fsck (this current problem not withstanding) then modifying the suspect filesystem in question is a really bad idea! The warnings are in place to cover this use case and to discourage it as a first port of call without giving it proper thought. On a Rawhide, systemd 212-4 system, using ext4, I get this at boot time when max-mount-counts as set with tune2fs -c is reached: systemd-fsck[241]: /dev/sda3 has been mounted 3 times without being checked, check forced. I can't actually tell if e2fsck -f was used, but that's what I'd expect, whereas the usual fsck used every boot with fs_passno 1 or 2 is e2fsck -p. If I'm reading the thread correctly, a distinction by systemd is being made between max-mount-counts and interval-between-checks. It does the forced fsck for max-mount-counts, but not for interval-between-checks resulting in the need for /forcefsck being used. Regardless of whether systemd should just do the forced fsck or not, the behavior should be the same for both max-mount-counts and interval-between-checks. Also on Rawhide, I'm finding that even if fs_passno is set to 0 , systemd is still doing fsck for root. Maybe it's arguably correct to ignore fs_passno 0 for root on ext234, but it's incorrect behavior for XFS and Btrfs and a bad hack for systemd to depend on a faux fsck.fs to ensure nothing is done even when nothing was asked to be done. https://bugzilla.redhat.com/show_bug.cgi?id=1098799 Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
2014-06-10 19:44 GMT+02:00 Lennart Poettering lenn...@poettering.net: I figure we don't really need network-pre.target, as units that want to run before the network is up should just use: Before=systemd-networkd.service basic.target THis is enough since network management services like NM are normal services, and networkd is the exception in being available from earliest boot on, including in the initrd. This means, that any firewall service that wants to cover this must be a early-boot service (i.e. DefaultDependencies=no), and thus ordering itself before networkd and basic.target should suffice... If one day there's another network management solution that is capable of running this early during boot, then we can revisit this, but otherwise, the ordering mentioned above should be above, and generic enough since it requires no explicit mentioning of units we wouldn't ship with systemd anyway. Debian's ifupdown does run during early boot, i.e. in sysinit.target. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
2014-06-10 19:44 GMT+02:00 Lennart Poettering lenn...@poettering.net: I figure we don't really need network-pre.target, as units that want to run before the network is up should just use: Before=systemd-networkd.service basic.target THis is enough since network management services like NM are normal services, and networkd is the exception in being available from earliest boot on, including in the initrd. This means, that any firewall service that wants to cover this must be a early-boot service (i.e. DefaultDependencies=no), and thus ordering itself before networkd and basic.target should suffice... Fwiw, I noticed that we already have a few firewall services using Before=network.target, specifically - firewalld - pyroman - iptables-persistent - shorewall - arno-iptables-firewall - netscript See [1]. I guess that means they are all broken atm and standardizing on a upstream provided target would make sense. Cheers, Michael [1] http://codesearch.debian.net/search?q=Before%3D.*network.target -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-network-wait-online symlinks to systemd-networkd
On Tue, 10.06.14 13:58, Mike Gilbert (flop...@gentoo.org) wrote: Symlinks should probably just be considered different type of file, that have a contents and stuff. The contents is usually a file name, and there's a size limit, but other than that it's just a magic kind of file, where the symlink destination is the conents. That's how git handles this, for example. I have the suspicion that this is really something to fix in your package manager. It should learn to handle symlink upgrades the same way as configuration file upgrades The problem with installing these symlinks as part of a package is that the user may have removed them from /etc/systemd using systemctl disable. The next time they install systemd, the package puts the symlinks right back. Again, that's exactly what happens for configuration files too if you use automake: on make install they are replaced by the original, upstream versions. Why is recreating the symlinks bad, if overriding the config files isn't? Gentoo's Portage package manager has functionality to protect modified config files under /etc from being overwritten during reinstalls and upgrades. However, this protection does not apply to files which have been removed entirely by the sysadmin. Well, this really sounds like a package manager deficiency. It should be able to manage symlinks properly. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-network-wait-online symlinks to systemd-networkd
On Tue, Jun 10, 2014 at 5:50 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 10.06.14 13:58, Mike Gilbert (flop...@gentoo.org) wrote: Symlinks should probably just be considered different type of file, that have a contents and stuff. The contents is usually a file name, and there's a size limit, but other than that it's just a magic kind of file, where the symlink destination is the conents. That's how git handles this, for example. I have the suspicion that this is really something to fix in your package manager. It should learn to handle symlink upgrades the same way as configuration file upgrades The problem with installing these symlinks as part of a package is that the user may have removed them from /etc/systemd using systemctl disable. The next time they install systemd, the package puts the symlinks right back. Again, that's exactly what happens for configuration files too if you use automake: on make install they are replaced by the original, upstream versions. Why is recreating the symlinks bad, if overriding the config files isn't? People don't generally remove config files; they just make changes. On the other hand, removing the symlinks would be a very typical action due to the way systemctl disable works. There is some ambiguity as to what a missing symlink means: did the sysadmin remove it, or did it never exist in the first place? If systemctl disable would do something like create a symlink to /dev/null, that would be easier to detect. I suppose we should implement something like Debian's conffiles to protect file removals, but that's probably not going to be a very high priority given the small number of packages for which it really matters. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
