Re: [systemd-devel] journal entries for most recent pid?
On Tue, 25.03.14 15:59, Peter Hutterer (peter.hutte...@who-t.net) wrote: > I can't seem to find this in the documentation, so I do wonder if it exists: > is there an equivalent to journalctl -b -1 that lists the log of the most > recent pid? > > Specifically I'd like to run journalctl /usr/bin/Xorg --pid -1 or similar to > get users to attach the most recent log file instead of having to provide > _PID manually. Hmm, I can see the usecase for that, but I am not sure how we could implement this nicely... To implement this we'd have to store the starttime of each PID in the database, and then order by that. And then we'd have to figure out the most recent one, probably in a similar fashion as we already allow this boot ids... I have added this now to the TODO list, but don't hold your breath... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] add keyhandler support to cryptsetup
On Tue, 25.03.14 09:32, Benjamin SANS (b...@ziirish.info) wrote: > * On Monday, 24 March 2014 23:24, Lennart Poettering > wrote: > > > > No grokking what this is about really? What do you need the param for, > > why isn't the existing agent logic good enough for this? Do you need > > some identifier to pass across, or what is supposed to be included > > there? > > > > The goal here is to be able to reuse "handlers" that have been developed for > Debian. > The original "keyscript" options comes from them and this implementation uses > the "key_file" field of the crypttab as an argument to the "keyscript". > This "key_file" does not have necessary to be a real "key_file". > > For instance, you could have something like that in your crypttab: > > crypt1 /dev/sda UUID=----,FILE=toto.key > luks,keyscript=/usr/bin/mykeyscript > crypt2 /dev/sdb > UUID=----,FILE=tata.key > luks,keyscript=/usr/bin/mykeyscript I really don't think keyscript and thus also some extensions to the password field is something I want to see in systemd-cryptsetup. We have a the password agent stuff and you can plug in there whatever you want. But I want programs to be able to make sense of /etc/crypttab, and they really shouldnt become programs of their own or something that cannot be understood anymore without knowing what the "keyscript" is doing. Really, this is a bad idea... 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] timedated: add --timezone option to set the default timezone
On Tue, 25.03.14 11:54, juho son (juho80@samsung.com) wrote: > > On 03/25/2014 04:47 AM, Lennart Poettering wrote: > >On Tue, 18.03.14 02:34, Juho Son (juho80@samsung.com) wrote: > > > >>This option could changes the default system's time zone. > >>The default time zone is /etc/localtime. If we want to use > >>the specific path, we could use this option. > >I agree with the others on this thread, this really looks like nothing > >we should support upstream. /etc is the place for configuration. If you > >decide to mount it read-only (which is absolutely valid), then > >configuration is ready-only, and that's the exactly the effect that > >mounting /etc read-only should have, so playing games with redirecting > >this sounds misleading. > > > >Lennart > > > Yeah if we decide to use the /etc to read-only, we should use like that. > but we could modify some configurations > like group, passwd, smack, mtab and localtime in runtime. > So we use links for that in read-only. > You already knew the systemd's configurations are in /etc/systemd. > It is very valid that /etc is read-only for protecting it. > So system configuration with link and read-only could give satisfaction for > protecting and supporting legacy module needed modification in runtime. > So I want to say I think that (link with read-only) is useful. > so put the "/etc with link and read-only" conversation beside. > > I want use the timedated in my system. > timedated only use "/etc/localtime" for system' timezone. > So I should modify timedated source code for my system. > That's why I suggest the option to configure. > Someone to use like me need that option or configuration. > Some system use TZ environment variable for specifying. > and if the TZ does not have value, > default timezone is /etc/localtime or /usr/local/etc/localtime. > In GNU C library, that depends on configuration in installation. > First time, I considered the build configuration like > "--with-timezone-path=". > but I think the option submitted is better after I see the rootdir > option in other. > So please consider it with flexible perspective for alternative system. I am not convinced this is something we should support upstream (this shouldn't stop you from changing this downstream though...). But I think there's no point in introducing multiple levels of /etc and advocating this from upstream... 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] [PATCH 2/2] Fix keysize handling in cryptsetup (bits vs. bytes)
On Tue, 25.03.14 11:05, David Härdeman (da...@hardeman.nu) wrote:
> The command line key-size is in bits but the libcryptsetup API expects bytes.
>
> Note that the modulo 8 check is in the original cryptsetup binary as well, so
> it's no new limitation.
>
> (v2: changed the point at which the /= 8 is performed, rebased,
> removed tabs)
Applied both! Thanks!
> ---
> src/cryptsetup/cryptsetup.c | 11 +--
> 1 file changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
> index a647a94..812b32f 100644
> --- a/src/cryptsetup/cryptsetup.c
> +++ b/src/cryptsetup/cryptsetup.c
> @@ -88,6 +88,13 @@ static int parse_one_option(const char *option) {
> return 0;
> }
>
> +if (arg_key_size % 8) {
> +log_error("size= not a multiple of 8, ignoring.");
> +return 0;
> +}
> +
> +arg_key_size /= 8;
> +
> } else if (startswith(option, "key-slot=")) {
>
> arg_type = CRYPT_LUKS1;
> @@ -414,7 +421,7 @@ static int attach_luks_or_plain(struct crypt_device *cd,
> /* for CRYPT_PLAIN limit reads
> * from keyfile to key length, and
> * ignore keyfile-size */
> -arg_keyfile_size = arg_key_size / 8;
> +arg_keyfile_size = arg_key_size;
>
> /* In contrast to what the name
> * crypt_setup() might suggest this
> @@ -577,7 +584,7 @@ int main(int argc, char *argv[]) {
> else
> until = 0;
>
> -arg_key_size = (arg_key_size > 0 ? arg_key_size : 256);
> +arg_key_size = (arg_key_size > 0 ? arg_key_size : (256 / 8));
>
> if (key_file) {
> struct stat st;
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] test-resolve.c: Cleanup and make use of sockaddr_pretty()
On Wed, 26.03.14 14:17, Daniel Buch (boogiewasth...@gmail.com) wrote:
Applied! Thanks!
> ---
> src/libsystemd/sd-resolve/test-resolve.c | 48
> +++-
> 1 file changed, 22 insertions(+), 26 deletions(-)
>
> diff --git a/src/libsystemd/sd-resolve/test-resolve.c
> b/src/libsystemd/sd-resolve/test-resolve.c
> index d3b2d55..6334dad 100644
> --- a/src/libsystemd/sd-resolve/test-resolve.c
> +++ b/src/libsystemd/sd-resolve/test-resolve.c
> @@ -4,6 +4,7 @@
>This file is part of systemd.
>
>Copyright 2005-2008 Lennart Poettering
> + Copyright 2014 Daniel Buch
>
>systemd is free software; you can redistribute it and/or modify it
>under the terms of the GNU Lesser General Public License as published by
> @@ -31,36 +32,39 @@
> #include
> #include
>
> +#include "socket-util.h"
> #include "sd-resolve.h"
> #include "resolve-util.h"
> #include "macro.h"
>
> int main(int argc, char *argv[]) {
> -int r = 1;
> +int r = 0;
> _cleanup_resolve_unref_ sd_resolve *resolve = NULL;
> _cleanup_resolve_addrinfo_free_ struct addrinfo *ai = NULL;
> _cleanup_free_ unsigned char *srv = NULL;
> -sd_resolve_query *q1 = NULL, *q2 = NULL, *q3 = NULL;
> -struct addrinfo hints = {};
> -struct sockaddr_in sa = {};
> _cleanup_free_ char *host = NULL, *serv = NULL;
> +sd_resolve_query *q1 = NULL, *q2 = NULL, *q3 = NULL;
> +
> +struct addrinfo hints = {
> +.ai_family = PF_UNSPEC,
> +.ai_socktype = SOCK_STREAM,
> +.ai_flags = AI_CANONNAME
> +};
> +
> +struct sockaddr_in sa = {
> +.sin_family = AF_INET,
> +.sin_port = htons(80)
> +};
>
> assert_se(sd_resolve_new(&resolve) >= 0);
>
> /* Make a name -> address query */
> -hints.ai_family = PF_UNSPEC;
> -hints.ai_socktype = SOCK_STREAM;
> -hints.ai_flags = AI_CANONNAME;
> -
> r = sd_resolve_getaddrinfo(resolve, &q1, argc >= 2 ? argv[1] :
> "www.heise.de", NULL, &hints);
> if (r < 0)
> log_error("sd_resolve_getaddrinfo(): %s\n", strerror(-r));
>
> /* Make an address -> name query */
> -sa.sin_family = AF_INET;
> -sa.sin_addr.s_addr = inet_addr(argc >= 3 ? argv[2] :
> "193.99.144.71");
> -sa.sin_port = htons(80);
> -
> +sa.sin_addr.s_addr = inet_addr(argc >= 3 ? argv[2] :
> "193.99.144.71"),
> r = sd_resolve_getnameinfo(resolve, &q2, (struct sockaddr*) &sa,
> sizeof(sa), 0, true, true);
> if (r < 0)
> log_error("sd_resolve_getnameinfo(): %s\n", strerror(-r));
> @@ -90,15 +94,11 @@ int main(int argc, char *argv[]) {
> struct addrinfo *i;
>
> for (i = ai; i; i = i->ai_next) {
> -char t[256];
> -const char *p = NULL;
> +_cleanup_free_ char *addr = NULL;
>
> -if (i->ai_family == PF_INET)
> -p = inet_ntop(AF_INET, &((struct
> sockaddr_in*) i->ai_addr)->sin_addr, t, sizeof(t));
> -else if (i->ai_family == PF_INET6)
> -p = inet_ntop(AF_INET6, &((struct
> sockaddr_in6*) i->ai_addr)->sin6_addr, t, sizeof(t));
> +assert_se(sockaddr_pretty(i->ai_addr, i->ai_addrlen,
> false, &addr) == 0);
>
> -printf("%s\n", p);
> +puts(addr);
> }
>
> printf("canonical name: %s\n", strna(ai->ai_canonname));
> @@ -109,7 +109,7 @@ int main(int argc, char *argv[]) {
> if (r)
> log_error("error: %s %i\n", gai_strerror(r), r);
> else
> -printf("%s -- %s\n", host, serv);
> +printf("Host: %s -- Serv: %s\n", host, serv);
>
> /* Interpret the result of the SRV lookup */
> r = sd_resolve_res_done(q3, &srv);
> @@ -118,9 +118,7 @@ int main(int argc, char *argv[]) {
> else if (r == 0)
> log_error("No reply for SRV lookup\n");
> else {
> -int qdcount;
> -int ancount;
> -int len;
> +int qdcount, ancount, len;
> const unsigned char *pos = srv + sizeof(HEADER);
> unsigned char *end = srv + r;
> HEADER *head = (HEADER *)srv;
> @@ -157,7 +155,5 @@ int main(int argc, char *argv[]) {
> }
> }
>
> -r = 0;
> -
> -return r;
> +return 0;
> }
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2 2/2] service: rename StartLimitAction enum to FailureAction
It's used for the FailureAction property as well.
---
Changes since v1:
- rebased on latest master
- also rename things in src/test/test-tables.c
src/core/dbus-service.c | 6 +++---
src/core/load-fragment-gperf.gperf.m4 | 4 ++--
src/core/load-fragment.c | 4 ++--
src/core/load-fragment.h | 2 +-
src/core/service.c| 32
src/core/service.h| 24
src/test/test-tables.c| 2 +-
7 files changed, 37 insertions(+), 37 deletions(-)
diff --git a/src/core/dbus-service.c b/src/core/dbus-service.c
index 2f9c25a..093289f 100644
--- a/src/core/dbus-service.c
+++ b/src/core/dbus-service.c
@@ -34,7 +34,7 @@ static BUS_DEFINE_PROPERTY_GET_ENUM(property_get_type,
service_type, ServiceType
static BUS_DEFINE_PROPERTY_GET_ENUM(property_get_result, service_result,
ServiceResult);
static BUS_DEFINE_PROPERTY_GET_ENUM(property_get_restart, service_restart,
ServiceRestart);
static BUS_DEFINE_PROPERTY_GET_ENUM(property_get_notify_access, notify_access,
NotifyAccess);
-static BUS_DEFINE_PROPERTY_GET_ENUM(property_get_start_limit_action,
start_limit_action, StartLimitAction);
+static BUS_DEFINE_PROPERTY_GET_ENUM(property_get_failure_action,
failure_action, FailureAction);
const sd_bus_vtable bus_service_vtable[] = {
SD_BUS_VTABLE_START(0),
@@ -49,9 +49,9 @@ const sd_bus_vtable bus_service_vtable[] = {
BUS_PROPERTY_DUAL_TIMESTAMP("WatchdogTimestamp", offsetof(Service,
watchdog_timestamp), 0),
SD_BUS_PROPERTY("StartLimitInterval", "t", bus_property_get_usec,
offsetof(Service, start_limit.interval), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY("StartLimitBurst", "u", bus_property_get_unsigned,
offsetof(Service, start_limit.burst), SD_BUS_VTABLE_PROPERTY_CONST),
-SD_BUS_PROPERTY("StartLimitAction", "s",
property_get_start_limit_action, offsetof(Service, start_limit_action),
SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY("StartLimitAction", "s", property_get_failure_action,
offsetof(Service, start_limit_action), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY("RebootArgument", "s", NULL, offsetof(Service,
reboot_arg), SD_BUS_VTABLE_PROPERTY_CONST),
-SD_BUS_PROPERTY("FailureAction", "s", property_get_start_limit_action,
offsetof(Service, failure_action), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY("FailureAction", "s", property_get_failure_action,
offsetof(Service, failure_action), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY("PermissionsStartOnly", "b", bus_property_get_bool,
offsetof(Service, permissions_start_only), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY("RootDirectoryStartOnly", "b", bus_property_get_bool,
offsetof(Service, root_directory_start_only), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY("RemainAfterExit", "b", bus_property_get_bool,
offsetof(Service, remain_after_exit), SD_BUS_VTABLE_PROPERTY_CONST),
diff --git a/src/core/load-fragment-gperf.gperf.m4
b/src/core/load-fragment-gperf.gperf.m4
index da6df5c..b8d8738 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -179,9 +179,9 @@ Service.TimeoutStopSec,
config_parse_service_timeout, 0,
Service.WatchdogSec, config_parse_sec, 0,
offsetof(Service, watchdog_usec)
Service.StartLimitInterval, config_parse_sec, 0,
offsetof(Service, start_limit.interval)
Service.StartLimitBurst, config_parse_unsigned, 0,
offsetof(Service, start_limit.burst)
-Service.StartLimitAction,config_parse_start_limit_action,0,
offsetof(Service, start_limit_action)
+Service.StartLimitAction,config_parse_failure_action,0,
offsetof(Service, start_limit_action)
Service.RebootArgument, config_parse_string,0,
offsetof(Service, reboot_arg)
-Service.FailureAction, config_parse_start_limit_action,0,
offsetof(Service, failure_action)
+Service.FailureAction, config_parse_failure_action,0,
offsetof(Service, failure_action)
Service.Type,config_parse_service_type, 0,
offsetof(Service, type)
Service.Restart, config_parse_service_restart, 0,
offsetof(Service, restart)
Service.PermissionsStartOnly,config_parse_bool, 0,
offsetof(Service, permissions_start_only)
diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c
index c604f90..6c92935 100644
--- a/src/core/load-fragment.c
+++ b/src/core/load-fragment.c
@@ -2
[systemd-devel] [PATCH v2 1/2] service: add FailureAction= option
It has the same possible values as StartLimitAction= and is executed
immediately if a service fails.
---
Changes since v1:
- rebased on latest master
man/systemd.service.xml | 11 ++
src/core/dbus-service.c | 1 +
src/core/load-fragment-gperf.gperf.m4 | 1 +
src/core/service.c| 39 ++-
src/core/service.h| 2 ++
5 files changed, 40 insertions(+), 14 deletions(-)
diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index a2a1b6b..af32ccb 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -1030,6 +1030,17 @@ ExecStart=/bin/echo $ONE $TWO ${TWO}
command.
+
+FailureAction=
+Configure the action
+to take when the service enters a failed
+state. Takes the same values as
+StartLimitAction=
+and executes the same actions.
+Defaults to none.
+
+
+
Check
diff --git a/src/core/dbus-service.c b/src/core/dbus-service.c
index 45bfecf..2f9c25a 100644
--- a/src/core/dbus-service.c
+++ b/src/core/dbus-service.c
@@ -51,6 +51,7 @@ const sd_bus_vtable bus_service_vtable[] = {
SD_BUS_PROPERTY("StartLimitBurst", "u", bus_property_get_unsigned,
offsetof(Service, start_limit.burst), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY("StartLimitAction", "s",
property_get_start_limit_action, offsetof(Service, start_limit_action),
SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY("RebootArgument", "s", NULL, offsetof(Service,
reboot_arg), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY("FailureAction", "s", property_get_start_limit_action,
offsetof(Service, failure_action), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY("PermissionsStartOnly", "b", bus_property_get_bool,
offsetof(Service, permissions_start_only), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY("RootDirectoryStartOnly", "b", bus_property_get_bool,
offsetof(Service, root_directory_start_only), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY("RemainAfterExit", "b", bus_property_get_bool,
offsetof(Service, remain_after_exit), SD_BUS_VTABLE_PROPERTY_CONST),
diff --git a/src/core/load-fragment-gperf.gperf.m4
b/src/core/load-fragment-gperf.gperf.m4
index cb98c83..da6df5c 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -181,6 +181,7 @@ Service.StartLimitInterval, config_parse_sec,
0,
Service.StartLimitBurst, config_parse_unsigned, 0,
offsetof(Service, start_limit.burst)
Service.StartLimitAction,config_parse_start_limit_action,0,
offsetof(Service, start_limit_action)
Service.RebootArgument, config_parse_string,0,
offsetof(Service, reboot_arg)
+Service.FailureAction, config_parse_start_limit_action,0,
offsetof(Service, failure_action)
Service.Type,config_parse_service_type, 0,
offsetof(Service, type)
Service.Restart, config_parse_service_restart, 0,
offsetof(Service, restart)
Service.PermissionsStartOnly,config_parse_bool, 0,
offsetof(Service, permissions_start_only)
diff --git a/src/core/service.c b/src/core/service.c
index 4ebce6a..593237a 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -1840,6 +1840,8 @@ static int cgroup_good(Service *s) {
return !r;
}
+static int service_execute_action(Service *s, StartLimitAction action, const
char *reason, bool log_action_none);
+
static void service_enter_dead(Service *s, ServiceResult f, bool
allow_restart) {
int r;
assert(s);
@@ -1849,6 +1851,9 @@ static void service_enter_dead(Service *s, ServiceResult
f, bool allow_restart)
service_set_state(s, s->result != SERVICE_SUCCESS ? SERVICE_FAILED :
SERVICE_DEAD);
+if (s->result != SERVICE_SUCCESS)
+service_execute_action(s, s->failure_action, "failed", false);
+
if (allow_restart &&
!s->forbid_restart &&
(s->restart == SERVICE_RESTART_ALWAYS ||
@@ -2371,22 +2376,19 @@ fail:
service_enter_stop(s, SERVICE_FAILURE_RESOURCES);
}
-static int service_start_limit_test(Service *s) {
+static int service_execute_action(Service *s, StartLimitAction action, const
char *reason, bool log_action_none) {
assert(s);
-if (ratelimit_test(&s->sta
Re: [systemd-devel] [SOLVED] mount failed during system start but after "systemctl daemon-reload" everything works
Found the solution: lists.freedesktop.org/archives/systemd-devel/2014-February/017362.html Maybe the dependency of udev for CONFIG_FHANDLE in kernel should be listed somewhere in the source tarball? Oliver Am 22.04.2014 18:49, schrieb Oliver: Am 22.04.2014 07:04, schrieb Lennart Poettering: On Fri, 18.04.14 10:32, Oliver (oli...@business-security.de) wrote: Hello. Could anyone tell me a reason why a mount (regardless of via fstab or "mountpoint.mount" unit file) during system boot leads to a timeout because of device timeout and after i do a "systemctl daemon-reload" the mount is successful? Detailed information: My system is a Linuxfromscratch 7.5 (so no "real" distribution - everything is self-compiled) and it runs as a paravirtualized Xen DomU. Therefore the block devices are /dev/xvda1 and /dev/xvdb1. The first is the root fs and mount and remount are okay. Then the second block device should mount and it timed out with "Dependency failed" and "dev-xvdb1.device/start timed out" When I run "udevadm info /dev/xvdb1" everything seems to be okay, but any try of mount this via systemd failes. When I mount manually via "mount /dev/xvdb1 /mountpoint" it's fine. Then "systemctl status mountpoint.mount" says "active". Manually unmount is okay and after this a mount via systemd failes again. If I do, and only if I do "systemctl daemon-reload" and then "systemctl start mountpoint.mount" it works. I'm a beginner with a systemd based system and do not know much about the internals. What could lead to this behaviour? Is it possible that I do anything wrong? Please help. I'm very frustrated. If you need more Input, please tell me. systemd's .device units rely on the "systemd" tag to be on the udev device, as well as DEVICE_READY=1 being absent of it. I have no idea how xen sets up block device nodes, but what is essential that this used to inform systemd when the devices are ready to be mounted. Lennart This is the output of "udevadm info /dev/xvdb1": P: /devices/vbd-51729/block/xvdb1 N: xvdb1 S: disk/by-uuid/d2b62043-e504-4005-b1f4-212e87360284 E: DEVLINKS=/dev/disk/by-uuid/d2b62043-e504-4005-b1f4-212e87360284 E: DEVNAME=/dev/xvdb1 E: DEVPATH=/devices/vbd-51729/block/xvdb1 E: DEVTYPE=disk E: ID_FS_TYPE=ext4 E: ID_FS_USAGE=filesystem E: ID_FS_UUID=d2b62043-e504-4005-b1f4-212e87360284 E: ID_FS_UUID_ENC=d2b62043-e504-4005-b1f4-212e87360284 E: ID_FS_VERSION=1.0 E: MAJOR=202 E: MINOR=17 E: SUBSYSTEM=block E: TAGS=:systemd: E: USEC_INITIALIZED=70616 Doesn't this mean, that the device is ready for a mount? Here one can see the difference before and after "systemctl daemon-reload": domU [ ~ ]# systemctl status dev-xvdb1.device * dev-xvdb1.device Loaded: loaded Active: inactive (dead) domU [ ~ ]# systemctl status dev-hvc0.device * dev-hvc0.device Loaded: loaded Active: inactive (dead) domU [ ~ ]# systemctl daemon-reload domU [ ~ ]# systemctl status dev-xvdb1.device * dev-xvdb1.device - /dev/xvdb1 Follow: unit currently follows state of sys-devices-vbd\x2d51729-block-xvdb1.device Loaded: loaded Active: active (plugged) Device: /sys/devices/vbd-51729/block/xvdb1 domU [ ~ ]# systemctl status dev-hvc0.device * dev-hvc0.device - /dev/hvc0 Follow: unit currently follows state of sys-devices-virtual-tty-hvc0.device Loaded: loaded Active: active (plugged) Device: /sys/devices/virtual/tty/hvc0 I added the device /dev/hvc0 (console inside Xen domU) because it's the same behaviour. What's going on at "systemctl daemon-reload"? I thought it only looks for new updates in "/etc/systemd/system" "/var/run/systemd/system" and "[/usr]/lib/systemd/system". What I realized was, that it updates files in /var/run/systemd/generator/ But everything there is the same. Any ideas? Best regard Oliver ___ 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] [SOLVED] mount failed during system start but after "systemctl daemon-reload" everything works
Sorry ... my fault. Grepped for "fhandle" so do not found "FHANDLE" in README ;-) Documentation is fine. Best regards Oliver Am 24.04.2014 10:13, schrieb Oliver: Found the solution: lists.freedesktop.org/archives/systemd-devel/2014-February/017362.html Maybe the dependency of udev for CONFIG_FHANDLE in kernel should be listed somewhere in the source tarball? Oliver Am 22.04.2014 18:49, schrieb Oliver: Am 22.04.2014 07:04, schrieb Lennart Poettering: On Fri, 18.04.14 10:32, Oliver (oli...@business-security.de) wrote: Hello. Could anyone tell me a reason why a mount (regardless of via fstab or "mountpoint.mount" unit file) during system boot leads to a timeout because of device timeout and after i do a "systemctl daemon-reload" the mount is successful? Detailed information: My system is a Linuxfromscratch 7.5 (so no "real" distribution - everything is self-compiled) and it runs as a paravirtualized Xen DomU. Therefore the block devices are /dev/xvda1 and /dev/xvdb1. The first is the root fs and mount and remount are okay. Then the second block device should mount and it timed out with "Dependency failed" and "dev-xvdb1.device/start timed out" When I run "udevadm info /dev/xvdb1" everything seems to be okay, but any try of mount this via systemd failes. When I mount manually via "mount /dev/xvdb1 /mountpoint" it's fine. Then "systemctl status mountpoint.mount" says "active". Manually unmount is okay and after this a mount via systemd failes again. If I do, and only if I do "systemctl daemon-reload" and then "systemctl start mountpoint.mount" it works. I'm a beginner with a systemd based system and do not know much about the internals. What could lead to this behaviour? Is it possible that I do anything wrong? Please help. I'm very frustrated. If you need more Input, please tell me. systemd's .device units rely on the "systemd" tag to be on the udev device, as well as DEVICE_READY=1 being absent of it. I have no idea how xen sets up block device nodes, but what is essential that this used to inform systemd when the devices are ready to be mounted. Lennart This is the output of "udevadm info /dev/xvdb1": P: /devices/vbd-51729/block/xvdb1 N: xvdb1 S: disk/by-uuid/d2b62043-e504-4005-b1f4-212e87360284 E: DEVLINKS=/dev/disk/by-uuid/d2b62043-e504-4005-b1f4-212e87360284 E: DEVNAME=/dev/xvdb1 E: DEVPATH=/devices/vbd-51729/block/xvdb1 E: DEVTYPE=disk E: ID_FS_TYPE=ext4 E: ID_FS_USAGE=filesystem E: ID_FS_UUID=d2b62043-e504-4005-b1f4-212e87360284 E: ID_FS_UUID_ENC=d2b62043-e504-4005-b1f4-212e87360284 E: ID_FS_VERSION=1.0 E: MAJOR=202 E: MINOR=17 E: SUBSYSTEM=block E: TAGS=:systemd: E: USEC_INITIALIZED=70616 Doesn't this mean, that the device is ready for a mount? Here one can see the difference before and after "systemctl daemon-reload": domU [ ~ ]# systemctl status dev-xvdb1.device * dev-xvdb1.device Loaded: loaded Active: inactive (dead) domU [ ~ ]# systemctl status dev-hvc0.device * dev-hvc0.device Loaded: loaded Active: inactive (dead) domU [ ~ ]# systemctl daemon-reload domU [ ~ ]# systemctl status dev-xvdb1.device * dev-xvdb1.device - /dev/xvdb1 Follow: unit currently follows state of sys-devices-vbd\x2d51729-block-xvdb1.device Loaded: loaded Active: active (plugged) Device: /sys/devices/vbd-51729/block/xvdb1 domU [ ~ ]# systemctl status dev-hvc0.device * dev-hvc0.device - /dev/hvc0 Follow: unit currently follows state of sys-devices-virtual-tty-hvc0.device Loaded: loaded Active: active (plugged) Device: /sys/devices/virtual/tty/hvc0 I added the device /dev/hvc0 (console inside Xen domU) because it's the same behaviour. What's going on at "systemctl daemon-reload"? I thought it only looks for new updates in "/etc/systemd/system" "/var/run/systemd/system" and "[/usr]/lib/systemd/system". What I realized was, that it updates files in /var/run/systemd/generator/ But everything there is the same. Any ideas? Best regard Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] libudev: replace name_to_handle_at with normal sscanf
On Thu, Apr 24, 2014 at 7:35 AM, Lennart Poettering wrote: > On Thu, 24.04.14 07:28, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: >> > Have you checked that EOPNOTSUPP is really the error that is returned by >> > name_to_handle_at() if the kernel has the entire syscall disabled? Note >> > that there are two different cases to distuingish here: a file system >> > not supporting the operation, and the kernel not supporting the >> > syscal... >> It's warning on everything except EOPNOTSUPP. My reasoning is: >> >> EOPNOTSUPP -> syscall supported, but wrong fs type, -> return false >> ENOSYS -> syscall not supported -> warn and return false >> any other error -> memory error or other major screw-up -> warn and return >> false > > Looks good to me then, Kay? Sure, looks all fine. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Start-up resource and prioritization control
Hi, We are starting many services between basic.target - multi-user.target at the same time and due to this we are suffering from following two subjects. What can we do to overcome these problems? 1) We would like to start a subset of services that are scheduled to start between basic.target - multi-user.target before the rest and there is no built in way to satisfy our needs. a) We could use Before=, After= on services but the downside of this kind of dependency is we have to edit every single service file with Before=, After= directive. This is not the best option when the subset of services we would like to start early might change between hardware or product configuration. b) The ongoing patch http://lists.freedesktop.org/archives/systemd-devel/2014-March/018220.html is promising but it seems to be stopped. Any reason? c) A service running before basic.target and queriying systemd with "systemctl show -p [Wants Requires] default.target" and adding Before=, After= dependency on services on runtime. Doesn't seem so efficient. 2) Due to starting too many services and due to having frequent context switches (flushing of caches), we see that boot time is longer than booting services sequentially. a) Proposing a configuration to limit the number of jobs that are in "activating" state. b) "nice" value of the services can be changed to prioritize things randomly but then we have to revert back the nice value once the boot is completed. Doesn't seem so easy. We are aware that our problem is mostly embedded platform specific. We could solve our problem staticly with what systemd offers but a static solution that is customized for one hardware is not the best solution for another hardware. Having static solutions per hardware is extremely hard to maintain and we would like to solve this problem upstream instead of downstream magic. Thanks, Umut ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevd-work: ressize 1024 too short
On Tue, Mar 25, 2014 at 1:36 PM, Robert Milasan wrote:
> Hello, seems that under some conditions in udev_rules_apply_to_event
> (@TK_M_PROGRAM) the fact that result is 1024 bytes creates problems if
> the output of the running command/app is bigger then 1024 bytes.
> +++ b/src/udev/udev-rules.c
> @@ -2027,7 +2027,7 @@ int udev_rules_apply_to_event(struct udev_rules
> *rules, struct udev_event *event case TK_M_PROGRAM: {
> char program[UTIL_PATH_SIZE];
> char **envp;
> -char result[UTIL_PATH_SIZE];
> +char result[UTIL_LINE_SIZE];
Applied.
Thanks,
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Assigning a second ip-address on interface (i.e. eth0 and eth0:1)
Is this possible via *.link *.network in /etc/systemd/network? Currently I use a custom service file but using native configuration would be much smarter. Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Assigning a second ip-address on interface (i.e. eth0 and eth0:1)
Hi Oliver, You can specify Address= more than once as it is explained in http://www.freedesktop.org/software/systemd/man/systemd.network.html (Address=). Thanks. On Thu, Apr 24, 2014 at 11:46 AM, Oliver wrote: > > Is this possible via *.link *.network in /etc/systemd/network? > Currently I use a custom service file but using native configuration would > be much smarter. > > Oliver > ___ > 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] Unable to override systemd-udevd.service
[Resend to mailing list, because my client somehow swallowed half the Cc fields
- sorry about that.]
Hi!
I encountered the same issue, running version 195-13.45.1 from opensuse in a
container:
On 23.04.2014, at 19:26, Andrey Borzenkov (by way of Andrey Borzenkov
) wrote:
> В Wed, 23 Apr 2014 06:43:04 +0200
> Lennart Poettering пишет:
>
>> On Sun, 30.03.14 19:23, Andrey Borzenkov (arvidj...@gmail.com) wrote:
>>
>>> linux-qbc6:~ # systemctl show systemd-udevd.service -p FragmentPath
>>> FragmentPath=/usr/lib/systemd/system/systemd-udevd.service
>>> linux-qbc6:~ # cp /usr/lib/systemd/system/systemd-udevd.service
>>> /etc/systemd/system
>>> linux-qbc6:~ # systemctl daemon-reload
>>> linux-qbc6:~ # cp /usr/lib/systemd/system/systemd-udevd.service
>>> /etc/systemd/system
>>> linux-qbc6:~ # systemctl show systemd-udevd.service -p FragmentPath
>>> FragmentPath=/usr/lib/systemd/system/systemd-udevd.service
>>> linux-qbc6:~ # exit
>>>
From non-exhaustive testing it appears to be the only unit showing this
>>> property. Enabling systemd debug does not add any useful information
>>> (no output about unit discovery). Any way to debug it?
>>>
>>> The version is systemd-208-19.1.x86_64 from openSUSE.
>>
>> Hmm, that's weird. Is /etc on some weird mount point or so?
>>
>
> Not really. Just plain disk in QEMU VM.
>
> 17 21 0:5 / /dev rw,relatime shared:2 - devtmpfs devtmpfs
> rw,size=380164k,nr_inodes=95041,mode=755
> 18 17 0:15 / /dev/shm rw,relatime shared:3 - tmpfs tmpfs rw
> 19 21 0:16 / /run rw,nosuid,nodev,relatime shared:6 - tmpfs tmpfs rw,mode=755
> 20 17 0:11 / /dev/pts rw,relatime shared:4 - devpts devpts
> rw,gid=5,mode=620,ptmxmode=000
> 21 1 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 rw,data=ordered
> ... etc
>
Similar situation here.
>> It might be interesting to run "strace -o log -e open -p 1" and then trigger
>> a
>> reload, and then look at the generate log file "log". It should show you
>> where systemd is looking for the udev service file, and might contain a
>> hint, why it skips the file in /etc?
>>
>
> Actually, it does not :)
>
> 1 open("/usr/lib/systemd/system/systemd-udevd.service",
> O_RDONLY|O_NOCTTY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC) = 17
> 1 open("/usr/lib/systemd/system/systemd-udevd-kernel.socket",
> O_RDONLY|O_NOCTTY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC) = 17
> 1 open("/usr/lib/systemd/system/systemd-udevd-control.socket",
> O_RDONLY|O_NOCTTY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC) = 17
> 1 open("/etc/systemd/system/systemd-udevd.service",
> O_RDONLY|O_NOCTTY|O_LARGEFILE|O_CLOEXEC) = 18
> 1 openat(AT_FDCWD, "/etc/systemd/system/systemd-udevd.service.d",
> O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such
> file or directory)
> 1 openat(AT_FDCWD, "/run/systemd/system/systemd-udevd.service.d",
> O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such
> file or directory)
> 1 openat(AT_FDCWD, "/run/systemd/generator/systemd-udevd.service.d",
> O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such
> file or directory)
> 1 openat(AT_FDCWD,
> "/usr/local/lib/systemd/system/systemd-udevd.service.d",
> O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such
> file or directory)
> 1 openat(AT_FDCWD, "/usr/lib/systemd/system/systemd-udevd.service.d",
> O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such
> file or directory)
> 1 openat(AT_FDCWD, "/lib/systemd/system/systemd-udevd.service.d",
> O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such
> file or directory)
>
Systemd does not even try to open the override in /etc here either. However, I
noticed an error with /usr/lib/systemd/system/udev.service:
open("/usr/lib/systemd/system/udev.service",
O_RDONLY|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC) = -1 ELOOP (Too many levels of symbolic
links)
open("/usr/lib/systemd/system/systemd-udevd.service",
O_RDONLY|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC) = 15
Interestingly, removing /usr/lib/systemd/system/udev.service (which is just a
symlink to systemd-udevd.service) makes the override work:
open("/etc/systemd/system/systemd-udevd.service",
O_RDONLY|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC) = 15
Could it be that this symlink somehow causes systemd to ignore the override?
Andrey, do you have similar behavior with /usr/lib/systemd/system/udev.service?
Thanks,
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Assigning a second ip-address on interface (i.e. eth0 and eth0:1)
On Thu, Apr 24, 2014 at 1:06 PM, Umut Tezduyar Lindskog wrote: > Hi Oliver, > > You can specify Address= more than once as it is explained in > http://www.freedesktop.org/software/systemd/man/systemd.network.html > (Address=). And just for the record, use `ip addr` to make sure it works, because chances are that `ifconfig` won't show it. Since kernel 2.2, there can be several IP addresses on the same eth0 interface without having to use 'aliases', using `ip addr add` for example. networkd uses the new method as well. Unfortunately, `ifconfig` – even the last version that Arch has – only shows the first address to this day. -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Assigning a second ip-address on interface (i.e. eth0 and eth0:1)
On Thu, Apr 24, 2014 at 12:30 PM, Mantas Mikulėnas wrote: > On Thu, Apr 24, 2014 at 1:06 PM, Umut Tezduyar Lindskog > wrote: >> Hi Oliver, >> >> You can specify Address= more than once as it is explained in >> http://www.freedesktop.org/software/systemd/man/systemd.network.html >> (Address=). > > And just for the record, use `ip addr` to make sure it works, because > chances are that `ifconfig` won't show it. > > Since kernel 2.2, there can be several IP addresses on the same eth0 > interface without having to use 'aliases', using `ip addr add` for > example. networkd uses the new method as well. Unfortunately, > `ifconfig` – even the last version that Arch has – only shows the > first address to this day. PSA: never, ever, use ifconfig or friends. It has been dead upstream since sometime in the last millenium and is known to give you misleading or just wrong information. I thought we had dropped it from Arch to be honest... Maybe time to look at that... Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journal entries for most recent pid?
On Thu, Apr 24, 2014 at 08:59:46AM +0200, Lennart Poettering wrote: > On Tue, 25.03.14 15:59, Peter Hutterer (peter.hutte...@who-t.net) wrote: > > > I can't seem to find this in the documentation, so I do wonder if it exists: > > is there an equivalent to journalctl -b -1 that lists the log of the most > > recent pid? > > > > Specifically I'd like to run journalctl /usr/bin/Xorg --pid -1 or similar to > > get users to attach the most recent log file instead of having to provide > > _PID manually. > > Hmm, I can see the usecase for that, but I am not sure how we could > implement this nicely... > > To implement this we'd have to store the starttime of each PID in the > database, and then order by that. And then we'd have to figure out the > most recent one, probably in a similar fashion as we already allow this > boot ids... > > I have added this now to the TODO list, but don't hold your breath... I've been thinking about this too, and actually for the same usecase (i.e. logs from X). I think we should teach various programs like X to logs an equivalent of _BOOT_ID (e.g. "XORG_RUN_ID"), and then systemctl could be extended to support it the same -b / --list-boots, except that the user would specify the tag (e.g. XORG_RUN_ID) to sort on. The advantage would be that e.g. Xorg and gdm could agree to use the same tag for the same session, thus making is easy to correlate log messages. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journal entries for most recent pid?
On Thu, 24.04.14 15:08, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > On Thu, Apr 24, 2014 at 08:59:46AM +0200, Lennart Poettering wrote: > > On Tue, 25.03.14 15:59, Peter Hutterer (peter.hutte...@who-t.net) wrote: > > > > > I can't seem to find this in the documentation, so I do wonder if it > > > exists: > > > is there an equivalent to journalctl -b -1 that lists the log of the most > > > recent pid? > > > > > > Specifically I'd like to run journalctl /usr/bin/Xorg --pid -1 or similar > > > to > > > get users to attach the most recent log file instead of having to provide > > > _PID manually. > > > > Hmm, I can see the usecase for that, but I am not sure how we could > > implement this nicely... > > > > To implement this we'd have to store the starttime of each PID in the > > database, and then order by that. And then we'd have to figure out the > > most recent one, probably in a similar fashion as we already allow this > > boot ids... > > > > I have added this now to the TODO list, but don't hold your breath... > I've been thinking about this too, and actually for the same usecase (i.e. > logs from X). I think we should teach various programs like X to logs an > equivalent of _BOOT_ID (e.g. "XORG_RUN_ID"), and then systemctl could be > extended to support it the same -b / --list-boots, except that the > user would specify the tag (e.g. XORG_RUN_ID) to sort on. The > advantage would be that e.g. Xorg and gdm could agree to use the same > tag for the same session, thus making is easy to correlate log > messages. Hmm, such an XORG_RUN_ID would be pretty close to _SYSTEMD_SESSION= then, no? 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] journal entries for most recent pid?
On Thu, Apr 24, 2014 at 04:15:43PM +0200, Lennart Poettering wrote: > On Thu, 24.04.14 15:08, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > > > On Thu, Apr 24, 2014 at 08:59:46AM +0200, Lennart Poettering wrote: > > > On Tue, 25.03.14 15:59, Peter Hutterer (peter.hutte...@who-t.net) wrote: > > > > > > > I can't seem to find this in the documentation, so I do wonder if it > > > > exists: > > > > is there an equivalent to journalctl -b -1 that lists the log of the > > > > most > > > > recent pid? > > > > > > > > Specifically I'd like to run journalctl /usr/bin/Xorg --pid -1 or > > > > similar to > > > > get users to attach the most recent log file instead of having to > > > > provide > > > > _PID manually. > > > > > > Hmm, I can see the usecase for that, but I am not sure how we could > > > implement this nicely... > > > > > > To implement this we'd have to store the starttime of each PID in the > > > database, and then order by that. And then we'd have to figure out the > > > most recent one, probably in a similar fashion as we already allow this > > > boot ids... > > > > > > I have added this now to the TODO list, but don't hold your breath... > > I've been thinking about this too, and actually for the same usecase (i.e. > > logs from X). I think we should teach various programs like X to logs an > > equivalent of _BOOT_ID (e.g. "XORG_RUN_ID"), and then systemctl could be > > extended to support it the same -b / --list-boots, except that the > > user would specify the tag (e.g. XORG_RUN_ID) to sort on. The > > advantage would be that e.g. Xorg and gdm could agree to use the same > > tag for the same session, thus making is easy to correlate log > > messages. > > Hmm, such an XORG_RUN_ID would be pretty close to _SYSTEMD_SESSION= > then, no? Yeah, but _SYSTEMD_SESSION repeats... It would be useful to have a randomized tag too. _SYSTEMD_SESSION_ID? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journal entries for most recent pid?
On Thu, 24.04.14 16:31, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > > I have added this now to the TODO list, but don't hold your breath... > > > I've been thinking about this too, and actually for the same usecase (i.e. > > > logs from X). I think we should teach various programs like X to logs an > > > equivalent of _BOOT_ID (e.g. "XORG_RUN_ID"), and then systemctl could be > > > extended to support it the same -b / --list-boots, except that the > > > user would specify the tag (e.g. XORG_RUN_ID) to sort on. The > > > advantage would be that e.g. Xorg and gdm could agree to use the same > > > tag for the same session, thus making is easy to correlate log > > > messages. > > > > Hmm, such an XORG_RUN_ID would be pretty close to _SYSTEMD_SESSION= > > then, no? > Yeah, but _SYSTEMD_SESSION repeats... It would be useful to have a randomized > tag too. _SYSTEMD_SESSION_ID? The idea was that it may be combined with the BOOT_ID and you'd then have a unique identifier... But the combination of the two fields would have to be client side... 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 v2 2/2] service: rename StartLimitAction enum to FailureAction
On Thu, 24.04.14 09:35, Michael Olbrich (m.olbr...@pengutronix.de) wrote:
Applied both! Thanks!
> It's used for the FailureAction property as well.
> ---
> Changes since v1:
> - rebased on latest master
> - also rename things in src/test/test-tables.c
>
> src/core/dbus-service.c | 6 +++---
> src/core/load-fragment-gperf.gperf.m4 | 4 ++--
> src/core/load-fragment.c | 4 ++--
> src/core/load-fragment.h | 2 +-
> src/core/service.c| 32
> src/core/service.h| 24
> src/test/test-tables.c| 2 +-
> 7 files changed, 37 insertions(+), 37 deletions(-)
>
> diff --git a/src/core/dbus-service.c b/src/core/dbus-service.c
> index 2f9c25a..093289f 100644
> --- a/src/core/dbus-service.c
> +++ b/src/core/dbus-service.c
> @@ -34,7 +34,7 @@ static BUS_DEFINE_PROPERTY_GET_ENUM(property_get_type,
> service_type, ServiceType
> static BUS_DEFINE_PROPERTY_GET_ENUM(property_get_result, service_result,
> ServiceResult);
> static BUS_DEFINE_PROPERTY_GET_ENUM(property_get_restart, service_restart,
> ServiceRestart);
> static BUS_DEFINE_PROPERTY_GET_ENUM(property_get_notify_access,
> notify_access, NotifyAccess);
> -static BUS_DEFINE_PROPERTY_GET_ENUM(property_get_start_limit_action,
> start_limit_action, StartLimitAction);
> +static BUS_DEFINE_PROPERTY_GET_ENUM(property_get_failure_action,
> failure_action, FailureAction);
>
> const sd_bus_vtable bus_service_vtable[] = {
> SD_BUS_VTABLE_START(0),
> @@ -49,9 +49,9 @@ const sd_bus_vtable bus_service_vtable[] = {
> BUS_PROPERTY_DUAL_TIMESTAMP("WatchdogTimestamp", offsetof(Service,
> watchdog_timestamp), 0),
> SD_BUS_PROPERTY("StartLimitInterval", "t", bus_property_get_usec,
> offsetof(Service, start_limit.interval), SD_BUS_VTABLE_PROPERTY_CONST),
> SD_BUS_PROPERTY("StartLimitBurst", "u", bus_property_get_unsigned,
> offsetof(Service, start_limit.burst), SD_BUS_VTABLE_PROPERTY_CONST),
> -SD_BUS_PROPERTY("StartLimitAction", "s",
> property_get_start_limit_action, offsetof(Service, start_limit_action),
> SD_BUS_VTABLE_PROPERTY_CONST),
> +SD_BUS_PROPERTY("StartLimitAction", "s",
> property_get_failure_action, offsetof(Service, start_limit_action),
> SD_BUS_VTABLE_PROPERTY_CONST),
> SD_BUS_PROPERTY("RebootArgument", "s", NULL, offsetof(Service,
> reboot_arg), SD_BUS_VTABLE_PROPERTY_CONST),
> -SD_BUS_PROPERTY("FailureAction", "s",
> property_get_start_limit_action, offsetof(Service, failure_action),
> SD_BUS_VTABLE_PROPERTY_CONST),
> +SD_BUS_PROPERTY("FailureAction", "s", property_get_failure_action,
> offsetof(Service, failure_action), SD_BUS_VTABLE_PROPERTY_CONST),
> SD_BUS_PROPERTY("PermissionsStartOnly", "b", bus_property_get_bool,
> offsetof(Service, permissions_start_only), SD_BUS_VTABLE_PROPERTY_CONST),
> SD_BUS_PROPERTY("RootDirectoryStartOnly", "b",
> bus_property_get_bool, offsetof(Service, root_directory_start_only),
> SD_BUS_VTABLE_PROPERTY_CONST),
> SD_BUS_PROPERTY("RemainAfterExit", "b", bus_property_get_bool,
> offsetof(Service, remain_after_exit), SD_BUS_VTABLE_PROPERTY_CONST),
> diff --git a/src/core/load-fragment-gperf.gperf.m4
> b/src/core/load-fragment-gperf.gperf.m4
> index da6df5c..b8d8738 100644
> --- a/src/core/load-fragment-gperf.gperf.m4
> +++ b/src/core/load-fragment-gperf.gperf.m4
> @@ -179,9 +179,9 @@ Service.TimeoutStopSec,
> config_parse_service_timeout, 0,
> Service.WatchdogSec, config_parse_sec, 0,
>offsetof(Service, watchdog_usec)
> Service.StartLimitInterval, config_parse_sec, 0,
>offsetof(Service, start_limit.interval)
> Service.StartLimitBurst, config_parse_unsigned, 0,
>offsetof(Service, start_limit.burst)
> -Service.StartLimitAction,config_parse_start_limit_action,0,
>offsetof(Service, start_limit_action)
> +Service.StartLimitAction,config_parse_failure_action,0,
>offsetof(Service, start_limit_action)
> Service.RebootArgument, config_parse_string,0,
>offsetof(Service, reboot_arg)
> -Service.FailureAction, config_parse_start_limit_action,0,
>offsetof(Service, failure_action)
> +Service.FailureAction, config_parse_failure_action,0,
>offsetof(Service, failure_action)
> Service.Type,config_parse_service_type, 0,
>offsetof(Service, type)
> Service.Restart, config_parse_service_restart, 0,
>offsetof(Service, restart)
> Service.PermissionsStartOn
[systemd-devel] [PATCH 1/2] bootchart: add control group option
---
man/bootchart.conf.xml | 5 +
man/systemd-bootchart.xml| 7 +++
src/bootchart/bootchart.c| 11 ++-
src/bootchart/bootchart.conf | 1 +
src/bootchart/bootchart.h| 2 ++
src/bootchart/store.c| 6 ++
src/bootchart/svg.c | 5 +++--
7 files changed, 34 insertions(+), 3 deletions(-)
diff --git a/man/bootchart.conf.xml b/man/bootchart.conf.xml
index 68d10d4..68834c7 100644
--- a/man/bootchart.conf.xml
+++ b/man/bootchart.conf.xml
@@ -145,6 +145,11 @@
graph components.
+
+ControlGroup=no
+Display process control
group.
+
+
diff --git a/man/systemd-bootchart.xml b/man/systemd-bootchart.xml
index 1715d5d..d83d032 100644
--- a/man/systemd-bootchart.xml
+++ b/man/systemd-bootchart.xml
@@ -198,6 +198,13 @@
+-g
+--control-group
+Display process control group
+
+
+
+
-o
--output
path
Specify the output directory
for the
diff --git a/src/bootchart/bootchart.c b/src/bootchart/bootchart.c
index 9f72d98..a73418a 100644
--- a/src/bootchart/bootchart.c
+++ b/src/bootchart/bootchart.c
@@ -78,6 +78,7 @@ bool initcall = true;
bool arg_relative = false;
bool arg_filter = true;
bool arg_show_cmdline = false;
+bool arg_show_cgroup = false;
bool arg_pss = false;
int samples;
int arg_samples_len = 500; /* we record len+1 (1 start sample) */
@@ -113,6 +114,7 @@ static void parse_conf(void) {
{ "Bootchart", "PlotEntropyGraph", config_parse_bool, 0,
&arg_entropy },
{ "Bootchart", "ScaleX", config_parse_double, 0,
&arg_scale_x },
{ "Bootchart", "ScaleY", config_parse_double, 0,
&arg_scale_y },
+{ "Bootchart", "ControlGroup", config_parse_bool, 0,
&arg_show_cgroup },
{ NULL, NULL, NULL, 0, NULL }
};
_cleanup_fclose_ FILE *f;
@@ -143,6 +145,7 @@ static int parse_args(int argc, char *argv[]) {
{"init", required_argument, NULL, 'i'},
{"no-filter", no_argument,NULL, 'F'},
{"cmdline", no_argument,NULL, 'C'},
+{"control-group", no_argument,NULL, 'c'},
{"help", no_argument,NULL, 'h'},
{"scale-x", required_argument, NULL, 'x'},
{"scale-y", required_argument, NULL, 'y'},
@@ -151,7 +154,7 @@ static int parse_args(int argc, char *argv[]) {
};
int c;
-while ((c = getopt_long(argc, argv, "erpf:n:o:i:FChx:y:", options,
NULL)) >= 0) {
+while ((c = getopt_long(argc, argv, "erpf:n:o:i:FCchx:y:", options,
NULL)) >= 0) {
int r;
switch (c) {
@@ -170,6 +173,9 @@ static int parse_args(int argc, char *argv[]) {
case 'C':
arg_show_cmdline = true;
break;
+case 'c':
+arg_show_cgroup = true;
+break;
case 'n':
r = safe_atoi(optarg, &arg_samples_len);
if (r < 0)
@@ -217,6 +223,7 @@ static int parse_args(int argc, char *argv[]) {
fprintf(stderr, " that are of
less importance or short-lived\n");
fprintf(stderr, " --cmdline, -C Display the
full command line with arguments\n");
fprintf(stderr, " of
processes, instead of only the process name\n");
+fprintf(stderr, " --control-group, -c Display
process control group\n");
fprintf(stderr, " --help, -h Display
this message\n");
fprintf(stderr, "See bootchart.conf for more
information.\n");
exit (EXIT_SUCCESS);
@@ -458,9 +465,11 @@ int main(int argc, char *argv[]) {
old->sample = old->sample->next;
free(oldsample);
}
+free(old->cgroup);
free(old->sample);
free(old);
}
+free(ps->cgroup);
free(ps->sample);
free(ps);
diff --git a/src/bootchart/bootchart.conf b/src/bootchart/bootchart.conf
index 48fad02..d7e0dab 100644
--- a/src/bootchart/bootchart.conf
+++ b/src/bootchart/bootchart.conf
@@ -18,3 +18,4 @@
#PlotEntropyGraph=no
#ScaleX=100
#ScaleY=20
[systemd-devel] [PATCH 2/2] bootchart: rewrite usage message more generally
---
src/bootchart/bootchart.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/src/bootchart/bootchart.c b/src/bootchart/bootchart.c
index a73418a..84497cc 100644
--- a/src/bootchart/bootchart.c
+++ b/src/bootchart/bootchart.c
@@ -209,22 +209,23 @@ static int parse_args(int argc, char *argv[]) {
arg_entropy = true;
break;
case 'h':
-fprintf(stderr, "Usage: %s [OPTIONS]\n", argv[0]);
-fprintf(stderr, " --rel, -r Record time
relative to recording\n");
-fprintf(stderr, " --freq, -f fSample
frequency [%f]\n", arg_hz);
-fprintf(stderr, " --samples, -n NStop
sampling at [%d] samples\n", arg_samples_len);
-fprintf(stderr, " --scale-x, -x NScale the
graph horizontally [%f] \n", arg_scale_x);
-fprintf(stderr, " --scale-y, -y NScale the
graph vertically [%f] \n", arg_scale_y);
-fprintf(stderr, " --pss, -p Enable PSS
graph (CPU intensive)\n");
-fprintf(stderr, " --entropy, -e Enable the
entropy_avail graph\n");
-fprintf(stderr, " --output,-o [PATH] Path to
output files [%s]\n", arg_output_path);
-fprintf(stderr, " --init, -i [PATH] Path to
init executable [%s]\n", arg_init_path);
-fprintf(stderr, " --no-filter, -F Disable
filtering of processes from the graph\n");
-fprintf(stderr, " that are of
less importance or short-lived\n");
-fprintf(stderr, " --cmdline, -C Display the
full command line with arguments\n");
-fprintf(stderr, " of
processes, instead of only the process name\n");
-fprintf(stderr, " --control-group, -c Display
process control group\n");
-fprintf(stderr, " --help, -h Display
this message\n");
+fprintf(stderr, "Usage: %s [OPTIONS]\n\n", argv[0]);
+fprintf(stderr, "Options:\n");
+fprintf(stderr, " -r, --rel Record time
relative to recording\n");
+fprintf(stderr, " -f, --freq=FREQSample
frequency [%f]\n", arg_hz);
+fprintf(stderr, " -n, --samples=NStop
sampling at [%d] samples\n", arg_samples_len);
+fprintf(stderr, " -x, --scale-x=NScale the
graph horizontally [%f] \n", arg_scale_x);
+fprintf(stderr, " -y, --scale-y=NScale the
graph vertically [%f] \n", arg_scale_y);
+fprintf(stderr, " -p, --pss Enable PSS
graph (CPU intensive)\n");
+fprintf(stderr, " -e, --entropy Enable the
entropy_avail graph\n");
+fprintf(stderr, " -o, --output=PATH Path to
output files [%s]\n", arg_output_path);
+fprintf(stderr, " -i, --init=PATHPath to init
executable [%s]\n", arg_init_path);
+fprintf(stderr, " -F, --no-filterDisable
filtering of processes from the graph\n");
+fprintf(stderr, " that are
of less importance or short-lived\n");
+fprintf(stderr, " -C, --cmdline Display the
full command line with arguments\n");
+fprintf(stderr, " of
processes, instead of only the process name\n");
+fprintf(stderr, " -c, --control-groupDisplay
process control group\n");
+fprintf(stderr, " -h, --help Display this
message\n\n");
fprintf(stderr, "See bootchart.conf for more
information.\n");
exit (EXIT_SUCCESS);
default:
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] bootchart: add control group option
On 04/25/2014 12:50 AM, WaLyong Cho wrote:
> ---
> man/bootchart.conf.xml | 5 +
> man/systemd-bootchart.xml| 7 +++
> src/bootchart/bootchart.c| 11 ++-
> src/bootchart/bootchart.conf | 1 +
> src/bootchart/bootchart.h| 2 ++
> src/bootchart/store.c| 6 ++
> src/bootchart/svg.c | 5 +++--
> 7 files changed, 34 insertions(+), 3 deletions(-)
>
> diff --git a/man/bootchart.conf.xml b/man/bootchart.conf.xml
> index 68d10d4..68834c7 100644
> --- a/man/bootchart.conf.xml
> +++ b/man/bootchart.conf.xml
> @@ -145,6 +145,11 @@
> graph components.
>
>
> +
> +
> ControlGroup=no
> +Display process control
> group.
> +
> +
>
>
>
> diff --git a/man/systemd-bootchart.xml b/man/systemd-bootchart.xml
> index 1715d5d..d83d032 100644
> --- a/man/systemd-bootchart.xml
> +++ b/man/systemd-bootchart.xml
> @@ -198,6 +198,13 @@
>
>
>
> +-g
> +--control-group
> +Display process control group
> +
> +
> +
> +
> -o
> --output
> path
> Specify the output directory
> for the
> diff --git a/src/bootchart/bootchart.c b/src/bootchart/bootchart.c
> index 9f72d98..a73418a 100644
> --- a/src/bootchart/bootchart.c
> +++ b/src/bootchart/bootchart.c
> @@ -78,6 +78,7 @@ bool initcall = true;
> bool arg_relative = false;
> bool arg_filter = true;
> bool arg_show_cmdline = false;
> +bool arg_show_cgroup = false;
> bool arg_pss = false;
> int samples;
> int arg_samples_len = 500; /* we record len+1 (1 start sample) */
> @@ -113,6 +114,7 @@ static void parse_conf(void) {
> { "Bootchart", "PlotEntropyGraph", config_parse_bool, 0,
> &arg_entropy },
> { "Bootchart", "ScaleX", config_parse_double, 0,
> &arg_scale_x },
> { "Bootchart", "ScaleY", config_parse_double, 0,
> &arg_scale_y },
> +{ "Bootchart", "ControlGroup", config_parse_bool, 0,
> &arg_show_cgroup },
> { NULL, NULL, NULL, 0, NULL }
> };
> _cleanup_fclose_ FILE *f;
> @@ -143,6 +145,7 @@ static int parse_args(int argc, char *argv[]) {
> {"init", required_argument, NULL, 'i'},
> {"no-filter", no_argument,NULL, 'F'},
> {"cmdline", no_argument,NULL, 'C'},
> +{"control-group", no_argument,NULL, 'c'},
> {"help", no_argument,NULL, 'h'},
> {"scale-x", required_argument, NULL, 'x'},
> {"scale-y", required_argument, NULL, 'y'},
> @@ -151,7 +154,7 @@ static int parse_args(int argc, char *argv[]) {
> };
> int c;
>
> -while ((c = getopt_long(argc, argv, "erpf:n:o:i:FChx:y:", options,
> NULL)) >= 0) {
> +while ((c = getopt_long(argc, argv, "erpf:n:o:i:FCchx:y:", options,
> NULL)) >= 0) {
> int r;
>
> switch (c) {
> @@ -170,6 +173,9 @@ static int parse_args(int argc, char *argv[]) {
> case 'C':
> arg_show_cmdline = true;
> break;
> +case 'c':
> +arg_show_cgroup = true;
> +break;
> case 'n':
> r = safe_atoi(optarg, &arg_samples_len);
> if (r < 0)
> @@ -217,6 +223,7 @@ static int parse_args(int argc, char *argv[]) {
> fprintf(stderr, " that are
> of less importance or short-lived\n");
> fprintf(stderr, " --cmdline, -C Display
> the full command line with arguments\n");
> fprintf(stderr, " of
> processes, instead of only the process name\n");
> +fprintf(stderr, " --control-group, -c Display
> process control group\n");
> fprintf(stderr, " --help, -h Display
> this message\n");
> fprintf(stderr, "See bootchart.conf for more
> information.\n");
> exit (EXIT_SUCCESS);
> @@ -458,9 +465,11 @@ int main(int argc, char *argv[]) {
> old->sample = old->sample->next;
> free(oldsample);
> }
> +free(old->cgroup);
> free(old->sample);
> free(old);
> }
> +free(ps->cg
Re: [systemd-devel] [PATCH] core: add startup resource control option
On 04/24/2014 06:15 AM, Lennart Poettering wrote: > On Wed, 26.03.14 00:12, WaLyong Cho (walyong@samsung.com) wrote: > >> >> On 03/25/2014 05:01 AM, Lennart Poettering wrote: >>> On Tue, 25.03.14 01:03, WaLyong Cho (walyong@samsung.com) wrote: >>> /* Figure out which controllers we need */ -if (c->cpu_accounting || c->cpu_shares != 1024) +if (c->cpu_accounting || +c->startup_cpu_shares != 1024 || +(manager_state(m) != MANAGER_STARTING && c->cpu_shares != 1024)) >>> >>> This looks incorrect. Shouldn't it be like this: >>> >>> ... >>> >>> if (c->cpu_accounting || >>> (manager->state(m) == MANAGER_STARTING ? c->startup_cpu_shares : >>> c->cpu_shares) != 1024) >>> >> >> At previous patch, I also wrote similar with your thought. Assume, some >> of units just only specified StartupCPUShares=(or >> StartupBlockIOWeight=). In this case, that unit will not be changed to >> default weight because global state is already changed to running. So I >> put startup_cpu_shares condition alone. > > No sure I understand. The service processes should be removed from the > CPU cgroup as soon as the global state reaches RUNNING if only > CPUShares= is set, but StartupCPUShares= isn't? Hence the startup cpu > shares value should not have an effect anymore. Am I missing something? > If I quote part of the commit message: only assign the specified weight during startup state. If not CPUShares= or BlockIOWeight= be specified, then the attribute is re-assigned to each default attribute value. This means if a service specified only "StartupCPUShare=" and has started with some of special cpu.shares. And systemd state is changed to running then cpu.shares of the service should be changed to default(1024). (I think this is make sense.) To do this, *cgroup_context_get_mask* have to detect the mask when only startup is set as NOT default(1024). see this my test. I made two services: -bash-4.2# cat delay.service [Unit] Description=delay Before=default.target [Service] Type=oneshot ExecStart=/bin/sleep 20 [Install] WantedBy=multi-user.target -bash-4.2# cat blabla.service [Unit] Description=blabla [Service] ExecStart=/bin/sleep 120 StartupCPUShares=700 [Install] WantedBy=multi-user.target And enabled both. and reboot. -bash-4.2# dbus-send --system --print-reply --dest=org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.DBus.Properties.Get string:org.freedesktop.systemd1.Manager string:SystemState;cat /sys/fs/cgroup/cpu/machine.slice/machine-container.scope/system.slice/blabla.service/cpu.shares method return sender=:1.1 -> dest=:1.7 reply_serial=2 variant string "starting" 700 blabla service successfully set as 700 cpu.shares. -bash-4.2# -bash-4.2# dbus-send --system --print-reply --dest=org.freedesktop.systemd1 /org/freedesktop/systemd1 org.freedesktop.DBus.Properties.Get string:org.freedesktop.systemd1.Manager string:SystemState;cat /sys/fs/cgroup/cpu/machine.slice/machine-container.scope/system.slice/blabla.service/cpu.shares method return sender=:1.1 -> dest=:1.8 reply_serial=2 variant string "running" 1024 After startup had finished then the blabla service was set as default(1024) value. -bash-4.2# cat /sys/fs/cgroup/cpu/machine.slice/machine-container.scope/system.slice/blabla.service/cpu.shares cat: /sys/fs/cgroup/cpu/machine.slice/machine-container.scope/system.slice/blabla.service/cpu.shares: No such file or directory And after two minutes later, the blabla service was finished. So the cgroup was disapeared. Thanks, WaLyong > > Lennart > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 1/2] hostnamed: expose KernelVersion on the bus
On Thu, Apr 24, 2014 at 08:53:27AM +0200, Lennart Poettering wrote: > On Wed, 23.04.14 23:03, Djalal Harouni (tix...@opendz.org) wrote: > > > This is needed to fix bug: > > > > https://bugs.freedesktop.org/show_bug.cgi?id=76498 > > Hmm, do we really want to expose the version here? I fail to see the > general usefulness of this value. The release is a lot more useful and > we already expose that, so do we really want the version here? Speaking about the version it shows if this is an SMP kernel, and if the kernel is preemtible, IOW build with CONFIG_PREEMPT Now, how many preemtible kernels are running systemd? And by coincidence, here we are speaking about systemd-analyze :-) Not to mention the build time stamp that will tell you if two same kernels differ... used in the embedded world. > I understand that the plot currently shows the value, but maybe the > right choice is to simply drop it there? Showing this sounds mostly like > folklore to me... Sure, David posted a nice video of it, during the last systemd hackfest :-) Ok, if you are against it, I'll just update the patch and drop it, I didn't bother, just fix the bug and keep the old behaviour. The code that adds this is really small. -- 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] [PATCH v2 1/2] hostnamed: expose KernelVersion on the bus
On Thu, Apr 24, 2014 at 10:34:05PM +0100, Djalal Harouni wrote: > On Thu, Apr 24, 2014 at 08:53:27AM +0200, Lennart Poettering wrote: > > On Wed, 23.04.14 23:03, Djalal Harouni (tix...@opendz.org) wrote: > > > > > This is needed to fix bug: > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=76498 > > > > Hmm, do we really want to expose the version here? I fail to see the > > general usefulness of this value. The release is a lot more useful and > > we already expose that, so do we really want the version here? > Speaking about the version it shows if this is an SMP kernel, and if the > kernel is preemtible, IOW build with CONFIG_PREEMPT > > Now, how many preemtible kernels are running systemd? > > And by coincidence, here we are speaking about systemd-analyze :-) > > Not to mention the build time stamp that will tell you if two same > kernels differ... used in the embedded world. It might be useful to distinguish bootcharts generated with different kernels when comparing compilation options or whatever. I'd be inclined to keep it. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-notify --ready is not reliable
On Wed, Apr 23, 2014 at 08:50:34PM +0200, Lennart Poettering wrote: > On Wed, 23.04.14 15:15, Eelco Dolstra (eelco.dols...@logicblox.com) wrote: > > > Hi all, > > > > I've noticed that the command "systemd-notify --ready" does not work > > reliably to > > signal that a service is ready. It works sometimes, but most of the time > > you get > > a message like: > > > > systemd[1]: Cannot find unit for notify message of PID 3137. > > > > in the journal, and the service stays in the "activating" state. > > > > The reason is that systemd-notify sends its message asynchronously and exits > > immediately. So by the time systemd processes the message, systemd-notify > > has > > probably already exited, and so systemd cannot gets cgroup. (Note that this > > affects other systemd-notify messages as well, but for --ready it's > > particularly > > bad because it causes services to "hang" in the "activating" state.) > > > > Any suggestions what to do about this? I can see a few solutions: > > There is ongoing work to fix the kernel to add SCM_CGROUPS for us to > messages. With that in place we have a race-free way to get this data > for incoming messages. I have some hopes that this will soonishly enter > the kernel, but then again, this story has been cookie for the past 5 > years to no successs... What about simply waiting in the background for 10s? An ugly workaround, but should fix the issue until we have something better. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] bootchart: add control group option
On Fri, Apr 25, 2014 at 12:59:04AM +0900, WaLyong Cho wrote: > On 04/25/2014 12:50 AM, WaLyong Cho wrote: > > --- > > man/bootchart.conf.xml | 5 + > > man/systemd-bootchart.xml| 7 +++ > > src/bootchart/bootchart.c| 11 ++- > > src/bootchart/bootchart.conf | 1 + > > src/bootchart/bootchart.h| 2 ++ > > src/bootchart/store.c| 6 ++ > > src/bootchart/svg.c | 5 +++-- > > 7 files changed, 34 insertions(+), 3 deletions(-) Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] libudev: replace name_to_handle_at with normal sscanf
On Thu, Apr 24, 2014 at 10:31:54AM +0200, Kay Sievers wrote: > On Thu, Apr 24, 2014 at 7:35 AM, Lennart Poettering > wrote: > > On Thu, 24.04.14 07:28, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) > > wrote: > >> > Have you checked that EOPNOTSUPP is really the error that is returned by > >> > name_to_handle_at() if the kernel has the entire syscall disabled? Note > >> > that there are two different cases to distuingish here: a file system > >> > not supporting the operation, and the kernel not supporting the > >> > syscal... > >> It's warning on everything except EOPNOTSUPP. My reasoning is: > >> > >> EOPNOTSUPP -> syscall supported, but wrong fs type, -> return false > >> ENOSYS -> syscall not supported -> warn and return false > >> any other error -> memory error or other major screw-up -> warn and return > >> false > > > > Looks good to me then, Kay? > > Sure, looks all fine. Pushed now. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] systemd-networkd man repair
Corrections to the manuals related to networkd-wait-online. --- man/networkd-wait-online.conf.xml| 4 ++-- man/systemd-networkd-wait-online.service.xml | 4 ++-- man/systemd-networkd.service.xml | 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/man/networkd-wait-online.conf.xml b/man/networkd-wait-online.conf.xml index 821b0ef..684326f 100644 --- a/man/networkd-wait-online.conf.xml +++ b/man/networkd-wait-online.conf.xml @@ -75,8 +75,7 @@ to wait for before deciding if the machine is considered to be online. The default is to wait for at least one that is managed by - systemd-networkd.service - 8, + systemd-networkd.service8, or one other which is brought up by someone else. @@ -89,6 +88,7 @@ systemd1, systemd-networkd.service8, + systemd-networkd-wait-online.service8 diff --git a/man/systemd-networkd-wait-online.service.xml b/man/systemd-networkd-wait-online.service.xml index d8f2226..78794be 100644 --- a/man/systemd-networkd-wait-online.service.xml +++ b/man/systemd-networkd-wait-online.service.xml @@ -64,7 +64,7 @@ systemd-networkd to appear, or for a link to be brought up by someone else. To wait for a specific set of links, see - systemd-networkd.conf5. + networkd-wait-online.conf5. This may be necessary on systems with more than one active link. @@ -73,8 +73,8 @@ See Also systemd1, - systemd-networkd.conf5, systemd-networkd.service8, + networkd-wait-online.conf5 diff --git a/man/systemd-networkd.service.xml b/man/systemd-networkd.service.xml index ca35a88..76ce73f 100644 --- a/man/systemd-networkd.service.xml +++ b/man/systemd-networkd.service.xml @@ -100,8 +100,8 @@ systemd1, systemd.link5, systemd.network5, - systemd.netdev5 - systemd-network-wait-online.service8 + systemd.netdev5, + systemd-networkd-wait-online.service8 -- 1.9.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
