Re: [systemd-devel] [PATCH v3 01/26] dhcp: Add DHCP protocol structures and initial defines
On Tue, 2013-12-10 at 18:48 +0100, Lennart Poettering wrote: I agree with Zbigniew: this should probably be in src/libsystemd-dhcp/, so that this is similar to libsystemd-bus/, libsystemd-id128/ and so on... Sent a patch for that, and in the process of creating an account on freedesktop.org. As that will most probably take some time, someone with proper access could bite the bullet... Cheers, Patrik ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] No security on systemd-journal-gatewayd
On 12/12/2013 05:20 AM, Kay Sievers wrote: On Wed, Dec 11, 2013 at 11:53 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 11.12.2013 22:41, schrieb Cecil Westerhof: I tried out systemd-journal-gatewayd. But it looks like that everyone that can contact, can get log info. Is that true, or am I overlooking something? as far as i remeber from older posts about it the intention is that a) it is not on by default b) if you turn it on you need to open the port in the firewall too c) if you open the port you do this only for trusted sources The current implementation is more a proof-of-concept, not used or enabled by default. It has zero built-in security, it cannot be used or enabled in untrusted environments without externally provided protection. OK, clear. Is there a timetable for a ‘full’ implementation? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question regarding the NotifyAccess parameter
I think my system had a bit older minor version of systemd ( systemd-204-8.fc19.x86_64 ). In another system I have tested where I have systemd higher version - where the issue is not there - ( systemd-204-17.fc19.x86_64 ). Thanks Salil On 11 December 2013 06:15, salil GK gksa...@gmail.com wrote: Thanks Lennart for the reply. The issue that I am facing is with the restart feature of systemd. I have configured my unit file as Restart=on-failure when the service fail to send watchdog signal the expectation is - systemd will restart the service. what I observed is - systemd started one more service rather than restarting. my previous mail describe what exactly I see in the console. If you need any more clarification I will provide. Thanks and regards Salil On 11 December 2013 04:55, Lennart Poettering lenn...@poettering.netwrote: On Mon, 09.12.13 09:47, salil GK (gksa...@gmail.com) wrote: Hello did any body get a chance to look into this. I am a kind of stuck on this. I can work around using ExecStartPre script where I can kill the previous instances. But if systemd is capable to do it by itself, that would be the neat solution. Hmm, the mail you pasted and the archives do not really give me any hint what your the problem you are trying to solve is? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] bus: Add support for eavesdrop in sd_bus_add_match()
Due to this patch, 'busctl monitor' prints all method calls,
method errors and signals both for dbus and kdbus.
---
src/libsystemd-bus/bus-control.c | 6 ++
src/libsystemd-bus/bus-match.c | 10 ++
src/libsystemd-bus/bus-match.h | 1 +
src/libsystemd-bus/busctl.c | 2 +-
4 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/src/libsystemd-bus/bus-control.c b/src/libsystemd-bus/bus-control.c
index 2682439..525e452 100644
--- a/src/libsystemd-bus/bus-control.c
+++ b/src/libsystemd-bus/bus-control.c
@@ -958,6 +958,12 @@ static int bus_add_match_internal_kernel(
}
break;
+case BUS_MATCH_EAVESDROP:
+if (streq(c-value_str, true)) {
+bus_kernel_monitor(bus);
+}
+break;
+
case BUS_MATCH_ARG...BUS_MATCH_ARG_LAST: {
char buf[sizeof(arg)-1 + 2 + 1];
diff --git a/src/libsystemd-bus/bus-match.c b/src/libsystemd-bus/bus-match.c
index f7fca5f..3da401c 100644
--- a/src/libsystemd-bus/bus-match.c
+++ b/src/libsystemd-bus/bus-match.c
@@ -163,6 +163,7 @@ static bool value_node_test(
case BUS_MATCH_INTERFACE:
case BUS_MATCH_MEMBER:
case BUS_MATCH_PATH:
+case BUS_MATCH_EAVESDROP:
case BUS_MATCH_ARG ... BUS_MATCH_ARG_LAST:
return streq_ptr(node-value.str, value_str);
@@ -203,6 +204,7 @@ static bool value_node_same(
case BUS_MATCH_INTERFACE:
case BUS_MATCH_MEMBER:
case BUS_MATCH_PATH:
+case BUS_MATCH_EAVESDROP:
case BUS_MATCH_ARG ... BUS_MATCH_ARG_LAST:
case BUS_MATCH_ARG_NAMESPACE ... BUS_MATCH_ARG_NAMESPACE_LAST:
case BUS_MATCH_PATH_NAMESPACE:
@@ -310,6 +312,9 @@ int bus_match_run(
test_str = m-path;
break;
+case BUS_MATCH_EAVESDROP:
+break;
+
case BUS_MATCH_ARG ... BUS_MATCH_ARG_LAST:
test_str = bus_message_get_arg(m, node-type - BUS_MATCH_ARG);
break;
@@ -590,6 +595,8 @@ enum bus_match_node_type
bus_match_node_type_from_string(const char *k, size_t n
return BUS_MATCH_PATH;
if (n == 14 startswith(k, path_namespace))
return BUS_MATCH_PATH_NAMESPACE;
+if (n == 9 startswith(k, eavesdrop))
+return BUS_MATCH_EAVESDROP;
if (n == 4 startswith(k, arg)) {
int j;
@@ -949,6 +956,9 @@ const char* bus_match_node_type_to_string(enum
bus_match_node_type t, char buf[]
case BUS_MATCH_PATH_NAMESPACE:
return path_namespace;
+case BUS_MATCH_EAVESDROP:
+return eavesdrop;
+
case BUS_MATCH_ARG ... BUS_MATCH_ARG_LAST:
snprintf(buf, l, arg%i, t - BUS_MATCH_ARG);
return buf;
diff --git a/src/libsystemd-bus/bus-match.h b/src/libsystemd-bus/bus-match.h
index 1d38126..17b50cb 100644
--- a/src/libsystemd-bus/bus-match.h
+++ b/src/libsystemd-bus/bus-match.h
@@ -38,6 +38,7 @@ enum bus_match_node_type {
BUS_MATCH_MEMBER,
BUS_MATCH_PATH,
BUS_MATCH_PATH_NAMESPACE,
+BUS_MATCH_EAVESDROP,
BUS_MATCH_ARG,
BUS_MATCH_ARG_LAST = BUS_MATCH_ARG + 63,
BUS_MATCH_ARG_PATH,
diff --git a/src/libsystemd-bus/busctl.c b/src/libsystemd-bus/busctl.c
index 57bc83d..5f86e0d 100644
--- a/src/libsystemd-bus/busctl.c
+++ b/src/libsystemd-bus/busctl.c
@@ -206,7 +206,7 @@ static int monitor(sd_bus *bus, char *argv[]) {
}
if (!added_something) {
-r = sd_bus_add_match(bus, , NULL, NULL);
+r = sd_bus_add_match(bus, eavesdrop='true', NULL, NULL);
if (r 0) {
log_error(Failed to add match: %s, strerror(-r));
return r;
--
1.8.3.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3 01/26] dhcp: Add DHCP protocol structures and initial defines
Hi Patrik, I agree with Zbigniew: this should probably be in src/libsystemd-dhcp/, so that this is similar to libsystemd-bus/, libsystemd-id128/ and so on... Sent a patch for that, and in the process of creating an account on freedesktop.org. As that will most probably take some time, someone with proper access could bite the bullet... I will take care of getting these patches committed. Can you just send an updated version with everything in place in the right location. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] dhcp: Move src/dhcp to src/libsystemd-dhcp
Hi Patrik, --- Makefile.am | 42 +- src/dhcp/Makefile |1 - src/dhcp/client.c | 1002 - src/dhcp/internal.h | 41 - src/dhcp/network.c| 65 -- src/dhcp/option.c | 184 src/dhcp/protocol.h | 119 --- src/dhcp/test-dhcp-client.c | 224 - src/dhcp/test-dhcp-option.c | 377 src/libsystemd-dhcp/Makefile |1 + src/libsystemd-dhcp/client.c | 1002 + src/libsystemd-dhcp/internal.h| 41 + src/libsystemd-dhcp/network.c | 65 ++ src/libsystemd-dhcp/option.c | 184 src/libsystemd-dhcp/protocol.h| 119 +++ src/libsystemd-dhcp/test-libsystemd-dhcp-client.c | 224 + src/libsystemd-dhcp/test-libsystemd-dhcp-option.c | 377 17 files changed, 2034 insertions(+), 2034 deletions(-) delete mode 12 src/dhcp/Makefile delete mode 100644 src/dhcp/client.c delete mode 100644 src/dhcp/internal.h delete mode 100644 src/dhcp/network.c delete mode 100644 src/dhcp/option.c delete mode 100644 src/dhcp/protocol.h delete mode 100644 src/dhcp/test-dhcp-client.c delete mode 100644 src/dhcp/test-dhcp-option.c create mode 12 src/libsystemd-dhcp/Makefile create mode 100644 src/libsystemd-dhcp/client.c create mode 100644 src/libsystemd-dhcp/internal.h create mode 100644 src/libsystemd-dhcp/network.c create mode 100644 src/libsystemd-dhcp/option.c create mode 100644 src/libsystemd-dhcp/protocol.h create mode 100644 src/libsystemd-dhcp/test-libsystemd-dhcp-client.c create mode 100644 src/libsystemd-dhcp/test-libsystemd-dhcp-option.c instead of moving everything around after the fact, I would say we better start off with a clean patch set and everything in the right spot in the first place. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] Initial libsystemd-asyncns commit
Hi Lennart, why do we have to spawn threads or do forks for DNS. This looks all pretty expensive. In ConnMan for example we just wrote our own async DNS using a mainloop. Works perfectly fine and is dirt cheap. Well, we don't fork threads/processes for each call but reuse them. What libasyncns does what your solution doesn't do is go via NSS. This means /etc/hosts, nss-myhostname, nss-ldap, nss-mdns and so on just work, while that all is lost when doing DNS natively. I am pretty sure we should not bypass NSS for this. actually NSS for DNS is pretty nasty stuff. I am pretty sure we should bypass it and create a proper implementation. Is anybody actually using NIS or LDAP for domain name resolution? The problem with NSS is that it still does not fix the fundamental problem. It is sequential and blocking. You can spawn as many threads as you want and it will stay sequential. I fully agree with you that we need to consider /etc/hosts, the local hostname and also mDNS, but I get the feeling it would be more beneficial to just build that in. ConnMan ships a DNS proxy cache to actually be able to be smart and parallel. We did not bother with the details like /etc/hosts so far since our use cases always had an empty /etc/hosts with just localhost only anyway. However that is easy to fix. Spawning threads or forking is expensive (even if you reuse it) comparing to what you actually do here. You just want to resolve a host. It is especially expensive since you can not control on what is actually used. And there are clearly use cases where you have to ask a specific nameserver or set of nameservers. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/3] journal: Try to pass log via /dev/shm to avoid waking up journal
Enabled by default for test purposes.
---
src/journal/journal-send.c | 39 +++
1 file changed, 39 insertions(+)
diff --git a/src/journal/journal-send.c b/src/journal/journal-send.c
index 281e154..9c4acc2 100644
--- a/src/journal/journal-send.c
+++ b/src/journal/journal-send.c
@@ -196,6 +196,41 @@ finish:
return r;
}
+static int write_snippet(const struct iovec *iov, int n) {
+
+static const char dir[] = /dev/shm;
+char path[PATH_MAX]; /* FIXME */
+struct timespec ts;
+struct stat st;
+int fd;
+int r;
+
+if (stat(dir, st) 0 || !S_ISDIR(st.st_mode))
+return -1;
+
+do {
+clock_gettime(CLOCK_REALTIME, ts);
+snprintf(path, PATH_MAX, %s/journal-snippet.%lu.%lu, dir,
ts.tv_sec, ts.tv_nsec); /* FIXME */
+
+fd = open(path, O_WRONLY | O_CREAT | O_EXCL, S_IRUSR |
S_IWUSR);
+
+} while (fd 0 errno == EEXIST);
+
+if (fd 0)
+return -errno;
+
+r = writev(fd, iov, n);
+if (r 0)
+r = -errno;
+else
+r = 1;
+
+close_nointr_nofail(fd);
+
+return r;
+}
+
+
_public_ int sd_journal_sendv(const struct iovec *iov, int n) {
PROTECT_ERRNO;
int fd, buffer_fd;
@@ -289,6 +324,10 @@ _public_ int sd_journal_sendv(const struct iovec *iov, int
n) {
IOVEC_SET_STRING(w[j++], \n);
}
+/* Try to drop journald snippet for delayed processing */
+if (write_snippet(w, j) 0)
+return 0;
+
fd = journal_fd();
if (_unlikely_(fd 0))
return fd;
--
1.8.4.rc3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/3] journal-feeder: trivial test program to flood journald
This is not a systemd patch but simple test program I have used
for measurements.
---
journal-feeder.c | 64
1 file changed, 64 insertions(+)
create mode 100644 journal-feeder.c
diff --git a/journal-feeder.c b/journal-feeder.c
new file mode 100644
index 000..df7a7e4
--- /dev/null
+++ b/journal-feeder.c
@@ -0,0 +1,64 @@
+/* journal-feeder M N: send N-sized messages M-times a second
+ *
+ * Compile: $CC -o journal-feeder journal-feeder.c $(pkg-config --cflags
--libs libsystemd-journal)
+ */
+#include stdio.h
+#include stdlib.h
+#include string.h
+#include assert.h
+#include errno.h
+#include stdint.h
+
+#include sys/types.h
+#include time.h
+#include systemd/sd-journal.h
+
+#define NELEMS(arr) (sizeof(arr)/sizeof(arr[0]))
+
+#define SEC_TO_MSEC(n) (1000*(n))
+#define SEC_TO_USEC(n) (1000*(SEC_TO_MSEC(n)))
+#define SEC_TO_NSEC(n) (1000*(SEC_TO_USEC(n)))
+
+
+int main(int argc, char *argv[])
+{
+int m_per_sec = 0;
+int sz = 0;
+int n;
+char message[4096] = Oh my, this should make some sense to reader on
the other side...;
+struct timespec tv;
+
+
+if (argc != 3) {
+fprintf(stderr, usage: %s MSG_PER_SEC MSG_SIZE\n, argv[0]);
+exit(1);
+}
+m_per_sec = atoi(argv[1]);
+sz = atoi(argv[2]);
+
+assert(m_per_sec);
+assert(sz 0 sz NELEMS(message));
+
+n = strlen(message);
+if (sz n)
+memset(message + n, 'X', sz - n);
+message[sz] = 0;
+
+tv.tv_sec = 0;
+tv.tv_nsec = SEC_TO_NSEC(1) / m_per_sec;
+
+if (tv.tv_nsec == SEC_TO_NSEC(1))
+tv.tv_nsec -= 1;
+
+printf(will wait %d ns\n, tv.tv_nsec);
+
+for (;;) {
+sd_journal_send(MESSAGE=%s, message, PRIORITY=%i,
LOG_INFO, NULL);
+
+while (nanosleep(tv, NULL) == -1 errno == -EAGAIN)
+;
+
+}
+
+return 0;
+}
--
1.8.4.rc3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC] [PATCH 0/3] journal: Add deferred log processing to reduce synchonous IO overhead
Folks, We are trying to apply journald as default (and only) logging system for our ARM-based handhelds. There is one major problem, though - performance. We have found that journald can consume considerable amount of CPU time under moderate load (10-20% of CPU per, for say 100-300msg/s). We have profiled journald and there are few places that could benefit from _some_ optimizations but I have come to conclusion it isn't journald code that is real bottleneck - it's, or seems to be, synchronous nature of send()/recv(). In default configuration each send() can cause context-switch which is especially costly on ARM. This is why I decided to try to make logging completely async and see if/what changes. Following patchset (based on top of f20c84c15f3) implements pickup logic in journald [patch 1] and uncoditionally enables it in client api [patch 2]. In short - instead of sending DGRAMs I do drop files to /dev/shm which are then picked up by journald at specified intervals. (Precisely, I have (ab)used mechanism used to pass fd via DGRAM when message is too big.) Patch 3 contains standalone test program, which floods journald with specified number of messages per second. On my development (x86) machine I made following test with good old time(1): # send 2000 messages (each of size 100 bytes) to journal per second # for ~5mins ./journal-feeder 2000 100 sleep $((60*5 - 10)) kill $! Unpatched systemd: == /usr/bin/time --verbose ./systemd-journald sleep $((60*5)) kill $(pidof systemd-journald) User time (seconds): 16.87 System time (seconds): 39.38 Percent of CPU this job got: 18% Elapsed (wall clock) time (h:mm:ss or m:ss): 5:00.06 Major (requiring I/O) page faults: 30 Minor (reclaiming a frame) page faults: 1061740 Voluntary context switches: 496757 Involuntary context switches: 497 File system inputs: 0 File system outputs: 50592 Deferred pickup every 5 secs (logs passed via /dev/shm/FILE rather than DGRAMs): /usr/bin/time --verbose ./systemd-journald sleep $((60*5)) kill $(pidof systemd-journald) User time (seconds): 8.27 System time (seconds): 8.40 Percent of CPU this job got: 5% Elapsed (wall clock) time (h:mm:ss or m:ss): 5:00.36 Major (requiring I/O) page faults: 180 Minor (reclaiming a frame) page faults: 38976 Voluntary context switches: 157 Involuntary context switches: 1933 File system inputs: 8 File system outputs: 307312 Deferred pickup every 1 sec (logs passed via /dev/shm/FILE rather than DGRAMs): === /usr/bin/time --verbose ./systemd-journald sleep $((60*5)) kill $(pidof systemd-journald) User time (seconds): 9.54 System time (seconds): 9.56 Percent of CPU this job got: 6% Elapsed (wall clock) time (h:mm:ss or m:ss): 5:00.15 Major (requiring I/O) page faults: 180 Minor (reclaiming a frame) page faults: 39034 Voluntary context switches: 382 Involuntary context switches: 2359 File system inputs: 0 File system outputs: 307768 This is quite naive test as a far more changes when we pass fd instead of DGRAM (ucred is NULL, which means we won't gather information from proc at all). However, we verified that cost of this is rather minor and not that important in this test. Of course, I'm not proposing to include it as is (uncoditionally enable it for all messages) but I would just like to hear your opinion about this idea. If I read these numbers correctly there seems to be considerable benefit in terms of CPU time. Something like that wouldn't be useful for all messages, but I think that gazzilions of debug messages that our apps produce could be send in non-synchronous and low-overhead manner. RFC. Thanks in advance! Karol Lewandowski (3): journald: Add deferred log processing logic journal: Try to pass log via /dev/shm to avoid waking up journal journal-feeder: trivial test program to flood journald journal-feeder.c | 64 +++ src/journal/journal-send.c | 39 ++ src/journal/journald-gperf.gperf | 2 + src/journal/journald-server.c| 107 +++ src/journal/journald-server.h| 5 ++ src/journal/journald.conf| 2 + 6 files changed, 219 insertions(+) create mode 100644 journal-feeder.c -- 1.8.4.rc3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] logs-show.c: Fix missing sys/socket.h include
CC src/shared/logs-show.lo src/shared/logs-show.c: In function 'get_boot_id_for_machine': src/shared/logs-show.c:1153:9: warning: implicit declaration of function 'socketpair' [-Wimplicit-function-declaration] if (socketpair(AF_UNIX, SOCK_DGRAM, 0, sock) 0) ^ src/shared/logs-show.c:1153:24: error: 'AF_UNIX' undeclared (first use in this function) if (socketpair(AF_UNIX, SOCK_DGRAM, 0, sock) 0) ^ src/shared/logs-show.c:1153:24: note: each undeclared identifier is reported only once for each function it appears in src/shared/logs-show.c:1153:33: error: 'SOCK_DGRAM' undeclared (first use in this function) if (socketpair(AF_UNIX, SOCK_DGRAM, 0, sock) 0) ^ src/shared/logs-show.c:1179:17: warning: implicit declaration of function 'send' [-Wimplicit-function-declaration] k = send(sock[1], buf, 36, MSG_NOSIGNAL); ^ src/shared/logs-show.c:1179:44: error: 'MSG_NOSIGNAL' undeclared (first use in this function) k = send(sock[1], buf, 36, MSG_NOSIGNAL); ^ src/shared/logs-show.c:1189:9: warning: implicit declaration of function 'recv' [-Wimplicit-function-declaration] k = recv(sock[0], buf, 36, 0); ^ --- src/shared/logs-show.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/shared/logs-show.c b/src/shared/logs-show.c index c99fc7569429..0e3fd3de2630 100644 --- a/src/shared/logs-show.c +++ b/src/shared/logs-show.c @@ -23,6 +23,7 @@ #include assert.h #include errno.h #include sys/poll.h +#include sys/socket.h #include string.h #include fcntl.h -- 1.8.3.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] dhcp: Move src/dhcp to src/libsystemd-dhcp
On Thu, Dec 12, 2013 at 02:00:48PM +0100, Marcel Holtmann wrote: instead of moving everything around after the fact, I would say we better start off with a clean patch set and everything in the right spot in the first place. Hi Marcel, I have a local git-filter-tree-ed branch with the locations updated if made for testing. If Patrik doesn't have furhter updates, I'll push that today. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] Initial libsystemd-asyncns commit
В Thu, 12 Dec 2013 14:09:42 +0100 Marcel Holtmann mar...@holtmann.org пишет: Hi Lennart, why do we have to spawn threads or do forks for DNS. This looks all pretty expensive. In ConnMan for example we just wrote our own async DNS using a mainloop. Works perfectly fine and is dirt cheap. Well, we don't fork threads/processes for each call but reuse them. What libasyncns does what your solution doesn't do is go via NSS. This means /etc/hosts, nss-myhostname, nss-ldap, nss-mdns and so on just work, while that all is lost when doing DNS natively. I am pretty sure we should not bypass NSS for this. actually NSS for DNS is pretty nasty stuff. I am pretty sure we should bypass it and create a proper implementation. Is anybody actually using NIS or LDAP for domain name resolution? Yes, there are solutions that are using LDAP for hostname resolution quite heavily - actually are based around LDAP without any local /etc/hosts. The problem with NSS is that it still does not fix the fundamental problem. It is sequential and blocking. You can spawn as many threads as you want and it will stay sequential. I fully agree with you that we need to consider /etc/hosts, the local hostname and also mDNS, but I get the feeling it would be more beneficial to just build that in. ConnMan ships a DNS proxy cache to actually be able to be smart and parallel. We did not bother with the details like /etc/hosts so far since our use cases always had an empty /etc/hosts with just localhost only anyway. However that is easy to fix. Spawning threads or forking is expensive (even if you reuse it) comparing to what you actually do here. You just want to resolve a host. It is especially expensive since you can not control on what is actually used. And there are clearly use cases where you have to ask a specific nameserver or set of nameservers. Regards Marcel ___ 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] shared: add missing include
On Thu, Dec 12, 2013 at 01:56:13PM +0900, Marc-Antoine Perennou wrote: Needed for socketpair, recv --- src/shared/logs-show.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/shared/logs-show.c b/src/shared/logs-show.c index c99fc75..0e3fd3d 100644 --- a/src/shared/logs-show.c +++ b/src/shared/logs-show.c @@ -23,6 +23,7 @@ #include assert.h #include errno.h #include sys/poll.h +#include sys/socket.h #include string.h #include fcntl.h Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] logs-show.c: Fix missing sys/socket.h include
On Thu, Dec 12, 2013 at 05:17:27AM -0800, Marcel Holtmann wrote: diff --git a/src/shared/logs-show.c b/src/shared/logs-show.c index c99fc7569429..0e3fd3de2630 100644 --- a/src/shared/logs-show.c +++ b/src/shared/logs-show.c @@ -23,6 +23,7 @@ #include assert.h #include errno.h #include sys/poll.h +#include sys/socket.h #include string.h #include fcntl.h Marc-Antoine sent an identical patch, applied the other one. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] No security on systemd-journal-gatewayd
On Thu, 12.12.13 05:20, Kay Sievers (k...@vrfy.org) wrote: On Wed, Dec 11, 2013 at 11:53 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 11.12.2013 22:41, schrieb Cecil Westerhof: I tried out systemd-journal-gatewayd. But it looks like that everyone that can contact, can get log info. Is that true, or am I overlooking something? as far as i remeber from older posts about it the intention is that a) it is not on by default b) if you turn it on you need to open the port in the firewall too c) if you open the port you do this only for trusted sources The current implementation is more a proof-of-concept, not used or enabled by default. It has zero built-in security, it cannot be used or enabled in untrusted environments without externally provided protection. That's not really true. There's security built in, it does SSL among other things if that's enabled. There's no authentication currently though. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] logs-show.c: Fix missing sys/socket.h include
Hi Zbyszek, diff --git a/src/shared/logs-show.c b/src/shared/logs-show.c index c99fc7569429..0e3fd3de2630 100644 --- a/src/shared/logs-show.c +++ b/src/shared/logs-show.c @@ -23,6 +23,7 @@ #include assert.h #include errno.h #include sys/poll.h +#include sys/socket.h #include string.h #include fcntl.h Marc-Antoine sent an identical patch, applied the other one. I would have picked the one with the clear commit subject and not this generic one. I had too generic commit messages ;) Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] Initial libsystemd-asyncns commit
On Thu, 12.12.13 14:09, Marcel Holtmann (mar...@holtmann.org) wrote: Hi Lennart, why do we have to spawn threads or do forks for DNS. This looks all pretty expensive. In ConnMan for example we just wrote our own async DNS using a mainloop. Works perfectly fine and is dirt cheap. Well, we don't fork threads/processes for each call but reuse them. What libasyncns does what your solution doesn't do is go via NSS. This means /etc/hosts, nss-myhostname, nss-ldap, nss-mdns and so on just work, while that all is lost when doing DNS natively. I am pretty sure we should not bypass NSS for this. actually NSS for DNS is pretty nasty stuff. I am pretty sure we should bypass it and create a proper implementation. Is anybody actually using NIS or LDAP for domain name resolution? Well, I am not opposed to having a different DNS implementation that is smarter than the one in glibc (i.e. can do split hoirzon and stuff), but I am sure that should be behind NSS, not bypassing it. The problem with NSS is that it still does not fix the fundamental problem. It is sequential and blocking. You can spawn as many threads as you want and it will stay sequential. Are you suggesting that there was a global lock around NSS that serializes all NSS requests? The getaddrinfo() RFC makes clear that the call needs to be reentrant, this would hence be news to me? I fully agree with you that we need to consider /etc/hosts, the local hostname and also mDNS, but I get the feeling it would be more beneficial to just build that in. ConnMan ships a DNS proxy cache to actually be able to be smart and parallel. We did not bother with the details like /etc/hosts so far since our use cases always had an empty /etc/hosts with just localhost only anyway. However that is easy to fix. Well, note that the API libasyncns exposes is actually abstract enough to support a different backend instead of NSS. It is also close enough to glibc to not be surprising. I am pretty sure that NSS should be kept in the loop, but even if we decide that we shouldn't need that then there's no reason to not do that behing the same API... 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] [RFC] Initial libsystemd-asyncns commit
Hi Andrey, why do we have to spawn threads or do forks for DNS. This looks all pretty expensive. In ConnMan for example we just wrote our own async DNS using a mainloop. Works perfectly fine and is dirt cheap. Well, we don't fork threads/processes for each call but reuse them. What libasyncns does what your solution doesn't do is go via NSS. This means /etc/hosts, nss-myhostname, nss-ldap, nss-mdns and so on just work, while that all is lost when doing DNS natively. I am pretty sure we should not bypass NSS for this. actually NSS for DNS is pretty nasty stuff. I am pretty sure we should bypass it and create a proper implementation. Is anybody actually using NIS or LDAP for domain name resolution? Yes, there are solutions that are using LDAP for hostname resolution quite heavily - actually are based around LDAP without any local /etc/hosts. that is extremely heavy and must suck form a latency point of view. Then again, nothing that a DNS-LDAP bridge couldn’t easily support. Since dragging LDAP dependencies into every program that has to load NSS modules is not a good idea either. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] install: Assume *.wants symlinks have the same name as their target for scalability.
On Wed, 11.12.13 15:54, da...@davidstrauss.net (da...@davidstrauss.net) wrote: From: David Strauss da...@davidstrauss.net --- src/shared/install.c | 5 + 1 file changed, 5 insertions(+) diff --git a/src/shared/install.c b/src/shared/install.c index 17e8a75..14c0f4b 100644 --- a/src/shared/install.c +++ b/src/shared/install.c @@ -423,6 +423,11 @@ static int find_symlinks_fd( bool found_path, found_dest, b = false; int q; +/* Skip symlinks with a different basename than + * the target unit */ +if (!streq(basename(de-d_name), name)) +continue; + /* Acquire symlink name */ p = path_make_absolute(de-d_name, path); if (!p) This isn't right. Units might be symlinked under different names, we need to support that. For example, all template instances carry a different name for the symlink then for the source. We need to find a different solution here. Maybe introduce a cache object or so where we load everything we find in too and that can be indexed by the target rather then the name of a symlink. 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] [RFC] Initial libsystemd-asyncns commit
On Thu, 12.12.13 15:20, Marcel Holtmann (mar...@holtmann.org) wrote: Hi Andrey, why do we have to spawn threads or do forks for DNS. This looks all pretty expensive. In ConnMan for example we just wrote our own async DNS using a mainloop. Works perfectly fine and is dirt cheap. Well, we don't fork threads/processes for each call but reuse them. What libasyncns does what your solution doesn't do is go via NSS. This means /etc/hosts, nss-myhostname, nss-ldap, nss-mdns and so on just work, while that all is lost when doing DNS natively. I am pretty sure we should not bypass NSS for this. actually NSS for DNS is pretty nasty stuff. I am pretty sure we should bypass it and create a proper implementation. Is anybody actually using NIS or LDAP for domain name resolution? Yes, there are solutions that are using LDAP for hostname resolution quite heavily - actually are based around LDAP without any local /etc/hosts. that is extremely heavy and must suck form a latency point of view. Then again, nothing that a DNS-LDAP bridge couldn’t easily support. Since dragging LDAP dependencies into every program that has to load NSS modules is not a good idea either. Note that nscd was created to deal with the performance of the LDAP setups and also doesn't require loading everything into the same process. 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] timedatectl: work with old timedated
On Wed, 11.12.13 14:04, Shawn Landden (sh...@churchofgit.com) wrote: Which does have TimeUSec. Should we specifically check for this method instead of assuming time=0 means it doesn't exist? Sounds OK to just check against time == 0. +if (i-time) For numeric values please always check with explicit numerical comparison. Something like this: if (i-time 0) or so.. +sec = (time_t) (i-time / USEC_PER_SEC); +else if (arg_transport == BUS_TRANSPORT_LOCAL) +sec = time(NULL); +else +return (void)fprintf(stderr, Could not get time from timedated and not operating locally.\n\n); I am pretty sure we shouldn't exit here. We should instead show a line of n/a or so for this value. Also please do not do stuff like return (void) printf()... We are not in a contest to write non-obvious C code 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] login: Don't stop a running user manager from garbage-collecting the user.
On Wed, 11.12.13 19:56, Thomas Bächler (tho...@archlinux.org) wrote:
With the current logic, a user will never be garbage-collected, since its
manager will always be around. Change the logic such that a user is
garbage-collected when it has no sessions and linger is disabled.
---
src/login/logind-user.c | 12
1 file changed, 12 deletions(-)
diff --git a/src/login/logind-user.c b/src/login/logind-user.c
index 6ba8d98..42a7524 100644
--- a/src/login/logind-user.c
+++ b/src/login/logind-user.c
@@ -612,18 +612,6 @@ bool user_check_gc(User *u, bool drop_not_started) {
if (user_check_linger_file(u) 0)
return true;
-if (u-slice_job manager_job_is_active(u-manager, u-slice_job))
-return true;
-
-if (u-service_job manager_job_is_active(u-manager,
-u-service_job))
-return true;
Hmm, we probably should stay around as long as the jobs are still
active.
-
-if (u-slice manager_unit_is_active(u-manager, u-slice) != 0)
-return true;
-
-if (u-service manager_unit_is_active(u-manager, u-service) !=
0)
-return true;
-
THis part should indeed go, yo are right.
Can you check whether things work correctly for you if you only remove
the latter two parts, but leave the former two in? I'lll merge the patch then.
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] logs-show.c: Fix missing sys/socket.h include
On Thu, Dec 12, 2013 at 03:18:14PM +0100, Marcel Holtmann wrote: Hi Zbyszek, diff --git a/src/shared/logs-show.c b/src/shared/logs-show.c index c99fc7569429..0e3fd3de2630 100644 --- a/src/shared/logs-show.c +++ b/src/shared/logs-show.c @@ -23,6 +23,7 @@ #include assert.h #include errno.h #include sys/poll.h +#include sys/socket.h #include string.h #include fcntl.h Marc-Antoine sent an identical patch, applied the other one. I would have picked the one with the clear commit subject and not this generic one. I had too generic commit messages ;) I go through the patches in fifo mode :) Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] libsystemd-bus: Add checking masks creds in bus_creds_dump() function
On Wed, 11.12.13 15:23, Lukasz Skalski (l.skal...@partner.samsung.com) wrote:
log_assert_failed_return macro generates a lot of logs when we use
bus_message_dump() function without checking masks in creds.
Actually, the checks in the creds object where wrong, they should not
have used assert_return(). I fixed those now.
---
src/libsystemd-bus/bus-dump.c | 93
+++
1 file changed, 59 insertions(+), 34 deletions(-)
diff --git a/src/libsystemd-bus/bus-dump.c b/src/libsystemd-bus/bus-dump.c
index ddad418..85396aa 100644
--- a/src/libsystemd-bus/bus-dump.c
+++ b/src/libsystemd-bus/bus-dump.c
@@ -322,9 +322,12 @@ int bus_creds_dump(sd_bus_creds *c, FILE *f) {
fprintf(f, TID=%lu, (unsigned long) c-tid);
if (c-mask SD_BUS_CREDS_UID)
fprintf(f, UID=%lu, (unsigned long) c-uid);
-r = sd_bus_creds_get_owner_uid(c, owner);
-if (r = 0)
-fprintf(f, OwnerUID=%lu, (unsigned long) owner);
+if (c-mask SD_BUS_CREDS_OWNER_UID) {
+r = sd_bus_creds_get_owner_uid(c, owner);
+if (r = 0)
+fprintf(f, OwnerUID=%lu, (unsigned long) owner);
+}
+
if (c-mask SD_BUS_CREDS_GID)
fprintf(f, GID=%lu, (unsigned long) c-gid);
@@ -359,29 +362,45 @@ int bus_creds_dump(sd_bus_creds *c, FILE *f) {
if (c-mask SD_BUS_CREDS_CGROUP)
fprintf(f, CGroup=%s, c-cgroup);
-sd_bus_creds_get_unit(c, u);
-if (u)
-fprintf(f, Unit=%s, u);
-sd_bus_creds_get_user_unit(c, uu);
-if (uu)
-fprintf(f, UserUnit=%s, uu);
-sd_bus_creds_get_slice(c, sl);
-if (sl)
-fprintf(f, Slice=%s, sl);
-sd_bus_creds_get_session(c, s);
-if (s)
-fprintf(f, Session=%s, s);
+if (c-mask SD_BUS_CREDS_UNIT) {
+sd_bus_creds_get_unit(c, u);
+if (u)
+fprintf(f, Unit=%s, u);
+}
+
+if (c-mask SD_BUS_CREDS_USER_UNIT) {
+sd_bus_creds_get_user_unit(c, uu);
+if (uu)
+fprintf(f, UserUnit=%s, uu);
+}
+
+if (c-mask SD_BUS_CREDS_SLICE) {
+sd_bus_creds_get_slice(c, sl);
+if (sl)
+fprintf(f, Slice=%s, sl);
+}
+
+if (c-mask SD_BUS_CREDS_SESSION) {
+sd_bus_creds_get_session(c, s);
+if (s)
+fprintf(f, Session=%s, s);
+}
if ((c-mask SD_BUS_CREDS_CGROUP) || u || uu || sl || s)
fputs(\n, f);
-if (sd_bus_creds_get_audit_login_uid(c, audit_loginuid) = 0) {
-audit_loginuid_is_set = true;
-fprintf(f, AuditLoginUID=%lu, (unsigned long)
audit_loginuid);
+if (c-mask SD_BUS_CREDS_AUDIT_LOGIN_UID) {
+if (sd_bus_creds_get_audit_login_uid(c, audit_loginuid) =
0) {
+audit_loginuid_is_set = true;
+fprintf(f, AuditLoginUID=%lu, (unsigned long)
audit_loginuid);
+}
}
-if (sd_bus_creds_get_audit_session_id(c, audit_sessionid) = 0) {
-audit_sessionid_is_set = true;
-fprintf(f, AuditSessionID=%lu, (unsigned long)
audit_sessionid);
+
+if (c-mask SD_BUS_CREDS_AUDIT_SESSION_ID) {
+if (sd_bus_creds_get_audit_session_id(c, audit_sessionid)
= 0) {
+audit_sessionid_is_set = true;
+fprintf(f, AuditSessionID=%lu, (unsigned long)
audit_sessionid);
+}
}
if (audit_loginuid_is_set || audit_sessionid_is_set)
@@ -390,27 +409,33 @@ int bus_creds_dump(sd_bus_creds *c, FILE *f) {
if (c-mask SD_BUS_CREDS_UNIQUE_NAME)
fprintf(f, UniqueName=%s, c-unique_name);
-if (sd_bus_creds_get_well_known_names(c, well_known) = 0) {
-char **i;
+if (c-mask SD_BUS_CREDS_WELL_KNOWN_NAMES) {
+if (sd_bus_creds_get_well_known_names(c, well_known) = 0) {
+char **i;
-fputs( WellKnownNames={, f);
-STRV_FOREACH(i, well_known) {
-if (i != well_known)
-fputc(' ', f);
+fputs( WellKnownNames={, f);
+STRV_FOREACH(i, well_known) {
+if (i != well_known)
+fputc(' ', f);
-fputs(*i, f);
-}
+fputs(*i, f);
+}
-fputc('}', f);
+
Re: [systemd-devel] Last question about systemd before my presentation
On Wed, 11.12.13 16:33, Cecil Westerhof (cecil.wester...@snow.nl) wrote: On 12/05/2013 08:39 PM, Lennart Poettering wrote: When virtual machines are implementd as a service. You need to let the host define the limits per guest I suppose? Not following? You can pack as many services in a slice as you want, and you can create a tree of slices, so that you can run a couple of services against a common set of resource limits. What I mend was the following: As I understood it, there are Virtual Machine solutions that are implemented as a service. When there are several VM's running in this service and one of those should get a lot more from the processor as the rest, then it is not something that could be taken care of by systemd, but should be done by the service that provides the Virtual Machine itself. virtual machine managers which want to make use of resource management for their VMs should create scope units for them, which is oart of the cgroup rework. http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ 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] login: Don't stop a running user manager from garbage-collecting the user.
Am 12.12.2013 15:38, schrieb Lennart Poettering:
On Wed, 11.12.13 19:56, Thomas Bächler (tho...@archlinux.org) wrote:
With the current logic, a user will never be garbage-collected, since its
manager will always be around. Change the logic such that a user is
garbage-collected when it has no sessions and linger is disabled.
---
src/login/logind-user.c | 12
1 file changed, 12 deletions(-)
diff --git a/src/login/logind-user.c b/src/login/logind-user.c
index 6ba8d98..42a7524 100644
--- a/src/login/logind-user.c
+++ b/src/login/logind-user.c
@@ -612,18 +612,6 @@ bool user_check_gc(User *u, bool drop_not_started) {
if (user_check_linger_file(u) 0)
return true;
-if (u-slice_job manager_job_is_active(u-manager, u-slice_job))
-return true;
-
-if (u-service_job manager_job_is_active(u-manager,
-u-service_job))
-return true;
Hmm, we probably should stay around as long as the jobs are still
active.
-
-if (u-slice manager_unit_is_active(u-manager, u-slice) != 0)
-return true;
-
-if (u-service manager_unit_is_active(u-manager, u-service) !=
0)
-return true;
-
THis part should indeed go, yo are right.
Can you check whether things work correctly for you if you only remove
the latter two parts, but leave the former two in? I'lll merge the patch then.
That's rather hard to test. I'd have to terminate the session while the
service or slice job is still running and see what happens.
My guess is that omitting the first two checks will work most of the
time, but fail under rare circumstance: You terminate the last session
while the start job is still active, omit gc'ing the user and never add
it to the gc list again.
On the other hand I think that removing those lines is fine: Stopping
the user will queue a stob job for the service and the slice. The
corresponding start job may still be running at that time, but the
system manager should be capable of dealing with such issues (it's the
same issues that arises when running systemctl stop before a systemctl
start finished).
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] [RFC] [PATCH 0/3] journal: Add deferred log processing to reduce synchonous IO overhead
On Thu, 12.12.13 14:12, Karol Lewandowski (k.lewando...@samsung.com) wrote: Folks, We are trying to apply journald as default (and only) logging system for our ARM-based handhelds. There is one major problem, though - performance. We have found that journald can consume considerable amount of CPU time under moderate load (10-20% of CPU per, for say 100-300msg/s). We have profiled journald and there are few places that could benefit from _some_ optimizations but I have come to conclusion it isn't journald code that is real bottleneck - it's, or seems to be, synchronous nature of send()/recv(). In default configuration each send() can cause context-switch which is especially costly on ARM. Hmm, but this wouldn't be any different from old syslog, right? I mean, old syslog also uses sendv() and recv() on AF_UNIX SOCK_DGRAM sockets... Note that on Linux the number of datagrams you can queue in an AF_UNIX/SOCK_DGRAM socket is very low (15). THis is controlled via /proc/sys/net/unix/max_dgram_qlen. When this limit is hit the client needs to wait for the server to finish processing. Unfortunately there's only that system-global way to increase the qlen. For a long time it has been on our wishlist to make this a per-socket tunable with a new sockopt() that behaves similar to SO_SNDBUF and friends... This is why I decided to try to make logging completely async and see if/what changes. Well, if AF_UNIX is slow, then we really should try to fix that in the kernel instead of bypassing it in userspace... Whether we rely on the socket buffer of the AF_UNIX socket or put together our own buffer in /dev/shm shouldn't be much of a difference if they both have the same size and can take the same number of entries... 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] [HACK/RFC/PATCH] systemd-su: su on steroids
On Wed, 11.12.13 15:57, David Herrmann (dh.herrm...@gmail.com) wrote: Hey On Wed, Dec 11, 2013 at 3:27 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 11.12.13 13:54, David Herrmann (dh.herrm...@gmail.com) wrote: Hi On Wed, Dec 11, 2013 at 12:18 AM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 02.12.13 21:47, David Herrmann (dh.herrm...@gmail.com) wrote: 4h later, I present systemd-su: If you want to give it a try, run: systemd-su -u david /bin/sh It requires the systemd-suexec helper internally, so if you didn't install it, use something like this: SYSTEMD_SUEXEC=/home/david/dev/systemd/systemd-suexec ./systemd-su -u david sh Otherwise, systemd-su cannot find the systemd-suexec binary. Hmm, if we allow that su - tells logind to create an entirely new session even when called from an existing one, do we still need systemd-su? That should be pretty close, no? That sounds easier to do... You cannot start a session from within an existing session. At least if audit-loginids are immutable, this also means the audit-sessionid is immutable (as the session ID is updated if, and only if, the logind-uid changes). Of course, immutable audit IDs are a somewhat controversial feature (and afaik don't work with containers?) but I still dislike the idea of starting sessions from within an existing session. It's ugly and we don't actually need it, do we? Currently su/sudo don't start new sessions and I think that is fine. Imho, their intention is to change the EUID, not to spawn a new session. So my hack here is just some example to play with, not something for real to replace su/sudo. The new switch I was suggesting for pam_systemd (force-new-session=1) would cause a new session to be started from within an existing one, in that case decoupling the session id from the audit id. Hence, when you first log into a computer you will get a session with a session ID identical to the audit id. However if you use su - which then does force-new-session=1 on pam_system you will get a new session that gets an independent id, that is decoupled from the audi session, and to avoid namespace clashes is prefixed with a lower-case c. We'd only do that for su -/sudo -i, not for su, su -. Yeah, I understand that and our code already does that, except for CreateSession() which always tries to pick up existing sessions. My question rather is: why would anyone want su --login to start a new session? Yeah, it's needed to set env-variables correctly on uid-change or set other things. But I've never seen a use-case where someone really wants a new session. Imho, su/sudo is exclusively used to change euids. Well, people do find it useful to quickly change identities. I use it like that all the time too actually. It's a bit like ssh'ing to the localhost, except that it doesn't require IP. And I am pretty sure that we should support it like that. For example, I make use of it all the time in containers, where nspawn just gives me a single console where I scan log in once. If I quickly need to change identity, then su - and sudo -l are certainly quicker then to open another window and use ss or machinectl login to get a second login su - and sudo -i would hence do the greatest possible disconnection from the originating session. (switch everything possible except the tty itself) There is actually one thing, that you *cannot* share between legacy/unix sessions, which is the CTTY. Only one SID can be assigned a given TTY as CTTY. We can avoid the setsid() call, obviously, but that seriously questions the idea why a new session is needed. Again, if you want to share the CTTY (which su/sudo usually do), it seems weird to not share the session. Well, but su/sudo give up the ctty while the transition is being done, and takes it back afterwards... 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] [HACK/RFC/PATCH] systemd-su: su on steroids
Hi On Thu, Dec 12, 2013 at 3:55 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 11.12.13 15:57, David Herrmann (dh.herrm...@gmail.com) wrote: Hey On Wed, Dec 11, 2013 at 3:27 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 11.12.13 13:54, David Herrmann (dh.herrm...@gmail.com) wrote: Hi On Wed, Dec 11, 2013 at 12:18 AM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 02.12.13 21:47, David Herrmann (dh.herrm...@gmail.com) wrote: 4h later, I present systemd-su: If you want to give it a try, run: systemd-su -u david /bin/sh It requires the systemd-suexec helper internally, so if you didn't install it, use something like this: SYSTEMD_SUEXEC=/home/david/dev/systemd/systemd-suexec ./systemd-su -u david sh Otherwise, systemd-su cannot find the systemd-suexec binary. Hmm, if we allow that su - tells logind to create an entirely new session even when called from an existing one, do we still need systemd-su? That should be pretty close, no? That sounds easier to do... You cannot start a session from within an existing session. At least if audit-loginids are immutable, this also means the audit-sessionid is immutable (as the session ID is updated if, and only if, the logind-uid changes). Of course, immutable audit IDs are a somewhat controversial feature (and afaik don't work with containers?) but I still dislike the idea of starting sessions from within an existing session. It's ugly and we don't actually need it, do we? Currently su/sudo don't start new sessions and I think that is fine. Imho, their intention is to change the EUID, not to spawn a new session. So my hack here is just some example to play with, not something for real to replace su/sudo. The new switch I was suggesting for pam_systemd (force-new-session=1) would cause a new session to be started from within an existing one, in that case decoupling the session id from the audit id. Hence, when you first log into a computer you will get a session with a session ID identical to the audit id. However if you use su - which then does force-new-session=1 on pam_system you will get a new session that gets an independent id, that is decoupled from the audi session, and to avoid namespace clashes is prefixed with a lower-case c. We'd only do that for su -/sudo -i, not for su, su -. Yeah, I understand that and our code already does that, except for CreateSession() which always tries to pick up existing sessions. My question rather is: why would anyone want su --login to start a new session? Yeah, it's needed to set env-variables correctly on uid-change or set other things. But I've never seen a use-case where someone really wants a new session. Imho, su/sudo is exclusively used to change euids. Well, people do find it useful to quickly change identities. I use it like that all the time too actually. It's a bit like ssh'ing to the localhost, except that it doesn't require IP. And I am pretty sure that we should support it like that. For example, I make use of it all the time in containers, where nspawn just gives me a single console where I scan log in once. If I quickly need to change identity, then su - and sudo -l are certainly quicker then to open another window and use ss or machinectl login to get a second login Ok. su - and sudo -i would hence do the greatest possible disconnection from the originating session. (switch everything possible except the tty itself) There is actually one thing, that you *cannot* share between legacy/unix sessions, which is the CTTY. Only one SID can be assigned a given TTY as CTTY. We can avoid the setsid() call, obviously, but that seriously questions the idea why a new session is needed. Again, if you want to share the CTTY (which su/sudo usually do), it seems weird to not share the session. Well, but su/sudo give up the ctty while the transition is being done, and takes it back afterwards... Are you sure? Last time I checked, su/sudo keep the CTTY the whole time or drop it entirely. Thing is, as long as your bash keeps the CTTY, no other process can call TIOCSCTTY() (only the session leader can do that), so once su/sudo drop the CTTY, they cannot reacquire it. Unless you force the TIOCSCTTY call after setsid().. but that causes the parent bash and all other processes in its session to loose the CTTY. Note, even if you call TIOCSCTTY in the parent bash, after su/sudo returns, you only set the CTTY for bash, not for the other processes in the process-group. But as long as you don't call setsid() and don't drop the CTTY, you're fine. But you will run under the parent-bash session. So if we don't care for UNIX SIDs, we can share CTTYs across sessions. David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org
Re: [systemd-devel] [PATCH] bus: Add support for eavesdrop in sd_bus_add_match()
On 12/12/13 14:28, Lennart Poettering wrote: kay and Daniel are working on changing the semantics of monitoring entirely. Instead of turning monitoring on and off on an existing connection they want this to be an entirely new connection type Colin Walters wanted to do this in dbus-daemon too (a separate /var/run/dbus/system_bus_monitor_socket that's only accessible by root, or something), but nobody has got round to it yet. Another possibility might be to make the eavesdropped stream obviously not the same thing as the normal D-Bus stream, for instance by wrapping it in pcap format as used by bustle(1) (as in my proof-of-concept dbus-daemon patches on https://bugs.freedesktop.org/show_bug.cgi?id=60859). bustle-pcap(1) is a standalone implementation of connect, eavesdrop, produce a pcap stream for traditional D-Bus, similar to dbus-monitor. the same way as starter (i.e. those which may be used to take a well-known name and get notified when the service behind it needs to be activated) connections are different from normal connections Please consider naming this differently: starter in the D-Bus Specification (e.g. DBUS_STARTER_ADDRESS) is something rather different. Maybe placeholder? (Which would break compat wit traditional dbus I figure, but that should be OK given that monitoring is a debugging feature anyway.) Yes, I think anyone using eavesdropping for purposes other than a debugging tool is wrong; when we added eavesdrop=true to dbus-daemon, it broke compatibility with older client libraries anyway. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] Initial libsystemd-asyncns commit
Hi Lennart, why do we have to spawn threads or do forks for DNS. This looks all pretty expensive. In ConnMan for example we just wrote our own async DNS using a mainloop. Works perfectly fine and is dirt cheap. Well, we don't fork threads/processes for each call but reuse them. What libasyncns does what your solution doesn't do is go via NSS. This means /etc/hosts, nss-myhostname, nss-ldap, nss-mdns and so on just work, while that all is lost when doing DNS natively. I am pretty sure we should not bypass NSS for this. actually NSS for DNS is pretty nasty stuff. I am pretty sure we should bypass it and create a proper implementation. Is anybody actually using NIS or LDAP for domain name resolution? Yes, there are solutions that are using LDAP for hostname resolution quite heavily - actually are based around LDAP without any local /etc/hosts. that is extremely heavy and must suck form a latency point of view. Then again, nothing that a DNS-LDAP bridge couldn’t easily support. Since dragging LDAP dependencies into every program that has to load NSS modules is not a good idea either. Note that nscd was created to deal with the performance of the LDAP setups and also doesn't require loading everything into the same process. and that is an excuse to keep using NSS modules? We took a rather shitty idea and hacked it up a little and it is now a little bit less shitty. Just to be clear, I have nothing against the general idea, I am just saying that NSS itself with its current design is pretty limited. And keep working around it is not helping either. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Last question about systemd before my presentation
On 12/12/2013 03:43 PM, Lennart Poettering wrote: What I mend was the following: As I understood it, there are Virtual Machine solutions that are implemented as a service. When there are several VM's running in this service and one of those should get a lot more from the processor as the rest, then it is not something that could be taken care of by systemd, but should be done by the service that provides the Virtual Machine itself. virtual machine managers which want to make use of resource management for their VMs should create scope units for them, which is oart of the cgroup rework. http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ Thank you. I'll look into it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bus: Add support for eavesdrop in sd_bus_add_match()
On 12/12/2013 04:22 PM, Simon McVittie wrote: On 12/12/13 14:28, Lennart Poettering wrote: kay and Daniel are working on changing the semantics of monitoring entirely. Instead of turning monitoring on and off on an existing connection they want this to be an entirely new connection type Colin Walters wanted to do this in dbus-daemon too (a separate /var/run/dbus/system_bus_monitor_socket that's only accessible by root, or something), but nobody has got round to it yet. I didn't know nothing about above plans - new connection type in kdbus and /var/run/dbus/system_bus_monitor_socket in dbus, so support for eavesdrop seemed to be missing in libsystemd-bus for me (especially that at this moment busctl prints infos only about signals). Thanks for explanations. Another possibility might be to make the eavesdropped stream obviously not the same thing as the normal D-Bus stream, for instance by wrapping it in pcap format as used by bustle(1) (as in my proof-of-concept dbus-daemon patches on https://bugs.freedesktop.org/show_bug.cgi?id=60859). bustle-pcap(1) is a standalone implementation of connect, eavesdrop, produce a pcap stream for traditional D-Bus, similar to dbus-monitor. the same way as starter (i.e. those which may be used to take a well-known name and get notified when the service behind it needs to be activated) connections are different from normal connections Please consider naming this differently: starter in the D-Bus Specification (e.g. DBUS_STARTER_ADDRESS) is something rather different. Maybe placeholder? (Which would break compat wit traditional dbus I figure, but that should be OK given that monitoring is a debugging feature anyway.) Yes, I think anyone using eavesdropping for purposes other than a debugging tool is wrong; when we added eavesdrop=true to dbus-daemon, it broke compatibility with older client libraries anyway. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Lukasz Skalski Samsung RD Institute Poland Samsung Electronics l.skal...@partner.samsung.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] No security on systemd-journal-gatewayd
On Thu, Dec 12, 2013 at 3:08 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 12.12.13 05:20, Kay Sievers (k...@vrfy.org) wrote: On Wed, Dec 11, 2013 at 11:53 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 11.12.2013 22:41, schrieb Cecil Westerhof: I tried out systemd-journal-gatewayd. But it looks like that everyone that can contact, can get log info. Is that true, or am I overlooking something? as far as i remeber from older posts about it the intention is that a) it is not on by default b) if you turn it on you need to open the port in the firewall too c) if you open the port you do this only for trusted sources The current implementation is more a proof-of-concept, not used or enabled by default. It has zero built-in security, it cannot be used or enabled in untrusted environments without externally provided protection. That's not really true. There's security built in, it does SSL among other things if that's enabled. There's no authentication currently though. We must not give the impression that this is secure in any way, it is not, and cannot generally be used unless it is secured by other things. So, no this is not secure at all, just possibly encrypted, but I doubt that was the question. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] [PATCH 0/3] journal: Add deferred log processing to reduce synchonous IO overhead
On Thu, Dec 12, 2013 at 03:51:05PM +0100, Lennart Poettering wrote:
On Thu, 12.12.13 14:12, Karol Lewandowski (k.lewando...@samsung.com) wrote:
(OP here from private email.)
Folks,
We are trying to apply journald as default (and only) logging system
for our ARM-based handhelds. There is one major problem, though -
performance.
We have found that journald can consume considerable amount of CPU
time under moderate load (10-20% of CPU per, for say 100-300msg/s).
We have profiled journald and there are few places that could benefit
from _some_ optimizations but I have come to conclusion it isn't
journald code that is real bottleneck - it's, or seems to be,
synchronous nature of send()/recv(). In default configuration each
send() can cause context-switch which is especially costly on ARM.
Hmm, but this wouldn't be any different from old syslog, right? I mean,
old syslog also uses sendv() and recv() on AF_UNIX SOCK_DGRAM sockets...
That's true, however, we aren't migrating from syslog, but from
Android Logger. Android provides /dev/log_{main,radio,...} device
nodes which are simple in-kernel circular buffers apps can write to at
any time. This was invented when /dev/kmsg wasn't writable and serves
more-or-less same purpose.
From 2.6.29 it's in mailine kernel under drivers/staging/android/logger.c
Note that on Linux the number of datagrams you can queue in an
AF_UNIX/SOCK_DGRAM socket is very low (15). THis is controlled via
/proc/sys/net/unix/max_dgram_qlen. When this limit is hit the client
needs to wait for the server to finish processing. Unfortunately there's
only that system-global way to increase the qlen. For a long time it has
been on our wishlist to make this a per-socket tunable with a new
sockopt() that behaves similar to SO_SNDBUF and friends...
We have played this tunable and it didn't bring considerable/measurable
improvements, unfortunately.
This is why I decided to try to make logging completely async and see
if/what changes.
Well, if AF_UNIX is slow, then we really should try to fix that in the
kernel instead of bypassing it in userspace... Whether we rely on the
socket buffer of the AF_UNIX socket or put together our own buffer in
/dev/shm shouldn't be much of a difference if they both have the same
size and can take the same number of entries...
I do agree. Truth is I have looked at linux/net/ code once but I
didn't grok it well. I guess it's the time to take a second look. ;)
Cheers,
Karol
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] dhcp: Move src/dhcp to src/libsystemd-dhcp
On Thu, Dec 12, 2013 at 02:41:45PM +0100, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Dec 12, 2013 at 02:00:48PM +0100, Marcel Holtmann wrote: instead of moving everything around after the fact, I would say we better start off with a clean patch set and everything in the right spot in the first place. Hi Marcel, I have a local git-filter-tree-ed branch with the locations updated if made for testing. If Patrik doesn't have furhter updates, I'll push that today. In the end I made more changes: not only is src/dhcp renamed to src/libsystemd-dhcp, but also src/libsystemd-dhcp/*.[ch] to src/libsystemd-dhcp/dhcp-*.[ch]. This is because we like to have unique names for files, which makes editing them slightly easier, and also cross-includes between directories are nicer. The test cases now use the static library instead of recompling all sources. Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bus: Add support for eavesdrop in sd_bus_add_match()
On Thu, 12.12.13 15:22, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: On 12/12/13 14:28, Lennart Poettering wrote: kay and Daniel are working on changing the semantics of monitoring entirely. Instead of turning monitoring on and off on an existing connection they want this to be an entirely new connection type Colin Walters wanted to do this in dbus-daemon too (a separate /var/run/dbus/system_bus_monitor_socket that's only accessible by root, or something), but nobody has got round to it yet. Another possibility might be to make the eavesdropped stream obviously not the same thing as the normal D-Bus stream, for instance by wrapping it in pcap format as used by bustle(1) (as in my proof-of-concept dbus-daemon patches on https://bugs.freedesktop.org/show_bug.cgi?id=60859). bustle-pcap(1) is a standalone implementation of connect, eavesdrop, produce a pcap stream for traditional D-Bus, similar to dbus-monitor. the same way as starter (i.e. those which may be used to take a well-known name and get notified when the service behind it needs to be activated) connections are different from normal connections Please consider naming this differently: starter in the D-Bus Specification (e.g. DBUS_STARTER_ADDRESS) is something rather different. Maybe placeholder? Well, the starter stuff is something that app developers will never see. It's just the backend for the .busname unit type, that's all, and people only get in contact with .busname units, nothing else. Thus I don't think that the name is a big issue. OTOH I don't mind renaming it in the Kernel either. Kay? Maybe call it activator instead? 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] timedatectl: work with old timedated
Which does have TimeUSec. Should we specifically check for this method
instead of assuming time=0 means it doesn't exist?
Before:
shawn@debian-T61:~/git/systemd$ ./timedatectl
Local time: Wed 1969-12-31 16:00:00 PST
Universal time: Thu 1970-01-01 00:00:00 UTC
RTC time: n/a
Timezone: America/Los_Angeles (PST, -0800)
NTP enabled: n/a
NTP synchronized: no
RTC in local TZ: no
DST active: no
Last DST change: DST ended at
Sun 1969-10-26 01:59:59 PDT
Sun 1969-10-26 01:00:00 PST
Next DST change: DST begins (the clock jumps one hour forward) at
Sun 1970-04-26 01:59:59 PST
Sun 1970-04-26 03:00:00 PDT
After:
shawn@debian-T61:~/git/systemd$ ./timedatectl
Local time: Wed 2013-12-11 14:03:21 PST
Universal time: Wed 2013-12-11 22:03:21 UTC
RTC time: n/a
Timezone: America/Los_Angeles (PST, -0800)
NTP enabled: n/a
NTP synchronized: no
RTC in local TZ: no
DST active: no
Last DST change: DST ended at
Sun 2013-11-03 01:59:59 PDT
Sun 2013-11-03 01:00:00 PST
Next DST change: DST begins (the clock jumps one hour forward) at
Sun 2014-03-09 01:59:59 PST
Sun 2014-03-09 03:00:00 PDT
---
src/timedate/timedatectl.c | 43 ++-
1 file changed, 30 insertions(+), 13 deletions(-)
diff --git a/src/timedate/timedatectl.c b/src/timedate/timedatectl.c
index 9b81513..6b09559 100644
--- a/src/timedate/timedatectl.c
+++ b/src/timedate/timedatectl.c
@@ -98,6 +98,7 @@ static void print_status_info(const StatusInfo *i) {
char s[32];
struct tm tm;
time_t sec;
+bool have_time = false;
char *zc, *zn;
time_t t, tc, tn;
int dn;
@@ -109,20 +110,35 @@ static void print_status_info(const StatusInfo *i) {
/* Enforce the values of /etc/localtime */
if (getenv(TZ)) {
fprintf(stderr, Warning: ignoring the TZ variable, reading
the system's timezone setting only.\n\n);
+fflush(stderr);
unsetenv(TZ);
}
-sec = (time_t) (i-time / USEC_PER_SEC);
+if (i-time != 0) {
+sec = (time_t) (i-time / USEC_PER_SEC);
+have_time = true;
+} else if (arg_transport == BUS_TRANSPORT_LOCAL) {
+sec = time(NULL);
+have_time = true;
+} else {
+fprintf(stderr, Warning: could not get time from timedated
and not operating locally.\n\n);
+fflush(stderr);
+}
-zero(tm);
-assert_se(strftime(a, sizeof(a), %a %Y-%m-%d %H:%M:%S %Z,
localtime_r(sec, tm)) 0);
-char_array_0(a);
-printf( Local time: %s\n, a);
+if (have_time) {
+zero(tm);
+assert_se(strftime(a, sizeof(a), %a %Y-%m-%d %H:%M:%S %Z,
localtime_r(sec, tm)) 0);
+char_array_0(a);
+printf( Local time: %s\n, a);
-zero(tm);
-assert_se(strftime(a, sizeof(a), %a %Y-%m-%d %H:%M:%S UTC,
gmtime_r(sec, tm)) 0);
-char_array_0(a);
-printf( Universal time: %s\n, a);
+zero(tm);
+assert_se(strftime(a, sizeof(a), %a %Y-%m-%d %H:%M:%S UTC,
gmtime_r(sec, tm)) 0);
+char_array_0(a);
+printf( Universal time: %s\n, a);
+} else {
+printf( Local time: %s\n, n/a);
+printf( Universal time: %s\n, n/a);
+}
if (i-rtc_time 0) {
time_t rtc_sec;
@@ -133,7 +149,7 @@ static void print_status_info(const StatusInfo *i) {
char_array_0(a);
printf(RTC time: %s\n, a);
} else
-printf(RTC time: n/a\n);
+printf(RTC time: %s\n, n/a);
zero(tm);
assert_se(strftime(a, sizeof(a), %Z, %z, localtime_r(sec, tm))
0);
@@ -151,8 +167,8 @@ static void print_status_info(const StatusInfo *i) {
tc, zc, is_dstc,
tn, dn, zn, is_dstn);
if (r 0)
-printf( DST active: n/a\n);
-else {
+printf( DST active: %s\n, n/a);
+else if (have_time) {
printf( DST active: %s\n, yes_no(is_dstc));
t = tc - 1;
@@ -183,7 +199,8 @@ static void print_status_info(const StatusInfo *i) {
free(zc);
free(zn);
-}
+} else
+printf( DST active: %s\n, yes_no(is_dstc));
if (i-rtc_local)
fputs(\n ANSI_HIGHLIGHT_ON
--
1.8.5.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] [PATCH 0/3] journal: Add deferred log processing to reduce synchonous IO overhead
On Thu, 12.12.13 17:42, Karol Lewandowski (lmc...@gmail.com) wrote:
Hmm, but this wouldn't be any different from old syslog, right? I mean,
old syslog also uses sendv() and recv() on AF_UNIX SOCK_DGRAM sockets...
That's true, however, we aren't migrating from syslog, but from
Android Logger. Android provides /dev/log_{main,radio,...} device
nodes which are simple in-kernel circular buffers apps can write to at
any time. This was invented when /dev/kmsg wasn't writable and serves
more-or-less same purpose.
From 2.6.29 it's in mailine kernel under
drivers/staging/android/logger.c
But if the the socket layer is really that much slower than android
logging, then that's kinda sad, and the kernel socket stuff should
probably be fixed?
This is why I decided to try to make logging completely async and see
if/what changes.
Well, if AF_UNIX is slow, then we really should try to fix that in the
kernel instead of bypassing it in userspace... Whether we rely on the
socket buffer of the AF_UNIX socket or put together our own buffer in
/dev/shm shouldn't be much of a difference if they both have the same
size and can take the same number of entries...
I do agree. Truth is I have looked at linux/net/ code once but I
didn't grok it well. I guess it's the time to take a second look. ;)
Here's another option: extend journald to use kdbus as additional
transport. This is something we want to do anyway since the kdbus
transport will attach the metadata we need without race to each
packet. Given that kdbus ultimately is just a way to write into an
mmaped tmpfs that some other process owns this should not be much worse
than the android logger in performance.
Special care needs to be taken to make this work though, as we should do
this only on kdbus systems. On non-kdbus systems journald can never talk
to dbus, because dbus-daemon is a client of journald and things would
deadlock...
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] [RFC] Initial libsystemd-asyncns commit
On Thu, 12.12.13 16:28, Marcel Holtmann (mar...@holtmann.org) wrote: Hi Lennart, why do we have to spawn threads or do forks for DNS. This looks all pretty expensive. In ConnMan for example we just wrote our own async DNS using a mainloop. Works perfectly fine and is dirt cheap. Well, we don't fork threads/processes for each call but reuse them. What libasyncns does what your solution doesn't do is go via NSS. This means /etc/hosts, nss-myhostname, nss-ldap, nss-mdns and so on just work, while that all is lost when doing DNS natively. I am pretty sure we should not bypass NSS for this. actually NSS for DNS is pretty nasty stuff. I am pretty sure we should bypass it and create a proper implementation. Is anybody actually using NIS or LDAP for domain name resolution? Yes, there are solutions that are using LDAP for hostname resolution quite heavily - actually are based around LDAP without any local /etc/hosts. that is extremely heavy and must suck form a latency point of view. Then again, nothing that a DNS-LDAP bridge couldn’t easily support. Since dragging LDAP dependencies into every program that has to load NSS modules is not a good idea either. Note that nscd was created to deal with the performance of the LDAP setups and also doesn't require loading everything into the same process. and that is an excuse to keep using NSS modules? We took a rather shitty idea and hacked it up a little and it is now a little bit less shitty. Well, I agree that NSS is a bit aged, given its synchronous behaviour. But it's the only name resolving API that is somewhat accepted these days. With systemd we try to keep the focus on the general purpose, which means we cannot just decide that NSS is shit and bypass all NSS modules. Or, maybe we can do that one day, but then we have to have something that is at least is powerful, and supports loadable modules and shit -- but we don't have that. In the meantime, going via NSS is the only viable option I think. And the API is generic enough to allow other backends too. It's a 1:1 translation of the classic getaddrinfo() interface to an async way of things. Whether there's actually getaddrinfo() behind it doesn't really matter, we can totally swap that out. For example, if eventuallly we have some kind of local DNS resolver daemon that can do split horizon and whatnot, and also supports an interface for LDAP, mdns, ... then we can certainly talk to that directly from the same lib, nobody needs to know that... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bus: Add support for eavesdrop in sd_bus_add_match()
On Thu, Dec 12, 2013 at 6:59 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 12.12.13 15:22, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: On 12/12/13 14:28, Lennart Poettering wrote: kay and Daniel are working on changing the semantics of monitoring entirely. Instead of turning monitoring on and off on an existing connection they want this to be an entirely new connection type Colin Walters wanted to do this in dbus-daemon too (a separate /var/run/dbus/system_bus_monitor_socket that's only accessible by root, or something), but nobody has got round to it yet. Another possibility might be to make the eavesdropped stream obviously not the same thing as the normal D-Bus stream, for instance by wrapping it in pcap format as used by bustle(1) (as in my proof-of-concept dbus-daemon patches on https://bugs.freedesktop.org/show_bug.cgi?id=60859). bustle-pcap(1) is a standalone implementation of connect, eavesdrop, produce a pcap stream for traditional D-Bus, similar to dbus-monitor. the same way as starter (i.e. those which may be used to take a well-known name and get notified when the service behind it needs to be activated) connections are different from normal connections Please consider naming this differently: starter in the D-Bus Specification (e.g. DBUS_STARTER_ADDRESS) is something rather different. Maybe placeholder? Well, the starter stuff is something that app developers will never see. It's just the backend for the .busname unit type, that's all, and people only get in contact with .busname units, nothing else. Thus I don't think that the name is a big issue. OTOH I don't mind renaming it in the Kernel either. Kay? Maybe call it activator instead? Put it on my list. I'll rename it, as soon as stuff works again. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timedatectl: work with old timedated
On Thu, 12.12.13 10:00, Shawn Landden (sh...@churchofgit.com) wrote:
Applied. Dropped the fflush(stderr) bits though as we that's not
necessary for stderr, and not even for stdout if an \n was printed
anyway...
Thanks!
diff --git a/src/timedate/timedatectl.c b/src/timedate/timedatectl.c
index 9b81513..6b09559 100644
--- a/src/timedate/timedatectl.c
+++ b/src/timedate/timedatectl.c
@@ -98,6 +98,7 @@ static void print_status_info(const StatusInfo *i) {
char s[32];
struct tm tm;
time_t sec;
+bool have_time = false;
char *zc, *zn;
time_t t, tc, tn;
int dn;
@@ -109,20 +110,35 @@ static void print_status_info(const StatusInfo *i) {
/* Enforce the values of /etc/localtime */
if (getenv(TZ)) {
fprintf(stderr, Warning: ignoring the TZ variable, reading
the system's timezone setting only.\n\n);
+fflush(stderr);
unsetenv(TZ);
}
-sec = (time_t) (i-time / USEC_PER_SEC);
+if (i-time != 0) {
+sec = (time_t) (i-time / USEC_PER_SEC);
+have_time = true;
+} else if (arg_transport == BUS_TRANSPORT_LOCAL) {
+sec = time(NULL);
+have_time = true;
+} else {
+fprintf(stderr, Warning: could not get time from timedated
and not operating locally.\n\n);
+fflush(stderr);
+}
-zero(tm);
-assert_se(strftime(a, sizeof(a), %a %Y-%m-%d %H:%M:%S %Z,
localtime_r(sec, tm)) 0);
-char_array_0(a);
-printf( Local time: %s\n, a);
+if (have_time) {
+zero(tm);
+assert_se(strftime(a, sizeof(a), %a %Y-%m-%d %H:%M:%S %Z,
localtime_r(sec, tm)) 0);
+char_array_0(a);
+printf( Local time: %s\n, a);
-zero(tm);
-assert_se(strftime(a, sizeof(a), %a %Y-%m-%d %H:%M:%S UTC,
gmtime_r(sec, tm)) 0);
-char_array_0(a);
-printf( Universal time: %s\n, a);
+zero(tm);
+assert_se(strftime(a, sizeof(a), %a %Y-%m-%d %H:%M:%S UTC,
gmtime_r(sec, tm)) 0);
+char_array_0(a);
+printf( Universal time: %s\n, a);
+} else {
+printf( Local time: %s\n, n/a);
+printf( Universal time: %s\n, n/a);
+}
if (i-rtc_time 0) {
time_t rtc_sec;
@@ -133,7 +149,7 @@ static void print_status_info(const StatusInfo *i) {
char_array_0(a);
printf(RTC time: %s\n, a);
} else
-printf(RTC time: n/a\n);
+printf(RTC time: %s\n, n/a);
zero(tm);
assert_se(strftime(a, sizeof(a), %Z, %z, localtime_r(sec, tm))
0);
@@ -151,8 +167,8 @@ static void print_status_info(const StatusInfo *i) {
tc, zc, is_dstc,
tn, dn, zn, is_dstn);
if (r 0)
-printf( DST active: n/a\n);
-else {
+printf( DST active: %s\n, n/a);
+else if (have_time) {
printf( DST active: %s\n, yes_no(is_dstc));
t = tc - 1;
@@ -183,7 +199,8 @@ static void print_status_info(const StatusInfo *i) {
free(zc);
free(zn);
-}
+} else
+printf( DST active: %s\n, yes_no(is_dstc));
if (i-rtc_local)
fputs(\n ANSI_HIGHLIGHT_ON
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] install: Assume *.wants symlinks have the same name as their target for scalability.
On Thu, Dec 12, 2013 at 6:23 AM, Lennart Poettering lenn...@poettering.net wrote: This isn't right. Units might be symlinked under different names, we need to support that. For example, all template instances carry a different name for the symlink then for the source. Good point, though we could still support that with smarter matching that doesn't require dereferencing the symlink. Would that work in the mean time? We need to find a different solution here. Maybe introduce a cache object or so where we load everything we find in too and that can be indexed by the target rather then the name of a symlink. I'm up for anything that fixes the timeouts this is causing. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] install: Assume *.wants symlinks have the same name as their target for scalability.
On Wed, Dec 11, 2013 at 8:36 PM, Andrey Borzenkov arvidj...@gmail.com wrote: This completely changes semantic of what it does. In this case no symlink is needed in the first place - just touch .../unit.wants/other.unit would be enough, as long as we assume units can only be located in standard config paths. That's interesting. I hadn't thought of that option. The only downside would be the loss of shell tooling related to finding stale symlinks. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timedatectl: work with old timedated
On Thu, Dec 12, 2013 at 11:02 AM, Lennart Poettering
lenn...@poettering.net wrote:
On Thu, 12.12.13 10:00, Shawn Landden (sh...@churchofgit.com) wrote:
Applied. Dropped the fflush(stderr) bits though as we that's not
necessary for stderr, and not even for stdout if an \n was printed
anyway...
ok, I was worried about the lack of synchronization between stderr and
stdout causing them to interlace.
Thanks!
diff --git a/src/timedate/timedatectl.c b/src/timedate/timedatectl.c
index 9b81513..6b09559 100644
--- a/src/timedate/timedatectl.c
+++ b/src/timedate/timedatectl.c
@@ -98,6 +98,7 @@ static void print_status_info(const StatusInfo *i) {
char s[32];
struct tm tm;
time_t sec;
+bool have_time = false;
char *zc, *zn;
time_t t, tc, tn;
int dn;
@@ -109,20 +110,35 @@ static void print_status_info(const StatusInfo *i) {
/* Enforce the values of /etc/localtime */
if (getenv(TZ)) {
fprintf(stderr, Warning: ignoring the TZ variable, reading
the system's timezone setting only.\n\n);
+fflush(stderr);
unsetenv(TZ);
}
-sec = (time_t) (i-time / USEC_PER_SEC);
+if (i-time != 0) {
+sec = (time_t) (i-time / USEC_PER_SEC);
+have_time = true;
+} else if (arg_transport == BUS_TRANSPORT_LOCAL) {
+sec = time(NULL);
+have_time = true;
+} else {
+fprintf(stderr, Warning: could not get time from timedated
and not operating locally.\n\n);
+fflush(stderr);
+}
-zero(tm);
-assert_se(strftime(a, sizeof(a), %a %Y-%m-%d %H:%M:%S %Z,
localtime_r(sec, tm)) 0);
-char_array_0(a);
-printf( Local time: %s\n, a);
+if (have_time) {
+zero(tm);
+assert_se(strftime(a, sizeof(a), %a %Y-%m-%d %H:%M:%S %Z,
localtime_r(sec, tm)) 0);
+char_array_0(a);
+printf( Local time: %s\n, a);
-zero(tm);
-assert_se(strftime(a, sizeof(a), %a %Y-%m-%d %H:%M:%S UTC,
gmtime_r(sec, tm)) 0);
-char_array_0(a);
-printf( Universal time: %s\n, a);
+zero(tm);
+assert_se(strftime(a, sizeof(a), %a %Y-%m-%d %H:%M:%S
UTC, gmtime_r(sec, tm)) 0);
+char_array_0(a);
+printf( Universal time: %s\n, a);
+} else {
+printf( Local time: %s\n, n/a);
+printf( Universal time: %s\n, n/a);
+}
if (i-rtc_time 0) {
time_t rtc_sec;
@@ -133,7 +149,7 @@ static void print_status_info(const StatusInfo *i) {
char_array_0(a);
printf(RTC time: %s\n, a);
} else
-printf(RTC time: n/a\n);
+printf(RTC time: %s\n, n/a);
zero(tm);
assert_se(strftime(a, sizeof(a), %Z, %z, localtime_r(sec, tm))
0);
@@ -151,8 +167,8 @@ static void print_status_info(const StatusInfo *i) {
tc, zc, is_dstc,
tn, dn, zn, is_dstn);
if (r 0)
-printf( DST active: n/a\n);
-else {
+printf( DST active: %s\n, n/a);
+else if (have_time) {
printf( DST active: %s\n, yes_no(is_dstc));
t = tc - 1;
@@ -183,7 +199,8 @@ static void print_status_info(const StatusInfo *i) {
free(zc);
free(zn);
-}
+} else
+printf( DST active: %s\n, yes_no(is_dstc));
if (i-rtc_local)
fputs(\n ANSI_HIGHLIGHT_ON
Lennart
--
Lennart Poettering, Red Hat
___
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] No security on systemd-journal-gatewayd
On Thu, Dec 12, 2013 at 8:15 AM, Kay Sievers k...@vrfy.org wrote: We must not give the impression that this is secure in any way, it is not, and cannot generally be used unless it is secured by other things. So, no this is not secure at all, just possibly encrypted, but I doubt that was the question. Supporting SSL means it's possible to set up an authority that only signs certificates you want to access the gateway. It's not sophisticated, but it's definitely a usable access-control mechanism. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 6/8] add GOP mode setting and splash drawing support
On Thu, Dec 12, 2013 at 09:51:43AM +0200, Joonas Lahtinen wrote: Hi Greg, I sent another set of patches, this time from command line, and at least I do not observe any line-wrapping with them when viewing the e-mail source. Did they apply fine for you? Yes, it looked fine, I didn't try to apply it yet, sorry. greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] journal: How to limit the file size of runtime system.journal
Hi, In kdump environment, memory resource is quite limited. I find that the runtime journal file (/run/log/journal/$id/system.journal) is 4 MB and I think that is too much for a initramfs context. After tuning both RuntimeMaxUse=1% or RuntimeMaxFileSiz=100K, I find system.journal is still 4 MB in size. So here comes my questions: 1. Did miss use of these two config options? Because regarding the journald.conf(5), it seems I was totally doing it right. 2. If I was doing it wrong, how can I limit this file size? -- Thanks WANG Chao ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journal: How to limit the file size of runtime system.journal
On Fri, Dec 13, 2013 at 01:33:17PM +0800, WANG Chao wrote: Hi, In kdump environment, memory resource is quite limited. I find that the runtime journal file (/run/log/journal/$id/system.journal) is 4 MB and I think that is too much for a initramfs context. After tuning both RuntimeMaxUse=1% or RuntimeMaxFileSiz=100K, I find system.journal is still 4 MB in size. So here comes my questions: 1. Did miss use of these two config options? Because regarding the journald.conf(5), it seems I was totally doing it right. 4MB is the minimum. Those settings are ignored if you set anything lower. 2. If I was doing it wrong, how can I limit this file size? It's not possible below this threshold. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] core: support Distribute=n to distribute to n workers
If Distribute=n, turns SO_REUSEPORT on, and spawns
n workers to handling incoming requests.
SO_REUSEPORT sockets on the same port must all be created
by the same uid, therefore using the option allows
other root programs (or programs of the same user
if running in --user mode) to hijack this port, even
after systemd reserves it.
This patch is currently not ready for merging because it is
possible to do quite a number of operations, and yet have no assurance
that we have accomplished anything, ending up in an
infinite loop respawning a service that never accept()s
the socket passed to it, and therefore leaving our copy
of the socket always in EPOLLIN status. To prevent this we need
to do one of:
*) Call accept() and pass an additional fd to the service.
*) Use EPOLLET: requires event to always dispatched when it comes in.
*) Disable and then reenable the event source (requiring
that we re-create the socket) every time we
enqueue an instance, essentially emulating the behavior
of EPOLLET.
---
TODO | 3 +-
man/systemd.socket.xml| 15 ++-
src/core/dbus-socket.c| 4 +-
src/core/load-fragment-gperf.gperf.m4 | 3 +-
src/core/socket.c | 76 ---
src/core/socket.h | 5 ++-
src/shared/conf-parser.c | 32 +++
src/shared/conf-parser.h | 1 +
8 files changed, 109 insertions(+), 30 deletions(-)
diff --git a/TODO b/TODO
index dad55c4..fbc2609 100644
--- a/TODO
+++ b/TODO
@@ -73,7 +73,7 @@ Features:
* rfkill,backlight: we probably should run the load tools inside of the udev
rules so that the state is properly initialized by the time other software sees
it
-* Add a new Distribute=$NUMBER key to socket units that makes use of
SO_REUSEPORT to distribute network traffic on $NUMBER instances
+* tmpfiles: when applying ownership to /run/log/journal, also do this for the
journal fails contained in it
* move config_parse_path_strv() out of conf-parser.c
@@ -187,7 +187,6 @@ Features:
* teach ConditionKernelCommandLine= globs or regexes (in order to match
foobar={no,0,off})
* Support SO_REUSEPORT with socket activation:
- - Let systemd maintain a pool of servers.
- Use for seamless upgrades, by running the new server before stopping the
old.
diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
index 7c10c58..6799020 100644
--- a/man/systemd.socket.xml
+++ b/man/systemd.socket.xml
@@ -404,7 +404,8 @@
designed for usage with
citerefentryrefentrytitleinetd/refentrytitlemanvolnum8/manvolnum/citerefentry
to work unmodified with systemd socket
-activation./para/listitem
+activation. Incompatible with
+
varnameDistribute=/varname/para/listitem
/varlistentry
varlistentry
@@ -519,6 +520,18 @@
/varlistentry
varlistentry
+termvarnameDistribute=/varname/term
+listitemparaTakes an integer
+value. Systemd will spawn up to
+given number of instances of service each
+listening to the same socket. Default is 0.
+Setting this requires corresponding service to
+be an instansiated service (name ends with
literal@.service/literal).
+Useful with varnameReusePort=/varname
above.
+Incompatible with
varnameAccept=true/varname./para/listitem
+/varlistentry
+
+varlistentry
termvarnameSmackLabel=/varname/term
termvarnameSmackLabelIPIn=/varname/term
termvarnameSmackLabelIPOut=/varname/term
diff --git a/src/core/dbus-socket.c b/src/core/dbus-socket.c
index 74217df..036c9af 100644
--- a/src/core/dbus-socket.c
+++ b/src/core/dbus-socket.c
@@ -40,7 +40,6 @@ static int property_get_listen(
void *userdata,
sd_bus_error *error) {
-
Socket *s = SOCKET(userdata);
SocketPort *p;
int r;
@@ -115,7 +114,8 @@ const sd_bus_vtable bus_socket_vtable[] = {
SD_BUS_PROPERTY(MessageQueueMaxMessages, x, bus_property_get_long,
offsetof(Socket, mq_maxmsg), 0),
SD_BUS_PROPERTY(MessageQueueMessageSize, x, bus_property_get_long,
offsetof(Socket, mq_msgsize), 0),
SD_BUS_PROPERTY(Result, s, property_get_result, offsetof(Socket,
result), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
-SD_BUS_PROPERTY(ReusePort, b,
