[systemd-devel] kmod-static-nodes.service doesn't care about udev?
Latest innovation with kmod-static-nodes.service introduce next issues with 1. default distro paths 2. interacting with rest configuration So, what is the problem. kmod-static-nodes.service.in: ExecStartPre=/usr/bin/mkdir -p /run/tmpfiles.d /usr/bin/mkdir zsh: no such file or directory: /usr/bin/mkdir That is not that big deal, because that should be replaced with tmpfiles.d conf file with lowest prioirty, but shows some kind of problem - different distros has utilites in different places. That is not the problem, because we have pathname resolution IEEE standard and core system rely on it. But not the systemd. Ok, maybe that makes some sence for ExecStart services, but do we really need that in ExecStartPre/ExecStartPost? Maybe some syntax shugar should be introduced like ExecStartPre=* - run with /bin/sh? The next one - kmod doesn't care about udev rules. So, I have something like this in udev rules: KERNEL==fuse, MODE=0666 and in autogenerated with kmod: c /dev/fuse 0600 - - - 10:229 The last one has priority. So, either kmod-static-nodes.service should be started before udev, or some new logic should be introduces somewhere to prevent that destructive behavior. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kmod-static-nodes.service doesn't care about udev?
On 12 Jul 2013 08:28, Oleksii Shevchuk alx...@gmail.com wrote: Latest innovation with kmod-static-nodes.service introduce next issues with 1. default distro paths 2. interacting with rest configuration So, what is the problem. kmod-static-nodes.service.in: ExecStartPre=/usr/bin/mkdir -p /run/tmpfiles.d /usr/bin/mkdir zsh: no such file or directory: /usr/bin/mkdir Good catch. The standard path is /bin/mkdir, so we should change it to that, or if any distribution uses something else we could detect at compile time. The next one - kmod doesn't care about udev rules. So, I have something like this in udev rules: KERNEL==fuse, MODE=0666 and in autogenerated with kmod: c /dev/fuse 0600 - - - 10:229 The last one has priority. So, either kmod-static-nodes.service should be started before udev, or some new logic should be introduces somewhere to prevent that destructive behavior. This should work, but your udev rule must be set up to apply to static nodes. See how it is done for snd/seq for instance. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journal and /run/systemd/journal/syslog
On Fri, Jul 12, 2013 at 1:08 AM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 10.07.13 12:30, Umut Tezduyar (u...@tezduyar.com) wrote: We though about just bumping this globally via sysctl, but we feared that might not sit well with some folks, as we shouldn't change a global setting just because one user of it would benefit, especially given that we don't know the effect this might have on others... I want to go this route and I think it is not possible at the moment due to undetermined start order between syslog.socket and systemd-sysctl.service. Can we change that? Hmm, are you saying that changing the sysctl value too late will have no effect on the sockets that already exist at that time? That is correct. Limit is applied to the socket when it is created (sk-sk_max_ack_backlog = net-unx.sysctl_max_dgram_qlen;). You could do this on your system: # mkdir /etc/systemd/system/syslog.socket.d/ # echo [Unit] After=systemd-sysctl.service /etc/systemd/system/syslog.socket.d/after-sysctl.conf Then, make the sysctl setting, and things should work? Lennart I believe using dropin services should work as well as handling this in linuxrc or ramfs. I was more after an upstream solution then per user solution but since we are all on the same page regarding the kernel fix for per socket limit, I guess I need to solve it in my application. Thanks for the help. Umut -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: notify triggered by socket of a service
On Wed, Jul 10, 2013 at 2:24 PM, Umut Tezduyar u...@tezduyar.com wrote:
On Wed, Jul 10, 2013 at 9:19 AM, Umut Tezduyar u...@tezduyar.com wrote:
---
systemd/src/core/service.c | 31 ---
systemd/src/core/socket.c | 33 -
systemd/src/core/socket.h |3 ---
3 files changed, 32 insertions(+), 35 deletions(-)
diff --git a/src/core/service.c b/src/core/service.c
index 3617c24..78ee272 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -1474,24 +1474,6 @@ static int service_search_main_pid(Service *s) {
return 0;
}
-static void service_notify_sockets_dead(Service *s, bool failed_permanent) {
-Iterator i;
-Unit *u;
-
-assert(s);
-
-/* Notifies all our sockets when we die */
-
-if (s-socket_fd = 0)
-return;
-
-SET_FOREACH(u, UNIT(s)-dependencies[UNIT_TRIGGERED_BY], i)
-if (u-type == UNIT_SOCKET)
-socket_notify_service_dead(SOCKET(u),
failed_permanent);
-
-return;
-}
-
static void service_set_state(Service *s, ServiceState state) {
ServiceState old_state;
const UnitActiveState *table;
@@ -1543,19 +1525,6 @@ static void service_set_state(Service *s,
ServiceState state) {
s-control_command_id = _SERVICE_EXEC_COMMAND_INVALID;
}
-if (state == SERVICE_FAILED)
-service_notify_sockets_dead(s, s-result ==
SERVICE_FAILURE_START_LIMIT);
-
-if (state == SERVICE_DEAD ||
-state == SERVICE_STOP ||
-state == SERVICE_STOP_SIGTERM ||
-state == SERVICE_STOP_SIGKILL ||
-state == SERVICE_STOP_POST ||
-state == SERVICE_FINAL_SIGTERM ||
-state == SERVICE_FINAL_SIGKILL ||
-state == SERVICE_AUTO_RESTART)
-service_notify_sockets_dead(s, false);
-
if (state != SERVICE_START_PRE
state != SERVICE_START
state != SERVICE_START_POST
diff --git a/src/core/socket.c b/src/core/socket.c
index 1b08f0a..21bbba5 100644
--- a/src/core/socket.c
+++ b/src/core/socket.c
@@ -2261,7 +2261,7 @@ int socket_collect_fds(Socket *s, int **fds, unsigned
*n_fds) {
return 0;
}
-void socket_notify_service_dead(Socket *s, bool failed_permanent) {
+static void socket_notify_service_dead(Socket *s, bool failed_permanent) {
assert(s);
/* The service is dead. Dang!
@@ -2306,6 +2306,35 @@ static void socket_reset_failed(Unit *u) {
s-result = SOCKET_SUCCESS;
}
+static void socket_trigger_notify(Unit *u, Unit *other) {
+Socket *s = SOCKET(u);
+Service *se = SERVICE(other);
+
+assert(u);
+assert(other);
+
+if (other-load_state != UNIT_LOADED ||
+other-type != UNIT_SERVICE)
+return;
+
+if (se-state == SERVICE_FAILED se-socket_fd 0)
+socket_notify_service_dead(s, se-result ==
SERVICE_FAILURE_START_LIMIT);
+
+if ((se-state == SERVICE_DEAD ||
+se-state == SERVICE_STOP ||
+se-state == SERVICE_STOP_SIGTERM ||
+se-state == SERVICE_STOP_SIGKILL ||
+se-state == SERVICE_STOP_POST ||
+se-state == SERVICE_FINAL_SIGTERM ||
+se-state == SERVICE_FINAL_SIGKILL ||
+se-state == SERVICE_AUTO_RESTART)
+se-socket_fd 0)
+socket_notify_service_dead(s, false);
+
+if (se-state == SERVICE_RUNNING)
+socket_set_state(s, SOCKET_RUNNING);
This doesn't work for socket activated/instantiated services. I should
be able to detect if a service is instantiated..
Lennart, do you have a solution for this that I can take in and
re-send the patch? It works great for socket activated services that
when service is running, the triggered by socket is set to running too
but it is not working for instantiated services. For instantiated
services, socket needs to stay in listening stay all the time.
+}
+
static int socket_kill(Unit *u, KillWho who, int signo, DBusError *error) {
return unit_kill_common(u, who, signo, -1, SOCKET(u)-control_pid,
error);
}
@@ -2385,6 +2414,8 @@ const UnitVTable socket_vtable = {
.sigchld_event = socket_sigchld_event,
.timer_event = socket_timer_event,
+.trigger_notify = socket_trigger_notify,
+
.reset_failed = socket_reset_failed,
.bus_interface = org.freedesktop.systemd1.Socket,
diff --git a/src/core/socket.h b/src/core/socket.h
index 9d48cde..9714303 100644
--- a/src/core/socket.h
+++ b/src/core/socket.h
@@ -154,9 +154,6 @@ struct Socket {
/* Called from the service code when collecting fds */
int socket_collect_fds(Socket *s, int **fds, unsigned *n_fds);
-/* Called from the service when it shut down */
-void
Re: [systemd-devel] [RFC PATCH] condition: add ConditionFileContains=
It was 2013-07-12 pią 04:48, when Kyungmin Park wrote: On Fri, Jul 12, 2013 at 7:43 AM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 11.07.13 13:37, Dave Reisner (d...@falconindy.com) wrote: +p = strchr(path, ':'); This is going to fail for a file:value pair such as /foo:/bar/baz:value. You could use strrchr(), but then you have to be concerned about matching values with a colon. This might become a problem, but then again, I think it is OK if some files cannot be checked with this. I'd prefer using a space or = as separator as a better choice though, as that's probably less frequent than : in the names of files one would check with this condition setting. Lennart It's another question. the main goal of this patch is that supports conditional execution If some services are executed with given condition, it should check some conditions and execute different flow. if [ condition is 1 ]; then launch A service else if [ condition is 2 ]; then launch B service else launch C service IMHO this looks too complicated to fit into systemd units. To support such (multiple choice) situation (which seems like the the conditions are not properly stated) we can use a generator to link the desired service to the proper target. -- Łukasz Stelmach Samsung RD Institute Poland Samsung Electronics ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] condition: add ConditionFileContains=
It was 2013-07-11 czw 19:18, when Karol Lewandowski wrote: Add ability to test if given file contains specified value. File and expected value are given as one argument separated by colon (:), i.e. ConditionFileContains=/sys/module/sn/parameters/enabled:1 --- As above example suggests we use it to conditionally start service based on kernel module parameter value. This can be (ab)used for other/regular files too. RFC I am confused a bit. Although I can see (hardly though) the point but I am not sure, yet another condition in unit files is required. IMHO systemd can check if files required by a service exist (and some other tests which more or less cover test(1) functions) and not lauch the service if they does not but, it is up to the service to check the files' contents. No matter if it is a single character or a 24Mpix jpeg file. Technically, except for the notes already given by others, the patch does not look bad. -- Łukasz Stelmach Samsung RD Institute Poland Samsung Electronics ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] update: udev keymaps are moving to hwdb
On Wed, Jul 10, 2013 at 11:38 PM, Kay Sievers k...@vrfy.org wrote: The systemd git source tree has now all the pieces to prepare the move from the current keymap handling to the hardware database. None of it will take any action at the moment, the hwdb file is not committed. The hand-edited: /usr/lib/udev/hwdb.d/60-keyboard.hwdb is in the systemd source tree now: http://cgit.freedesktop.org/systemd/systemd/tree/hwdb/60-keyboard.hwdb? It should contain almost all data from the keymaps. The Logitech too broad matches for USB devices, which use the textual string instead of the usual USB IDs have been dropped, they need to be resurrected when someone can supply the USB IDs. Again, any help or testing would be very welcome. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] condition: add ConditionFileContains=
On Fri, 12.07.13 11:48, Kyungmin Park (kmp...@infradead.org) wrote: It's another question. the main goal of this patch is that supports conditional execution If some services are executed with given condition, it should check some conditions and execute different flow. if [ condition is 1 ]; then launch A service else if [ condition is 2 ]; then launch B service else launch C service current systemd scheme we have to prepare three service file. so can we make it only one service with some unit extension? IOW multipul unit support? [Unit] ... ConditionBlahBlah=1 [Unit] ... ConditionBlahBlah=2 [Unit] ... ConditionBlahBlah=!1 !2 or empty line Unit files are not supposed to be a Turing complete programming language, and conditions are suggested only as simple checks for optimizing start-up of some services. Their configuration files are independent of each other so that we can load/unload them separately. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] condition: add ConditionFileContains=
On Fri, 12.07.13 10:16, Łukasz Stelmach (l.stelm...@samsung.com) wrote: It was 2013-07-11 czw 19:18, when Karol Lewandowski wrote: Add ability to test if given file contains specified value. File and expected value are given as one argument separated by colon (:), i.e. ConditionFileContains=/sys/module/sn/parameters/enabled:1 --- As above example suggests we use it to conditionally start service based on kernel module parameter value. This can be (ab)used for other/regular files too. RFC I am confused a bit. Although I can see (hardly though) the point but I am not sure, yet another condition in unit files is required. IMHO systemd can check if files required by a service exist (and some other tests which more or less cover test(1) functions) and not lauch the service if they does not but, it is up to the service to check the files' contents. No matter if it is a single character or a 24Mpix jpeg file. Technically, except for the notes already given by others, the patch does not look bad. To make this clear: I am not keen on adding this. I can see the usefulness, and the thing is still simple enough so that it would be OK to add this, but if you guys don't actually need that I'd prefer to keep our codebase smaller... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] condition: add ConditionFileContains=
On Fri, Jul 12, 2013 at 3:31 PM, Lennart Poettering lenn...@poettering.net wrote: ConditionFileContains=/sys/module/sn/parameters/enabled:1 To make this clear: I am not keen on adding this. I can see the usefulness, and the thing is still simple enough so that it would be OK to add this, but if you guys don't actually need that I'd prefer to keep our codebase smaller... Just a note: The above example should be triggered by a udev rule anyway. During bootup: udevadm trigger --type=subsystems will coldplug all modules, and udev rules can catch the content of a module parameter and pull-in a service on demand. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevadm settle hangs due to veths in seperate network namespaces
On Fri, Jul 12, 2013 at 4:49 PM, Daniel P. Berrange berra...@redhat.com wrote: On Fri, Jul 12, 2013 at 04:42:34PM +0200, Kay Sievers wrote: On Fri, Jul 12, 2013 at 4:21 PM, Kay Sievers k...@vrfy.org wrote: On Fri, Jul 12, 2013 at 4:14 PM, Daniel P. Berrange berra...@redhat.com wrote: On Fri, Jul 12, 2013 at 04:10:35PM +0200, Kay Sievers wrote: Hmm, we just don't really support running udev inside of containers. Hotplug and full OS containers have did never get any real attention from udev running inside container setups. This example is *not* running udev in the container. The 'udevadm settle' command above is being run in the primary OS. IOW, the fact that the container has a network namespace with a veth, is breaking udevadm in the host. Oh, interesting. I thought you meant running 'settle' inside the container. That, then sounds like something we should be able cope with. I'll have a look now ... The kernel uevents generated inside the network namespace use the same single global sequence number as the host, but the events for the in-namespace devices are simply filtered out not to show up in the host. Settle expects to see *all* sequence numbers to wait for, and does not accept holes in the sequence. Hmm, at this moment, I have no idea how that should work, we cannot easily find out that these events will never show up in the host and we should not wait for them. The uevent filter hack in the kernel maybe should just be changed to not allocate sequence numbers of the *host* inside the namespace, and always compose the events inside the namespace with SEQNUM=0. Ewww, yes, that's pretty nasty kernel behaviour/change there :-( The sequence numbers were done to track queued events in the host and to wait for them, having the netns hack stealing the devices in /sys and the uevents by filtering seems to work ok, but stealing our sequence numbers is pretty nasty. :) Yeah, we need to find out what other options we have. Maybe there is a way to reliably work around that issue in udev, but at this moment I don't really see how ... Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstab Mounts Not Getting Waken Up
cac...@quantum-sci.com: Dave Reisner: On Thu, Jul 11, 2013 at 12:57:22PM -0700, cac...@quantum-sci.com wrote: I'd understood that if a mount is in fstab, that it should be re-established when the system wakes. But that's not happening. Meaning two sshfs mounts as so: sshfs#carl@droog://media/droogfuse user,auto,_netdev,gid=6,umask=007,cache=no,ServerAliveInterval=15,allow_other,comment=sshfs 0 0 Why would this be? Your use of sshfs# as a FUSE type is wrong -- you must use fuse.sshfs as the fstype instead. I don't know if this in particular is the solution to the problem you're seeing, but the source field is certainly wrong. Thanks, but it didn't work. Waking the machine from sleep, the drive is never mounted. Also now the mount command fails. Before it worked. /bin/sh: fuse.sshfs: command not found Believe me, my system has worked for years. But with the transition to systemd, it will no longer mount on wake. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] shared: rename hasprefix() to startswith(), which is functionally identical and removed
as most (if not all) of the prefix strings are static, these will get
forward constant propagation optimized into single memcmp() calls, which
should be much better than the non-SIMD hand-rolled version.
---
src/journal/journal-send.c | 2 +-
src/journal/journald-native.c | 12 ++--
src/libsystemd-bus/bus-match.c | 26 +-
src/shared/logs-show.c | 2 +-
src/shared/macro.h | 2 +-
src/shared/util.c | 17 -
src/shared/util.h | 1 -
7 files changed, 22 insertions(+), 40 deletions(-)
diff --git a/src/journal/journal-send.c b/src/journal/journal-send.c
index fef66fc..d00e26f 100644
--- a/src/journal/journal-send.c
+++ b/src/journal/journal-send.c
@@ -245,7 +245,7 @@ _public_ int sd_journal_sendv(const struct iovec *iov, int
n) {
have_syslog_identifier = have_syslog_identifier ||
(c == (char *) iov[i].iov_base + 17
- hasprefix(iov[i].iov_base, SYSLOG_IDENTIFIER));
+ startswith(iov[i].iov_base, SYSLOG_IDENTIFIER));
nl = memchr(iov[i].iov_base, '\n', iov[i].iov_len);
if (nl) {
diff --git a/src/journal/journald-native.c b/src/journal/journald-native.c
index 0f9af37..c50cf64 100644
--- a/src/journal/journald-native.c
+++ b/src/journal/journald-native.c
@@ -154,23 +154,23 @@ void server_process_native_message(
* of this entry for the rate limiting
* logic */
if (l == 10
-hasprefix(p, PRIORITY=)
+startswith(p, PRIORITY=)
p[9] = '0' p[9] = '9')
priority = (priority LOG_FACMASK) |
(p[9] - '0');
else if (l == 17
- hasprefix(p, SYSLOG_FACILITY=)
+ startswith(p, SYSLOG_FACILITY=)
p[16] = '0' p[16] = '9')
priority = (priority LOG_PRIMASK) |
((p[16] - '0') 3);
else if (l == 18
- hasprefix(p, SYSLOG_FACILITY=)
+ startswith(p, SYSLOG_FACILITY=)
p[16] = '0' p[16] = '9'
p[17] = '0' p[17] = '9')
priority = (priority LOG_PRIMASK) |
(((p[16] - '0')*10 + (p[17] - '0')) 3);
else if (l = 19
- hasprefix(p, SYSLOG_IDENTIFIER=)) {
+ startswith(p, SYSLOG_IDENTIFIER=)) {
char *t;
t = strndup(p + 18, l - 18);
@@ -179,7 +179,7 @@ void server_process_native_message(
identifier = t;
}
} else if (l = 8
- hasprefix(p, MESSAGE=)) {
+ startswith(p, MESSAGE=)) {
char *t;
t = strndup(p + 8, l - 8);
@@ -189,7 +189,7 @@ void server_process_native_message(
}
} else if (l strlen(OBJECT_PID=)
l strlen(OBJECT_PID=) +
DECIMAL_STR_MAX(pid_t)
- hasprefix(p, OBJECT_PID=)
+ startswith(p, OBJECT_PID=)
allow_object_pid(ucred)) {
char buf[DECIMAL_STR_MAX(pid_t)];
memcpy(buf, p + strlen(OBJECT_PID=),
l - strlen(OBJECT_PID=));
diff --git a/src/libsystemd-bus/bus-match.c b/src/libsystemd-bus/bus-match.c
index 750acfe..1411167 100644
--- a/src/libsystemd-bus/bus-match.c
+++ b/src/libsystemd-bus/bus-match.c
@@ -555,22 +555,22 @@ static int bus_match_find_leaf(
enum bus_match_node_type bus_match_node_type_from_string(const char *k, size_t
n) {
assert(k);
-if (n == 4 hasprefix(k, type))
+if (n == 4 startswith(k, type))
return BUS_MATCH_MESSAGE_TYPE;
-if (n == 6 hasprefix(k, sender))
+if (n == 6 startswith(k, sender))
return BUS_MATCH_SENDER;
-if (n == 11 hasprefix(k, destination))
+if (n == 11 startswith(k, destination))
return BUS_MATCH_DESTINATION;
-if (n == 9 hasprefix(k, interface))
+if (n ==
[systemd-devel] [PATCH v2] shared: rename hasprefix() to startswith(), which is functionally identical and removed
as most (if not all) of the prefix strings are static, these will get
forward constant propagation optimized into single memcmp() calls, which
should be much better than the non-SIMD hand-rolled version.
---
TODO | 2 --
src/journal/journal-send.c | 2 +-
src/journal/journald-native.c | 12 ++--
src/libsystemd-bus/bus-match.c | 26 +-
src/shared/logs-show.c | 2 +-
src/shared/macro.h | 2 +-
src/shared/util.c | 17 -
src/shared/util.h | 1 -
8 files changed, 22 insertions(+), 42 deletions(-)
diff --git a/TODO b/TODO
index 5d4ba8f..ad600c2 100644
--- a/TODO
+++ b/TODO
@@ -57,8 +57,6 @@ Features:
* Get rid of systemd-sysv:
https://fedoraproject.org/wiki/User:Toshio/Systemd_Convert_draft
-* do we really need both hasprefix() and startswith()?
-
* when a kernel driver logs in a tight loop we should ratelimit that too.
* journald: when we drop syslog messages because the syslog socket is
diff --git a/src/journal/journal-send.c b/src/journal/journal-send.c
index fef66fc..d00e26f 100644
--- a/src/journal/journal-send.c
+++ b/src/journal/journal-send.c
@@ -245,7 +245,7 @@ _public_ int sd_journal_sendv(const struct iovec *iov, int
n) {
have_syslog_identifier = have_syslog_identifier ||
(c == (char *) iov[i].iov_base + 17
- hasprefix(iov[i].iov_base, SYSLOG_IDENTIFIER));
+ startswith(iov[i].iov_base, SYSLOG_IDENTIFIER));
nl = memchr(iov[i].iov_base, '\n', iov[i].iov_len);
if (nl) {
diff --git a/src/journal/journald-native.c b/src/journal/journald-native.c
index 0f9af37..c50cf64 100644
--- a/src/journal/journald-native.c
+++ b/src/journal/journald-native.c
@@ -154,23 +154,23 @@ void server_process_native_message(
* of this entry for the rate limiting
* logic */
if (l == 10
-hasprefix(p, PRIORITY=)
+startswith(p, PRIORITY=)
p[9] = '0' p[9] = '9')
priority = (priority LOG_FACMASK) |
(p[9] - '0');
else if (l == 17
- hasprefix(p, SYSLOG_FACILITY=)
+ startswith(p, SYSLOG_FACILITY=)
p[16] = '0' p[16] = '9')
priority = (priority LOG_PRIMASK) |
((p[16] - '0') 3);
else if (l == 18
- hasprefix(p, SYSLOG_FACILITY=)
+ startswith(p, SYSLOG_FACILITY=)
p[16] = '0' p[16] = '9'
p[17] = '0' p[17] = '9')
priority = (priority LOG_PRIMASK) |
(((p[16] - '0')*10 + (p[17] - '0')) 3);
else if (l = 19
- hasprefix(p, SYSLOG_IDENTIFIER=)) {
+ startswith(p, SYSLOG_IDENTIFIER=)) {
char *t;
t = strndup(p + 18, l - 18);
@@ -179,7 +179,7 @@ void server_process_native_message(
identifier = t;
}
} else if (l = 8
- hasprefix(p, MESSAGE=)) {
+ startswith(p, MESSAGE=)) {
char *t;
t = strndup(p + 8, l - 8);
@@ -189,7 +189,7 @@ void server_process_native_message(
}
} else if (l strlen(OBJECT_PID=)
l strlen(OBJECT_PID=) +
DECIMAL_STR_MAX(pid_t)
- hasprefix(p, OBJECT_PID=)
+ startswith(p, OBJECT_PID=)
allow_object_pid(ucred)) {
char buf[DECIMAL_STR_MAX(pid_t)];
memcpy(buf, p + strlen(OBJECT_PID=),
l - strlen(OBJECT_PID=));
diff --git a/src/libsystemd-bus/bus-match.c b/src/libsystemd-bus/bus-match.c
index 750acfe..1411167 100644
--- a/src/libsystemd-bus/bus-match.c
+++ b/src/libsystemd-bus/bus-match.c
@@ -555,22 +555,22 @@ static int bus_match_find_leaf(
enum bus_match_node_type bus_match_node_type_from_string(const char *k, size_t
n) {
assert(k);
-if (n == 4
Re: [systemd-devel] fstab Mounts Not Getting Waken Up
Your use of sshfs# as a FUSE type is wrong -- you must use fuse.sshfs as the fstype instead. this simply wrong, this line below in /etc/fstab works day and night from FC9 to Fedora 18 as well as curlftpsfs mounts in /etc/fstab are starting with curlftpfs# and *both* have fuse and nothing else as fstype sshfs#reindl@webserver:/ /mnt/webserver fuse noauto,user,rw,noexec,nosuid,nodev,uid=harry the server is a simple openssh on F17 with native sftp-chroot signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstab Mounts Not Getting Waken Up
On Fri, Jul 12, 2013 at 05:46:37PM +0200, Reindl Harald wrote: Your use of sshfs# as a FUSE type is wrong -- you must use fuse.sshfs as the fstype instead. this simply wrong, this line below in /etc/fstab works day and night from FC9 to Fedora 18 as well as curlftpsfs mounts in /etc/fstab are starting with curlftpfs# and *both* have fuse and nothing else as fstype sshfs#reindl@webserver:/ /mnt/webserver fuse noauto,user,rw,noexec,nosuid,nodev,uid=harry the server is a simple openssh on F17 with native sftp-chroot I direct you to mount(8): The programs mount and umount support filesystem subtypes. The subtype is defined by '.subtype' suffix. For example 'fuse.sshfs'. It's recommended to use subtype notation rather than add any prefix to the mount source (for example 'sshfs#example.com' is deprecated). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstab Mounts Not Getting Waken Up
Am 12.07.2013 17:54, schrieb Dave Reisner: On Fri, Jul 12, 2013 at 05:46:37PM +0200, Reindl Harald wrote: Your use of sshfs# as a FUSE type is wrong -- you must use fuse.sshfs as the fstype instead. this simply wrong, this line below in /etc/fstab works day and night from FC9 to Fedora 18 as well as curlftpsfs mounts in /etc/fstab are starting with curlftpfs# and *both* have fuse and nothing else as fstype sshfs#reindl@webserver:/ /mnt/webserver fuse noauto,user,rw,noexec,nosuid,nodev,uid=harry the server is a simple openssh on F17 with native sftp-chroot I direct you to mount(8): The programs mount and umount support filesystem subtypes. The subtype is defined by '.subtype' suffix. For example 'fuse.sshfs'. It's recommended to use subtype notation rather than add any prefix to the mount source (for example 'sshfs#example.com' is deprecated) there is a difference between is deprecated while there is no single message in /var/log/messages where it would belong to in this case or claim is wrong as you did! signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstab Mounts Not Getting Waken Up
Reindl Harald: Your use of sshfs# as a FUSE type is wrong -- you must use fuse.sshfs as the fstype instead. this simply wrong, this line below in /etc/fstab works day and night from FC9 to Fedora 18 as well as curlftpsfs mounts in /etc/fstab are starting with curlftpfs# and *both* have fuse and nothing else as fstype sshfs#reindl@webserver:/ /mnt/webserver fuse noauto,user,rw,noexec,nosuid,nodev,uid=harry the server is a simple openssh on F17 with native sftp-chroot Reindl, thank goodness you're listening. Have you by chance, tried this with auto, to see whether it automounts on wake from suspend? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] shared: rename hasprefix() to startswith(), which is functionally identical and removed
On Fri, 12.07.13 08:42, Shawn Landden (shawnland...@gmail.com) wrote: as most (if not all) of the prefix strings are static, these will get forward constant propagation optimized into single memcmp() calls, which should be much better than the non-SIMD hand-rolled version. They are functionally close, but not the same. I added this to the TODO list because I'd like to see them merged one day, but it's not trivial as your patch. startswith() is not particularly optimized, but it has one major benefit: it returns a pointer to the first char after the passed prefix, which is actually hugely useful and used at various places. hasprefix() is more efficient for static+const prefix strings. (startswith() is also nicer if prefix is potentially large. But I figure this property doesn't matter and is somethign we can get rid of) It should be possible to merge both calls in one macro, and that's how I'd like to see this fixed. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevadm settle hangs due to veths in seperate network namespaces
On Fri, Jul 12, 2013 at 5:00 PM, Daniel P. Berrange berra...@redhat.com wrote: On Fri, Jul 12, 2013 at 02:51:10PM +0100, Daniel P. Berrange wrote: We're hitting a problem in libvirt where 'udevadm settle' will get stuck in a loop until it eventually times out. Eventually we realized this happens when we have any LXC containers active with veth devices in a separate network namespace. Incidentally, I recall reading something by (iirc) Lennart saying that apps really should use 'udevadm settle' at all.\ You mean *not*, I guess. There are still valid uses of settle for command line tools, and that will be likely valid in the future too. There is no simple replacement for this barrier to be implemented by simple command line tools. Letting then subscribe to hotplug would ask for too much in quite a few cases. No advanced subsystem or service though should rely or model around settle and make assumptions about everything is there now, tools should subscribe to udev events and after that enumerate the current devices. Things that pull-in settle at bootup are kind of broken, that is the aspect of seetle you heard from Lennart rightfully complaining, I guess. Libvirt uses it in a couple of places, all related to code which obtains lists of storage devices Which makes sense according to the current state of affairs. Storage tools are only slowly catching up with the reality of devices coming and going all the time on today's systems. They get fixed, and things look at least better today than they have been, but settle is still needed for some operations. - After adding a disk partition in parted, we use it to wait for the /dev/sdXXNNN device nodes to all show up Primary device node creation (not symlinks) is synchronous since a couple of years. Devtmps does that for us. The ioctl to add a part table entry, re-read the part table will not return until devtmpfs has created the device nodes. The udev symlinks though might only be available after a settle call. - After logging into an iscsi target with iscsiadm, we use it to wait for all the /dev/sdXXX devices nodes associated with the iSCSI target to appear. - After triggering a SCSI HBA rescan via sysfs, we use it to wait for all the /dev/sdXXX devices nodes associated with the SCI HBA to appear - After creating an NPIV virtual HBA via sysfs, we use it to wait for all the /dev/sdXXX devices nodes associated with the vHBA to appear As said, this should all be covered on more recent systems. - After activating an LVM volume group, we use it to wait for all the /dev/VGNAME/ device nodes to appear - After deleting an LVM volume we use it to wait for the device node to be removed - After adding an LVM volume we use it to wait for the device node to be added LVM is a story on its own, it's pretty complex, and it slowly gets fixed over time. With the very recent changes it might integrate nicer now. I guess there are still situations though where settle is needed and the simplest solution. All of that applies only to the command line tools again, not for bootup related services, or full-blown storage management services. It is not ok for them to relay on settle. You can see a pattern there - after doing some action related to storage, we need to synchronize wrt the creation/deletion of device nodes in /dev, otherwise we miss out LUNs when we scan for the list of device nodes associated with a HBA/VolGroup/etc. Any suggestions for alternative techniques / approaches here ? I think it's fine and is needed for libvirt to use settle. At least as long as it calls the command line tools. There is no generally available storage interface on Linux which would solve all these problems for libvirt, and I don't think you should declare these problems as libvirt problems. Using settle to get a barrier for the tools you need to use which themselves cannot handle async setup and hotplug sounds fine to me. Many of the issues though might already be history with devtmpfs, at least when the primary nodes (and not the symlinks) are used. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstab Mounts Not Getting Waken Up
Am 12.07.2013 17:58, schrieb cac...@quantum-sci.com: Reindl Harald: Your use of sshfs# as a FUSE type is wrong -- you must use fuse.sshfs as the fstype instead. this simply wrong, this line below in /etc/fstab works day and night from FC9 to Fedora 18 as well as curlftpsfs mounts in /etc/fstab are starting with curlftpfs# and *both* have fuse and nothing else as fstype sshfs#reindl@webserver:/ /mnt/webserver fuse noauto,user,rw,noexec,nosuid,nodev,uid=harry the server is a simple openssh on F17 with native sftp-chroot Reindl, thank goodness you're listening. Have you by chance, tried this with auto, to see whether it automounts on wake from suspend? sorry, i stopped in 2011 to use notebooks forever and all and switched to workstations with RAID10 which are 365 days a year on or at least the whole workday i only stepped in to correct the Your use of sshfs# as a FUSE type is wrong which at least should have been is deprecated at least as long the mount command comes with this: [root@srv-rhsoft:~]$ mount.fuse --help usage: mount.fuse type#[source] destination [-t type] [-o opt[,opts...]] signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstab Mounts Not Getting Waken Up
On Fri, Jul 12, 2013 at 07:25:04AM -0700, cac...@quantum-sci.com wrote: Lennart Poettering: On Thu, 11.07.13 12:57, cac...@quantum-sci.com (cac...@quantum-sci.com) wrote: I'd understood that if a mount is in fstab, that it should be re-established when the system wakes. But that's not happening. Meaning two sshfs mounts as so: sshfs#carl@droog:/ /media/droogfuse user,auto,_netdev,gid=6,umask=007,cache=no,ServerAliveInterval=15,allow_other,comment=sshfs 0 0 Why would this be? Entries in /etc/fstab that are listed as auto will be mounted at boot, that's all. Not entirely sure what you are referring to as wake? systemd resumes from suspend? I agree, that is how it is -supposed- to work, but as you can see it does not. Yes, when the system wakes from suspend, the drive is never mounted. Resume is not boot. -- Tomasz Torcz RIP is irrevelant. Spoofing is futile. xmpp: zdzich...@chrome.pl Your routes will be aggreggated. -- Alex Yuriev ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevadm settle hangs due to veths in seperate network namespaces
On Fri, Jul 12, 2013 at 06:00:42PM +0200, Kay Sievers wrote: On Fri, Jul 12, 2013 at 5:00 PM, Daniel P. Berrange berra...@redhat.com wrote: On Fri, Jul 12, 2013 at 02:51:10PM +0100, Daniel P. Berrange wrote: We're hitting a problem in libvirt where 'udevadm settle' will get stuck in a loop until it eventually times out. Eventually we realized this happens when we have any LXC containers active with veth devices in a separate network namespace. Incidentally, I recall reading something by (iirc) Lennart saying that apps really should use 'udevadm settle' at all.\ You mean *not*, I guess. Opps. yes. There are still valid uses of settle for command line tools, and that will be likely valid in the future too. There is no simple replacement for this barrier to be implemented by simple command line tools. Letting then subscribe to hotplug would ask for too much in quite a few cases. No advanced subsystem or service though should rely or model around settle and make assumptions about everything is there now, tools should subscribe to udev events and after that enumerate the current devices. Things that pull-in settle at bootup are kind of broken, that is the aspect of seetle you heard from Lennart rightfully complaining, I guess. Libvirt uses it in a couple of places, all related to code which obtains lists of storage devices Which makes sense according to the current state of affairs. Storage tools are only slowly catching up with the reality of devices coming and going all the time on today's systems. They get fixed, and things look at least better today than they have been, but settle is still needed for some operations. - After adding a disk partition in parted, we use it to wait for the /dev/sdXXNNN device nodes to all show up Primary device node creation (not symlinks) is synchronous since a couple of years. Devtmps does that for us. The ioctl to add a part table entry, re-read the part table will not return until devtmpfs has created the device nodes. The udev symlinks though might only be available after a settle call. - After logging into an iscsi target with iscsiadm, we use it to wait for all the /dev/sdXXX devices nodes associated with the iSCSI target to appear. - After triggering a SCSI HBA rescan via sysfs, we use it to wait for all the /dev/sdXXX devices nodes associated with the SCI HBA to appear - After creating an NPIV virtual HBA via sysfs, we use it to wait for all the /dev/sdXXX devices nodes associated with the vHBA to appear As said, this should all be covered on more recent systems. - After activating an LVM volume group, we use it to wait for all the /dev/VGNAME/ device nodes to appear - After deleting an LVM volume we use it to wait for the device node to be removed - After adding an LVM volume we use it to wait for the device node to be added LVM is a story on its own, it's pretty complex, and it slowly gets fixed over time. With the very recent changes it might integrate nicer now. I guess there are still situations though where settle is needed and the simplest solution. All of that applies only to the command line tools again, not for bootup related services, or full-blown storage management services. It is not ok for them to relay on settle. You can see a pattern there - after doing some action related to storage, we need to synchronize wrt the creation/deletion of device nodes in /dev, otherwise we miss out LUNs when we scan for the list of device nodes associated with a HBA/VolGroup/etc. Any suggestions for alternative techniques / approaches here ? I think it's fine and is needed for libvirt to use settle. At least as long as it calls the command line tools. There is no generally available storage interface on Linux which would solve all these problems for libvirt, and I don't think you should declare these problems as libvirt problems. Using settle to get a barrier for the tools you need to use which themselves cannot handle async setup and hotplug sounds fine to me. Many of the issues though might already be history with devtmpfs, at least when the primary nodes (and not the symlinks) are used. Unfortunately we do make use of the /dev/disk/by- paths in order to get paths which are stable across hosts and/or reboots, but not always. So perhaps I'll look at avoiding use of 'settle' in cases where we don't need the symlinks the commands are synchronous. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org
Re: [systemd-devel] fstab Mounts Not Getting Waken Up
Dave Reisner: On Fri, Jul 12, 2013 at 05:46:37PM +0200, Reindl Harald wrote: Your use of sshfs# as a FUSE type is wrong -- you must use fuse.sshfs as the fstype instead. this simply wrong, this line below in /etc/fstab works day and night from FC9 to Fedora 18 as well as curlftpsfs mounts in /etc/fstab are starting with curlftpfs# and *both* have fuse and nothing else as fstype sshfs#reindl@webserver:/ /mnt/webserver fuse noauto,user,rw,noexec,nosuid,nodev,uid=harry the server is a simple openssh on F17 with native sftp-chroot I direct you to mount(8): The programs mount and umount support filesystem subtypes. The subtype is defined by '.subtype' suffix. For example 'fuse.sshfs'. It's recommended to use subtype notation rather than add any prefix to the mount source (for example 'sshfs#example.com' is deprecated). You must not actually be -using- this, as it simply does not work, as I say. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstab Mounts Not Getting Waken Up
2013/7/12 cac...@quantum-sci.com: Reindl Harald: Your use of sshfs# as a FUSE type is wrong -- you must use fuse.sshfs as the fstype instead. this simply wrong, this line below in /etc/fstab works day and night from FC9 to Fedora 18 as well as curlftpsfs mounts in /etc/fstab are starting with curlftpfs# and *both* have fuse and nothing else as fstype sshfs#reindl@webserver:/ /mnt/webserver fuse noauto,user,rw,noexec,nosuid,nodev,uid=harry the server is a simple openssh on F17 with native sftp-chroot Reindl, thank goodness you're listening. Have you by chance, tried this with auto, to see whether it automounts on wake from suspend? systemd doesn't unmount the fs on suspend, why should it mount it on resume? Maybe you are mixing up what auto means. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shared: rename hasprefix() to startswith(), which is functionally identical and removed
On Fri, Jul 12, 2013 at 5:35 PM, Shawn Landden shawnland...@gmail.com wrote: as most (if not all) of the prefix strings are static, these will get forward constant propagation optimized into single memcmp() calls, which should be much better than the non-SIMD hand-rolled version. -#define hasprefix(s, prefix) (memcmp(s, prefix, strlen(prefix)) == 0) +#define startswith(s, prefix) (memcmp(s, prefix, strlen(prefix)) == 0) What if 's' is shorter than 'prefix'? We should not access the possibly uninitialized memory? Also there are users like: e = startswith() which rely on the returned offset. That would go wrong now, right? I guess we need a smarter version of startswith, maybe one that behaves different for const values and uses __builtin_constant_p logic to compile-time optimize it. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstab Mounts Not Getting Waken Up
Tomasz Torcz: Second, the solution. The functionality you want is provide by ”automount”. When using fstab, you can use the handy shortcut of putting ”x-systemd.automount” in your fstab. Best replace your ”auto” with ”x-systemd.automount”. For details, see man systemd.mount. Thank you. I'll check this out. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kmod-static-nodes.service doesn't care about udev?
On Fri, 12.07.13 09:28, Oleksii Shevchuk (alx...@gmail.com) wrote: Latest innovation with kmod-static-nodes.service introduce next issues with 1. default distro paths 2. interacting with rest configuration So, what is the problem. kmod-static-nodes.service.in: ExecStartPre=/usr/bin/mkdir -p /run/tmpfiles.d Hmm, why do we need this at all? Where the service file located? Couldn't find it in the kmod repo? Would like to have a look. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] travis: Add a travis.yml for doing CI after commits
On Tue, 09.07.13 18:09, Holger Hans Peter Freyther (hol...@freyther.de) wrote: From: Holger Hans Peter Freyther hol...@moiji-mobile.com Instruct travis-ci to build systemd and create a tarball. In case of an error travis-ci will complain on IRC. The systemd testsuite currently requires the host to have a recent version of systemd installed and running. This is not the case for the Ubuntu VM of travis-ci. This means make check and make distcheck will result in a build failure and to avoid this these commands are not executed. This requires a one time configuration on travis-ci for the repo on github by the owner of the repo. Commited. I figure this will not be useful right-away, since current git of systemd requires a very new version of kmod that is not available at Travis. However, it's still a good thing to have and to enable as soon as that issue is solved. BTW, I am totally happy if our tests get fixed (or even skipped) to not require a systemd running. It's simply that on our own machines we never have these issues, and that's where we run make check most of the time. I figure a simple if (sd_booted() = 0) return EXIT_TEST_SKIP; at the top of the tests in question would already be a big step forward. And then we could work on enabling more tests as things go. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kmod-static-nodes.service doesn't care about udev?
On Fri, Jul 12, 2013 at 07:08:48PM +0200, Lennart Poettering wrote: On Fri, 12.07.13 09:28, Oleksii Shevchuk (alx...@gmail.com) wrote: Latest innovation with kmod-static-nodes.service introduce next issues with 1. default distro paths 2. interacting with rest configuration So, what is the problem. kmod-static-nodes.service.in: ExecStartPre=/usr/bin/mkdir -p /run/tmpfiles.d Hmm, why do we need this at all? Where the service file located? Couldn't find it in the kmod repo? Would like to have a look. units/kmod-static-nodes.service.in :) I see another problem: in a container, this unit fails with: # /usr/bin/kmod static-nodes --format=tmpfiles --output=/run/tmpfiles.d/kmod.conf Error: could not open /lib/modules/3.9.6-301.fc19.x86_64/modules.devname - No such file or directory There was no requirement to have the kernel installation available before, and it'd be stupid to add it just for that. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kmod-static-nodes.service doesn't care about udev?
On Fri, 12.07.13 19:57, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Fri, Jul 12, 2013 at 07:08:48PM +0200, Lennart Poettering wrote: On Fri, 12.07.13 09:28, Oleksii Shevchuk (alx...@gmail.com) wrote: Latest innovation with kmod-static-nodes.service introduce next issues with 1. default distro paths 2. interacting with rest configuration So, what is the problem. kmod-static-nodes.service.in: ExecStartPre=/usr/bin/mkdir -p /run/tmpfiles.d Hmm, why do we need this at all? Where the service file located? Couldn't find it in the kmod repo? Would like to have a look. units/kmod-static-nodes.service.in :) Oh, humm, does the unit file really belong in systemd? Sounds like something that should be in kmod, no? And I don't really like that we need to invoke /usr/bin/mkdir first... I'd prefer if kmod could do that on its own when creating the file? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kmod-static-nodes.service doesn't care about udev?
On Fri, Jul 12, 2013 at 7:08 PM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 12.07.13 09:28, Oleksii Shevchuk (alx...@gmail.com) wrote: Latest innovation with kmod-static-nodes.service introduce next issues with 1. default distro paths 2. interacting with rest configuration So, what is the problem. kmod-static-nodes.service.in: ExecStartPre=/usr/bin/mkdir -p /run/tmpfiles.d Hmm, why do we need this at all? We want to be able to install systemd-tmpfiles configuration files to /run before running systemd-tmpfiles, so the folder must be created manually (unless we want to do this special-case explicitly somewhere else?). FWIW, this is what happens: mkdir -p /run/tmpfiles.d kmod static-nodes --format=tmpfiles --output=/run/tmpfiles.d/kmod.conf systemd-tmpfiles --prefix=/dev --create Where the service file located? http://cgit.freedesktop.org/systemd/systemd/tree/units/kmod-static-nodes.service.in -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kmod-static-nodes.service doesn't care about udev?
On Fri, Jul 12, 2013 at 08:16:51PM +0200, Lennart Poettering wrote: On Fri, 12.07.13 19:57, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Fri, Jul 12, 2013 at 07:08:48PM +0200, Lennart Poettering wrote: On Fri, 12.07.13 09:28, Oleksii Shevchuk (alx...@gmail.com) wrote: Latest innovation with kmod-static-nodes.service introduce next issues with 1. default distro paths 2. interacting with rest configuration So, what is the problem. kmod-static-nodes.service.in: ExecStartPre=/usr/bin/mkdir -p /run/tmpfiles.d Hmm, why do we need this at all? Where the service file located? Couldn't find it in the kmod repo? Would like to have a look. units/kmod-static-nodes.service.in :) Oh, humm, does the unit file really belong in systemd? Sounds like something that should be in kmod, no? As far as I understand, systemd here is a consumer of a service provided by kmod (the ability to write something in our tmpfiles.d format). And kmod is used by/for udevd. So it seems to fit in systemd. And I don't really like that we need to invoke /usr/bin/mkdir first... I'd prefer if kmod could do that on its own when creating the file? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd config recipes for namespace-isolated webapps
On Wed, 03.07.13 11:47, Martin Langhoff (martin.langh...@gmail.com) wrote: On Wed, Jul 3, 2013 at 10:49 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: - How do I tell several services to use the same cg? They can't all use the same cg, because systemd uses groups to group units. But they can share a slice of resources, by assigning a group of services to the same systemd .slice. This part is currently in fast development, but should be usable already. In F19 / systemd v209, is there any usable way to have slices or something resembling them? No, this will only be in F20. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kmod-static-nodes.service doesn't care about udev?
On Fri, Jul 12, 2013 at 7:57 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: I see another problem: in a container, this unit fails with: # /usr/bin/kmod static-nodes --format=tmpfiles --output=/run/tmpfiles.d/kmod.conf Error: could not open /lib/modules/3.9.6-301.fc19.x86_64/modules.devname - No such file or directory There was no requirement to have the kernel installation available before, and it'd be stupid to add it just for that. Except for the failed unit, this doesn't cause any other problems, right? It used to be that the missing modules.devname file would be silently ignored. I guess we could go back to doing that. We just have to decide if we should ignore the error in kmod or just in the unit file. I'm tempted to make the change in kmod, so that if no kernel is found it does nothing and returns success. Thoughts? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kmod-static-nodes.service doesn't care about udev?
On Fri, 12.07.13 20:33, Tom Gundersen (t...@jklm.no) wrote: On Fri, Jul 12, 2013 at 8:16 PM, Lennart Poettering lenn...@poettering.net wrote: Oh, humm, does the unit file really belong in systemd? Sounds like something that should be in kmod, no? I don't have a strong opinion about where the unit should live. As far as I remember Lucas requested I put it in systemd, but I forgot now what his rationale was. Lucas? Well, Zbigniew made a good point, and there are other cases where we ship a unit file for something that is maintained outside of systemd, so maybe leave it as is... And I don't really like that we need to invoke /usr/bin/mkdir first... I'd prefer if kmod could do that on its own when creating the file? Sure, could do. Just out of interest, why do you prefer it that way? Forking sucks... I like the simplicity of having one-liners in unit files, if you get what i mean... And it sounds so wrong having to invoke mkdir for a dir in /run exlicitly when prepping for a tool that, well, is mostly concerned with creating dirs in /run. I'd rather prefer to hide that fact... ;-) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kmod-static-nodes.service doesn't care about udev?
On Fri, 12.07.13 20:37, Tom Gundersen (t...@jklm.no) wrote: On Fri, Jul 12, 2013 at 7:57 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: I see another problem: in a container, this unit fails with: # /usr/bin/kmod static-nodes --format=tmpfiles --output=/run/tmpfiles.d/kmod.conf Error: could not open /lib/modules/3.9.6-301.fc19.x86_64/modules.devname - No such file or directory There was no requirement to have the kernel installation available before, and it'd be stupid to add it just for that. Except for the failed unit, this doesn't cause any other problems, right? It used to be that the missing modules.devname file would be silently ignored. I guess we could go back to doing that. Maybe add a condition check for it? Might be hard with the with kernel version in the path, but we could add a %v or so for this which resolves to the output of uname -r. Which could be really useful anyway, wherever things are done with kernels, initrds, modules? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/3 (rebased)] cryptsetup: Add tcrypt support
On 07/12/2013 08:36 PM, Lennart Poettering wrote:
On Tue, 09.07.13 21:15, Jan Janssen (medhe...@web.de) wrote:
+if (*key_file) {
+r = read_one_line_file(*key_file, passphrase);
+if (r 0) {
+log_error(Failed to read key file: %s, strerror(-r));
+*key_file = NULL;
+return -EAGAIN;
I can't say I like functions that change the parameters when they fail,
any chance we can fix that?
otherwise looks good.
Lennart
When I read the (old) luks code correctly, it does the same: falling
back to normal password query if the key file does not work. I just
thought it would be best to do the same here.
I can certainly make this a fatal error, so no retries are attempted,
but then the luks code should do the same, imho. What do you think?
Jan
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Dynamic locale changes with localed
On Tue, 02.07.13 21:42, Tristan Van Berkom (trista...@openismus.com) wrote: Hello Mailing List. I have a quick question about the org.freedesktop.locale1 interface. I've been working on some locale bound addressbook features for Evolution Data Server, and we wanted a feature to handle locale changes dynamically. To handle this, we thought for starters it would be a good idea to listen for 'Locale' property changes on the interface defined here: http://www.freedesktop.org/wiki/Software/systemd/localed This seems to work well but I've only tested receiving the locale changes so far (using GTestDBus in an encapsulated D-Bus environment... which we use in unit tests). Now that we're trying this in a running system, we're encountering some problems (or, the functionality is perhaps just not exactly what we expected). When calling the 'SetLocale' D-Bus method on the said interface, there is some latency, and I wonder if the values are policed somehow by the localed daemon (specifically, when setting some locales, the following 'Locale' property change notifications sends the 'C' locale instead of the locale which we set). Hmm, that sounds like a bug. Could you file one on fdo? Normally the event should happen instantaneous. There might be some cleaning up of passed in locales (especially regarding the empty locale, and C), but what you oass in should be applied. See simplify() in http://cgit.freedesktop.org/systemd/systemd/tree/src/locale/localed.c#n173 The locale handling is here: http://cgit.freedesktop.org/systemd/systemd/tree/src/locale/localed.c#n995 The only thing that might cause a delay in there is the polkit interaction? Are there any constraints to what values are acceptable to pass to 'SetLocale' ? Perhaps the locale data for a given locale must be installed on the said system to be accepted by (and then propagated) localed ? We do not do such checking for installed locales, but we probably should, and this has been requested before. Perhaps there is some latency only to synchronize the setting into some database ? Not really. The bus signal should come immediately after the polkit transaciton. Of course, system services see the locale change after they are restarted. And user programs only after the user logged out/back in -- if at all, because the DE overrides the system setting. Is there any information (or documentation) regarding how the localed daemon is expected to work which could help us test our dynamic locale changes ? There is this: http://www.freedesktop.org/wiki/Software/systemd/localed/ And that's it. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] condition: add ConditionFileContains=
On 07/12/2013 03:40 PM, Kay Sievers wrote: On Fri, Jul 12, 2013 at 3:31 PM, Lennart Poettering lenn...@poettering.net wrote: ConditionFileContains=/sys/module/sn/parameters/enabled:1 To make this clear: I am not keen on adding this. I can see the usefulness, and the thing is still simple enough so that it would be OK to add this, but if you guys don't actually need that I'd prefer to keep our codebase smaller... We can workaround this one way or another - be it shell script, udev rule or, in some cases, generator. Patch that started this discussion is yet another option. I have looked into /etc/init.d on my Debian system and found following examples of 'grepping' files used to decide if given service should be started or not: - kernel option specified - /proc/cmdline - filesystem available - /proc/filesystems - file contains non commented out lines - /etc/exports - cpu features available - /proc/cpuinfo - software raid (md) status - /proc/mdstat - ... Every such case could be handled by generic built-in grep instead of dozen of flags like ConditionCPUFeature=, ConditionMDStatus=, ... Having said that I fully understand that the line has to be drawn somewhere. [1] Such condition should probably support globs so we would end up with something like ConditionFileContentsGlob= Just a note: The above example should be triggered by a udev rule anyway. Agreed. Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kmod-static-nodes.service doesn't care about udev?
On Fri, Jul 12, 2013 at 8:42 PM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 12.07.13 20:37, Tom Gundersen (t...@jklm.no) wrote: On Fri, Jul 12, 2013 at 7:57 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: I see another problem: in a container, this unit fails with: # /usr/bin/kmod static-nodes --format=tmpfiles --output=/run/tmpfiles.d/kmod.conf Error: could not open /lib/modules/3.9.6-301.fc19.x86_64/modules.devname - No such file or directory There was no requirement to have the kernel installation available before, and it'd be stupid to add it just for that. Except for the failed unit, this doesn't cause any other problems, right? It used to be that the missing modules.devname file would be silently ignored. I guess we could go back to doing that. Maybe add a condition check for it? Might be hard with the with kernel version in the path, but we could add a %v or so for this which resolves to the output of uname -r. Which could be really useful anyway, wherever things are done with kernels, initrds, modules? I agree that %v sounds useful in general. I'm not sure I like it for this purpose though, as ideally modules.devname (and the location of /lib/modules for that matter) should eventually become entirely internal to kmod. I'll post a patch to the kmod ML to gather some feedback on just turning kmod static-nodes into a noop when no kernel is found. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] list-unit-files does not show generated units
On Sun, 30.06.13 21:58, Andrey Borzenkov (arvidj...@gmail.com) wrote: Is it intentional? This could be quite confusing when trying to debug problems involving generated units. No, not intentional, just forgotten... Added to the TODO list now. We probably should show it along with a specific state for it as generated. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/3 (rebased)] cryptsetup: Add tcrypt support
On Fri, 12.07.13 20:48, Jan Janssen (medhe...@web.de) wrote:
On 07/12/2013 08:36 PM, Lennart Poettering wrote:
On Tue, 09.07.13 21:15, Jan Janssen (medhe...@web.de) wrote:
+if (*key_file) {
+r = read_one_line_file(*key_file, passphrase);
+if (r 0) {
+log_error(Failed to read key file: %s,
strerror(-r));
+*key_file = NULL;
+return -EAGAIN;
I can't say I like functions that change the parameters when they fail,
any chance we can fix that?
otherwise looks good.
Lennart
When I read the (old) luks code correctly, it does the same: falling
back to normal password query if the key file does not work. I just
thought it would be best to do the same here.
I am all for falling back to normal password query if the file does not
exist, however, I don't like the programming style where you alter
pass-by-reference parameters of function when failing.
Changing pass-by-ref parameters on success is a good way to return data,
but I think it is generally a bad idea to alter pass-by-ref params if
you fail.
So, this is not a question of general behaviour of the tool, but only of
the coding style.
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH] condition: add ConditionFileContains=
On Fri, 12.07.13 20:42, Karol Lewandowski (k.lewando...@samsung.com) wrote: On Fri, Jul 12, 2013 at 3:31 PM, Lennart Poettering lenn...@poettering.net wrote: ConditionFileContains=/sys/module/sn/parameters/enabled:1 To make this clear: I am not keen on adding this. I can see the usefulness, and the thing is still simple enough so that it would be OK to add this, but if you guys don't actually need that I'd prefer to keep our codebase smaller... We can workaround this one way or another - be it shell script, udev rule or, in some cases, generator. Patch that started this discussion is yet another option. I have looked into /etc/init.d on my Debian system and found following examples of 'grepping' files used to decide if given service should be started or not: - kernel option specified - /proc/cmdline We have ConditionKernelCommandLine= for this case, and it is a bit more powerful. - filesystem available - /proc/filesystems This sounds like something one could also do with ConditionPathExists= checking for some module in /sys/module/ or so. - file contains non commented out lines - /etc/exports It's probably a better idea to simply not ship that file by default. That's how we handle the rc.boot case. - cpu features available - /proc/cpuinfo We have CPU feature based kernel module auto-loading these days, which makes pretty much all of these cases where this was necessary redundant. If the modules are auto-loaded where needed it is afterrwards sufficient to check for /sys/module/ for the functionality... - software raid (md) status - /proc/mdstat Not sure what this is really doing... - ... Every such case could be handled by generic built-in grep instead of dozen of flags like ConditionCPUFeature=, ConditionMDStatus=, ... I am pretty sure we cover most of these cases with some other way too. I mean, I am generally willing to add this, but if there's no strict need for it, I'd avoid it. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] travis: Add a travis.yml for doing CI after commits
On Fri, Jul 12, 2013 at 07:51:26PM +0200, Lennart Poettering wrote: On Tue, 09.07.13 18:09, Holger Hans Peter Freyther (hol...@freyther.de) wrote: I figure a simple if (sd_booted() = 0) return EXIT_TEST_SKIP; Ah great, I had planned to search if something like sd_booted() exists, skipping the tests will be trivial now. thanks holger ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] journalctl: have a useful --setup-keys error message when using non-persistant logging
Generating seed...
Generating key pair...
Generating sealing key...
Failed to open
/var/log/journal/33f46101703a10c5fc6fa4f451840101/fss.tmp.k2wDDU: No such file
or directory
---
src/journal/journalctl.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
index 7baea23..458d80d 100644
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -725,6 +725,23 @@ static int setup_keys(void) {
char *p = NULL, *k = NULL;
struct FSSHeader h;
uint64_t n;
+stat st;
+
+r = stat(/var/log/journal, st);
+if (r 0) {
+if (errno == ENOENT || errno == ENOTDIR) {
+log_error(%s is not a directory, must be using
persistant logging for FSS: %s, /var/log/journal, strerror(errno));
+return -errno;
+} else {
+log_error(stat(\%s\) failed: %m,
/var/log/journal);
+return -errno;
+}
+}
+
+if (!S_ISDIR(st.st_mode)) {
+log_error(%s is not a directory, must be using persistant
logging for FSS: %s, /var/log/journal, strerror(ENOTDIR));
+return -ENOTDIR;
+}
r = sd_id128_get_machine(machine);
if (r 0) {
--
1.8.3.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
