[systemd-devel] [PATCH 4/4] Always use recvmsg with MSG_CMSG_CLOEXEC
---
src/libsystemd-network/sd-dhcp-client.c | 2 +-
src/libsystemd-network/sd-dhcp-server.c | 2 +-
src/libsystemd/sd-rtnl/rtnl-message.c | 4 ++--
src/libudev/libudev-monitor.c | 2 +-
src/machine/machine-dbus.c | 2 +-
src/resolve/resolved-manager.c | 2 +-
src/shutdownd/shutdownd.c | 2 +-
src/timesync/timesyncd-manager.c| 2 +-
src/udev/udev-ctrl.c| 2 +-
9 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/libsystemd-network/sd-dhcp-client.c
b/src/libsystemd-network/sd-dhcp-client.c
index 5f90617..2f76e24 100644
--- a/src/libsystemd-network/sd-dhcp-client.c
+++ b/src/libsystemd-network/sd-dhcp-client.c
@@ -1582,7 +1582,7 @@ static int client_receive_message_raw(sd_event_source *s,
int fd,
iov.iov_base = packet;
iov.iov_len = buflen;
-len = recvmsg(fd, msg, 0);
+len = recvmsg(fd, msg, MSG_CMSG_CLOEXEC);
if (len 0) {
log_dhcp_client(client, could not receive message from raw
socket: %m);
diff --git a/src/libsystemd-network/sd-dhcp-server.c
b/src/libsystemd-network/sd-dhcp-server.c
index 3f89f34..1cb782f 100644
--- a/src/libsystemd-network/sd-dhcp-server.c
+++ b/src/libsystemd-network/sd-dhcp-server.c
@@ -897,7 +897,7 @@ static int server_receive_message(sd_event_source *s, int
fd,
iov.iov_base = message;
iov.iov_len = buflen;
-len = recvmsg(fd, msg, 0);
+len = recvmsg(fd, msg, MSG_CMSG_CLOEXEC);
if (len buflen)
return 0;
else if ((size_t)len sizeof(DHCPMessage))
diff --git a/src/libsystemd/sd-rtnl/rtnl-message.c
b/src/libsystemd/sd-rtnl/rtnl-message.c
index 276591f..e7e3799 100644
--- a/src/libsystemd/sd-rtnl/rtnl-message.c
+++ b/src/libsystemd/sd-rtnl/rtnl-message.c
@@ -1431,7 +1431,7 @@ static int socket_recv_message(int fd, struct iovec *iov,
uint32_t *_group, bool
assert(fd = 0);
assert(iov);
-r = recvmsg(fd, msg, MSG_TRUNC | (peek ? MSG_PEEK : 0));
+r = recvmsg(fd, msg, MSG_TRUNC | MSG_CMSG_CLOEXEC | (peek ? MSG_PEEK
: 0));
if (r 0) {
/* no data */
if (errno == ENOBUFS)
@@ -1467,7 +1467,7 @@ static int socket_recv_message(int fd, struct iovec *iov,
uint32_t *_group, bool
/* not from the kernel, ignore */
if (peek) {
/* drop the message */
-r = recvmsg(fd, msg, 0);
+r = recvmsg(fd, msg, MSG_CMSG_CLOEXEC);
if (r 0)
return (errno == EAGAIN || errno == EINTR) ? 0
: -errno;
}
diff --git a/src/libudev/libudev-monitor.c b/src/libudev/libudev-monitor.c
index 08ddde8..82ce7f6 100644
--- a/src/libudev/libudev-monitor.c
+++ b/src/libudev/libudev-monitor.c
@@ -600,7 +600,7 @@ retry:
smsg.msg_name = snl;
smsg.msg_namelen = sizeof(snl);
-buflen = recvmsg(udev_monitor-sock, smsg, 0);
+buflen = recvmsg(udev_monitor-sock, smsg, MSG_CMSG_CLOEXEC);
if (buflen 0) {
if (errno != EINTR)
log_debug(unable to receive message);
diff --git a/src/machine/machine-dbus.c b/src/machine/machine-dbus.c
index b46f0a8..da8e6c0 100644
--- a/src/machine/machine-dbus.c
+++ b/src/machine/machine-dbus.c
@@ -255,7 +255,7 @@ int bus_machine_method_get_addresses(sd_bus *bus,
sd_bus_message *message, void
iov[0] = (struct iovec) { .iov_base = family, .iov_len =
sizeof(family) };
iov[1] = (struct iovec) { .iov_base = in_addr, .iov_len =
sizeof(in_addr) };
-n = recvmsg(pair[0], mh, 0);
+n = recvmsg(pair[0], mh, MSG_CMSG_CLOEXEC);
if (n 0)
return sd_bus_error_set_errno(error, -errno);
if ((size_t) n sizeof(family))
diff --git a/src/resolve/resolved-manager.c b/src/resolve/resolved-manager.c
index 890cc04..d5c1bf0 100644
--- a/src/resolve/resolved-manager.c
+++ b/src/resolve/resolved-manager.c
@@ -892,7 +892,7 @@ int manager_recv(Manager *m, int fd, DnsProtocol protocol,
DnsPacket **ret) {
mh.msg_control = control;
mh.msg_controllen = sizeof(control);
-l = recvmsg(fd, mh, 0);
+l = recvmsg(fd, mh, MSG_CMSG_CLOEXEC);
if (l 0) {
if (errno == EAGAIN || errno == EINTR)
return 0;
diff --git a/src/shutdownd/shutdownd.c b/src/shutdownd/shutdownd.c
index 826efbf..6eb522b 100644
--- a/src/shutdownd/shutdownd.c
+++ b/src/shutdownd/shutdownd.c
@@ -69,7 +69,7 @@ static int read_packet(int fd, union shutdown_buffer *_b) {
assert(fd = 0);
assert(_b);
-n = recvmsg(fd, msghdr, MSG_DONTWAIT);
+n = recvmsg(fd, msghdr, MSG_DONTWAIT|MSG_CMSG_CLOEXEC);
if (n = 0) {
if (n == 0)
[systemd-devel] [PATCH] keymap: Add microphone mute keymap for several HP laptops
On these several HP laptops, the microphone mute hotkey is Fn+F8 and the scancode for this hotkey is 0x81, but this scancode was mapped to fn_esc in the HP generic keymap section. To fix this problem, we add a machine specific keymap section to add the correct keymap rule. BugLink: https://bugs.launchpad.net/bugs/1409721 BugLink: https://bugs.launchpad.net/bugs/1334968 Signed-off-by: Hui Wang hui.w...@canonical.com --- hwdb/60-keyboard.hwdb | 8 1 file changed, 8 insertions(+) diff --git a/hwdb/60-keyboard.hwdb b/hwdb/60-keyboard.hwdb index 94f36d9..1b7d871 100644 --- a/hwdb/60-keyboard.hwdb +++ b/hwdb/60-keyboard.hwdb @@ -473,6 +473,14 @@ keyboard:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pnFalco:pvr* # KEYBOARD_KEY_3e=fullscreen, no defined key sym +# HP EliteBook 725 G2 +keyboard:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pnHPLicrice:pvr* +# HP ProBook 440 G2 +keyboard:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pnHP440G2:pvr* +# HP ProBook 445 G1 +keyboard:dmi:bvn*:bvr*:bd*:svnHewlett-Packard*:pnHPProBook445G1NotebookPC:pvr* + KEYBOARD_KEY_81=f20# Fn+F8; Microphone mute button, should be micmute + ### # IBM ### -- 1.9.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] keymap: Add microphone mute keymap for several HP laptops
Hey Hui Wang, Hui Wang [2015-02-10 16:42 +0800]: On these several HP laptops, the microphone mute hotkey is Fn+F8 and the scancode for this hotkey is 0x81, but this scancode was mapped to fn_esc in the HP generic keymap section. To fix this problem, we add a machine specific keymap section to add the correct keymap rule. Applied, thanks! Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] avahi disconnects from bus with kdbus
Hi, This is just a heads up. Avahi-daemon doesn't work on my system with kdbus and bus-proxyd. I appended a log. I hope this helps. Otherwise every thing works quite well for me with current systemd,kdbus git. feb 10 10:11:12 dbuch-laptop avahi-daemon[2561]: avahi-daemon 0.6.31 exiting. feb 10 10:11:37 dbuch-laptop systemd[1]: Starting Avahi mDNS/DNS-SD Stack... feb 10 10:11:37 dbuch-laptop avahi-daemon[2582]: Found user 'avahi' (UID 84) and group 'avahi' (GID 84). feb 10 10:11:37 dbuch-laptop avahi-daemon[2582]: Successfully dropped root privileges. feb 10 10:11:37 dbuch-laptop avahi-daemon[2582]: avahi-daemon 0.6.31 starting up. feb 10 10:11:37 dbuch-laptop avahi-daemon[2582]: Successfully called chroot(). feb 10 10:11:37 dbuch-laptop avahi-daemon[2582]: Successfully dropped remaining capabilities. feb 10 10:11:37 dbuch-laptop avahi-daemon[2582]: Loading service file /services/sftp-ssh.service. feb 10 10:11:37 dbuch-laptop avahi-daemon[2582]: Loading service file /services/ssh.service. feb 10 10:11:37 dbuch-laptop avahi-daemon[2582]: Joining mDNS multicast group on interface wlp3s0.IPv4 with address 192.168.1.3. feb 10 10:11:37 dbuch-laptop avahi-daemon[2582]: New relevant interface wlp3s0.IPv4 for mDNS. feb 10 10:11:37 dbuch-laptop avahi-daemon[2582]: Network interface enumeration completed. feb 10 10:11:37 dbuch-laptop avahi-daemon[2582]: Registering new address record for 192.168.1.3 on wlp3s0.IPv4. feb 10 10:11:37 dbuch-laptop avahi-daemon[2582]: Registering HINFO record with values 'X86_64'/'LINUX'. feb 10 10:11:37 dbuch-laptop systemd[1]: Started Avahi mDNS/DNS-SD Stack. feb 10 10:11:38 dbuch-laptop avahi-daemon[2582]: Server startup complete. Host name is dbuch-laptop.local. Local service cookie is 234317167 feb 10 10:11:38 dbuch-laptop systemd-bus-proxyd[1783]: Failed to send message to bus: Operation not permitted feb 10 10:11:38 dbuch-laptop avahi-daemon[2582]: Disconnected from D-Bus, exiting. feb 10 10:11:38 dbuch-laptop avahi-daemon[2582]: Got SIGTERM, quitting. feb 10 10:11:38 dbuch-laptop avahi-daemon[2582]: Leaving mDNS multicast group on interface wlp3s0.IPv4 with address 192.168.1.3. feb 10 10:11:38 dbuch-laptop avahi-daemon[2582]: avahi-daemon 0.6.31 exiting. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] help with compiling systemd-218 library only 32-bit multilib host
On Mon, 09.02.15 13:25, lux-integ (lux-in...@btconnect.com) wrote: however I found hard links to /usr/lib even when when passes --libexecdir=/usr/lib64 for the 64bit build Yeah, /usr/lib64 is the place for 64bit versions of shared objects on multilib 32/64 hosts. Everything that is not a library stays in /usr/lib, even if multilib is used. (except on Gentoo, because the Gentoo folks don't understand multilib and think if a path has 64 in it, it must be better... ;-) ) If you only build for x86-64 then you could as well not use multilib at all and avoid having /usr/lib64 at 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] pam_limits: Could not set limit for ...: Operation not permitted
On Tue, 10.02.15 08:42, Kai Krakow (hurikha...@gmail.com) wrote: Dez 15 22:33:57 jupiter systemd[1515]: pam_limits(systemd-user:session): Could not set limit for 'memlock': Operation not permitted Dez 15 22:33:57 jupiter systemd[1515]: pam_limits(systemd-user:session): Could not set limit for 'nice': Operation not permitted Dez 15 22:33:57 jupiter systemd[1515]: pam_limits(systemd-user:session): Could not set limit for 'rtprio': Operation not permitted Dez 15 22:33:57 jupiter systemd[1515]: PAM audit_log_acct_message() failed: Operation not permitted Dez 15 22:33:57 jupiter systemd[1515]: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted Is it meaningless? Do I have to worry? Or which configuration do I miss? Hmm, this is certainly weird. It indicates some issue with your PAM setup maybe? Do you have SELinux enabled? Is this in some container or so? This is a Gentoo box, plain hardware. My pam configuration looks right. When I run systemd --user manually through strace, I see missing permissions on cgroups. But I almost guess this is intended if running from an already existing user session. Yeah, --user instances of systemd don't get access to the controller attributes of the cgroup tree, and that's intended. I don't use SELinux or similar security policies, just plain Linux security policy as it is default in Gentoo. But strangely systemd gives me on boot: systemd 218 running in system mode. (+PAM -AUDIT -SELINUX +IMA -APPARMOR +SMACK -SYSVINIT +UTMP -LIBCRYPTSETUP -GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN) I don't know why smack is enabled... It's not in my kernel and isn't set as a feature to compile in the ebuild. But I'm not sure if it would make a difference for this problem. Well, turn it off during build-time if you don't want it. Use --disable-smack. It is enabled by default, since all features we consider stable are enabled by default unless their library dependencies are missing. Since SMACK so far didn't require any library it hence is effectively always on unless you explicitly turn it off... I suppose for the same reason, rtkit-daemon cannot give RT priority to itself... This is unrelated. The kernel RT cgroup API is really just awfully broken, ignore this. Not sure what else I can suggest... 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] systemd-run fails with certain properties
On Fri, 06.02.15 18:09, Daurnimator (q...@daurnimator.com) wrote: Trying to use systemd-run with certain properties consistently fails, e.g.: $ systemd-run --scope --nice 18 --property=NoNewPrivileges=true echo test Unknown assignment NoNewPrivileges=true. Failed to create bus message: No such device or address $ systemd-run --scope --user --nice 18 -p User=nobody echo hi Failed to create bus message: Read-only file system Two things: a) not all properties are currently settable for transient units, simply because we haven't hooked that up yet. We are happy to hook up more though, it's just a matter of doing the work... b) Neither NoNewPrivileges= nor User= apply to *scope* units anyway. Note that for scope unit its not systemd that forks of the executables, but it's your client side tool, you just ask systemd for to manage them for you. Now, since NoNewPrivileges= and User= are execution parameters, they don't apply at all to scope units... systemd-run supports both running binaries as a service and as a scope. You selected scope, hence the line you specify makes little sense. The reason you get two different error codes is that in the first case we have no hook-up for NoNewPrivileges= at all so far, i.e. issue a) hits. In the second case issue b) hits as the property is parsed but not available for scope units. Of course, the error messgae should be more explanatory, it's rubbish the way it is. Added to the TODO list to fix 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] [PATCH 2/2] logind: do not continue when runtime creation path fails
Hi,
On 10/02/15 13:30, Lennart Poettering wrote:
On Sun, 08.02.15 22:21, Philippe De Swert (philippedesw...@gmail.com) wrote:
In user_mkdir_runtime_path() there is no need to continue if the
creation of the directory fails for whatever reason, as subsequent
actions on that directory will fail anyway.
Found with Coverity. Fixes: CID#1237538
---
src/login/logind-user.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/login/logind-user.c b/src/login/logind-user.c
index 7b40ef5..a329457 100644
--- a/src/login/logind-user.c
+++ b/src/login/logind-user.c
@@ -322,7 +322,8 @@ static int user_mkdir_runtime_path(User *u) {
if (path_is_mount_point(p, false) = 0) {
_cleanup_free_ char *t = NULL;
-mkdir(p, 0700);
+if(mkdir(p, 0700) 0)
+ goto fail;
No, it's completely OK if this fails, and it is very likely that it
*will* fail, since the dir might already exist, and we thus get
EEXIST.
True, I somehow always forget that is an error case too. However the
problem is still there if creation fails, filesystem full/ro, ...
Although I need to admit it is rather cosmetic as problems will be
caught later anyway.
Regards,
Philippe
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] logind: do not continue when runtime creation path fails
On Tue, 10.02.15 13:45, Philippe De Swert (philippedesw...@gmail.com) wrote:
Hi,
On 10/02/15 13:30, Lennart Poettering wrote:
On Sun, 08.02.15 22:21, Philippe De Swert (philippedesw...@gmail.com) wrote:
In user_mkdir_runtime_path() there is no need to continue if the
creation of the directory fails for whatever reason, as subsequent
actions on that directory will fail anyway.
Found with Coverity. Fixes: CID#1237538
---
src/login/logind-user.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/login/logind-user.c b/src/login/logind-user.c
index 7b40ef5..a329457 100644
--- a/src/login/logind-user.c
+++ b/src/login/logind-user.c
@@ -322,7 +322,8 @@ static int user_mkdir_runtime_path(User *u) {
if (path_is_mount_point(p, false) = 0) {
_cleanup_free_ char *t = NULL;
-mkdir(p, 0700);
+if(mkdir(p, 0700) 0)
+ goto fail;
No, it's completely OK if this fails, and it is very likely that it
*will* fail, since the dir might already exist, and we thus get
EEXIST.
True, I somehow always forget that is an error case too. However the
problem is still there if creation fails, filesystem full/ro, ...
Although I need to admit it is rather cosmetic as problems will be
caught later anyway.
Yes, the idea is that the mount() later on will catch all errors, and
there's nothing gained by checking any failure of mkdir()...
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] Added support for Uplink Failure Detection using BindCarrier
Hi Zbyszek, Thanks for your review. I've handled your remarks. Let me know what you think. Best Regards, Alin Alin Rauta (1): Added support for Uplink Failure Detection using BindCarrier man/systemd.network.xml | 11 ++ src/libsystemd/sd-network/sd-network.c | 4 + src/network/networkctl.c | 211 --- src/network/networkd-link.c | 123 +- src/network/networkd-link.h | 1 + src/network/networkd-manager.c | 7 + src/network/networkd-network-gperf.gperf | 1 + src/network/networkd-network.c | 10 ++ src/network/networkd.h | 2 +- src/systemd/sd-network.h | 3 + 10 files changed, 355 insertions(+), 18 deletions(-) -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] .gitignore: add systemd-pull
--- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index ab6d9d1..e8a4085 100644 --- a/.gitignore +++ b/.gitignore @@ -103,6 +103,7 @@ /systemd-notify /systemd-nspawn /systemd-path +/systemd-pull /systemd-quotacheck /systemd-random-seed /systemd-rc-local-generator -- 1.9.3 pgpfSyc5R3OK3.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] .gitignore: add systemd-pull
On Tue, 10.02.15 12:31, Vincent Batts (vba...@redhat.com) wrote: Indeed! Applied! Thanks! --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index ab6d9d1..e8a4085 100644 --- a/.gitignore +++ b/.gitignore @@ -103,6 +103,7 @@ /systemd-notify /systemd-nspawn /systemd-path +/systemd-pull /systemd-quotacheck /systemd-random-seed /systemd-rc-local-generator -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel 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] Added support for Uplink Failure Detection using BindCarrier
---
man/systemd.network.xml | 11 ++
src/libsystemd/sd-network/sd-network.c | 4 +
src/network/networkctl.c | 211 ---
src/network/networkd-link.c | 123 +-
src/network/networkd-link.h | 1 +
src/network/networkd-manager.c | 7 +
src/network/networkd-network-gperf.gperf | 1 +
src/network/networkd-network.c | 10 ++
src/network/networkd.h | 2 +-
src/systemd/sd-network.h | 3 +
10 files changed, 355 insertions(+), 18 deletions(-)
diff --git a/man/systemd.network.xml b/man/systemd.network.xml
index 9b3a92d..8b2ca4e 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -270,6 +270,17 @@
/listitem
/varlistentry
varlistentry
+ termvarnameBindCarrier=/varname/term
+ listitem
+paraA port or a list of ports. When set, controls the
+behaviour of the current interface. When all ports in the list
+are operational down, the failure is propagated to the current
+interface. When at least one port has carrier, the current
+interface is brought up.
+/para
+ /listitem
+/varlistentry
+varlistentry
termvarnameAddress=/varname/term
listitem
paraA static IPv4 or IPv6 address and its prefix length,
diff --git a/src/libsystemd/sd-network/sd-network.c
b/src/libsystemd/sd-network/sd-network.c
index c735cac..b574d19 100644
--- a/src/libsystemd/sd-network/sd-network.c
+++ b/src/libsystemd/sd-network/sd-network.c
@@ -264,6 +264,10 @@ _public_ int sd_network_link_get_domains(int ifindex, char
***ret) {
return network_get_link_strv(DOMAINS, ifindex, ret);
}
+_public_ int sd_network_link_get_carriers(int ifindex, char ***ret) {
+return network_get_link_strv(CARRIERS, ifindex, ret);
+}
+
_public_ int sd_network_link_get_wildcard_domain(int ifindex) {
int r;
_cleanup_free_ char *p = NULL, *s = NULL;
diff --git a/src/network/networkctl.c b/src/network/networkctl.c
index aa83f32..ffb38e8 100644
--- a/src/network/networkctl.c
+++ b/src/network/networkctl.c
@@ -22,6 +22,7 @@
#include stdbool.h
#include getopt.h
#include net/if.h
+#include fnmatch.h
#include sd-network.h
#include sd-rtnl.h
@@ -393,6 +394,161 @@ static int get_gateway_description(
return -ENODATA;
}
+static bool is_carrier(const char *ifname,
+ char **carriers) {
+ char **i;
+
+ STRV_FOREACH(i, carriers)
+ if (fnmatch(*i, ifname, 0) == 0)
+ return true;
+
+ return false;
+}
+
+/* get the links that are bound to this port. */
+static int get_downlinks(const char *name,
+ sd_rtnl_message *m,
+ LinkInfo **downlinks,
+ int *down_count) {
+_cleanup_free_ LinkInfo *links = NULL;
+sd_rtnl_message *i;
+size_t size = 0;
+size_t c = 0;
+int r;
+
+assert(m);
+assert(name);
+
+*down_count = 0;
+*downlinks = NULL;
+
+for (i = m; i; i = sd_rtnl_message_next(i)) {
+_cleanup_strv_free_ char **carriers = NULL;
+const char *link_name;
+int ifindex;
+
+r = sd_rtnl_message_link_get_ifindex(i, ifindex);
+if (r 0)
+return r;
+
+r = sd_rtnl_message_read_string(i, IFLA_IFNAME, link_name);
+if (r 0)
+return r;
+
+r = sd_network_link_get_carriers(ifindex, carriers);
+if (r == -ENODATA || strv_isempty(carriers))
+continue;
+
+if (r 0) {
+log_warning(Failed to get carrier list for port: %s,
name);
+continue;
+}
+
+if (is_carrier(name, carriers)) {
+ if (!GREEDY_REALLOC(links, size, c+1))
+ return -ENOMEM;
+
+ links[c].name = link_name;
+ c++;
+}
+}
+
+*downlinks = links;
+*down_count = (int) c;
+
+links = NULL;
+
+return 0;
+}
+
+/* get the links to which current port is bound to. */
+static int get_uplinks(int ifindex,
+ sd_rtnl_message *m,
+ LinkInfo **uplinks,
+ int *up_count) {
+_cleanup_free_ LinkInfo *links = NULL;
+_cleanup_strv_free_ char **carriers = NULL;
+sd_rtnl_message *i;
+size_t size = 0, c = 0;
+int r;
+
+assert(m);
+
+*up_count = 0;
+*uplinks = NULL;
+
+/* check if this port has carriers. */
+r =
Re: [systemd-devel] [PATCH 2/2] logind: do not continue when runtime creation path fails
On Sun, 08.02.15 22:21, Philippe De Swert (philippedesw...@gmail.com) wrote:
In user_mkdir_runtime_path() there is no need to continue if the
creation of the directory fails for whatever reason, as subsequent
actions on that directory will fail anyway.
Found with Coverity. Fixes: CID#1237538
---
src/login/logind-user.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/login/logind-user.c b/src/login/logind-user.c
index 7b40ef5..a329457 100644
--- a/src/login/logind-user.c
+++ b/src/login/logind-user.c
@@ -322,7 +322,8 @@ static int user_mkdir_runtime_path(User *u) {
if (path_is_mount_point(p, false) = 0) {
_cleanup_free_ char *t = NULL;
-mkdir(p, 0700);
+if(mkdir(p, 0700) 0)
+ goto fail;
No, it's completely OK if this fails, and it is very likely that it
*will* fail, since the dir might already exist, and we thus get
EEXIST.
This is a candidate for prefixing with (void), to tell Coverity that
we knowingly ignore the return value.
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] logind: do not continue when runtime creation path fails
On Tue, 10.02.15 12:30, Lennart Poettering (lenn...@poettering.net) wrote:
On Sun, 08.02.15 22:21, Philippe De Swert (philippedesw...@gmail.com) wrote:
In user_mkdir_runtime_path() there is no need to continue if the
creation of the directory fails for whatever reason, as subsequent
actions on that directory will fail anyway.
Found with Coverity. Fixes: CID#1237538
---
src/login/logind-user.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/login/logind-user.c b/src/login/logind-user.c
index 7b40ef5..a329457 100644
--- a/src/login/logind-user.c
+++ b/src/login/logind-user.c
@@ -322,7 +322,8 @@ static int user_mkdir_runtime_path(User *u) {
if (path_is_mount_point(p, false) = 0) {
_cleanup_free_ char *t = NULL;
-mkdir(p, 0700);
+if(mkdir(p, 0700) 0)
+ goto fail;
No, it's completely OK if this fails, and it is very likely that it
*will* fail, since the dir might already exist, and we thus get
EEXIST.
This is a candidate for prefixing with (void), to tell Coverity that
we knowingly ignore the return value.
Prefixed it now like this, in git.
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] systemd-nspawn create container under unprivileged user
On Thu, 05.02.15 02:03, Vasiliy Tolstov (v.tols...@selfip.ru) wrote: Hello! Does it possible to create container as regular user? Oh what capabilities i need to add to create container not using root? Invoking containers without privileges is not supported by nspawn, and this is unlikely to change, as I fail to see any strong usecase for this... If somebody can englighten me about the usecase for allowing containers to be run by unprivileged users, I'd be willing to change my mind though... Note that to my knowledge any support for unprivileged containers has been disabled in the kernel on many distros though including Fedora's, since it's basically one giant security hole. Note that many of machinectl's commands involve polkit checks, which means it's easy to open them up for unprivileged clients. However, in that case the containers would be forked off and maintained privileged, only the clients will be unprivileged... LXC supports unprivileged containers though, this might be an option for you. 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] networkd DHCPv4 logging endian fix
On Tue, 10.02.15 18:07, Paul Martin (paul.mar...@codethink.co.uk) wrote: On a big-endian host, systemd-networkd prints out IPv4 network addresses byte reversed: Feb 10 16:43:32 hostname systemd-networkd[151]: eth0 : DHCPv4 address 158.1.24.10/16 via 1.1.24.10 The address obtained is 10.24.1.158/16 and the route is 10.24.0.0/16 dev eth0 src 10.24.1.187 The macro ADDRESS_FMT_VAL() unpacks a struct in_addr in a little-endian specific manner. This patch makes the macro endian agnostic using the same trick as is used in the IN6_ARE_ADDR_EQUAL() macro in netinet/in.h. diff --git a/src/network/networkd-link.h b/src/network/networkd-link.h index 449dbc8..3394b61 100644 --- a/src/network/networkd-link.h +++ b/src/network/networkd-link.h @@ -153,7 +153,7 @@ DEFINE_TRIVIAL_CLEANUP_FUNC(Link*, link_unref); #define log_link_struct(link, level, ...) log_struct(level, INTERFACE=%s, link-ifname, __VA_ARGS__) #define ADDRESS_FMT_VAL(address)\ -(address).s_addr 0xFF,\ -((address).s_addr 8) 0xFF, \ -((address).s_addr 16) 0xFF,\ -(address).s_addr 24 +((const uint8_t *) (address))[0], \ +((const uint8_t *) (address))[1], \ +((const uint8_t *) (address))[2], \ +((const uint8_t *) (address))[3] Hmm, I think it would be nicer to use be32toh() here instead, since it ensures the macro is (to a limited degree) typesafe. Any chance you could rework that? 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] networkd DHCPv4 logging endian fix
On a big-endian host, systemd-networkd prints out IPv4 network addresses byte reversed: Feb 10 16:43:32 hostname systemd-networkd[151]: eth0 : DHCPv4 address 158.1.24.10/16 via 1.1.24.10 The address obtained is 10.24.1.158/16 and the route is 10.24.0.0/16 dev eth0 src 10.24.1.187 The macro ADDRESS_FMT_VAL() unpacks a struct in_addr in a little-endian specific manner. This patch makes the macro endian agnostic using the same trick as is used in the IN6_ARE_ADDR_EQUAL() macro in netinet/in.h. diff --git a/src/network/networkd-link.h b/src/network/networkd-link.h index 449dbc8..3394b61 100644 --- a/src/network/networkd-link.h +++ b/src/network/networkd-link.h @@ -153,7 +153,7 @@ DEFINE_TRIVIAL_CLEANUP_FUNC(Link*, link_unref); #define log_link_struct(link, level, ...) log_struct(level, INTERFACE=%s, link-ifname, __VA_ARGS__) #define ADDRESS_FMT_VAL(address)\ -(address).s_addr 0xFF,\ -((address).s_addr 8) 0xFF, \ -((address).s_addr 16) 0xFF,\ -(address).s_addr 24 +((const uint8_t *) (address))[0], \ +((const uint8_t *) (address))[1], \ +((const uint8_t *) (address))[2], \ +((const uint8_t *) (address))[3] -- Paul Martin http://www.codethink.co.uk/ Senior Software Developer, Codethink Ltd ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] pam_limits: Could not set limit for ...: Operation not permitted
Lennart Poettering lenn...@poettering.net schrieb: On Tue, 10.02.15 08:42, Kai Krakow (hurikha...@gmail.com) wrote: Dez 15 22:33:57 jupiter systemd[1515]: pam_limits(systemd-user:session): Could not set limit for 'memlock': Operation not permitted Dez 15 22:33:57 jupiter systemd[1515]: pam_limits(systemd-user:session): Could not set limit for 'nice': Operation not permitted Dez 15 22:33:57 jupiter systemd[1515]: pam_limits(systemd-user:session): Could not set limit for 'rtprio': Operation not permitted Dez 15 22:33:57 jupiter systemd[1515]: PAM audit_log_acct_message() failed: Operation not permitted Dez 15 22:33:57 jupiter systemd[1515]: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted Is it meaningless? Do I have to worry? Or which configuration do I miss? Hmm, this is certainly weird. It indicates some issue with your PAM setup maybe? Do you have SELinux enabled? Is this in some container or so? This is a Gentoo box, plain hardware. My pam configuration looks right. When I run systemd --user manually through strace, I see missing permissions on cgroups. But I almost guess this is intended if running from an already existing user session. Yeah, --user instances of systemd don't get access to the controller attributes of the cgroup tree, and that's intended. Then the question is: Why or what does try to start a user session in the first place? I don't think KDE does this as it's not there yet (at least in KDE 4.x). And I didn't enable a user@...service (but shouldn't it work then when started from the normal service startups in systemd). I don't consider this a bug, but my main problem with this is I have no idea how to track that down. I don't use SELinux or similar security policies, just plain Linux security policy as it is default in Gentoo. But strangely systemd gives me on boot: systemd 218 running in system mode. (+PAM -AUDIT -SELINUX +IMA -APPARMOR +SMACK -SYSVINIT +UTMP -LIBCRYPTSETUP -GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN) I don't know why smack is enabled... It's not in my kernel and isn't set as a feature to compile in the ebuild. But I'm not sure if it would make a difference for this problem. Well, turn it off during build-time if you don't want it. Use --disable-smack. It is enabled by default, since all features we consider stable are enabled by default unless their library dependencies are missing. Since SMACK so far didn't require any library it hence is effectively always on unless you explicitly turn it off... If it doesn't hurt either, I just let it the way it is. There was just this idea it could be related to the problem. But from your words I guess: nope. I suppose for the same reason, rtkit-daemon cannot give RT priority to itself... This is unrelated. The kernel RT cgroup API is really just awfully broken, ignore this. Maybe just turn off the RT_FIFO feature in the kernel for the time being? Not sure what else I can suggest... I appreciate that you answered although this was pretty old. Good to know thinks don't become forgotten, just take time. ;-) -- Replies to list only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] directive for executing a script on service failure
On Fri, 06.02.15 21:23, Mantas Mikulėnas (graw...@gmail.com) wrote: On Fri, Feb 6, 2015 at 5:26 PM, George Karakougioumtzis mad-proffes...@hotmail.com wrote: Hi. Congrats for the near perfect job on systemd! I was searching for a directive to execute a script upon systemd service failure. I would like to receive desktop notifications about such failures. I stumbled upon OnFailure and FailureAction but these have hardcoded list of actions? One of those actions is start an arbitrary unit, which could handle notifications... Unfortunately it doesn't actually pass any failure information to that unit. So, instead, you might have to watch the system log (journal) for unit failure notices. (I would normally have said that the journal makes it easy to filter for them, but quite strangely, these ones don't have a MESSAGE_ID attached...) if you use OnFailure= I'd recommend checking the properties of the unit that failed instead of checking the journal. i.e. the equivalent of systemctl show -p ... on the unit that failed... And yeah, we should define a MESSAGE_ID for unit failure log messages. Any hints how to get notified (with notify-send most likely)? systemd calling notify-send isn't going to happen – as a service, it runs outside your desktop session, and has no access to its D-Bus session bus, which tends to be started at a random address. (There might even be several sessions, not just one!) And even considering the future user bus plans (which would put the session bus at a known fixed location), the whole idea of having a service inject something into a desktop session is really ugly. Even Microsoft realized that and implemented session 0 isolation in VIsta. Yes, that's correct. We do not call from lower layers into higher layers in systemd. Higher layers should instead subscribe to lower layers... In other words, such a notifier would need to be started from within your desktop session, connect *to* systemd (either by waiting for signals on the system bus or by watching the journal messages), and idle in background waiting for some unit to fail. With DBus it could be a simple 10-line script, waiting for signals on one bus and calling Notify() on another... Another option would be to write a clinet that watches the journal constantly, and pops up a notification each time a message with LOG_ERR and higer is sent. After all, not only service errors should be interesting, all other errors should matter 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] Removing unnecessary includes
On Mon, 09.02.15 10:19, Thomas H.P. Andersen (pho...@gmail.com) wrote: include-what-you-use is actually pretty nice. It is also a little bit crazy. It wants to include everything directly and we would add a lot includes for errno.h, string.h, stdlib.h, stdbool.h, stddef.h, etc etc everywhere. It also wants to use forward declares when possible. The coding style does not say anything specific about this. Any preferences? I will use the tool to trim the unnecessary includes first and leave its other advise for later. It will be interesting to see how each step affects the build time. A feature is that I find interesting is that it can comment each include with the reason that it was included. Not something to commit, but useful to get an overview of why each include is there. Hmm, I find this unnecessary noise I must say... #include stdbool.h// for false, true, bool #include stddef.h // for offsetof, size_t #include stdint.h // for uint64_t #include string.h // for strdup, strlen #include config.h // for PACKAGE_STRING, #VERSION This one we get though -include config.h on the gcc command line. #include src/shared/macro.h // for assert, assert_cc, etc #include src/shared/path-lookup.h #include src/shared/time-util.h // for format_timespan, usec_t, etc #include src/systemd/sd-bus-protocol.h // for ::SD_BUS_TYPE_ARRAY Nah, please no absolute includes... Any chance this can turned off? The full include-list for src/analyze/analyze.c: #include errno.h // for EIO, ENOMEM, E2BIG, EINVAL, etc #include fnmatch.h// for fnmatch #include getopt.h // for optind, no_argument, optarg, etc #include locale.h // for NULL, setlocale, LC_ALL, etc #include stdbool.h// for false, true, bool #include stddef.h // for offsetof, size_t #include stdint.h // for uint64_t #include stdio.h // for printf, puts, fputs, stdout #include stdlib.h // for free, qsort, EXIT_FAILURE, etc #include string.h // for strdup, strlen #include analyze-verify.h // for verify_units #include build.h // for SYSTEMD_FEATURES #include bus-error.h // for bus_error_message #include bus-util.h // for UnitInfo, etc #include config.h // for PACKAGE_STRING, VERSION #include hashmap.h// for hashmap_get, Hashmap, etc #include log.h// for log_error, log_oom, etc #include pager.h // for pager_close, pager_open #include sd-bus.h // for sd_bus, SD_BUS_ERROR_NULL, etc #include special.h// for SPECIAL_DEFAULT_TARGET #include src/shared/macro.h // for assert, assert_cc, etc #include src/shared/path-lookup.h #include src/shared/time-util.h // for format_timespan, usec_t, etc #include src/systemd/sd-bus-protocol.h // for ::SD_BUS_TYPE_ARRAY #include strv.h // for strv_isempty, STRV_FOREACH, etc #include strxcpyx.h // for strpcpyf #include unit-name.h // for unit_dbus_path_from_name #include util.h // for isempty, streq, etc Note that I actually try to roughly maintain an order when including things: For the headers of other projects i try to put system headers first, 3rd party headers second. For our own stuff I try to put external API stuff first (i.e. sd-*.h), followed by internal API-like stuff form src/shared, and finally the other headers that are prviate to the specific module the code is in. I'd really like to avoid a scheme where this is reordered randomly... The order kinda is relevant, since more local, specific definitions should never influence more public, generic interfaces, if you follow what I mean? A lot of header files use #ifndef, and only conditionally define things then. They should not get confused by our own definitions 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] pam_limits: Could not set limit for ...: Operation not permitted
Lennart Poettering lenn...@poettering.net schrieb: On Tue, 10.02.15 20:16, Kai Krakow (hurikha...@gmail.com) wrote: Then the question is: Why or what does try to start a user session in the first place? I don't think KDE does this as it's not there yet (at least in KDE 4.x). And I didn't enable a user@...service (but shouldn't it work then when started from the normal service startups in systemd). logind maintains one user@.service instance per-user as long as she or he is logged in at least once. The service is basically ref-counted by the user's session. So, be patient with me until I fully understand it... I'm using kdm (previously lightdm but made no difference) to launch my KDE session. At some time in the process, the aforementioned messages get logged. As far as I can tell, logind is involved in this as it actually does spawn my graphical session. That in turn, according to your words, means: A user@.service for me should be launched (whether I need it or not). If this is true, I should see a systemd user instance in ps axuw, or simpler: Another systemd process except PID1 should be running. So far the outcome is: It doesn't but I instead see those error logs in the journal. I don't consider this a bug, but my main problem with this is I have no idea how to track that down. Do you have any weird kernel patch applied, something that is supposed to improve security or so? This is the plain Gentoo kernel 3.18.6 for desktop, nothing special except BFQ patches (applied by the Gentoo kernel package itself, not manually patched). I'm pretty sure Gentoo does not apply any special extra patches. Autogrouping for cgroups (SCHED_AUTOGROUP) is turned on - I'm not sure if it plays into the issue but from what I read it shouldn't. Maybe I should diff my kernel config with one that doesn't show this behaviour. Do you have one I should compare with? This is unrelated. The kernel RT cgroup API is really just awfully broken, ignore this. Maybe just turn off the RT_FIFO feature in the kernel for the time being? Nah, just ignore that log msg... I meant SCHED_OTHER/RR_FIFO, but I'll ignore that then. -- Replies to list only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] units: add SecureBits
On Sat, 07.02.15 10:40, Topi Miettinen (toiwo...@gmail.com) wrote: No setuid programs are expected to be executed, so add SecureBits=no-setuid-fixup no-setuid-fixup-locked to unit files. So, hmm, after reading the man page again: what's the rationale for precisely these bits? I mean no-setuid-fixup seems to be something that applies to setuid(), setresuid() calls and suchlike, which seems pretty uninteresting. Much more interesting is SECBIT_NOROOT, which disables suid binary handling... Can you elaborate? 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] Removing unnecessary includes
On Sat, 07.02.15 10:29, Thomas H.P. Andersen (pho...@gmail.com) wrote: Hi, I am looking at ways to automatically trim the unnecessary includes. One way to do it is a script[1] which simply tests if the compile still works after removing each include one at a time. It does this in reverse order for all includes in the .c files. Using -Werror we catch any new warnings too. I think this is quite useful, but I'd also be really careful with this. glibc versions sometimes require different headers to be included to get some functionality, thus automatic removal of headers that are unnecessary on one system doesn't mean this is universally the case... Moreover depdending on compile-time options you might different headers... 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] networkd: use valid bus paths
Hi, Mantas Mikulėnas: Object path components must start with [A-Za-z_] (AFAIK). Also the value of 'p' is undefined if asprintf fails. IMHO you should not put two unrelated issues in one patch. -- -- Matthias Urlichs ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: use valid bus paths
On Tue, Feb 10, 2015 at 9:02 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Fri, 06.02.15 22:35, Mantas Mikulėnas (graw...@gmail.com) wrote:
Object path components must start with [A-Za-z_] (AFAIK).
Also the value of 'p' is undefined if asprintf fails.
Well, asprintf() the way glibc defines it does not clobber the
passed-in pointer on failure. We rely on that all over the code, and I
am pretty sure that's the right thing to do. The man page of
asprintf() is a bit misleading in this case, and the info page doesn't
mention this at all. The glibc sources tell show that they indeed
don't clobber the pointer on failure.
Given that p was initialized to NULL the check Tom had in place
originally is OK hence.
And even if glibc asprintf() would clobber passed in pointers on
failure, the right fix would really be to write a small wrapper that
corrects that, and use that everywhere instead of patching this
individually on each invocation...
For the record: This has now all been refactored to use
sd_bus_path_{en,de}code, so the issues no longer apply. Thanks for
looking at it though!
Cheers,
Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] pam_limits: Could not set limit for ...: Operation not permitted
On Tue, 10.02.15 20:16, Kai Krakow (hurikha...@gmail.com) wrote: Then the question is: Why or what does try to start a user session in the first place? I don't think KDE does this as it's not there yet (at least in KDE 4.x). And I didn't enable a user@...service (but shouldn't it work then when started from the normal service startups in systemd). logind maintains one user@.service instance per-user as long as she or he is logged in at least once. The service is basically ref-counted by the user's session. I don't consider this a bug, but my main problem with this is I have no idea how to track that down. Do you have any weird kernel patch applied, something that is supposed to improve security or so? I suppose for the same reason, rtkit-daemon cannot give RT priority to itself... This is unrelated. The kernel RT cgroup API is really just awfully broken, ignore this. Maybe just turn off the RT_FIFO feature in the kernel for the time being? Nah, just ignore that log msg... 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 4/4] Always use recvmsg with MSG_CMSG_CLOEXEC
On Tue, 10.02.15 12:06, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:
Well, all but two of these recvmsg() invocations apply to network
sockets, which cannot receive fds, hence specifying the flag is kinda
pointless...
For the other two cases we should probably close all fds we
receive... I mean receiving them and not doing anything with them is
not any worse or better as doing so and having O_CLOEXEC set for
them...
That said, I think it probably makes sense to enforce the general rule
that recvmsg() must be invoked with MSG_CMSG_CLOEXEC, hence I applied
your patch and updated the CODING_STYLE to mention this.
---
src/libsystemd-network/sd-dhcp-client.c | 2 +-
src/libsystemd-network/sd-dhcp-server.c | 2 +-
src/libsystemd/sd-rtnl/rtnl-message.c | 4 ++--
src/libudev/libudev-monitor.c | 2 +-
src/machine/machine-dbus.c | 2 +-
src/resolve/resolved-manager.c | 2 +-
src/shutdownd/shutdownd.c | 2 +-
src/timesync/timesyncd-manager.c| 2 +-
src/udev/udev-ctrl.c| 2 +-
9 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/libsystemd-network/sd-dhcp-client.c
b/src/libsystemd-network/sd-dhcp-client.c
index 5f90617..2f76e24 100644
--- a/src/libsystemd-network/sd-dhcp-client.c
+++ b/src/libsystemd-network/sd-dhcp-client.c
@@ -1582,7 +1582,7 @@ static int client_receive_message_raw(sd_event_source
*s, int fd,
iov.iov_base = packet;
iov.iov_len = buflen;
-len = recvmsg(fd, msg, 0);
+len = recvmsg(fd, msg, MSG_CMSG_CLOEXEC);
if (len 0) {
log_dhcp_client(client, could not receive message from raw
socket: %m);
diff --git a/src/libsystemd-network/sd-dhcp-server.c
b/src/libsystemd-network/sd-dhcp-server.c
index 3f89f34..1cb782f 100644
--- a/src/libsystemd-network/sd-dhcp-server.c
+++ b/src/libsystemd-network/sd-dhcp-server.c
@@ -897,7 +897,7 @@ static int server_receive_message(sd_event_source *s, int
fd,
iov.iov_base = message;
iov.iov_len = buflen;
-len = recvmsg(fd, msg, 0);
+len = recvmsg(fd, msg, MSG_CMSG_CLOEXEC);
if (len buflen)
return 0;
else if ((size_t)len sizeof(DHCPMessage))
diff --git a/src/libsystemd/sd-rtnl/rtnl-message.c
b/src/libsystemd/sd-rtnl/rtnl-message.c
index 276591f..e7e3799 100644
--- a/src/libsystemd/sd-rtnl/rtnl-message.c
+++ b/src/libsystemd/sd-rtnl/rtnl-message.c
@@ -1431,7 +1431,7 @@ static int socket_recv_message(int fd, struct iovec
*iov, uint32_t *_group, bool
assert(fd = 0);
assert(iov);
-r = recvmsg(fd, msg, MSG_TRUNC | (peek ? MSG_PEEK : 0));
+r = recvmsg(fd, msg, MSG_TRUNC | MSG_CMSG_CLOEXEC | (peek ?
MSG_PEEK : 0));
if (r 0) {
/* no data */
if (errno == ENOBUFS)
@@ -1467,7 +1467,7 @@ static int socket_recv_message(int fd, struct iovec
*iov, uint32_t *_group, bool
/* not from the kernel, ignore */
if (peek) {
/* drop the message */
-r = recvmsg(fd, msg, 0);
+r = recvmsg(fd, msg, MSG_CMSG_CLOEXEC);
if (r 0)
return (errno == EAGAIN || errno == EINTR) ?
0 : -errno;
}
diff --git a/src/libudev/libudev-monitor.c b/src/libudev/libudev-monitor.c
index 08ddde8..82ce7f6 100644
--- a/src/libudev/libudev-monitor.c
+++ b/src/libudev/libudev-monitor.c
@@ -600,7 +600,7 @@ retry:
smsg.msg_name = snl;
smsg.msg_namelen = sizeof(snl);
-buflen = recvmsg(udev_monitor-sock, smsg, 0);
+buflen = recvmsg(udev_monitor-sock, smsg, MSG_CMSG_CLOEXEC);
if (buflen 0) {
if (errno != EINTR)
log_debug(unable to receive message);
diff --git a/src/machine/machine-dbus.c b/src/machine/machine-dbus.c
index b46f0a8..da8e6c0 100644
--- a/src/machine/machine-dbus.c
+++ b/src/machine/machine-dbus.c
@@ -255,7 +255,7 @@ int bus_machine_method_get_addresses(sd_bus *bus,
sd_bus_message *message, void
iov[0] = (struct iovec) { .iov_base = family, .iov_len =
sizeof(family) };
iov[1] = (struct iovec) { .iov_base = in_addr, .iov_len =
sizeof(in_addr) };
-n = recvmsg(pair[0], mh, 0);
+n = recvmsg(pair[0], mh, MSG_CMSG_CLOEXEC);
if (n 0)
return sd_bus_error_set_errno(error, -errno);
if ((size_t) n sizeof(family))
diff --git a/src/resolve/resolved-manager.c b/src/resolve/resolved-manager.c
index 890cc04..d5c1bf0 100644
--- a/src/resolve/resolved-manager.c
+++ b/src/resolve/resolved-manager.c
@@ -892,7 +892,7 @@ int manager_recv(Manager *m, int fd, DnsProtocol
protocol, DnsPacket
Re: [systemd-devel] suspend home server on idle / inactivity
On Mon, 09.02.15 21:52, Thomas Koch (tho...@koch.ro) wrote: first asked here: http://stackoverflow.com/questions/28399754 I've setup my home server to wake-on-lan and my router sends the wake-on-lan package when I try to access the server from anywhere. Now the server should also suspend again after like 5 minutes after - last disk activity - last network activity - and last considerable CPU load Can systemd solve this? Well, yes and no. We have idle detection in logind, and the system can be suspended or powered down automatically on idle. However, that idle logic is built around user interactive and idle locks. What we do not do is black magic stuff where we guess whether it might be OK to shutdown the machine due to some secondary indicators such as disk/network/cpu activity. And I am really not convinced that that's a good idea... Not a fan of heuristics I must say... The proper way to handle this would be to make daemons take idle locks whenever they are not idle. But I don't think it will be easy to convince a lot of daemons of this logic... Another option might be to extend systemd to allow marking certain services as implying an idle lock as long as they are running, and then teaching them exit-on-idle. But this would still require patching, to make them exit-on-idle. And getting this all into place in a race-free fashion is particualrly hard... Or the really short summary: if you want something quickly, then this needs to be done outside of the systemd context... 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 1/2] libsystemd-network: Avoid potential NULL dereference in test-lldp
On Sun, 08.02.15 22:21, Philippe De Swert (philippedesw...@gmail.com) wrote:
As a malloc0 could fail, doing a strncpy without checking could
cause issues. Adding an assert should be good enough and in line
with other similar routines in the code.
Thanks, applied.
Found with Coverity Fixes: CID#1261402
---
src/libsystemd-network/test-lldp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/libsystemd-network/test-lldp.c
b/src/libsystemd-network/test-lldp.c
index 288aac5..2e6bf14 100644
--- a/src/libsystemd-network/test-lldp.c
+++ b/src/libsystemd-network/test-lldp.c
@@ -166,6 +166,7 @@ static int lldp_parse_system_name_tlv(tlv_packet *m) {
assert_se(tlv_packet_read_string(m, str, length) = 0);
p = malloc0(length + 1);
+assert_se(p);
strncpy(p, str, length);
assert_se(streq(p, TEST_LLDP_TYPE_SYSTEM_NAME) == 1);
--
2.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
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] [systemd-commits] 4 commits - man/systemd.network.xml network/80-container-host0.network network/80-container-ve.network src/libsystemd src/network
On Mon, 09.02.15 03:20, Tom Gundersen (tome...@kemper.freedesktop.org) wrote: commit 7f77697a1744f8df2089848b9d718faf7ba6c665 Author: Tom Gundersen t...@jklm.no Date: Sun Feb 8 23:20:56 2015 +0100 networkd: add support for IPv6 tokens This allows the admin to set the host-specific part of IPv6 addresses, but still receive the prefix via SLAAC. This lacks a manpage update. In particular useful since the concept of Ipv6 tokens is relatively exotic, no? I mean, i never heard of this before... } + +int config_parse_token( That sounds overly generic ;-) networkd: generalize IPv4LL to LinkLocal This allows both IPv4 and IPv6 link-local addresses to be enabled or disabled. By default we still enable IPv6LL and disable IPv4LL. The old config option is kept for backwards compatibility, but removed from the documentation. diff --git a/man/systemd.network.xml b/man/systemd.network.xml index b8facdc..6c137e1 100644 --- a/man/systemd.network.xml +++ b/man/systemd.network.xml @@ -236,10 +236,12 @@ /listitem /varlistentry varlistentry - termvarnameIPv4LL=/varname/term + termvarnameLinkLocal=/varname/term Thinking about this, I am wondering if this shouldn't be called LinkLocalAddressing= or so? I mean, link-local is more like an adjective, which one could misunderstand? 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] pam_limits: Could not set limit for ...: Operation not permitted
В Tue, 10 Feb 2015 22:28:23 +0100 Kai Krakow hurikha...@gmail.com пишет: Lennart Poettering lenn...@poettering.net schrieb: On Tue, 10.02.15 20:16, Kai Krakow (hurikha...@gmail.com) wrote: Then the question is: Why or what does try to start a user session in the first place? I don't think KDE does this as it's not there yet (at least in KDE 4.x). And I didn't enable a user@...service (but shouldn't it work then when started from the normal service startups in systemd). logind maintains one user@.service instance per-user as long as she or he is logged in at least once. The service is basically ref-counted by the user's session. So, be patient with me until I fully understand it... I'm using kdm (previously lightdm but made no difference) to launch my KDE session. At some time in the process, the aforementioned messages get logged. As far as I can tell, logind is involved in this as it actually does spawn my graphical session. That in turn, according to your words, means: A user@.service for me should be launched (whether I need it or not). If this is true, I should see a systemd user instance in ps axuw, or simpler: Another systemd process except PID1 should be running. So far the outcome is: It doesn't but I instead see those error logs in the journal. Well, it fails at spawning it. What is the content of your limits.conf? Did you try to enable pam_limits debugging? I don't consider this a bug, but my main problem with this is I have no idea how to track that down. Do you have any weird kernel patch applied, something that is supposed to improve security or so? This is the plain Gentoo kernel 3.18.6 for desktop, nothing special except BFQ patches (applied by the Gentoo kernel package itself, not manually patched). I'm pretty sure Gentoo does not apply any special extra patches. Autogrouping for cgroups (SCHED_AUTOGROUP) is turned on - I'm not sure if it plays into the issue but from what I read it shouldn't. Maybe I should diff my kernel config with one that doesn't show this behaviour. Do you have one I should compare with? This is unrelated. The kernel RT cgroup API is really just awfully broken, ignore this. Maybe just turn off the RT_FIFO feature in the kernel for the time being? Nah, just ignore that log msg... I meant SCHED_OTHER/RR_FIFO, but I'll ignore that then. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Making udev emit a signal when it is done loading modules
On Wed, Jan 28, 2015 at 02:38:52AM +0100, Lennart Poettering wrote: To clarify this: if people do this, then this pulls in systemd-udev-settle.service, which slows down boot. Every service that does that is hence a majour source of slowness. It's a hack to use this, not a solution. Well, yes. There aren't really any good solutions with our event driven model - we never finish booting, we just get to a point where nothing has been happening for a while. I have been thinking that we need to just admit that properly and do something timer based - have a timer that gets reset every time we instantiate something, then do all our end of boot actions when nothing happened for a while. It's not elegant but I don't think elegant is a realistic goal here. 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] Removing unnecessary includes
On Tue, Feb 10, 2015 at 10:13 PM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 09.02.15 10:19, Thomas H.P. Andersen (pho...@gmail.com) wrote: include-what-you-use is actually pretty nice. It is also a little bit crazy. It wants to include everything directly and we would add a lot includes for errno.h, string.h, stdlib.h, stdbool.h, stddef.h, etc etc everywhere. It also wants to use forward declares when possible. The coding style does not say anything specific about this. Any preferences? I will use the tool to trim the unnecessary includes first and leave its other advise for later. It will be interesting to see how each step affects the build time. A feature is that I find interesting is that it can comment each include with the reason that it was included. Not something to commit, but useful to get an overview of why each include is there. Hmm, I find this unnecessary noise I must say... Well, for someone who is still learning it can be useful :) Getting that list of symbols actually used from each header adds some context and makes the includes feel less magic. Anyway, something to use on the fly but not to commit of course. There is an option to turn it off so that is not a problem. #include stdbool.h// for false, true, bool #include stddef.h // for offsetof, size_t #include stdint.h // for uint64_t #include string.h // for strdup, strlen #include config.h // for PACKAGE_STRING, #VERSION This one we get though -include config.h on the gcc command line. We can configure it to understand that. #include src/shared/macro.h // for assert, assert_cc, etc #include src/shared/path-lookup.h #include src/shared/time-util.h // for format_timespan, usec_t, etc #include src/systemd/sd-bus-protocol.h // for ::SD_BUS_TYPE_ARRAY Nah, please no absolute includes... Any chance this can turned off? I did not find any option for that but it is something to look into. The full include-list for src/analyze/analyze.c: #include errno.h // for EIO, ENOMEM, E2BIG, EINVAL, etc #include fnmatch.h// for fnmatch #include getopt.h // for optind, no_argument, optarg, etc #include locale.h // for NULL, setlocale, LC_ALL, etc #include stdbool.h// for false, true, bool #include stddef.h // for offsetof, size_t #include stdint.h // for uint64_t #include stdio.h // for printf, puts, fputs, stdout #include stdlib.h // for free, qsort, EXIT_FAILURE, etc #include string.h // for strdup, strlen #include analyze-verify.h // for verify_units #include build.h // for SYSTEMD_FEATURES #include bus-error.h // for bus_error_message #include bus-util.h // for UnitInfo, etc #include config.h // for PACKAGE_STRING, VERSION #include hashmap.h// for hashmap_get, Hashmap, etc #include log.h// for log_error, log_oom, etc #include pager.h // for pager_close, pager_open #include sd-bus.h // for sd_bus, SD_BUS_ERROR_NULL, etc #include special.h// for SPECIAL_DEFAULT_TARGET #include src/shared/macro.h // for assert, assert_cc, etc #include src/shared/path-lookup.h #include src/shared/time-util.h // for format_timespan, usec_t, etc #include src/systemd/sd-bus-protocol.h // for ::SD_BUS_TYPE_ARRAY #include strv.h // for strv_isempty, STRV_FOREACH, etc #include strxcpyx.h // for strpcpyf #include unit-name.h // for unit_dbus_path_from_name #include util.h // for isempty, streq, etc Note that I actually try to roughly maintain an order when including things: For the headers of other projects i try to put system headers first, 3rd party headers second. For our own stuff I try to put external API stuff first (i.e. sd-*.h), followed by internal API-like stuff form src/shared, and finally the other headers that are prviate to the specific module the code is in. I'd really like to avoid a scheme where this is reordered randomly... Understood. The include-what-you-use tool consists of two separate parts. The first is a program to scan the code and create a report of what to add and remove. The second part is a python script that reads the report and patches the source files. Perhaps the latter be extended to do what we need. The order kinda is relevant, since more local, specific definitions should never influence more public, generic interfaces, if you follow what I mean? A lot of header files use #ifndef, and only conditionally define things then. They should not get
