[systemd-devel] [PATCH 2/2] socket: Introduce SCTP support
This patch adds SCTP protcol support for socket activation.
SCTP socket can be configured via the conf parameter
'ListenStreamControlTrans' which is kind of too long.
---
man/systemd.socket.xml| 3 ++-
src/core/load-fragment-gperf.gperf.m4 | 1 +
src/core/load-fragment.c | 5 -
src/core/socket.c | 8 ++--
4 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
index ddd74a6..934a45e 100644
--- a/man/systemd.socket.xml
+++ b/man/systemd.socket.xml
@@ -168,10 +168,11 @@
termvarnameListenStream=/varname/term
termvarnameListenDatagram=/varname/term
termvarnameListenSequentialPacket=/varname/term
+
termvarnameListenStreamControlTrans=/varname/term
listitemparaSpecifies an address
to listen on for a stream
(constantSOCK_STREAM/constant), datagram
(constantSOCK_DGRAM/constant),
-or sequential packet
+SCTP (constantIPPROTO_SCTP/constant),or
sequential packet
(constantSOCK_SEQPACKET/constant) socket,
respectively. The address
can be written in various formats:/para
diff --git a/src/core/load-fragment-gperf.gperf.m4
b/src/core/load-fragment-gperf.gperf.m4
index f4acdda..a295923 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -211,6 +211,7 @@ KILL_CONTEXT_CONFIG_ITEMS(Service)m4_dnl
m4_dnl
Socket.ListenStream, config_parse_socket_listen,
SOCKET_SOCKET, 0
Socket.ListenDatagram, config_parse_socket_listen,
SOCKET_SOCKET, 0
+Socket.ListenStreamControlTrans, config_parse_socket_listen,
SOCKET_SOCKET, 0
Socket.ListenSequentialPacket, config_parse_socket_listen,
SOCKET_SOCKET, 0
Socket.ListenFIFO, config_parse_socket_listen,
SOCKET_FIFO, 0
Socket.ListenNetlink,config_parse_socket_listen,
SOCKET_SOCKET, 0
diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c
index 81f1379..0ae116b 100644
--- a/src/core/load-fragment.c
+++ b/src/core/load-fragment.c
@@ -358,7 +358,10 @@ int config_parse_socket_listen(const char *unit,
p-address.type = SOCK_STREAM;
else if (streq(lvalue, ListenDatagram))
p-address.type = SOCK_DGRAM;
-else {
+else if (streq(lvalue, ListenStreamControlTrans)) {
+ p-address.type = SOCK_STREAM;
+ p-address.protocol = IPPROTO_SCTP;
+} else {
assert(streq(lvalue, ListenSequentialPacket));
p-address.type = SOCK_SEQPACKET;
}
diff --git a/src/core/socket.c b/src/core/socket.c
index 7070bd7..82d8eaf 100644
--- a/src/core/socket.c
+++ b/src/core/socket.c
@@ -445,11 +445,14 @@ static int socket_load(Unit *u) {
return socket_verify(s);
}
-_const_ static const char* listen_lookup(int family, int type) {
+_const_ static const char* listen_lookup(int family, int type, int protocol) {
if (family == AF_NETLINK)
return ListenNetlink;
+if (protocol == IPPROTO_SCTP)
+return ListenStreamControlTrans;
+
if (type == SOCK_STREAM)
return ListenStream;
else if (type == SOCK_DGRAM)
@@ -607,7 +610,8 @@ static void socket_dump(Unit *u, FILE *f, const char
*prefix) {
else
t = k;
-fprintf(f, %s%s: %s\n, prefix,
listen_lookup(socket_address_family(p-address), p-address.type), t);
+fprintf(f, %s%s: %s\n, prefix,
listen_lookup(socket_address_family(p-address),
+
p-address.type, p-address.protocol), t);
free(k);
} else if (p-type == SOCKET_SPECIAL)
fprintf(f, %sListenSpecial: %s\n, prefix, p-path);
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] socket: add support for tcp nagle
This patch adds support for TCP TCP_NODELAY socket
option. This can be configured via NoDelay conf
parameter.TCP Nagle's algorithm works by combining a number of
small outgoing messages, and sending them all at once.
This controls the TCP_NODELAY socket option
---
man/systemd.socket.xml| 11 +++
src/core/load-fragment-gperf.gperf.m4 | 1 +
src/core/socket.c | 8
src/core/socket.h | 1 +
4 files changed, 21 insertions(+)
diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
index 09a7311..ddd74a6 100644
--- a/man/systemd.socket.xml
+++ b/man/systemd.socket.xml
@@ -488,6 +488,17 @@
/varlistentry
varlistentry
+termvarnameNoDelay=/varname/term
+listitemparaTakes a boolean
+argument. TCP Nagle's algorithm works by
combining a number of
+small outgoing messages, and sending them all
at once.
+This controls the TCP_NODELAY socket option
(see
+
citerefentryrefentrytitletcp/refentrytitlemanvolnum7/manvolnum/citerefentry
+Defaults to
+optionfalse/option./para/listitem
+/varlistentry
+
+varlistentry
termvarnamePriority=/varname/term
listitemparaTakes an integer
argument controlling the priority for
diff --git a/src/core/load-fragment-gperf.gperf.m4
b/src/core/load-fragment-gperf.gperf.m4
index d70f9ee..f4acdda 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -231,6 +231,7 @@ Socket.DirectoryMode,config_parse_mode,
0,
Socket.Accept, config_parse_bool, 0,
offsetof(Socket, accept)
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.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 646887d..7070bd7 100644
--- a/src/core/socket.c
+++ b/src/core/socket.c
@@ -480,6 +480,7 @@ static void socket_dump(Unit *u, FILE *f, const char
*prefix) {
%sSocketMode: %04o\n
%sDirectoryMode: %04o\n
%sKeepAlive: %s\n
+%sNodelay: %s\n
%sFreeBind: %s\n
%sTransparent: %s\n
%sBroadcast: %s\n
@@ -494,6 +495,7 @@ static void socket_dump(Unit *u, FILE *f, const char
*prefix) {
prefix, s-socket_mode,
prefix, s-directory_mode,
prefix, yes_no(s-keep_alive),
+prefix, yes_no(s-no_delay),
prefix, yes_no(s-free_bind),
prefix, yes_no(s-transparent),
prefix, yes_no(s-broadcast),
@@ -790,6 +792,12 @@ static void socket_apply_socket_options(Socket *s, int fd)
{
log_warning_unit(UNIT(s)-id, SO_KEEPALIVE failed:
%m);
}
+if (s-no_delay) {
+int b = s-no_delay;
+if (setsockopt(fd, SOL_TCP, TCP_NODELAY, b, sizeof(b)) 0)
+log_warning_unit(UNIT(s)-id, TCP_NODELAY failed:
%m);
+}
+
if (s-broadcast) {
int one = 1;
if (setsockopt(fd, SOL_SOCKET, SO_BROADCAST, one,
sizeof(one)) 0)
diff --git a/src/core/socket.h b/src/core/socket.h
index 814a3bf..98396e7 100644
--- a/src/core/socket.h
+++ b/src/core/socket.h
@@ -134,6 +134,7 @@ struct Socket {
/* Socket options */
bool keep_alive;
+bool no_delay;
bool free_bind;
bool transparent;
bool broadcast;
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journald: fix syslog facility for messages coming from kmsg
On Sun, Jul 27, 2014 at 07:57:47PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
On Sun, Jul 27, 2014 at 01:11:07PM +0200, Michal Sekletar wrote:
On Sat, Jul 26, 2014 at 09:11:47PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
Hm, what was wrong with the facility before?
I think that we should always add SYSLOG_FACILITY field. Now, if (priority
LOG_FACMASK) == LOG_KERN we don't do that. We set SYSLOG_IDENTIFIER to
kernel
tough. But missing SYSLOG_FACILITY field confuses some tools, most notably
rsyslog, thus rsyslog filters like kern.* /var/log/kernel.log doesn't
work and
rsyslog don't output kernel log messages to /var/log/kernel.log.
Agreed, even though for slightly different reason :)
syslog(2) describes LOG_KERN as the facility for kernel messages, so we should
set it so. So I'm +1 for pushing this change, but *please* add the explanation
to the commit message. It makes it much easier for downstreams, especially for
people who see the commit in isolation on some stable branch a few months down
the road.
Pushed, with explanation. Thanks!
Zbyszek
On Fri, Jul 25, 2014 at 03:04:44PM +0200, Michal Sekletar wrote:
---
src/journal/journald-kmsg.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/journal/journald-kmsg.c b/src/journal/journald-kmsg.c
index 12992e7..8d24344 100644
--- a/src/journal/journald-kmsg.c
+++ b/src/journal/journald-kmsg.c
@@ -274,6 +274,9 @@ static void dev_kmsg_record(Server *s, char *p,
size_t l) {
if (asprintf(syslog_priority, PRIORITY=%i, priority
LOG_PRIMASK) = 0)
IOVEC_SET_STRING(iovec[n++], syslog_priority);
+if (asprintf(syslog_facility, SYSLOG_FACILITY=%i, priority
LOG_FACMASK) = 0)
+IOVEC_SET_STRING(iovec[n++], syslog_facility);
+
if ((priority LOG_FACMASK) == LOG_KERN)
IOVEC_SET_STRING(iovec[n++],
SYSLOG_IDENTIFIER=kernel);
else {
@@ -295,9 +298,6 @@ static void dev_kmsg_record(Server *s, char *p,
size_t l) {
if (syslog_pid)
IOVEC_SET_STRING(iovec[n++],
syslog_pid);
}
-
-if (asprintf(syslog_facility, SYSLOG_FACILITY=%i,
LOG_FAC(priority)) = 0)
-IOVEC_SET_STRING(iovec[n++], syslog_facility);
}
message = cunescape_length_with_prefix(p, pl, MESSAGE=);
--
2.0.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Implementing resume from hibernation as a systemd unit file
Hello all, I'm trying to implement resuming from hibernation with systemd-based initramfs, i. e. in terms of systemd unit files. That is, there should be a unit which waits for the resume device and writes its major:minor into /sys/power/resume. I've chosen to write a templated resume@path.service and a generator which parses 'resume=' kernel parameter and enables a corresponding instance of the resume@.service unit. The resume@.service itself shall be ordered so that it is activated when there are no filesystems mounted read-write, except tmpfs instances. It will be good if it works both from initramfs and from real rootfs (if it is mounted RO). So, here are some questions: - is it the way to go (overall)? - is it OK to use generators for outlined purpose? - how to order resume@.service and where to symlink it? I'm using Arch, if that matters -- but, IIUC, Arch strives to do everything in the upstream's way, so there should be no distro-specific details. 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
Re: [systemd-devel] [systemd-commits] factory/etc
Zbigniew Jędrzejewski-Szmek wrote on 27/07/14 18:09: On Sun, Jul 27, 2014 at 05:54:15AM -0700, Kay Sievers wrote: factory/etc/nsswitch.conf |6 ++ 1 file changed, 6 insertions(+) New commits: commit ccc6fa0d6b8e3ce5e7508ee8a141ee26f380b4a3 Author: Kay Sievers k...@vrfy.org Date: Sun Jul 27 14:53:21 2014 +0200 factory: nss - add generic config diff --git a/factory/etc/nsswitch.conf b/factory/etc/nsswitch.conf new file mode 100644 index 000..5f2984e --- /dev/null +++ b/factory/etc/nsswitch.conf @@ -0,0 +1,6 @@ +# This file is part of systemd. + +passwd: files +shadow: files +group: files +hosts: files mymachines resolve myhostname Hi Kay, I know that traditionally myhostname is added at the end. Oh, crap. I just realised that all my setups have myhostname before dns. Oops! But local configuration should be more trusted than DNS (*). It is also more trusted then guest machines. So imho the right order is files myhostname mymachines resolve That would match my natural assumption (i.e. I saw myhostname as a replacement for putting static, but expected, definitions in /etc/hosts) so glad I'm not venturing too far off the reservation :p (*) One specific example that I've encountered is when local DNS is tied with DHCP server, and registers names automatically. Then a misconfiguration of the DNS server is likely, and it wreaks havoc. Common examples starting to resolve 'localhost' when a computer without a hostname configured (and thus using localhost.localdomain as the fqdn) acquired an address, or resolving the name of a computer to the address of previous lease. Also, since DNS is not (usually) secure against attack over the local network, by giving DNS higher priority, we open up an attack vector where 'localhost' can be spoofed to refer to a different machine, even with a correctly functioning server. There's no valid reason to make the resolution of localhost* names configurable through DNS, so we may just as well do it locally for speed and robustness. The same logic is true for the other names returned by myhostname. Seems sensible to me but will be interested to hear if there is a counter argument. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Correct references to ProtectSystem and ProtectHome in documentation
--- NEWS | 2 +- man/systemd.exec.xml | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/NEWS b/NEWS index 71017fa..d6cbc5a 100644 --- a/NEWS +++ b/NEWS @@ -299,7 +299,7 @@ CHANGES WITH 214: moved to /run/systemd/resolve/. If you have a symlink from /etc/resolv.conf, it might be necessary to correct it. -* Two new service settings, ProtectedHome= and ProtectedSystem=, +* Two new service settings, ProtectHome= and ProtectSystem=, have been added. When enabled, they will make the user data (such as /home) inaccessible or read-only and the system (such as /usr) read-only, for specific services. This allows diff --git a/man/systemd.exec.xml b/man/systemd.exec.xml index 2f75915..a1eb112 100644 --- a/man/systemd.exec.xml +++ b/man/systemd.exec.xml @@ -1027,8 +1027,8 @@ namespace related options (varnamePrivateTmp=/varname, varnamePrivateDevices=/varname, -varnameReadOnlySystem=/varname, -varnameProtectedHome=/varname, +varnameProtectSystem=/varname, +varnameProtectHome=/varname, varnameReadOnlyDirectories=/varname, varnameInaccessibleDirectories=/varname and -- 2.0.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
