[systemd-devel] [PATCH] journal-remote: do not install tmpfiles and sysusers files by default
Change-Id: I5cbbcec134f52267ac4841b7d8f14d341a2d2184 Signed-off-by: Łukasz Stelmach l.stelm...@samsung.com --- Makefile.am | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/Makefile.am b/Makefile.am index 1674f61..cf21563 100644 --- a/Makefile.am +++ b/Makefile.am @@ -2036,7 +2036,6 @@ nodist_tmpfiles_DATA = \ dist_tmpfiles_DATA = \ tmpfiles.d/systemd.conf \ tmpfiles.d/systemd-nologin.conf \ - tmpfiles.d/systemd-remote.conf \ tmpfiles.d/tmp.conf \ tmpfiles.d/x11.conf \ tmpfiles.d/var.conf @@ -2091,8 +2090,7 @@ SYSINIT_TARGET_WANTS += \ systemd-sysusers.service dist_sysusers_DATA = \ - sysusers.d/systemd.conf \ - sysusers.d/systemd-remote.conf + sysusers.d/systemd.conf nodist_sysusers_DATA = \ sysusers.d/basic.conf @@ -3834,6 +3832,16 @@ systemd_journal_remote_CFLAGS = \ systemd_journal_remote_LDADD += \ $(MICROHTTPD_LIBS) +if ENABLE_SYSUSERS +dist_sysusers_DATA += \ + sysusers.d/systemd-remote.conf +endif + +if ENABLE_TMPFILES +dist_tmpfiles_DATA += \ + tmpfiles.d/systemd-remote.conf +endif + if HAVE_GNUTLS systemd_journal_remote_LDADD += \ $(GNUTLS_LIBS) -- 1.9.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] timesyncd: do not keep listening socket open forever
This also makes the source port less predicatable.
---
src/timesync/timesyncd-manager.c | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/src/timesync/timesyncd-manager.c b/src/timesync/timesyncd-manager.c
index 3ae01eb..03cfb24 100644
--- a/src/timesync/timesyncd-manager.c
+++ b/src/timesync/timesyncd-manager.c
@@ -132,6 +132,7 @@ struct ntp_msg {
static int manager_arm_timer(Manager *m, usec_t next);
static int manager_clock_watch_setup(Manager *m);
+static int manager_listen_setup(Manager *m);
static double ntp_ts_short_to_d(const struct ntp_ts_short *ts) {
return be16toh(ts-sec) + (be16toh(ts-frac) / 65536.0);
@@ -184,6 +185,14 @@ static int manager_send_request(Manager *m) {
m-event_timeout = sd_event_source_unref(m-event_timeout);
+if (m-server_socket 0) {
+r = manager_listen_setup(m);
+if (r 0) {
+log_warning(Failed to setup connection socket: %s,
strerror(-r));
+return r;
+}
+}
+
/*
* Set transmit timestamp, remember it; the server will send that back
* as the origin timestamp and we have an indication that this is the
@@ -250,7 +259,6 @@ static int manager_arm_timer(Manager *m, usec_t next) {
int r;
assert(m);
-assert(m-event_receive);
if (next == 0) {
m-event_timer = sd_event_source_unref(m-event_timer);
@@ -610,6 +618,10 @@ static int manager_receive_response(sd_event_source
*source, int fd, uint32_t re
m-pending = false;
m-retry_interval = 0;
+/* Stop listening */
+m-event_receive = sd_event_source_unref(m-event_receive);
+m-server_socket = safe_close(m-server_socket);
+
/* announce leap seconds */
if (NTP_FIELD_LEAP(ntpmsg.field) NTP_LEAP_PLUSSEC)
leap_sec = 1;
@@ -741,12 +753,6 @@ static int manager_begin(Manager *m) {
log_info(Using NTP server %s (%s)., strna(pretty),
m-current_server_name-string);
sd_notifyf(false, STATUS=Using Time Server %s (%s)., strna(pretty),
m-current_server_name-string);
-r = manager_listen_setup(m);
-if (r 0) {
-log_warning(Failed to setup connection socket: %s,
strerror(-r));
-return r;
-}
-
r = manager_clock_watch_setup(m);
if (r 0)
return r;
--
2.1.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Native Journal source vs syslog forwarding
Hi! I have an interesting situation here, which I'm trying to wrap my head around and solve. The problem is that I have a syslog daemon (syslog-ng 3.6.1) that has a native Journal source, meaning it can pull entries from the Journal directly, and does not need the syslog forwarding socket - and this is the default when running on a systemd-enabled machine. This works beautifully, except there's one problem: Nov 26 10:41:05 eowyn systemd-journal[14843]: Forwarding to syslog missed 1343 messages. On Debian, syslog forwarding is enabled by default, and since syslog-ng reads from the journal, there's nothing listening on /run/systemd/journal/syslog, and I get spammed with messages like the one above. I'm not sure how to solve this problem. As far as I see, I have the following options: 1) Drop the native journal source and use syslog forwarding. This is trivial to do, but I loose the extra fields and info the Journal collects. I'd rather not do this. 2) Have a dummy listener on /run/systemd/journal/syslog, that just reads everything and drops it on the floor. This sounds fishy, and is a bit awkward to implement in the config. This would also be an ugly hack, not a real solution. 3) Disable syslog forwarding if syslog-ng is installed Not sure how this could be achieved, because journald.conf does not belong to the syslog-ng package, therefore I can't fiddle its settings from there. (Technically, I could, but I won't, that'd be extremely rude.) I'd appreciate any hints. (Disabling syslog forwarding by default is not an option.) -- |8] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Native Journal source vs syslog forwarding
Gergely Nagy wrote on 26/11/14 10:04: 3) Disable syslog forwarding if syslog-ng is installed Not sure how this could be achieved, because journald.conf does not belong to the syslog-ng package, therefore I can't fiddle its settings from there. (Technically, I could, but I won't, that'd be extremely rude.) I think there were some patches recently that talked about added .d/ dir support for such config files. Thus syslog-ng could ship a /etc/systemd/journal.conf.d/syslog-ng.conf file which did this (or preferably a /usr/lib/systemd/journal.conf.d/syslog-ng.conf file so it follows best practice guidelines for stateless systems) See the patches by Josh Triplett: [PATCH 1/2] Introduce CONF_DIRS_NULSTR helper to define standard conf dirs [PATCH 2/2] logind: Support logind.conf.d directories in the usual search paths The latter patch just adds support in logind, but mentions the likes of journald too as further work if approved. I think this approach would solve your problem fairly cleanly. 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] Native Journal source vs syslog forwarding
On 11/26/2014 10:04 AM, Gergely Nagy wrote: Hi! I have an interesting situation here, which I'm trying to wrap my head around and solve. The problem is that I have a syslog daemon (syslog-ng 3.6.1) that has a native Journal source, meaning it can pull entries from the Journal directly, and does not need the syslog forwarding socket - and this is the default when running on a systemd-enabled machine. This works beautifully, except there's one problem: Nov 26 10:41:05 eowyn systemd-journal[14843]: Forwarding to syslog missed 1343 messages. This happens when the socket buffer is full for the syslogd which is being forwarding to. ( try tweaking those settings ) On Debian, syslog forwarding is enabled by default, and since syslog-ng reads from the journal, there's nothing listening on /run/systemd/journal/syslog, and I get spammed with messages like the one above. I'm not sure how to solve this problem. As far as I see, I have the following options: 1) Drop the native journal source and use syslog forwarding. This is trivial to do, but I loose the extra fields and info the Journal collects. I'd rather not do this. 2) Have a dummy listener on /run/systemd/journal/syslog, that just reads everything and drops it on the floor. This sounds fishy, and is a bit awkward to implement in the config. This would also be an ugly hack, not a real solution. 3) Disable syslog forwarding if syslog-ng is installed Not sure how this could be achieved, because journald.conf does not belong to the syslog-ng package, therefore I can't fiddle its settings from there. (Technically, I could, but I won't, that'd be extremely rude.) As of systemd 216 forwarding to another syslogd has been disabled by default so no need to fiddle with this setting. I'd appreciate any hints. (Disabling syslog forwarding by default is not an option.) Why is that not an option since there is nothing by your own account listening to /run/systemd/journal/syslog? JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Compatibility between D-Bus and kdbus
On Tue, 25.11.14 18:32, Thiago Macieira (thi...@kde.org) wrote: On Wednesday 26 November 2014 01:25:18 Lennart Poettering wrote: Thinking of non-system buses here. If the variable is empty, I agree that it should have an equivalent of an autostart mechanism, but I disagree on the solution and I also disagree that distros should leave it empty. Oh, no. No autostart please. No such concept exists in kdbus, and systemd/sd-bus will not support that either. In fact I refuse to support that even on dbus1 in sd-bus. Autostart is a kludge for systems where dbus is just an add-on, but that's completely out-of-focus for kdbus, systemd and sd-bus. I didn't actually mean automatically starting the bus, sorry for the confusion. I meant automatic discovery only. Currently on dbus1, autostart: as a transport protocol means both auto discovery and automatic starting if the bus isn't running. Please also note that the autostart solution has a valid use-case which is when a D-Bus application is launched in an environment where no bus had been started before. I understand this is out-of-scope for kdbus, since after all a regular user won't be able to create a kdbus bus if one wasn't provided by a privileged process before. In an environment where a kdbus bus wasn't provided, the only alternative is to fallback to dbus1. Hmm? Creating busses requires no privileges. Users create their own busses without requiring any kind of privilege for that. You are free to implement autostart behaviour for dbus1 in your own library, but this concept is not defined for kdbus. No, we don't support weird setups where kdbusfs mounted elsewhere. This is a bew API we introduce here, and we can very much make decisions where stuff is to be mounted. You may not support it in systemd, but from reading the kernel API that could happen with another implementation. Well, you can also mount /sys to /foobar and /proc to /waldo. No app supports that though and the place where kdbusfs is mounted is simply part of the kdbus API definition, and if you mount it anywhere else you get to keep the pieces. Note that we the kernel driver explicitly creates a dir /sys/fs/kdbus in order to have a place where to mount it. The location is really not configurable. We initially tried to support that, but it's awfully racy, since the driver calls and calls to other services wouldn't be executed in strict order anymore... We removed this again after figuring out and decided that emulation can only happen client side, synchronous to the message stream if we want to guarantee correct ordering. I'm not asking for AddMatch and connection control mechanisms. The one I really want is StartServiceByName, since it can't be emulated. Moreover, starting services is systemd's raison-d'être, so I feel it should be no problem for you to provide such a service. My recommendation for StartServiceByName() is to convert it into a Ping() method call to the respective service and wait for it to return. This is at least what the compat proxy does. It would be nice if UpdateActivationEnvironment worked. This functionality was added for people who need to update variables like XDG_DATA_DIRS after starting the bus. If this one isn't present, we can report not implemented and be fine with it. We'll just have to tell people to configure their systemd user session environments properly. The same goes for ReloadConfig, but I'd prefer to know whether that failed (no config reloading is possible) or whether it happens automatically whether the call was made or not. ReloadConfig is important when there are new activatable services on a user's bus, such as newly-installed applications. If you really want to support this, then call into systemd for it, and make it graceful to support non-systemd systems. Return a notsupported error if the systemd service is not reachable. The client side emulation can choose to either forward ReloadConifg and UpdateActivationEnvironment to the respect systemd calls, or just return som not supported error. Can't do that. What if it's a kdbus system that is not systemd? Well, again, return not supported then. I mean, currently there is no kdbus userspace implementation beyond kdbus, we cannot really discuss something that doesn't exist... I assume you meant beyond systemd there. Oops. Sorry, yes. Note that on dbus1 systemd systems we actually never provided UpdateActivationEnvironment correctly (since services got forked off PID 1, instead of dbus-daemon but the call would alter dbus-daemon's env block, not systemd's one), but nobody ever noticed. I really think you should just return some not supported error or make it a NOP if you don't want to pass this on to systemd. I *want* to pass this to systemd, somehow. So the first question is whether we can expect there to be a connection by systemd in
Re: [systemd-devel] Compatibility between D-Bus and kdbus
On Tue, 25.11.14 18:46, Thiago Macieira (thi...@kde.org) wrote: On Wednesday 26 November 2014 00:46:50 David Herrmann wrote: We had systemd-bus-driverd, which implemented org.freedesktop.DBus as normal service. However, this didn't work out as many dbus clients rely on this services to not be re-ordered in regard to external requests. In particular, if gdbus runs AddMatch(), it assumes the match takes effect immediately. If it sends a method call to another service after installing the match, and this triggers a signal, gdbus assumes the AddMatch() call to have succeeded (without waiting for the reply). However, if org.freedesktop.DBus is not implemented by the bus, but by an external service, you cannot guarantee that messages targetted at different receivers don't get re-ordered, and there're no guarantees which process gets scheduled first. This is a real bug and we couldn't figure out a way to fix it. Current DBus applications depend on org.freedesktop.DBus to be handled by the bus entity _in-order_. Therefore, we dropped systemd-bus-driverd and all the kdbus ioctls that we added to support this. Aside from the connection-control mechanisms (AddMatch, RemoveMatch), did you see any problems? It was primarily about that, but it is easy to construct races with this for most of the other driver calls as well. The race is very real btw. Because a frequent pattern is to establish a match, then invoke some method on some random service. However, with doing the driver in a separate service it might happen that the method call is processed before the driver finds the time to process the add match request. And then, any signals sent out by the service processing the method call might not be subject to the added match... User code usually shouldn't be doing AddMatch and RemoveMatch (the only case I can think of is dconf, which does its own parsing of the message payload). That's the domain of the binding, which will know that it connected to kdbus and won't be making those calls. Well, I am sure that in many cases apps want to install their own matches, beyond the object model of the used framework. For example, a graphical UI for systemd might want to subscribe to all of systemd's signals without actually matching on any specific object. Most framework object models don#t cover that. Or think of a tool like d-feet that wants to subscribe even more liberally, per service... Custom endpoints do _not_ create new buses. Really. You could create a custom bus and use it for just 2 connections, but then you could also just use socketpair(2). Note that there was some discussion on anonymous buses, which would allow to create such buses on the fly. But again, this will not be part of the initial kdbus draft. If anyone cares, submit it as patches once kdbus is upstream. As far as I can tell, an anonymous bus in the sense of a bus with a randomised name is doable by having the proper interface in the systemd1 system bus service. An application would request the bus and receive as a reply the address of the bus, the file descriptor for the control, and a file descriptor to a privileged connection so it can control the policies. No need to involve systemd. Creating additional busses requires no priviliges. You can just invoke the ioctls directly. 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] Native Journal source vs syslog forwarding
Jóhann == Jóhann B Guðmundsson johan...@gmail.com writes: Jóhann On 11/26/2014 10:04 AM, Gergely Nagy wrote: On Debian, syslog forwarding is enabled by default, and since syslog-ng reads from the journal, there's nothing listening on /run/systemd/journal/syslog, and I get spammed with messages like the one above. [...] 3) Disable syslog forwarding if syslog-ng is installed Not sure how this could be achieved, because journald.conf does not belong to the syslog-ng package, therefore I can't fiddle its settings from there. (Technically, I could, but I won't, that'd be extremely rude.) Jóhann As of systemd 216 forwarding to another syslogd has been disabled by Jóhann default so no need to fiddle with this setting. Forwarding is enabled by default on Debian, as I wrote in my original mail. I have no control over the default, and I have no desire to argue for changing it. There are other syslogds in Debian (including the default one) that do not read from the Journal, but rely on forwarding. If forwarding was turned off, they'd stop working. Older versions of syslog-ng would, too. -- |8] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Native Journal source vs syslog forwarding
Colin == Colin Guthrie gm...@colin.guthr.ie writes: Colin Gergely Nagy wrote on 26/11/14 10:04: 3) Disable syslog forwarding if syslog-ng is installed Not sure how this could be achieved, because journald.conf does not belong to the syslog-ng package, therefore I can't fiddle its settings from there. (Technically, I could, but I won't, that'd be extremely rude.) Colin I think there were some patches recently that talked about added .d/ Colin dir support for such config files. Thus syslog-ng could ship a Colin /etc/systemd/journal.conf.d/syslog-ng.conf file which did this (or Colin preferably a /usr/lib/systemd/journal.conf.d/syslog-ng.conf file so it Colin follows best practice guidelines for stateless systems) Thanks, this sounds like a good start! -- |8] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] logind: Support logind.conf.d directories in the usual search paths
Josh == Josh Triplett j...@joshtriplett.org writes: Josh This makes it possible to drop in logind configuration snippets from a Josh package or other configuration management mechanism. [...] Josh If this approach looks sensible, I'll send further patches for various Josh other tools with configuration files, such as journald and Josh timesyncd; I recently hit an issue where a journald.conf.d/ would have been incredibly useful. Any news on this patchset, by any chance? -- |8] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rpcbind: systemd socket activation (v2)
On 11/25/2014 05:40 PM, J. Bruce Fields wrote: On Tue, Nov 25, 2014 at 12:05:32PM -0500, Steve Dickson wrote: This is based on a patch originally posted by Lennart Poettering: http://permalink.gmane.org/gmane.linux.nfs/33774. Have you run this by the reporter of https://bugzilla.redhat.com/show_bug.cgi?id=1158164 ? Because he tried applying that old patch and found he was still having problems. But they may well be problems that are fixed by your version, or he may have applied it incorrectly, I didn't try to figure it out. If he was using the systemd scripts in the patch then there would be problems... which is the reason I eliminated them steved. --b. That patch was not merged due to the lack of a shared library and as systemd was seen to be too Fedora specific. Systemd now provides a shared library, and it is (or very soon will be) the default init system on all the major Linux distributions. This version of the patch has three changes from the original: * It uses the shared library. * It comes with unit files. * It is rebased on top of master. Please review the patch with git show -b or otherwise ignoring the whitespace changes, or it will be extremely difficult to read. v5: incorporated comments on the PKG_CHECK_MODULES macro. v4: reorganized the changes to make the diff easier to read remove systemd scripts. v3: rebase fix typos listen on /run/rpcbind.sock, rather than /var/run/rpcbind.sock (the latter is a symlink to the former, but this means the socket can be created before /var is mounted) NB: this version has been compile-tested only as I no longer use rpcbind myself v2: correctly enable systemd code at compile time handle the case where not all the required sockets were supplied listen on udp/tcp port 111 in addition to /var/run/rpcbind.sock do not daemonize Tom Gundersen (1): rpcbind: add support for systemd socket activation Makefile.am | 6 + configure.ac | 12 + src/rpcbind.c | 81 ++- 3 files changed, 93 insertions(+), 6 deletions(-) -- 1.9.3 -- To unsubscribe from this list: send the line unsubscribe linux-nfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-nfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rpcbind: add support for systemd socket activation
On 11/25/2014 12:05 PM, Steve Dickson wrote:
From: Tom Gundersen t...@jklm.no
Making rpcbind sockect activated will greatly simplify
its integration in systemd systems. In essence, other services
may now assume that rpcbind is always available, even during very
early boot. This means that we no longer need to worry about any
ordering dependencies.
Original-patch-by: Lennart Poettering lenn...@poettering.net
Cc: systemd-devel@lists.freedesktop.org
Acked-by: Cristian Rodríguezcrrodrig...@opensuse.org
Signed-off-by: Tom Gundersen t...@jklm.no
Signed-off-by: Steve Dickson ste...@redhat.com
Committed...
steved.
---
Makefile.am | 6 +
configure.ac | 12 +
src/rpcbind.c | 81
++-
3 files changed, 93 insertions(+), 6 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 8715082..c99566d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -41,6 +41,12 @@ rpcbind_SOURCES = \
src/warmstart.c
rpcbind_LDADD = $(TIRPC_LIBS)
+if SYSTEMD
+AM_CPPFLAGS += $(SYSTEMD_CFLAGS) -DSYSTEMD
+
+rpcbind_LDADD += $(SYSTEMD_LIBS)
+endif
+
rpcinfo_SOURCES = src/rpcinfo.c
rpcinfo_LDADD = $(TIRPC_LIBS)
diff --git a/configure.ac b/configure.ac
index 5a88cc7..967eb05 100644
--- a/configure.ac
+++ b/configure.ac
@@ -36,6 +36,18 @@ AC_SUBST([nss_modules], [$with_nss_modules])
PKG_CHECK_MODULES([TIRPC], [libtirpc])
+PKG_PROG_PKG_CONFIG
+AC_ARG_WITH([systemdsystemunitdir],
+ AS_HELP_STRING([--with-systemdsystemunitdir=DIR], [Directory for systemd
service files]),
+ [], [with_systemdsystemunitdir=$($PKG_CONFIG
--variable=systemdsystemunitdir systemd)])
+ if test x$with_systemdsystemunitdir != xno; then
+AC_SUBST([systemdsystemunitdir], [$with_systemdsystemunitdir])
+ PKG_CHECK_MODULES([SYSTEMD], [libsystemd], [],
+[PKG_CHECK_MODULES([SYSTEMD], [libsystemd-daemon], [],
+AC_MSG_ERROR([libsystemd support requested but found]))])
+ fi
+AM_CONDITIONAL(SYSTEMD, [test -n $with_systemdsystemunitdir -a
x$with_systemdsystemunitdir != xno ])
+
AS_IF([test x$enable_libwrap = xyes], [
AC_CHECK_LIB([wrap], [hosts_access], ,
AC_MSG_ERROR([libwrap support requested but unable to find
libwrap]))
diff --git a/src/rpcbind.c b/src/rpcbind.c
index e3462e3..f7c71ee 100644
--- a/src/rpcbind.c
+++ b/src/rpcbind.c
@@ -56,6 +56,9 @@
#include netinet/in.h
#endif
#include arpa/inet.h
+#ifdef SYSTEMD
+#include systemd/sd-daemon.h
+#endif
#include fcntl.h
#include netdb.h
#include stdio.h
@@ -296,6 +299,7 @@ init_transport(struct netconfig *nconf)
u_int32_t host_addr[4]; /* IPv4 or IPv6 */
struct sockaddr_un sun;
mode_t oldmask;
+ int n;
res = NULL;
if ((nconf-nc_semantics != NC_TPI_CLTS)
@@ -314,6 +318,76 @@ init_transport(struct netconfig *nconf)
fprintf(stderr, [%d] - %s\n, i, *s);
}
#endif
+ if (!__rpc_nconf2sockinfo(nconf, si)) {
+ syslog(LOG_ERR, cannot get information for %s,
+ nconf-nc_netid);
+ return (1);
+ }
+
+#ifdef SYSTEMD
+ n = sd_listen_fds(0);
+ if (n 0) {
+ syslog(LOG_ERR, failed to acquire systemd sockets: %s,
strerror(-n));
+ return 1;
+ }
+
+ /* Try to find if one of the systemd sockets we were given match
+ * our netconfig structure. */
+
+ for (fd = SD_LISTEN_FDS_START; fd SD_LISTEN_FDS_START + n; fd++) {
+ struct __rpc_sockinfo si_other;
+ union {
+ struct sockaddr sa;
+ struct sockaddr_un un;
+ struct sockaddr_in in4;
+ struct sockaddr_in6 in6;
+ struct sockaddr_storage storage;
+ } sa;
+ socklen_t addrlen = sizeof(sa);
+
+ if (!__rpc_fd2sockinfo(fd, si_other)) {
+ syslog(LOG_ERR, cannot get information for fd %i, fd);
+ return 1;
+ }
+
+ if (si.si_af != si_other.si_af ||
+si.si_socktype != si_other.si_socktype ||
+si.si_proto != si_other.si_proto)
+ continue;
+
+ if (getsockname(fd, sa.sa, addrlen) 0) {
+ syslog(LOG_ERR, failed to query socket name: %s,
+ strerror(errno));
+ goto error;
+ }
+
+ /* Copy the address */
+ taddr.addr.maxlen = taddr.addr.len = addrlen;
+ taddr.addr.buf = malloc(addrlen);
+ if (taddr.addr.buf == NULL) {
+ syslog(LOG_ERR,
+ cannot allocate memory for %s address,
+ nconf-nc_netid);
+ goto error;
+ }
+
Re: [systemd-devel] Native Journal source vs syslog forwarding
On 11/26/2014 12:07 PM, Gergely Nagy wrote: Jóhann == Jóhann B Guðmundsson johan...@gmail.com writes: Jóhann On 11/26/2014 10:04 AM, Gergely Nagy wrote: On Debian, syslog forwarding is enabled by default, and since syslog-ng reads from the journal, there's nothing listening on /run/systemd/journal/syslog, and I get spammed with messages like the one above. [...] 3) Disable syslog forwarding if syslog-ng is installed Not sure how this could be achieved, because journald.conf does not belong to the syslog-ng package, therefore I can't fiddle its settings from there. (Technically, I could, but I won't, that'd be extremely rude.) Jóhann As of systemd 216 forwarding to another syslogd has been disabled by Jóhann default so no need to fiddle with this setting. Forwarding is enabled by default on Debian, as I wrote in my original mail. I have no control over the default, and I have no desire to argue for changing it. There are other syslogds in Debian (including the default one) that do not read from the Journal, but rely on forwarding. If forwarding was turned off, they'd stop working. Older versions of syslog-ng would, too. Right but you are going against downstream distribution policy and unwilling yourself ( or have the consumer of the syslog-ng package do that ) to change the default manually ( via journald.conf ) or advocate for that change ( which would be simply advocating for following upstream ). If you are the syslog-ng maintainer in Debian then I guess you will have to introduce conflicts with other sysloggers in other components and have them remove the default syslogger ( assuming the journal has not been made the default yet in Debian and something like rsyslog is ) because if you go the snipped route you would overwrite the default thus break rsyslog ( and others if they exist ) in the process. What is Jessie using 215? if so you are probably stuck with 215 for the reminder of Jessie which requires you to convince the Debian systemd maintainers to backport the relevant patch(es) to make that work. Does Debian have two syslog-ng components one tweak for journal as in uses systemd-journal() along with filters and default journal tweaked send declaration and another one that is tweaked for $other systemd init systems since there are more tweaks than just systemd-journal() which should be made as an default in that process? Or is there a single component that detects which init system is installed and install configuration files based on that? ( if so could he not simply s/ForwardToSyslog=/ from yes to no in the process? ) JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Compatibility between D-Bus and kdbus
On 25/11/14 23:46, David Herrmann wrote: In particular, if gdbus runs AddMatch(), it assumes the match takes effect immediately. If it sends a method call to another service after installing the match, and this triggers a signal, gdbus assumes the AddMatch() call to have succeeded (without waiting for the reply). Argument in favour of this being sane: if AddMatch() failed, what would it do about it? The only error that can happen without programmer error is running out of match rule slots, which can't be recovered from in traditional D-Bus (but now that https://code.google.com/p/d-bus/issues/detail?id=10 has been fixed, kdbus *can* recover). I strongly recommend to either drop support for org.freedesktop.DBus on any kdbus-aware DBus APIs, or fake it in the library. sd-bus doesn't support it, and IIRC Ryan didn't want to fake it in gdbus either. For sd-bus, a new and non-API-stable library, that's reasonable. For existing libraries, this sounds like an argument in favour of having a separate DBUS_BUS_SESSION_KDBUS (or whatever you want to call it, but basically it means allowed to be kdbus), to be able to opt-in to potentially breaking changes: lack of ACLs (definitely a breaking change on the system bus but arguably not a breaking change on the session bus), and lack of support for direct o.fd.DBus calls (a breaking change on both buses). There are several o.fd.DBus calls for which libdbus doesn't have high-level API at all, so libdbus users have no option but to use direct calls. GDBus might be more complete in that respect? S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: remove --gc-sections to fix debugging
(cc'ing Zbigniew because he introduced gold, cc'ing Gustavo because he added --gc-sections) On Monday 24 November 2014 20:00:58 Peter Wu wrote: The --gc-sections linker option triggers a bug in the gold linker[1] which results in a bogus .eh_frame section making debugging harder: gdb backtraces stop at a library built by systemd and libunwind simply segfaults. Workaround by that bug by removing the option. The additional disk space saved by this option is marginal anyway (less than 1%). To illustrate this, see this `du -ks` on the installed files: 83548 without-gc-sections/install 83432 with-gc-sections/install 25796 without-gc-sections/install-strip 25752 with-gc-sections/install-strip The above tests were done with binutils 2.24-8 on Arch Linux x86_64 (installation media, so a pretty pristine packages list). Meanwhile the bug has been fixed in binutils git (which will also end up in binutils 2.25). The numbers for binutils commit c924eb67e143722e4098d84c1cb91123a51c988f (Fix corrupted .eh_frame section with LTO and --gc-sections.) and the same configure options: 84024 new-binutils-without-gc-sections/install 83988 new-binutils-with-gc-sections/install 26384 new-binutils-without-gc-sections/install-strip 26380 new-binutils-with-gc-sections/install-strip For clarity on how I got these numbers, I ran 'makepkg' to build systemd (based on 217-7), then executed 'make install(-strip) DESTDIR=$PWD/fs' and counted the size with `du -sk`. The gains were pretty small, so what about removing the option and improve the debugging experience? [1]: https://sourceware.org/bugzilla/show_bug.cgi?id=17639 https://bugs.freedesktop.org/show_bug.cgi?id=8 --- configure.ac | 1 - 1 file changed, 1 deletion(-) diff --git a/configure.ac b/configure.ac index bd3cc0e..8d926be 100644 --- a/configure.ac +++ b/configure.ac @@ -219,7 +219,6 @@ AC_SUBST([OUR_CPPFLAGS], $with_cppflags $sanitizer_cppflags) CC_CHECK_FLAGS_APPEND([with_ldflags], [LDFLAGS], [\ -Wl,--as-needed \ -Wl,--no-undefined \ --Wl,--gc-sections \ -Wl,-z,relro \ -Wl,-z,now \ -pie \ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] add configuration for smackfs root
The smackfs root was changed few month ago. But some of systems are
still using old smackfs root. For compatibility, add smackfs root
configure option. Default is /sys/fs/smackfs.
---
Makefile.am | 1 +
configure.ac| 7 +++
src/core/mount-setup.c | 2 +-
src/core/smack-setup.c | 4 ++--
src/shared/smack-util.c | 2 +-
5 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index b52ff8e..c91c1b7 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -192,6 +192,7 @@ AM_CPPFLAGS = \
-DUDEVLIBEXECDIR=\$(udevlibexecdir)\ \
-DPOLKIT_AGENT_BINARY_PATH=\$(bindir)/pkttyagent\ \
-DQUOTACHECK=\$(QUOTACHECK)\ \
+ -DSMACKFSROOT=\$(SMACKFSROOT)\ \
-DKEXEC=\$(KEXEC)\ \
-DLIBDIR=\$(libdir)\ \
-DROOTLIBDIR=\$(rootlibdir)\ \
diff --git a/configure.ac b/configure.ac
index a4e91e3..97cd5ad 100644
--- a/configure.ac
+++ b/configure.ac
@@ -661,6 +661,13 @@ AS_HELP_STRING([--with-smack-run-label=STRING],
[AC_DEFINE_UNQUOTED(SMACK_RUN_LABEL, [$withval], [Run with a smack
label])],
[])
+AC_ARG_WITH(smackfs-root,
+AS_HELP_STRING([--with-smackfs-root=PATH],
+[Specify the smackfs root [/sys/fs/smackfs]]),
+[SMACKFSROOT=$withval],
+[SMACKFSROOT=/sys/fs/smackfs])
+AC_SUBST(SMACKFSROOT)
+
if test x${have_smack} = xyes ; then
AC_DEFINE(HAVE_SMACK, 1, [Define if SMACK is available])
fi
diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
index df9d9da..01fed83 100644
--- a/src/core/mount-setup.c
+++ b/src/core/mount-setup.c
@@ -81,7 +81,7 @@ static const MountPoint mount_table[] = {
{ securityfs, /sys/kernel/security, securityfs, NULL,
MS_NOSUID|MS_NOEXEC|MS_NODEV,
NULL, MNT_NONE },
#ifdef HAVE_SMACK
-{ smackfs,/sys/fs/smackfs, smackfs,
smackfsdef=*, MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_STRICTATIME,
+{ smackfs,SMACKFSROOT, smackfs,
smackfsdef=*, MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_STRICTATIME,
mac_smack_use, MNT_FATAL },
{ tmpfs, /dev/shm, tmpfs,
mode=1777,smackfsroot=*, MS_NOSUID|MS_NODEV|MS_STRICTATIME,
mac_smack_use, MNT_FATAL },
diff --git a/src/core/smack-setup.c b/src/core/smack-setup.c
index d0fd180..b81d76f 100644
--- a/src/core/smack-setup.c
+++ b/src/core/smack-setup.c
@@ -124,7 +124,7 @@ int mac_smack_setup(bool *loaded_policy) {
assert(loaded_policy);
-r = write_rules(/sys/fs/smackfs/load2, SMACK_CONFIG);
+r = write_rules(SMACKFSROOT /load2, SMACK_CONFIG);
switch(r) {
case -ENOENT:
log_debug(Smack is not enabled in the kernel.);
@@ -148,7 +148,7 @@ int mac_smack_setup(bool *loaded_policy) {
SMACK_RUN_LABEL, strerror(-r));
#endif
-r = write_rules(/sys/fs/smackfs/cipso2, CIPSO_CONFIG);
+r = write_rules(SMACKFSROOT /cipso2, CIPSO_CONFIG);
switch(r) {
case -ENOENT:
log_debug(Smack/CIPSO is not enabled in the kernel.);
diff --git a/src/shared/smack-util.c b/src/shared/smack-util.c
index b6c9643..551a234 100644
--- a/src/shared/smack-util.c
+++ b/src/shared/smack-util.c
@@ -36,7 +36,7 @@ bool mac_smack_use(void) {
static int cached_use = -1;
if (cached_use 0)
-cached_use = access(/sys/fs/smackfs/, F_OK) = 0;
+cached_use = access(SMACKFSROOT, F_OK) = 0;
return cached_use;
#else
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: remove --gc-sections to fix debugging
On Wed, Nov 26, 2014 at 03:28:15PM +0100, Peter Wu wrote: (cc'ing Zbigniew because he introduced gold, cc'ing Gustavo because he added --gc-sections) On Monday 24 November 2014 20:00:58 Peter Wu wrote: The --gc-sections linker option triggers a bug in the gold linker[1] which results in a bogus .eh_frame section making debugging harder: gdb backtraces stop at a library built by systemd and libunwind simply segfaults. Workaround by that bug by removing the option. The additional disk space saved by this option is marginal anyway (less than 1%). To illustrate this, see this `du -ks` on the installed files: 83548 without-gc-sections/install 83432 with-gc-sections/install 25796 without-gc-sections/install-strip 25752 with-gc-sections/install-strip The above tests were done with binutils 2.24-8 on Arch Linux x86_64 (installation media, so a pretty pristine packages list). Meanwhile the bug has been fixed in binutils git (which will also end up in binutils 2.25). The numbers for binutils commit c924eb67e143722e4098d84c1cb91123a51c988f (Fix corrupted .eh_frame section with LTO and --gc-sections.) and the same configure options: 84024 new-binutils-without-gc-sections/install 83988 new-binutils-with-gc-sections/install 26384 new-binutils-without-gc-sections/install-strip 26380 new-binutils-with-gc-sections/install-strip For clarity on how I got these numbers, I ran 'makepkg' to build systemd (based on 217-7), then executed 'make install(-strip) DESTDIR=$PWD/fs' and counted the size with `du -sk`. The gains were pretty small, so what about removing the option and improve the debugging experience? I'm okay with the change to remove gc-sections. systemd is pretty good at not leaving crap in its code, then results are pretty small as we saw. My only comment is that we should also remove: -ffunction-sections -fdata-sections those are only useful to enable gc-sections. From time to time someone should run a build with -ffunction-sections -fdata-sections -Wl,--gc-sections -Wl,--print-gc-sections so we print out sections that are dangling and then we could remove them from source code if needed. BR, -- Gustavo Sverzut Barbieri Intel Open source Technology Center ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: remove --gc-sections to fix debugging
2014-11-26 18:16 GMT+01:00 Gustavo Sverzut Barbieri gustavo.barbi...@intel.com: My only comment is that we should also remove: -ffunction-sections -fdata-sections those are only useful to enable gc-sections. From time to time someone should run a build with -ffunction-sections -fdata-sections -Wl,--gc-sections -Wl,--print-gc-sections so we print out sections that are dangling and then we could remove them from source code if needed. Could we add them to autogen.sh so it's used by the developers? After all, we already set quite a few CFLAGS in autogen.sh. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: remove --gc-sections to fix debugging
On Wed, 26.11.14 15:16, Gustavo Sverzut Barbieri (gustavo.barbi...@intel.com) wrote: I'm okay with the change to remove gc-sections. systemd is pretty good at not leaving crap in its code, then results are pretty small as we saw. My only comment is that we should also remove: -ffunction-sections -fdata-sections those are only useful to enable gc-sections. From time to time someone should run a build with -ffunction-sections -fdata-sections -Wl,--gc-sections -Wl,--print-gc-sections so we print out sections that are dangling and then we could remove them from source code if needed. This is not that simple. We have a large set of shared functions in src/shared/*.c, and we link that into pretty much any binary we build, even though each binary only needs a small subset of them. We rely on the GC logic to deal with this and remove the functions that are unused by the specific program. Howver, that is not an indication that we can remove the function, that's simply an indication that that one binary of the 90 or so we build doesn't need it. Other binaries might need it still, but print-gc-sections won't tell you about that. 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] build-sys: remove --gc-sections to fix debugging
On Wed, Nov 26, 2014 at 06:27:45PM +0100, Michael Biebl wrote: 2014-11-26 18:16 GMT+01:00 Gustavo Sverzut Barbieri gustavo.barbi...@intel.com: My only comment is that we should also remove: -ffunction-sections -fdata-sections those are only useful to enable gc-sections. From time to time someone should run a build with -ffunction-sections -fdata-sections -Wl,--gc-sections -Wl,--print-gc-sections so we print out sections that are dangling and then we could remove them from source code if needed. Could we add them to autogen.sh so it's used by the developers? After all, we already set quite a few CFLAGS in autogen.sh. It's something that is quite annoying, then I'd not add. Maybe to make distcheck via DISTCHECK_CONFIGURE_FLAGS? -- Gustavo Sverzut Barbieri Intel Open source Technology Center ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: remove --gc-sections to fix debugging
On Wed, Nov 26, 2014 at 06:33:31PM +0100, Lennart Poettering wrote: On Wed, 26.11.14 15:16, Gustavo Sverzut Barbieri (gustavo.barbi...@intel.com) wrote: I'm okay with the change to remove gc-sections. systemd is pretty good at not leaving crap in its code, then results are pretty small as we saw. My only comment is that we should also remove: -ffunction-sections -fdata-sections those are only useful to enable gc-sections. From time to time someone should run a build with -ffunction-sections -fdata-sections -Wl,--gc-sections -Wl,--print-gc-sections so we print out sections that are dangling and then we could remove them from source code if needed. This is not that simple. We have a large set of shared functions in src/shared/*.c, and we link that into pretty much any binary we build, even though each binary only needs a small subset of them. We rely on the GC logic to deal with this and remove the functions that are unused by the specific program. Howver, that is not an indication that we can remove the function, that's simply an indication that that one binary of the 90 or so we build doesn't need it. Other binaries might need it still, but print-gc-sections won't tell you about that. For shared libraries it won't remove exported (visible) symbols. Only stuff (functions, variables) that have not reference are removed. Of course those local to a file (ie: static) are always eliminated, that's why we see minor benefit with gc-sections as the major bulk are marked as static. As I said, if the functions are exported (visibility=default), then they are not GC, what leaves us to extern symbols, those that are visible across files but not exported in the elf. -- Gustavo Sverzut Barbieri Intel Open source Technology Center ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Compatibility between D-Bus and kdbus
On Wednesday 26 November 2014 12:27:16 Lennart Poettering wrote: Please also note that the autostart solution has a valid use-case which is when a D-Bus application is launched in an environment where no bus had been started before. I understand this is out-of-scope for kdbus, since after all a regular user won't be able to create a kdbus bus if one wasn't provided by a privileged process before. In an environment where a kdbus bus wasn't provided, the only alternative is to fallback to dbus1. Hmm? Creating busses requires no privileges. Users create their own busses without requiring any kind of privilege for that. How is that secure? That would imply that any process, with any UID, can issue KDBUS_CMD_BUS_MAKE for a bus name that another UID would expect to use. I must be misunderstanding something. My recommendation for StartServiceByName() is to convert it into a Ping() method call to the respective service and wait for it to return. This is at least what the compat proxy does. Hmm... I had forgotten about Ping(). That sounds like a solution. It would be nice if UpdateActivationEnvironment worked. This functionality was added for people who need to update variables like XDG_DATA_DIRS after starting the bus. If this one isn't present, we can report not implemented and be fine with it. We'll just have to tell people to configure their systemd user session environments properly. The same goes for ReloadConfig, but I'd prefer to know whether that failed (no config reloading is possible) or whether it happens automatically whether the call was made or not. ReloadConfig is important when there are new activatable services on a user's bus, such as newly-installed applications. If you really want to support this, then call into systemd for it, and make it graceful to support non-systemd systems. Return a notsupported error if the systemd service is not reachable. Well, that's exactly what I want, but see below. Note that on dbus1 systemd systems we actually never provided UpdateActivationEnvironment correctly (since services got forked off PID 1, instead of dbus-daemon but the call would alter dbus-daemon's env block, not systemd's one), but nobody ever noticed. I really think you should just return some not supported error or make it a NOP if you don't want to pass this on to systemd. I *want* to pass this to systemd, somehow. So the first question is whether we can expect there to be a connection by systemd in the buses it creates. On the system bus, there's org.freedesktop.systemd1 so I expect that to continue. Can we expect a similar service on systemd-user buses? Yes. systemd creates the bus and then acquires org.freedesktop.systemd1 on it, and does this for both the system and the user bus the same way. My argument was for a more generic name, such as something in the org.freedesktop.DBus hierarchy. That way, if someone else wants to provide kdbus-powered buses, they'd implement that interface instead of trying to emulate systemd and playing catch-up and possibly bug compatibility. Further, if it does acquire the org.freedesktop.DBus name itself, libraries won't have to emulate most of the compat behaviour by intercepting outgoing messages. Intercepting means EVERY message needs to be inspected at one point or another, instead of letting it fallback when the call actually happens. In other words, providing a fallback service optimises for the right use-case. Since systemd will connect to the bus anyway and will acquire a name, it can acquire another. When creating the bus the creator can pass policy to the kernel so that there is no time window where the bus is accessible and open to manipulation from untrusted clients. How can you update the policies then? There's an ioctl for that too, that the creator can then call on the fd it has open. I guess I got confused by the wording of what you can do with what file descriptors. I was under the impression that you'd need three file descriptors for a bus or an endpoint to make any useful use 1) one fd that opened the control file (to create a bus) or to the bus (to create the endpoint) 2) one fd that you'll want to open the bus/endpoint on so you can later send updates to the policies 3) one fd to actually do talking on My confusion was that the doc says that after CMD_xxx_MAKE the file descriptor can't be used again. 5.3 says ... is file descriptor will manage the newly created endpoint resource. It cannot be used to manage further resources. I guess I read further resources as including changing policies on this bus/endpoint. Thanks for the clarification. I recommend adding a section on what steps to do to create a bus (including setting up policies, activators), one on creating an endpoint, and then one on how a controlling process should operate to manage the bus/endpoint properly. What's the usecase? I mean
Re: [systemd-devel] Compatibility between D-Bus and kdbus
On Wed, 26.11.14 10:04, Thiago Macieira (thi...@kde.org) wrote: On Wednesday 26 November 2014 12:27:16 Lennart Poettering wrote: Please also note that the autostart solution has a valid use-case which is when a D-Bus application is launched in an environment where no bus had been started before. I understand this is out-of-scope for kdbus, since after all a regular user won't be able to create a kdbus bus if one wasn't provided by a privileged process before. In an environment where a kdbus bus wasn't provided, the only alternative is to fallback to dbus1. Hmm? Creating busses requires no privileges. Users create their own busses without requiring any kind of privilege for that. How is that secure? That would imply that any process, with any UID, can issue KDBUS_CMD_BUS_MAKE for a bus name that another UID would expect to use. I must be misunderstanding something. The kernel enforces that each bus name is prefixed with $UID-. This is why the system bus is /sys/fs/kdbus/0-system rather than just /sys/fs/kdbus/system. This makes sure that users cannot play games with other users. Note that on dbus1 systemd systems we actually never provided UpdateActivationEnvironment correctly (since services got forked off PID 1, instead of dbus-daemon but the call would alter dbus-daemon's env block, not systemd's one), but nobody ever noticed. I really think you should just return some not supported error or make it a NOP if you don't want to pass this on to systemd. I *want* to pass this to systemd, somehow. So the first question is whether we can expect there to be a connection by systemd in the buses it creates. On the system bus, there's org.freedesktop.systemd1 so I expect that to continue. Can we expect a similar service on systemd-user buses? Yes. systemd creates the bus and then acquires org.freedesktop.systemd1 on it, and does this for both the system and the user bus the same way. My argument was for a more generic name, such as something in the org.freedesktop.DBus hierarchy. That way, if someone else wants to provide kdbus-powered buses, they'd implement that interface instead of trying to emulate systemd and playing catch-up and possibly bug compatibility. I am really not keen in defining a new abstract bus interface for two functions of which at least one is very questionnable anyway, and where it's not clear that there will ever be a second implementation of... I mean, the two operations are not even really abstractable since both the update-env stuff and the reload stuff have different semantics on systemd: they are much more comprehensive and apply to all services at once instead of just the bus services. I mean, it sounds OK to me to pass this to systemd for compat reasons in a quirky way. But it if we define an abstract, well-defined, standardized interface for this with inherently unclean semantics this is really nothing I want to do. Further, if it does acquire the org.freedesktop.DBus name itself, libraries won't have to emulate most of the compat behaviour by intercepting outgoing messages. Intercepting means EVERY message needs to be inspected at one point or another, instead of letting it fallback when the call actually happens. In other words, providing a fallback service optimises for the right use-case. This kind of half/half solution sounds messy to me. Either emulate it or don't. But having some of the calls emulated on the client-side and some elsewhere sounds messy. There's an ioctl for that too, that the creator can then call on the fd it has open. I guess I got confused by the wording of what you can do with what file descriptors. I was under the impression that you'd need three file descriptors for a bus or an endpoint to make any useful use 1) one fd that opened the control file (to create a bus) or to the bus (to create the endpoint) 2) one fd that you'll want to open the bus/endpoint on so you can later send updates to the policies 3) one fd to actually do talking on My confusion was that the doc says that after CMD_xxx_MAKE the file descriptor can't be used again. 5.3 says ... is file descriptor will manage the newly created endpoint resource. It cannot be used to manage further resources. I guess I read further resources as including changing policies on this bus/endpoint. Thanks for the clarification. I recommend adding a section on what steps to do to create a bus (including setting up policies, activators), one on creating an endpoint, and then one on how a controlling process should operate to manage the bus/endpoint properly. To create a bus you open the control file, issue an ioctl (MAKE_BUS) on the fd, and the fd is then *converted* into a reference to the bus. You can use it then only for updating policy and for eventually closing it to make the bus go away. To create a bus connection you open the bus file,
[systemd-devel] [PATCH v2] build-sys: remove --gc-sections to fix debugging
The `--gc-sections` linker option triggers a bug in the gold linker[1] (binutils 2.24 or older). This results in a bogus .eh_frame section making debugging harder: gdb backtraces stop at a library built by systemd and libunwind simply segfaults because it does not check for garbage values. Workaround that bug by removing `-Wl,--gc-sections`. Also remove `-fdata-sections` and `-ffunction-sections` as suggested by Gustavo Sverzut Barbieri. There is no benefit in creating separate sections for each function or data item if unused sections are not removed. The additional disk space saved by this option is marginal anyway (less than 1%). To illustrate this, see this `du -ks` on the installed files (where `-Wl,--gc-sections` is removed): 83548 broken-binutils-without-gc-sections/install 83432 broken-binutils-with-gc-sections/install 25796 broken-binutils-without-gc-sections/install-strip 25752 broken-binutils-with-gc-sections/install-strip 84024 binutils-master-without-gc-sections/install 83988 binutils-master-with-gc-sections/install 26384 binutils-master-without-gc-sections/install-strip 26380 binutils-master-with-gc-sections/install-strip [1]: https://sourceware.org/bugzilla/show_bug.cgi?id=17639 https://bugs.freedesktop.org/show_bug.cgi?id=8 --- v2:removed -ffunction-sections and -fdata-sections too, mention that binutils fixed the bug. --- configure.ac | 3 --- 1 file changed, 3 deletions(-) diff --git a/configure.ac b/configure.ac index bd3cc0e..baba072 100644 --- a/configure.ac +++ b/configure.ac @@ -191,8 +191,6 @@ CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [\ -fdiagnostics-show-option \ -fno-strict-aliasing \ -fvisibility=hidden \ --ffunction-sections \ --fdata-sections \ -fstack-protector \ -fstack-protector-strong \ -fPIE \ @@ -219,7 +217,6 @@ AC_SUBST([OUR_CPPFLAGS], $with_cppflags $sanitizer_cppflags) CC_CHECK_FLAGS_APPEND([with_ldflags], [LDFLAGS], [\ -Wl,--as-needed \ -Wl,--no-undefined \ --Wl,--gc-sections \ -Wl,-z,relro \ -Wl,-z,now \ -pie \ -- 1.9.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Compatibility between D-Bus and kdbus
On Wed, 26.11.14 10:10, Thiago Macieira (thi...@kde.org) wrote: On Wednesday 26 November 2014 12:35:33 Lennart Poettering wrote: Aside from the connection-control mechanisms (AddMatch, RemoveMatch), did you see any problems? It was primarily about that, but it is easy to construct races with this for most of the other driver calls as well. [snip] Can you explain, if you remember, how the race could happen for the other driver calls? Is this one: GetConnectionUnixProcessID could return stale information because the process has exited by the time that the reply arrived. If so, this race already existed in dbus1. Here's are two examples: First: AcquireName(): you issue issue an async request for acquiring foo.bar, and immediately send a message to it. On dbus1 this will work: the bus will first process the AcquireName(), and then deliver the message back to you given that you now have the name. In a kdbus design with an extern driver process the AcquireName() call would be passed to the driver, and the next message most likely be processed before the driver processes it, thus most likely resulting in a delivery failure of the second message. Now, that's the reason why acquirename/releasename need to be implemented client side. With that knowledge we can punch holes in the other calls too. For example, the GetConnectionUnixProcessID() call you brought up: let's now issue a GetConnectionUnixProcessID() async first, immediately followed by an AcquireName() for the same name. On dbus this will tell you the old owner, and then acquire the name for you. On kdbus with an external driver this would be different though. While the GetConnecitonUnixProcessID() is queued and waiting to be processed the AcquireName() might already have been executed (because it needs to be an ioctl as we have shown above), hence you would get your own PID returned, not the old one! hence, this calls really should be sync local ioctl()s, not half-half... 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] Compatibility between D-Bus and kdbus
On Wednesday 26 November 2014 19:30:16 Lennart Poettering wrote: I must be misunderstanding something. The kernel enforces that each bus name is prefixed with $UID-. This is why the system bus is /sys/fs/kdbus/0-system rather than just /sys/fs/kdbus/system. This makes sure that users cannot play games with other users. Thanks for the clarification. That tidbit is nowhere in the kdbus.txt docs. It should probably be mentioned in the section about creating buses. Also, shouldn't CAP_IPC_OWNER-privileged processes be able to create a bus with an arbitrary name? My argument was for a more generic name, such as something in the org.freedesktop.DBus hierarchy. That way, if someone else wants to provide kdbus-powered buses, they'd implement that interface instead of trying to emulate systemd and playing catch-up and possibly bug compatibility. I am really not keen in defining a new abstract bus interface for two functions of which at least one is very questionnable anyway, and where it's not clear that there will ever be a second implementation of... I understand that reluctance. I mean, the two operations are not even really abstractable since both the update-env stuff and the reload stuff have different semantics on systemd: they are much more comprehensive and apply to all services at once instead of just the bus services. I mean, it sounds OK to me to pass this to systemd for compat reasons in a quirky way. But it if we define an abstract, well-defined, standardized interface for this with inherently unclean semantics this is really nothing I want to do. Well, whatever it is, we need a sane API. I'm willing to standardise on the systemd behaviour if the current one is quirky anyway. If we do that, we'll need a new interface name anyway. Further, if it does acquire the org.freedesktop.DBus name itself, libraries won't have to emulate most of the compat behaviour by intercepting outgoing messages. Intercepting means EVERY message needs to be inspected at one point or another, instead of letting it fallback when the call actually happens. In other words, providing a fallback service optimises for the right use-case. This kind of half/half solution sounds messy to me. Either emulate it or don't. But having some of the calls emulated on the client-side and some elsewhere sounds messy. I don't want to emulate any in the library. Any calls that are made are sent to the service. AddMatch and RemoveMatch would reply with error, but most of the others should just work. But given the other email, I guess I am only looking at my own problem. I didn't know that other applications, using other bindings, had legitimate uses for calling AddMatch directly. Thanks for the clarification. I recommend adding a section on what steps to do to create a bus (including setting up policies, activators), one on creating an endpoint, and then one on how a controlling process should operate to manage the bus/endpoint properly. To create a bus you open the control file, issue an ioctl (MAKE_BUS) on the fd, and the fd is then *converted* into a reference to the bus. You can use it then only for updating policy and for eventually closing it to make the bus go away. To create a bus connection you open the bus file, issue an ioctl (HELLO) on the fd, and the fd is then *converted* into a connection fd. You can then use that for send/recv messages, or acquiring/releasing names. To create a bus EP you open the bus file, issue an ioctl (MAKE_EP) on the fd, and the fd is then *converted* into a reference to the EP. You can use it then only to update the EP's policy, and for eventually closing it to make the EP go away. The systemd PID 1 instance has only two fds open hence: one bus reference, and one bus connection. A sandboxing app executor has one, maybe two fds open: the EP reference, and maybe a bus connection in case it wants to offer some services... Understood. My recommendation for clarification in kdbus.txt remains. Well, but in those cases you can just use the user bus or system bus, there's no need to create a new bus just for the purpose of P2P... That implies changes to the user application. I want to provide a replacement API for DBusServer. So, if this is about compat with old apps then continue to use AF_UNIX for that... No need to push them to something new... Well, one thing I've just realised is that the other app needs to know about kdbus too. So we have a double compat issue. Still, I think that a binding *can* provide a P2P-style bus by abusing endpoints with just a bit of convention rules. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ systemd-devel mailing list
Re: [systemd-devel] Compatibility between D-Bus and kdbus
On Wednesday 26 November 2014 19:44:46 Lennart Poettering wrote: Now, that's the reason why acquirename/releasename need to be implemented client side. With that knowledge we can punch holes in the other calls too. For example, the GetConnectionUnixProcessID() call you brought up: let's now issue a GetConnectionUnixProcessID() async first, immediately followed by an AcquireName() for the same name. On dbus this will tell you the old owner, and then acquire the name for you. On kdbus with an external driver this would be different though. While the GetConnecitonUnixProcessID() is queued and waiting to be processed the AcquireName() might already have been executed (because it needs to be an ioctl as we have shown above), hence you would get your own PID returned, not the old one! hence, this calls really should be sync local ioctl()s, not half-half... Ok, thanks. I understand the issue now. Given that and the fact that there are legitimate uses for AddMatch, I am in agreement that bindings need to provide the interception themselves. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Compatibility between D-Bus and kdbus
On Wed, 26.11.14 11:08, Thiago Macieira (thi...@kde.org) wrote: On Wednesday 26 November 2014 19:30:16 Lennart Poettering wrote: I must be misunderstanding something. The kernel enforces that each bus name is prefixed with $UID-. This is why the system bus is /sys/fs/kdbus/0-system rather than just /sys/fs/kdbus/system. This makes sure that users cannot play games with other users. Thanks for the clarification. That tidbit is nowhere in the kdbus.txt docs. It should probably be mentioned in the section about creating buses. Added now. Also, shouldn't CAP_IPC_OWNER-privileged processes be able to create a bus with an arbitrary name? We thought about that too, but then stepped away from it, in order to avoid potential namespace clashes with additional files we might want to place in the kdbusfs file system in the future. Given that there's a strict regime now how the userspace objects are named we have freedom picking names for new files we want to introduce from the kernel-side, as long as we don't name thew new files $SOMENUMBER-$SOMETHINGELSE... Also, it's another thing where being strict initially is a good thing, since opening stuff up later is easier than closing it down later. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] build-sys: remove --gc-sections to fix debugging
El 26/11/14 a las 15:31, Peter Wu escribió: [1]: https://sourceware.org/bugzilla/show_bug.cgi?id=17639 https://bugs.freedesktop.org/show_bug.cgi?id=8 --- v2:removed -ffunction-sections and -fdata-sections too, mention that binutils fixed the bug. --- -1 Just fix the linker and move along... not our bug IMHO. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd: reload network unit from a non-root partition using a mount unit
Hello, I try to configure systemd 216 to boot an embedded board where the network configuration stays on a different partition. The boot should look like: - mount a partition called config using a mount unit - now systemd should reload its configuration to get two network units which resides on the config partition [the path /etc/systemd/network/ is linked to that partition] - on the root file system I have a wpa_supplicant@ unit for the wlan0 device [the wpa_supplicant.conf file for that device also resides on the config partition] My problem is that I can't get systemd to succesfully reload its configuration for my network units after mounting the config partition. I tried to to add a ExecStart systemctl daemon-reload inside the wpa_supplicant rule. If I have the network unit in my (read-only) root filesystem everything works fine. (No reloading is needed here ...) Is it possible to place the network untis onto a partition which is mounted by systemd? Best regards, Matthias ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] build-sys: remove --gc-sections to fix debugging
On Wed, Nov 26, 2014 at 05:24:37PM -0300, Cristian Rodríguez wrote: El 26/11/14 a las 15:31, Peter Wu escribió: [1]: https://sourceware.org/bugzilla/show_bug.cgi?id=17639 https://bugs.freedesktop.org/show_bug.cgi?id=8 --- v2:removed -ffunction-sections and -fdata-sections too, mention that binutils fixed the bug. --- -1 Just fix the linker and move along... not our bug IMHO. Hm, with this patch the build fails for me with ../src/shared/ptyfwd.c:117: error: undefined reference to 'sd_event_source_unref' ../src/shared/ptyfwd.c:120: error: undefined reference to 'sd_event_exit' ../src/shared/ptyfwd.c:127: error: undefined reference to 'sd_event_source_unref' ../src/shared/ptyfwd.c:134: error: undefined reference to 'sd_event_exit' ../src/shared/ptyfwd.c:151: error: undefined reference to 'sd_event_source_unref' ../src/shared/ptyfwd.c:154: error: undefined reference to 'sd_event_exit' ../src/shared/ptyfwd.c:180: error: undefined reference to 'sd_event_source_unref' ../src/shared/ptyfwd.c:183: error: undefined reference to 'sd_event_exit' ../src/shared/ptyfwd.c:374: error: undefined reference to 'sd_event_unref' ../src/shared/ptyfwd.c:298: error: undefined reference to 'sd_event_ref' ../src/shared/ptyfwd.c:300: error: undefined reference to 'sd_event_default' ../src/shared/ptyfwd.c:345: error: undefined reference to 'sd_event_add_io' ../src/shared/ptyfwd.c:349: error: undefined reference to 'sd_event_add_io' ../src/shared/ptyfwd.c:353: error: undefined reference to 'sd_event_add_io' ../src/shared/ptyfwd.c:360: error: undefined reference to 'sd_event_add_signal' ../src/shared/pty.c:436: error: undefined reference to 'sd_event_source_set_io_events' ../src/shared/pty.c:468: error: undefined reference to 'sd_event_add_io' ../src/shared/pty.c:477: error: undefined reference to 'sd_event_source_set_prepare' ../src/shared/pty.c:483: error: undefined reference to 'sd_event_add_child' collect2: error: ld returned 1 exit status Makefile:10333: recipe for target 'login.la' failed (and many repeats for other libraries). $ rpm -q gcc binutils gcc-4.9.2-1.fc21.x86_64 binutils-2.24-21.fc21.x86_64 ../configure CFLAGS='-g -Og -ftrapv' CPPFLAGS=-DVALDGRIND=1 --disable-compat-libs --disable-kdbus --sysconfdir=/etc --localstatedir=/var --libdir=/usr/lib64 --enable-lz4 --enable-xz --enable-terminal I think I'm with Christian here... let sleeping dogs lie. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd: reload network unit from a non-root partition using a mount unit
Hi Matthias, On Wed, Nov 26, 2014 at 9:40 PM, Matthias Klein matthias.kl...@linux.com wrote: I try to configure systemd 216 to boot an embedded board where the network configuration stays on a different partition. The boot should look like: - mount a partition called config using a mount unit - now systemd should reload its configuration to get two network units which resides on the config partition [the path /etc/systemd/network/ is linked to that partition] - on the root file system I have a wpa_supplicant@ unit for the wlan0 device [the wpa_supplicant.conf file for that device also resides on the config partition] My problem is that I can't get systemd to succesfully reload its configuration for my network units after mounting the config partition. I tried to to add a ExecStart systemctl daemon-reload inside the wpa_supplicant rule. If I have the network unit in my (read-only) root filesystem everything works fine. (No reloading is needed here ...) Is it possible to place the network untis onto a partition which is mounted by systemd? This sort of scheme (mounting partitions with extra config files after the daemons have started) is not really something we support. We would rather recommend you mount everything you need for your base system (i.e., all of /etc and /usr, but not necessarily /var, /home, ...) from your initrd so that it is all there once your real userspace is started. That said, it _should_ just work to simply restart the relevant services (i.e., systemd-networkd and wpa_supplicant), or better you, just order them After= the relevant mount units (the latter will only work if you don't need any networking before this point of course). Please note that 'systemctl daemon-reload' only reloads the configuration of PID1 itself, and not of the individual daemons, so that is probably what tripped you up. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] How to start unit before everything else on shutdown
Hello, I'd like to start a unit on system shutdown and reboot, but do so immediately after the systemctl reboot command is executed, before any other units are terminated. Is there a way to do that? At first I thought that Before=shutdown.target might work, but thinking about it, I think this just means that my unit will be started before shutdown.target has been reached, but jobs to terminate other units may be started before my unit. Is that correct? Thanks, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-cgroups-agent not working in containers
Hi! I run a Linux container setup with openSUSE 13.1/2 as guest distro. After some time containers slow down. An investigation showed that the containers slow down because a lot of stale user sessions slow down almost all systemd tools, mostly systemctl. loginctl reports many thousand sessions. All in state closing. The vast majority of these sessions are from crond an ssh logins. It turned out that sessions are never closed and stay around. The control group of a said session contains zero tasks. So I started to explore why systemd keeps it. After another few hours of debugging I realized that systemd never issues the release signal from cgroups. Also calling the release agent by hand did not help. i.e. /usr/lib/systemd/systemd-cgroups-agent /user.slice/user-0.slice/session-c324.scope Therefore systemd never recognizes that a server/session has no more tasks and will close it. First I thought it is an issue in libvirt combined with user namespaces. But I can trigger this also without user namespaces and also with systemd-nspawn. Tested with systemd 208 and 210 from openSUSE, their packages have all known bugfixes. Any idea where to look further? How do you run the most current systemd on your distro? Thanks, //richard ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Unbounded journal~ file accumulation
Running v215-6 via Debian jessie In my situation, it is common to have unclean reboots. On the subsequent boot, a system@journal~ file is created. The problem is that these journal~ files do not trigger any cleanup with respect to SystemMaxUse. If this occurs repeatedly, disk usage can go _way_ above SystemMaxUse. Sending a SIGUSR2 to the systemd-journald process to force a rotation cleans them up, but without that (and assuming the active journal file doesn't get full and need to be rotated) there doesn't seem to be any limit on how much disk space the journal will use (I've had it go 10x SystemMaxUse - until the entire filesystem was full - according to du and journalctl --disk-usage). I could add a service to my boot that issues the SIGUSR2, but the unnecessary _rotation_ would result in a journal file that only had the relatively small number of messages that cover part of a single bootup sequence (while still using 4M of disk space*). My SystemMaxuse is pretty small (low tens of MiB), so that's a significant chunk wasted every boot. Is there any way I can trigger the _cleanup_ (vacuum?) without triggering the rotation of the active log? Is the behavior I'm seeing a bug that should be filed (should it already be doing that cleanup without me having to trigger it)? * With my low SystemMaxUse, 4M is pretty large. I see this minimum is hard-coded as JOURNAL_FILE_SIZE_MIN in the code. Would I be inviting problems if I lowered this value to something like 512K? It was 64K until commit 253f59dff9. Note: this query is secondary to the journal~ accumulation issue. Thanks in advance. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] add configuration for smackfs root
On Thu, Nov 27, 2014 at 01:02:01AM +0900, WaLyong Cho wrote: The smackfs root was changed few month ago. But some of systems are still using old smackfs root. For compatibility, add smackfs root configure option. Default is /sys/fs/smackfs. Sorry, /sys/fs/smackfs was made official in v3.6-rc7-58-ge930723741, and we support 3.7. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] build-sys: remove --gc-sections to fix debugging
On Wednesday 26 November 2014 21:41:48 Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Nov 26, 2014 at 05:24:37PM -0300, Cristian Rodríguez wrote:
El 26/11/14 a las 15:31, Peter Wu escribió:
[1]: https://sourceware.org/bugzilla/show_bug.cgi?id=17639
https://bugs.freedesktop.org/show_bug.cgi?id=8
---
v2:removed -ffunction-sections and -fdata-sections too, mention
that binutils fixed the bug.
---
-1 Just fix the linker and move along... not our bug IMHO.
Now that this bug is fixed, there is less need for this patch, but the
options themselves do not seem to bring great benefit so might as well
remove it. See also below.
Hm, with this patch the build fails for me with
../src/shared/ptyfwd.c:117: error: undefined reference to
'sd_event_source_unref'
../src/shared/ptyfwd.c:120: error: undefined reference to 'sd_event_exit'
[..]
(and many repeats for other libraries).
$ rpm -q gcc binutils
gcc-4.9.2-1.fc21.x86_64
binutils-2.24-21.fc21.x86_64
../configure CFLAGS='-g -Og -ftrapv' CPPFLAGS=-DVALDGRIND=1
--disable-compat-libs --disable-kdbus --sysconfdir=/etc --localstatedir=/var
--libdir=/usr/lib64 --enable-lz4 --enable-xz --enable-terminal
Reproduced. I built with --enable-compat-libs. Isn't a real bug being
hidden by the -Wl,--gc-sections option? id128.so uses the
sd_event_source_unref symbol which is provided by libsystemd-internal,
but id128 only links to libsystemd-shared. When linking with
-Wl,--gc-sections, I get:
$ readelf -s .libs/id128.so | grep sd_event_source_unref
1913: 0 NOTYPE GLOBAL DEFAULT UND sd_event_source_unref
I think I'm with Christian here... let sleeping dogs lie.
Now that a bug is released in binutils (I did not expect such a quick
response, kudos to them!), I can live with this patch not being applied.
But the reasoning is wrong, something was actually broken and you cannot
just ignore that.
As an aside, none of the files in /usr/{lib,bin} on my system were
compiled with this fatal combination of flags, except for systemd. It is
apparently not a common option.
I was also thinking about other adopters of systemd, like Debian. They
just disable gold[1] which would overcome the issue without this patch.
Though if they upgrade systemd in the future they will either have to
disable compat libs or otherwise run in the problem described at
https://bugs.freedesktop.org/show_bug.cgi?id=8. Hmm, strange folks,
they use --enable-compat-libs but then remove[2] the libraries...?
--
Kind regards,
Peter
https://lekensteyn.nl
[1]:
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/buildsys-Don-t-default-to-gold-as-the-linker.patch
[2]:
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/rules#n129
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] build-sys: remove --gc-sections to fix debugging
2014-11-26 23:40 GMT+01:00 Peter Wu pe...@lekensteyn.nl: https://bugs.freedesktop.org/show_bug.cgi?id=8. Hmm, strange folks, they use --enable-compat-libs but then remove[2] the libraries...? We don't remove the libraries, we remove .so symlinks, since they are useless. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] build-sys: remove --gc-sections to fix debugging
On Wednesday 26 November 2014 23:55:52 Michael Biebl wrote: 2014-11-26 23:40 GMT+01:00 Peter Wu pe...@lekensteyn.nl: https://bugs.freedesktop.org/show_bug.cgi?id=8. Hmm, strange folks, they use --enable-compat-libs but then remove[2] the libraries...? We don't remove the libraries, we remove .so symlinks, since they are useless. Ah, to prevent building with -lsystemd-X while allowing existing programs to run I guess. On topic, I think that --gc-section hides those errors as the code do not reference directly and --gc-sections strip them before it get to linking. This is the case for python-systemd. No other part of the code uses id128.so, _daemon.so, _journal.so, login.so or _reader.so. With --without-python --disable-compat-libs, everything still compiles. It could likely be fixed for --with-python by adding systemd-shared to id128_la_LIBADD (etc.)? -- Kind regards, Peter https://lekensteyn.nl ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] logind: Support logind.conf.d directories in the usual search paths
On Wed, Nov 26, 2014 at 01:24:53PM +0100, Gergely Nagy wrote: Josh == Josh Triplett j...@joshtriplett.org writes: Josh This makes it possible to drop in logind configuration snippets from a Josh package or other configuration management mechanism. [...] Josh If this approach looks sensible, I'll send further patches for various Josh other tools with configuration files, such as journald and Josh timesyncd; I recently hit an issue where a journald.conf.d/ would have been incredibly useful. Any news on this patchset, by any chance? Applied. Sorry for the delay. It would be great if you could prepare patches for the other deamons. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] logind: Support logind.conf.d directories in the usual search paths
On Thu, Nov 27, 2014 at 01:45:43AM +0100, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Nov 26, 2014 at 01:24:53PM +0100, Gergely Nagy wrote: Josh == Josh Triplett j...@joshtriplett.org writes: Josh This makes it possible to drop in logind configuration snippets from a Josh package or other configuration management mechanism. [...] Josh If this approach looks sensible, I'll send further patches for various Josh other tools with configuration files, such as journald and Josh timesyncd; I recently hit an issue where a journald.conf.d/ would have been incredibly useful. Any news on this patchset, by any chance? Applied. Sorry for the delay. Thanks! And no problem. It would be great if you could prepare patches for the other deamons. Will do. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 4 commits - src/core test/TEST-03-JOBS
On Wed, Nov 26, 2014 at 07:35:30AM -0800, Michal Schmidt wrote:
src/core/job.c |7 +--
src/core/job.h | 14 ++
src/core/transaction.c |2 +-
test/TEST-03-JOBS/test-jobs.sh |9 +
4 files changed, 25 insertions(+), 7 deletions(-)
Hi,
test-engine does not pass anymore. I didn't check exactly, but one
of those commits is the most likely culprit.
Requested transaction contradicts existing jobs: Resource deadlock avoided
Assertion 'manager_add_job(m, JOB_RESTART, g, JOB_FAIL, false, NULL, j) == 0'
failed at src/test/test-engine.c:95, function main(). Aborting.
[1]17355 abort (core dumped) ./test-engine
Zbyszek
New commits:
commit e0312f4db08c7100bd00299614e87bedc759b366
Author: Michal Schmidt mschm...@redhat.com
Date: Wed Nov 26 16:33:46 2014 +0100
core: fix check for transaction destructiveness
When checking if the transaction is destructive, we need to check if the
previously installed job is a superset of the new job (and hence the new
job will fold into the installed one without changing it), not the other
way around.
diff --git a/src/core/transaction.c b/src/core/transaction.c
index bbaa6da..b992edd 100644
--- a/src/core/transaction.c
+++ b/src/core/transaction.c
@@ -511,7 +511,7 @@ static int transaction_is_destructive(Transaction *tr,
JobMode mode, sd_bus_erro
assert(!j-transaction_next);
if (j-unit-job (mode == JOB_FAIL ||
j-unit-job-irreversible)
-!job_type_is_superset(j-type, j-unit-job-type))
+!job_type_is_superset(j-unit-job-type, j-type))
return sd_bus_error_setf(e,
BUS_ERROR_TRANSACTION_IS_DESTRUCTIVE,
Transaction is
destructive.);
}
commit 61da906a744594002c2c967ecf6ec7899c7a9397
Author: Michal Schmidt mschm...@redhat.com
Date: Wed Nov 26 16:33:45 2014 +0100
core: drop now-redundant special-casing of JOB_NOP
job_type_is_conflicting(X, JOB_NOP) correctly gives: false.
job_type_allows_late_merge(JOB_NOP) job_type_is_superset(X, JOB_NOP)
correctly gives: true.
diff --git a/src/core/job.c b/src/core/job.c
index 1411603..9adc3fd 100644
--- a/src/core/job.c
+++ b/src/core/job.c
@@ -160,12 +160,12 @@ Job* job_install(Job *j) {
uj = *pj;
if (uj) {
-if (j-type != JOB_NOP job_type_is_conflicting(uj-type,
j-type))
+if (job_type_is_conflicting(uj-type, j-type))
job_finish_and_invalidate(uj, JOB_CANCELED, false);
else {
/* not conflicting, i.e. mergeable */
-if (j-type == JOB_NOP || uj-state == JOB_WAITING ||
+if (uj-state == JOB_WAITING ||
(job_type_allows_late_merge(j-type)
job_type_is_superset(uj-type, j-type))) {
job_merge_into_installed(uj, j);
log_debug_unit(uj-unit-id,
commit 7e803f5ecf689216d6fcd8a1d19a442f234bf28b
Author: Michal Schmidt mschm...@redhat.com
Date: Wed Nov 26 16:33:43 2014 +0100
core: fix assertion failure in checking a transaction with a JOB_NOP
Several functions called from transaction_activate() need to correctly
handle the case where a JOB_NOP job is being checked against a unit's
pending job. The assumption that JOB_NOP never merges with other job
types was correct, but since the job_type_is_*() functions are
implemented using the merge lookup, they need to special-case JOB_NOP
to avoid hitting assertion failures.
diff --git a/src/core/job.c b/src/core/job.c
index 51d1581..1411603 100644
--- a/src/core/job.c
+++ b/src/core/job.c
@@ -352,6 +352,9 @@ bool job_type_is_redundant(JobType a, UnitActiveState b) {
return
b == UNIT_ACTIVATING;
+case JOB_NOP:
+return true;
+
default:
assert_not_reached(Invalid job type);
}
diff --git a/src/core/job.h b/src/core/job.h
index b7ebd8d..223ff9c 100644
--- a/src/core/job.h
+++ b/src/core/job.h
@@ -49,9 +49,11 @@ enum JobType {
_JOB_TYPE_MAX_MERGING,
/* JOB_NOP can enter into a transaction, but as it won't pull in
- * any dependencies, it won't have to merge with anything.
- * job_install() avoids the problem of merging JOB_NOP too (it's
- * special-cased, only merges with other JOB_NOPs). */
+ * any dependencies and it uses the special 'nop_job' slot in Unit,
+ * it won't have to merge with anything (except possibly into another
+ * JOB_NOP, previously installed). JOB_NOP is special-cased in
+ * job_type_is_*() functions so that the transaction can be
Re: [systemd-devel] [PATCH v2 2/2] coredump: collect all /proc data useful for bug reporting
On Tue, Nov 25, 2014 at 07:37:48AM +0100, Jakub Filak wrote:
/proc/[pid]:
- status
- maps
- limits
- cgroup
- cwd
- root
- environ
- fd/ fdinfo/ joined in open_fds
---
src/journal/coredump.c | 156
-
1 file changed, 154 insertions(+), 2 deletions(-)
diff --git a/src/journal/coredump.c b/src/journal/coredump.c
index 26a2010..58012d6 100644
--- a/src/journal/coredump.c
+++ b/src/journal/coredump.c
@@ -36,6 +36,7 @@
#include log.h
#include util.h
+#include fileio.h
#include strv.h
#include macro.h
#include mkdir.h
@@ -461,24 +462,107 @@ static int allocate_journal_field(int fd, size_t size,
char **ret, size_t *ret_s
return 0;
}
+/* Joins /proc/[pid]/fd/ and /proc/[pid]/fdinfo/ into the following lines:
+ * 0:/dev/pts/23
+ * pos:0
+ * flags: 012
+ *
+ * 1:/dev/pts/23
+ * pos:0
+ * flags: 012
+ *
+ * 2:/dev/pts/23
+ * pos:0
+ * flags: 012
+ * EOF
+ */
+static int compose_open_fds(pid_t pid, char **open_fds) {
+_cleanup_fclose_ FILE *stream = NULL;
+_cleanup_free_ char *outcome = NULL;
+char path[PATH_MAX], line[LINE_MAX];
+size_t ignored_size;
+const char *fddelim = ;
+struct dirent *dent = NULL;
+_cleanup_closedir_ DIR *proc_fd_dir = NULL;
+int r = 0;
+
+assert(pid = 0);
+assert(open_fds != NULL);
+
+sprintf(path, /proc/PID_FMT/fd, pid);
+proc_fd_dir = opendir(path);
+
+if (proc_fd_dir == NULL)
+return -ENOENT;
+
+stream = open_memstream(outcome, ignored_size);
This needs oom handling.
+
+for (dent = readdir(proc_fd_dir); dent != NULL; dent =
readdir(proc_fd_dir)) {
+_cleanup_free_ char *fdname = NULL;
+_cleanup_fclose_ FILE *fdinfo = NULL;
+
+if (dent-d_name[0] == '.' || strcmp(dent-d_name, ..) ==
0)
+continue;
+
+/* Too long path is unlikely a path to valid file descriptor
in /proc/[pid]/fd */
+/* Skip it. */
+r = snprintf(path, sizeof(path), /proc/PID_FMT/fd/%s,
pid, dent-d_name);
+if (r = (int)sizeof(path))
+continue;
+
+r = readlink_malloc(path, fdname);
+if (r 0)
+return r;
+
+fprintf(stream, %s%s:%s\n, fddelim, dent-d_name, fdname);
+fddelim = \n;
+
+/* Use the directory entry from /proc/[pid]/fd with
/proc/[pid]/fdinfo */
+
+/* Too long path is unlikely a path to valid file descriptor
info in /proc/[pid]/fdinfo */
+/* Skip it. */
+r = snprintf(path, sizeof(path),
/proc/PID_FMT/fdinfo/%s, pid, dent-d_name);
+if (r = (int)sizeof(path))
+continue;
+
+fdinfo = fopen(path, re);
+if (fdinfo == NULL)
+continue;
+
+while(fgets(line, sizeof(line), fdinfo) != NULL)
+fprintf(stream, %s%s, strchr(line, '\n') == NULL ?
\n : , line);
Isn't this backwards (the newline should be after)?
+}
+
+fclose(stream);
+stream = NULL;
outcome is only updated here, so actually it is not necessary to use a
helper variable, and open_fds can be passed to open_memstream directly. It'll
only be touched on success.
+*open_fds = outcome;
+outcome = NULL;
+
+return 0;
+}
+
int main(int argc, char* argv[]) {
_cleanup_free_ char *core_pid = NULL, *core_uid = NULL, *core_gid =
NULL, *core_signal = NULL,
*core_timestamp = NULL, *core_comm = NULL, *core_exe = NULL,
*core_unit = NULL,
*core_session = NULL, *core_message = NULL, *core_cmdline =
NULL, *coredump_data = NULL,
-*core_slice = NULL, *core_cgroup = NULL, *core_owner_uid =
NULL,
+*core_slice = NULL, *core_cgroup = NULL, *core_owner_uid =
NULL, *core_open_fds = NULL,
+*core_proc_status = NULL, *core_proc_maps = NULL,
*core_proc_limits = NULL, *core_proc_cgroup = NULL,
+*core_cwd = NULL, *core_root = NULL, *core_environ = NULL,
*exe = NULL, *comm = NULL, *filename = NULL;
const char *info[_INFO_LEN];
_cleanup_close_ int coredump_fd = -1;
-struct iovec iovec[18];
+struct iovec iovec[26];
off_t coredump_size;
int r, j = 0;
uid_t uid, owner_uid;
gid_t gid;
pid_t pid;
char *t;
+const char *p;
/* Make sure we never enter a loop */
prctl(PR_SET_DUMPABLE, 0);
@@ -638,6 +722,74 @@ int main(int argc, char* argv[]) {
Re: [systemd-devel] [PATCH] timesyncd: do not keep listening socket open forever
On Wed, Nov 26, 2014 at 09:33:30AM +, Sean Young wrote: This also makes the source port less predicatable. Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journal-remote: do not install tmpfiles and sysusers files by default
On Wed, Nov 26, 2014 at 09:17:50AM +0100, Łukasz Stelmach wrote: Change-Id: I5cbbcec134f52267ac4841b7d8f14d341a2d2184 Signed-off-by: Łukasz Stelmach l.stelm...@samsung.com I removed that lines... Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: route - allow routes without a gateway
On Mon, Nov 24, 2014 at 03:51:31PM -0800, Gavin Li wrote: From: Gavin Li g...@thegavinli.com For IPv6, the kernel returns EINVAL if a route is added with the RTA_GATEWAY attribute set to in6addr_any (::). A route without a gateway is useful in some situations, such as layer 3 tunneling (sit, gre, etc.). This patch prevents the RTA_GATEWAY attribute from being added when route.in_addr is ip6addr_any (::). Patch looks straightforward, even though this is not my area of expertise, so I went ahead and applied it. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] unit-name: fix escaping logic in unit_name_mangle_with_suffix().
On Tue, Nov 25, 2014 at 09:58:14PM +0300, Ivan Shapovalov wrote: Make screened character set consistent with unit_name_mangle() by splitting off the escaping loop into a separate function. Before this fix, unit names such as `foo@bar.target` would get transformed into `foo\x40bar.target` when unit_name_mangle_with_suffix() is used. https://bugs.freedesktop.org/show_bug.cgi?id=86711 Thanks, applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journalctl: --follow with --since behaviour
On Tue, Nov 25, 2014 at 08:47:49PM +0100, Andrej Manduch wrote:
journalctl will print not only 10 lines but all relevant when --since is
in use
Hi,
patch applied.
--- 8 ---
git am treates the stuff above this line as the commit message, while
the stuff below is more interesting. I copied it into the commit
message.
Zbyszek
Hi,
When I tryed to run journalctl with --follow and --since arguments it
behaved very strangely.
First It prints logs from what I specified in --since argument, then
printed 10 lines (as is default in --follow) and when app put something
new in to log journalctl printed everithing from the last printed line.
How to reproduce:
1. run: journalctl -m --since 14:00 --follow
Then you'll see 10 lines of logs since 14:00. After that wait until some
app add something in the journal or just run `systemd-cat echo test`
2. After that journalctl will print every single line since 14:00 and will
follow as expected.
As long as --since and --follow will eventually print all relevant
lines, I seen no reason why not to print them right away and not after
first new message in journal.
Relevant bugzillas:
https://bugs.freedesktop.org/show_bug.cgi?id=71546
Closed.
https://bugs.freedesktop.org/show_bug.cgi?id=64291
This one was a different issue actually, but it can be now closed too.
---
src/journal/journalctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
index b168d1e..904880b 100644
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -712,7 +712,7 @@ static int parse_argv(int argc, char *argv[]) {
assert_not_reached(Unhandled option);
}
-if (arg_follow !arg_no_tail arg_lines == ARG_LINES_DEFAULT)
+if (arg_follow !arg_no_tail !arg_since arg_lines ==
ARG_LINES_DEFAULT)
arg_lines = 10;
if (!!arg_directory + !!arg_file + !!arg_machine 1) {
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udevadm hwdb: discard extra leading whitespaces in hwdb
On Thu, Nov 27, 2014 at 03:19:44PM +1000, Peter Hutterer wrote: Currently a property in the form of FOO=bar is stored as FOO=bar, i.e. the property name contains a leading space. That's quite hard to spot. This patch discards all extra whitespaces but the first one which is required by libudev's hwdb_add_property. --- src/udev/udevadm-hwdb.c | 4 1 file changed, 4 insertions(+) diff --git a/src/udev/udevadm-hwdb.c b/src/udev/udevadm-hwdb.c index 3ca755e..dcc6e0f 100644 --- a/src/udev/udevadm-hwdb.c +++ b/src/udev/udevadm-hwdb.c @@ -428,6 +428,10 @@ static int insert_data(struct trie *trie, struct udev_list *match_list, value[0] = '\0'; value++; +/* libudev requires properties to start with a space */ +while(line[0] != '\0' isblank(line[1])) +line++; Coding style doesn't match the rest of the file :( ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 2/2] coredump: collect all /proc data useful for bug reporting
On Thu, 2014-11-27 at 06:30 +0100, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Nov 25, 2014 at 07:37:48AM +0100, Jakub Filak wrote: ... This all looks (and works) great, so I implemented the changes suggested above and pushed your patch. Please check that I didn't break anything. I also added a follow up commit to use openat to avoid concatenating paths... I don't think it matters for efficiency, but the code is imho slightly nicer without the fixed-size buffers. I tested your patches on Fedora Rawhide and it works fantastic. Thank you very much indeed! Regards, Jakub ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udevadm hwdb: discard extra leading whitespaces in hwdb
On Wed, Nov 26, 2014 at 09:55:10PM -0800, Greg KH wrote: On Thu, Nov 27, 2014 at 03:19:44PM +1000, Peter Hutterer wrote: Currently a property in the form of FOO=bar is stored as FOO=bar, i.e. the property name contains a leading space. That's quite hard to spot. This patch discards all extra whitespaces but the first one which is required by libudev's hwdb_add_property. --- src/udev/udevadm-hwdb.c | 4 1 file changed, 4 insertions(+) diff --git a/src/udev/udevadm-hwdb.c b/src/udev/udevadm-hwdb.c index 3ca755e..dcc6e0f 100644 --- a/src/udev/udevadm-hwdb.c +++ b/src/udev/udevadm-hwdb.c @@ -428,6 +428,10 @@ static int insert_data(struct trie *trie, struct udev_list *match_list, value[0] = '\0'; value++; +/* libudev requires properties to start with a space */ +while(line[0] != '\0' isblank(line[1])) Shouldn't this be while (isblank(line[0]) isblank(line[1])) ? Otherwise stuff like x yyy=111 might slip through. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journal-remote: do not install tmpfiles and sysusers files by default
It was 2014-11-27 czw 06:32, when Zbigniew Jędrzejewski-Szmek wrote: On Wed, Nov 26, 2014 at 09:17:50AM +0100, Łukasz Stelmach wrote: Change-Id: I5cbbcec134f52267ac4841b7d8f14d341a2d2184 Signed-off-by: Łukasz Stelmach l.stelm...@samsung.com I removed that lines... Sure, thanks. -- Łukasz Stelmach Samsung RD Institute Poland Samsung Electronics pgpetqEON_RWo.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
