Re: [systemd-devel] Revisiting the "ExecRestart" issue
Le vendredi 28 mars 2014 à 12:12 -0500, Brandon Black a écrit : > > Hi all, >I've brought this up before, but I became busy/discouraged and > dropped the ball. As systemd becomes increasingly widely deployed, I > can no longer afford to do so, so I'd like to explore this area a bit > further on the list again and see if we can't come up with a workable > solution, or if perhaps I've missed some systemd/cgroups change in the > past year or so that already allows a workaround. > > [.. snip .. ] > > 4) Socket Activation! I know this is what some will scream when they > skim the above, but it's not a realistic solution in this case for a > few reasons: > a) The startup delay, in some cases, can be many whole wallclock > seconds. This is necessary and acceptable in the general sense (this > is network service that people use with large server-side > installations, not a desktop thing). It only occurs on the first start, no ? > b) The primary socket traffic we care about is UDP, and further we > *really* care about request->response latency for this traffic. Even > if you could set a large enough receive buffer to handle several > seconds of heavy UDP requests (and you can't, for at least some > installations), the multi-second-delay in the responses isn't > reasonable. Again, that's a multiple second delay only for the first start, after, this will be the regular way since the socket is directly used by the daemon. > c) Another side-point that might be better addressed in another > thread: even if both of the above weren't true, this daemon uses > several sockets for multiple "roles" internally, some of which share > all low-level details (e.g. two distinct use-cases for multiple TCP > sockets that serve different high-level protocols, where the user > might choose arbitrary ports for both). I'm not seeing any trivial > way to distinguish these via socket activation - perhaps some kind of > socket "label" that could be accessed by the daemon via sd_* APIs to > distinguish would be useful here? You can use getsockopt to get some information, and match the port/type to the appropriate structure. See https://trac.torproject.org/projects/tor/ticket/8908 for a patch doing that kind of thing for tor. -- Michael Scherer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC PATCH] networkd: add 'search' to resolv.conf
From: Matthew Monaco
---
man/systemd.network.xml | 6 ++
src/network/networkd-manager.c | 3 +++
src/network/networkd-network-gperf.gperf | 1 +
src/network/networkd-network.c | 1 +
src/network/networkd.h | 1 +
5 files changed, 12 insertions(+)
diff --git a/man/systemd.network.xml b/man/systemd.network.xml
index f3b3b31..c2dd145 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -229,6 +229,12 @@
+
DNSSearch=
+
+A space separated list
of search domains.
+
+
+
Bridge=
The name of the bridge
to add the link to.
diff --git a/src/network/networkd-manager.c b/src/network/networkd-manager.c
index b2cb0fa..893b997 100644
--- a/src/network/networkd-manager.c
+++ b/src/network/networkd-manager.c
@@ -447,6 +447,9 @@ int manager_update_resolv_conf(Manager *m) {
append_dns(f, &address->in_addr.in,
address->family, &count);
}
+
+if (link->network->dns_search)
+fprintf(f, "search %s\n",
link->network->dns_search);
}
}
diff --git a/src/network/networkd-network-gperf.gperf
b/src/network/networkd-network-gperf.gperf
index 6ba890f..6929cb6 100644
--- a/src/network/networkd-network-gperf.gperf
+++ b/src/network/networkd-network-gperf.gperf
@@ -34,6 +34,7 @@ Network.IPv4LL, config_parse_bool,
0,
Network.Address, config_parse_address, 0,
0
Network.Gateway, config_parse_gateway, 0,
0
Network.DNS, config_parse_dns, 0,
offsetof(Network, dns)
+Network.DNSSearch, config_parse_string,0,
offsetof(Network, dns_search)
Address.Address, config_parse_address, 0,
0
Address.Broadcast, config_parse_broadcast, 0,
0
Address.Label, config_parse_label, 0,
0
diff --git a/src/network/networkd-network.c b/src/network/networkd-network.c
index 47fab4e..057f86a 100644
--- a/src/network/networkd-network.c
+++ b/src/network/networkd-network.c
@@ -159,6 +159,7 @@ void network_free(Network *network) {
address_free(address);
set_free(network->dns);
+free(network->dns_search);
hashmap_free(network->vlans);
diff --git a/src/network/networkd.h b/src/network/networkd.h
index 8144031..912ae90 100644
--- a/src/network/networkd.h
+++ b/src/network/networkd.h
@@ -136,6 +136,7 @@ struct Network {
Hashmap *routes_by_section;
Set *dns;
+char *dns_search;
LIST_FIELDS(Network, networks);
};
--
1.9.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] kdbus: Check for bloom parameter in "make bus" command
On Sat, Mar 29, 2014 at 5:54 PM, Ingo van Lil wrote: > When handling a KDBUS_CMD_BUS_MAKE command the kernel must make sure > that the message contains a bloom parameter item to avoid a null- > pointer dereference. > > Signed-off-by: Ingo van Lil > --- > bus.c | 2 +- Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] gummiboot: build-sys: don't copy .eh_frame into final exe
On Sat, Mar 29, 2014 at 7:22 PM, Florian Albrechtskirchinger wrote: > Apparently some firmware implementations[1] won't run executables > containing an .eh_frame section, failing instead with "Error reported: > Unsupported" on the shell. There's also no obvious need for it, so > don't copy it. > > [1] e.g., the one used on the ASRock C2750D4I > --- > Makefile.am | 2 +- Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] gummiboot: build-sys: don't copy .eh_frame into final exe
Apparently some firmware implementations[1] won't run executables containing an .eh_frame section, failing instead with "Error reported: Unsupported" on the shell. There's also no obvious need for it, so don't copy it. [1] e.g., the one used on the ASRock C2750D4I --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index d224418..d004bdd 100644 --- a/Makefile.am +++ b/Makefile.am @@ -144,7 +144,7 @@ $(efi_solib): $(efi_objects) $(efi_loadername): $(efi_solib) $(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \ - -j .dynsym -j .rel -j .rela -j .reloc -j .eh_frame \ + -j .dynsym -j .rel -j .rela -j .reloc \ --target=efi-app-$(ARCH) $< $@ # -- -- 1.9.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd not correctly handle audio device acls for the active session?
On Sat, Mar 29, 2014 at 4:13 AM, Kawing Chiu wrote: > Thanks, now I understand where does the problem come from. > > So, is that simply not achievable in systemd? I mean, since logind "has no > way to know about my session on vt7", then what about I *tell* it > explicitly? Maybe through some cmdline tools, for example, something like: > `loginctl add-vt vt7 session03`, or through proper configuration of logind? > Or can I just spawn startx in a new session that is associative with vt7, > i.e. something like `systemd-setsid startx -- vt7`? No, there is no option for that. (As a workaround, if you require X11 on vt7, you can start getty@tty7.service, and startx there.) -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] kdbus: Check for bloom parameter in "make bus" command
When handling a KDBUS_CMD_BUS_MAKE command the kernel must make sure that the message contains a bloom parameter item to avoid a null- pointer dereference. Signed-off-by: Ingo van Lil --- bus.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bus.c b/bus.c index 8c4efda..9fea643 100644 --- a/bus.c +++ b/bus.c @@ -359,7 +359,7 @@ int kdbus_bus_make_user(const struct kdbus_cmd_make *make, if (!KDBUS_ITEMS_END(item, make->items, KDBUS_ITEMS_SIZE(make, items))) return -EINVAL; - if (!n) + if (!n || !bl) return -EBADMSG; if (bl->size < 8 || bl->size > KDBUS_BUS_BLOOM_MAX_SIZE) -- 1.9.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: networkd failed to run
On Sat, Mar 29, 2014 at 8:49 AM, Andrew Rose wrote: > networkd: error while loading shared libraries: librt.so.1: cannot open > shared object file: Permission denied I guess the lbrt library is missing? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Fwd: networkd failed to run
I have custom linux build with kernel and some utils (coreutils, util-linux, network utils), i build systemd with option; ./configure --prefix=/ --host="$HOST" CFLAGS="-g -O0 -ftrapv -I$SYSROOT/usr/include/" \ --disable-manpage \ --disable-xattr \ --without-python \ --disable-gudev \ --disable-gcrypt \ --disable-tests \ --disable-pam \ --with-dbuspolicydir="/etc/" \ --with-dbussystemservicedir="/usr/etc/" then i try run networkd-serviced. i get strange error Mar 26 20:08:16 localhost systemd-networkd[216]: /usr/lib/systemd/systemd-networkd: error while loading shared libraries: librt.so.1: cannot open shared object file: Permission denied Mar 26 20:08:16 localhost systemd[1]: systemd-networkd.service: main process exited, code=exited, status=127/n/a Mar 26 20:08:16 localhost systemd[1]: Failed to start Network Service. Mar 26 20:08:16 localhost systemd[1]: Unit systemd-networkd.service entered failed state. Mar 26 20:08:16 localhost systemd[1]: systemd-networkd.service has no holdoff time, scheduling restart. Mar 26 20:08:16 localhost systemd[1]: Stopping Network Service... Mar 26 20:08:16 localhost systemd[1]: Starting Network Service... Mar 26 20:08:16 localhost systemd[1]: systemd-networkd.service start request repeated too quickly, refusing to start. Mar 26 20:08:16 localhost systemd[1]: Failed to start Network Service. Mar 26 20:08:16 localhost systemd[1]: Unit systemd-networkd.service entered failed state. when i use version systemd version 210 network work fine but i try version from git nevest 210 i always get this error strace log: http://pastebin.com/raw.php?i=7jTcGKzg ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
