[systemd-devel] /dev/log tends to block on socket based activation ...
Good morning everyone, I'm playing around a bit with systemd's socket based activation of systemd-journald. My intention is to shift back in time the actual startup of systemd-journald.service to save resources (CPU) for early applications during startup. The respective socket is activated as usual to not lose any early (sys)logs. The actual startup of the service is delayed by adding some dependencies to targets (basic.target for instance). In principal, the idea is working as expected but sometimes the logging via syslog(..) blocks applications until the daemon is actually started. Depending on how the startup of such application is integrated into the startup configuration, this might lead to deadlock situations. Has anyone here any idea how one can prevent the blocking situation. Some observations: - The blocking situation is not happening on each syslog call, sometimes this happens after one call, sometimes after a few calls. I wasn't able by now isolating the concrete case that leads to a blocking socket - I doubt that the underlying socket buffer is full - The call is blocked by the kernel syscall send() that is invoked by the syslog() call Thx in advance for any hints ... Best regards Marko Hoyer Advanced Driver Information Technology GmbH Software Group II (ADITG/SW2) Robert-Bosch-Str. 200 31139 Hildesheim Germany Tel. +49 5121 49 6948 Fax +49 5121 49 6999 mho...@de.adit-jv.com ADIT is a joint venture company of Robert Bosch GmbH/Robert Bosch Car Multimedia GmbH and DENSO Corporation Sitz: Hildesheim, Registergericht: Amtsgericht Hildesheim HRB 3438 Geschäftsführung: Wilhelm Grabow, Katsuyoshi Maeda ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Fix off-by-one error in Missed X kernel messages warning
On receiving a message, kernel_seqnum is set to serial + 1. So
subtracting 1 will cause messages like Missed 0 kernel messages,
which should be Missed 1 kernel messages.
---
src/journal/journald-kmsg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/journal/journald-kmsg.c b/src/journal/journald-kmsg.c
index 9935986..fb8ea08 100644
--- a/src/journal/journald-kmsg.c
+++ b/src/journal/journald-kmsg.c
@@ -152,7 +152,7 @@ static void dev_kmsg_record(Server *s, char *p, size_t l) {
/* Did we lose any? */
if (serial *s-kernel_seqnum)
server_driver_message(s, SD_MESSAGE_JOURNAL_MISSED,
Missed %PRIu64 kernel messages,
- serial - *s-kernel_seqnum - 1);
+ serial - *s-kernel_seqnum);
/* Make sure we never read this one again. Note that
* we always store the next message serial we expect
--
1.9.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Work on adding polkit support to systemd1
I've done initial work on adding polkit support to systemd1 DBus methods. You can see it here: https://github.com/stefwalter/systemd/commits/polkit-systemd1 Basic rules: * Read access for everyone * Methods that modifies running unit state is controlled by a polkit action: org.freedesktop.systemd1.manage-units * Methods that modifies unit state files is controlled by a polkit action: org.freedesktop.systemd1.manage-unit-files * Many methods are only callable by root callers, like: Poweroff() Kexec() etc... * Job.Cancel() and Manager.CancelJob() are callable by the caller(s) that started the job. * Setting properties is only possible by root callers. The way that each callback in sd-bus has to handle verification seems a bit risky to me. So I've only opened up the specific interfaces I touched in the DBus policy file. Eventually the DBus policy file would go away, but hopefully sd-bus will have a less risky way of verifying callers at that point. I need to work on testing this. Will send a patch set when I'm done. I'd be happy to add documentation here when we're done: http://www.freedesktop.org/wiki/Software/systemd/dbus/ Cheers, Stef ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Work on adding polkit support to systemd1
Stef Walter wrote on 06/08/14 12:23: I've done initial work on adding polkit support to systemd1 DBus methods. Hmmm, I thought this was deliberately not included as it meant a circular dep on polkit when talking to the system that's used to start up polkitd itself... what happens if you try to talk to systemd1 interface during early boot before polkitd has started (and before a dep that's needed by it) has started? I thought the main reason for logind to essentially proxy the Power/Reboot related stuff was such that polkit support could be added there outside of systemd1 itself and thus not have any circular dep problems. Perhaps things have moved on from the old days, or maybe I picked this up wrong in the first place and this is not a concern. 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
Re: [systemd-devel] Work on adding polkit support to systemd1
On 06.08.2014 14:23, Colin Guthrie wrote: Stef Walter wrote on 06/08/14 12:23: I've done initial work on adding polkit support to systemd1 DBus methods. Hmmm, I thought this was deliberately not included as it meant a circular dep on polkit when talking to the system that's used to start up polkitd itself... We were discussing this in Strasbourg. Lennart can probably summarize better than I can. But my understanding is that these circular dependency issues have been resolved. what happens if you try to talk to systemd1 interface during early boot before polkitd has started (and before a dep that's needed by it) has started? I think it falls back on just allowing uid zero. But would be good to double check. I thought the main reason for logind to essentially proxy the Power/Reboot related stuff was such that polkit support could be added there outside of systemd1 itself and thus not have any circular dep problems. FWIW, we don't involve polkit on on Power/Reboot and similar of.systemd1.Manager method calls. General purpose callers should continue to go through logind and/or the shutdown command. Stef ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] core: mount only 4 partition in mount_setup_early()
systemd doesn't mount smackfs if systemd was compiled without Smack
support. However, the number of mount point entry in mount_setup_early()
(i.e. N_EARLY_MOUNT) is 5 since smackfs is included. N_EARLY_MOUNT
should be 4 because currently smackfs is optional.
Signed-off-by: Sangjung Woo sangjung@samsung.com
---
src/core/mount-setup.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
index 206f89a..f15647b 100644
--- a/src/core/mount-setup.c
+++ b/src/core/mount-setup.c
@@ -64,7 +64,7 @@ typedef struct MountPoint {
/* The first three entries we might need before SELinux is up. The
* fourth (securityfs) is needed by IMA to load a custom policy. The
* other ones we can delay until SELinux and IMA are loaded. */
-#define N_EARLY_MOUNT 5
+#define N_EARLY_MOUNT 4
static const MountPoint mount_table[] = {
{ sysfs, /sys, sysfs, NULL,
MS_NOSUID|MS_NOEXEC|MS_NODEV,
--
1.7.9.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Work on adding polkit support to systemd1
Stef Walter wrote on 06/08/14 13:44: On 06.08.2014 14:23, Colin Guthrie wrote: Stef Walter wrote on 06/08/14 12:23: I've done initial work on adding polkit support to systemd1 DBus methods. Hmmm, I thought this was deliberately not included as it meant a circular dep on polkit when talking to the system that's used to start up polkitd itself... We were discussing this in Strasbourg. Lennart can probably summarize better than I can. But my understanding is that these circular dependency issues have been resolved. Ahh good to hear! I'll no doubt catch up at some point on the latest cool stuff! :) 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] sd-dhcp6-client: support custom DUIDs
The caller may have an existing DUID that it wants to use, and may
want to use some other DUID generation scheme than systemd's
default DUID-EN.
---
src/libsystemd-network/sd-dhcp6-client.c | 52 +++---
src/libsystemd-network/test-dhcp6-client.c | 4 +--
src/network/networkd-link.c| 2 +-
src/systemd/sd-dhcp6-client.h | 2 +-
4 files changed, 38 insertions(+), 22 deletions(-)
diff --git a/src/libsystemd-network/sd-dhcp6-client.c
b/src/libsystemd-network/sd-dhcp6-client.c
index c6c82eb..8123dc8 100644
--- a/src/libsystemd-network/sd-dhcp6-client.c
+++ b/src/libsystemd-network/sd-dhcp6-client.c
@@ -35,14 +35,16 @@
#include dhcp6-protocol.h
#include dhcp6-internal.h
#include dhcp6-lease-internal.h
#define SYSTEMD_PEN 43793
#define HASH_KEY SD_ID128_MAKE(80,11,8c,c2,fe,4a,03,ee,3e,d6,0c,6f,36,39,14,09)
+#define MAX_DUID_LEN 32
+
struct sd_dhcp6_client {
RefCount n_ref;
enum DHCP6State state;
sd_event *event;
int event_priority;
int index;
@@ -57,20 +59,16 @@ struct sd_dhcp6_client {
sd_event_source *receive_message;
usec_t retransmit_time;
uint8_t retransmit_count;
sd_event_source *timeout_resend;
sd_event_source *timeout_resend_expire;
sd_dhcp6_client_cb_t cb;
void *userdata;
-
-struct duid_en {
-uint16_t type; /* DHCP6_DUID_EN */
-uint32_t pen;
-uint8_t id[8];
-} _packed_ duid;
+uint8_t duid[MAX_DUID_LEN];
+size_t duid_len;
};
static const uint16_t default_req_opts[] = {
DHCP6_OPTION_DNS_SERVERS,
DHCP6_OPTION_DOMAIN_LIST,
DHCP6_OPTION_NTP_SERVER,
};
@@ -300,15 +298,15 @@ static int client_send_message(sd_dhcp6_client *client) {
r = dhcp6_option_append(opt, optlen, DHCP6_OPTION_ORO,
client-req_opts_len * sizeof(be16_t),
client-req_opts);
if (r 0)
return r;
r = dhcp6_option_append(opt, optlen, DHCP6_OPTION_CLIENTID,
-sizeof(client-duid), client-duid);
+client-duid_len, client-duid);
if (r 0)
return r;
r = dhcp6_network_send_udp_socket(client-fd, all_servers, message,
len - optlen);
if (r 0)
return r;
@@ -585,15 +583,15 @@ static int client_parse_message(sd_dhcp6_client *client,
case DHCP6_OPTION_CLIENTID:
if (clientid) {
log_dhcp6_client(client, %s contains multiple
clientids,
dhcp6_message_type_to_string(message-type));
return -EINVAL;
}
-if (optlen != sizeof(client-duid) ||
+if (optlen != client-duid_len ||
memcmp(client-duid, optval, optlen) != 0) {
log_dhcp6_client(client, %s DUID does not
match,
dhcp6_message_type_to_string(message-type));
return -EINVAL;
}
clientid = true;
@@ -1059,47 +1057,65 @@ sd_dhcp6_client *sd_dhcp6_client_unref(sd_dhcp6_client
*client) {
return NULL;
}
return client;
}
-int sd_dhcp6_client_new(sd_dhcp6_client **ret)
+struct duid_en {
+uint16_t type; /* DHCP6_DUID_EN */
+uint32_t pen;
+uint8_t id[8];
+} _packed_;
+
+int sd_dhcp6_client_new(sd_dhcp6_client **ret, uint8_t *duid, size_t duid_len)
{
_cleanup_dhcp6_client_unref_ sd_dhcp6_client *client = NULL;
sd_id128_t machine_id;
int r;
size_t t;
assert_return(ret, -EINVAL);
+if (duid)
+assert_return(duid_len 0 duid_len MAX_DUID_LEN,
-EINVAL);
+else
+assert_return(duid_len == 0, -EINVAL);
client = new0(sd_dhcp6_client, 1);
if (!client)
return -ENOMEM;
client-n_ref = REFCNT_INIT;
client-ia_na.type = DHCP6_OPTION_IA_NA;
client-index = -1;
client-fd = -1;
/* initialize DUID */
-client-duid.type = htobe16(DHCP6_DUID_EN);
-client-duid.pen = htobe32(SYSTEMD_PEN);
+if (duid) {
+memcpy(client-duid, duid, duid_len);
+client-duid_len = duid_len;
+} else {
+struct duid_en *en = (struct duid_en *) client-duid;
-r = sd_id128_get_machine(machine_id);
-if (r 0)
-return r;
+en-type = htobe16(DHCP6_DUID_EN);
+en-pen = htobe32(SYSTEMD_PEN);
-/* a bit
[systemd-devel] [RFC PATCH] sd-dhcp-client: support non-Ethernet hardware addresses
Like Infiniband. See RFC 4390 section 2.1 for details on DHCP
and Infiniband; chaddr is zeroed, hlen is set to 0, and htype
is set to ARPHRD_INFINIBAND because IB hardware addresses
are 20 bytes in length.
---
NOTE: because of how dhcp_network_bind_raw_socket() does its packet
filter, it's not easy to change some of the checks it uses without
having callers pass the actual values into the function, which seems
redundant. Thus I opted for the current approach, but that does
add a warning about mixed declarations and code. Can anyone think
of a better way to do this?
An possible improvement to sd_dhcp_client_set_mac() would be
keying the MAC address length off 'arp_type' instead of
specifying it explicitly.
src/libsystemd-network/dhcp-internal.h| 10 +++--
src/libsystemd-network/dhcp-network.c | 39 +++
src/libsystemd-network/dhcp-packet.c | 8 ++--
src/libsystemd-network/sd-dhcp-client.c | 63 +++
src/libsystemd-network/sd-dhcp-server.c | 6 +--
src/libsystemd-network/test-dhcp-client.c | 14 +--
src/libsystemd-network/test-dhcp-option.c | 2 +-
src/network/networkd-link.c | 9 -
src/systemd/sd-dhcp-client.h | 4 +-
9 files changed, 116 insertions(+), 39 deletions(-)
diff --git a/src/libsystemd-network/dhcp-internal.h
b/src/libsystemd-network/dhcp-internal.h
index 1069c8a..d358a49 100644
--- a/src/libsystemd-network/dhcp-internal.h
+++ b/src/libsystemd-network/dhcp-internal.h
@@ -20,22 +20,25 @@
You should have received a copy of the GNU Lesser General Public License
along with systemd; If not, see http://www.gnu.org/licenses/.
***/
#include stdint.h
#include linux/if_packet.h
+#include net/if_arp.h
#include net/ethernet.h
#include socket-util.h
#include sd-dhcp-client.h
#include dhcp-protocol.h
-int dhcp_network_bind_raw_socket(int index, union sockaddr_union *link,
uint32_t xid, struct ether_addr mac_addr);
+int dhcp_network_bind_raw_socket(int index, union sockaddr_union *link,
+ uint32_t xid, const uint8_t *mac_addr,
+ size_t mac_addr_len, uint16_t arp_type);
int dhcp_network_bind_udp_socket(be32_t address, uint16_t port);
int dhcp_network_send_raw_socket(int s, const union sockaddr_union *link,
const void *packet, size_t len);
int dhcp_network_send_udp_socket(int s, be32_t address, uint16_t port,
const void *packet, size_t len);
int dhcp_option_append(DHCPMessage *message, size_t size, size_t *offset,
uint8_t overload,
@@ -43,16 +46,17 @@ int dhcp_option_append(DHCPMessage *message, size_t size,
size_t *offset, uint8_
typedef int (*dhcp_option_cb_t)(uint8_t code, uint8_t len,
const uint8_t *option, void *user_data);
int dhcp_option_parse(DHCPMessage *message, size_t len,
dhcp_option_cb_t cb, void *user_data);
-int dhcp_message_init(DHCPMessage *message, uint8_t op, uint32_t xid, uint8_t
type,
- size_t optlen, size_t *optoffset);
+int dhcp_message_init(DHCPMessage *message, uint8_t op, uint32_t xid,
+ uint8_t type, uint16_t arp_type, size_t optlen,
+ size_t *optoffset);
uint16_t dhcp_packet_checksum(uint8_t *buf, size_t len);
void dhcp_packet_append_ip_headers(DHCPPacket *packet, be32_t source_addr,
uint16_t source, be32_t destination_addr,
uint16_t destination, uint16_t len);
diff --git a/src/libsystemd-network/dhcp-network.c
b/src/libsystemd-network/dhcp-network.c
index 1ced5cf..4d82bcf 100644
--- a/src/libsystemd-network/dhcp-network.c
+++ b/src/libsystemd-network/dhcp-network.c
@@ -18,26 +18,45 @@
***/
#include errno.h
#include sys/types.h
#include sys/socket.h
#include string.h
#include linux/if_packet.h
+#include linux/if_infiniband.h
#include net/ethernet.h
#include net/if_arp.h
#include stdio.h
#include unistd.h
#include linux/filter.h
#include socket-util.h
#include dhcp-internal.h
+/* Default broadcast address for IPoIB */
+static const uint8_t ib_bcast_addr[20] = {
+0x00, 0xff, 0xff, 0xff, 0xff, 0x12, 0x40, 0x1b,
+0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+0xff, 0xff, 0xff, 0xff
+};
+
int dhcp_network_bind_raw_socket(int ifindex, union sockaddr_union *link,
- uint32_t xid, struct ether_addr mac_addr) {
+ uint32_t xid, const uint8_t *mac_addr,
+ size_t mac_addr_len, uint16_t arp_type) {
+struct ether_addr eth_mac = { { 0, 0, 0, 0, 0, 0 } };
+uint8_t dhcp_hlen = 0;
+
+assert_return(mac_addr_len 0, -EINVAL);
+
+if (arp_type == ARPHRD_ETHER) {
+assert_return(mac_addr_len == ETH_ALEN, -EINVAL);
+memcpy(eth_mac,
Re: [systemd-devel] [PATCH] Fix compilation under clang/LLVM
The error: non-const static data member must be initialized out of line can be fixed by declaring the _a and _b variables in MAX() as const. Then only the following error remains: statement expression not allowed at file scope I don't know how this could be fixed and it might be considered a clang bug. The problem is that MAX() is written as a statement expression (correctly so) and is used at file scope according to clang. I do think that this is incorrect and a union definition isn't file scope, but I could be wrong. clang disallowed statement expressions at file scope in 2009: http://llvm.org/bugs/show_bug.cgi?id=3062 A relevant bug report was later filed but nobody looked into it: http://llvm.org/bugs/show_bug.cgi?id=6857 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-journald doesn't follow max datagram length when forwarding messages to syslog
Hi,
journald fails to forward messages to syslog when it is using
Server-syslog_fd even before the limit of
/proc/sys/net/unix/max_dgram_qlen is reached.
For this experiment,
1) I have made sure /proc/sys/net/unix/max_dgram_qlen is set to
before syslog.socket is created.
2) Replaced rsyslog.service's ExecStart with /bin/sleep
3) Booted system and observed following messages:
systemd-journal[434]: Forwarding to syslog missed 2 messages. (succeed
274 messages) [*]
systemd-journal[434]: Forwarding to syslog missed 183 messages.
(succeed 274 messages)
systemd-journal[434]: Forwarding to syslog missed 41 messages.
(succeed 274 messages)
This got me interested since we are loosing messages and after further
debugging I have come up with attached patch [**]. After booting up
the system and filling up the journal with systemd-cat echo hello,
following correct behavior is observed.
systemd-journal[449]: Forwarding to syslog missed 1 messages. (succeed
1 messages)
It is same hardware and clearly I have enough memory to store 1000
messages. I can't explain why it would make a difference to use
Server-syslog_fd vs a new socket fd but something is not right and
hopefully someone can explain. Further, we can fix journal so we won't
miss messages.
Thank you
Umut
[*] The number 274 fluctuates a bit between boots and I patched
journald to display how many messages have been sent to syslog.
[**] Patch is only to show proof of concept and not optimized.
diff --git a/systemd/src/journal/journald-server.h
b/systemd/src/journal/journald-server.h
index 42a2235..b4117f7 100644
--- a/systemd/src/journal/journald-server.h
+++ b/systemd/src/journal/journald-server.h
@@ -100,6 +100,7 @@ typedef struct Server {
bool forward_to_wall;
unsigned n_forward_syslog_missed;
+unsigned n_forward_syslog_success;
usec_t last_warn_forward_syslog_missed;
uint64_t cached_available_space;
diff --git a/systemd/src/journal/journald-syslog.c
b/systemd/src/journal/journald-syslog.c
index b826e23..537386f 100644
--- a/systemd/src/journal/journald-syslog.c
+++ b/systemd/src/journal/journald-syslog.c
@@ -37,6 +37,7 @@
static void forward_syslog_iovec(Server *s, const struct iovec *iovec,
unsigned n_iovec, struct ucred *ucred, struct timeval *tv) {
+int fd = -1;
union sockaddr_union sa = {
.un.sun_family = AF_UNIX,
.un.sun_path = /run/systemd/journal/syslog,
@@ -71,12 +72,22 @@ static void forward_syslog_iovec(Server *s, const struct
iovec *iovec, unsigned
msghdr.msg_controllen = cmsg-cmsg_len;
}
+fd = socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0);
+if (fd 0) {
+log_debug(Failed to create a socket);
+return;
+}
+
+
/* Forward the syslog message we received via /dev/log to
* /run/systemd/syslog. Unfortunately we currently can't set
* the SO_TIMESTAMP auxiliary data, and hence we don't. */
-if (sendmsg(s-syslog_fd, msghdr, MSG_NOSIGNAL) = 0)
+if (sendmsg(fd, msghdr, MSG_NOSIGNAL) = 0) {
+s-n_forward_syslog_success++;
+close(fd);
return;
+ }
/* The socket is full? I guess the syslog implementation is
* too slow, and we shouldn't wait for that... */
@@ -96,17 +107,22 @@ static void forward_syslog_iovec(Server *s, const struct
iovec *iovec, unsigned
u.pid = getpid();
memcpy(CMSG_DATA(cmsg), u, sizeof(struct ucred));
-if (sendmsg(s-syslog_fd, msghdr, MSG_NOSIGNAL) = 0)
+if (sendmsg(fd, msghdr, MSG_NOSIGNAL) = 0) {
+s-n_forward_syslog_success++;
+close(fd);
return;
+ }
if (errno == EAGAIN) {
s-n_forward_syslog_missed++;
+close(fd);
return;
}
}
if (errno != ENOENT)
log_debug(Failed to forward syslog message: %m);
+close(fd);
}
static void forward_syslog_raw(Server *s, int priority, const char *buffer,
struct ucred *ucred, struct timeval *tv) {
@@ -492,7 +508,8 @@ void server_maybe_warn_forward_syslog_missed(Server *s) {
if (s-last_warn_forward_syslog_missed +
WARN_FORWARD_SYSLOG_MISSED_USEC n)
return;
-server_driver_message(s, SD_MESSAGE_FORWARD_SYSLOG_MISSED, Forwarding
to syslog missed %u messages., s-n_forward_syslog_missed);
+server_driver_message(s, SD_MESSAGE_FORWARD_SYSLOG_MISSED, Forwarding
to syslog missed %u messages. (succeed %u messages),
s-n_forward_syslog_missed,
+
s-n_forward_syslog_success);
