Re: [systemd-devel] [ANNOUNCE] systemd 219
В Wed, 18 Feb 2015 01:14:44 +0100 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет: On Tue, Feb 17, 2015 at 08:05:29PM +0100, Goffredo Baroncelli wrote: Hi Lennart, On 2015-02-16 23:59, Lennart Poettering wrote: * journald now sets the special FS_NOCOW file flag for its journal files. This should improve performance on btrfs, by avoiding heavy fragmentation when journald's write-pattern is used on COW file systems. It degrades btrfs' data integrity guarantees for the files to the same levels as for ext3/ext4 however. This should be OK though as journald does its own data integrity checks and all its objects are checksummed on disk. Also, journald should handle btrfs disk full events a lot more gracefully now, by processing SIGBUS errors, and not relying on fallocate() anymore. If I read correctly the code, the FS_NOCOW is a temporary workaround, i.e. when the file is closed (or rotated ?) the FS_NOCOW flags is unset again. It is true ? Yes, but you miss the point in general. FS_NOCOW is set during the entire time when the file is being written to, which could be months, and then it is unset when the file will not be written to anymore. So indeed, the file is not protected by btrfs checksums for the majority of time, but journald does its own checksumming, so the contents are protected in a different way. btrfs checksumming theoretically allows you to transparently recover after media corruption if filesystem has redundancy (more than one copy of data). Journald checksum will probably detect corruption, but can it repair it? If so, the time window where a file is un-protect by the checksum is quite small. I was worried not about the corruption detection but about loosing the ability to recover the file from a good copy (if available) in case of corruption. But this seems limited only when the file is in use (before the next rotation). Zbyszek ___ 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
Re: [systemd-devel] [PATCH v4] Added support for Uplink Failure Detection using BindCarrier
В Tue, 17 Feb 2015 04:06:57 -0800
Alin Rauta alin.ra...@intel.com пишет:
+
+static int link_handle_bound_to_list(Link *link) {
+Link *l;
+Iterator i;
+int r;
+bool required_up = false;
+bool link_is_up = false;
+
+assert(link);
+
+if (hashmap_isempty(link-bound_to_links))
+return 0;
+
+if (link-flags IFF_UP)
+link_is_up = true;
+
+HASHMAP_FOREACH (l, link-bound_to_links, i)
+if (link_has_carrier(l)) {
+required_up = true;
+break;
+}
+
+if (!required_up link_is_up) {
+r = link_down(link);
+if (r 0)
+return r;
+} else if (required_up !link_is_up) {
+r = link_up(link);
+if (r 0)
+return r;
+}
+
+return 0;
+}
+
This means if link was administratively down it will be
reactivated again
ip link set dev down-link down
unplug up-link
plug up-link
down-link is now up. Is it intentional?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/9] Connect to plymouth and support cancellation of in, progress fsck
On Tue, Feb 17, 2015 at 05:26:05PM +0100, Didier Roche wrote:
Le 14/02/2015 17:38, Zbigniew Jędrzejewski-Szmek a écrit :
On Thu, Feb 05, 2015 at 06:09:24PM +0100, Didier Roche wrote:
From ec3b3d2cd4b0097f9fafa6c3f0f400e06292e21c Mon Sep 17 00:00:00 2001
From: Didier Roche didro...@ubuntu.com
Date: Thu, 5 Feb 2015 17:08:18 +0100
Subject: [PATCH 3/9] Connect to plymouth and support cancellation of in
progress fsck
Try to connect and send to plymouth (if running) some checked report
progress,
using direct plymouth protocole.
Update message is the following:
fsckd:num_devices:progress:string
* num_devices corresponds to the current number of devices being checked
(int)
* progress corresponds to the current minimum percentage of all devices
being
checked (float, from 0 to 100)
* string is a translated message ready to be displayed by the plymouth theme
displaying the information above. It can be overriden by plymouth themes
supporting i18n.
Grab in fsckd plymouth watch key Control+C, and propagate this cancel
request
to systemd-fsck which will terminate fsck.
Send a message to signal to user what key we are grabbing for fsck cancel.
Message is: fsckd-cancel-msg:string
Where string is a translated string ready to be displayed by the plymouth
theme
indicating that Control+C can be used to cancel current checks. It can be
overriden (matching only fsckd-cancel-msg prefix) for themes supporting
i18n.
---
src/fsck/fsck.c | 33 +
src/fsckd/fsckd.c | 145
+-
src/fsckd/fsckd.h | 5 ++
3 files changed, 173 insertions(+), 10 deletions(-)
diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
index d5aaf9e..1f5a3de 100644
--- a/src/fsck/fsck.c
+++ b/src/fsck/fsck.c
@@ -132,7 +132,7 @@ static void test_files(void) {
}
-static int process_progress(int fd, dev_t device_num) {
+static int process_progress(int fd, pid_t fsck_pid, dev_t device_num) {
_cleanup_fclose_ FILE *f = NULL;
usec_t last = 0;
_cleanup_close_ int fsckd_fd = -1;
@@ -159,11 +159,13 @@ static int process_progress(int fd, dev_t device_num)
{
while (!feof(f)) {
int pass;
+size_t buflen;
size_t cur, max;
-ssize_t n;
+ssize_t r;
usec_t t;
_cleanup_free_ char *device = NULL;
FsckProgress progress;
+FsckdMessage fsckd_message;
if (fscanf(f, %i %lu %lu %ms, pass, cur, max,
device) != 4)
break;
@@ -181,9 +183,19 @@ static int process_progress(int fd, dev_t device_num) {
progress.max = max;
progress.pass = pass;
-n = send(fsckd_fd, progress, sizeof(FsckProgress), 0);
-if (n 0 || (size_t) n sizeof(FsckProgress))
+r = send(fsckd_fd, progress, sizeof(FsckProgress), 0);
+if (r 0 || (size_t) r sizeof(FsckProgress))
log_warning_errno(errno, Cannot communicate fsck
progress to fsckd: %m);
+
+/* get fsckd requests, only read when we have coherent
size data */
+r = ioctl(fsckd_fd, FIONREAD, buflen);
+if (r == 0 (size_t) buflen == sizeof(FsckdMessage)) {
Shoudlnt' this be = ? If two messages are queued, buflen will be
bigger then one message, and we'll never read it.
Indeed, changed it.
+r = recv(fsckd_fd, fsckd_message,
sizeof(FsckdMessage), 0);
+if (r 0 fsckd_message.cancel) {
+log_warning(Request to cancel fsck from
fsckd);
log_notice or log_info. Actually log_info I think, since this is a
legitimate user request.
Done.
+
+n = send(current-fd, cancel_msg, sizeof(FsckdMessage), 0);
+if (n 0 || (size_t) n sizeof(FsckdMessage))
+return log_warning_errno(n, Cannot send cancel to fsck on
(%u, %u): %m, major(current-devnum), minor(current-devnum));
line wrap please.
Done. Btw, I was wondering if there was any kind of contributor rule
like a style guideline in systemd? I probably just missed it.
CODING_STYLE.
There's a bit of a inconsitency about good line length limits, but
this one wraps two times in my window which I consider too much :)
+
+if (!m-plymouth_cancel_sent) {
+/* indicate to plymouth that we listen to Ctrl+C */
+r = loop_write(m-plymouth_fd, PLYMOUTH_REQUEST_KEY,
sizeof(PLYMOUTH_REQUEST_KEY), true);
+if (r 0)
+return log_warning_errno(errno, Can't send to
plymouth cancel key: %m);
+m-plymouth_cancel_sent = true;
+plymouth_cancel_message = strappenda(fsckd-cancel-msg:,
Press Ctrl+C to cancel all checks in
Re: [systemd-devel] [PATCH] shutdown: avoid calling `kexec` binary unnessecarily
The bootloader spec does not say which entry is to be the default. I cannot
support the spec unless I can choose a single default kernel.
http://freedesktop.org/wiki/Specifications/BootLoaderSpec/
On Tue, Feb 17, 2015 at 7:00 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Mon, Feb 16, 2015 at 07:53:47PM -0800, Shawn Landden wrote:
On Mon, Feb 16, 2015 at 5:08 AM, Lennart Poettering
lenn...@poettering.net
wrote:
On Fri, 13.02.15 14:18, Shawn Landden (sh...@churchofgit.com) wrote:
Still use helper when Xen Dom0, to avoid duplicating some hairy
code.
Hmm, what precisely does the helper do on xen?
So we don't have any logic to load kexec kernels?
Currently we don't.
My hope though was that we can make the whole kexec thing work without
having kexec-tools installed. With the new kernel syscall for loading
the kernel we should be able to implement this all without any other
tools.
Ideally we'd not use any external tools anymore, not even in the Xen
case, hence I am curious what precisely the special hookup for Xen is
here...?
Lennart
https://git.kernel.org/cgit/utils/kernel/kexec/kexec-tools.git/tree/kexec/kexec-xen.c
I've attached my patch.
I'm having a problem with kexec_file_load() returning ENOMEM that I
havn't
resolved.
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Shawn Landden
From d5446e324143f55e67bc2defe1c78a4ea4201142 Mon Sep 17 00:00:00 2001
From: Shawn Landden sh...@churchofgit.com
Date: Fri, 13 Feb 2015 13:48:07 -0800
Subject: [PATCH] shutdown: avoid calling `kexec` binary unnessecarily
Still use helper when Xen Dom0, to avoid duplicating some hairy code.
So we don't have any logic to load kexec kernels?
---
TODO | 3 --
src/core/shutdown.c | 121
++-
src/shared/missing.h | 7 +++
3 files changed, 116 insertions(+), 15 deletions(-)
diff --git a/TODO b/TODO
index 255a4f2..d914d2c 100644
--- a/TODO
+++ b/TODO
@@ -90,9 +90,6 @@ Features:
* maybe introduce WantsMountsFor=? Usecase:
http://lists.freedesktop.org/archives/systemd-devel/2015-January/027729.html
-* rework kexec logic to use new kexec_file_load() syscall, so that we
- don't have to call kexec tool anymore.
-
* The udev blkid built-in should expose a property that reflects
whether media was sensed in USB CF/SD card readers. This should then
be used to control SYSTEMD_READY=1/0 so that USB card readers aren't
diff --git a/src/core/shutdown.c b/src/core/shutdown.c
index 71f001a..14febf3 100644
--- a/src/core/shutdown.c
+++ b/src/core/shutdown.c
@@ -19,6 +19,7 @@
along with systemd; If not, see http://www.gnu.org/licenses/.
***/
+#include ctype.h
#include sys/mman.h
#include sys/types.h
#include sys/reboot.h
@@ -27,6 +28,7 @@
#include sys/stat.h
#include sys/mount.h
#include sys/syscall.h
+#include sys/utsname.h
#include fcntl.h
#include dirent.h
#include errno.h
@@ -138,6 +140,35 @@ static int parse_argv(int argc, char *argv[]) {
return 0;
}
+/*
+ * Remove parameter from a kernel command line. Helper function for
kexec.
+ * (copied from kexec-tools)
+ */
+static void remove_parameter(char *line, const char *param_name) {
+char *start, *end;
+
+start = strstr(line, param_name);
+
+/* parameter not found */
+if (!start)
+return;
+
+/*
+ * check if that's really the start of a parameter and not in
+ * the middle of the word
+ */
+if (start != line !isspace(*(start-1)))
+return;
+
+end = strstr(start, );
+if (!end)
+*start = 0;
+else {
+memmove(start, end+1, strlen(end));
+*(end + strlen(end)) = 0;
+}
+}
+
static int switch_root_initramfs(void) {
if (mount(/run/initramfs, /run/initramfs, NULL, MS_BIND,
NULL) 0)
return log_error_errno(errno, Failed to mount bind
/run/initramfs on /run/initramfs: %m);
@@ -152,6 +183,57 @@ static int switch_root_initramfs(void) {
return switch_root(/run/initramfs, /oldroot, false,
MS_BIND);
}
+static int kernel_load(bool overwrite) {
+int r = -ENOTSUP;
+
+/* only x86_64 and x32 in 3.18 */
+#ifdef __NR_kexec_file_load
+/* If uses has no already loaded a kexec kernel assume
they
+ * want the same one they are currently running. */
+if (!overwrite !kexec_loaded()) {
+struct utsname u;
+_cleanup_free_
Re: [systemd-devel] [PATCH] shutdown: avoid calling `kexec` binary unnessecarily
On Tue, Feb 17, 2015 at 7:00 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Mon, Feb 16, 2015 at 07:53:47PM -0800, Shawn Landden wrote:
On Mon, Feb 16, 2015 at 5:08 AM, Lennart Poettering
lenn...@poettering.net
wrote:
On Fri, 13.02.15 14:18, Shawn Landden (sh...@churchofgit.com) wrote:
Still use helper when Xen Dom0, to avoid duplicating some hairy
code.
Hmm, what precisely does the helper do on xen?
So we don't have any logic to load kexec kernels?
Currently we don't.
My hope though was that we can make the whole kexec thing work without
having kexec-tools installed. With the new kernel syscall for loading
the kernel we should be able to implement this all without any other
tools.
Ideally we'd not use any external tools anymore, not even in the Xen
case, hence I am curious what precisely the special hookup for Xen is
here...?
Lennart
https://git.kernel.org/cgit/utils/kernel/kexec/kexec-tools.git/tree/kexec/kexec-xen.c
I've attached my patch.
I'm having a problem with kexec_file_load() returning ENOMEM that I
havn't
resolved.
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Shawn Landden
From d5446e324143f55e67bc2defe1c78a4ea4201142 Mon Sep 17 00:00:00 2001
From: Shawn Landden sh...@churchofgit.com
Date: Fri, 13 Feb 2015 13:48:07 -0800
Subject: [PATCH] shutdown: avoid calling `kexec` binary unnessecarily
Still use helper when Xen Dom0, to avoid duplicating some hairy code.
So we don't have any logic to load kexec kernels?
---
TODO | 3 --
src/core/shutdown.c | 121
++-
src/shared/missing.h | 7 +++
3 files changed, 116 insertions(+), 15 deletions(-)
diff --git a/TODO b/TODO
index 255a4f2..d914d2c 100644
--- a/TODO
+++ b/TODO
@@ -90,9 +90,6 @@ Features:
* maybe introduce WantsMountsFor=? Usecase:
http://lists.freedesktop.org/archives/systemd-devel/2015-January/027729.html
-* rework kexec logic to use new kexec_file_load() syscall, so that we
- don't have to call kexec tool anymore.
-
* The udev blkid built-in should expose a property that reflects
whether media was sensed in USB CF/SD card readers. This should then
be used to control SYSTEMD_READY=1/0 so that USB card readers aren't
diff --git a/src/core/shutdown.c b/src/core/shutdown.c
index 71f001a..14febf3 100644
--- a/src/core/shutdown.c
+++ b/src/core/shutdown.c
@@ -19,6 +19,7 @@
along with systemd; If not, see http://www.gnu.org/licenses/.
***/
+#include ctype.h
#include sys/mman.h
#include sys/types.h
#include sys/reboot.h
@@ -27,6 +28,7 @@
#include sys/stat.h
#include sys/mount.h
#include sys/syscall.h
+#include sys/utsname.h
#include fcntl.h
#include dirent.h
#include errno.h
@@ -138,6 +140,35 @@ static int parse_argv(int argc, char *argv[]) {
return 0;
}
+/*
+ * Remove parameter from a kernel command line. Helper function for
kexec.
+ * (copied from kexec-tools)
+ */
+static void remove_parameter(char *line, const char *param_name) {
+char *start, *end;
+
+start = strstr(line, param_name);
+
+/* parameter not found */
+if (!start)
+return;
+
+/*
+ * check if that's really the start of a parameter and not in
+ * the middle of the word
+ */
+if (start != line !isspace(*(start-1)))
+return;
+
+end = strstr(start, );
+if (!end)
+*start = 0;
+else {
+memmove(start, end+1, strlen(end));
+*(end + strlen(end)) = 0;
+}
+}
+
static int switch_root_initramfs(void) {
if (mount(/run/initramfs, /run/initramfs, NULL, MS_BIND,
NULL) 0)
return log_error_errno(errno, Failed to mount bind
/run/initramfs on /run/initramfs: %m);
@@ -152,6 +183,57 @@ static int switch_root_initramfs(void) {
return switch_root(/run/initramfs, /oldroot, false,
MS_BIND);
}
+static int kernel_load(bool overwrite) {
+int r = -ENOTSUP;
+
+/* only x86_64 and x32 in 3.18 */
+#ifdef __NR_kexec_file_load
+/* If uses has no already loaded a kexec kernel assume
they
+ * want the same one they are currently running. */
+if (!overwrite !kexec_loaded()) {
+struct utsname u;
+_cleanup_free_ char *vmlinuz = NULL, *initrd =
NULL, *cmdline = NULL;
+_cleanup_close_ int vmlinuz_fd = -1, initrd_fd
= -1;
+
+r = uname(u);
+
Re: [systemd-devel] [PATCH] shutdown: avoid calling `kexec` binary unnessecarily
On Tue, Feb 17, 2015 at 4:34 PM, Shawn Landden sh...@churchofgit.com
wrote:
On Tue, Feb 17, 2015 at 7:00 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Mon, Feb 16, 2015 at 07:53:47PM -0800, Shawn Landden wrote:
On Mon, Feb 16, 2015 at 5:08 AM, Lennart Poettering
lenn...@poettering.net
wrote:
On Fri, 13.02.15 14:18, Shawn Landden (sh...@churchofgit.com) wrote:
Still use helper when Xen Dom0, to avoid duplicating some hairy
code.
Hmm, what precisely does the helper do on xen?
So we don't have any logic to load kexec kernels?
Currently we don't.
My hope though was that we can make the whole kexec thing work without
having kexec-tools installed. With the new kernel syscall for loading
the kernel we should be able to implement this all without any other
tools.
Ideally we'd not use any external tools anymore, not even in the Xen
case, hence I am curious what precisely the special hookup for Xen is
here...?
Lennart
https://git.kernel.org/cgit/utils/kernel/kexec/kexec-tools.git/tree/kexec/kexec-xen.c
I've attached my patch.
I'm having a problem with kexec_file_load() returning ENOMEM that I
havn't
resolved.
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Shawn Landden
From d5446e324143f55e67bc2defe1c78a4ea4201142 Mon Sep 17 00:00:00 2001
From: Shawn Landden sh...@churchofgit.com
Date: Fri, 13 Feb 2015 13:48:07 -0800
Subject: [PATCH] shutdown: avoid calling `kexec` binary unnessecarily
Still use helper when Xen Dom0, to avoid duplicating some hairy code.
So we don't have any logic to load kexec kernels?
---
TODO | 3 --
src/core/shutdown.c | 121
++-
src/shared/missing.h | 7 +++
3 files changed, 116 insertions(+), 15 deletions(-)
diff --git a/TODO b/TODO
index 255a4f2..d914d2c 100644
--- a/TODO
+++ b/TODO
@@ -90,9 +90,6 @@ Features:
* maybe introduce WantsMountsFor=? Usecase:
http://lists.freedesktop.org/archives/systemd-devel/2015-January/027729.html
-* rework kexec logic to use new kexec_file_load() syscall, so that we
- don't have to call kexec tool anymore.
-
* The udev blkid built-in should expose a property that reflects
whether media was sensed in USB CF/SD card readers. This should then
be used to control SYSTEMD_READY=1/0 so that USB card readers aren't
diff --git a/src/core/shutdown.c b/src/core/shutdown.c
index 71f001a..14febf3 100644
--- a/src/core/shutdown.c
+++ b/src/core/shutdown.c
@@ -19,6 +19,7 @@
along with systemd; If not, see http://www.gnu.org/licenses/.
***/
+#include ctype.h
#include sys/mman.h
#include sys/types.h
#include sys/reboot.h
@@ -27,6 +28,7 @@
#include sys/stat.h
#include sys/mount.h
#include sys/syscall.h
+#include sys/utsname.h
#include fcntl.h
#include dirent.h
#include errno.h
@@ -138,6 +140,35 @@ static int parse_argv(int argc, char *argv[]) {
return 0;
}
+/*
+ * Remove parameter from a kernel command line. Helper function for
kexec.
+ * (copied from kexec-tools)
+ */
+static void remove_parameter(char *line, const char *param_name) {
+char *start, *end;
+
+start = strstr(line, param_name);
+
+/* parameter not found */
+if (!start)
+return;
+
+/*
+ * check if that's really the start of a parameter and not in
+ * the middle of the word
+ */
+if (start != line !isspace(*(start-1)))
+return;
+
+end = strstr(start, );
+if (!end)
+*start = 0;
+else {
+memmove(start, end+1, strlen(end));
+*(end + strlen(end)) = 0;
+}
+}
+
static int switch_root_initramfs(void) {
if (mount(/run/initramfs, /run/initramfs, NULL, MS_BIND,
NULL) 0)
return log_error_errno(errno, Failed to mount bind
/run/initramfs on /run/initramfs: %m);
@@ -152,6 +183,57 @@ static int switch_root_initramfs(void) {
return switch_root(/run/initramfs, /oldroot, false,
MS_BIND);
}
+static int kernel_load(bool overwrite) {
+int r = -ENOTSUP;
+
+/* only x86_64 and x32 in 3.18 */
+#ifdef __NR_kexec_file_load
+/* If uses has no already loaded a kexec kernel assume
they
+ * want the same one they are currently running. */
+if (!overwrite !kexec_loaded()) {
+struct utsname u;
+_cleanup_free_ char *vmlinuz = NULL, *initrd =
NULL, *cmdline = NULL;
+_cleanup_close_ int vmlinuz_fd = -1,
Re: [systemd-devel] [PATCH] shutdown: avoid calling `kexec` binary unnessecarily
On Tue, Feb 17, 2015 at 04:46:26PM -0800, Shawn Landden wrote: The bootloader spec does not say which entry is to be the default. I cannot support the spec unless I can choose a single default kernel. http://freedesktop.org/wiki/Specifications/BootLoaderSpec/ But it says where to look for kernels. Your patch only checks in /boot directly, but the BLS specifies more directories. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 219
Lennart Poettering wrote on 17/02/15 10:08: mount something-else /foo systemctl start foo.mount In this case the second line is a NOP, since the first line already mounted something on /foo, and thus made foo.mount active. So, even if foo.mount (the actual unit file) specifies it's What=something (not What=something-else) the fact that *anything* is mounted to /foo is sufficient to make the foo.mount unit active? This seems somewhat counter-intuitive to me. I can understand why from an implementation perspective - the mount units are all geared around the mountpoint not the What=, but it's certainly not what I'd expect as a user. Wouldn't it be better if there was some other state - e.g. conflict if something other than the desired device was mounted to the specified destination? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 219
On Wed, Feb 18, 2015 at 06:22:38AM +0300, Andrei Borzenkov wrote: В Wed, 18 Feb 2015 01:14:44 +0100 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет: On Tue, Feb 17, 2015 at 08:05:29PM +0100, Goffredo Baroncelli wrote: Hi Lennart, On 2015-02-16 23:59, Lennart Poettering wrote: * journald now sets the special FS_NOCOW file flag for its journal files. This should improve performance on btrfs, by avoiding heavy fragmentation when journald's write-pattern is used on COW file systems. It degrades btrfs' data integrity guarantees for the files to the same levels as for ext3/ext4 however. This should be OK though as journald does its own data integrity checks and all its objects are checksummed on disk. Also, journald should handle btrfs disk full events a lot more gracefully now, by processing SIGBUS errors, and not relying on fallocate() anymore. If I read correctly the code, the FS_NOCOW is a temporary workaround, i.e. when the file is closed (or rotated ?) the FS_NOCOW flags is unset again. It is true ? Yes, but you miss the point in general. FS_NOCOW is set during the entire time when the file is being written to, which could be months, and then it is unset when the file will not be written to anymore. So indeed, the file is not protected by btrfs checksums for the majority of time, but journald does its own checksumming, so the contents are protected in a different way. btrfs checksumming theoretically allows you to transparently recover after media corruption if filesystem has redundancy (more than one copy of data). Journald checksum will probably detect corruption, but can it repair it? No. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] units: add ConditionKernelCommandLine=resume
В Tue, 17 Feb 2015 01:33:41 -0300 Cristian Rodríguez crrodrig...@opensuse.org пишет: If there is no resume= ..it is not possible to hubrid-sleep or hibernate Why? (default) resume device can be specified directly in initrd. --- units/systemd-hibernate.service.in| 1 + units/systemd-hybrid-sleep.service.in | 1 + 2 files changed, 2 insertions(+) diff --git a/units/systemd-hibernate.service.in b/units/systemd-hibernate.service.in index 29d9b69..2a21cfc 100644 --- a/units/systemd-hibernate.service.in +++ b/units/systemd-hibernate.service.in @@ -11,6 +11,7 @@ Documentation=man:systemd-suspend.service(8) DefaultDependencies=no Requires=sleep.target After=sleep.target +ConditionKernelCommandLine=resume [Service] Type=oneshot diff --git a/units/systemd-hybrid-sleep.service.in b/units/systemd-hybrid-sleep.service.in index 914b686..b3039a0 100644 --- a/units/systemd-hybrid-sleep.service.in +++ b/units/systemd-hybrid-sleep.service.in @@ -11,6 +11,7 @@ Documentation=man:systemd-suspend.service(8) DefaultDependencies=no Requires=sleep.target After=sleep.target +ConditionKernelCommandLine=resume [Service] Type=oneshot ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Fw: Errors using machinectl pull-tar and machinectl pull-dkr
I tried systemd 219 on another system as well using some more debug options. Here's the outcome of this. 1) Checking signature of tar.gz failed there as well There's an error complaining about missing permissions to access /root/.gnupg/trustdb.gpg. It doesn't matter if the file exist. The error is always the same. Why does machinectl need access to that keyring? There's a keyring available at /usr/lib/systemd/import-pubring.gpg, shouldn't systemd-importd also have its own trustdb? Or is that import-pubring.gpg the trustdb of systemd-importd [root@host machinectl]# SYSTEMD_LOG_LEVEL=debug strace -o /tmp/machinectl.log -f -e file machinectl pull-tar https://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-root.tar.gz Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 error=n/a Got message type=method_return sender=org.freedesktop.DBus destination=:1.20 object=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=AddMatch cookie=2 reply_cookie=0 error=n/a Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=AddMatch cookie=3 reply_cookie=0 error=n/a Sent message type=method_call sender=n/a destination=org.freedesktop.import1 object=/org/freedesktop/import1 interface=org.freedesktop.import1.Manager member=PullTar cookie=4 reply_cookie=0 error=n/a Enqueued transfer job 1. Press C-c to continue download in background. Got message type=signal sender=org.freedesktop.DBus destination=:1.20 object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameAcquired cookie=2 reply_cookie=0 error=n/a Got message type=signal sender=:1.21 destination=n/a object=/org/freedesktop/import1/transfer/_1 interface=org.freedesktop.import1.Transfer member=LogMessage cookie=6 reply_cookie=0 error=n/a Pulling 'https://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-root.tar.gz', saving as 'trusty-server-cloudimg-amd64-root'. Got message type=signal sender=:1.21 destination=n/a object=/org/freedesktop/import1/transfer/_1 interface=org.freedesktop.import1.Transfer member=LogMessage cookie=7 reply_cookie=0 error=n/a Downloading 1.7K for https://cloud-images.ubuntu.com/trusty/current/SHA256SUMS. Got message type=signal sender=:1.21 destination=n/a object=/org/freedesktop/import1/transfer/_1 interface=org.freedesktop.import1.Transfer member=LogMessage cookie=8 reply_cookie=0 error=n/a Download of https://cloud-images.ubuntu.com/trusty/current/SHA256SUMS complete. Got message type=signal sender=:1.21 destination=n/a object=/org/freedesktop/import1/transfer/_1 interface=org.freedesktop.import1.Transfer member=LogMessage cookie=9 reply_cookie=0 error=n/a Downloading 177.6M for https://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-root.tar.gz. Got message type=signal sender=:1.21 destination=n/a object=/org/freedesktop/import1/transfer/_1 interface=org.freedesktop.import1.Transfer member=LogMessage cookie=10 reply_cookie=0 error=n/a Downloading 836B for https://cloud-images.ubuntu.com/trusty/current/SHA256SUMS.gpg. Got message type=signal sender=:1.21 destination=n/a object=/org/freedesktop/import1/transfer/_1 interface=org.freedesktop.import1.Transfer member=LogMessage cookie=11 reply_cookie=0 error=n/a Download of https://cloud-images.ubuntu.com/trusty/current/SHA256SUMS.gpg complete. Got message type=signal sender=:1.21 destination=n/a object=/org/freedesktop/import1/transfer/_1 interface=org.freedesktop.import1.Transfer member=LogMessage cookie=12 reply_cookie=0 error=n/a Got 1% of https://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-root.tar.gz. Got message type=signal sender=:1.21 destination=n/a object=/org/freedesktop/import1/transfer/_1 interface=org.freedesktop.import1.Transfer member=LogMessage cookie=13 reply_cookie=0 error=n/a Got 12% of https://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-root.tar.gz. 11s left at 13.1M/s. Got message type=signal sender=:1.21 destination=n/a object=/org/freedesktop/import1/transfer/_1 interface=org.freedesktop.import1.Transfer member=LogMessage cookie=14 reply_cookie=0 error=n/a Got 18% of https://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-root.tar.gz. 12s left at 11.7M/s. Got message type=signal sender=:1.21 destination=n/a object=/org/freedesktop/import1/transfer/_1 interface=org.freedesktop.import1.Transfer member=LogMessage cookie=15 reply_cookie=0 error=n/a Got 25% of https://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-root.tar.gz. 11s left
Re: [systemd-devel] Mount options of /var/run/users/pid
Thanks for all. I solve my problem with pam_exec for /etc/pam.d/login, /etc/pam.d/gdm-password by adding: session require pam_exec.so /sbin/resources /sbin/resources: #!/bin/bash mount $XDG_RUNTIME_DIR -o remount,noexec I mean this tread closed. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] shared: fix utf16_to_utf8() on big endian machines
Hello all,
219 shows a test failure in test-utf8 on big-endian machines (on
Debian: powerpc, s390, mips):
Assertion 'streq(a, utf8)' failed at src/test/test-utf8.c:103, function
test_utf16_to_utf8(). Aborting.
gdb shows that indeed the converted string is utter bogus. a is the
converted string, utf8 the expected outcome:
| Program received signal SIGABRT, Aborted.
| 0x20319c48 in raise () from /lib/powerpc-linux-gnu/libc.so.6
| (gdb) f 3
| #3 0x204befbc in test_utf16_to_utf8 () at src/test/test-utf8.c:103
| 103 assert_se(streq(a, utf8));
| (gdb) p a
| $1 = 0x204eb068
\346\204\200\303\230\346\210\200\303\234\346\214\200\307\230\343\237\234
| (gdb) p utf8
| $2 = abc\360\220\220\267
Patch against master attached, tested on both little-endian (unchanged
behaviour/code) and big-endian machine.
CC'ing Tom for reviewing, as that was introduced in
http://cgit.freedesktop.org/systemd/systemd/commit/?id=04166cb7d and
he might still have the UTF-16 stuff in his head :-)
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From 6768ad9a451c012615091ac2427ef5103cb1d178 Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Wed, 18 Feb 2015 06:45:34 +0100
Subject: [PATCH] shared: fix utf16_to_utf8() on big endian machines
We get the utf16 data passed as void* thus we need to correctly read the 16 bit
words in big endian order on big endian machines.
Spotted by failure of test_utf16_to_utf8() on PowerPC.
https://bugs.debian.org/778654
---
src/shared/utf8.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/shared/utf8.c b/src/shared/utf8.c
index 013c110..751ee3f 100644
--- a/src/shared/utf8.c
+++ b/src/shared/utf8.c
@@ -322,7 +322,11 @@ char *utf16_to_utf8(const void *s, size_t length) {
/* see RFC 2781 section 2.2 */
+#if __BYTE_ORDER == __LITTLE_ENDIAN
w1 = f[1] 8 | f[0];
+#else
+w1 = f[0] 8 | f[1];
+#endif
f += 2;
if (!utf16_is_surrogate(w1)) {
@@ -336,7 +340,11 @@ char *utf16_to_utf8(const void *s, size_t length) {
else if (f = (const uint8_t*) s + length)
break;
+#if __BYTE_ORDER == __LITTLE_ENDIAN
w2 = f[1] 8 | f[0];
+#else
+w2 = f[0] 8 | f[1];
+#endif
f += 2;
if (!utf16_is_trailing_surrogate(w2)) {
--
2.1.4
signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 219
On Tue, 17.02.15 17:13, Maciej Wereski (m.were...@partner.samsung.com) wrote: Hello, Dnia poniedziałek, 16 lutego 2015 23:59:56 Lennart Poettering pisze: Note that this version is not available in Fedora F22/F23 yet. The linker on ARM segfaults. Since the i386 and x86_64 versions built fine, I decided to release 219 anyway. I was able to build systemd v219 both on armv7l and aarch64. As a workaround I had to disable Link Time Optimizations. Well, did it segfault for you if you had lto on? This toolchain bug is tracked here btw: https://bugzilla.redhat.com/show_bug.cgi?id=1193212 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 5/9] Translate fsckd messages for plymouth
Updated to latest (impacted by a change in 3/9)
Didier
From b0209d20c648f6d275ed72bd78e74e3d48fc4068 Mon Sep 17 00:00:00 2001
From: Didier Roche didro...@ubuntu.com
Date: Mon, 26 Jan 2015 17:12:54 +0100
Subject: [PATCH 5/9] Translate fsckd messages for plymouth
For plymouth themes not supporting i18n (like .script), send translated
messages to display to user, which is equivalent to the sent machine
readable data.
---
po/POTFILES.in| 1 +
src/fsckd/fsckd.c | 10 +++---
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/po/POTFILES.in b/po/POTFILES.in
index b4c1121..70e7594 100644
--- a/po/POTFILES.in
+++ b/po/POTFILES.in
@@ -5,3 +5,4 @@ src/locale/org.freedesktop.locale1.policy.in
src/login/org.freedesktop.login1.policy.in
src/machine/org.freedesktop.machine1.policy.in
src/timedate/org.freedesktop.timedate1.policy.in
+src/fsckd/fsckd.c
diff --git a/src/fsckd/fsckd.c b/src/fsckd/fsckd.c
index 30c4f28..2143e1c 100644
--- a/src/fsckd/fsckd.c
+++ b/src/fsckd/fsckd.c
@@ -24,6 +24,7 @@
#include getopt.h
#include errno.h
+#include libintl.h
#include math.h
#include stdbool.h
#include stdlib.h
@@ -182,7 +183,7 @@ static int send_message_plymouth(Manager *m, const char *message) {
if (r 0)
return log_warning_errno(errno, Can't send to plymouth cancel key: %m);
m-plymouth_cancel_sent = true;
-plymouth_cancel_message = strappenda(fsckd-cancel-msg:, Press Ctrl+C to cancel all filesystem checks in progress);
+plymouth_cancel_message = strappenda(fsckd-cancel-msg:, _(Press Ctrl+C to cancel all filesystem checks in progress));
r = send_message_plymouth_socket(m-plymouth_fd, plymouth_cancel_message, false);
if (r 0)
log_warning_errno(r, Can't send filesystem cancel message to plymouth: %m);
@@ -222,8 +223,10 @@ static int update_global_progress(Manager *m) {
m-numdevices = current_numdevices;
m-percent = current_percent;
-if (asprintf(console_message, Checking in progress on %d disks (%3.1f%% complete),
-m-numdevices, m-percent) 0)
+if (asprintf(console_message,
+ ngettext(Checking in progress on %d disk (%3.1f%% complete),
+ Checking in progress on %d disks (%3.1f%% complete), m-numdevices),
+ m-numdevices, m-percent) 0)
return -ENOMEM;
if (asprintf(fsck_message, fsckd:%d:%3.1f:%s, m-numdevices, m-percent, console_message) 0)
return -ENOMEM;
@@ -507,6 +510,7 @@ int main(int argc, char *argv[]) {
log_set_target(LOG_TARGET_AUTO);
log_parse_environment();
log_open();
+init_gettext();
r = parse_argv(argc, argv);
if (r = 0)
--
2.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Errors using machinectl pull-tar and machinectl pull-dkr
Hi there, I tried machinectl from systemd 219 on Arch Linux (testing) today: I got two errors. Should we discuss this here or should I open a Bug Report? 1) Download if tar-file (http://www.freedesktop.org/software/systemd/man/machinectl.html#Examples) # machinectl pull-tar https://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-root.tar.gz Pulling 'https://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-root.tar.gz', saving as 'trusty-server-cloudimg-amd64-root'. Downloading 1.7K for https://cloud-images.ubuntu.com/trusty/current/SHA256SUMS. Image already downloaded. Skipping download. Download of https://cloud-images.ubuntu.com/trusty/current/trusty-server-cloudimg-amd64-root.tar.gz complete. Download of https://cloud-images.ubuntu.com/trusty/current/SHA256SUMS complete. Downloading 836B for https://cloud-images.ubuntu.com/trusty/current/SHA256SUMS.gpg. Download of https://cloud-images.ubuntu.com/trusty/current/SHA256SUMS.gpg complete. Failed to create local image: Is a directory Exiting It fails with Failed to create local image: Is a directory. I deleted all directories in /var/lib/machines before running this. But it doesn't help. 2) Download docker image # machinectl pull-dkr maxmeyer/middleman-presentation --verify=no --dkr-index-url=https://index.docker.io Enqueued transfer job 2. Press C-c to continue download in background. Pulling 'maxmeyer/middleman-presentation' with tag 'latest', saving as 'middleman-presentation'. Download of https://index.docker.io/v1/repositories/maxmeyer/middleman-presentation/images complete. Index lookup succeeded, directed to registry registry-1.docker.io. Downloading 66B for https://registry-1.docker.io/v1/repositories/maxmeyer/middleman-presentation/tags/latest. Download of https://registry-1.docker.io/v1/repositories/maxmeyer/middleman-presentation/tags/latest complete. Tag lookup succeeded, resolved to layer 9c7a28e8ae71392749006238db6f14c7877eefb22d61fe1d80dd3628ce46e89c. Downloading 1.9K for https://registry-1.docker.io/v1/images/9c7a28e8ae71392749006238db6f14c7877eefb22d61fe1d80dd3628ce46e89c/json. Download of https://registry-1.docker.io/v1/images/9c7a28e8ae71392749006238db6f14c7877eefb22d61fe1d80dd3628ce46e89c/json complete. Downloading 1.7K for https://registry-1.docker.io/v1/images/9c7a28e8ae71392749006238db6f14c7877eefb22d61fe1d80dd3628ce46e89c/ancestry. Download of https://registry-1.docker.io/v1/images/9c7a28e8ae71392749006238db6f14c7877eefb22d61fe1d80dd3628ce46e89c/ancestry complete. Ancestor lookup succeeded, requires layers: 511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158 8771fbfe935cde12b40418e029cdb68adff76d740eddb72fc6c811b1b4c16a3e 0e30e84e9513cb3d9d991389adfb77ac6afc9d75a5234e3d61af2f080c75d0ce c90a56bfe7ddec9f0c050f2ffcaa22e85d5e5996a00d9d163f819a57dc311851 6b030fdd4748e2dd0512b630f53d35d1034a2e293142288aa1ac740c50c0c1fc 787349ce806c46e8573f0c4973090474c62daf9e391aee0b17a01da129376651 9a1b111b9a31c2db50a3ddece4ff90a9a568f583ebaef0d0f8b23a86709e c4324c76a65d6eee9b0fbcd4fad4095510363d5b9412fb7e64e52e9c0cd724f8 0159db5a516e0292271ecb93664c35b8d8d129176b2b3995c0671b340408e5d7 ee340c5ac539f39ef06be2e3e6d12ebde2d7d624d6fd9b9c4176862272906f9a b33716f9c0ee2a2752f59e05b39b315cb6989803eb3232a396a454176da2e492 6af4b8ec77c0503d796caa1c9ab8649fc245534dc0f3b3b77bf0fa38222f8e3b c5d66d7f0f7eac219505d095055d0c1a597d2c03538bec7f1690360793202753 73b8b09f0244237c2cda8424253164328e6b8fd48869278c52ccf08dda71dbe8 51473a2975deaa7db36de496ded61e35c00040ea5f6bed1589c4370244d04b1b 1f74eced4c19ce234b731d5212ca36d5cf6f13db37ca003ca5c8cb5693920803 b6ab81dd3cee7dd4b8aaef1702904e56ed8653d4bc8c9d207e15c886fa29e785 95c4ff5d9bde3020eb6044662ce4af55449569935ee3e003b8c02609ac38aa59 9072524810f8feee04ce0c5a8127c78b6629a32485c2897dc1e5e854c80d7609 d7d9062aeb6dcf550991f0144df50183d9b773bcead883658297338983a3df5b d96ef2140cfc07e194cfb895be43cd9c78e37e0f8528ba742f2dbfc4e7657cfc 08c69fc1e0f0de7c750ff73940f8745a8b85fd438e181a981f54ff0ef4ef8397 0e8470f28955f606932c10539230e228f6680b6ff6ff7d58e906b19b4e971b03 8015de42529a447a0af23514324ebb31efc52be23446709d3a1ea2195e20c02a 07af4cff607d908c7d0ea1b7591a05902792c168d9d231a55c6487e9e37dd418 2409dfdde91c149f10a3b1cf6ffdb0d9a4588fa2fb6086410fe0049c117ca543 9c7a28e8ae71392749006238db6f14c7877eefb22d61fe1d80dd3628ce46e89c Pulling layer 511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158... Downloading 921B for https://registry-1.docker.io/v1/images/511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158/layer. Downloading 10.0K for https://registry-1.docker.io/v1/images/511136ea3c5a64f264b78b5433614aec563103b4d4702f3ba7d4d2698e22c158/layer. Failed
Re: [systemd-devel] [PATCH 8/9] Add man page and references to it.
Le 14/02/2015 17:58, Zbigniew Jędrzejewski-Szmek a écrit : On Thu, Feb 05, 2015 at 06:11:24PM +0100, Didier Roche wrote: Thanks for the suggestions, all applied! + +paraThe first time it connects to plymouth, a request +to grab Control+C keypresses is sent, as well as a text message. +When the cancel key is pressed, all running fscks are terminated. +It will also cancel any new connected fsck for the lifetime of +filenamesystemd-fsckd/filename./para paracommandsystemd-fsckd/ will instruct plymouth to grab Control+C keypresses. When the key is pressed, running checks will be terminated. It will also cancel any newly connected fsck instances for the lifetime of filenamesystemd-fsckd/filename./para This raises an intereseting question. IIUC, fsckd will exit on idle after 30s, losing the information that ^C was pressed. Shouldn't the exit-on-idle be raised to something bigger like 5 minutes, to make this less likely to happen? Good point, 30s of idleness (and so keeping ^C status) sounded enough to me at boot time (the more likely this will occur), most of fsck will chain anyway (first, the root one, and then, the other disks). Do you think about some cases with some .mount unit that are activated afterwards but still while plymouth is shown, like some encrypted /home partitions before the display manager shows up (didn't include the change, happy to do it though)? + +parafilenamesystemd-fsckd/filename passes the +following messages to the theme via libplymouth:/para Does it actually use libplymouth? argh, sorry, didn't change it. Now done. + + refsect1 +titleSee Also/title +para + citerefentryrefentrytitlesystemd/refentrytitlemanvolnum1/manvolnum/citerefentry, + citerefentryrefentrytitlesystemd-fsck/refentrytitlemanvolnum8/manvolnum/citerefentry, + citerefentryrefentrytitlefsck/refentrytitlemanvolnum8/manvolnum/citerefentry, + citerefentryrefentrytitlesystemd-quotacheck.service/refentrytitlemanvolnum8/manvolnum/citerefentry, Please add something like project='man-pages' (needs to be checked) to citerefentry, so the links are correct in html version. Seems to be project='man-pages' indeed. Done when referring to non systemd manpages (for the fsck* references) and same on man/systemd-f...@.service.xml Cheers, Didier From 3f888284bb59ecaa8b8fba614161dfabb6a3463e Mon Sep 17 00:00:00 2001 From: Didier Roche didro...@ubuntu.com Date: Mon, 26 Jan 2015 17:34:59 +0100 Subject: [PATCH 8/9] Add man page and references to it. Add man page explaining the plymouth theme protocol, usage of the daemon as well as the socket activation part. Adapt existing fsck man page. --- Makefile-man.am| 12 +++ man/systemd-f...@.service.xml | 24 +++--- man/systemd-fsckd.service.xml | 162 + units/systemd-fsckd.service.in | 1 + units/systemd-fsckd.socket | 2 +- 5 files changed, 189 insertions(+), 12 deletions(-) create mode 100644 man/systemd-fsckd.service.xml diff --git a/Makefile-man.am b/Makefile-man.am index 105853e..f2e13e8 100644 --- a/Makefile-man.am +++ b/Makefile-man.am @@ -67,6 +67,7 @@ MANPAGES += \ man/systemd-escape.1 \ man/systemd-firstboot.1 \ man/systemd-fsck@.service.8 \ + man/systemd-fsckd.service.8 \ man/systemd-fstab-generator.8 \ man/systemd-getty-generator.8 \ man/systemd-gpt-auto-generator.8 \ @@ -210,6 +211,8 @@ MANPAGES_ALIAS += \ man/systemd-firstboot.service.1 \ man/systemd-fsck-root.service.8 \ man/systemd-fsck.8 \ + man/systemd-fsckd.8 \ + man/systemd-fsckd.socket.8 \ man/systemd-hibernate-resume.8 \ man/systemd-hibernate.service.8 \ man/systemd-hybrid-sleep.service.8 \ @@ -323,6 +326,8 @@ man/systemd-ask-password-wall.service.8: man/systemd-ask-password-console.servic man/systemd-firstboot.service.1: man/systemd-firstboot.1 man/systemd-fsck-root.service.8: man/systemd-fsck@.service.8 man/systemd-fsck.8: man/systemd-fsck@.service.8 +man/systemd-fsckd.8: man/systemd-fsckd.service.8 +man/systemd-fsckd.socket.8: man/systemd-fsckd.service.8 man/systemd-hibernate-resume.8: man/systemd-hibernate-resume@.service.8 man/systemd-hibernate.service.8: man/systemd-suspend.service.8 man/systemd-hybrid-sleep.service.8: man/systemd-suspend.service.8 @@ -606,6 +611,12 @@ man/systemd-fsck-root.service.html: man/systemd-f...@.service.html man/systemd-fsck.html: man/systemd-f...@.service.html $(html-alias) +man/systemd-fsckd.html: man/systemd-fsckd.service.html + $(html-alias) + +man/systemd-fsckd.socket.html: man/systemd-fsckd.service.html + $(html-alias) + man/systemd-hibernate-resume.html: man/systemd-hibernate-res...@.service.html $(html-alias) @@ -1732,6 +1743,7 @@ EXTRA_DIST += \ man/systemd-escape.xml \ man/systemd-firstboot.xml \ man/systemd-f...@.service.xml \ + man/systemd-fsckd.service.xml \ man/systemd-fstab-generator.xml \ man/systemd-getty-generator.xml \ man/systemd-gpt-auto-generator.xml \ diff
Re: [systemd-devel] [PATCH 3/9] Connect to plymouth and support cancellation of in, progress fsck
Le 14/02/2015 17:38, Zbigniew Jędrzejewski-Szmek a écrit :
On Thu, Feb 05, 2015 at 06:09:24PM +0100, Didier Roche wrote:
From ec3b3d2cd4b0097f9fafa6c3f0f400e06292e21c Mon Sep 17 00:00:00 2001
From: Didier Roche didro...@ubuntu.com
Date: Thu, 5 Feb 2015 17:08:18 +0100
Subject: [PATCH 3/9] Connect to plymouth and support cancellation of in
progress fsck
Try to connect and send to plymouth (if running) some checked report progress,
using direct plymouth protocole.
Update message is the following:
fsckd:num_devices:progress:string
* num_devices corresponds to the current number of devices being checked (int)
* progress corresponds to the current minimum percentage of all devices being
checked (float, from 0 to 100)
* string is a translated message ready to be displayed by the plymouth theme
displaying the information above. It can be overriden by plymouth themes
supporting i18n.
Grab in fsckd plymouth watch key Control+C, and propagate this cancel request
to systemd-fsck which will terminate fsck.
Send a message to signal to user what key we are grabbing for fsck cancel.
Message is: fsckd-cancel-msg:string
Where string is a translated string ready to be displayed by the plymouth theme
indicating that Control+C can be used to cancel current checks. It can be
overriden (matching only fsckd-cancel-msg prefix) for themes supporting i18n.
---
src/fsck/fsck.c | 33 +
src/fsckd/fsckd.c | 145 +-
src/fsckd/fsckd.h | 5 ++
3 files changed, 173 insertions(+), 10 deletions(-)
diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
index d5aaf9e..1f5a3de 100644
--- a/src/fsck/fsck.c
+++ b/src/fsck/fsck.c
@@ -132,7 +132,7 @@ static void test_files(void) {
}
-static int process_progress(int fd, dev_t device_num) {
+static int process_progress(int fd, pid_t fsck_pid, dev_t device_num) {
_cleanup_fclose_ FILE *f = NULL;
usec_t last = 0;
_cleanup_close_ int fsckd_fd = -1;
@@ -159,11 +159,13 @@ static int process_progress(int fd, dev_t device_num) {
while (!feof(f)) {
int pass;
+size_t buflen;
size_t cur, max;
-ssize_t n;
+ssize_t r;
usec_t t;
_cleanup_free_ char *device = NULL;
FsckProgress progress;
+FsckdMessage fsckd_message;
if (fscanf(f, %i %lu %lu %ms, pass, cur, max, device) != 4)
break;
@@ -181,9 +183,19 @@ static int process_progress(int fd, dev_t device_num) {
progress.max = max;
progress.pass = pass;
-n = send(fsckd_fd, progress, sizeof(FsckProgress), 0);
-if (n 0 || (size_t) n sizeof(FsckProgress))
+r = send(fsckd_fd, progress, sizeof(FsckProgress), 0);
+if (r 0 || (size_t) r sizeof(FsckProgress))
log_warning_errno(errno, Cannot communicate fsck progress
to fsckd: %m);
+
+/* get fsckd requests, only read when we have coherent size
data */
+r = ioctl(fsckd_fd, FIONREAD, buflen);
+if (r == 0 (size_t) buflen == sizeof(FsckdMessage)) {
Shoudlnt' this be = ? If two messages are queued, buflen will be
bigger then one message, and we'll never read it.
Indeed, changed it.
+r = recv(fsckd_fd, fsckd_message,
sizeof(FsckdMessage), 0);
+if (r 0 fsckd_message.cancel) {
+log_warning(Request to cancel fsck from
fsckd);
log_notice or log_info. Actually log_info I think, since this is a
legitimate user request.
Done.
+
+n = send(current-fd, cancel_msg, sizeof(FsckdMessage), 0);
+if (n 0 || (size_t) n sizeof(FsckdMessage))
+return log_warning_errno(n, Cannot send cancel to fsck on (%u, %u):
%m, major(current-devnum), minor(current-devnum));
line wrap please.
Done. Btw, I was wondering if there was any kind of contributor rule
like a style guideline in systemd? I probably just missed it.
+
+if (!m-plymouth_cancel_sent) {
+/* indicate to plymouth that we listen to Ctrl+C */
+r = loop_write(m-plymouth_fd, PLYMOUTH_REQUEST_KEY,
sizeof(PLYMOUTH_REQUEST_KEY), true);
+if (r 0)
+return log_warning_errno(errno, Can't send to plymouth
cancel key: %m);
+m-plymouth_cancel_sent = true;
+plymouth_cancel_message = strappenda(fsckd-cancel-msg:, Press
Ctrl+C to cancel all checks in progress);
...all filesystem checks...
done (will repost the i18n patch + po ones as they are impacted by that
change)
+r = send_message_plymouth_socket(m-plymouth_fd,
plymouth_cancel_message, false);
+if (r 0)
+log_warning_errno(r, Can't send
Re: [systemd-devel] /run conf_file_dirs are never created
On Tue, 17.02.15 12:36, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: Hi: It appears that with the exception of /run/tmpfiles.d , the rest of the volatile conf_file_dirs are never created at boot. Is this intentional ? Yes. We only create those dirs if we actually want to place something in 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] [ANNOUNCE] systemd 219
Hello, Dnia poniedziałek, 16 lutego 2015 23:59:56 Lennart Poettering pisze: Note that this version is not available in Fedora F22/F23 yet. The linker on ARM segfaults. Since the i386 and x86_64 versions built fine, I decided to release 219 anyway. I was able to build systemd v219 both on armv7l and aarch64. As a workaround I had to disable Link Time Optimizations. Tizen 3.0: gcc 4.9.2 binutils 2.24.90 cheers, -- Maciej Wereski Samsung RD Institute Poland Samsung Electronics m.were...@partner.samsung.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/9] fsckd daemon for inter-fsckd communication
Le 14/02/2015 17:21, Zbigniew Jędrzejewski-Szmek a écrit :
Thanks for the review, reattached the patch with those fixes.
On Thu, Feb 05, 2015 at 06:06:50PM +0100, Didier Roche wrote:
+if (fsckd_fd 0) {
+log_warning_errno(errno, Cannot open fsckd socket, we won't report
fsck progress: %m);
+return -errno;
+}
+if (connect(fsckd_fd, sa.sa, offsetof(struct sockaddr_un, sun_path) +
strlen(sa.un.sun_path)) 0) {
+log_warning_errno(errno, Cannot connect to fsckd socket, we won't
report fsck progress: %m);
+return -errno;
Use 'return log_warning_errno(...)'.
+}
f = fdopen(fd, r);
if (!f) {
-safe_close(fd);
+log_warning_errno(errno, Cannot connect to fsck, we won't report
fsck progress: %m);
return -errno;
}
Also changed it on this last one below, thanks!
+
+/* ensure we have enough data to read */
+r = ioctl(fd, FIONREAD, buflen);
+if (r == 0 buflen != 0 (size_t) buflen sizeof(FsckProgress)) {
+if (client-buflen != buflen)
+client-buflen = buflen;
+/* we got twice the same size from a bad behaving client, kick
it off the list */
+else {
Shouldn't this be logged? Seems like this should be detected and fixed
if it happens.
Good suggestion. We don't have that much information on the client than
the fd at this stage (if we never got progress, we don't know device
major and minor numbers), but at least, we'll know that there are bad
behaving client. Added.
Didier
From fb6d1cc4df6a27684720ccfacdeca3cddadc44ca Mon Sep 17 00:00:00 2001
From: Didier Roche didro...@ubuntu.com
Date: Wed, 4 Feb 2015 16:42:47 +0100
Subject: [PATCH 1/9] fsckd daemon for inter-fsckd communication
Add systemd-fsckd multiplexer which accepts multiple systemd-fsck
instances to connect to it and sends progress report. systemd-fsckd then
computes and writes to /dev/console the number of devices currently being
checked and the minimum fsck progress. This will be used for interactive
progress report and cancelling in plymouth.
systemd-fsckd stops on idle when no systemd-fsck is connected.
Make the necessary changes to systemd-fsck to connect to the systemd-fsckd
socket.
---
.gitignore | 1 +
Makefile.am| 13 ++
src/fsck/fsck.c| 88
src/fsckd/Makefile | 1 +
src/fsckd/fsckd.c | 404 +
src/fsckd/fsckd.h | 34 +
6 files changed, 484 insertions(+), 57 deletions(-)
create mode 12 src/fsckd/Makefile
create mode 100644 src/fsckd/fsckd.c
create mode 100644 src/fsckd/fsckd.h
diff --git a/.gitignore b/.gitignore
index ab6d9d1..9400e75 100644
--- a/.gitignore
+++ b/.gitignore
@@ -74,6 +74,7 @@
/systemd-evcat
/systemd-firstboot
/systemd-fsck
+/systemd-fsckd
/systemd-fstab-generator
/systemd-getty-generator
/systemd-gnome-ask-password-agent
diff --git a/Makefile.am b/Makefile.am
index c463f23..e0e8bc6 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -389,6 +389,7 @@ rootlibexec_PROGRAMS = \
systemd-remount-fs \
systemd-reply-password \
systemd-fsck \
+ systemd-fsckd \
systemd-machine-id-commit \
systemd-ac-power \
systemd-sysctl \
@@ -2355,6 +2356,18 @@ systemd_fsck_LDADD = \
libsystemd-shared.la
# --
+systemd_fsckd_SOURCES = \
+ src/fsckd/fsckd.c \
+ $(NULL)
+
+systemd_fsckd_LDADD = \
+ libsystemd-internal.la \
+ libsystemd-label.la \
+ libsystemd-shared.la \
+ libudev-internal.la \
+ $(NULL)
+
+# --
systemd_machine_id_commit_SOURCES = \
src/machine-id-commit/machine-id-commit.c \
src/core/machine-id-setup.c \
diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
index 20b7940..f6ed1d1 100644
--- a/src/fsck/fsck.c
+++ b/src/fsck/fsck.c
@@ -27,6 +27,7 @@
#include unistd.h
#include fcntl.h
#include sys/file.h
+#include sys/stat.h
#include sd-bus.h
#include libudev.h
@@ -39,6 +40,8 @@
#include fileio.h
#include udev-util.h
#include path-util.h
+#include socket-util.h
+#include fsckd/fsckd.h
static bool arg_skip = false;
static bool arg_force = false;
@@ -132,58 +135,36 @@ static void test_files(void) {
arg_show_progress = true;
}
-static double percent(int pass, unsigned long cur, unsigned long max) {
-/* Values stolen from e2fsck */
-
-static const int pass_table[] = {
-0, 70, 90, 92, 95, 100
+static int process_progress(int fd, dev_t device_num) {
+_cleanup_fclose_ FILE *f = NULL;
+usec_t last = 0;
+_cleanup_close_ int fsckd_fd = -1;
+static const union sockaddr_union sa = {
+.un.sun_family = AF_UNIX,
+.un.sun_path = FSCKD_SOCKET_PATH,
};
-
Re: [systemd-devel] Scroll journalctl
Op Tue, 17 Feb 2015 15:25:42 +0100 schreef Reindl Harald h.rei...@thelounge.net: Am 17.02.2015 um 15:14 schrieb Floris: Dear maintainers, in the past I was able to scroll the journalctl output with the arrow keys. Unfortunately since 215 I have to use the s, d, f, and z keys. Even after the 218 update there is no difference. I hope someone can point me into the right direction to solve this problem in doubt journalctl | less to skip the hardwired pager Thanks, 'less' was missing on my system, after installing the journal works as expected. floris ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] /run conf_file_dirs are never created
Hi: It appears that with the exception of /run/tmpfiles.d , the rest of the volatile conf_file_dirs are never created at boot. Is this intentional ? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Scroll journalctl
Am 17.02.2015 um 15:14 schrieb Floris: Dear maintainers, in the past I was able to scroll the journalctl output with the arrow keys. Unfortunately since 215 I have to use the s, d, f, and z keys. Even after the 218 update there is no difference. I hope someone can point me into the right direction to solve this problem in doubt journalctl | less to skip the hardwired pager signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Scroll journalctl
Dear maintainers, in the past I was able to scroll the journalctl output with the arrow keys. Unfortunately since 215 I have to use the s, d, f, and z keys. Even after the 218 update there is no difference. I hope someone can point me into the right direction to solve this problem, thanks floris uname -a Linux Jessica 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) x86_64 GNU/Linux systemd --version systemd 218 +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT -GNUTLS +ACL +XZ -LZ4 -SECCOMP +BLKID -ELFUTILS +KMOD -IDN ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /run conf_file_dirs are never created
On Tue, Feb 17, 2015 at 12:36:39PM -0300, Cristian Rodríguez wrote: Hi: It appears that with the exception of /run/tmpfiles.d , the rest of the volatile conf_file_dirs are never created at boot. Is this intentional ? /run/tmpfiles.d is created as a side effect of kmod running. I don't think empty directories are configured to be created anywhere. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shutdown: avoid calling `kexec` binary unnessecarily
On Mon, Feb 16, 2015 at 07:53:47PM -0800, Shawn Landden wrote:
On Mon, Feb 16, 2015 at 5:08 AM, Lennart Poettering lenn...@poettering.net
wrote:
On Fri, 13.02.15 14:18, Shawn Landden (sh...@churchofgit.com) wrote:
Still use helper when Xen Dom0, to avoid duplicating some hairy
code.
Hmm, what precisely does the helper do on xen?
So we don't have any logic to load kexec kernels?
Currently we don't.
My hope though was that we can make the whole kexec thing work without
having kexec-tools installed. With the new kernel syscall for loading
the kernel we should be able to implement this all without any other
tools.
Ideally we'd not use any external tools anymore, not even in the Xen
case, hence I am curious what precisely the special hookup for Xen is
here...?
Lennart
https://git.kernel.org/cgit/utils/kernel/kexec/kexec-tools.git/tree/kexec/kexec-xen.c
I've attached my patch.
I'm having a problem with kexec_file_load() returning ENOMEM that I havn't
resolved.
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Shawn Landden
From d5446e324143f55e67bc2defe1c78a4ea4201142 Mon Sep 17 00:00:00 2001
From: Shawn Landden sh...@churchofgit.com
Date: Fri, 13 Feb 2015 13:48:07 -0800
Subject: [PATCH] shutdown: avoid calling `kexec` binary unnessecarily
Still use helper when Xen Dom0, to avoid duplicating some hairy code.
So we don't have any logic to load kexec kernels?
---
TODO | 3 --
src/core/shutdown.c | 121
++-
src/shared/missing.h | 7 +++
3 files changed, 116 insertions(+), 15 deletions(-)
diff --git a/TODO b/TODO
index 255a4f2..d914d2c 100644
--- a/TODO
+++ b/TODO
@@ -90,9 +90,6 @@ Features:
* maybe introduce WantsMountsFor=? Usecase:
http://lists.freedesktop.org/archives/systemd-devel/2015-January/027729.html
-* rework kexec logic to use new kexec_file_load() syscall, so that we
- don't have to call kexec tool anymore.
-
* The udev blkid built-in should expose a property that reflects
whether media was sensed in USB CF/SD card readers. This should then
be used to control SYSTEMD_READY=1/0 so that USB card readers aren't
diff --git a/src/core/shutdown.c b/src/core/shutdown.c
index 71f001a..14febf3 100644
--- a/src/core/shutdown.c
+++ b/src/core/shutdown.c
@@ -19,6 +19,7 @@
along with systemd; If not, see http://www.gnu.org/licenses/.
***/
+#include ctype.h
#include sys/mman.h
#include sys/types.h
#include sys/reboot.h
@@ -27,6 +28,7 @@
#include sys/stat.h
#include sys/mount.h
#include sys/syscall.h
+#include sys/utsname.h
#include fcntl.h
#include dirent.h
#include errno.h
@@ -138,6 +140,35 @@ static int parse_argv(int argc, char *argv[]) {
return 0;
}
+/*
+ * Remove parameter from a kernel command line. Helper function for kexec.
+ * (copied from kexec-tools)
+ */
+static void remove_parameter(char *line, const char *param_name) {
+char *start, *end;
+
+start = strstr(line, param_name);
+
+/* parameter not found */
+if (!start)
+return;
+
+/*
+ * check if that's really the start of a parameter and not in
+ * the middle of the word
+ */
+if (start != line !isspace(*(start-1)))
+return;
+
+end = strstr(start, );
+if (!end)
+*start = 0;
+else {
+memmove(start, end+1, strlen(end));
+*(end + strlen(end)) = 0;
+}
+}
+
static int switch_root_initramfs(void) {
if (mount(/run/initramfs, /run/initramfs, NULL, MS_BIND, NULL)
0)
return log_error_errno(errno, Failed to mount bind
/run/initramfs on /run/initramfs: %m);
@@ -152,6 +183,57 @@ static int switch_root_initramfs(void) {
return switch_root(/run/initramfs, /oldroot, false, MS_BIND);
}
+static int kernel_load(bool overwrite) {
+int r = -ENOTSUP;
+
+/* only x86_64 and x32 in 3.18 */
+#ifdef __NR_kexec_file_load
+/* If uses has no already loaded a kexec kernel assume they
+ * want the same one they are currently running. */
+if (!overwrite !kexec_loaded()) {
+struct utsname u;
+_cleanup_free_ char *vmlinuz = NULL, *initrd = NULL,
*cmdline = NULL;
+_cleanup_close_ int vmlinuz_fd = -1, initrd_fd = -1;
+
+r = uname(u);
+if (r 0)
+return -errno;
+
+vmlinuz = malloc(strlen(/boot/vmlinuz-) +
strlen(u.release) + 1);
+initrd =
Re: [systemd-devel] tmpfiles.d specifier support on argument when operating on files
El 17/02/15 a las 15:38, Cristian Rodríguez escribió:
HI:
In openSUSE, we have per *running kernel* sysctl snippets, currently
implemented as patch on systemd-sysctl.. I 'm currently attempting to
replace it for something sane..like
d /run/sysctl.d
L/run/sysctl.d/00-sysctl.conf-%v ----
/boot/sysctl.conf-%v
BUt argument does not support specifier expasion when dealing with
path names.. would you take patches for this ?
Thanks.
Ok, this patch works for my usecase..
From 10f9c96bb40834191765bd19f313ab17d18e3b31 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cristian=20Rodr=C3=ADguez?= crrodrig...@opensuse.org
Date: Tue, 17 Feb 2015 17:34:17 -0300
Subject: [PATCH] tmpfiles: add specifier support for the create symlink
argument
---
src/tmpfiles/tmpfiles.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index c948d4d..1b35b8e 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -1590,6 +1590,12 @@ static int parse_line(const char *fname, unsigned line, const char *buffer) {
i.argument = strappend(/usr/share/factory/, i.path);
if (!i.argument)
return log_oom();
+} else {
+r = specifier_printf(i.argument, specifier_table, NULL, i.argument);
+if (r 0) {
+log_error([%s:%u] Failed to replace specifiers: %s, fname, line, path);
+return r;
+}
}
break;
--
2.2.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] unit: When stopping due to BindsTo=, log which unit caused it
On Tue, Feb 17, 2015, at 01:47 PM, Colin Walters wrote: I'm trying to track down a relatively recent change in systemd which broke OSTree; see https://bugzilla.gnome.org/show_bug.cgi?id=743891 Systemd started to stop sysroot.mount, and this patch should help me debug why at least. Running with this patch, I see: systemd[1]: Unit sysroot.mount is bound to inactive unit dev-vda3.device. Stopping, too. But, dev-vda3.device is active: * dev-vda3.device - /dev/vda3 Follow: unit currently follows state of sys-devices-pci:00-:00:07.0-virtio2-block-vda-vda3.device Loaded: loaded Active: active (plugged) since Tue 2015-02-17 19:15:29 GMT; 6min ago Device: /sys/devices/pci:00/:00:07.0/virtio2/block/vda/vda3 I'll see if I can get more information out of debug logging. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 219
Hi Lennart, On 2015-02-16 23:59, Lennart Poettering wrote: * journald now sets the special FS_NOCOW file flag for its journal files. This should improve performance on btrfs, by avoiding heavy fragmentation when journald's write-pattern is used on COW file systems. It degrades btrfs' data integrity guarantees for the files to the same levels as for ext3/ext4 however. This should be OK though as journald does its own data integrity checks and all its objects are checksummed on disk. Also, journald should handle btrfs disk full events a lot more gracefully now, by processing SIGBUS errors, and not relying on fallocate() anymore. If I read correctly the code, the FS_NOCOW is a temporary workaround, i.e. when the file is closed (or rotated ?) the FS_NOCOW flags is unset again. It is true ? If so, the time window where a file is un-protect by the checksum is quite small. I was worried not about the corruption detection but about loosing the ability to recover the file from a good copy (if available) in case of corruption. But this seems limited only when the file is in use (before the next rotation). BR G.Baroncelli -- gpg @keyserver.linux.it: Goffredo Baroncelli kreijackATinwind.it Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd mysteriously shutting down after launch
On Sat, 2015-02-14 at 18:03 +0100, Zbigniew Jędrzejewski-Szmek wrote: On Fri, Feb 13, 2015 at 10:49:12AM +0100, Lennart Poettering wrote: On Thu, 12.02.15 22:30, Keller, Jacob E (jacob.e.kel...@intel.com) wrote: On Thu, 2015-02-12 at 20:15 +0100, Tom Gundersen wrote: On Thu, Feb 12, 2015 at 7:28 PM, Keller, Jacob E Now I'm having an interesting issue with the current git of systemd-networkd... It works just fine on load, and I get an ip address and everything is happy. After some amount of time, systemd-networkd goes into shutting down.. and I lose my ip address.. There is nothing obvious in the log to indicate that it was turned off. Any suggestions? I'm capturing a clean boot with the issue with SYSTEMD_LOG_LEVEL=debug enabled for more information now. This might be caused by the new exit-on-idle logic Tom added. But that should leave the IP address untouched when exiting. Tom, can you look at this? This should be fixed by commit a8ba6cd15d3a5edf1f9fbb4fd08dc428c3939072 Author: Tom Gundersen t...@jklm.no Date: Fri Feb 13 16:20:45 2015 +0100 exit-on-idle: only exit if actually idle sd_event_wait() returning 0 usually means that it timed out, which means it must have been idle. However, sd_event_wait() may return 0 in case an event was triggered but it turned out there was nothing to do. Make the check for idle explicit to avoid this edge-case. Zbyszek Yep this was fixed. Thanks so much for the help! Regards, Jake ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] unit: When stopping due to BindsTo=, log which unit caused it
I'm trying to track down a relatively recent change in systemd
which broke OSTree; see https://bugzilla.gnome.org/show_bug.cgi?id=743891
Systemd started to stop sysroot.mount, and this patch should help
me debug why at least.
While we're here, break on the first unit we find that will
deactivate, as there's no point in further iteration.
---
src/core/unit.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/core/unit.c b/src/core/unit.c
index ee8e607..c88eca3 100644
--- a/src/core/unit.c
+++ b/src/core/unit.c
@@ -1629,7 +1629,7 @@ static void unit_check_unneeded(Unit *u) {
static void unit_check_binds_to(Unit *u) {
bool stop = false;
-Unit *other;
+Unit *other = NULL;
Iterator i;
assert(u);
@@ -1648,12 +1648,14 @@ static void unit_check_binds_to(Unit *u) {
continue;
stop = true;
+break;
}
if (!stop)
return;
-log_unit_info(u-id, Unit %s is bound to inactive unit. Stopping,
too., u-id);
+assert(other);
+log_unit_info(u-id, Unit %s is bound to inactive unit %s. Stopping,
too., u-id, other-id);
/* A unit we need to run is gone. Sniff. Let's stop this. */
manager_add_job(u-manager, JOB_STOP, u, JOB_FAIL, true, NULL, NULL);
--
1.8.3.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] tmpfiles.d specifier support on argument when operating on files
HI: In openSUSE, we have per *running kernel* sysctl snippets, currently implemented as patch on systemd-sysctl.. I 'm currently attempting to replace it for something sane..like d /run/sysctl.d L/run/sysctl.d/00-sysctl.conf-%v ---- /boot/sysctl.conf-%v BUt argument does not support specifier expasion when dealing with path names.. would you take patches for this ? Thanks. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v4] Added support for Uplink Failure Detection using BindCarrier
---
man/systemd.network.xml | 11 +
src/libsystemd/sd-network/sd-network.c | 8 +
src/network/networkctl.c | 43 ++--
src/network/networkd-link.c | 394 +--
src/network/networkd-link.h | 3 +
src/network/networkd-network-gperf.gperf | 1 +
src/network/networkd-network.c | 1 +
src/network/networkd.h | 2 +-
src/systemd/sd-network.h | 6 +
9 files changed, 438 insertions(+), 31 deletions(-)
diff --git a/man/systemd.network.xml b/man/systemd.network.xml
index 485876b..60252e5 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -280,6 +280,17 @@
/listitem
/varlistentry
varlistentry
+ termvarnameBindCarrier=/varname/term
+ listitem
+paraA port or a list of ports. When set, controls the
+behaviour of the current interface. When all ports in the list
+are in an operational down state, the current interface is brought
+down. When at least one port has carrier, the current interface
+is brought up.
+/para
+ /listitem
+/varlistentry
+varlistentry
termvarnameAddress=/varname/term
listitem
paraA static IPv4 or IPv6 address and its prefix length,
diff --git a/src/libsystemd/sd-network/sd-network.c
b/src/libsystemd/sd-network/sd-network.c
index c4713fe..fb5152c 100644
--- a/src/libsystemd/sd-network/sd-network.c
+++ b/src/libsystemd/sd-network/sd-network.c
@@ -264,6 +264,14 @@ _public_ int sd_network_link_get_domains(int ifindex, char
***ret) {
return network_get_link_strv(DOMAINS, ifindex, ret);
}
+_public_ int sd_network_link_get_carrier_bound_to(int ifindex, char ***ret) {
+return network_get_link_strv(CARRIER_BOUND_TO, ifindex, ret);
+}
+
+_public_ int sd_network_link_get_carrier_bound_by(int ifindex, char ***ret) {
+return network_get_link_strv(CARRIER_BOUND_BY, ifindex, ret);
+}
+
_public_ int sd_network_link_get_wildcard_domain(int ifindex) {
int r;
_cleanup_free_ char *p = NULL, *s = NULL;
diff --git a/src/network/networkctl.c b/src/network/networkctl.c
index aa83f32..0637513 100644
--- a/src/network/networkctl.c
+++ b/src/network/networkctl.c
@@ -508,6 +508,8 @@ static int link_status_one(
const char *driver = NULL, *path = NULL, *vendor = NULL, *model =
NULL, *link = NULL;
const char *on_color_operational, *off_color_operational,
*on_color_setup, *off_color_setup;
+_cleanup_strv_free_ char **carrier_bound_to = NULL;
+_cleanup_strv_free_ char **carrier_bound_by = NULL;
struct ether_addr e;
unsigned iftype;
int r, ifindex;
@@ -606,12 +608,15 @@ static int link_status_one(
sd_network_link_get_network_file(ifindex, network);
+sd_network_link_get_carrier_bound_to(ifindex, carrier_bound_to);
+sd_network_link_get_carrier_bound_by(ifindex, carrier_bound_by);
+
printf(%s%s%s %i: %s\n, on_color_operational,
draw_special_char(DRAW_BLACK_CIRCLE), off_color_operational, ifindex, name);
-printf( Link File: %s\n
- Network File: %s\n
- Type: %s\n
- State: %s%s%s (%s%s%s)\n,
+printf( Link File: %s\n
+ Network File: %s\n
+ Type: %s\n
+ State: %s%s%s (%s%s%s)\n,
strna(link),
strna(network),
strna(t),
@@ -619,13 +624,13 @@ static int link_status_one(
on_color_setup, strna(setup_state), off_color_setup);
if (path)
-printf(Path: %s\n, path);
+printf(Path: %s\n, path);
if (driver)
-printf( Driver: %s\n, driver);
+printf( Driver: %s\n, driver);
if (vendor)
-printf( Vendor: %s\n, vendor);
+printf( Vendor: %s\n, vendor);
if (model)
-printf( Model: %s\n, model);
+printf( Model: %s\n, model);
if (have_mac) {
_cleanup_free_ char *description = NULL;
@@ -634,23 +639,29 @@ static int link_status_one(
ieee_oui(hwdb, e, description);
if (description)
-printf( HW Address: %s (%s)\n,
ether_addr_to_string(e, ea), description);
+printf( HW Address: %s (%s)\n,
ether_addr_to_string(e, ea), description);
else
-printf( HW Address: %s\n, ether_addr_to_string(e,
ea));
+printf( HW Address: %s\n,
ether_addr_to_string(e, ea));
}
if (mtu 0)
-printf( MTU: %u\n, mtu);
+
[systemd-devel] [PATCH v4] Added support for Uplink Failure Detection using BindCarrier
Hi, I've creating patch v4 after addressing your comments. I provided two APIs for networkctl command: 1. int sd_network_link_get_carrier_bound_to(int ifindex, char ***carriers); 2. int sd_network_link_get_carrier_bound_by(int ifindex, char ***carriers); This way, only few changes were needed in networkctl. Only the bound_by links (uplinks) are monitored. The bound_by map is evaluated only when the carrier is lost or gained. When a link is added, its bound_by bound_to maps are created. When a link is dropped, both maps are removed. When a link is readded, the maps are created again. When a link is renamed, the old bound_by bound_to maps are removed and new ones are created taking into account the new name. Let me know what you think, Alin Alin Rauta (1): Added support for Uplink Failure Detection using BindCarrier man/systemd.network.xml | 11 + src/libsystemd/sd-network/sd-network.c | 8 + src/network/networkctl.c | 43 ++-- src/network/networkd-link.c | 394 +-- src/network/networkd-link.h | 3 + src/network/networkd-network-gperf.gperf | 1 + src/network/networkd-network.c | 1 + src/network/networkd.h | 2 +- src/systemd/sd-network.h | 6 + 9 files changed, 438 insertions(+), 31 deletions(-) -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] test: bump KDBUS_CONN_MAX_MSGS_PER_USER value
Hi On Tue, Feb 17, 2015 at 12:35 PM, Lukasz Skalski l.skal...@samsung.com wrote: On 02/17/2015 12:20 PM, Djalal Harouni wrote: Hi Lukasz, Hi Djalal, On Tue, Feb 17, 2015 at 11:37:53AM +0100, Lukasz Skalski wrote: diff --git a/test/test-message.c b/test/test-message.c index 03ac71e..0cae942 100644 --- a/test/test-message.c +++ b/test/test-message.c @@ -28,7 +28,7 @@ * maximum number of queued messages from the same indvidual user after the * the un-accounted value has been hit */ -#define KDBUS_CONN_MAX_MSGS_PER_USER16 +#define KDBUS_CONN_MAX_MSGS_PER_USER128 Actually, the limit bump is just a temporary solution, to inspect or fix other bugs related to Gnome. David is working on this, I will let him decide if he wants to apply this patch or let it as it... Yes, I know that it is temporary solution, but at this moment, after bumping KDBUS_CONN_MAX_MSGS_PER_USER value we have some new errors in tests - for example in test-message.c:736 we get EXFULL errno (queue.c:287 says that we can't take more than half of the remaining space) instead of ENOBUFS. IMO we should align tests with latest changes. For the archives (as said on IRC): The old quota checks were easily exploitable, but on the other hand way too restrictive. On some fast machines, 32 queued messages exceeds the polkit queues on normal boots. That's why I bumped the limit for now. The patch you posted is technically correct (and I have the same queued locally since yesterday). However, the limit is so high, that you basically exceed the 10M pool size and thus cannot really test for the quota limits. I'm reworking the whole quota logic. I hope I can push it later today. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] feature request: dlopen
i don't know if you've seen this yet: http://news.slashdot.org/story/15/02/15/1959209/removing-libsystemd0-from-a-live-running-debian-system my name's luke leighton, i'm a software libre advocate, and the first major contribution that i made to software libre was to help bridge the impossible chasm between the microsoft world and the unix world, back in 1996 to 1999, by implementing and documenting NT Domains as well as a proper Network Neighbourhood (features of which, interestingly, have since been completely reimplemented in the form of avahi and zeroconf). i now tend to keep to myself except in circumstances where i perceive something similar occurring in the software libre community: a polarisation or an opportunity to extend (or reduce) the reach of software libre. a decision that has been made which makes the lives of huge numbers of ordinary users and systems administrators incredibly difficult, forcing them to make impossible decisions - that sort of thing. i note that there was announcement recently that the systemd team 'listens to users', so i am taking you at your word on that. now, i'm keenly aware of the views (technical and more) of systemd: i'm aware that there have been polls. most of them remind me of mother theresa's refusal to go to a war protest rally - she pointed out that next time they had a *peace* rally, to give her a call. so i'm not going to protest - i'm going to try a different approach. i'd like you to look at this list of debian packages that are dependent on libsystemd0: http://lkcl.net/reports/removing_systemd_from_debian/list_of_libsystemd0_dependent_packages.txt it's an enormous list, comprising some 15% of the packages present in debian today. it includes apache2-dev, bluetooth / bluez, the gimp, php, *all* of the video players (xine, mplayer, vlc), *all* of the games and 3D packages that use SDL or pulseaudio (which is most of them), *all* of the major desktop environments including xfce4, lxde, Gnome and KDE/Plasma, cups-daemon, one of the anti-virus daemons, most of the music software packages and services, most of the VoIP clients, the android SDK, the eclipse IDE, OpenJDK 7, erlang, Apache Tomcat. i'm just absolutely blown away by the extent of the dependencies. oh - and php as well. what the heck php5 is doing with a hard dependency on libsystemd0 i cannot imagine. now, because those are hard compile-time dependencies, the only possibility for the average debian user who chooses *not* to have libsystemd0 present on their system is for them to simply... not use *anything* on that list of over four and a half THOUSAND packages. i think the most important question to ask you at this point is: as a team, were you aware of the extent to which libsystemd0 has become a hard compile-time dependency on so many critical software packages in use today? and the second question, which is just as important, is: does this shock or alarm you enough to appreciate why people find the rapid introduction of libsystemd0 to be so objectionable? before answering, please bear in mind that i have done an analysis of a similar library and runtime (which i worked with a decade ago and am a minor contributor on): libselinux1 and SE/LInux. i can tell you right now that the way in which SE/Linux was introduced is *genuinely* completely different from the one that has brought us libsystemd0 (and has nothing to do with the technical debate, merits or otherwise of the software *or* its alternatives). in fact, the way in which libselinux1 was introduced - the careful research, the definition of its scope, how its instigators stuck to a clear roadmap, and its gradual introduction as an *optional* component that could be tested, deployed and rolled back *without* inconvenience or attempting to reverse impossiblly challenging or irreversible decisions if found to be troublesome, could be said (with understatement) to be a humbling model that libsystemd0 should learn from, retrospectively, very very fast. now, since beginning to write this a couple of days ago, i have encountered this: * https://lists.debian.org/debian-devel/2015/02/msg00189.html * http://forums.debian.net/viewtopic.php?f=20t=119836 there, we see that a debian developer has created unofficial packages that, if installed, provide replacements for key strategic packages entirely recompiled *without* systemd and without libsystemd0 being present. the key here is that they *are* entirely unofficial, making the decision to install them a difficult one, and flat-out impossible for many deployments where there are rules and contracts in place that prevent and prohibit the use even of debian-backports, let alone unofficial repositories. also, adam's work is only going to get harder and harder as time goes by, as the depth and extent of systemd's reach increases. so, whilst it's a good thing that adam has achieved what he has, it can definitely be said to be a stop-gap measure - allowing a *small subset* of users
Re: [systemd-devel] feature request: dlopen
On Tue, Feb 17, 2015 at 08:24:37PM +, Luke Kenneth Casson Leighton wrote: so i'm not going to protest - i'm going to try a different approach. i'd like you to look at this list of debian packages that are dependent on libsystemd0: http://lkcl.net/reports/removing_systemd_from_debian/list_of_libsystemd0_dependent_packages.txt it's an enormous list, comprising some 15% of the packages present in debian today. it includes apache2-dev, bluetooth / bluez, the gimp, php, *all* of the video players (xine, mplayer, vlc), *all* of the games and 3D packages that use SDL or pulseaudio (which is most of them), *all* of the major desktop environments including xfce4, lxde, Gnome and KDE/Plasma, cups-daemon, one of the anti-virus daemons, most of the music software packages and services, most of the VoIP clients, the android SDK, the eclipse IDE, OpenJDK 7, erlang, Apache Tomcat. i'm just absolutely blown away by the extent of the dependencies. How exactly did you create such a dependancy list? On my system (non-debian but fully systemd-only), I picked two random packages from your list, gimp and cheese: $ ldd /usr/bin/cheese | grep system $ ldd /usr/bin/gimp | grep system Hm, no dependencies there. Perhaps you might wish to just file a Debian bug so that they fix their build systems? Arch Linux doesn't have this kind of requirement, so something must be odd here... Also, this is a distro choice to make, the Debian developers seem pretty happy with systemd and how it is being loaded in their systems, so perhaps you might wish to ask them about this hard-requirement. Other distros do not have such a hard-requirement at this time, perhaps you might wish to try one of them if you do not want to use systemd? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] feature request: dlopen
2015-02-17 22:25 GMT+01:00 Greg KH gre...@linuxfoundation.org: On Tue, Feb 17, 2015 at 08:24:37PM +, Luke Kenneth Casson Leighton wrote: so i'm not going to protest - i'm going to try a different approach. i'd like you to look at this list of debian packages that are dependent on libsystemd0: http://lkcl.net/reports/removing_systemd_from_debian/list_of_libsystemd0_dependent_packages.txt it's an enormous list, comprising some 15% of the packages present in debian today. it includes apache2-dev, bluetooth / bluez, the gimp, php, *all* of the video players (xine, mplayer, vlc), *all* of the games and 3D packages that use SDL or pulseaudio (which is most of them), *all* of the major desktop environments including xfce4, lxde, Gnome and KDE/Plasma, cups-daemon, one of the anti-virus daemons, most of the music software packages and services, most of the VoIP clients, the android SDK, the eclipse IDE, OpenJDK 7, erlang, Apache Tomcat. i'm just absolutely blown away by the extent of the dependencies. How exactly did you create such a dependancy list? On my system (non-debian but fully systemd-only), I picked two random packages from your list, gimp and cheese: $ ldd /usr/bin/cheese | grep system $ ldd /usr/bin/gimp | grep system Hm, no dependencies there. Perhaps you might wish to just file a Debian bug so that they fix their build systems? Arch Linux doesn't have this kind of requirement, so something must be odd here... There is no such dependency in Debian either [1]. Luke simply has no idea what he is talking about. It would be great if Luke did some basic research and educate himself and not spread such misinformation. [1] https://packages.debian.org/sid/gimp -- 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] feature request: dlopen
Hi Luke, On Tue, Feb 17, 2015 at 9:24 PM, Luke Kenneth Casson Leighton l...@lkcl.net wrote: i note that there was announcement recently that the systemd team 'listens to users', so i am taking you at your word on that. I believe we are listening a lot. That does not necessarily mean that everyone will get all that they ask for though... i'd like you to look at this list of debian packages that are dependent on libsystemd0: http://lkcl.net/reports/removing_systemd_from_debian/list_of_libsystemd0_dependent_packages.txt it's an enormous list, comprising some 15% of the packages present in debian today. it includes apache2-dev, bluetooth / bluez, the gimp, php, *all* of the video players (xine, mplayer, vlc), *all* of the games and 3D packages that use SDL or pulseaudio (which is most of them), *all* of the major desktop environments including xfce4, lxde, Gnome and KDE/Plasma, cups-daemon, one of the anti-virus daemons, most of the music software packages and services, most of the VoIP clients, the android SDK, the eclipse IDE, OpenJDK 7, erlang, Apache Tomcat. i'm just absolutely blown away by the extent of the dependencies. oh - and php as well. what the heck php5 is doing with a hard dependency on libsystemd0 i cannot imagine. now, because those are hard compile-time dependencies, the only possibility for the average debian user who chooses *not* to have libsystemd0 present on their system is for them to simply... not use *anything* on that list of over four and a half THOUSAND packages. i think the most important question to ask you at this point is: as a team, were you aware of the extent to which libsystemd0 has become a hard compile-time dependency on so many critical software packages in use today? Speaking only for myself: no I was not aware of that. Moreover, I find it completely unbelievable. Admittedly I do not use Debian, and did not check how they do their packaging, but there is just no reason at all for most of those packages to link against libsystemd. and the second question, which is just as important, is: does this shock or alarm you enough to appreciate why people find the rapid introduction of libsystemd0 to be so objectionable? Again, speaking only for myself: no. (Again with the caveat that I don't actually believe in your statements, but for the sake of argument...) we are providing software that we hope people find useful. That includes a C library that people may link against if they so wish. If a lot of third-party developers chose to do that, that is firstly a sign that we are successful in creating useful software and secondly completely out of our control. If you don't want people to use our APIs, you should address the third-party developers who do. I really don't see what there is for us to do here. If you find the existence of libsystemd on your machine objectionable (note that it does not necessarily entail actually using systemd as PID1), then a more useful way to spend your time would be to post patches to make sure the existence of libsystemd does not adversely affect the software you are running (these patches probably need to go to the projects linking against systemd). In most cases that I'm aware of (e.g. the code I have contributed to third-party packages), the usage of libsystemd is a noop on systems where systemd is not running, so I really don't see the problem here. to the trouble of digging into why libsystemd0 is found to be so objectionable. my take on the matter is that the technical arguments - benefits or otherwise - of systemd and its alternatives - is completely irrelevant. over time people *will* develop alternatives (and are already doing so: mdev, eudev, uselessd, openrc and many more). Side note: these things are not alternatives to libsystemd (they are alternatives to udev and/or systemd as PID1). no, i feel that it really does have nothing to do with the technical benefits of the available options: what people are finding completely objectionable is that they have *no good choices*. it's use systemd or go away - and unfortunately almost without exception (slackware and FreeBSD being two notable ones) that piss off attitude is being replicated across *the entire GNU/Linux Distro world*. the situation is completely unprecedented and without parallel in the short history of software libre (and that's something that, honestly, i find to be really shocking, hence why i am contacting you). I disagree with most of that, but importantly you are missing a point: many (most?) packages linking against libsystemd can already at runtime fall back to alternatives. There is really no need for dlopen for this. The only cost you have is to have the (possibly unused) libsystemd library around on your system. It will be far from the only unused library you have, so this really seems like a tempest in a teapot. overall, they feel that they're being forced into the use of something that they feel
Re: [systemd-devel] udev: 60-persistent-storage.rules attempts blkid on removable devices with no medium present
On Mon, 2015-02-16 at 14:52 -0800, Hans Scholze wrote:
Hi,
I'm not sure if this is considered a problem but I noticed some
spurious error messages during boot. The source appears to be:
1. a USB media card reader is plugged in at boot
2. the device node exists regardless of whether a card is present
(expected)
3. line 70 of 60-persistent-storage.rules (KERNEL!=sr*,
IMPORT{builtin}=blkid) attempts blkid on the device with no card
present
4. the open() call in builtin_blkid() in udev-builtin-blkid.c fails
resulting in an error: /dev/sdd: No medium found message printed to
stderr
That seems to be the error. You cannot guarantee that blkid will never
see this error if the drive has removable media. It should have an
option for silently failing in these cases.
Regards
Oliver
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] feature request: dlopen
2015-02-17 22:35 GMT+01:00 Michael Biebl mbi...@gmail.com: 2015-02-17 22:25 GMT+01:00 Greg KH gre...@linuxfoundation.org: On Tue, Feb 17, 2015 at 08:24:37PM +, Luke Kenneth Casson Leighton wrote: so i'm not going to protest - i'm going to try a different approach. i'd like you to look at this list of debian packages that are dependent on libsystemd0: http://lkcl.net/reports/removing_systemd_from_debian/list_of_libsystemd0_dependent_packages.txt it's an enormous list, comprising some 15% of the packages present in debian today. it includes apache2-dev, bluetooth / bluez, the gimp, php, *all* of the video players (xine, mplayer, vlc), *all* of the games and 3D packages that use SDL or pulseaudio (which is most of them), *all* of the major desktop environments including xfce4, lxde, Gnome and KDE/Plasma, cups-daemon, one of the anti-virus daemons, most of the music software packages and services, most of the VoIP clients, the android SDK, the eclipse IDE, OpenJDK 7, erlang, Apache Tomcat. i'm just absolutely blown away by the extent of the dependencies. How exactly did you create such a dependancy list? On my system (non-debian but fully systemd-only), I picked two random packages from your list, gimp and cheese: $ ldd /usr/bin/cheese | grep system $ ldd /usr/bin/gimp | grep system Hm, no dependencies there. Perhaps you might wish to just file a Debian bug so that they fix their build systems? Arch Linux doesn't have this kind of requirement, so something must be odd here... There is no such dependency in Debian either [1]. Luke simply has no idea what he is talking about. It would be great if Luke did some basic research and educate himself and not spread such misinformation. Let me clarify this this misinformation and make it absolutely clear: There are less then 100 packages in the Debian archive which depend on libsystemd0 -- 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
[systemd-devel] [PATCH] test: bump KDBUS_CONN_MAX_MSGS_PER_USER value
diff --git a/test/test-message.c b/test/test-message.c index 03ac71e..0cae942 100644 --- a/test/test-message.c +++ b/test/test-message.c @@ -28,7 +28,7 @@ * maximum number of queued messages from the same indvidual user after the * the un-accounted value has been hit */ -#define KDBUS_CONN_MAX_MSGS_PER_USER 16 +#define KDBUS_CONN_MAX_MSGS_PER_USER 128 #define MAX_USER_TOTAL_MSGS (KDBUS_CONN_MAX_MSGS_UNACCOUNTED + \ KDBUS_CONN_MAX_MSGS_PER_USER) diff --git a/test/test-policy-ns.c b/test/test-policy-ns.c index 3437012..3c8b78e 100644 --- a/test/test-policy-ns.c +++ b/test/test-policy-ns.c @@ -38,7 +38,7 @@ #define MAX_CONN 64 #define POLICY_NAMEfoo.test.policy-test -#define KDBUS_CONN_MAX_MSGS_PER_USER16 +#define KDBUS_CONN_MAX_MSGS_PER_USER128 /** * Note: this test can be used to inspect policy_db-talk_access_hash -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] test: bump KDBUS_CONN_MAX_MSGS_PER_USER value
Hi Lukasz, On Tue, Feb 17, 2015 at 11:37:53AM +0100, Lukasz Skalski wrote: diff --git a/test/test-message.c b/test/test-message.c index 03ac71e..0cae942 100644 --- a/test/test-message.c +++ b/test/test-message.c @@ -28,7 +28,7 @@ * maximum number of queued messages from the same indvidual user after the * the un-accounted value has been hit */ -#define KDBUS_CONN_MAX_MSGS_PER_USER 16 +#define KDBUS_CONN_MAX_MSGS_PER_USER 128 Actually, the limit bump is just a temporary solution, to inspect or fix other bugs related to Gnome. David is working on this, I will let him decide if he wants to apply this patch or let it as it... Thank you Lukasz! #define MAX_USER_TOTAL_MSGS (KDBUS_CONN_MAX_MSGS_UNACCOUNTED + \ KDBUS_CONN_MAX_MSGS_PER_USER) diff --git a/test/test-policy-ns.c b/test/test-policy-ns.c index 3437012..3c8b78e 100644 --- a/test/test-policy-ns.c +++ b/test/test-policy-ns.c @@ -38,7 +38,7 @@ #define MAX_CONN 64 #define POLICY_NAME foo.test.policy-test -#define KDBUS_CONN_MAX_MSGS_PER_USER16 +#define KDBUS_CONN_MAX_MSGS_PER_USER128 /** * Note: this test can be used to inspect policy_db-talk_access_hash -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Djalal Harouni http://opendz.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Mount options of /var/run/users/pid
On Mon, 16.02.15 22:14, Павел Самсонов (pvsamsono...@gmail.com) wrote: If I have multiuser Linux installation with shell and DE access, my users have not places in system, where they able download something from internet and execute: / ro,exec /home rw,noexec /var rw,noexec All tmpfs noexec In Debian wheezy this done and work. In Debian jessie I have places (/run/users/*), where users may execute dowloaded executables. What I must do with this? As mentioned already. We do not support mounting /run/user/* with other mount options, and this is unlikely to hange. WHat you are trying to do does not provide any security (as discussed in this thread otherwise), and thus this is something we are unlikely to consider to support. Sorry, 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] user units and system units behavior
On 2015-02-16 at 11:14 +, Simon McVittie wrote: On 14/02/15 18:26, Ivan Shapovalov wrote: Yes, the per-session bus is there, but it is not used at all for communication with per-user systemd instance. I do want this to work, and I'm working on making it happen. It works on my Debian system, with the patched dbus that I recently uploaded to experimental. When my patches on https://bugs.freedesktop.org/show_bug.cgi?id=61301 have been merged, if dbus is compiled with --enable-user-session and you are running systemd, the per-login-session dbus-daemon --session will be replaced by a per-user-session dbus-daemon --session (see earlier thread for explanation of login session vs. user session). At that point, the dbus-daemon --session can be suitable for communicating with `systemd --user`. (I believe the plan is (still) that kdbus systems will always have an equivalent of this new per-user-session bus, and never a per-login-session bus.) No, mine /etc/X11/xinitrc.d is Simon's /etc/X11/Xsession.d and similar setups. It's apparently a distro-specific path. Yes. I think /etc/X11/xinitrc.d is what Red Hat and its derivatives use. Xsession.d is used instead in Debian and its derivatives, including Ubuntu. The differences are because, historically, this sort of plumbing was something that every distribution had to invent for itself. S Thanks for the heads-up and your work, Simon. I'm also looking forward for the time when all the bits are there. It means that `systemd --user` will be finally able to launch various pieces of DE, right? (Maybe with policykit patches to grant needed permissions to processes under `systemd --user`...) -- 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
