Re: [systemd-devel] Pairing udev's SYSTEMD_WANTS and systemd's templated units
On Thursday 14 August 2014 at 01:55:26, Lennart Poettering wrote:
On Thu, 31.07.14 16:55, Ivan Shapovalov (intelfx...@gmail.com) wrote:
Hello all,
I'm trying to start from an udev rule a templated systemd unit, whose
instance
should be a properly escaped device node path (so that %i.device would
represent
an existing unit). Which udev specifier should I use for this?
Or, in more clear wording:
given the rule:
ACTION==add, ..., TAG+=systemd,
ENV{SYSTEMD_WANTS}+=foo@$some_specifier.service
and the unit foo@.service:
[Unit]
After=%i.device
BindsTo=%i.device
...
Which $some_specifier should I use in the udev rule to get %i.device in
my service file to refer to the valid and corresponding device unit?
The closest match I've got is sys%p, but it does not work because dashes
are not
escaped, and I get
sys-devices-pci:00-:00:1d.0-usb4-4-1-4-1.2.device
instead of
sys-devices-pci:00-:00:1d.0-usb4-4\x2d1-4\x2d1.2.device
and so on.
Can you invoke systemd-escape from the udev rule?
Lennart
Yes, (built systemd from git) it seems to work.
/etc/udev/rules.d/99-foo.rules:
ACTION==add, ..., TAG+=systemd, PROGRAM=/usr/bin/systemd-escape -p
%S%p, ENV{SYSTEMD_WANTS}+=foo@%c.service
/etc/systemd/system/foo@.service:
[Unit]
Description=Test unit for %f
BindsTo=%i.device
After=%i.device
[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/etc/systemd/scripts/foo.sh %f
The only thing: PROGRAM=..., ENV{SYSTEMD_WANTS}+=...%c... idiom seems a
pretty ugly way to invoke systemd-escape. This looks like a pretty common
thing to do; shouldn't there be a shorthand or something? (just a suggestion)
Thanks!
--
Ivan Shapovalov / intelfx /
signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] socket: add support for TCP fast Open
TCP Fast Open (TFO) speeds up the opening of successiveTCP)
connections between two endpoints.It works by using a TFO cookie
in the initial SYN packet to authenticate a previously connected
client. It starts sending data to the client before the receipt
of the final ACK packet of the three way handshake is received,
skipping a round trip and lowering the latency in the start of
transmission of data.
---
man/systemd.socket.xml| 15 +++
src/core/dbus-socket.c| 1 +
src/core/load-fragment-gperf.gperf.m4 | 1 +
src/core/socket.c | 8
src/core/socket.h | 1 +
5 files changed, 26 insertions(+)
diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
index 352825f..170d010 100644
--- a/man/systemd.socket.xml
+++ b/man/systemd.socket.xml
@@ -499,6 +499,21 @@
/varlistentry
varlistentry
+termvarnameFastOpen=/varname/term
+listitemparaTakes a boolean
+argument. It works by using a TFO cookie (a
TCP option) in the initial
+SYN packet to authenticate a previously
connected client. If successful,
+it may start sending data to the client before
the receipt of the final
+ACK packet of the three way handshake is
received, skipping a round trip
+and lowering the latency in the start of
transmission of data.
+This controls the TCP_FASTOPEN socket option
(see
+the ulink
url=http://lwn.net/Articles/508865/;TCP
+Fast Open: expediting web services/ulink for
details.)
+Defaults to
+optionfalse/option./para/listitem
+/varlistentry
+
+varlistentry
termvarnamePriority=/varname/term
listitemparaTakes an integer
argument controlling the priority for
diff --git a/src/core/dbus-socket.c b/src/core/dbus-socket.c
index ad135a1..71c0115 100644
--- a/src/core/dbus-socket.c
+++ b/src/core/dbus-socket.c
@@ -97,6 +97,7 @@ const sd_bus_vtable bus_socket_vtable[] = {
SD_BUS_PROPERTY(DirectoryMode, u, bus_property_get_mode,
offsetof(Socket, directory_mode), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(Accept, b, bus_property_get_bool, offsetof(Socket,
accept), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(KeepAlive, b, bus_property_get_bool,
offsetof(Socket, keep_alive), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(FastOpen , b, bus_property_get_bool,
offsetof(Socket, fast_open), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(Priority, i, bus_property_get_int,
offsetof(Socket, priority), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(ReceiveBuffer, t, bus_property_get_size,
offsetof(Socket, receive_buffer), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(SendBuffer, t, bus_property_get_size,
offsetof(Socket, send_buffer), SD_BUS_VTABLE_PROPERTY_CONST),
diff --git a/src/core/load-fragment-gperf.gperf.m4
b/src/core/load-fragment-gperf.gperf.m4
index f4acdda..08d0593 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -232,6 +232,7 @@ Socket.Accept, config_parse_bool,
0,
Socket.MaxConnections, config_parse_unsigned, 0,
offsetof(Socket, max_connections)
Socket.KeepAlive,config_parse_bool, 0,
offsetof(Socket, keep_alive)
Socket.NoDelay, config_parse_bool, 0,
offsetof(Socket, no_delay)
+Socket.FastOpen, config_parse_bool, 0,
offsetof(Socket, fast_open)
Socket.Priority, config_parse_int, 0,
offsetof(Socket, priority)
Socket.ReceiveBuffer,config_parse_iec_size, 0,
offsetof(Socket, receive_buffer)
Socket.SendBuffer, config_parse_iec_size, 0,
offsetof(Socket, send_buffer)
diff --git a/src/core/socket.c b/src/core/socket.c
index 5af1596..44827ad 100644
--- a/src/core/socket.c
+++ b/src/core/socket.c
@@ -481,6 +481,7 @@ static void socket_dump(Unit *u, FILE *f, const char
*prefix) {
%sDirectoryMode: %04o\n
%sKeepAlive: %s\n
%sNoDelay: %s\n
+%sFastOpen: %s\n
%sFreeBind: %s\n
%sTransparent: %s\n
Re: [systemd-devel] [PATCH] resolved: re-add support for getting local domain from DHCP
On Aug 14, 2014 1:21 AM, Lennart Poettering lenn...@poettering.net
wrote:
On Mon, 04.08.14 10:05, Michael Marineau (michael.marin...@coreos.com)
wrote:
Patch looks pretty good, though I'd really prefer if we could do the
UseDomain= thing as discussed in the other mail, and not propagate
DHCP-supplied domain names unless explicitly requested.
This would means we probably mean we'd need two new sd-network.h calls:
int sd_network_get_link_route_domains(int ifindex, char **domains);
int sd_network_get_link_search_domains(int ifindex, char **domains);
The former would return the list of domains whose requests shall be
routed to the specified interface, and the latter would be the list of
domains we actively use for searching single-label domains in.
Any domains configured statically for a link in the .network files would
be listed in both lists. And depending on the UseDomains= settings the
dhcp provides domains might be listed on none, both or only one of
them. or something like that...
src/network/networkd-link.c| 9 +
src/network/sd-network.c | 24
src/resolve/resolved-link.c| 20
src/resolve/resolved-link.h| 2 ++
src/resolve/resolved-manager.c | 10 +-
src/systemd/sd-network.h | 3 +++
6 files changed, 67 insertions(+), 1 deletion(-)
diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
index 172be64..42d528f 100644
--- a/src/network/networkd-link.c
+++ b/src/network/networkd-link.c
@@ -2385,6 +2385,15 @@ int link_save(Link *link) {
(address + 1 ? : ));
fputs(\n, f);
+
+if (link-network-dhcp_domainname
+link-dhcp_lease) {
+const char *domainname;
+
+r =
sd_dhcp_lease_get_domainname(link-dhcp_lease, domainname);
+if (r = 0)
+fprintf(f, DOMAINNAME=%s\n,
domainname);
THis should be plural really, from the beginning. After all the newer
DHCP specs allow a full list... and we want to allow a full list to be
provided in the .network files too...
Lennart
--
Lennart Poettering, Red Hat
Right now the search domains DHCP option is unsupported so it is indeed
singular. Also I had assumed since search domains is both a different DHCP
option and a different resolve.conf option that they would be recorded
separately but I suppose the two options is more of a legacy artifact than
meaningful distinction so it is equally as valid to squash them together
into the search domain list. I am happy to write a follow up patch to
implement the search domains option and support providing additional
domains in the .network file but I think this patch can stand alone since
it fixes a regression.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/3] socket: Add support for TCP Fast Open
Hi Lennart, On 08/14/2014 06:16 AM, Lennart Poettering wrote: On Tue, 29.07.14 23:10, Susant Sahani (sus...@redhat.com) wrote: Looks good. Wanted to apply. But this requires your previous patch, so please rebase on a new version of that! Thanks! Since this patch does not depend on the other patches I merged it with the current code. Susant ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options
On Wed, Aug 13, 2014 at 06:42:13PM +0200, Lennart Poettering wrote: On Wed, 13.08.14 16:43, Marc Haber (mh+systemd-de...@zugschlus.de) wrote: did I reach the wrong mailing list? Is there better forum to get systemd working with something resembling my current setup? No, this is the right place. But I just have a huge backlog of threads to reply to on the ML. I am slowly working on catching up now, in preparation for a new release. Ok, I'll sit back quietly ;-) Maybe somebody else cares to comment? Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Implementing resume from hibernation as a systemd unit file
On Thu, 14.08.14 09:20, Ivan Shapovalov (intelfx...@gmail.com) wrote: The udev rule should be possible (provided that udevd does not need rootfs remounted read-write -- I'd like to preserve some decency towards initrd-less systems), but udev is a framework for handling events, whereas we don't have any events here: such symlink can be derived from kernel command-line alone, statically. udev is totally fine with read-only everything. It just needs writable /run. Yes, a udev rule would allow to create a symlink which is tracked by systemd, so the dev-disk-resume.device appears and then it can be easily After='ed from the resume unit, but... really, is udev the proper tool for this? The symlink thing we already do in a very similar way for the gpt auto root logic (see 60-persistent-storage.rules) already, so there's prior art. Actually, the main question is how to order the resume unit. It needs to run before any real filesystems are mounted (speaking in terms of initrd) AND before rootfs is remounted read-write (speaking in terms of initrd-less system), but after whatever is needed to make the device node appear. You could turn this into a generator, that pulls the switch from the kernel cmdline, and generates a service that orders itself before local-fs-pre.taret and after the device you need. The device you need you give a stable name via an udev rule. That's pretty much exactly how the got auto root thing works... 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] Pairing udev's SYSTEMD_WANTS and systemd's templated units
On Thu, 14.08.14 10:02, Ivan Shapovalov (intelfx...@gmail.com) wrote:
The only thing: PROGRAM=..., ENV{SYSTEMD_WANTS}+=...%c... idiom seems a
pretty ugly way to invoke systemd-escape. This looks like a pretty common
thing to do; shouldn't there be a shorthand or something? (just a suggestion)
Yeah, I agree, but I not entirely sure how this could look like in a
nice way?
Maybe add:
ENV{SYSTEMD_WANTS_INSTANCE}=bar
ENV{SYSTEMD_WANTS_TEMPLATE}=foo@.service
or so, would escape bar and add it into foo@.service... But that's not
particularly generic but focusses only on the instance/template case...
Ideas?
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] resolved: re-add support for getting local domain from DHCP
On Thu, 14.08.14 02:21, Lennart Poettering (lenn...@poettering.net) wrote: On Mon, 04.08.14 10:05, Michael Marineau (michael.marin...@coreos.com) wrote: Patch looks pretty good, though I'd really prefer if we could do the UseDomain= thing as discussed in the other mail, and not propagate DHCP-supplied domain names unless explicitly requested. This would means we probably mean we'd need two new sd-network.h calls: int sd_network_get_link_route_domains(int ifindex, char **domains); int sd_network_get_link_search_domains(int ifindex, char **domains); The former would return the list of domains whose requests shall be routed to the specified interface, and the latter would be the list of domains we actively use for searching single-label domains in. Any domains configured statically for a link in the .network files would be listed in both lists. And depending on the UseDomains= settings the dhcp provides domains might be listed on none, both or only one of them. or something like that... So, I have thought about this a bit more over night... I think this would still be too complicated, and I don't really see the need to make the dhcp search thing that configurable. I see no risk in strictly making single-label host names searchable in all configured domains of the interface and nothing else... I think I am back at suggesting that there should be the follow .network settings: [Network] Domains=0pointer.de redhat.com [DHCP] UseDomains=yes|no And one sd-network function: int sd_network_get_link_domains(int ifindex, char **domains); And that should be it. UseDomain= should have the effect of adding the domains from dhcp option 15 and 119 to the list of domains for the interface. And sd_network_get_link_domains() should then return a single list, of deduplicated entries, with the domains specified in Domains= first, and then the dhcp domains possible added in at the end. Zbigniew, I think this simplification would be beneficial, as I really don't see the need to make the search vs. route domain thing configurable Tom, what's your take on all of this? The domain data from DHCP should be thoroughly verified btw. For example, if is_hostname() is true for some domain acquired via DHCP we should ignore it, and we should make sure that the domain name is actually valid, and so 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] [PATCH] bus.h: add missing include to linux/kref.h
Symptoms: kdbus/bus.h:56:14: error: field ‘kref’ has incomplete type struct kref kref; Signed-off-by: Alban Crequy alban.cre...@collabora.co.uk --- bus.h | 1 + 1 file changed, 1 insertion(+) diff --git a/bus.h b/bus.h index a5832b8..c7ce2fa 100644 --- a/bus.h +++ b/bus.h @@ -16,6 +16,7 @@ #include linux/hashtable.h #include linux/spinlock.h #include linux/idr.h +#include linux/kref.h #include util.h -- 1.8.5.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] socket: Add Support for TCP keep alive variables
On 08/14/2014 06:13 AM, Lennart Poettering wrote: On Tue, 29.07.14 23:10, Susant Sahani (sus...@redhat.com) wrote: tcp_keepalive_time: The number of seconds a connection needs to be idle before TCP begins sending out keep-alive probes. Looks pretty OK. --- varlistentry + termvarnameKeepAliveTime=/varname/term + listitemparaTakes time (in seconds) as argument . The connection needs to remain ^ there's a spurious space too much here... Removed . + idle before TCP starts sending keepalive probes. This controls the TCP_KEEPIDLE + socket option (see +/varlistentry Could you indent this like the rest of the settings, please? Ok +SD_BUS_PROPERTY(KeepAliveTime, t, bus_property_get_usec, offsetof(Socket, keep_alive_time), SD_BUS_VTABLE_PROPERTY_CONST), +SD_BUS_PROPERTY(KeepAliveInterval, t, bus_property_get_usec, offsetof(Socket, keep_alive_interval), SD_BUS_VTABLE_PROPERTY_CONST), +SD_BUS_PROPERTY(KeepAliveProbes, i, bus_property_get_int, offsetof(Socket, keep_alive_cnt), SD_BUS_VTABLE_PROPERTY_CONST), This should really be an u and use bus_property_get_unsigned(), no? I mean, there is no negative count possible, is there? Yes :) +if(s-keep_alive_time) +fprintf(f, +%sKeepAliveTime: %lo\n, +prefix, s-keep_alive_time / USEC_PER_SEC); Please format this with format_timespan()! made the changes Otherwise looks good! Lennart Re-sending Both the patches . Thanks for reviewing. Susant ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] [RFC] [WIP] [kdbus] Attempt to recursively pass fd
Before Linux commit 25888e (from 2.6.37-rc4, Nov 2010), fd-passing on Unix
sockets could recursively be stacked, allowing a process to exhaust the open
files limit (/proc/sys/fs/file-max) on the system without restriction from
ulimit -n.
This DoS on Unix sockets was fixed by commit:
commit 25888e30319f8896fc656fc68643e6a078263060
Author: Eric Dumazet eric.duma...@gmail.com
Date: Thu Nov 25 04:11:39 2010 +
af_unix: limit recursion level
But that commit introduced a bug in dbus:
https://bugs.freedesktop.org/show_bug.cgi?id=80163
kdbus does not use fd-passing on Unix sockets so it is not affected by this.
However, it allows fd-passing similarly. This patch shows it is possible to
recursively pass file descriptors in kdbus and stack them without keeping them
attached to the initial process. I could stack passed fds 256 times, probably
because of the limit KDBUS_USER_MAX_CONN:
defaults.h:#define KDBUS_USER_MAX_CONN 256
But this limit could probably be overrided by using fds from different
endpoints.
I am also afraid that fds from Unix sockets and fds from kdbus could be stacked
together, defeating the limit implemented in unix_attach_fds() by commit 25888e
because the check uses unix_get_socket(), making the assumption that only Unix
sockets could carry file descriptors:
http://lxr.free-electrons.com/source/net/unix/af_unix.c#L1380
http://lxr.free-electrons.com/source/net/unix/garbage.c#L99
---
test/test-kdbus.c | 72 +++
1 file changed, 72 insertions(+)
diff --git a/test/test-kdbus.c b/test/test-kdbus.c
index f0bf705..3c79877 100644
--- a/test/test-kdbus.c
+++ b/test/test-kdbus.c
@@ -12,6 +12,8 @@
#include limits.h
#include sys/mman.h
#include sys/ioctl.h
+#include sys/types.h
+#include sys/socket.h
#include getopt.h
#include stdbool.h
@@ -1004,6 +1006,75 @@ static int check_msg_basic(struct kdbus_check_env *env)
return CHECK_OK;
}
+static int send_fds(struct conn *conn, uint64_t dst_id, int fds[2])
+{
+ struct kdbus_msg *msg;
+ struct kdbus_item *item;
+ uint64_t size;
+ int ret;
+
+ size = sizeof(struct kdbus_msg);
+ size += KDBUS_ITEM_SIZE(sizeof(int[2]));
+
+ msg = malloc(size);
+ ASSERT_RETURN (msg != NULL);
+
+ memset(msg, 0, size);
+ msg-size = size;
+ msg-src_id = conn-id;
+ msg-dst_id = dst_id;
+ msg-payload_type = KDBUS_PAYLOAD_DBUS;
+
+ item = msg-items;
+
+ item-type = KDBUS_ITEM_FDS;
+ item-size = KDBUS_ITEM_HEADER_SIZE + sizeof(int[2]);
+ item-fds[0] = fds[0];
+ item-fds[1] = fds[1];
+ item = KDBUS_ITEM_NEXT(item);
+
+ ret = ioctl(conn-fd, KDBUS_CMD_MSG_SEND, msg);
+ if (ret) {
+ fprintf(stderr, error sending message: %d err %d (%m)\n, ret,
errno);
+ return EXIT_FAILURE;
+ }
+
+ free(msg);
+
+ return 0;
+}
+
+static int check_fds_passing(struct kdbus_check_env *env)
+{
+ struct conn *conn_src, *conn_dst;
+ int fds[2];
+ int ret;
+ int i;
+
+ /* create two connections */
+ conn_src = kdbus_hello(env-buspath, 0, NULL, 0);
+ ASSERT_RETURN(conn_src != NULL);
+
+ for (i = 0; i = 0; i++) {
+ conn_dst = kdbus_hello(env-buspath, 0, NULL, 0);
+ ASSERT_RETURN(conn_dst != NULL);
+
+ fds[0] = conn_src-fd;
+ fds[1] = conn_dst-fd;
+
+ ret = send_fds (conn_src, conn_dst-id, fds);
+ printf(check_fds_passing: iter: %d fds %d-%d ret %d err %d
(%m)\n, i, fds[0], fds[1], ret, errno);
+ ASSERT_RETURN(ret == 0);
+
+ close(conn_src-fd);
+ free(conn_src);
+
+ conn_src = conn_dst;
+ }
+
+ return CHECK_OK;
+}
+
static int check_msg_free(struct kdbus_check_env *env)
{
int ret;
@@ -,6 +1182,7 @@ static const struct kdbus_check checks[] = {
{ name queue, check_name_queue,
CHECK_CREATE_BUS | CHECK_CREATE_CONN},
{ message basic, check_msg_basic,
CHECK_CREATE_BUS | CHECK_CREATE_CONN},
{ message free, check_msg_free,
CHECK_CREATE_BUS | CHECK_CREATE_CONN},
+ { fds passing,check_fds_passing,
CHECK_CREATE_BUS},
{ connection info,check_conn_info,
CHECK_CREATE_BUS | CHECK_CREATE_CONN},
{ match id add, check_match_id_add,
CHECK_CREATE_BUS | CHECK_CREATE_CONN},
{ match id remove,check_match_id_remove,
CHECK_CREATE_BUS | CHECK_CREATE_CONN},
--
1.8.5.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] socket: add support for TCP fast Open
On Thu, 14.08.14 14:31, Susant Sahani (sus...@redhat.com) wrote:
Thanks! Applied!
TCP Fast Open (TFO) speeds up the opening of successiveTCP)
connections between two endpoints.It works by using a TFO cookie
in the initial SYN packet to authenticate a previously connected
client. It starts sending data to the client before the receipt
of the final ACK packet of the three way handshake is received,
skipping a round trip and lowering the latency in the start of
transmission of data.
---
man/systemd.socket.xml| 15 +++
src/core/dbus-socket.c| 1 +
src/core/load-fragment-gperf.gperf.m4 | 1 +
src/core/socket.c | 8
src/core/socket.h | 1 +
5 files changed, 26 insertions(+)
diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
index 352825f..170d010 100644
--- a/man/systemd.socket.xml
+++ b/man/systemd.socket.xml
@@ -499,6 +499,21 @@
/varlistentry
varlistentry
+termvarnameFastOpen=/varname/term
+listitemparaTakes a boolean
+argument. It works by using a TFO cookie (a
TCP option) in the initial
+SYN packet to authenticate a previously
connected client. If successful,
+it may start sending data to the client
before the receipt of the final
+ACK packet of the three way handshake is
received, skipping a round trip
+and lowering the latency in the start of
transmission of data.
+This controls the TCP_FASTOPEN socket option
(see
+the ulink
url=http://lwn.net/Articles/508865/;TCP
+Fast Open: expediting web services/ulink
for details.)
+Defaults to
+optionfalse/option./para/listitem
+/varlistentry
+
+varlistentry
termvarnamePriority=/varname/term
listitemparaTakes an integer
argument controlling the priority for
diff --git a/src/core/dbus-socket.c b/src/core/dbus-socket.c
index ad135a1..71c0115 100644
--- a/src/core/dbus-socket.c
+++ b/src/core/dbus-socket.c
@@ -97,6 +97,7 @@ const sd_bus_vtable bus_socket_vtable[] = {
SD_BUS_PROPERTY(DirectoryMode, u, bus_property_get_mode,
offsetof(Socket, directory_mode), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(Accept, b, bus_property_get_bool,
offsetof(Socket, accept), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(KeepAlive, b, bus_property_get_bool,
offsetof(Socket, keep_alive), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(FastOpen , b, bus_property_get_bool,
offsetof(Socket, fast_open), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(Priority, i, bus_property_get_int,
offsetof(Socket, priority), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(ReceiveBuffer, t, bus_property_get_size,
offsetof(Socket, receive_buffer), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(SendBuffer, t, bus_property_get_size,
offsetof(Socket, send_buffer), SD_BUS_VTABLE_PROPERTY_CONST),
diff --git a/src/core/load-fragment-gperf.gperf.m4
b/src/core/load-fragment-gperf.gperf.m4
index f4acdda..08d0593 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -232,6 +232,7 @@ Socket.Accept, config_parse_bool,
0,
Socket.MaxConnections, config_parse_unsigned, 0,
offsetof(Socket, max_connections)
Socket.KeepAlive,config_parse_bool, 0,
offsetof(Socket, keep_alive)
Socket.NoDelay, config_parse_bool, 0,
offsetof(Socket, no_delay)
+Socket.FastOpen, config_parse_bool, 0,
offsetof(Socket, fast_open)
Socket.Priority, config_parse_int, 0,
offsetof(Socket, priority)
Socket.ReceiveBuffer,config_parse_iec_size, 0,
offsetof(Socket, receive_buffer)
Socket.SendBuffer, config_parse_iec_size, 0,
offsetof(Socket, send_buffer)
diff --git a/src/core/socket.c b/src/core/socket.c
index 5af1596..44827ad 100644
--- a/src/core/socket.c
+++ b/src/core/socket.c
@@ -481,6 +481,7 @@ static void socket_dump(Unit *u, FILE *f, const char
*prefix) {
%sDirectoryMode: %04o\n
Re: [systemd-devel] [PATCH] resolved: re-add support for getting local domain from DHCP
On Thu, Aug 14, 2014 at 1:11 PM, Lennart Poettering lenn...@poettering.net wrote: UseDomain= should have the effect of adding the domains from dhcp option 15 and 119 to the list of domains for the interface. And sd_network_get_link_domains() should then return a single list, of deduplicated entries, with the domains specified in Domains= first, and then the dhcp domains possible added in at the end. Zbigniew, I think this simplification would be beneficial, as I really don't see the need to make the search vs. route domain thing configurable Tom, what's your take on all of this? Sorry for taking forever to answer to this thread. I have been going back and forth in my mind about how this should look. I think in the end I essentially agree with Lennart's last suggestion. Let's make this dead-simple and collapse the search/route domains for each link into a single list. I think this is fine given that we restrict the search behaviour to single-labels. My only hesitation has been that I can imagine someone wanting to add search domains that do not imply anything about routing. However, I think in this case it does not make much sense to make this per-link, but it should rather be a global SearchDomains= option (in resolved.conf) or something to that effect. Zbigniew, Michael, what do you think? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] resolved: re-add support for getting local domain from DHCP
On Thu, 14.08.14 13:27, Tom Gundersen (t...@jklm.no) wrote: On Thu, Aug 14, 2014 at 1:11 PM, Lennart Poettering lenn...@poettering.net wrote: UseDomain= should have the effect of adding the domains from dhcp option 15 and 119 to the list of domains for the interface. And sd_network_get_link_domains() should then return a single list, of deduplicated entries, with the domains specified in Domains= first, and then the dhcp domains possible added in at the end. Zbigniew, I think this simplification would be beneficial, as I really don't see the need to make the search vs. route domain thing configurable Tom, what's your take on all of this? Sorry for taking forever to answer to this thread. I have been going back and forth in my mind about how this should look. I think in the end I essentially agree with Lennart's last suggestion. Let's make this dead-simple and collapse the search/route domains for each link into a single list. I think this is fine given that we restrict the search behaviour to single-labels. My only hesitation has been that I can imagine someone wanting to add search domains that do not imply anything about routing. However, I think in this case it does not make much sense to make this per-link, but it should rather be a global SearchDomains= option (in resolved.conf) or something to that effect. Zbigniew, Michael, what do you think? Tom reminded me of the fact now, that at the systemd hackfest in Brno last week (which really was more a talkfest) people suggested we should actually make it possible that if you go to lets say xhamster.com you never ever want this to be resolved via the redhat VPN. That probably makes a lot of sense. Hence, I would suggest adding a syntax of: [Network] Domains=* which would have the effect to route all DNS traffic that is not explicitly routed somewhereelse to this interface. Internally, this would just set a boolean, which could be queried with: int sd_network_link_get_wildcard_domain(int ifindex); or so, which would return 0 or 1 or negative -errno... But then again, this doesn't have to be there from day one, we can add that later... But of course, I'd love to see this done early on, too, after all the porn usecase is a major one. 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.h: add missing include to linux/kref.h
On 08/14/2014 01:13 PM, Alban Crequy wrote: Symptoms: kdbus/bus.h:56:14: error: field ‘kref’ has incomplete type struct kref kref; Signed-off-by: Alban Crequy alban.cre...@collabora.co.uk Strange I don't see this error here. Anyway, applied. Thanks! --- bus.h | 1 + 1 file changed, 1 insertion(+) diff --git a/bus.h b/bus.h index a5832b8..c7ce2fa 100644 --- a/bus.h +++ b/bus.h @@ -16,6 +16,7 @@ #include linux/hashtable.h #include linux/spinlock.h #include linux/idr.h +#include linux/kref.h #include util.h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] networkd losing dhcp lease with dracut / nfs root
On Tue, Jul 15, 2014 at 3:50 AM, Rich Freeman r-syst...@thefreemanclan.net wrote: not update valid_lft A minute later it again renews DHCP, but also does not update valid_lft. 51 seconds later it again renews DHCP, and this time it updates valid_lft. So, the interface never drops, but it isn't really maintaining valid_lft at all points where it could. I don't know what would have happened if it didn't get the lease at the last update - at that point there was around 30s left. I guess I could test that if necessary by shutting down the dhcp server. Hi Rich, Sorry for not getting back to you sooner. I had another look a this, and I cannot reproduce. Whenever my DHCP lease is renewed, this is immediately reflected in the lft_valid. I added a bit more debugging to networkd, so if you are able to reproduce this with current git, please post your debug logs. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] race conditions after SIGTERM
On Sun, 27.07.14 19:53, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Sat, Jul 26, 2014 at 02:46:05PM +0200, Reindl Harald wrote: after that happend a few minutes ago systemd on F19: https://bugzilla.redhat.com/show_bug.cgi?id=1123557 since the sleep 1 was enough over months and now sleep 6 between systemctl stop and rsync is also not relieable my only conclusion is that systemd don't care about the still running MAINPID of type=simple and in case of a existing ExecStopPost the logic is correct Hi, PIDFile with Type=simple is not supported. Adding support would be tricky, because with Type=simple there's no obvious mechanism to notify systemd *when* to read the file. With Type=forking, when the first process exits, systemd knows it can read the file. It could be done with inotify maybe. A long-standing item on the TODO list is to add a new Type=pid-file or so that waits for a PID file to appear and uses that as indication when a daemon is up, or dies. I figure the example above would be a good case for this. 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] race conditions after SIGTERM
On Sun, 27.07.14 20:04, Reindl Harald (h.rei...@thelounge.net) wrote: but that still don't explain why ExecStopPost=/sur/bin/true or whatever ExecStopPost solves that and if it is not supported why systemctl don't return after the one and only process exited Well, this is a misunderstanding how ExecStop= and friends are supposed to work. They are supposed to do what they did on sysvinit: synchronously terminate a service. And not asynchronously do that. We hence don't wait for anything else then, because what is left afterwards must be left-over processes that ExecStop= and friends couldn't clean up properly... 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] resolved: re-add support for getting local domain from DHCP
On Thu, Aug 14, 2014 at 1:47 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 14.08.14 13:27, Tom Gundersen (t...@jklm.no) wrote: On Thu, Aug 14, 2014 at 1:11 PM, Lennart Poettering lenn...@poettering.net wrote: UseDomain= should have the effect of adding the domains from dhcp option 15 and 119 to the list of domains for the interface. And sd_network_get_link_domains() should then return a single list, of deduplicated entries, with the domains specified in Domains= first, and then the dhcp domains possible added in at the end. Zbigniew, I think this simplification would be beneficial, as I really don't see the need to make the search vs. route domain thing configurable Tom, what's your take on all of this? Sorry for taking forever to answer to this thread. I have been going back and forth in my mind about how this should look. I think in the end I essentially agree with Lennart's last suggestion. Let's make this dead-simple and collapse the search/route domains for each link into a single list. I think this is fine given that we restrict the search behaviour to single-labels. My only hesitation has been that I can imagine someone wanting to add search domains that do not imply anything about routing. However, I think in this case it does not make much sense to make this per-link, but it should rather be a global SearchDomains= option (in resolved.conf) or something to that effect. Zbigniew, Michael, what do you think? Tom reminded me of the fact now, that at the systemd hackfest in Brno last week (which really was more a talkfest) people suggested we should actually make it possible that if you go to lets say xhamster.com you never ever want this to be resolved via the redhat VPN. That probably makes a lot of sense. Hence, I would suggest adding a syntax of: [Network] Domains=* which would have the effect to route all DNS traffic that is not explicitly routed somewhereelse to this interface. Internally, this would just set a boolean, which could be queried with: int sd_network_link_get_wildcard_domain(int ifindex); or so, which would return 0 or 1 or negative -errno... But then again, this doesn't have to be there from day one, we can add that later... But of course, I'd love to see this done early on, too, after all the porn usecase is a major one. As discussed off-list, I agree with adding this API / behaviour. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to get rid of this ordering cycle?
Hi, I have Debian Testing running with some additional packages from Linux Mint which are installed for testing purposes. One of them is mintsystem, which causes an ordering cycle during the boot: авг 14 13:51:06 jessica systemd[1]: Found ordering cycle on basic.target/start авг 14 13:51:06 jessica systemd[1]: Found dependency on sysinit.target/start авг 14 13:51:06 jessica systemd[1]: Found dependency on mintsystem.service/start авг 14 13:51:06 jessica systemd[1]: Found dependency on dbus.service/start авг 14 13:51:06 jessica systemd[1]: Found dependency on basic.target/start авг 14 13:51:06 jessica systemd[1]: Breaking ordering cycle by deleting job mintsystem.service/start авг 14 13:51:06 jessica systemd[1]: Job mintsystem.service/start deleted to break ordering cycle starting with basic.target/start The init script in mintsystem package is /etc/init.d/mintsystem. Here's its contents: #! /bin/sh ### BEGIN INIT INFO # Provides: mintsystem # Required-Start:$local_fs $syslog $remote_fs dbus # Required-Stop: $local_fs $syslog $remote_fs # Default-Start: S # Default-Stop: ### END INIT INFO /usr/lib/linuxmint/mintSystem/mint-adjust.py I'd like to know: what can I change in this script to get rid of the ordering cycle? Thanks in advance. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] race conditions after SIGTERM
Am 14.08.2014 um 14:22 schrieb Lennart Poettering: On Sun, 27.07.14 19:53, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Sat, Jul 26, 2014 at 02:46:05PM +0200, Reindl Harald wrote: after that happend a few minutes ago systemd on F19: https://bugzilla.redhat.com/show_bug.cgi?id=1123557 since the sleep 1 was enough over months and now sleep 6 between systemctl stop and rsync is also not relieable my only conclusion is that systemd don't care about the still running MAINPID of type=simple and in case of a existing ExecStopPost the logic is correct Hi, PIDFile with Type=simple is not supported. Adding support would be tricky, because with Type=simple there's no obvious mechanism to notify systemd *when* to read the file. With Type=forking, when the first process exits, systemd knows it can read the file. It could be done with inotify maybe. A long-standing item on the TODO list is to add a new Type=pid-file or so that waits for a PID file to appear and uses that as indication when a daemon is up, or dies. I figure the example above would be a good case for this yes, but the problem is somewhere else look at the bugreport, it happened also witout the PIDFile line well, yesterday i upgraded production to Fedora 20 maybe that is now solved anyways i will report in both cases in the RH bugzilla * if it did not happen again for 3 weeks * if it happens again pretty sure a regression in the last F19 systemd update only in rare situations triggered or at least it got bader with that version since the /usr/bin/sleep 1 workaround did no longer help relieable 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] race conditions after SIGTERM
Am 14.08.2014 um 14:24 schrieb Lennart Poettering: On Sun, 27.07.14 20:04, Reindl Harald (h.rei...@thelounge.net) wrote: but that still don't explain why ExecStopPost=/usr/bin/true or whatever ExecStopPost solves that and if it is not supported why systemctl don't return after the one and only process exited Well, this is a misunderstanding how ExecStop= and friends are supposed to work. They are supposed to do what they did on sysvinit: synchronously terminate a service. And not asynchronously do that. We hence don't wait for anything else then, because what is left afterwards must be left-over processes that ExecStop= and friends couldn't clean up properly... no - the point was why was mysqld not finished with write down his ariadb-logs while systemctl returns and hence the corruption by start rsysnc the datadir in case of Type=simple and mysqld directly called in ExecStart without the mysqld_safe script there are not much processes to left over 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] Bug#758050: udev: ID_VENDOR_FROM_DATABASE, ID_MODEL_FROM_DATABASE for unrecognised USB device are taken from USB hub
I recently opened this Debian bug, for which I attach a
patch that seems to work. Bug report quoted in full below.
I would appreciate udev maintainers' opinions on whether this is
likely to break non-USB devices, or whether there is a better way
to do it.
S
Steps to reproduce: plug in a USB device which isn't in the udev
hwdb, like this one:
Bus 003 Device 017: ID 21b4:0081
Device Descriptor:
bLength18
bDescriptorType 1
bcdUSB 1.00
bDeviceClass0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x21b4
idProduct 0x0081
bcdDevice1.20
iManufacturer 1 AudioQuest inc.
iProduct2 AudioQuest DragonFly
iSerial 3 (C) 2013 Wavelength Audio, ltd.
(Yes I know that's a weird serial number, I didn't design the device.)
Expected result:
* ID_MODEL_FROM_DATABASE and ID_VENDOR_FROM_DATABASE are missing
* Interested applications can look up those properties using
idVendor and idProduct if they want to
Actual result: those strings are taken from the parent device,
an Intel Corp. Integrated Rate Matching Hub (vendor 8087, product 0024):
P: /devices/pci:00/:00:1a.0/usb3/3-1/3-1.2/3-1.2:1.0/sound/card1
E:
DEVPATH=/devices/pci:00/:00:1a.0/usb3/3-1/3-1.2/3-1.2:1.0/sound/card1
E: ID_BUS=usb
E: ID_FOR_SEAT=sound-pci-_00_1a_0-usb-0_1_2_1_0
E: ID_ID=usb-AudioQuest_inc._AudioQuest_DragonFly-00-DragonFly
E: ID_MODEL=AudioQuest_DragonFly
E: ID_MODEL_ENC=AudioQuest\x20DragonFly
E: ID_MODEL_FROM_DATABASE=Integrated Rate Matching Hub
E: ID_MODEL_ID=0081
E: ID_PATH=pci-:00:1a.0-usb-0:1.2:1.0
E: ID_PATH_TAG=pci-_00_1a_0-usb-0_1_2_1_0
E: ID_REVISION=0120
E: ID_SERIAL=AudioQuest_inc._AudioQuest_DragonFly
E: ID_TYPE=audio
E: ID_USB_DRIVER=snd-usb-audio
E: ID_USB_INTERFACES=:010100:010200:
E: ID_USB_INTERFACE_NUM=00
E: ID_VENDOR=AudioQuest_inc.
E: ID_VENDOR_ENC=AudioQuest\x20inc.
E: ID_VENDOR_FROM_DATABASE=Intel Corp.
E: ID_VENDOR_ID=21b4
E: SOUND_INITIALIZED=1
E: SUBSYSTEM=sound
E: SYSTEMD_WANTS=sound.target
E: TAGS=:seat:systemd:
E: USEC_INITIALIZED=6479525776
This makes PulseAudio assign a silly name to this device, which shows
up in control UIs (e.g. Integrated Rate Matching Hub Analog Stereo in
pavucontrol and Analog Stereo - Integrated Rate Matching Hub in
gnome-control-center):
index: 1
name:
alsa_output.usb-AudioQuest_inc._AudioQuest_DragonFly-00-DragonFly.analog-stereo
...
card: 1
alsa_card.usb-AudioQuest_inc._AudioQuest_DragonFly-00-DragonFly
...
properties:
...
alsa.card_name = AudioQuest DragonFly
alsa.long_card_name = AudioQuest inc. AudioQuest DragonFly at
usb-:00:1a.0-1.2, full speed
...
udev.id =
usb-AudioQuest_inc._AudioQuest_DragonFly-00-DragonFly
device.bus = usb
device.vendor.id = 21b4
device.vendor.name = Intel Corp.
device.product.id = 0081
device.product.name = Integrated Rate Matching Hub
device.serial = AudioQuest_inc._AudioQuest_DragonFly
...
device.profile.name = analog-stereo
device.profile.description = Analog Stereo
device.description = Integrated Rate Matching Hub Analog
Stereo
From e0bb1d9cf82e397b08335e5d7107a8506849e823 Mon Sep 17 00:00:00 2001
From: Simon McVittie simon.mcvit...@collabora.co.uk
Date: Thu, 14 Aug 2014 14:05:45 +0100
Subject: [PATCH] hwdb: stop looking at parent devices if the modalias changes
This avoids claiming that an unrecognised USB device is an Intel USB
hub, just because it happens to be plugged into an Intel USB hub.
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758050
---
src/udev/udev-builtin-hwdb.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/udev/udev-builtin-hwdb.c b/src/udev/udev-builtin-hwdb.c
index cac97e7..ac8d2e3 100644
--- a/src/udev/udev-builtin-hwdb.c
+++ b/src/udev/udev-builtin-hwdb.c
@@ -89,6 +89,7 @@ static int udev_builtin_hwdb_search(struct udev_device *dev, struct udev_device
struct udev_device *d;
char s[16];
int n = 0;
+char found_modalias[16] = { 0 };
for (d = srcdev; d; d = udev_device_get_parent(d)) {
const char *dsubsys;
@@ -111,6 +112,16 @@ static int udev_builtin_hwdb_search(struct udev_device *dev, struct udev_device
if (!modalias)
continue;
+/* if we already found a device with a vendor:product
+ * and this device has a different vendor:product, stop -
+ * this avoids matching the hub to which a USB device is
+ * attached */
+if (found_modalias[0]
Re: [systemd-devel] How to get rid of this ordering cycle?
On Thu, 14.08.14 16:27, Vlad Orlov (mon...@inbox.ru) wrote: Hi, I have Debian Testing running with some additional packages from Linux Mint which are installed for testing purposes. One of them is mintsystem, which causes an ordering cycle during the boot: авг 14 13:51:06 jessica systemd[1]: Found ordering cycle on basic.target/start авг 14 13:51:06 jessica systemd[1]: Found dependency on sysinit.target/start авг 14 13:51:06 jessica systemd[1]: Found dependency on mintsystem.service/start авг 14 13:51:06 jessica systemd[1]: Found dependency on dbus.service/start авг 14 13:51:06 jessica systemd[1]: Found dependency on basic.target/start авг 14 13:51:06 jessica systemd[1]: Breaking ordering cycle by deleting job mintsystem.service/start авг 14 13:51:06 jessica systemd[1]: Job mintsystem.service/start deleted to break ordering cycle starting with basic.target/start The init script in mintsystem package is /etc/init.d/mintsystem. Here's its contents: #! /bin/sh ### BEGIN INIT INFO # Provides: mintsystem # Required-Start:$local_fs $syslog $remote_fs dbus # Required-Stop: $local_fs $syslog $remote_fs # Default-Start: S # Default-Stop: ### END INIT INFO /usr/lib/linuxmint/mintSystem/mint-adjust.py I'd like to know: what can I change in this script to get rid of the ordering cycle? This must be a really old systemd version? So the problem here is that you want this to be started in the S runlevel, i.e. during early boot. But you also want this to run after dbus. dbus however is only started in late boot. You have to make a decision here: run the thing in early boot (and hence not in S), or run it after dbus. Both you cannot do, that's not possible... That said, we removed support for sysv init scripts as part of early-boot a long time ago. Your distro's systemd must be really old or somebody must have patched that it added that back in. 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] How to get rid of this ordering cycle?
On 14/08/14 13:27, Vlad Orlov wrote: ### BEGIN INIT INFO # Provides: mintsystem # Required-Start:$local_fs $syslog $remote_fs dbus # Required-Stop: $local_fs $syslog $remote_fs # Default-Start: S # Default-Stop: ### END INIT INFO As Lennart said, this is Debian-(and-its-derivatives)-specific: upstream systemd does not support sysvinit services during early boot, i.e. rcS. In Debian, support for sysvinit scripts in rcS was patched back in to avoid breaking existing software, because it's unlikely that all of the packages listed in http://codesearch.debian.net/search?q=Default-Start%3A\s*S will get a native systemd unit any time soon. Most of them probably doesn't actually need to run in rcS - nvi? seriously? - but if fixing them all was on the critical path for adopting systemd, we'd probably still be using sysvinit for years to come. Default-Start: S means basic-target.target depends on mintsystem.service, which depends on dbus.service, which does not have DefaultDependencies=no, so it implicitly depends on sysinit.target, so you lose. Or to put it in sysvinit terms, this is still incorrect: a service started in rcS should not depend on dbus, which is started in rc2. (Perhaps dbus should use DefaultDependencies=no - I think all it actually needs are syslog.socket and /usr - but it has traditionally been run in rc2.) I'd like to know: what can I change in this script to get rid of the ordering cycle? You can start it later, in rc2 (so it can start after dbus.service); or you can make it not depend on dbus if it doesn't actually need dbus-daemon; or you can modify dbus.service to use DefaultDependencies=no and declare its dependencies explicitly; or you can delete it. If mint-adjust.py is https://github.com/linuxmint/mintsystem/blob/master/usr/lib/linuxmint/mintSystem/mint-adjust.py then, ugh, this is the sort of thing that should not be done (and Debian Policy specifically forbids it). Linux Mint should ship a patched version of Debian's base-files package instead, like Ubuntu, SteamOS and other Debian derivatives do: that's the correct place to declare your OS to be a fork of Debian. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to get rid of this ordering cycle?
On 14/08/14 14:31, Simon McVittie wrote: Default-Start: S means basic-target.target depends on mintsystem.service, which depends on dbus.service, which does not have DefaultDependencies=no, so it implicitly depends on sysinit.target, so you lose. Sorry, that's not quite right. Default-Start: S translates into making sysinit.target depend on mintsystem.service, and mintsystem.service depends on dbus.service, which implicitly depends on basic.target as a result of default dependencies, and basic.target depends on sysinit.target. So, again, a cycle. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] socket: add support for TCP fast Open
On Thu, Aug 14, 2014 at 02:31:47PM +0530, Susant Sahani wrote:
TCP Fast Open (TFO) speeds up the opening of successiveTCP)
connections between two endpoints.It works by using a TFO cookie
in the initial SYN packet to authenticate a previously connected
client. It starts sending data to the client before the receipt
of the final ACK packet of the three way handshake is received,
skipping a round trip and lowering the latency in the start of
transmission of data.
---
Why does this default to false? The kernel enables this by default as of
3.13 and exposes /proc/sys/net/ipv4/tcp_fastopen. Are there really
cases where one might want this conditionally enabled/disabled?
man/systemd.socket.xml| 15 +++
src/core/dbus-socket.c| 1 +
src/core/load-fragment-gperf.gperf.m4 | 1 +
src/core/socket.c | 8
src/core/socket.h | 1 +
5 files changed, 26 insertions(+)
diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
index 352825f..170d010 100644
--- a/man/systemd.socket.xml
+++ b/man/systemd.socket.xml
@@ -499,6 +499,21 @@
/varlistentry
varlistentry
+termvarnameFastOpen=/varname/term
+listitemparaTakes a boolean
+argument. It works by using a TFO cookie (a
TCP option) in the initial
+SYN packet to authenticate a previously
connected client. If successful,
+it may start sending data to the client
before the receipt of the final
+ACK packet of the three way handshake is
received, skipping a round trip
+and lowering the latency in the start of
transmission of data.
+This controls the TCP_FASTOPEN socket option
(see
+the ulink
url=http://lwn.net/Articles/508865/;TCP
+Fast Open: expediting web services/ulink
for details.)
+Defaults to
+optionfalse/option./para/listitem
+/varlistentry
+
+varlistentry
termvarnamePriority=/varname/term
listitemparaTakes an integer
argument controlling the priority for
diff --git a/src/core/dbus-socket.c b/src/core/dbus-socket.c
index ad135a1..71c0115 100644
--- a/src/core/dbus-socket.c
+++ b/src/core/dbus-socket.c
@@ -97,6 +97,7 @@ const sd_bus_vtable bus_socket_vtable[] = {
SD_BUS_PROPERTY(DirectoryMode, u, bus_property_get_mode,
offsetof(Socket, directory_mode), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(Accept, b, bus_property_get_bool,
offsetof(Socket, accept), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(KeepAlive, b, bus_property_get_bool,
offsetof(Socket, keep_alive), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(FastOpen , b, bus_property_get_bool,
offsetof(Socket, fast_open), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(Priority, i, bus_property_get_int,
offsetof(Socket, priority), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(ReceiveBuffer, t, bus_property_get_size,
offsetof(Socket, receive_buffer), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(SendBuffer, t, bus_property_get_size,
offsetof(Socket, send_buffer), SD_BUS_VTABLE_PROPERTY_CONST),
diff --git a/src/core/load-fragment-gperf.gperf.m4
b/src/core/load-fragment-gperf.gperf.m4
index f4acdda..08d0593 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -232,6 +232,7 @@ Socket.Accept, config_parse_bool,
0,
Socket.MaxConnections, config_parse_unsigned, 0,
offsetof(Socket, max_connections)
Socket.KeepAlive,config_parse_bool, 0,
offsetof(Socket, keep_alive)
Socket.NoDelay, config_parse_bool, 0,
offsetof(Socket, no_delay)
+Socket.FastOpen, config_parse_bool, 0,
offsetof(Socket, fast_open)
Socket.Priority, config_parse_int, 0,
offsetof(Socket, priority)
Socket.ReceiveBuffer,config_parse_iec_size, 0,
offsetof(Socket, receive_buffer)
Socket.SendBuffer, config_parse_iec_size, 0,
offsetof(Socket, send_buffer)
diff --git a/src/core/socket.c b/src/core/socket.c
index 5af1596..44827ad 100644
---
Re: [systemd-devel] How to get rid of this ordering cycle?
On Thu, 14.08.14 14:31, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: In Debian, support for sysvinit scripts in rcS was patched back in to avoid breaking existing software, because it's unlikely that all of the packages listed in http://codesearch.debian.net/search?q=Default-Start%3A\s*S will get a native systemd unit any time soon. Most of them probably doesn't actually need to run in rcS - nvi? seriously? - but if fixing them all was on the critical path for adopting systemd, we'd probably still be using sysvinit for years to come. I have the suspicion that this creates as many problems as it solves... That's why we removed support for that, especially since there's no realy standard about this anyway... 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] Removed PPC 32 bit LE architecture
On 11/08/14 17:14, Lennart Poettering wrote: On Mon, 11.08.14 15:57, Lennart Poettering (lenn...@poettering.net) wrote: On Fri, 08.08.14 17:00, har...@redhat.com (har...@redhat.com) wrote: From: Harald Hoyer har...@redhat.com According to Brent Baude bba...@redhat.com, who provided the patch, IBM doesn't want to support the PPC 32 bit LE architecture at all. What is support supposed to mean? Does that mean that the silicon for PPC32LE has and will never exist? Or does this mean that they are simply not interested in supporting Linux on ppc32le like this with support employees and stuff? I think if the silicon exists and people play around with it, we should keep the thing probably. However, if this is a theoretic architecture only, then let's kill it. Judging by this it's something that actually exists: http://lwn.net/Articles/408051/ Hence I think we should leave the arch in... Lennart Thanks. (As in, it's supported arch in Gentoo) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] socket: add support for TCP fast Open
On Thu, 14.08.14 09:54, Dave Reisner (d...@falconindy.com) wrote: On Thu, Aug 14, 2014 at 02:31:47PM +0530, Susant Sahani wrote: TCP Fast Open (TFO) speeds up the opening of successiveTCP) connections between two endpoints.It works by using a TFO cookie in the initial SYN packet to authenticate a previously connected client. It starts sending data to the client before the receipt of the final ACK packet of the three way handshake is received, skipping a round trip and lowering the latency in the start of transmission of data. --- Why does this default to false? The kernel enables this by default as of 3.13 and exposes /proc/sys/net/ipv4/tcp_fastopen. Are there really cases where one might want this conditionally enabled/disabled? Oh, indeed. Also the setsockopt actually doesn't take a bool but a qlen integer, according to the LWN story. The sysctl is actually a bit field, and by default turns on the server side of TCP fastopen, but not the client side. However, we only do the server side in systemd anyway, so it's always on anyway... I reverted this for now hence, this needs more discussion. 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] networkd Promiscuous mode
On Wed, 13.08.14 18:53, Marcel Holtmann (mar...@holtmann.org) wrote: Hi Lennart, There seems to be no way in systemd-networkd to put a link in Promiscuous mode. This is needed to make macvlan work correctly (Otherwise it receives no traffic with its mac address as the destination). If I am not mistaken this could be a boolean in *.link files. Sounds useful. Added to the todo list. actually this sounds like a design mistake. If macvlan requires the network interface in promiscuous mode, then it should do that internally. Inside the kernel the promiscuous mode is actually reference counted. This can for example be utilized from packet(7) sockets. That way you do not accidentally leave a device in promiscuous mode if all users are gone. So why not fix macvlan to put the parent into promiscuous mode. Makes sense. Removed the thing from the TODO list again... 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] networkd Promiscuous mode
On Thu, Aug 14, 2014 at 3:53 AM, Marcel Holtmann mar...@holtmann.org wrote: Hi Lennart, There seems to be no way in systemd-networkd to put a link in Promiscuous mode. This is needed to make macvlan work correctly (Otherwise it receives no traffic with its mac address as the destination). If I am not mistaken this could be a boolean in *.link files. Sounds useful. Added to the todo list. actually this sounds like a design mistake. If macvlan requires the network interface in promiscuous mode, then it should do that internally. Inside the kernel the promiscuous mode is actually reference counted. This can for example be utilized from packet(7) sockets. That way you do not accidentally leave a device in promiscuous mode if all users are gone. So why not fix macvlan to put the parent into promiscuous mode. Yeah, this sounds like a kernel bug. If there is some independent reason to unconditionally enable promiscuous mode, we could consider it. Otherwise, I'd let it be. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Pairing udev's SYSTEMD_WANTS and systemd's templated units
On 14.08.2014 13:00, Lennart Poettering wrote:
On Thu, 14.08.14 10:02, Ivan Shapovalov (intelfx...@gmail.com) wrote:
The only thing: PROGRAM=..., ENV{SYSTEMD_WANTS}+=...%c... idiom seems a
pretty ugly way to invoke systemd-escape. This looks like a pretty common
thing to do; shouldn't there be a shorthand or something? (just a suggestion)
Yeah, I agree, but I not entirely sure how this could look like in a
nice way?
Maybe add:
ENV{SYSTEMD_WANTS_INSTANCE}=bar
ENV{SYSTEMD_WANTS_TEMPLATE}=foo@.service
or so, would escape bar and add it into foo@.service... But that's not
particularly generic but focusses only on the instance/template case...
Ideas?
Lennart
Why not extend udev with new % specifiers for the systemd escaped name?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to get rid of this ordering cycle?
On Thu, Aug 14, 2014 at 02:31:00PM +0100, Simon McVittie wrote: On 14/08/14 13:27, Vlad Orlov wrote: ### BEGIN INIT INFO # Provides: mintsystem # Required-Start:$local_fs $syslog $remote_fs dbus # Required-Stop: $local_fs $syslog $remote_fs # Default-Start: S # Default-Stop: ### END INIT INFO As Lennart said, this is Debian-(and-its-derivatives)-specific: upstream systemd does not support sysvinit services during early boot, i.e. rcS. In Debian, support for sysvinit scripts in rcS was patched back in to avoid breaking existing software, because it's unlikely that all of the packages listed in http://codesearch.debian.net/search?q=Default-Start%3A\s*S will get a native systemd unit any time soon. Most of them probably doesn't actually need to run in rcS - nvi? seriously? - but if fixing them all was on the critical path for adopting systemd, we'd probably still be using sysvinit for years to come. Actually, most of them probably don't need to run at all: util-linux: hwclock.sh - not necessary with systemd systemd: Copy rules generated while the root was ro - argh, installing a sysv script as part of systemd? udev: Start udevd, populate /dev and load drivers - ?? procps: Configure kernel parameters at boottime - not necessary with systemd, probably downright harmful sysvinit:- n/a kmod: Load the modules listed in /etc/modules - not necessary with systemd console-setup: - not necessary with systemd, probably will cause a mess by duplicating functionality xorg:- I doubt that this has to run in early boot insserv: - n/a, seems to be some tests fuse:- Not sure what this does, but it proably should be started on demand only and then there's lvm2: ifupdown: So there's two scripts to convert, and a bunch to disable. Those that should be disabled are either already disabled with systemd, or will have to be for correctness anyway. And that leaves two scripts to take care of. At least for lvm2, converting it to properly support systemd seems to be a prerequisite for proper shutdown, and is something that it worth doing anyway. For some of those scripts, support in systemd might be inadequate. But fixing/enhancing systemd is imho a much better approach than adding workarounds in obsolete init scripts. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] eye of cylon / timeout timer is cut off
On Sun, 27.07.14 21:47, Michael Biebl (mbi...@gmail.com) wrote: Hi, as you can see at the attached diff, there is a small issue with the timer that is disabled, when systemd is waiting for a job. In this case, the job is already running 1min 17secs, but only 17 secs is displayed, the other part is cut off. Hmm, well, we currently ellipsize at 75% of the line width. I have now moved that to 50%, so that there's a chance that the time is still shown on tiny displays. But it's a stupid game. We will have to cut out something... Anyway, let's see if people complain about this new setting too... 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] Reason for IgnoreSIGPIPE=true by default
On Fri, 25.07.14 20:22, Ansgar Burchardt (ans...@debian.org) wrote: Heya! I think I replied to this since on IRC, but just for the sake of completeness of the ML archives: I'm wondering what the reason for IgnoreSIGPIPE to default to true is. The documentation just states that SIGPIPE is primarily something to ripple up shell pipelines right to left, if something dies. EOF is usually used from left-to-right. That's not really useful for normal daemons though, and as we try to provide a good, useful execution environment for daemons, we turn this off. Of course, shells should and suchlike should turn this on again. Defaults to true because SIGPIPE generally is useful only in shell pipelines. But I don't think that this alone is a good reason to change the default. It can confuse programs which use pipes and do not expect their signal handlers to be messed with, see [1] for the same issue in Python. As another example, tar xf *.tar.gz will fail on some archives if SIGPIPE is ignored[2]. Another problem is that this not only affects the program started by systemd itself, but leaks into all child processes as well. See [3] for a bug report against cron due to this (yes, can be worked around by setting IgnoreSIGPIPE=false for cron.service, but I believe systemd is wrong here). Ansgar [1] http://bugs.python.org/issue1652 I think the Python guys did the right thing here, and reset the SIG_IGN again before execing something else... Also, to my knowledge bash is actually smart enough to reset this on its own when it is invoked. Which sounds like the right thing to do. Maybe this bug is specific to Debian's bash replacement, and should be fixed there. In addition, note that for gettys/user shells and stuff we actually explicitly set IgnoreSIGPIPE=no currently. Same for all sysv init scripts, to provide compatible behaviour. 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] How to get rid of this ordering cycle?
On 14/08/14 16:04, Zbigniew Jędrzejewski-Szmek wrote: Actually, most of them probably don't need to run at all: Many of the ones you quoted indeed don't make sense with systemd and are either explicitly masked by a symlink to /dev/null, or have a corresponding native systemd service that overrides them - notably, everything in systemd, sysvinit, util-linux and procps - but you might have missed the next page link at the bottom? There are about 4 pages of results at the moment. That search is among source packages, not binaries, so it'll match anything that ships a rcS script, whether we would actually execute that script under systemd or not. (The ones in the systemd source package are for udev on a non-systemd init system, FWIW.) At some point a mass-bug-filing on packages that ship an rcS script without a corresponding systemd service would make sense, yes. Hopefully many of them could be dealt with by masking the sysvinit script and shipping a tmpfiles.d fragment. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Pairing udev's SYSTEMD_WANTS and systemd's templated units
On Thu, 14.08.14 17:10, Harald Hoyer (harald.ho...@gmail.com) wrote:
On 14.08.2014 13:00, Lennart Poettering wrote:
On Thu, 14.08.14 10:02, Ivan Shapovalov (intelfx...@gmail.com) wrote:
The only thing: PROGRAM=..., ENV{SYSTEMD_WANTS}+=...%c... idiom seems a
pretty ugly way to invoke systemd-escape. This looks like a pretty common
thing to do; shouldn't there be a shorthand or something? (just a
suggestion)
Yeah, I agree, but I not entirely sure how this could look like in a
nice way?
Maybe add:
ENV{SYSTEMD_WANTS_INSTANCE}=bar
ENV{SYSTEMD_WANTS_TEMPLATE}=foo@.service
or so, would escape bar and add it into foo@.service... But that's not
particularly generic but focusses only on the instance/template case...
Ideas?
Lennart
Why not extend udev with new % specifiers for the systemd escaped name?
What syntax would you propose? Note that there are probably a couple of
different strings people might want to have escaped?
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] How to get rid of this ordering cycle?
On Thu, 14.08.14 17:04, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: systemd: Copy rules generated while the root was ro Hmm, wut? What's that supposed to be? 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] Changing configurations with networkd
On Thu, 24.07.14 10:49, Tom Gundersen (t...@jklm.no) wrote: I think there was some misunderstanding here. I don't want to keep the lease across reboots. I don't care about that. I think networkd should remember the lease when restarting networkd only and not send a new dhcp discover. Right, I spoke too quickly. What I don't want is to preserve state between reboots, preserving it between restarts of networkd would indeed be fine. We already serialize the dhcp leases to /run, so I'd be happy to take a patch to deserialize these again when networkd starts. Yeah, this would be great. This is what we are doing for machined and logind too now, where we store everything in /run all the time, and can then stop and start at any time without losing any information. I think we should follow this scheme wherever we can. This would be particularly useful when transitioning from the initrd to the main system, since the initrd's networkd could simply be terminated and be replaced by the host's version and still find everything. 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] Changing configurations with networkd
On Fri, 25.07.14 09:48, Michael Olbrich (m.olbr...@pengutronix.de) wrote: What I'm _not_ seeing, and what usually comes when anything else changes in the network configuration is: systemd-timesyncd[348]: Network configuration changed, trying to establish connection. I would expect, that systemd-timesyncd should be notified in this case as well, right? This should be fixed with current git. Could you please recheck? 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] How to get rid of this ordering cycle?
On 14/08/14 16:29, Lennart Poettering wrote: On Thu, 14.08.14 17:04, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: systemd: Copy rules generated while the root was ro Hmm, wut? What's that supposed to be? I think it's glue for running udev when pid 1 != systemd and there was no initramfs. (All the rcS scripts in systemd are either masked or hidden by a corresponding whatever.service on systemd systems anyway, so that particular script is not relevant here.) S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sysusers and login.defs checks
On Thu, 24.07.14 13:32, Colin Guthrie (gm...@colin.guthr.ie) wrote: I guess my main concern still remains that uid range settings for system users would now be in two places - one used by sysusers and another by adduser (I now accept your argument that the other two places are different configuration data even if it's conceptually similar). I want to be able to tell a user that the configuration is in one place not explain that package system users ranges are in one place and adduser's system user range is in another. Well, here's the thing: I reall don't think the boundary should be a user configuration thing. It should be a vendor configuration thing. And thus you shouldn't tell your users about how to configure it at all. I think communicating how to select the users that get split up journals makes a lot of sense, but not how to shift the boundary in general. And that's kinda the key of the issue here... I am still convinced that adding a range command to sysusers and a SplitUserRange= setting to journald is the right way to go... 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] How to get rid of this ordering cycle?
On Thu, 14.08.14 16:41, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: On 14/08/14 16:29, Lennart Poettering wrote: On Thu, 14.08.14 17:04, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: systemd: Copy rules generated while the root was ro Hmm, wut? What's that supposed to be? I think it's glue for running udev when pid 1 != systemd and there was no initramfs. (All the rcS scripts in systemd are either masked or hidden by a corresponding whatever.service on systemd systems anyway, so that particular script is not relevant here.) Hmm, Debian still generates persistent rules at boot? Yuck! 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] eye of cylon / timeout timer is cut off
2014-08-14 17:17 GMT+02:00 Lennart Poettering lenn...@poettering.net: On Sun, 27.07.14 21:47, Michael Biebl (mbi...@gmail.com) wrote: Hi, as you can see at the attached diff, there is a small issue with the timer that is disabled, when systemd is waiting for a job. In this case, the job is already running 1min 17secs, but only 17 secs is displayed, the other part is cut off. Hmm, well, we currently ellipsize at 75% of the line width. I have now moved that to 50%, so that there's a chance that the time is still shown on tiny displays. Well, that's the standard resolution on non-KMS enabled systems, like in a virtualized environment (the screenshot was made using vbox). So it's pretty common, I'd say. But it's a stupid game. We will have to cut out something... Anyway, let's see if people complain about this new setting too... With 50% being the cut-off, you'll only be able to see A stop job is running... afaics without showing the actual unit which is being waited for. That doesn't sound great either. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to get rid of this ordering cycle?
2014-08-14 17:57 GMT+02:00 Lennart Poettering lenn...@poettering.net: Hmm, Debian still generates persistent rules at boot? Yuck! Correct. We still use the old persistent network naming scheme and have not transitioned to the new scheme [1] yet. We might in the future or not. This needs further investigation and a proper transition plan. At least for jessie we don't want to deal with yet another transition which has the potential to break a lot of existing installations. Cheers, Michael [1] http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/3] socket: Add support for TCP defer accept
On Tue, Jul 29, 2014 at 11:10:09PM +0530, Susant Sahani wrote:
TCP_DEFER_ACCEPT Allow a listener to be awakened only when data
arrives on the socket. If TCP_DEFER_ACCEPT set on a server-side
listening socket, the TCP/IP stack will not to wait for the final
ACK packet and not to initiate the process until the first packet
of real data has arrived. After sending the SYN/ACK, the server will
then wait for a data packet from a client. Now, only three packets
will be sent over the network, and the connection establishment delay
will be significantly reduced.
---
man/systemd.socket.xml | 16
src/core/dbus-socket.c | 1 +
src/core/socket.c | 11 +++
src/core/socket.h | 1 +
4 files changed, 29 insertions(+)
diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
index e6bbb2e..9ce94aa 100644
--- a/man/systemd.socket.xml
+++ b/man/systemd.socket.xml
@@ -539,6 +539,22 @@
/varlistentry
varlistentry
+termvarnameDeferAccept=/varname/term
+listitemparaTakes time (in seconds) as
argument
+Allow a listener to be awakened only when
data arrives on the socket.
+If TCP_DEFER_ACCEPT set on a server-side
listening socket,
+the TCP/IP stack will not to wait for the
final ACK packet and not to
+initiate the process until the first packet
of real data has arrived.
+After sending the SYN/ACK, the server will
then wait for a data packet
+from a client. Now, only three packets will
be sent over the network,
+and the connection establishment delay will
be significantly reduced.
+This controls the TCP_DEFER_ACCEPT socket
option (see
+
citerefentryrefentrytitlesocket/refentrytitlemanvolnum7/manvolnum/citerefentry
+Defaults to
+optiondisabled/option./para/listitem
I think this needs to be cleaned up to be gramatically correct. Right now
some guesswork is required to gather the true meaning.
Maybe something like this:
---
paraTakes time (in seconds) as argument. If set, the listening process
will be awakened only when data arrives on the socket, and not immediately
when connection is established. When this option is set, the
constantTCP_DEFER_ACCEPT/constant socket option will be used
(see
citerefentryrefentrytitletcp/refentrytitlemanvolnum7/manvolnum/citerefentry),
and the kernel will ignore initial ACK packets without any data.
The argument specifies the approximate amount
of time the kernel should wait for incoming data before falling
back to the normal behaviour of honouring empty ACK packets.
This option beneficial for protocols where the client sends the data
first (e.g. HTTP, in contrast to SMTP), because the server
process will not be woken up unnecessarily before it can take any action.
/para
paraIf the client also uses the constantTCP_DEFER_ACCEPT/constant
option, the latency of the initial connection may be
reduced, because the kernel will send data in the
final packet establishing the connection (the third packet in the
three-way handshake)./para
paraDisabled by default./para
---
(Note that TCP_DEFER_ACCEPT is described in tcp(7), not socket(7), and this
description is so terse that it is nearly useless anyway.)
Zbyszek
+/varlistentry
+
+varlistentry
termvarnamePriority=/varname/term
listitemparaTakes an integer
argument controlling the priority for
diff --git a/src/core/dbus-socket.c b/src/core/dbus-socket.c
index f9ef7ef..1142ca5 100644
--- a/src/core/dbus-socket.c
+++ b/src/core/dbus-socket.c
@@ -101,6 +101,7 @@ const sd_bus_vtable bus_socket_vtable[] = {
SD_BUS_PROPERTY(KeepAliveInterval, t, bus_property_get_usec,
offsetof(Socket, keep_alive_interval), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(KeepAliveProbes, i, bus_property_get_int,
offsetof(Socket, keep_alive_cnt), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(FastOpen , b, bus_property_get_bool,
offsetof(Socket, fast_open), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(DeferAccept , t, bus_property_get_usec,
offsetof(Socket, defer_accept), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(Priority, i, bus_property_get_int,
offsetof(Socket, priority), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(ReceiveBuffer, t, bus_property_get_size,
offsetof(Socket, receive_buffer), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(SendBuffer, t, bus_property_get_size,
Re: [systemd-devel] eye of cylon / timeout timer is cut off
On Thu, Aug 14, 2014 at 06:13:47PM +0200, Michael Biebl wrote: 2014-08-14 17:17 GMT+02:00 Lennart Poettering lenn...@poettering.net: On Sun, 27.07.14 21:47, Michael Biebl (mbi...@gmail.com) wrote: Hi, as you can see at the attached diff, there is a small issue with the timer that is disabled, when systemd is waiting for a job. In this case, the job is already running 1min 17secs, but only 17 secs is displayed, the other part is cut off. Hmm, well, we currently ellipsize at 75% of the line width. I have now moved that to 50%, so that there's a chance that the time is still shown on tiny displays. Well, that's the standard resolution on non-KMS enabled systems, like in a virtualized environment (the screenshot was made using vbox). So it's pretty common, I'd say. But it's a stupid game. We will have to cut out something... Anyway, let's see if people complain about this new setting too... With 50% being the cut-off, you'll only be able to see A stop job is running... afaics without showing the actual unit which is being waited for. That doesn't sound great either. It would be more useful to remove the / 1min 30s part. Maybe the cylon code could be smart enough for that. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] eye of cylon / timeout timer is cut off
2014-08-14 18:36 GMT+02:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: It would be more useful to remove the / 1min 30s part. Maybe the cylon code could be smart enough for that. I think it's useful information to know that the timeout is 90s. An alternative could be, to simply use seconds and not convert that into h:m:s values. A 77s / 90s display would be ok to me. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to get rid of this ordering cycle?
2014-08-14 17:04 GMT+02:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: On Thu, Aug 14, 2014 at 02:31:00PM +0100, Simon McVittie wrote: On 14/08/14 13:27, Vlad Orlov wrote: ### BEGIN INIT INFO # Provides: mintsystem # Required-Start:$local_fs $syslog $remote_fs dbus # Required-Stop: $local_fs $syslog $remote_fs # Default-Start: S # Default-Stop: ### END INIT INFO As Lennart said, this is Debian-(and-its-derivatives)-specific: upstream systemd does not support sysvinit services during early boot, i.e. rcS. In Debian, support for sysvinit scripts in rcS was patched back in to avoid breaking existing software, because it's unlikely that all of the packages listed in http://codesearch.debian.net/search?q=Default-Start%3A\s*S will get a native systemd unit any time soon. Most of them probably doesn't actually need to run in rcS - nvi? seriously? - but if fixing them all was on the critical path for adopting systemd, we'd probably still be using sysvinit for years to come. Actually, most of them probably don't need to run at all: Yeah, this is correct. Those init scripts are only necessary if you actually still use sysvinit as PID 1. See http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/systemd.links -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Networkd dhcp hostname override
On Wed, 2014-08-13 at 18:55 -0700, Marcel Holtmann wrote: Hi Lennart, Now that networkd can send the systems hostname to the dhcp server, I would find it useful to have an option to override the hostname that gets sent. In my use case, I would like to setup a number of macvlans with different hostnames. Something as simple as [DHCP] SendHostname=true Hostname=foo Sounds useful, though this could just be a single option SendHostname=foobar or so. If not set it sends the system hostname, otherwise the specified hostname. Or something like that. what would this be useful for? Either you send the hostname or you don't. I think what you are looking for is an option to set the Client ID. And when that is set, then that is used. If it not set and SendHostname=true, the hostname is used as Client ID. If SendHostname=false and Client ID is not send, then none of them are send. Typically the send-hostname thing is actually used for DNS updates, where you send the hostname to the DHCP server, which then gives you a lease and sends the hostname + IP to the DNS server, so that your machine is accessible via DNS automatically. I've never heard of it being used as a Client ID, and AFAIK the send hostname and client ID can both be used at the same time. Dan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] core: do not add default dependencies to /usr mount unit
On Tue, 22.07.14 00:39, Jon Severinsson (j...@severinsson.net) wrote: This makes no difference if /usr was mounted in the initrd, and brings the behaviour of legacy systems closer to those with a propper initrd. I applied this one now, as /usr is probably indeed mostly like /, and we shouldn't handle it at all with default dependencies. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] units: add RequiresMountsFor=/usr/… to various systemd service files
On Tue, 22.07.14 14:45, Jon Severinsson (j...@severinsson.net) wrote: At Tuesday 22 July 2014 13:01:24 Lennart Poettering wrote: I am totally not convinced this would be a good idea. You cannot fix this anyway... Think about udevd: if you start it without /usr is around, then it won't find the rules files below /usr. So by your logic you'd add a RequiresMountsFor=/usr to udev's service file. But that would totally break things, as the backing device for /usr will not become available without udev. The difference being that systemd units and udev rules goes to $(rootlibdir) by default, but these goes to $(libdir) by default. Also, systemd units and udev rules might be required to mount local file systems, these are not. systemd currently doesn't totally fail if /usr is found to be empty when it initializes, but it will set a taint flag, since that really is an unsupported setup. I'm well aware that a separate /usr not mounted in the initrd is an unsupported setup, but a separate /usr/local *is* supposed to work, and making a separate /usr slightly less broken when it comes at virtually no extra cost (on top of getting a separate /usr/local working) is imho a good thing. I am tempted to say that stuff that runs in early-boot (i.e. before basic.target) cannot be split off into external partitions. And the ones you list in your patch are all things that run in early boot... (Also tmpfiles is ordered after local-fs.target anyway, so it is actually ordered after /usr/local anyway, indirectly) (And /usr/share/zoneinfo is something that is never Ok to split off. We are not playing games of trying to come up with more exciting schemes how people split up /usr. Really, /usr should be one thing, and maybe /usr/local split off, but then it shouldn't expect to install anything into early boot really...) 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 v3] readahead: use BTRFS_IOC_DEFRAG_RANGE
On Mon, 21.07.14 20:23, Timofey Titovets (nefelim...@gmail.com) wrote: Just completed TODO: * readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG ioctl, with START_IO Hmm, the patch is line broken... But this patch only replaces one ioctl with another right? It doesn't actually improve anything effectively, does it? I am not really convinced that we should make this change, maybe we should remove readahead from the the package instead... commit d3fc81bd6a5a046b22600ac1204df220c93d2c15 refs/tags/v30 Author: Lennart Poettering lenn...@poettering.net Date: Wed Jun 15 15:39:10 2011 +0200 update TODO i no add this todo in TODO list (recursively todo %), and as this my opinion may be not relevant with author. As i understand start_io option force write data after defragment, without buffering it in memory. v1 - v2 Fixed spelling in TODO v2 - v3 Deleted todo from code Fix compilation issues Delete fallback code, because BTRFS_IOC_DEFRAG_RANGE supported as 2.6.29 oldest longterm 2.6.32.63 Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [HEADS-UP] Intent to remove readahead from systemd
Heya, Since its early days systemd contained the systemd-readahead tool, whose job was to improve boot times by reading files in their order on disk, before they would actually be needed by applications. In times of SSD the benefit of systemd-readahead is much less convincing, in many case it actually slows things down. The fact is now that nobody really cares about systemd-readahead much anymore. Nobody in the systemd team still works on a laptop with rotating media, hence nobody tries to optimize it in any way. And it probably needs a lot of looking after and love to still be useful as general purpose systems, instead of just slowing them down... So, I think with the release after the upcoming one we should just remove it from the systemd package and just throw it on the pile of historic cruft. So, yeah, here's the advance warning that this will be happening... (Well, unless somebody from the community who cares and wants to invest the necessary time in it steps up and gives it the love it really needs. If nobody does until that release, I will delete the component from systemd). I fully understand that not everybody uses SSDs yet, and also that theoretically doign systemd-readahead on SSD could be beneficial still (since RAM is still orders of magnitude faster than SSDs), but it's really not about that, it's about maintainership and giving the tool the love it needs. 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] race conditions after SIGTERM
В Thu, 14 Aug 2014 14:24:49 +0200 Lennart Poettering lenn...@poettering.net пишет: On Sun, 27.07.14 20:04, Reindl Harald (h.rei...@thelounge.net) wrote: but that still don't explain why ExecStopPost=/sur/bin/true or whatever ExecStopPost solves that and if it is not supported why systemctl don't return after the one and only process exited Well, this is a misunderstanding how ExecStop= and friends are supposed to work. They are supposed to do what they did on sysvinit: synchronously terminate a service. And not asynchronously do that. I have to ask again - why is forcing every package to re-implement busy loop waiting for process to exit better than doing this wait in one place - PID 1 - which is the most natural place to do it? We hence don't wait for anything else then, because what is left afterwards must be left-over processes that ExecStop= and friends couldn't clean up properly... Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] eye of cylon / timeout timer is cut off
On Thu, Aug 14, 2014 at 06:44:03PM +0200, Michael Biebl wrote: 2014-08-14 18:36 GMT+02:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: It would be more useful to remove the / 1min 30s part. Maybe the cylon code could be smart enough for that. I think it's useful information to know that the timeout is 90s. An alternative could be, to simply use seconds and not convert that into h:m:s values. A 77s / 90s display would be ok to me. What I meant is to skip the limit only where there is a shortage of space. But thinking about it again, it is hard to say which is more important. So maybe it is better to instead display the time remaining, like -33s, -32s, -31s... when columns() = 80. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] race conditions after SIGTERM
On Thu, 14.08.14 21:16, Andrei Borzenkov (arvidj...@gmail.com) wrote: В Thu, 14 Aug 2014 14:24:49 +0200 Lennart Poettering lenn...@poettering.net пишет: On Sun, 27.07.14 20:04, Reindl Harald (h.rei...@thelounge.net) wrote: but that still don't explain why ExecStopPost=/sur/bin/true or whatever ExecStopPost solves that and if it is not supported why systemctl don't return after the one and only process exited Well, this is a misunderstanding how ExecStop= and friends are supposed to work. They are supposed to do what they did on sysvinit: synchronously terminate a service. And not asynchronously do that. I have to ask again - why is forcing every package to re-implement busy loop waiting for process to exit better than doing this wait in one place - PID 1 - which is the most natural place to do it? Which is what we do. Except when you specify ExecStop= which basically tells systemd that you want to do it instead. So there you go! 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] How to get rid of this ordering cycle?
On Aug 14, Lennart Poettering lenn...@poettering.net wrote: Hmm, Debian still generates persistent rules at boot? Yuck! Experience shows that it worked better than the alternatives for our users, so I think that we will just keep it around for a while, probably until most hardware will provide persistent names via BIOS tables. -- ciao, Marco signature.asc Description: Digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] readahead: use BTRFS_IOC_DEFRAG_RANGE
On Tue, 22.07.14 06:29, Andrey Borzenkov (arvidj...@gmail.com) wrote:
В Mon, 21 Jul 2014 18:15:37 +0300
Timofey Titovets nefelim...@gmail.com пишет:
Zbyszek, i research problem and i found what in btrfs.h
struct btrfs_ioctl_defrag_range_args not defined
This acceptable if i add it in missing.h like:
/* btrfs_ioctl_defrag_range_args now 21.07.2014
* not defined in btrfs.h and duplicated from kernel/fs/btrfs/ctree.h
*/
#ifdef HAVE_LINUX_BTRFS_H
struct btrfs_ioctl_defrag_range_args {
uint64_t start; /* start byte = 0 */
uint64_t len; /* whole file uint64_t-1 */
uint64_t flags; /* start_io 2 */
uint32_t extent_thresh; /* 0 */
uint32_t compress_type;
uint32_t unused[4];
};
#endif
I think it should really be discussed on btrfs list. It must be
properly exported to user space if user space is going to use it.
Well, the ioctls of btrfs seldom come with proper userpace headers
unfortunately...
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] readahead: use BTRFS_IOC_DEFRAG_RANGE
On Mon, 21.07.14 15:02, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Mon, Jul 21, 2014 at 09:38:57AM +0300, Timofey Titovets wrote: Just completed TODO: * readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG This is still not an explanation. What is the difference between the two? The idea really was to just defrag the bits of files that we really needed instead of all of them... 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 1/3] socket: Add Support for TCP keep alive variables
The tcp keep alive variables now can be configured via conf
parameter. Follwing variables are now supported by this patch.
tcp_keepalive_intvl: The number of seconds between TCP keep-alive probes
tcp_keepalive_probes: The maximum number of TCP keep-alive probes to
send before giving up and killing the connection if no response is
obtained from the other end.
tcp_keepalive_time: The number of seconds a connection needs to be
idle before TCP begins sending out keep-alive probes.
---
man/systemd.socket.xml| 36 +++
src/core/dbus-socket.c| 3 +++
src/core/load-fragment-gperf.gperf.m4 | 3 +++
src/core/socket.c | 36 +++
src/core/socket.h | 3 +++
5 files changed, 81 insertions(+)
diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
index 352825f..5efb398 100644
--- a/man/systemd.socket.xml
+++ b/man/systemd.socket.xml
@@ -488,6 +488,42 @@
/varlistentry
varlistentry
+termvarnameKeepAliveTime=/varname/term
+listitemparaTakes time (in seconds) as
argument . The connection needs to remain
+idle before TCP starts sending keepalive
probes. This controls the TCP_KEEPIDLE
+socket option (see
+
citerefentryrefentrytitlesocket/refentrytitlemanvolnum7/manvolnum/citerefentry
+and the ulink
+
url=http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/;TCP
+Keepalive HOWTO/ulink for details.)
+Defaults value is 7200 seconds (2
hours)./para/listitem
+/varlistentry
+
+varlistentry
+
termvarnameKeepAliveInterval=/varname/term
+listitemparaTakes time (in seconds) as
argument between individual keepalive probes,
+if the socket option SO_KEEPALIVE has been
set on this socket seconds as argument.
+This controls the TCP_KEEPINTVL socket option
(see
+
citerefentryrefentrytitlesocket/refentrytitlemanvolnum7/manvolnum/citerefentry
+and the ulink
+
url=http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/;TCP
+Keepalive HOWTO/ulink for details.)
+Defaults value is 75 seconds./para/listitem
+/varlistentry
+
+varlistentry
+
termvarnameKeepAliveProbes=/varname/term
+listitemparaTakes interger as argument.
It's the number of unacknowledged probes to
+send before considering the connection dead
and notifying the application layer.
+This controls the TCP_KEEPCNT socket option
(see
+
citerefentryrefentrytitlesocket/refentrytitlemanvolnum7/manvolnum/citerefentry
+and the ulink
+
url=http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/;TCP
+Keepalive HOWTO/ulink for details.)
+Defaults value is 9./para/listitem
+/varlistentry
+
+varlistentry
termvarnameNoDelay=/varname/term
listitemparaTakes a boolean
argument. TCP Nagle's algorithm works by
combining a number of
diff --git a/src/core/dbus-socket.c b/src/core/dbus-socket.c
index ad135a1..bdf111c 100644
--- a/src/core/dbus-socket.c
+++ b/src/core/dbus-socket.c
@@ -97,6 +97,9 @@ const sd_bus_vtable bus_socket_vtable[] = {
SD_BUS_PROPERTY(DirectoryMode, u, bus_property_get_mode,
offsetof(Socket, directory_mode), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(Accept, b, bus_property_get_bool, offsetof(Socket,
accept), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(KeepAlive, b, bus_property_get_bool,
offsetof(Socket, keep_alive), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(KeepAliveTime, t, bus_property_get_usec,
offsetof(Socket, keep_alive_time), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(KeepAliveInterval, t, bus_property_get_usec,
offsetof(Socket, keep_alive_interval), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(KeepAliveProbes, u, bus_property_get_unsigned,
offsetof(Socket, keep_alive_cnt), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(Priority, i, bus_property_get_int,
offsetof(Socket, priority),
[systemd-devel] [PATCH 2/3] socket: Add support for TCP defer accept
TCP_DEFER_ACCEPT Allow a listener to be awakened only when data
arrives on the socket. If TCP_DEFER_ACCEPT set on a server-side
listening socket, the TCP/IP stack will not to wait for the final
ACK packet and not to initiate the process until the first packet
of real data has arrived. After sending the SYN/ACK, the server will
then wait for a data packet from a client. Now, only three packets
will be sent over the network, and the connection establishment delay
will be significantly reduced.
---
man/systemd.socket.xml| 24
src/core/dbus-socket.c| 1 +
src/core/load-fragment-gperf.gperf.m4 | 1 +
src/core/socket.c | 12
src/core/socket.h | 1 +
5 files changed, 39 insertions(+)
diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
index 5efb398..38f16e5 100644
--- a/man/systemd.socket.xml
+++ b/man/systemd.socket.xml
@@ -546,6 +546,30 @@
/varlistentry
varlistentry
+termvarnameDeferAccept=/varname/term
+listitemparaTakes time (in seconds) as
argument. If set, the listening process
+will be awakened only when data arrives on the
socket, and not immediately
+when connection is established. When this
option is set, the
+constantTCP_DEFER_ACCEPT/constant socket
option will be used
+(see
+
citerefentryrefentrytitletcp/refentrytitlemanvolnum7/manvolnum/citerefentry),
+and the kernel will ignore initial ACK packets
without any data.
+The argument specifies the approximate amount
+of time the kernel should wait for incoming
data before falling
+back to the normal behaviour of honouring
empty ACK packets.
+This option beneficial for protocols where the
client sends the data
+first (e.g. HTTP, in contrast to SMTP),
because the server
+process will not be woken up unnecessarily
before it can take any action.
+/para
+paraIf the client also uses the
constantTCP_DEFER_ACCEPT/constant
+option, the latency of the initial connection
may be
+reduced, because the kernel will send data in
the
+final packet establishing the connection (the
third packet in the
+three-way handshake)./para
+paraDisabled by default./para/listitem
+/varlistentry
+
+varlistentry
termvarnameReceiveBuffer=/varname/term
termvarnameSendBuffer=/varname/term
listitemparaTakes an integer
diff --git a/src/core/dbus-socket.c b/src/core/dbus-socket.c
index bdf111c..cc55b8d 100644
--- a/src/core/dbus-socket.c
+++ b/src/core/dbus-socket.c
@@ -100,6 +100,7 @@ const sd_bus_vtable bus_socket_vtable[] = {
SD_BUS_PROPERTY(KeepAliveTime, t, bus_property_get_usec,
offsetof(Socket, keep_alive_time), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(KeepAliveInterval, t, bus_property_get_usec,
offsetof(Socket, keep_alive_interval), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(KeepAliveProbes, u, bus_property_get_unsigned,
offsetof(Socket, keep_alive_cnt), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(DeferAccept , t, bus_property_get_usec,
offsetof(Socket, defer_accept), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(Priority, i, bus_property_get_int,
offsetof(Socket, priority), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(ReceiveBuffer, t, bus_property_get_size,
offsetof(Socket, receive_buffer), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(SendBuffer, t, bus_property_get_size,
offsetof(Socket, send_buffer), SD_BUS_VTABLE_PROPERTY_CONST),
diff --git a/src/core/load-fragment-gperf.gperf.m4
b/src/core/load-fragment-gperf.gperf.m4
index 67bd0e5..b4e2b25 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -234,6 +234,7 @@ Socket.KeepAlive,config_parse_bool,
0,
Socket.KeepAliveTime,config_parse_sec, 0,
offsetof(Socket, keep_alive_time)
Socket.KeepAliveInterval,config_parse_sec, 0,
offsetof(Socket, keep_alive_interval)
Socket.KeepAliveProbes, config_parse_unsigned, 0,
[systemd-devel] [PATCH 3/3] socket: add bus property for bus property NoDelay
Missed to add the SD_BUS_PROPERTY for no_delay.
---
src/core/dbus-socket.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/core/dbus-socket.c b/src/core/dbus-socket.c
index cc55b8d..e9e2430 100644
--- a/src/core/dbus-socket.c
+++ b/src/core/dbus-socket.c
@@ -101,6 +101,7 @@ const sd_bus_vtable bus_socket_vtable[] = {
SD_BUS_PROPERTY(KeepAliveInterval, t, bus_property_get_usec,
offsetof(Socket, keep_alive_interval), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(KeepAliveProbes, u, bus_property_get_unsigned,
offsetof(Socket, keep_alive_cnt), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(DeferAccept , t, bus_property_get_usec,
offsetof(Socket, defer_accept), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(NoDelay, b, bus_property_get_bool,
offsetof(Socket, no_delay), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(Priority, i, bus_property_get_int,
offsetof(Socket, priority), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(ReceiveBuffer, t, bus_property_get_size,
offsetof(Socket, receive_buffer), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(SendBuffer, t, bus_property_get_size,
offsetof(Socket, send_buffer), SD_BUS_VTABLE_PROPERTY_CONST),
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] race conditions after SIGTERM
В Thu, 14 Aug 2014 19:24:54 +0200 Lennart Poettering lenn...@poettering.net пишет: On Thu, 14.08.14 21:16, Andrei Borzenkov (arvidj...@gmail.com) wrote: В Thu, 14 Aug 2014 14:24:49 +0200 Lennart Poettering lenn...@poettering.net пишет: On Sun, 27.07.14 20:04, Reindl Harald (h.rei...@thelounge.net) wrote: but that still don't explain why ExecStopPost=/sur/bin/true or whatever ExecStopPost solves that and if it is not supported why systemctl don't return after the one and only process exited Well, this is a misunderstanding how ExecStop= and friends are supposed to work. They are supposed to do what they did on sysvinit: synchronously terminate a service. And not asynchronously do that. I have to ask again - why is forcing every package to re-implement busy loop waiting for process to exit better than doing this wait in one place - PID 1 - which is the most natural place to do it? Which is what we do. Except when you specify ExecStop= which basically tells systemd that you want to do it instead. So there you go! Those daemons I have seen are terminated after receiving signal/command to do it. Those sysvinit scripts that synchronously terminated services did it by implementing wait for daemon process to exit. What is worse, the only way to do it is busy looping as they cannot normally receive notification about process exit. So currently package author who needs to be sure daemon have enough time to finish housekeeping have choice between a) implement custom busy looping a la sysvinit script b) implement custom synchronous protocol between daemon and external program that somehow connects to daemon and blocks until daemon is terminated Compare this with send daemon command - signal or whatever - and wait until it exits. This needs to be implemented just once in PID 1 - and PID 1 already does exactly this most of the time anyway. Why is this the wrong thing to do? You never explained this when you rejected my patch. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] Refuse mount on symlink
Okay, i will rebase and resend, and add warning
But what i must do with message:
symlink.mount failed to run 'mount' task: Too many levels of symbolic links?
Just leave and add additional massage error or replace?
2014-08-14 20:31 GMT+03:00 Timofey Titovets nefelim...@gmail.com:
Okay, i will rebase and resend, and add warning
But what i must do with message:
symlink.mount failed to run 'mount' task: Too many levels of symbolic links?
Just leave and add additional massage error or replace?
2014-08-14 20:05 GMT+03:00 Lennart Poettering lenn...@poettering.net:
On Mon, 21.07.14 19:24, Timofey Titovets (nefelim...@gmail.com) wrote:
Doesn't apply to current git. Could you please rebase on current git?
+int fail_if_symlink(const char *unit, const char* where) {
+assert(where);
+
+if (!is_symlink(where))
+return 0;
This should probably be if (is_symlink(where) 0).
Also I think we should print an explicit message here, that tells the
admin that mounting symlinks is not supported.
Sorry for the long delay in responding.
Lennart
--
Lennart Poettering, Red Hat
--
Best regards,
Timofey.
--
Best regards,
Timofey.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options
On Mon, 21.07.14 10:46, Marc Haber (mh+systemd-de...@zugschlus.de) wrote: Heya, I have read the thread (from 2012?) where those things were discussed here and I understand that I should replace my keyscript with a passwort agent. Things would then work like this: There's currently no streamlined support for stacking password questions really. You currently cannot take possession of specific password questions. Also note that we really should redesign the entire scheme around the kernel keyring as only transport for the keys (and the bus for signalling). I am a bit conservative in changing here too much for now, because we really should figure out that bit first. (4) My PasswordAgent indicates taking responsibility by unlinking the ask.xxx file from /run/systemd/ask-password. The interactive password Well, so far it is the querier that removes the file, not the agent... agents will remove their interactive requests then. The user will therefore see the password request popping up for a very short period of time, if at all. (5) Should my PasswordAgent need a password to act itself (like a PIN for a hardware device, for example), it would place its own ask.xxx file in /run/systemd/ask-password. The interactive PasswordAgents would act on that, obtain the password/PIN interactively from the user and return it to my PasswordAgent. (6) My PasswordAgent would then obtain the password for the file system itself and return it to systemd which can now proceed to unlock the file system. Am I understanding things correctly so far? Yes, this should indeed work. If so, this leaves the task to write my PasswordAgent. I have found some example code in python for a password agent. To use this to unlock the root fs, an entire python installation would need to go in my initramfs, right? And if I want to keep things simple, the best idea would be to write my PasswordAgent in a compiled language which would only need the binary and its libs in the initramfs, right? Yes. Correct. If you want to stick something into the initrd, I'd always do things in C (or shell if you must), but nothing else. Is there code for an example PasswordAgent in C++ which I can use as a template? I am quite reluctant to write a program which needs to to complex string processing and is bound to run as root in C because my C experience is somewhat lacking. Not aware of an C++ code. There's a vala one, and of course the one we ship in systemd itself in C, but c++ i cannot help you with, sorry. Can you please recommend a way to allow me to migrate to systemd? Without keyscript= being supported in /etc/crypttab, I need to replace my 50 line key script written in POSIX shell and would like to keep things simple. Thank you very much for your consideration. I fear I don#t have an easy suggestion. What kind of device do you actually want to make work here? some smartcard or so? I think in the long run we should somehow work towards the direction to make things like that just work, for common devices like smartcards and other auth tokens... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] Refuse mount on symlink
On Thu, 14.08.14 20:31, Timofey Titovets (nefelim...@gmail.com) wrote:
Okay, i will rebase and resend, and add warning
But what i must do with message:
symlink.mount failed to run 'mount' task: Too many levels of symbolic links?
Just leave and add additional massage error or replace?
Yeah, I think it's OK to leave both messages in there.
2014-08-14 20:05 GMT+03:00 Lennart Poettering lenn...@poettering.net:
On Mon, 21.07.14 19:24, Timofey Titovets (nefelim...@gmail.com) wrote:
Doesn't apply to current git. Could you please rebase on current git?
+int fail_if_symlink(const char *unit, const char* where) {
+assert(where);
+
+if (!is_symlink(where))
+return 0;
This should probably be if (is_symlink(where) 0).
Also I think we should print an explicit message here, that tells the
admin that mounting symlinks is not supported.
Sorry for the long delay in responding.
Lennart
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] race conditions after SIGTERM
On Thu, 14.08.14 21:38, Andrei Borzenkov (arvidj...@gmail.com) wrote: Which is what we do. Except when you specify ExecStop= which basically tells systemd that you want to do it instead. So there you go! Those daemons I have seen are terminated after receiving signal/command to do it. Those sysvinit scripts that synchronously terminated services did it by implementing wait for daemon process to exit. What is worse, the only way to do it is busy looping as they cannot normally receive notification about process exit. Well, if they don't have such a protocol, then they can use systemd's default logic for this, and just tweak the parameters. KillMode=, KillSignal=, TimeoutStopSec= are all ways how you can control how exactly systemd should terminate your service. Compare this with send daemon command - signal or whatever - and wait until it exits. This needs to be implemented just once in PID 1 - and PID 1 already does exactly this most of the time anyway. Why is this the wrong thing to do? You never explained this when you rejected my patch. Hmm, this is what we do. By specifiying ExecStop= you turn that off however can plug in your own logic. If you don't have any better logic, then simply don't plug anything in, that's what we recommend anyway. Again: systemd does what you want it to do by default, anyway. By specifiying ExecStop= you however turn this off, and have to do it on your own! 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] resolved: fix warnings
On Sat, 19.07.14 10:37, Thomas H.P. Andersen (pho...@gmail.com) wrote:
--- a/src/resolve/resolved-dns-scope.c
+++ b/src/resolve/resolved-dns-scope.c
@@ -292,7 +292,7 @@ int dns_scope_llmnr_membership(DnsScope *s, bool b) {
if (s-family == AF_INET) {
struct ip_mreqn mreqn = {
.imr_multiaddr = LLMNR_MULTICAST_IPV4_ADDRESS,
-.imr_ifindex = s-link-ifindex,
+.imr_ifindex = s-link ? s-link-ifindex : 0,
LLMNR scopes don't exist with a NULL link value, they are strictly bound
to physical links.
I have now added a couple of assert()s to the function, that should
clarify that and hopefully tell the compiler that these are necessarily
initialized.
Does this make things work for you? Please check.
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] machine_kill(): Don't kill the unit when killing the leader
If machinectl poweroff or machinectl reboot is used on a
systemd-nspawn container started with --keep-unit and --register, it
should *only* send the appropriate signal to the leader PID (i.e. the
container's systemd process). It shouldn't fall through to
manager_kill_unit() to also send the signal to the unit. The latter
ends up killing systemd-nspawn, which takes down the container
prematurely.
---
src/machine/machine.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/machine/machine.c b/src/machine/machine.c
index 1c9177e..13d3448 100644
--- a/src/machine/machine.c
+++ b/src/machine/machine.c
@@ -493,6 +493,8 @@ int machine_kill(Machine *m, KillWho who, int signo) {
if (kill(m-leader, signo) 0)
return -errno;
+
+return 0;
}
/* Otherwise make PID 1 do it for us, for the entire cgroup */
--
1.9.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] compile with clang broken
On Fri, 18.07.14 16:02, Thomas H.P. Andersen (pho...@gmail.com) wrote: 1716f6dcf54d4c181c2e2558e3d5414f54c8d9ca (resolved: add LLMNR support for looking up names) broke the build on clang. src/resolve/resolved-manager.c:553:43: error: non-const static data member must be initialized out of line uint8_t buffer[CMSG_SPACE(MAX(sizeof(struct in_pktinfo), sizeof(struct in6_pktinfo))) Moving the MAX(...) to a separate line fixes that problem but another error then happens: src/resolve/resolved-manager.c:554:25: error: fields must have a constant size: 'variable length array in structure' extension will never be supported uint8_t buffer[CMSG_SPACE(size) We have encountered the same problem before and Lennart was able to write the code in a different way. Would this be possible here too? My sugegstion here would be to maybe rewrite the MAX() macro to use __builtin_constant_p() so that it becomes constant if the params are constant, and only uses code block when it isn't. Or so... http://lists.freedesktop.org/archives/systemd-devel/2014-August/021912.html 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] Thoughts about /etc/crypttab keyscript options
Hi On Thu, Aug 14, 2014 at 7:44 PM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 21.07.14 10:46, Marc Haber (mh+systemd-de...@zugschlus.de) wrote: Heya, I have read the thread (from 2012?) where those things were discussed here and I understand that I should replace my keyscript with a passwort agent. Things would then work like this: There's currently no streamlined support for stacking password questions really. You currently cannot take possession of specific password questions. Also note that we really should redesign the entire scheme around the kernel keyring as only transport for the keys (and the bus for signalling). I am a bit conservative in changing here too much for now, because we really should figure out that bit first. The hack you describe here should work, however, it's really an ugly hack. One thing you really need to take care of is to not cause recursive loops. That is, if your agent places a new *.ask file, it will be called on it again and *must* ignore it. Otherwise, you end up with an endless loop. Anyhow, I don't think we should support stacked agents. Agents are meant as an API to interact with users. They should not employ any logic/rules regarding the query itself. They're solely meant as GUI. That is, to solve your problem, I'd recommend to make systemd allow external scripts like keyscript= before placing *.ask files (or some other hookup or configuration, if scripts are not suitable for that). I have never worked with crypttab, though. I have to refer to Lennart here to tell whether that makes sense. I just want to make clear that once you query the ask-password tool, you will inevitably end up forwarding that request unchanged to an UI. Polkit provides .rule scripts for that. We don't have any equivalent for ask-password. I'm not sure whether that would make sense. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] machine_kill(): Don't kill the unit when killing the leader
On Thu, 14.08.14 19:59, Eelco Dolstra (eelco.dols...@logicblox.com) wrote:
Thanks!
Applied!
If machinectl poweroff or machinectl reboot is used on a
systemd-nspawn container started with --keep-unit and --register, it
should *only* send the appropriate signal to the leader PID (i.e. the
container's systemd process). It shouldn't fall through to
manager_kill_unit() to also send the signal to the unit. The latter
ends up killing systemd-nspawn, which takes down the container
prematurely.
---
src/machine/machine.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/machine/machine.c b/src/machine/machine.c
index 1c9177e..13d3448 100644
--- a/src/machine/machine.c
+++ b/src/machine/machine.c
@@ -493,6 +493,8 @@ int machine_kill(Machine *m, KillWho who, int signo) {
if (kill(m-leader, signo) 0)
return -errno;
+
+return 0;
}
/* Otherwise make PID 1 do it for us, for the entire cgroup */
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] Thoughts about /etc/crypttab keyscript options
Hi Lennart, thanks for your thoughts. On Thu, Aug 14, 2014 at 07:44:59PM +0200, Lennart Poettering wrote: On Mon, 21.07.14 10:46, Marc Haber (mh+systemd-de...@zugschlus.de) wrote: (4) My PasswordAgent indicates taking responsibility by unlinking the ask.xxx file from /run/systemd/ask-password. The interactive password Well, so far it is the querier that removes the file, not the agent... I see. What would happen if I remove the file myself? To use this to unlock the root fs, an entire python installation would need to go in my initramfs, right? And if I want to keep things simple, the best idea would be to write my PasswordAgent in a compiled language which would only need the binary and its libs in the initramfs, right? Yes. Correct. If you want to stick something into the initrd, I'd always do things in C (or shell if you must), but nothing else. Is there code for an example PasswordAgent in C++ which I can use as a template? I am quite reluctant to write a program which needs to to complex string processing and is bound to run as root in C because my C experience is somewhat lacking. Not aware of an C++ code. There's a vala one, and of course the one we ship in systemd itself in C, but c++ i cannot help you with, sorry. Is it possible to write a PasswordAgent in shell? Example code please ;) Can you please recommend a way to allow me to migrate to systemd? Without keyscript= being supported in /etc/crypttab, I need to replace my 50 line key script written in POSIX shell and would like to keep things simple. Thank you very much for your consideration. I fear I don#t have an easy suggestion. What kind of device do you actually want to make work here? some smartcard or so? That's the vision, yes. At the moment, my keyscript unlocks a small LUKS partition on the disk and takes the key for the root fs from there. That's just a placeholder for a future more complicated setup. With Debian's initramfs, unlocking the small LUKS partition works transparently even with plymouth. This is real functionality being lost in the systemd migration. I think in the long run we should somehow work towards the direction to make things like that just work, for common devices like smartcards and other auth tokens... First step to do that would be to implement support for the keyscript= option in /etc/crypttab as this is the canonical place to hook into on non-system systems. At least it's the case on Debian, I don't know about Red Hat, Fedora and other distributions. The PasswordAgent stuff is really neat, but complicated due to the socket communication, and it's far from being a drop-in replacement. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options
Hi, On Thu, Aug 14, 2014 at 08:09:05PM +0200, David Herrmann wrote: That is, to solve your problem, I'd recommend to make systemd allow external scripts like keyscript= before placing *.ask files (or some other hookup or configuration, if scripts are not suitable for that). If systemd would support keyscript=, migration would be painless. I am absolutely in favor of that ;-) Greetings Marc, unfortunately too bad a C programmer to write a patch -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things.Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600420 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Thoughts about /etc/crypttab keyscript options
On Thu, 14.08.14 20:10, Marc Haber (mh+systemd-de...@zugschlus.de) wrote: Not aware of an C++ code. There's a vala one, and of course the one we ship in systemd itself in C, but c++ i cannot help you with, sorry. Is it possible to write a PasswordAgent in shell? Example code please ;) Probably possible, after all bash allows you to talk to unix sockets and stuff. And you could probably put the protocol together with carefully crafted echo lines, but I know of nobody who has done that so far... I fear I don#t have an easy suggestion. What kind of device do you actually want to make work here? some smartcard or so? That's the vision, yes. At the moment, my keyscript unlocks a small LUKS partition on the disk and takes the key for the root fs from there. That's just a placeholder for a future more complicated setup. Not following. You place a key for a LUKS partition on another LUKS partition? What's the benefit of that? Inception? ;-) With Debian's initramfs, unlocking the small LUKS partition works transparently even with plymouth. This is real functionality being lost in the systemd migration. Haven't understood your setup yet I must say, before I can agree that this is real functionality... I think in the long run we should somehow work towards the direction to make things like that just work, for common devices like smartcards and other auth tokens... First step to do that would be to implement support for the keyscript= option in /etc/crypttab as this is the canonical place to hook into on non-system systems. At least it's the case on Debian, I don't know about Red Hat, Fedora and other distributions. Well, I am really not convinced that this is a well-defined interface. Even in your case you have to wait for two devices at least, right? a synchronous shell callout won't solve that for you since there's no guarantee that the second LUKS device has already shown up, or am I missing something? Shell callouts always appear simply or powerful, but when it comes to waiting for devices, and executing things as things pop up its often really not the right tool. As mentioned we really should redesign the whole thing around the kernel keyring anyway, I am really conservative in adding support for Debian's keyscript thingy upstream now. (That of course shouldn't stop Debian from adding this downstream) The PasswordAgent stuff is really neat, but complicated due to the socket communication, and it's far from being a drop-in replacement. Well, it's really easy in C I figure, but admittedly not in shell... 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] Start Up services using systemd
On Mon, 21.07.14 17:26, Bharath Chandra (ellurubharat...@gmail.com) wrote: Heya, Hi, I am trying to analyze what all services that would start during boot up process statically, i.e just by looking into the unit files, without running the system. I have understood the dependecies of unit files using Wants, Requires,After but i do not find all of the services which are listed under a specific target.wants directory to be in active state. Some services actually terminate after they have done their job. Do you have any services in particular in mind here that do not stay active? From which targets are they pulled in? Eg: All the services are not loaded which are present under multi-user.target.wants directory. I am new to systemd. Kindly help me in understanding the dependencies. This is actually not that easy, as many of the services started at boot might get pulled in dynamically due to udev rules, or because of generators and suchlike which can dynamically extend the initial transaction depending on external configuration. 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] Forcing default route as the one provided by one interface
On Thu, 17.07.14 15:44, Mauricio Tavares (raubvo...@gmail.com) wrote: Newbie question: if I have two interfaces (in separate networks) with each of them using DHCP, how can I specify that I want the default route to be the one being obtained by, say, interface A? I read through http://www.freedesktop.org/software/systemd/man/systemd.network.html and did not see any option to specify that a given interface is providing the default gateway. Am I missing something? If such an option does not exist, would it be possible to have a, say, SetDefaultGateway/UseDefaultGateway (boolean) option to do so? networkd should probably gain a way to define a default metric for all routes defined on a specific .network, and maybe a second one as default metric for all DHCP acquired routes on a specify network. That way you could just set two different defaults for your two networks and the IP stack will always use the right one. Added to the TODO list. 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] Warnings from recent commits
On Mon, 21.07.14 16:09, Samuli Suominen (ssuomi...@gentoo.org) wrote:
4.6 is the minimum dependency as-is, for eg. _Static_assert,
DISABLE_WARNING_{DECLARATION_AFTER_STATEMENT,FORMAT_NONLITERAL,MISSING_PROTOTYPES,NONNULL},
REENABLE_WARNING
Just to get the udev part of the systemd tree compiled with gcc-4.5 or
older, you need something like,
http://510524.bugs.gentoo.org/attachment.cgi?id=380992
Just saying, that 4.6 minimum wouldn't be a new thing, it's been around
for several releases now
I am fine with supporting gcc 4.5. This patch really looks like it could
be turned into something upstreamable. I mean, we already have a manual
fallback for assert_cc(), so it shouldn't be too hard to figure
something out that works on gcc 4.5. I mean, i think it would be totally
OK to throw warnings on gcc 4.5, as long as it compiles. And the
DISABLE_WARNING_xyz stuff is really only stuff to make warnings go away,
that is all...
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] Bug#758050: udev: ID_VENDOR_FROM_DATABASE, ID_MODEL_FROM_DATABASE for unrecognised USB device are taken from USB hub
On Thu, Aug 14, 2014 at 3:07 PM, Simon McVittie simon.mcvit...@collabora.co.uk wrote: I recently opened this Debian bug, for which I attach a patch that seems to work. Bug report quoted in full below. I would appreciate udev maintainers' opinions on whether this is likely to break non-USB devices, or whether there is a better way to do it. Maybe replace streq(dsubsys, usb) with a specific match on devtype == usb_device (sysfs hierarchy is usb_interface - usb_device) and if we hit that, we make sure we stop looking at any of the parents? Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] resolved: fix warnings
I just hit this assert on my arch system with gcc 4.9,
dbuch-laptop systemd-resolved[457]: Assertion 's-protocol ==
DNS_PROTOCOL_LLMNR' failed at src/resolve/resolved-dns-scope.c:369
2014-08-14 19:58 GMT+02:00 Lennart Poettering lenn...@poettering.net:
On Sat, 19.07.14 10:37, Thomas H.P. Andersen (pho...@gmail.com) wrote:
--- a/src/resolve/resolved-dns-scope.c
+++ b/src/resolve/resolved-dns-scope.c
@@ -292,7 +292,7 @@ int dns_scope_llmnr_membership(DnsScope *s, bool b) {
if (s-family == AF_INET) {
struct ip_mreqn mreqn = {
.imr_multiaddr = LLMNR_MULTICAST_IPV4_ADDRESS,
-.imr_ifindex = s-link-ifindex,
+.imr_ifindex = s-link ? s-link-ifindex : 0,
LLMNR scopes don't exist with a NULL link value, they are strictly bound
to physical links.
I have now added a couple of assert()s to the function, that should
clarify that and hopefully tell the compiler that these are necessarily
initialized.
Does this make things work for you? Please check.
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] [PATCH v2] readahead: use BTRFS_IOC_DEFRAG_RANGE
Just completed TODO: * readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG ioctl, with START_IO Hmm, the patch is line broken... But this patch only replaces one ioctl with another right? It doesn't actually improve anything effectively, does it? I am not really convinced that we should make this change, maybe we should remove readahead from the the package instead... On my machine it not get my any speed up (btrfs, hdd/ssd, latest arch). But i already talk with ext4 developers, and one of devs try to port e4rat functionally to ext progs and mainline kernel. And as i think on ext4, we can port to readahead functional from ext progs and defrag files what reading while boot, to one line on hdd. But it function must be part of systemd? 2014-08-14 20:29 GMT+03:00 Lennart Poettering lenn...@poettering.net: On Mon, 21.07.14 15:02, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Mon, Jul 21, 2014 at 09:38:57AM +0300, Timofey Titovets wrote: Just completed TODO: * readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG This is still not an explanation. What is the difference between the two? The idea really was to just defrag the bits of files that we really needed instead of all of them... On btrfs with compress mount option, we can't determine file fragmented or not, i'm didn't deep read of btrfs progs while porting BTRFS_IOC_DEFRAG_RANGE, but as i understand btrfs self defrag files and BTRFS_IOC_DEFRAG_RANGE just add aditional filters to this operation, but i can be wrong. Lennart -- Lennart Poettering, Red Hat -- Best regards, Timofey. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3 2/3] cxgb4: use module_long_probe_init()
On Thu, Aug 14, 2014 at 09:42:49AM -0700, Casey Leedom wrote: On 08/13/2014 04:33 PM, Anish Bhatt wrote: Adding Casey who's actually incharge of this code and missing from the CC list Thanks Anish! As I mentioned to Anish, there are fundamentally two problems here in the time being consumed by the cxgb4 PCI probe() function: 1. When various firmware files aren't present, request_firmware() can take a very long time. This is easily solved by using request_firmware_direct() and I certainly have no objection to that. I sent a patch for this a while ago, since there is no objection if you'd like to apply the patch: http://patchwork.ozlabs.org/patch/363756/ Apart from that you also want to use asynch firmware loading but to use that properly (I also had sent some basic initial patches for asynch firmware loading but without moving out other logic yet) you want to also let driver initalization complete asynchronously later. 2. When there are multiple adapters present in a system which need firmware downloaded, each one individually may not take a ton of time but together they can exceed simple Module Load Timeouts. There's not a simple answer here. I had originally recommended to write your own platform driver for this and have each port probe but Greg has provided the last advice for this on the patch I sent to add deferred probe support from init, his recommendation was for you to write your own bus code for the driver: http://www.spinics.net/lists/linux-scsi/msg76695.html Part of the problem here is that it's a Module Load Timeout instead of a per-device Probe Timeout. Seems like you can fix this with a bus driver. Part of the problem is that the current architecture has Device Probe happening out of the Module Initialization when we call pci_register_driver() with our PCI Device ID Table. Running the Device Probes asynchronously has been discussed but that has the problem that it's then impossible to return the Device Probe Status. This is a problem for Driver Fallback and, if the probe fails, we're not supposed to call the Device Remove function. To make this work, the synchronous/asynchronous boundary would really need to be up in the PCI Infrastructure layer so the Device Probe status could be captured in the normal logic. This would be a moderately large change there ... Some maintainers consider most of the work to get what you need done simple, I've tried to explain it ain't so, so glad you provided a bit of details here. To be clear its not just about asynch firmware loading, you need a bit more work. Can you evaluate using a bus driver? Deferring the Device Initialization till the first ifup has also been discussed and is certainly possible, though a moderately large architectural change to every driver which needs it. It also has the unfortunate effect of introducing random large delays directly on user commands. From a User Experience perspective I would tend to want such large delays in the Device Probe You should just use asynch firmware loading there and only once your driver is done loading firmware start exposing the device(s) as you see fit with your bus driver. . But that's something that really deserves a real User Interaction study rather than throwing a dart. On the whole, I think that introducing these Module Load Timeouts hasn't been well thought out with respect to the repercussions and I'd be more inclined to back that out till a well thought out design is developed. But I'm here for the discussion. The way that the 30 second timeout was introduced as a new driver initialization requirement was certainly not ideal specially since the respective systemd patch that intended to trigger the SIGKILL on kmod module loading only took effect once kernel commit 786235ee went in about a year later, and since the original systemd commit was only addressing asynchronous firmware loading as a possible issue that drivers may need to fix. The cxgb4 driver is a good example that needs quite a bit of more work. Regardless systemd folks are right -- but again, having this be introduced as a new requirement that otherwise simply kills drivers seems a bit too aggressive specially if its killing boot on some systems due to delays on storage drivers. What's done is done -- and we need to move on. We already reviewed twice now reverting 786235ee and that won't happen, as a compromise we're looking for an easy agreeable general driver work around that would both circumvent the issue and let us easily grep for broken drivers. The deferred probe trick was the first approach and this series addresses the more agreeable solution. This 2 line patch then is what we are looking as work around until your driver gets properly fixed. Apart from these kernel changes there are systemd changes we've looked at modifying, Hannes' patch 9719859c07a, now merged upstream on systemd lets you override the
Re: [systemd-devel] Networkd dhcp hostname override
Hi Dan, Now that networkd can send the systems hostname to the dhcp server, I would find it useful to have an option to override the hostname that gets sent. In my use case, I would like to setup a number of macvlans with different hostnames. Something as simple as [DHCP] SendHostname=true Hostname=foo Sounds useful, though this could just be a single option SendHostname=foobar or so. If not set it sends the system hostname, otherwise the specified hostname. Or something like that. what would this be useful for? Either you send the hostname or you don't. I think what you are looking for is an option to set the Client ID. And when that is set, then that is used. If it not set and SendHostname=true, the hostname is used as Client ID. If SendHostname=false and Client ID is not send, then none of them are send. Typically the send-hostname thing is actually used for DNS updates, where you send the hostname to the DHCP server, which then gives you a lease and sends the hostname + IP to the DNS server, so that your machine is accessible via DNS automatically. I've never heard of it being used as a Client ID, and AFAIK the send hostname and client ID can both be used at the same time. this means that allowing to provide a custom hostname that is not set via hostname or hostnamectl makes no sense at all. Since you want to send your actual hostname. So current boolean for SendHostname is the right way to do this. In addition someone might add a ClientId=foo option. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Networkd dhcp hostname override
Typically the send-hostname thing is actually used for DNS updates, where you send the hostname to the DHCP server, which then gives you a lease and sends the hostname + IP to the DNS server, so that your machine is accessible via DNS automatically. I've never heard of it being used as a Client ID, and AFAIK the send hostname and client ID can both be used at the same time. Yes. In my network the Host Name dhcp option is used to configure dns. I am attempting to use a single machine to operate several instances of the same server. Therefore I need to bind each server to a unique IP. Currently I use macvlan and dhcpcd to have the dns entries created. this means that allowing to provide a custom hostname that is not set via hostname or hostnamectl makes no sense at all. I will agree that conventionally in the linux world the hostname is for the system itself and not per interface. I suppose it needs to be decided whether it is tolerable for this convention to be bent in networkd. Bridged virtual machines effectively do the same thing, but one could argue it isn't really the same machine. Since you want to send your actual hostname. In this case I don't, I want to specify a custom host name for dhcp on a specific interface. So current boolean for SendHostname is the right way to do this. In addition someone might add a ClientId=foo option. I am not very familiar with the Client ID. It appears to only be useful to change if you wanted multiple dhcp leases with the same hardware address, which I have avoided with macvlans. Regards, Thomas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Networkd dhcp hostname override
On Thu, 2014-08-14 at 14:29 -0700, Thomas Suckow wrote: Typically the send-hostname thing is actually used for DNS updates, where you send the hostname to the DHCP server, which then gives you a lease and sends the hostname + IP to the DNS server, so that your machine is accessible via DNS automatically. I've never heard of it being used as a Client ID, and AFAIK the send hostname and client ID can both be used at the same time. Yes. In my network the Host Name dhcp option is used to configure dns. I am attempting to use a single machine to operate several instances of the same server. Therefore I need to bind each server to a unique IP. Currently I use macvlan and dhcpcd to have the dns entries created. this means that allowing to provide a custom hostname that is not set via hostname or hostnamectl makes no sense at all. I will agree that conventionally in the linux world the hostname is for the system itself and not per interface. I suppose it needs to be decided whether it is tolerable for this convention to be bent in networkd. Bridged virtual machines effectively do the same thing, but one could argue it isn't really the same machine. Since you want to send your actual hostname. In this case I don't, I want to specify a custom host name for dhcp on a specific interface. So current boolean for SendHostname is the right way to do this. In addition someone might add a ClientId=foo option. I am not very familiar with the Client ID. It appears to only be useful to change if you wanted multiple dhcp leases with the same hardware address, which I have avoided with macvlans. It's used as a general identifier of the client in any situation, so that the server can pass back specific options. Yes, this can be done by looking at the client MAC address, but that's not sufficient in the following cases: 1) non-Ethernet hardware addresses 2) dual-stack clients using DHCPv4 and DHCPv6 3) you change the NIC and want the same options 4) the NIC doesn't have a permanent MAC address The client ID (and on the DHCPv6 side, the DUID) is the single-identifier solution that should really be used instead of the MAC address. Dan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC] Remove warning: var may be used uninitialized
Good time of day, when i compile systemd i get ton of warning like: var may be used uninitialized in function... May be i can spend some time and create patches with fixes of that warnings? As example declare it by default to 0 or something like that. Or this is not a bug, just feature? %) -- Have a nice day, Timofey. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Networkd dhcp hostname override
It's used as a general identifier of the client in any situation, so that the server can pass back specific options. Yes, this can be done by looking at the client MAC address, but that's not sufficient in the following cases: 1) non-Ethernet hardware addresses 2) dual-stack clients using DHCPv4 and DHCPv6 3) you change the NIC and want the same options 4) the NIC doesn't have a permanent MAC address The client ID (and on the DHCPv6 side, the DUID) is the single-identifier solution that should really be used instead of the MAC address. Touché - Thomas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unit to test if a domain is reachable
On Thu, 17.07.14 11:37, Moviuro (movi...@gmail.com) wrote: However, everything I tried proved an utter failure: target says reached even though it doesn't even have an IP on any link; wait-online obviously didn't even check if I had a DNS whatsoever. This sounds like a shortcoming of your network stack? network-wait-online.target is supposed to be filled with meaning by your networking stack, i.e. NetworkManager or suchlike. The implementation that is networkd should get this right really. Which one are you using? 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] Socket activated SSHD service showing up as a failure when the client connection fReply-To:
On Thu, 17.07.14 13:49, Roger Qiu (roger@polycademy.com) wrote: I've googled around and saw that 255 error code comes up a lot. But most resources talked about ssh not necessarily the sshd. If we ignore 255 code, is it possible we're also ignoring some other real errors, and not just the client failing the connection? Basically I would like sshd to report an error, if it is indeed an error from the host's side, not the client's side. In general I'd recommend to use ExecStart=-/usr/sbin/sshd..., i.e. with the - between the = and the /. This tells systemd to completely ignore the exit/failure status of the process. The reason for this is that if an sshd instance fails it would stay around in failed state. Since you use per-connection instances this might be able to give an attacker the chance to create tons of failed services, until systemd refuses. I'd hence recommend to always ignore errors for services that are instantiated in theoretic unbounded numbers. You'll still get them reported in the logs, but I'd recommend not making them enter a service into failed mode. I hope that makes some sense, 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] Logind error - Failed to abandon session scope: Connection reset
On Thu, 17.07.14 11:49, Roger Qiu (roger@polycademy.com) wrote: Hi, (sorry for the late response) Are you saying that logind should be terminated first then dbus should be terminated second? Yes, dbus should best be stopped after logind. In what situations would their termination sequence get mixed? That's a good question. I am a bit puzzled why this race never shows up for me, but it shows up for you. I mean, looking at the deps both services are not ordered against each other, so it kinda should happen frequently, but it never does for me... Anyway, this is really just cosmetic, the only thing we can fix here I guess is hide the warning. Or just wait for kdbus at which point the problem goes away entirely as the bus will survive the entire system runtime. 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 v3] Refuse mount on symlink
Just complete TODO:
* refuse mounting on symlinks
I not add this TODO, but i think what it avoid potential security
{and/or} bug issues
v2 - v3:
Rebase on latest git
Add message unit: Mount on symlink path not allowed.
if systemd try mounting entry from fstab on symlink, user get:
$ systemctl status symlink.mount
[1:29:45]
● symlink.mount - /symlink
Loaded: loaded (/etc/fstab)
Active: failed (Result: resources)
Where: /symlink
What: /dev/sda2
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
Aug 15 01:26:47 beplan.lan systemd[1]: Mounting /symlink...
Aug 15 01:26:47 beplan.lan systemd[1]: symlink.mount: Mount on symlink
/symlink not allowed.
Aug 15 01:26:47 beplan.lan systemd[1]: symlink.mount failed to run
'mount' task: Too many levels of symbolic links
Aug 15 01:26:47 beplan.lan systemd[1]: Failed to mount /symlink.
Aug 15 01:26:47 beplan.lan systemd[1]: Unit symlink.mount entered failed
state.
can be pulled from:
https://github.com/Nefelim4ag/systemd.git
TODO | 2 --
src/core/mount.c | 21 +
src/core/mount.h | 2 ++
src/shared/util.c | 12
src/shared/util.h | 2 ++
5 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/TODO b/TODO
index d58da71..c8e9f27 100644
--- a/TODO
+++ b/TODO
@@ -93,8 +93,6 @@ Features:
* Add a new verb systemctl top
-* refuse mounting on symlinks
-
* logind: allow users to kill or lock their own sessions
* add new gpt type for btrfs volumes
diff --git a/src/core/mount.c b/src/core/mount.c
index 39a9aaf..f51e0f3 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -827,6 +827,23 @@ void warn_if_dir_nonempty(const char *unit, const
char* where) {
NULL);
}
+int fail_if_symlink(const char *unit, const char* where) {
+assert(where);
+
+if (is_symlink(where) 0) {
+log_struct_unit(LOG_WARNING,
+unit,
+MESSAGE=%s: Mount on symlink %s not
allowed.,
+unit, where,
+WHERE=%s, where,
+MESSAGE_ID(SD_MESSAGE_OVERMOUNTING),
+NULL);
+
+return -ELOOP;
+}
+return 0;
+}
+
static void mount_enter_unmounting(Mount *m) {
int r;
@@ -877,6 +894,10 @@ static void mount_enter_mounting(Mount *m) {
if (p mount_is_bind(p))
mkdir_p_label(p-what, m-directory_mode);
+r = fail_if_symlink(m-meta.id, m-where);
+if (r 0)
+goto fail;
+
if (m-from_fragment)
r = exec_command_set(
m-control_command,
diff --git a/src/core/mount.h b/src/core/mount.h
index 2dcb663..5fc1fe1 100644
--- a/src/core/mount.h
+++ b/src/core/mount.h
@@ -128,3 +128,5 @@ const char* mount_result_to_string(MountResult i)
_const_;
MountResult mount_result_from_string(const char *s) _pure_;
void warn_if_dir_nonempty(const char *unit, const char* where);
+
+int fail_if_symlink(const char *unit, const char* where);
\ No newline at end of file
diff --git a/src/shared/util.c b/src/shared/util.c
index 3d16cd1..0db4bd9 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -6918,3 +6918,15 @@ int take_password_lock(const char *root) {
return fd;
}
+
+int is_symlink(const char *path) {
+struct stat info;
+
+if (lstat(path, info) 0)
+return -errno;
+
+if (S_ISLNK(info.st_mode))
+return 1;
+
+return 0;
+}
\ No newline at end of file
diff --git a/src/shared/util.h b/src/shared/util.h
index 101d2df..bd8bbb2 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -966,3 +966,5 @@ char *tempfn_random(const char *p);
bool is_localhost(const char *hostname);
int take_password_lock(const char *root);
+
+int is_symlink(const char *path);
\ No newline at end of file
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 05/10] rules: skip 99-systemd.rules when not running systemd as init
On Wed, 16.07.14 20:45, Jon Severinsson (j...@severinsson.net) wrote: onsdagen den 16 juli 2014 16:49:55 skrev Lennart Poettering: On Wed, 16.07.14 12:09, Jon Severinsson (j...@severinsson.net) wrote: From: Tollef Fog Heen tfh...@err.no If you really want to support systems without systemd installed, then I'd recommend placing this rules file in the systemd pacakge, so that it is gone if you uninstall systemd. That said, nothing of what the file does is in any way something that could break things on non-systemd systems, hence the whole excercise sounds pointless... The file still contains one RUN+=@rootlibexecdir@/systemd-sysctl ..., which I don't think is desirable when systemd is installed but not running as PID 1 (which we also have to support). The tool actually will work fine if you run it outside of systemd. There's no dependency on systemd being PID 1 in that tool. But I do see your point. 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] Remove warning: var may be used uninitialized
On Fri, 15.08.14 01:11, Timofey Titovets (nefelim...@gmail.com) wrote: Good time of day, when i compile systemd i get ton of warning like: var may be used uninitialized in function... May be i can spend some time and create patches with fixes of that warnings? As example declare it by default to 0 or something like that. Or this is not a bug, just feature? %) Did you compile this with -flto? (which is the default, unless you build with autogen.sh c or suchlike) With lto enabled gcc warnings about that are not useful, and should be ignored mostly, right now. Turn off lto, and they become more useful, but we should be pretty clean with that already. 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 v3] Refuse mount on symlink
On Fri, 15.08.14 01:43, Timofey Titovets (nefelim...@gmail.com) wrote:
+int fail_if_symlink(const char *unit, const char* where) {
+assert(where);
+
+if (is_symlink(where) 0) {
+log_struct_unit(LOG_WARNING,
+unit,
+MESSAGE=%s: Mount on symlink %s
not allowed.,
+unit, where,
+WHERE=%s, where,
+MESSAGE_ID(SD_MESSAGE_OVERMOUNTING),
+NULL);
+
+return -ELOOP;
+}
+return 0;
+}
Looks good, but the patch is line broken, I can't apply it like
that... Maybe attach the patch?
diff --git a/src/core/mount.h b/src/core/mount.h
index 2dcb663..5fc1fe1 100644
--- a/src/core/mount.h
+++ b/src/core/mount.h
@@ -128,3 +128,5 @@ const char* mount_result_to_string(MountResult
i) _const_;
MountResult mount_result_from_string(const char *s) _pure_;
void warn_if_dir_nonempty(const char *unit, const char* where);
+
+int fail_if_symlink(const char *unit, const char* where);
No reason to export this, or am I missing something? Just make the
function static, and don't include it in the header file, unless some
other .c file is actually using it.
Otherwise looks good.
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] Remove warning: var may be used uninitialized
I just use: ./autogen.sh ./configure make But did not matter, thanks for explanation, i think what this thread can be closed. 2014-08-15 1:57 GMT+03:00 Lennart Poettering lenn...@poettering.net: On Fri, 15.08.14 01:11, Timofey Titovets (nefelim...@gmail.com) wrote: Good time of day, when i compile systemd i get ton of warning like: var may be used uninitialized in function... May be i can spend some time and create patches with fixes of that warnings? As example declare it by default to 0 or something like that. Or this is not a bug, just feature? %) Did you compile this with -flto? (which is the default, unless you build with autogen.sh c or suchlike) With lto enabled gcc warnings about that are not useful, and should be ignored mostly, right now. Turn off lto, and they become more useful, but we should be pretty clean with that already. Lennart -- Lennart Poettering, Red Hat -- Have a nice day, Timofey. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] Refuse mount on symlink
2014-08-15 2:00 GMT+03:00 Lennart Poettering lenn...@poettering.net:
On Fri, 15.08.14 01:43, Timofey Titovets (nefelim...@gmail.com) wrote:
+int fail_if_symlink(const char *unit, const char* where) {
+assert(where);
+
+if (is_symlink(where) 0) {
+log_struct_unit(LOG_WARNING,
+unit,
+MESSAGE=%s: Mount on symlink %s
not allowed.,
+unit, where,
+WHERE=%s, where,
+MESSAGE_ID(SD_MESSAGE_OVERMOUNTING),
+NULL);
+
+return -ELOOP;
+}
+return 0;
+}
Looks good, but the patch is line broken, I can't apply it like
that... Maybe attach the patch?
diff --git a/src/core/mount.h b/src/core/mount.h
index 2dcb663..5fc1fe1 100644
--- a/src/core/mount.h
+++ b/src/core/mount.h
@@ -128,3 +128,5 @@ const char* mount_result_to_string(MountResult
i) _const_;
MountResult mount_result_from_string(const char *s) _pure_;
void warn_if_dir_nonempty(const char *unit, const char* where);
+
+int fail_if_symlink(const char *unit, const char* where);
No reason to export this, or am I missing something? Just make the
function static, and don't include it in the header file, unless some
other .c file is actually using it.
Fixed in patch
Otherwise looks good.
Lennart
--
Lennart Poettering, Red Hat
--
Have a nice day,
Timofey.
From 5f4325df1cd8f3c6ee3790e6c9c23b6dd0aaffec Mon Sep 17 00:00:00 2001
From: Timofey nefelim...@gmail.com
Date: Fri, 15 Aug 2014 02:05:47 +0300
Subject: [PATCH] Refuse mount on symlink
Signed-off-by: Timofey nefelim...@gmail.com
---
TODO | 2 --
src/core/mount.c | 21 +
src/shared/util.c | 12
src/shared/util.h | 2 ++
4 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/TODO b/TODO
index d58da71..c8e9f27 100644
--- a/TODO
+++ b/TODO
@@ -93,8 +93,6 @@ Features:
* Add a new verb systemctl top
-* refuse mounting on symlinks
-
* logind: allow users to kill or lock their own sessions
* add new gpt type for btrfs volumes
diff --git a/src/core/mount.c b/src/core/mount.c
index 39a9aaf..ec90b0a 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -827,6 +827,23 @@ void warn_if_dir_nonempty(const char *unit, const char* where) {
NULL);
}
+static int fail_if_symlink(const char *unit, const char* where) {
+assert(where);
+
+if (is_symlink(where) 0) {
+log_struct_unit(LOG_WARNING,
+unit,
+MESSAGE=%s: Mount on symlink %s not allowed.,
+unit, where,
+WHERE=%s, where,
+MESSAGE_ID(SD_MESSAGE_OVERMOUNTING),
+NULL);
+
+return -ELOOP;
+}
+return 0;
+}
+
static void mount_enter_unmounting(Mount *m) {
int r;
@@ -877,6 +894,10 @@ static void mount_enter_mounting(Mount *m) {
if (p mount_is_bind(p))
mkdir_p_label(p-what, m-directory_mode);
+r = fail_if_symlink(m-meta.id, m-where);
+if (r 0)
+goto fail;
+
if (m-from_fragment)
r = exec_command_set(
m-control_command,
diff --git a/src/shared/util.c b/src/shared/util.c
index 3d16cd1..0db4bd9 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -6918,3 +6918,15 @@ int take_password_lock(const char *root) {
return fd;
}
+
+int is_symlink(const char *path) {
+struct stat info;
+
+if (lstat(path, info) 0)
+return -errno;
+
+if (S_ISLNK(info.st_mode))
+return 1;
+
+return 0;
+}
\ No newline at end of file
diff --git a/src/shared/util.h b/src/shared/util.h
index 101d2df..bd8bbb2 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -966,3 +966,5 @@ char *tempfn_random(const char *p);
bool is_localhost(const char *hostname);
int take_password_lock(const char *root);
+
+int is_symlink(const char *path);
\ No newline at end of file
--
2.0.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH] socket: show full instance name in services' description
On Tue, 15.07.14 16:36, Łukasz Stelmach (l.stelm...@samsung.com) wrote: Change the way socket activated services are instantiated so that the full instnace name with addresses of both parties and not only the counter make it into units' descriptions visible in the journal. Hmm, what I really don't like about this scheme is the selinux handling, i.e. previously we just pre-allocated a stream when we had to label the socket, and then used it much later, when the first actual connection was coming in. Allocating and then freeing it immediately during labelling sounds not so attractive to me. Maybe we can fix this problem differently. I mean we use unit_choose_id() to make sure the primary name for the unit is the pretty one. Maybe we can find a way how to make sure that the log messages you are interested in are only generated after that? So, hmm, which log messages are you interested in particular to carry the final name? 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 v3] Refuse mount on symlink
On Fri, 15.08.14 02:17, Timofey Titovets (nefelim...@gmail.com) wrote: Applied! Thanks! Signed-off-by: Timofey nefelim...@gmail.com We don't do Signed-off-by on systemd, so I drop this when I pushed it. Thanks! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
