Re: [systemd-devel] [PATCH 01/12] fsckd daemon for inter-fsckd communication
On Thu, 29.01.15 18:41, Didier Roche (didro...@ubuntu.com) wrote:
Le 28/01/2015 21:16, Lennart Poettering a écrit :
Thanks for your feedbacks! Changes integrated, some remaining questions
though:
On Wed, 28.01.15 14:20, Didier Roche (didier.ro...@canonical.com) wrote:
+last_activity = now(CLOCK_MONOTONIC);
+
+for (;;) {
+int new_client_fd = 0;
+Clients *current;
+_cleanup_free_ char *console_message = NULL;
+double current_percent = 100;
+int current_numdevices = 0, m = 0;
+usec_t t;
+
+/* Initialize and list new clients */
+new_client_fd = accept4(socket_fd, NULL, NULL,
SOCK_NONBLOCK);
+if (new_client_fd 0) {
+log_debug(new fsck client connected to fd: %d,
new_client_fd);
+current = alloca0(sizeof(Clients));
It's not OK to invoke alloca() in loops. This cannot work. Please use
normal heap memoy for this.
Oh, good to know, replaced with a regular malloc. I didn't handle the
freeing of Clients as they are destructed on program close, should I handle
this (and thus looping over and freeing the new char* - which part of the
struct)?
Yes, please, always release all memory you allocate before
exiting. This makes life much much easier when valgrinding
things. There are only very few cases where it is OK to leave memory
unfreed on shutdown.
+current = NULL;
+}
+
+LIST_FOREACH(clients, current, first) {
+ FsckProgress fsck_data;
+ int rc = 0;
+
+if (current-fd 0)
+rc = recv(current-fd, fsck_data,
sizeof(FsckProgress), 0);
+
+if ((current-fd != 0) (rc == 0)) {
+log_debug(fsck client connected to
fd %d disconnected, current-fd);
Please print propery exit codes.
That was my bad, it's r rather then rc, so not a return code but number of
bytes read, or I missing something?
Sorry, I meant proper error codes. I.e. print errno. In systemd we
have this idiom of:
log_debug_errno(errno, foo bar waldo: %m);
i.e. the log_debug_errno() macro takes the error number as first arg,
and then resolves it to a human readable string with %m.
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] Support for staged startup
On Thu, 29.01.15 17:20, Hoyer, Marko (ADITG/SW2) (mho...@de.adit-jv.com) wrote: Hi all, I'd like to realize a staged startup with systemd which is mainly about: - starting up a static tree up to a final service - the only job of the final service is to kick off the start of an additional sub tree of units This kind of startup could be realized simply by adding an additional one shot service which executes: systemctl start xxx.target My question now is: Is this the appropriate way for realizing this or is there any other more elegant way. My problem with this approach is that systemd executes a binary (systemctl), which communicates with systemd just to queue a new job in systemd. Sounds as if there should be a way which is a bit more direct ... This has come up before, for example here: http://lists.freedesktop.org/archives/systemd-devel/2014-May/019187.html I think generally it is a better idea to push as many IO and CPU workloads into the kernel as possible, plus appropriate scheduling settings and let it figure out the rest, than trying to work around it by pushing things into the kernel only bit-by-bit, like you would do with such a staged startup. We already added support for applying different scheduling settings during startup then during normal operating to help with this. What I'd still like to see changed in systemd proper is permitting the user to control which job to execute first if multiple jobs are runnable at the same time. Currently the order is undefined (though not random). If you really want to do a staged boot-up then invoking systemctl start --no-block from a service is the option of choice I figure... 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] User sessions, session buses, user buses
On Fri, 30.01.15 09:30, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: user-session I don't think there is a standard term for this so I'm making one up. The XDG_RUNTIME_DIR specification says that there is at most one XDG_RUNTIME_DIR per uid per machine, that it is created at the beginning of the user's first login session, and that it is removed at the end of a login session if no other login sessions remain for that uid. systemd-logind implements those semantics, and also runs a `systemd --user` for the lifetime of the user-session. Ubuntu previously used libpam-xdg-runtime to provide compatible semantics without systemd. The resulting situation looks something like this (assume all the sessions shown are under the same uid): \ \\ login | user- || session | \ session || - overlapping login session c42 23 | login | ||shares the user-session with 23 / session | || - 23 ends but c42 keeps u.-session c42 | ||alive \ | || - 57 begins, shares u.-sess. login | / || - c42 ends, 57 keeps user-session session | ||alive 57 | || / // no more l.sessions, u.-session ends \ \\ new l.session, u.-session starts login | user- || session | session || ... . ... .. user-sessions do not have any meaningful identifier apart from their owner's uid (strictly speaking, the owner's loginuid, i.e. the user who initially logged in, even if they su). They do not need another identifier, because by definition there is only one per uid at a time. Small addition: these super-sessions are slightly modulated by the linger boolean setting that logind manages per-user. If that boolean is true the user's super-session stays alive from boot to shutdown. Digression: (at least some) users and developers don't want that Adding in here: note that firefox and some other apps actually lock thheir configuration directory, so that it effectively a singleton program per-user anyway. One of the most important apps of the user is hence per-use anyway, even if started in a per-session context. It's already been discussed multiple times on the list and apparently a user bus is too confusing or not really useful unless you make it a user bus shared across a network cluster. I don't agree, and I think that the consequence of this stance will be a proliferation of hacks like the one I just sketched out (not to mention even grosser hacks like Ubuntu's ACPI scripts grepping the environment of the user's processes in /proc to find their session bus to tell their screensaver to lock). Not convinced that the ACPI thing is a good example. It's not a confusion about session/user contexts, but more a confusion about privileged code calling into unprvileged code, which should never happen. This leaves the problem that, if you have chosen the user-session-centric model, current D-Bus doesn't actually work very well: we have dbus-launch and dbus-run-session for login-session-centric D-Bus, but if you want to make D-Bus user-session-centric, you need to resort to third-party user bus units like user-session-units, which float around Github and somehow never make it upstream. I'm now on my third unrelated work project that contains a copypaste of dbus.socket and dbus.service, and I'm sure my colleagues have others - this is not the flying car future I signed up for. So I would like to get this stuff upstream into dbus.git. So that the people who are happy with the complexities of the current arrangement can remain happy, here is how I intend it to work: * ./configure --disable-user-bus: you get a login-session-centric world * ./configure --enable-user-bus: you get a user-session-centric world * configure either way and selectively install/delete files: you can either have a login-session-centric or user-session-centric world, depending what you install. (This is so I can have dbus-user-bus and dbus-x11 binary packages in Debian, where the answer to do A or do B? is always both!, without having to compile everything twice; the GNOME metapackage could eventually depend on dbus-user-bus.) So far our logic in systemd was to simply set the $DBUS_SESSION_BUS_ADDRESS to the user bus address, to redirect all access to the session bus to the user bus. Sadly, not all the issues have been resolved yet. The biggest is environment variables: on existing systems there is an expectation that environment variables set by *dm, PAM, or /etc/X11/Xsession.d (or the non-Debian equivalent) will be propagated into every
Re: [systemd-devel] User sessions, session buses, user buses
On Sat, 31.01.15 09:43, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: Losing DBUS_SESSION_BUS_ADDRESS was part of the point of this thread. BTW: DBUS_SESSION_BUS_ADDRESS we currently set on kdbus systems from pam_systemd. That way we can be sure it is set for all the user's sessions. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 8 commits - man/custom-html.xsl man/systemd-nspawn.xml src/core src/fsck src/journal src/journal-remote src/libsystemd src/libsystemd-terminal src/shared src/time
On Mon, Feb 02, 2015 at 09:36:15PM +0100, Lennart Poettering wrote: On Mon, 02.02.15 21:21, Lennart Poettering (lenn...@poettering.net) wrote: I now fixed all but the DECIMAL_STR_MAX() + 1 issue now... Was too lazy for DECIMAL_STR_MAX() thing... Hm, I'm not sure if we want DECIMAL_STR_MAX to include the space for the null. Sometimes there's more than one decimal in a format. Also, even if there's just one, but not at the end, it somehow feels awkward to have the extra byte allocated in the middle of the string. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 8 commits - man/custom-html.xsl man/systemd-nspawn.xml src/core src/fsck src/journal src/journal-remote src/libsystemd src/libsystemd-terminal src/shared src/time
On Sun, 01.02.15 14:28, Zbigniew Jędrzejewski-Szmek
(zbys...@kemper.freedesktop.org) wrote:
if (!switch_root_init) {
-char sfd[16];
+char sfd[DECIMAL_STR_MAX(int) + 1];
/* First try to spawn ourselves with the right
* path, and with full serialization. We do
@@ -1893,8 +1893,7 @@ finish:
assert(arg_serialization);
assert(fds);
-snprintf(sfd, sizeof(sfd), %i,
fileno(arg_serialization));
-char_array_0(sfd);
+xsprintf(sfd, %i,
-fileno(arg_serialization));
BTW, one minor comment on this: DECIMAL_STR_MAX() actually already
includes space for the trailing NUL, the +1 for sizing this array are
hence unnecesary.
I like the xsprintf() concept!
diff --git a/src/timedate/timedatectl.c b/src/timedate/timedatectl.c
index 74f40b9..1f85536 100644
--- a/src/timedate/timedatectl.c
+++ b/src/timedate/timedatectl.c
@@ -38,6 +38,8 @@
#include pager.h
#include time-dst.h
+#define xstrftime(buf, fmt, tm) assert_se(strftime(buf, sizeof(buf), fmt,
tm) 0)
+
Maybe move this to time-util.h, even though it currently has a single
user only...
+typedef enum {
+CREATION_NORMAL,
+CREATION_EXISTING,
+CREATION_FORCE,
+} CreationMode;
+
+static const char* creation_verb(CreationMode mode) {
+switch(mode) {
+case CREATION_NORMAL:
+return Created;
+case CREATION_EXISTING:
+return Found existing;
+case CREATION_FORCE:
+return Created replacement;
+}
+assert_not_reached(Bad creation);
+}
Maybe a candidate for DEFINE_PRIVATE_STRING_TABLE_LOOKUP_TO_STRING()?
I recently split up DEFINE_PRIVATE_STRING_TABLE_LOOKUP() so that one
can also just male use of the to_string() part without the
from_string() part...
--- a/units/systemd-backli...@.service.in
+++ b/units/systemd-backli...@.service.in
@@ -19,3 +19,4 @@ Type=oneshot
RemainAfterExit=yes
ExecStart=@rootlibexecdir@/systemd-backlight load %i
ExecStop=@rootlibexecdir@/systemd-backlight save %i
+TimeoutSec=2min
Our usual default timeout is 90s so far (see def.h), we probably
should stick to that here...
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] What's the correct way to configure encrypted volume and mount point?
On Sat, 31.01.15 11:21, John Lane (syst...@jelmail.com) wrote: Further to this, I tried manually creating a systemd-cryptsetup unit instead of putting an entry in /etc/crypttab. This allowed me to remove the RequiresMountsFor entry. Yeah, I figure for your usecase a WantsMountsFor= setting would be useful. (Wants is generally the softer variant of Requires for us). Added to the TODO list for now. 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] User sessions, session buses, user buses
On Fri, 30.01.15 22:53, Elias Probst (m...@eliasprobst.eu) wrote: On 01/30/2015 09:30 AM, Simon McVittie wrote: Remaining issue: environment variables == […] As a short-term solution, I'm tempted to write that tool, but make it only upload a whitelisted set of variables automatically, and say if you install dbus-user-bus, you are expected to run this tool from your ~/.xsession if you need it. IMHO, env variables are something we should get rid of in the long term. It might be fine for now to provide some legacy-compatibility mechanisms (like your not-yet-written tool), but to me environment variables are something straight out of the dark ages. I think in the long-run we should not use environment variables for all these things in the default codepaths. However, the user always needs the ability to set some if he desires to do so. 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] User sessions, session buses, user buses
On Mon, 02.02.15 10:22, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: plus the obvious ones set by *dm, such as DISPLAY, or by PAM. Similarly, a user's ~/.xsession can set arbitrary variables - mine sets CCACHE_DIR, EDITOR, MPD_HOST and XDG_CONFIG_DIRS, among others. The naive implementation would be to run a tool at the end of /etc/X11/Xsession.d that uploads all of these into `dbus-daemon --session` (if used) and into `systemd --user` (if used). However, not all environment variables set in such scripts are suitable for that use: notably, XDG_SESSION_ID from the login session should not be copied into activated processes that exist outside any login session. The rest of the email thread is adequate. I would like to experiment with a user-bus, potentially in a transient manner to have 3 buses: system, user, session busses. And migrate things from session to user bus experiment as to how much stuff breaks. I think being explicit about session vs user bus would avoid confusion, and will help manifest bugs have a clear migration plan. E.g. when org.freedesktop.Telepathy / ca.desrt.dconf moves to user bus, things should know how to start talking to Telepathy/dconf over user bus. I'd be very careful with running things with three instead of two busses, since most user services only open one bus connection, and they assume they find all the user's services on that one connection. If you now intrdouce a seperate user and session bus, you will have to patch all those apps to keep connections open to both busses, and individually check for each bus call they make which bus they need to do that on. I am pretty sure the going for 3 busses, instead of 2 is not worth the effort and much much more work than just redefining session to user, the way we currently try to do in the kdbus context. Note that we test this per-user bus daily, since its the default mode of operation if you boot with kdbus turned on. For that, simply build the kdbus kernel modules as well as systemd with kdbus. Then boot with kdbus on the kernel cmdline and all should be good. We now ship with all the necessary bits in systemd git to make this just work. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 5 commits - Makefile.am man/systemd-networkd-wait-online.service.xml src/libsystemd src/network src/systemd TODO units/systemd-networkd.service.in units/systemd-n
On Mon, 02.02.15 03:00, Tom Gundersen (tome...@kemper.freedesktop.org) wrote:
+static int systemd_netlink_fd(int *ret) {
+int n, fd, rtnl_fd = -1;
+
+n = sd_listen_fds(true);
+if (n = 0)
+return -EINVAL;
+
+for (fd = SD_LISTEN_FDS_START; fd SD_LISTEN_FDS_START + n; fd ++) {
+if (sd_is_socket(fd, AF_NETLINK, SOCK_RAW, -1) 0) {
+if (rtnl_fd = 0)
+return -EINVAL;
+
+rtnl_fd = fd;
+}
+}
+
+if (rtnl_fd 0)
+return -EINVAL;
+
+*ret = rtnl_fd;
+
+return 0;
+}
BTW, if a function that returns an fd, can just do so as return value,
rather than as call-by-ref argument, since fds are = 0 and errors are
0, and hence we can use the full int range then.
+int sd_rtnl_new_from_netlink(sd_rtnl **ret, int fd) {
Can't his one be folded into sd_rtnl_open_fd()? It does one more step,
invoking bind() on the fd, but if we handling double binding
correctly, then I think that would be the cleaner API?
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 8 commits - man/custom-html.xsl man/systemd-nspawn.xml src/core src/fsck src/journal src/journal-remote src/libsystemd src/libsystemd-terminal src/shared src/time
On Mon, 02.02.15 21:21, Lennart Poettering (lenn...@poettering.net) wrote: I now fixed all but the DECIMAL_STR_MAX() + 1 issue now... Was too lazy for DECIMAL_STR_MAX() thing... 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] timesyncd: tighten unit file
On Sun, 01.02.15 09:28, Topi Miettinen (toiwo...@gmail.com) wrote: On 01/27/15 22:19, Lennart Poettering wrote: On Tue, 27.01.15 21:58, Topi Miettinen (toiwo...@gmail.com) wrote: Well, the way I read the paragraph above if we set PR_SET_NO_NEW_PRIVS after forking, but before execing systemd-timesyncd, and that binary has an selinux label on it, that the selinux label would be ignore, and things would continue to run with the same label as we forked off. This pretty much renders SELinux usesless, since all services where we set the bit for would then run as init_t... and that's something we really shouldn't do. seccomp_filter.txt on the other hand says that Prior to use, the task must call prctl(PR_SET_NO_NEW_PRIVS, 1) or run with CAP_SYS_ADMIN privileges in its namespace. If these are not true, -EACCES will be returned. This requirement ensures that filter programs cannot be applied to child processes with greater privileges than the task that installed them. Does this mean that SELinux and seccomp are mutually exclusive? Awful design if so. Well, no it doesn't mean that. If systemd sets up a seccomp filter it has CAP_SYS_ADMIN, hence all is good. And it can leave PR_SET_NO_NEW_PRIVS off, and thus not break selinux. So in conclusion, only the SecureBits part would be interesting. Looking at the unit files, which of them expect to run setuid helpers? I looked at the unit files and briefly at the corresponding programs (also to get to know them better), so I offer my guesses below: In general, I would only bother with setting the securebits for long-running services. The stuff that only sets up something and quickly exits is probably not worth the efforts... Also, anything that invokes generic user code (such as the gettys or logind) can't really be locked down, since we should not restrict what the users can do. I'd also not bother with debugging/profiling tools such as bootchart, since they aren't part of normal code paths. Which means I think only these really remain: units/systemd-hostnamed.service.in units/systemd-importd.service.in Calls systemd-importd, which in turn executes several helpers, especially gpg which could be setuid to lock memory, so no. Actually, importd already drops most caps on its own. It even takes most caps away from gpg... I think it is safe to use securebits on this. units/systemd-journald.service.in units/systemd-journal-gatewayd.service.in units/systemd-journal-remote.service.in units/systemd-journal-upload.service.in units/systemd-localed.service.in units/systemd-logind.service.in units/systemd-machined.service.in units/systemd-networkd.service.in units/systemd-resolved.service.in units/systemd-timedated.service.in units/systemd-timesyncd.service.in I think adding the securebits stuff should be safe for all of these... 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] timesyncd: tighten unit file
On Sun, 01.02.15 11:21, Cristian Rodríguez (crrodrig...@opensuse.org) wrote: El 27/01/15 a las 21:18, Lennart Poettering escribió: On Tue, 27.01.15 15:12, Cameron Norman (camerontnor...@gmail.com) wrote: Lennart: if you really want to test the profile, you just need to spin up an OpenSuSE, Ubuntu, or Debian VM (on debian you need to install and enable apparmor, which takes a short while). Well, I have no personal interest in AppArmor, and I really have enough stuff to do. If AA shall be supported in systemd, then I am happy to merge stuff for it, if it is reviewed properly, but I am not the one to test it. Sorry... Hi Lennart: To make apparmor work, only the initial policy loading bits (like selinux, smack..etc) needs to be implemented..currently it is done by some really ugly init script. Would be happy to take a patch for that. Appamor policies however, just like the case of selinux have to go somewhere else, namely the apparmor upstream repository. OK, if it's customary to ship apparmor profiles in a centralized distro-wide policy package, then we shouldn't include this in systemd. Same case as for the SELinux policy I figure... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn support for loading kernel modules / custom seccomp rules
On Thu, 29.01.15 22:47, Jay Faulkner (j...@jvf.cc) wrote: Hi all, I’m a big fan of systemd, and currently use IPA[1] running inside systemd-nspawn containers to provision and maintain systems as part of OpenStack Ironic. This includes, at times, doing things like flashing firmwares which may require a kernel module to be loaded. What kinda of kernel modules is this? Note that most normal kernel modules are nowadays auto-loaded the first time one of their features is requested. We nowadays explicitly disallow non-auto loading of kernel modules from containers, for security reasons. If you want to allow kernel modules, then you can do so by adding the CAP_SYS_MODULE capability set to the set of caps to retain in nspawn, by using its --capability= switch. However, you would also have to include the kernel modules to load in the container's directory tree. Is it possible to have a switch added to systemd-nspawn to allow me to specify custom seccomp filters, or to disable them entirely? So far we use seccomp filtering only to deal with audit incompatibilities, we do not prohibit kernel module loading that way. Hope this is useful, 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] Questions regarding dbus started via systemd --user
On Thu, 08.01.15 17:48, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: On 8 January 2015 at 17:15, Andrei Borzenkov arvidj...@gmail.com wrote: В Thu, 8 Jan 2015 16:03:43 + Dimitri John Ledkov dimitri.j.led...@intel.com пишет: On 8 January 2015 at 15:37, Simon McVittie simon.mcvit...@collabora.co.uk wrote: On 08/01/15 14:36, Colin Guthrie wrote: Lennart Poettering wrote on 08/01/15 13:19: Thus my expectation would be to have a systemd (dbus, etc...) --user per-session/per-seat, rather than per-uid. How do you manage things that are inherently per-user and not per-session (like pulse audio, ssh-/gpg-agents)? E.g. ssh-/gpg-agents - they are upstart jobs, and thus are started per-session. They use environment variables to point at the active agent. Are you sure that ssh/gpg agent are happy with being started multiple times per-user? Even on your desktop, you can spawn two agents and use different SSH_AUTH_SOCK to talk to one or the other. Ideally such variables could be eliminated in favor of using address namespacing e.g. always talk to unix:abstract=/tmp/agent - which is Well, the abstract AF_UNIX namespace is subject to network namespaces, which means you'd have to run each user in a network namespace of his own, which however then would mean it would have no network interfaces except the loopback device... Abstract namespace sockets are pretty useless these days, and simply risky due to the namespacing issue. Don't use them. The ssh/gpg sockets should really move to XDG_RUNTIME_DIR, and nowhere else. 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] Questions regarding dbus started via systemd --user
On Fri, 09.01.15 12:18, Colin Guthrie (gm...@colin.guthr.ie) wrote: Mantas Mikulėnas wrote on 09/01/15 10:31: I guess you could use KillMode= for this? I don't think so. This would mean the unit would still be alive even although the main process died and when I next tried to open a gnome-terminal, it would try and speak to the dbus service again and then dbus would try and spawn it but systemd would say it's already running and not actually run a new gnome-terminal-server process. Not really, if you use KillMode=main for this, then systemd simply doesn't care for any remaining processes, except for the main one, and the unit's state would not be affected in any way by those processes. The right thing should happen. 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] Propagate reload from RELOADING=1 notifications
On Tue, 30.12.14 20:22, Jouke Witteveen (j.wittev...@gmail.com) wrote:
Hmm, what happened to this patch? Did you ever resend it with the
commit msg fix Zbigniew suggested? I don't see it in the mail
archives?
---
This fixes #87251
src/core/manager.c | 42 ++
src/core/manager.h | 1 +
src/core/service.c | 7 +++
3 files changed, 50 insertions(+)
diff --git a/src/core/manager.c b/src/core/manager.c
index 9705e64..11cca17 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -1226,6 +1226,48 @@ int manager_add_job_by_name(Manager *m, JobType type,
const char *name, JobMode
return manager_add_job(m, type, unit, mode, override, e, _ret);
}
+int manager_propagate_reload(Manager *m, Unit *unit, JobMode mode, bool
override, sd_bus_error *e) {
+int r;
+Transaction *tr;
+Iterator i;
+Unit *dep;
+
+
Spurious newline...
Otherwise looks great!
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] Propagate reload from RELOADING=1 notifications
On Thu, 01.01.15 19:15, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
On Tue, Dec 30, 2014 at 08:22:27PM +0100, Jouke Witteveen wrote:
---
This fixes #87251
This is actually important information that should be included in the
commit message (i.e. above not below ---). We usually include the
full url, since we also use distribution bug trackers and having the full
url makes things easier to click. In this case:
https://bugs.freedesktop.org/show_bug.cgi?id=87251
static void service_enter_reload_by_notify(Service *s) {
+_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
+int r;
+
assert(s);
if (s-timeout_start_usec 0)
service_arm_timer(s, s-timeout_start_usec);
+r = manager_propagate_reload(UNIT(s)-manager, UNIT(s),
JOB_REPLACE, false, error);
+if(r 0)
+log_unit_warning(UNIT(s)-id, %s failed to schedule
propagation of reload: %s, UNIT(s)-id, bus_error_message(error, -r));
+
Let's say that a.service has PropagateReloadsTo=b.service, and a.service
provides
the RELOADING=1 notification during a reload.
What happens if a reload is requested with 'systemctl reload a', and systemd
schedules a reload of a and b. Is it possible for b to be reloaded a second
time
as a result of notification of a? This should not happen, have you verified
that
this will not happen?
THis is a real issue I fear.
If service units use an asynchronous command in ExecReload= (such as
one that just sends a SIGHUP signal to the daemon and terminates),
then the daemon might send its RELOADING=1 later than the ExecReload=
finishes. This would then trigger a second reload in b.service...
This problem goes away if the people use synchronous commands in
ExecReload= however, that wait for the reload to complete. In that
case the RELOADING=1 from the service would be queued in s-notify_state,
and be unset again when the daemon reports READY=1 again. And only
after that the ExecReload= process would exit, and hence no second
reload be propagated. (this is race-free because we always process
notification messages before SIGCHLD).
Now I wonder what to do with this. I think the change would be
welcome, but I wonder if we can simply require people who use
PropagateReloadsTo= to define synchronous ExecReload= processes or
accept double reloads to be forwarded...
I leaning towards merging the patch, but this would require an
explanation in the man page of sd_notify() and in systemd.unit near
the description of PropagateReloadsTo=.
Jouke, could you resend this patch with such an addition?
Thanks,
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 8 commits - man/custom-html.xsl man/systemd-nspawn.xml src/core src/fsck src/journal src/journal-remote src/libsystemd src/libsystemd-terminal src/shared src/time
On Mon, 02.02.15 23:25, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Mon, Feb 02, 2015 at 09:36:15PM +0100, Lennart Poettering wrote: On Mon, 02.02.15 21:21, Lennart Poettering (lenn...@poettering.net) wrote: I now fixed all but the DECIMAL_STR_MAX() + 1 issue now... Was too lazy for DECIMAL_STR_MAX() thing... Hm, I'm not sure if we want DECIMAL_STR_MAX to include the space for the null. Sometimes there's more than one decimal in a format. Also, even if there's just one, but not at the end, it somehow feels awkward to have the extra byte allocated in the middle of the string. Yeah, I figure it would make sense to remove the +1 for the NUL byte from the macro. If you want to fix this, go ahead, but of course this would mean checking all current uses of that macro to see if it needs an extra +1 then... 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] Questions regarding dbus started via systemd --user
On Thu, 08.01.15 19:01, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: On 08/01/15 17:04, Colin Guthrie wrote: Although when I discussed this on the ML before, one case which a PAM solution wouldn't address is people running startx after logging into a tty session I personally am very tempted to say that startx users get to keep both pieces, and that the *dm family of services are just a better approach all round... startx could simply invoke systemctl import DISPLAY after setting it, and things should just work for it too, as long as it just takes over the tty it is running on instead of allocating a new one. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Questions regarding dbus started via systemd --user
On Thu, 08.01.15 18:24, Cameron Norman (camerontnor...@gmail.com) wrote: On Thu, Jan 8, 2015 at 9:42 AM, Dimitri John Ledkov dimitri.j.led...@intel.com wrote: On 8 January 2015 at 17:24, Simon McVittie simon.mcvit...@collabora.co.uk wrote: On 08/01/15 16:03, Dimitri John Ledkov wrote: * I'm in an X11 session and my GUI locks up. I use Ctrl+Alt+F1 and log in at the getty. How do I communicate with X11 session things over D-Bus, perhaps to disconnect from Telepathy without losing messages? * The same, but I ssh in from another machine instead. Same question? On Ubuntu at the moment this looks in practice something like this: find UPSTART_SESSION_ID of your tty7 session, export that variable in your getty shell, then use initctl list-env (systemctl) to list environment variables, one of them is DBUS_SESSION_BUS_ADDRESS use that to communicate with dbus. It would be easer if there was a variable like `$XDG_RUNTIME_SESSION_DIR`, which would point to `$XDG_RUNTIME_DIR/sessions/$sid`. Then you could just change that to attach to a currently running session, and you could easily visualize which sessions are running. It would also be nice because services that do not conflict with themselves when running a second instance with the same uid (not dconf, but something along the lines of a GUI shell or gnome-session/upstart) could use it instead of doing their own session instancing (like upstart does). I am not convinced that we need special support for this really. I fail to see the usecase. I mean, it's usually the background stuff that listens on sockets, and all that background stuff tends to be more per-user than per-session. I fail to see which service would really need a per-session listening socket... And if there is one, then using $XDG_RUNTIME_DIR/foobar.$XDG_SESSION_ID should be good enough... 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] Second (erroneous) check of rootfs?
On Tue, 03.02.15 00:27, Lennart Poettering (lenn...@poettering.net) wrote: On Thu, 08.01.15 16:34, Harald Hoyer (harald.ho...@gmail.com) wrote: IMHO systemd-fsck-root.service should be removed entirely and generated by the fstab-generator in the real root like all the other mount points. Well, we also need it if there's no /etc/fstab... OR fstab-generator should create systemd-fsck-root.service for the /sysroot mountpoint in the initrd, which then will be serialized. That sounds like a good idea. I take that back. By which I mean that after reading the thread again I think that this is probably the way to go: The fstab generator should enqeue an s-f@.s for the root device as usual, when it runs in an initrd. However, it should also create a mask file for s-f-r.s in /run, so that it is not executed after the transition. This should be a one-line fix pretty much, and we don't need any flag file. Does that make sense? Would be happy to take a tested patch for this! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] src/bus-proxyd src/login src/machine src/nspawn src/tmpfiles
On Mon, Feb 02, 2015 at 02:07:37PM -0800, Thomas H.P. Andersen wrote:
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -3610,7 +3610,6 @@ int main(int argc, char *argv[]) {
}
if (arg_ephemeral) {
-_cleanup_release_lock_file_ LockFile original_lock =
LOCK_FILE_INIT;
char *np;
/* If the specified path is a mount point we
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 930b9a6..443851a 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -630,7 +630,7 @@ static int get_xattrs_from_arg(Item *i) {
while ((r = unquote_first_word(p, xattr, false)) 0) {
_cleanup_free_ char *tmp = NULL, *name = NULL,
-*value = NULL, *value2 = NULL, *_xattr = xattr;
+*value = NULL, *value2 = NULL;
This leaks xattr, no?
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Container, private network and socket activation
I've set up a container via systemd-nspawn tool, and I wanted to use the private network feature. The line that launches the container includes --network-bridge= and --network-veth options. The whole systemd .service file looks like this: [Unit] Description=My little container [Service] Type=simple KillMode=process ExecStart=/usr/bin/systemd-nspawn -jbD /media/Kabi/debian-tree/ \ --network-bridge=br_lxc \ --network-veth \ --bind /media/Kabi/apache/:/apache/ \ --bind /media/Kabi/backup_packages/apt/archives/:/var/cache/apt/archives/ \ --bind /media/Kabi/repozytorium:/repozytorium \ 3 The bridge interface was created through the /etc/network/interface file, and it looks as follows: auto br_lxc iface br_lxc inet static address 192.168.10.100 netmask 255.255.255.0 broadcast 192.168.10.255 bridge_ports none bridge_waitport 0 bridge_fd 0 The container is able to boot: # systemctl status mycontainer.service ● mycontainer.service - My little container Loaded: loaded (/etc/systemd/system/mycontainer.service; static; vendor preset: enabled) Active: active (running) since Tue 2015-02-03 01:57:24 CET; 12s ago Main PID: 84905 (systemd-nspawn) CGroup: /system.slice/mycontainer.service └─84905 /usr/bin/systemd-nspawn -jbD /media/Kabi/debian-tree/ --network-bridge=br_lxc --network-veth --bind /media/Kabi/apache/:/apache/ --bind /media/Kabi/backup_packages/apt/arch... Feb 03 01:57:25 morfikownia systemd-nspawn[84905]: [ OK ] Started Console Getty. Feb 03 01:57:25 morfikownia systemd-nspawn[84905]: [ OK ] Reached target Login Prompts. Feb 03 01:57:25 morfikownia systemd-nspawn[84905]: [ OK ] Started System Logging Service. Feb 03 01:57:25 morfikownia systemd-nspawn[84905]: [ OK ] Started Cleanup of Temporary Directories. Feb 03 01:57:27 morfikownia systemd-nspawn[84905]: [ OK ] Started LSB: Start and stop the mysql database server daemon. Feb 03 01:57:28 morfikownia systemd-nspawn[84905]: [ OK ] Started LSB: Apache2 web server. Feb 03 01:57:28 morfikownia systemd-nspawn[84905]: [ OK ] Reached target Multi-User System. Feb 03 01:57:28 morfikownia systemd-nspawn[84905]: Starting Update UTMP about System Runlevel Changes... Feb 03 01:57:28 morfikownia systemd-nspawn[84905]: [ OK ] Started Update UTMP about System Runlevel Changes. Feb 03 01:57:29 morfikownia systemd-nspawn[84905]: Debian GNU/Linux 8 www console # machinectl MACHINE CONTAINER SERVICE debian-tree container nspawn 1 machines listed. # machinectl status debian-tree debian-tree Since: Tue 2015-02-03 01:57:24 CET; 2min 54s ago Leader: 84906 (systemd) Service: nspawn; class container Root: /media/Kabi/debian-tree Iface: br_lxc Address: 192.168.10.10 fe80::541b:d0ff:febc:c38c%7 OS: Debian GNU/Linux 8 (jessie) Unit: machine-debian\x2dtree.scope ├─84906 /lib/systemd/systemd 3 └─system.slice ├─dbus.service │ └─85024 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation ├─cron.service │ └─85003 /usr/sbin/cron -f ├─apache2.service │ ├─85427 /usr/sbin/apache2 -k start │ ├─85454 /usr/sbin/apache2 -k start │ ├─85485 /usr/sbin/apache2 -k start │ ├─85486 /usr/sbin/apache2 -k start │ ├─85488 /usr/sbin/apache2 -k start │ ├─85489 /usr/sbin/apache2 -k start │ └─85491 /usr/sbin/apache2 -k start ├─systemd-journald.service │ └─84941 /lib/systemd/systemd-journald ├─systemd-logind.service │ └─85006 /lib/systemd/systemd-logind ├─mysql.service │ ├─85057 /bin/sh /usr/bin/mysqld_safe │ └─85415 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql --log-error=/var/log/mysql/error.log --pid-file=/var/run... ├─console-getty.service │ └─85055 /sbin/agetty --noclear --keep-baud console 115200 38400 9600 vt102 └─rsyslog.service └─85051 /usr/sbin/rsyslogd -n Inside of the container I added the following configuration to its network interface: auto host0 iface host0 inet static address 192.168.10.10 network 192.168.10.0/24 netmask 255.255.255.0 broadcast 192.168.10.255 gateway 192.168.10.100 Communication works (ping from the container): root@www:~# ping 8.8.8.8 PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data. 64 bytes from 8.8.8.8: icmp_seq=1 ttl=52
Re: [systemd-devel] Second (erroneous) check of rootfs?
On Thu, 08.01.15 16:34, Harald Hoyer (harald.ho...@gmail.com) wrote: IMHO systemd-fsck-root.service should be removed entirely and generated by the fstab-generator in the real root like all the other mount points. Well, we also need it if there's no /etc/fstab... OR fstab-generator should create systemd-fsck-root.service for the /sysroot mountpoint in the initrd, which then will be serialized. That sounds like a good idea. 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] Autocompletion by default in containers and typo on systemctl.in
On Thu, 29.01.15 05:44, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Sat, Jan 10, 2015 at 01:29:11AM +0100, Carlos Morata Castillo wrote: Hi, 1- It'll be nice if when you nspawn a container it'll have autocompletion enabled by default. Just need to execute this line: . /usr/share/bash-completion/bash_completion (This file is /usr/share/bash-completion/bash_completion/systemctl by default in bash-completion) There's no guarantee that the container has the same (or even similar) shell, systemd version, etc. Why do you think completions shouldn't happen through the normal process where stuff is installed into the container if it so be used there? Yeah, I fully agree with Zbigniew here. This is something the distro and shell maintainers have to figure out between themselves, systemd should not be involved... 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] Questions regarding dbus started via systemd --user
On Thu, 08.01.15 14:36, Colin Guthrie (gm...@colin.guthr.ie) wrote: (Sorry for the late reply. Still busy processing all the queued mails. I figure half of what this mail was about was already discussed on the hackfest last friday, but in case something was missing, here we go) Lennart Poettering wrote on 08/01/15 13:19: On Thu, 08.01.15 11:55, Colin Guthrie (co...@mageia.org) wrote: Hi, I'm just playing around with this and making some progress. I've got a modified dbus-launch that can be slotted in nicely to poke dbus activated via systemd and teach it about the environment for subsequent launching. It also pokes systemd --user with the environment too. It's pretty simply and allows for experimentation without too much impact. The issue I currently have is that the dbus daemon itself is now part of the user@.service cgroup and NOT part of the session cgroup i.e. here it is: 4:devices:/user.slice,1:name=systemd:/user.slice/user-603.slice/user@603.service/dbus.service rather than in say: 4:devices:/user.slice,1:name=systemd:/user.slice/user-603.slice/session-c2.scope I guess my question is: Is this OK? Yes, the idea is that these services become singleton services of the user, and the sessions ultimately only retain a stub process that does little more than maybe invoke something via systemd and hang around until log out. Ahh OK, so this would be a change in the socket activation code in systemd --user. Once that works, this might just move over the the session? Note sure I follow on this one. Which socket activation code do you precisely mean? But dbus-daemon itself might be excluded from that no? I mean the model is now one-dbus per user and thus it should be shared by all sessions, therefore it cannot live within a session itself right? Well, I mean, we only ever put this altogether for kdbus, where systemd itself is the one setting up the bus. But yeah, if you want to make this all work with dbus-daemon, then you would have to teach it bus activation support. Most likely that should be really easy, and just involves also installing a dbus.socket and dbus.service into the user unit dir. But obviously the stuff *spawned* by dbus should be within a particular session (i.e. dbus would perhaps have to query logind when spawning to get the right session - similar in concept to how Kay's patch for polkit queries logind to get the current display session)? No, all stuff should be forked off systemd, and hence be outside of any immediate user ssession, and instead be a per-user singleton. 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] slow systemd-networkd DHCP client on wlan0 with systemd v217
On Sun, 11.01.15 18:45, Charles Devereaux (syst...@guylhem.net) wrote: What's not is the time it takes to systemd-networkd : 1 second for IPv6 is acceptable (I'm using SLAAC with radvd on the other end), but for ipv4 it's more like 3 seconds, plus another 3 to use the proper DNS server (!!) [...] So basically, I don't know why it's so slow, except that it comes from DHCP IPv4 Tom has fixed that with d4cdbea5550ae9defa1c731ffe091837d329fec7, could you please verify? 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] Programmatically setting udev properties
On Mon, Feb 02, 2015 at 12:57:24PM +0100, Lennart Poettering wrote: On Fri, 30.01.15 08:12, Peter Hutterer (peter.hutte...@who-t.net) wrote: Hi, I need some sort of way of assigning udev properties on the fly to a device, but I'm short of ideas how to do this sensibly. THis is explicitly not supported. Conceptually udev only supports new, change and removed events, and there's no way to change only individual props. if you want to change individual props, you need to plug them into the rules files, and retrigger the device as a whole, which will not only refresh the props you are interested but all props of the device. A bit more context: The libinput test suite works by setting up uinput devices for each test case, then hooking libinput contexts up to those devices. libinput itself uses some udev properties to adjust internal behaviours. That works for real hardware because the rules are written for that (and we can require a make install) but uinput devices don't have the same hierarchy and thus don't trigger those rules. Plus, requiring an install before running the test suite isn't very nice. So basically what I'd like would be a udev_device_set_property() call or something similar. We're in control of the uinput and the libinput bits, i.e. there are no race conditions to worry about. Because of uinput, the test suite runs as root. One solution would be to drop a custom test rule, reload, create the uinput device, run the test, rm the rule again. Not pretty though, I was hoping there was something nicer. Any ideas? Sorry, this is not available, and we explicitly don't want that as people would misuse it if it existed. It would require inventing a new notifciation scheme for individual prop changes, and we don#t want that. Note that udev reads udev rules from /run, so you could drop them there, then retrigger the device (by writing change into the device's uevent file in /sys), and remove the rule afterwards. Other than that umockdev and LD_PRELOAD hacks might be options for test cases like this... ok, no worries. thanks for the answers, we're going with the /run option now, which isn't 100% perfect but close enough for the tests we need at the moment. Cheers, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Questions regarding dbus started via systemd --user
On Thu, 08.01.15 17:42, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote: It also means you can't use D-Bus names as single-instance mutexes to avoid last write wins, earlier writes are lost (or worse!) data corruption in the home directory, because it allows more than one D-Bus session to share a home directory, even in the absence of NFS or whatever. This was meant to be one of the uses of D-Bus name ownership semantics, so it's a pity that it has never worked in the general case. Finally, there is no canonical list of the situations that the session bus does and doesn't support, so whenever someone raises a bug or feature request about one of the corner cases, nobody knows whether it's a bug or a feature request or just wrong. Typical corner cases include: True, hence we only enabled user session management with upstart on the graphical logins. However, we also included facilities to join/part a given user session. Thus one can join a given upstart session id, and control it, query it's environment and move into that environment. (Not automated, but there are qa scripts that do that for validation) I'd ver very careful with concepts of joining and parting sessions. A session is made up of tons of different things, and some are hard to see or even impossible to alter. For example, if you have a MAC system like selinux you cannot easily patch around in the labels during runtime if you want to change it orthogonally to normal process inheritance. But it's not just that. For example, you cannot override audit login/session ids after you wrote them once for a process and its children. This means, if you introduce concepts for joining and parting, then your audit traces start to deviate from the rest of the system's idea of a session, and then things get really annoying. I'd really try to stay away from concepts of parting/joining, it's hard to know and patch all process attribs that requires, and even impossible for some of them. 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] Propagate reload from RELOADING=1 notifications
On Tue, 06.01.15 16:33, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: Isn't that just bad behavior? Sending a RELOADING=1 notification after a reload is initiated? I guess if both service_enter_reload() and service_enter_reload_by_notify() are called it is justified to propagate two reloads. Before testing it might be nice to know what we want :-). Hm. Looking at the code, sending periodic RELOADING=1 notifications can be used to sidestep the timeouts. This does not look OK, but maybe I'm misreading the code. I think you are reading the code right. Not sure though whether that should be considered a bug though... 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] test-dhcp-client failing in mock builds
On Mon, Feb 02, 2015 at 08:30:43AM +0100, Jan Synacek wrote: http://lists.freedesktop.org/archives/systemd-devel/2014-December/026190.html I haven't got time to properly analyze the problem since then... It sounded familiar ;) On Mon, Feb 02, 2015 at 01:36:29PM +0200, Patrik Flykt wrote: Operation not permitted is what is printed for EPERM. But EPERM is not present in the client code itself, so I'm inclined towards a permission problem somewhere when running mock. EPERM is also returned when using /dev/null in epoll_ctl_add. I think I fixed it now. Which leads to a failure on arm in test-network: FAIL: test-network == Assertion '!address_equal(a1, a2)' failed at ../src/network/test-network.c:161, function test_address_equality(). Aborting. I got out my chromebook to see what going on here. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Questions regarding dbus started via systemd --user
On Fri, 09.01.15 10:26, Colin Guthrie (gm...@colin.guthr.ie) wrote: Colin Guthrie wrote on 08/01/15 11:55: I solved this by adding a user unit for gnome-termnial-server and making dbus use systemd activation for it, but that just moves it to a different cgroup. I guess it's OK like this. Just as a minor curiosity related to this bit... I discovered today that handing this particular process over to as systemd --user unit is a bit broken! It seems that gnome-terminal-server will exit when the last gnome-terminal dies. If you have started any programs in the background in the terminal (xeyes, or even screen) and then close all your gnome-terminal processes, the main process of the cgroup becomes empty and then all the child processes are (correctly) reaped by systemd --user Fun! The screen example is a tough one here tho' with gnome-terminal-server. Since I removed it's own systemd unit, it will now live in the dbus daemon's cgroup and depending when the daemon dies, it not survive a logout... will have to check that! Might be OK tho'. Playing with systemd --user is fun :) Ideally gnome-terminal would open a user scope unit for each of its tabs. This would allow them to survive, even without patching KillMode= for the g-t-s service... 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] Callback of sd_bus_track: when it will be invoked
On Fri, 30.01.15 15:18, cee1 (fykc...@gmail.com) wrote: Hi all, I notice in sd_bus_track_new, a callback can be specified, but when it will be invoked? It seems it will not be triggered when a name in track is removed. But that's what it is supposed to be used for. You need to run an event loop for this, and attach the bus object to it though. i.e. either run an sd_event event loop and use sd_bus_attach_event(), or use some other event loop and integrate sd-bus into it. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH 2/2] localed: add LANGUAGE= fallback?when LANG= is specified
On Mon, Feb 02, 2015 at 07:11:04AM +, Jan Janssen wrote: Zbigniew Jędrzejewski-Szmek zbyszek at in.waw.pl writes: I think the implementation is fine, since it is rather trivial, but I'm less certain about the implications of setting LANGUAGE in addtion to LANG. Zbyszek Isn't this something that should be in glibc's lang/locale handling code? They probably could in principle, but those settings are somewhat arbitrary and at a higher level than libc usually operates. We are already taking care of configuration of a lot of related stuff, so this seems a natural extension. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH 2/2] localed: add LANGUAGE= fallback when LANG= is specified
On Mon, Feb 02, 2015 at 11:56:39AM +0100, Martin Pitt wrote: Zbigniew Jędrzejewski-Szmek [2015-01-31 20:20 +0100]: I think the implementation is fine, since it is rather trivial, but I'm less certain about the implications of setting LANGUAGE in addtion to LANG. That's totally fine -- it's precisely what $LANGUAGE is meant for. One must be aware that it is a GNU extension, i. e. software like thunderbird won't respect it and thus just use $LANG (in which case you are no worse than now). But pretty much all native Linux sofware does and thus will behave as intended. We've used this schema in Ubuntu since around 2005 [1]. Thanks. Incomplete support sounds fine. Now, I wish such a fallback list would be in upstream glibc so that OSes, systemd etc. wouldn't have to repeat and maintain it; but while [1] looks quite complex, it hasn't really changed in years. Looking at the list, I'm wondering about using en_GB as the fallback for most locales. I guess that for European countries it makes some sense, but for Japanese, Kazakh, and many other places, I'd expect en_US to be better last choice. Especially that en_US translation coverage is more complete than en_GB. Also, I'd expect a fallback to Russian before English for Kazakh, it's their second official language. If this patch goes in, I'm happy to augment the list according to [1] and then move our language-selector to use that instead, to reduce duplication. Great. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: typos in systemd-network.xml regarding DHCP
Hmm. Interesting. Something went sideways with the compatibility. The lineage of this patch is due to the following errors: Jan 31 14:43:30 localhost systemd[1]: Starting Network Service... -- Subject: Unit systemd-networkd.service has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit systemd-networkd.service has begun starting up. Jan 31 14:43:30 localhost systemd-networkd[464]: [/etc/systemd/network/zz-default.network:2] Failed to parse DHCP option, ignoring: ipv4 Jan 31 14:43:30 localhost systemd[1]: Started Network Service. -- Subject: Unit systemd-networkd.service has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit systemd-networkd.service has finished starting up. -- -- The start-up result is done. Jan 31 14:46:20 localhost systemd[1]: Starting Network Service... -- Subject: Unit systemd-networkd.service has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit systemd-networkd.service has begun starting up. Jan 31 14:46:20 localhost systemd-networkd[609]: [/etc/systemd/network/zz-default.network:2] Failed to parse DHCP option, ignoring: ipv6 Jan 31 14:46:20 localhost systemd[1]: Started Network Service. -- Subject: Unit systemd-networkd.service has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit systemd-networkd.service has finished starting up. -- -- The start-up result is done. --Brian 'redbeard' Harrington --CoreOS On 02/02/2015 03:26 AM, Lennart Poettering wrote: On Sat, 31.01.15 16:16, Brian Redbeard (redbe...@dead-city.org) wrote: In the systemd documentation for systemd.network units the [Network] section notes that for the option DHCP=: DHCP= Enables DHCPv4 and/or DHCPv6 support. Accepts yes, no, ipv4 or ipv6. In testing the options ipv4 and ipv6 are actually implemented as v4 and v6. Additionally on the same page in Example 2 the sample is give: [Network] DHCP=both which is not referenced in the above option. This is due to a recent change: cb9fc36a1211967e8c58b0502a26c42552ac8060 Basically, the intention here is that options like this work as per-address-family booleans. i.e. they primarily parse as booleans, but you can also assign them the special value ipv4 and ipv6, which turns them on only for one of the two address families. The old names for the options are still accepted for compat, but we only document the new names, to make people use only the new names. Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] test-dhcp-client failing in mock builds
Hi, On Sat, 2015-01-31 at 15:48 +0100, Zbigniew Jędrzejewski-Szmek wrote: DHCP CLIENT (0xa71f5099): STARTED on ifindex 42 DHCP CLIENT (0xa71f5099): DISCOVER DHCP CLIENT (0xa71f5099): OFFER DHCP CLIENT (0xa71f5099): REQUEST (requesting) DHCP CLIENT (0xa71f5099): ACK DHCP CLIENT (0xa71f5099): lease expires in 9min 58.349975s DHCP CLIENT (0xa71f5099): T2 expires in 8min 43.759020s DHCP CLIENT (0xa71f5099): T1 expires in 4min 59.245773s Up until here everything is fine, and the proper messages are sent back and forth between the client code and the test program which pretends to be the server in this scenario. DHCP CLIENT (0xa71f5099): STOPPED: Operation not permitted This printout comes from client_stop(sd_dhcp_client *client, int error) when given a negative error value. Operation not permitted is what is printed for EPERM. But EPERM is not present in the client code itself, so I'm inclined towards a permission problem somewhere when running mock. In function client_handle_message(), the function call to client_set_lease_timeouts() is the one printing the T2 and T1 expiration values. After this function, the first possible call to client_stop() containing a negative value which that does not log additional strings beforehand happens in client_initialize_io_events(). This if the io handler cannot be (re?)set for some reason. It seems there already exists an io handler at this point, but why it should fail only for mock is something I don't understand. The test program just worksforme too. It can't really be the following client_notify(client, notify_event) call either, as notify_event = 0 or r, where r must have been = 0 to begin with. If it was client_handle_ack() that returned 0 a little bit earlier, no T2 and T1 timers would have been set. With the above I was assuming that the latest version was used and not an older release. Cheers, Patrik ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 01/12] fsckd daemon for inter-fsckd communication
Le 31/01/2015 01:34, Zbigniew Jędrzejewski-Szmek a écrit :
On Thu, Jan 29, 2015 at 06:37:53PM +0100, Didier Roche wrote:
Le 28/01/2015 15:37, Zbigniew Jędrzejewski-Szmek a écrit :
On Wed, Jan 28, 2015 at 02:20:40PM +0100, Didier Roche wrote:
\ No newline at end of file
diff --git a/src/fsckd/fsckd.c b/src/fsckd/fsckd.c
new file mode 100644
index 000..3059c68
--- /dev/null
+++ b/src/fsckd/fsckd.c
@@ -0,0 +1,295 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+}
+
+static int handle_requests(int socket_fd) {
+Clients *first = NULL;
+usec_t last_activity = 0;
+int numdevices = 0, clear = 0;
+double percent = 100;
+_cleanup_fclose_ FILE *console = NULL;
NULL not necessary (and you don't have it in similar circumstances above ;))
So, after the discussion on the mailing list and to be more future
proof, I went to recheck, but I'm afraid that I didn't find any
place where I have some _cleanup_* without initializing to NULL? Did
I get it wrong?
fsckd_fd variable.
Right, done with -1 as init. Thanks!
Didier
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 04/12] Add some plymouth functionality to connect and send, messages
Le 31/01/2015 01:39, Zbigniew Jędrzejewski-Szmek a écrit : On Thu, Jan 29, 2015 at 06:43:22PM +0100, Didier Roche wrote: Le 28/01/2015 21:22, Lennart Poettering a écrit : On Wed, 28.01.15 14:22, Didier Roche (didro...@ubuntu.com) wrote: # -- +have_plymouth=no +AC_ARG_ENABLE(plymouth, AS_HELP_STRING([--disable-plymouth], [disable plymouth integration])) +if test x$enable_plymouth != xno; then +PKG_CHECK_MODULES([PLYMOUTH], [ply-boot-client = 0.8.0], +[AC_DEFINE(HAVE_PLYMOUTH, 1, [Define if plymouth is available]) have_plymouth=yes], have_plymouth=no) +if test x$have_plymouth = xno -a x$enable_plymouth = xyes; then +AC_MSG_ERROR([*** plymouth integration requested but libraries not found]) +fi +fi +AM_CONDITIONAL(HAVE_PLYMOUTH, [test $have_plymouth = yes]) Hmm, I am bit concerned about adding this dependency. So far we managed to talk to plymouth without using its library, and I am really not sure we should start doing so now. So far the messages to send were so simply that it really wasn't worth the effort to use the full library. This is doable for the first part, similar to what src/tty-ask-password-agent/tty-ask-password-agent.c is doing (using the socket directly to send update and message to it). I'm quite unsure watch and get key events part as looking at libplymouth code, this seems quite more complex as a protocol to achieve. If you feel that needs to be done anyway, I can look deeper at this if you really feel we should reimplement libplymouth protocol rathen than having an optional dep on it. plymouth-core-libs are 200kb in Fedora. I wouldn't sweat it too much. We discussed it during the hackfest, and got thanks to Lennart's strace suggestion the protocol figured out, will work on that before resending the patch list then (I hope, this week if I get time to look at this). Didier Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] User sessions, session buses, user buses
On 30 January 2015 at 08:30, Simon McVittie simon.mcvit...@collabora.co.uk wrote: Remaining issue: environment variables == Sadly, not all the issues have been resolved yet. The biggest is environment variables: on existing systems there is an expectation that environment variables set by *dm, PAM, or /etc/X11/Xsession.d (or the non-Debian equivalent) will be propagated into every process in the session. In a brief survey of about half the Xsession.d scripts in Debian, I identified these environment variables: * PULSE_SERVER * ESPEAKER * XDG_DATA_HOME, XDG_DATA_DIRS * each variable printed by locale(1) * VDPAU_DRIVER * GTK_IM_MODULE, QT_IM_MODULE, QT4_IM_MODULE, CLUTTER_IM_MODULE, XMODIFIERS * GTK_MODULES And one shall not forget GNOME_DESKTOP_SESSION_ID=this-is-deprecated for a certain C++ toolkit to not look like it's 1995. ;-) plus the obvious ones set by *dm, such as DISPLAY, or by PAM. Similarly, a user's ~/.xsession can set arbitrary variables - mine sets CCACHE_DIR, EDITOR, MPD_HOST and XDG_CONFIG_DIRS, among others. The naive implementation would be to run a tool at the end of /etc/X11/Xsession.d that uploads all of these into `dbus-daemon --session` (if used) and into `systemd --user` (if used). However, not all environment variables set in such scripts are suitable for that use: notably, XDG_SESSION_ID from the login session should not be copied into activated processes that exist outside any login session. The rest of the email thread is adequate. I would like to experiment with a user-bus, potentially in a transient manner to have 3 buses: system, user, session busses. And migrate things from session to user bus experiment as to how much stuff breaks. I think being explicit about session vs user bus would avoid confusion, and will help manifest bugs have a clear migration plan. E.g. when org.freedesktop.Telepathy / ca.desrt.dconf moves to user bus, things should know how to start talking to Telepathy/dconf over user bus. Looking at the stuff that I have on my session dbus, I see quite a few things that do interract with DISPLAY=:0, or rather create GUI windows and expect them to appear in the right place, as in on the currently active seat. Similarly they would need to be migrated/restarted if we ever allow multiple graphical search for a single UID. I wonder if this is at all an actual problem, maybe all current/sophisticated dbus-heavy DEs cannot in fact have multiple graphical sessions for the same UID, in which case switching to user bus today is non-regressing (given that current active graphical session cannot migrate a seat (?! not sure if this)). Going down this rabbit-hole, the only difference between current session-bus (e.g. where under gdm only one graphical login is allowed per UID) and the user-bus seems to be the life-time of the bus (tied from first login until last login V.S. X11 started and finished). That means that dbus-activated services have to simply become seat aware, and know that if they were started on a non-graphical seat, later on active seat might be graphical and thus they should migrate/recreate/create GUI windows on currently active seat - or across all seats if that's appropriate. -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 04/12] Add some plymouth functionality to connect and send, messages
Le 31/01/2015 01:44, Zbigniew Jędrzejewski-Szmek a écrit :
On Thu, Jan 29, 2015 at 06:42:42PM +0100, Didier Roche wrote:
Le 28/01/2015 15:44, Zbigniew Jędrzejewski-Szmek a écrit :
On Wed, Jan 28, 2015 at 02:22:04PM +0100, Didier Roche wrote:
bool plymouth_running(void) {
return access(/run/plymouth/pid, F_OK) = 0;
}
+
+#ifdef HAVE_PLYMOUTH
+bool plymouth_connect(void) {
Is there a particular reason why this cannot return a normal int code?
No reason, I changed to 0 for connected, -1 for can't connect.
No, please return a real return code (-ENOMEM on the allocation failure
in this case). -1 is EPERM.
Done, (even if I think that particular function is going to change with
the libplymouth dep removal.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] tmpfiles: Remove unnecessary blank line when configured with --disable-resolved
This patch removes unnecessary blank line in /usr/lib/tmpfiles.d/etc.conf when configured with --disable-resolved. (i.e. ENABLE_RESOLVED is not defined) Signed-off-by: Sangjung Woo sangjung@samsung.com --- tmpfiles.d/etc.conf.m4 |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tmpfiles.d/etc.conf.m4 b/tmpfiles.d/etc.conf.m4 index f567c8d..9b0e080 100644 --- a/tmpfiles.d/etc.conf.m4 +++ b/tmpfiles.d/etc.conf.m4 @@ -12,6 +12,6 @@ L /etc/localtime - - - - ../usr/share/zoneinfo/UTC L+ /etc/mtab - - - - ../proc/self/mounts m4_ifdef(`ENABLE_RESOLVED', L /etc/resolv.conf - - - - ../run/systemd/resolve/resolv.conf -) +)m4_dnl C /etc/nsswitch.conf - - - - C /etc/pam.d - - - - -- 1.7.9.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: typos in systemd-network.xml regarding DHCP
On Sat, 31.01.15 16:16, Brian Redbeard (redbe...@dead-city.org) wrote: In the systemd documentation for systemd.network units the [Network] section notes that for the option DHCP=: DHCP= Enables DHCPv4 and/or DHCPv6 support. Accepts yes, no, ipv4 or ipv6. In testing the options ipv4 and ipv6 are actually implemented as v4 and v6. Additionally on the same page in Example 2 the sample is give: [Network] DHCP=both which is not referenced in the above option. This is due to a recent change: cb9fc36a1211967e8c58b0502a26c42552ac8060 Basically, the intention here is that options like this work as per-address-family booleans. i.e. they primarily parse as booleans, but you can also assign them the special value ipv4 and ipv6, which turns them on only for one of the two address families. The old names for the options are still accepted for compat, but we only document the new names, to make people use only the new names. 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] Support for staged startup
Hello, thx for the answer. If you do not use --no-block to start your second target, first target will never finish. That's something I cannot confirm. If you define the service, which is calling systemctl start xxx, as oneshot the service will be in state activating for exactly the time needed to bring up the target. Other caveat of your way is that systemd doesn't know about your final target until it receives systemctl start destination.target. Since it doesn't know about the target, units that are requested by destination.target will not have the default dependencies applied. That's true but wanted in my case ;) Best regards Marko Hoyer Software Group II (ADITG/SW2) Tel. +49 5121 49 6948 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Docker vs PrivateTmp
On Fri, 30.01.15 11:02, Alexander Larsson (al...@redhat.com) wrote: I think the problem is that docker daemon makes /var/lib/docker/devicemapper private in the host namespace to handle some scalability issues we found in the kernel. This causes problem not with docker containers (because they unmount all other mounts as per the above), but with other namespace-using apps. For instance, if a service with PrivateTmp is launched, it will inherit the existing mounts in /var/lib/docker/devicemapper at the point of startup, but when these are eventually unmounted in the host namespace this is not propagated into the service (due to it being a private mount, not a slave mount). We could try making this slave instead, but I don't know if that then fixes the scalability issues we had, because they were related to stupidities in the kernel wrt propagating mounts. If it doesn't work, then we have to put docker-daemon in its own namespace. The daemon should first create its own namespace, and then detach propagation, not the other way round. This really isn't stupidity in the kernel, but in docker's userspace... 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] User sessions, session buses, user buses
On 02/02/15 10:22, Dimitri John Ledkov wrote: I would like to experiment with a user-bus, potentially in a transient manner to have 3 buses: system, user, session busses. I still think it's a bad idea to have both a user bus and a session bus. Having things on the wrong bus is definitely an API break, and having processes' messages be out-of-order will break application expectations (message order is guaranteed to be a consistent total ordering within one bus, but you can't even rely on causal ordering across multiple buses). E.g. when org.freedesktop.Telepathy / ca.desrt.dconf moves to user bus, things should know how to start talking to Telepathy/dconf over user bus. If you have both buses, this is a flag-day API break for each thing that moves. Please don't go there if you want to reach a user bus in a finite time. If you only have a session bus, where session is taken to mean either login session or user-session/super-session depending on a choice made by the OS integrator and/or sysadmin, you don't get that problem. I wonder if this is at all an actual problem, maybe all current/sophisticated dbus-heavy DEs cannot in fact have multiple graphical sessions for the same UID, in which case switching to user bus today is non-regressing (given that current active graphical session cannot migrate a seat (?! not sure if this)). GNOME (at least, if you have the full GNOME suite including gdm) specifically does not support more than one graphical session per seat: if you are logged in (with screen locked) on tty7, and you type your username and password into a Switch User gdm prompt on tty8, gdm will just switch to tty7 and unlock your screen. I think this is a perfectly reasonable model. I don't know about multiple seats as the same user, but I suspect that, in practice, it doesn't work very well (if at all) and in any case, why would you? You are only physically in one place after all :-) I believe the situation last time we discussed this was that KDE does support more than one simultaneous graphical session, but Thiago was unsure whether that was by policy or coincidence. Going down this rabbit-hole, the only difference between current session-bus (e.g. where under gdm only one graphical login is allowed per UID) and the user-bus seems to be the life-time of the bus (tied from first login until last login V.S. X11 started and finished). Yes. This is part of the reasoning behind the mental model that Havoc proposed last time this was discussed: this is not about the D-Bus maintainers deciding how long a D-Bus bus lasts, but about OS integrators deciding how long a session lasts (or to put it another way, which of the multiple possible definitions of session should be the one used for D-Bus). When you think of it like that, the decision point becomes whether the OS integrator wants: * dbus-launch manages one session bus per X11 session (current reality, and apparently some people strongly prefer it this way) * dbus.socket/dbus.service manages one session bus per user-session/super-session (I anticipate that e.g. Fedora and GNOME-Continuous will probably make this simplification mandatory) * punt the decision to the sysadmin via whether an optional dbus-user-bus.deb, or RPM equivalent, is installed (I suspect I will have to support both ways for Debian for a while) Over time, as GUI things adjust to the 'systemd --user'-style model, I anticipate that the disadvantages of the user-session bus will decrease and its advantages will increase; maybe one day nobody will use dbus-launch and it can be deleted. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: typos in systemd-network.xml regarding DHCP
NM. I wasn't quite following. I just re-parsed the statement: The old names for the options are still accepted for compat, but we only document the new names, to make people use only the new names. While this was on systemd218 I just realized the commit is only as of a few weeks ago. Comes down to local vs upstream man pages. Thanks for the clarification. --Brian 'redbeard' Harrington --CoreOS On 02/02/2015 03:30 AM, Brian Redbeard wrote: Hmm. Interesting. Something went sideways with the compatibility. The lineage of this patch is due to the following errors: Jan 31 14:43:30 localhost systemd[1]: Starting Network Service... -- Subject: Unit systemd-networkd.service has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Docker vs PrivateTmp
On mån, 2015-02-02 at 12:12 +0100, Lennart Poettering wrote: On Fri, 30.01.15 11:02, Alexander Larsson (al...@redhat.com) wrote: I think the problem is that docker daemon makes /var/lib/docker/devicemapper private in the host namespace to handle some scalability issues we found in the kernel. This causes problem not with docker containers (because they unmount all other mounts as per the above), but with other namespace-using apps. For instance, if a service with PrivateTmp is launched, it will inherit the existing mounts in /var/lib/docker/devicemapper at the point of startup, but when these are eventually unmounted in the host namespace this is not propagated into the service (due to it being a private mount, not a slave mount). We could try making this slave instead, but I don't know if that then fixes the scalability issues we had, because they were related to stupidities in the kernel wrt propagating mounts. If it doesn't work, then we have to put docker-daemon in its own namespace. The daemon should first create its own namespace, and then detach propagation, not the other way round. This really isn't stupidity in the kernel, but in docker's userspace... The stupidity was the O(n^4) algorithm in the kernel when it was duplicating all vfsmounts that could possibly be propagated, and then immediately freeing them when they did not propagate, which interacted poorly with some lame kernel O(n^2) allocator behaviour. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander LarssonRed Hat, Inc al...@redhat.comalexander.lars...@gmail.com He's an oversexed shark-wrestling rock star from the 'hood. She's a high-kicking cigar-chomping former first lady with the power to see death. They fight crime! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] BUG: several bugs in core/main.c (v218)
On Thu, 29.01.15 21:54, tomazzi (toma...@wp.pl) wrote: But that's not really a problem, since the handler is not even re-entrant (f.e. due to dynamic memory allocation performed trough log_ macros - log_full_errno - log_internal - journal-send.c::_printf_() - vasprintf() ) There is no such call chain. log_internal() does not invoke any function from journal-send.c. Our internal non-structured logging code does not allocate dynamic memory, since we want to be able to aclal it in signal handlers, and allocating dynamic memory is not OK in signal handlers. The structured logging code does allocate memory (log_struct() and friends), simply because I couldn't find a nice way how to pull that off. However this should not really be a limitation, the rule is simply that our signal handlers should not invoke structured logging functions, but only the non-structured ones. 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] Programmatically setting udev properties
On Fri, 30.01.15 08:12, Peter Hutterer (peter.hutte...@who-t.net) wrote: Hi, I need some sort of way of assigning udev properties on the fly to a device, but I'm short of ideas how to do this sensibly. THis is explicitly not supported. Conceptually udev only supports new, change and removed events, and there's no way to change only individual props. if you want to change individual props, you need to plug them into the rules files, and retrigger the device as a whole, which will not only refresh the props you are interested but all props of the device. A bit more context: The libinput test suite works by setting up uinput devices for each test case, then hooking libinput contexts up to those devices. libinput itself uses some udev properties to adjust internal behaviours. That works for real hardware because the rules are written for that (and we can require a make install) but uinput devices don't have the same hierarchy and thus don't trigger those rules. Plus, requiring an install before running the test suite isn't very nice. So basically what I'd like would be a udev_device_set_property() call or something similar. We're in control of the uinput and the libinput bits, i.e. there are no race conditions to worry about. Because of uinput, the test suite runs as root. One solution would be to drop a custom test rule, reload, create the uinput device, run the test, rm the rule again. Not pretty though, I was hoping there was something nicer. Any ideas? Sorry, this is not available, and we explicitly don't want that as people would misuse it if it existed. It would require inventing a new notifciation scheme for individual prop changes, and we don#t want that. Note that udev reads udev rules from /run, so you could drop them there, then retrigger the device (by writing change into the device's uevent file in /sys), and remove the rule afterwards. Other than that umockdev and LD_PRELOAD hacks might be options for test cases like this... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH 2/2] localed: add LANGUAGE= fallback when LANG= is specified
Zbigniew Jędrzejewski-Szmek [2015-01-31 20:20 +0100]: I think the implementation is fine, since it is rather trivial, but I'm less certain about the implications of setting LANGUAGE in addtion to LANG. That's totally fine -- it's precisely what $LANGUAGE is meant for. One must be aware that it is a GNU extension, i. e. software like thunderbird won't respect it and thus just use $LANG (in which case you are no worse than now). But pretty much all native Linux sofware does and thus will behave as intended. We've used this schema in Ubuntu since around 2005 [1]. Now, I wish such a fallback list would be in upstream glibc so that OSes, systemd etc. wouldn't have to repeat and maintain it; but while [1] looks quite complex, it hasn't really changed in years. If this patch goes in, I'm happy to augment the list according to [1] and then move our language-selector to use that instead, to reduce duplication. Martin [1] http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/vivid/language-selector/vivid/view/head:/data/languagelist -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Support for staged startup
Hello, thx for the answer. Why not start the final sub-tree units the conventional way, but make them all wait, listening on sockets?A final service need not contain a 'systemctl start xxx.target' command, as instead it could simply write a message to those sockets. Some services could receive a signal telling them to terminate, and others telling them to continue. Ok good idea. But finally this is (effort wise) the same like calling systemctl (kick off one process, which communicates via IPC with another one). If it is now my own socket or the systemd control socket does not really matter. Given that it's possible to specify the startup service in the kernel command line with system.unit=, the engineer configuring the startup sequence could specify a variety of alternate dependency trees.Each tree would have a different unit at its head.The units in one tree need not appear in another at all, or they could appear in the second tree in a different order. That's possible as well but might get a bit too complex for a bit more dynamics. This finally depends probably on the actual use case. Ok I guess what I learned from your answers now is that the systemctl approach is probably the best one for my concrete use case. Thx all for sharing your thoughts. Best regards Marko Hoyer Software Group II (ADITG/SW2) Tel. +49 5121 49 6948 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] I see Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory in systemd journal when I log in as root via ssh.
Below is the relevant part of the systemd journal log. /usr/lib/systemd/systemd exists, but the journal says it doesn't exist sometimes when I log in as root via ssh. Feb 03 12:28:21 arch-server sshd[15918]: Accepted publickey for root from 192.168.1.3 port 56913 ssh2: RSA 52:ec:f5:00:67:40:96:a6:47:de:e0:f6:3f:58:80:83 Feb 03 12:28:21 arch-server sshd[15918]: pam_unix(sshd:session): session opened for user root by (uid=0) Feb 03 12:28:21 arch-server systemd[1]: Starting user-0.slice. -- Subject: Unit user-0.slice has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit user-0.slice has begun starting up. Feb 03 12:28:21 arch-server systemd[1]: Created slice user-0.slice. -- Subject: Unit user-0.slice has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit user-0.slice has finished starting up. -- -- The start-up result is done. Feb 03 12:28:21 arch-server systemd[1]: Starting User Manager for UID 0... -- Subject: Unit user@0.service has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit user@0.service has begun starting up. Feb 03 12:28:21 arch-server systemd[1]: Starting Session c209 of user root. -- Subject: Unit session-c209.scope has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit session-c209.scope has begun starting up. Feb 03 12:28:21 arch-server systemd-logind[460]: New session c209 of user root. -- Subject: A new session c209 has been created for user root -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- Documentation: http://www.freedesktop.org/wiki/Software/systemd/multiseat -- -- A new session with the ID c209 has been created for the user root. -- -- The leading process of the session is 15918. Feb 03 12:28:21 arch-server systemd[1]: Started Session c209 of user root. -- Subject: Unit session-c209.scope has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit session-c209.scope has finished starting up. -- -- The start-up result is done. Feb 03 12:28:21 arch-server systemd[15920]: Failed at step CGROUP spawning /usr/lib/systemd/systemd: No such file or directory -- Subject: Process /usr/lib/systemd/systemd could not be executed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- The process /usr/lib/systemd/systemd could not be executed and failed. -- -- The error number returned while executing this process is 2. Feb 03 12:28:21 arch-server systemd[1]: Started User Manager for UID 0. -- Subject: Unit user@0.service has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit user@0.service has finished starting up. -- -- The start-up result is done. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Ensure that systemd is the init called after using bootchart
Ça va Sebastien, Sebastien Bacher [2015-02-02 16:14 +0100]: When booting with systemd-bootchart, default to call the systemd binary rather than the init binary on disk, which might be another init system. Collecting data doesn't work out of systemd. I'm not a native speaker either, but out of systemd sounds strange. only works with booting systemd.? -#define DEFAULT_INIT /sbin/init +#ifdef HAVE_SPLIT_USR +#define DEFAULT_INIT /lib/systemd/systemd +#else +#define DEFAULT_INIT /usr/lib/systemd/systemd +#endif Since ./configure allows you to specify paths independent from --enable-split-usr, IMHO it is more robust to do #define DEFAULT_INIT ROOTLIBDIR /systemd/systemd The idea sounds sane in general, though. Specifying init=/usr/lib/systemd/systemd-bootchart is pretty explicit about which init system one wants. Merci, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Ensure that systemd is the init called after using bootchart
On 2 February 2015 at 15:14, Sebastien Bacher seb...@ubuntu.com wrote: Hey systemd hackers, While trying systemd-bootchart on my Ubuntu vivid system I ran into some issues. My system has upstart as /sbin/init, but I use init=/lib/systemd/systemd and that works fine. Today I tried to change that to /lib/systemd/systemd-bootchart but the charting failed on a missing /run/log. Turns out that it's because systemd-bootchart runs /sbin/init by default, would it make sense to run the systemd binary instead? I'm attaching a patch that does that +1 from me. Not because of upstart, but becuase I see people hacking in /sbin/init symlink just because of bootchart. Alternatively one can set Init option in the bootchart.conf file, but defaulting to systemd install location is better imho. -- Regards, Dimitri. Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup: Do not warn If the key is /dev/*random
El 02/02/15 a las 12:42, Lennart Poettering escribió: I'd prefer if we'd change the check instead to only apply to S_ISREG() files. This way we wouldn't have to list all RNG device nodes. Yeah.. the other version I had did a !S_ISCHR check but S_ISREG is more adequate in this case. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Ensure that systemd is the init called after using bootchart
On Mon, 02.02.15 16:14, Sebastien Bacher (seb...@ubuntu.com) wrote: Hey systemd hackers, While trying systemd-bootchart on my Ubuntu vivid system I ran into some issues. My system has upstart as /sbin/init, but I use init=/lib/systemd/systemd and that works fine. Today I tried to change that to /lib/systemd/systemd-bootchart but the charting failed on a missing /run/log. Turns out that it's because systemd-bootchart runs /sbin/init by default, would it make sense to run the systemd binary instead? I'm attaching a patch that does that Generally makes sense. The canonical path for systemd is /usr/lib/systemd/systemd, hence we should invoke that. That siad, please make the change Martin suggested in the other mail and reuse ROOTLIBDIR. Looks good otherwise. 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] Ensure that systemd is the init called after using bootchart
On 02/02/2015 03:32 PM, Dimitri John Ledkov wrote: On 2 February 2015 at 15:14, Sebastien Bacher seb...@ubuntu.com wrote: Hey systemd hackers, While trying systemd-bootchart on my Ubuntu vivid system I ran into some issues. My system has upstart as /sbin/init, but I use init=/lib/systemd/systemd and that works fine. Today I tried to change that to /lib/systemd/systemd-bootchart but the charting failed on a missing /run/log. Turns out that it's because systemd-bootchart runs /sbin/init by default, would it make sense to run the systemd binary instead? I'm attaching a patch that does that +1 from me. Not because of upstart, but becuase I see people hacking in /sbin/init symlink just because of bootchart. Alternatively one can set Init option in the bootchart.conf file, but defaulting to systemd install location is better imho. systemd-bootchart is integrated and intended to be used with systemd as the default init system people should use alternative bootcharts to use with their alternative init system JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup: Do not warn If the key is /dev/*random
Hey Cristian, Cristian Rodríguez [2015-02-02 12:06 -0300]: Using /dev/urandom as a key is valid for swap, do not warn if this devices are world readable. Thanks! Simple enough, applied. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] cryptsetup: Do not warn If the key is /dev/*random
Using /dev/urandom as a key is valid for swap, do not
warn if this devices are world readable.
---
src/cryptsetup/cryptsetup.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index e6b37ac..38930ae 100644
--- a/src/cryptsetup/cryptsetup.c
+++ b/src/cryptsetup/cryptsetup.c
@@ -624,8 +624,10 @@ int main(int argc, char *argv[]) {
/* Ideally we'd do this on the open fd, but since this
is just a
* warning it's OK to do this in two steps. */
-if (stat(key_file, st) = 0 (st.st_mode 0005))
-log_warning(Key file %s is world-readable.
This is not a good idea!, key_file);
+if (stat(key_file, st) = 0 (st.st_mode 0005)) {
+if(!STR_IN_SET(key_file, /dev/urandom,
/dev/random, /dev/hw_random))
+log_warning(Key file %s is
world-readable. This is not a good idea!, key_file);
+}
}
for (tries = 0; arg_tries == 0 || tries arg_tries; tries++) {
--
2.2.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Ensure that systemd is the init called after using bootchart
Hey systemd hackers,
While trying systemd-bootchart on my Ubuntu vivid system I ran into some
issues. My system has upstart as /sbin/init, but I use
init=/lib/systemd/systemd and that works fine. Today I tried to change
that to /lib/systemd/systemd-bootchart but the charting failed on a
missing /run/log. Turns out that it's because systemd-bootchart runs
/sbin/init by default, would it make sense to run the systemd binary
instead? I'm attaching a patch that does that
Cheers,
Sebastien Bacher
From 60783beb0cad6dc55be8591b8648e00a38fe9210 Mon Sep 17 00:00:00 2001
From: Sebastien Bacher seb...@ubuntu.com
Date: Mon, 2 Feb 2015 15:48:40 +0100
Subject: [PATCH] Ensure that systemd is the init called after using bootchart
When booting with systemd-bootchart, default to call the systemd binary
rather than the init binary on disk, which might be another init system.
Collecting data doesn't work out of systemd.
---
man/bootchart.conf.xml| 2 +-
man/systemd-bootchart.xml | 4 ++--
src/bootchart/bootchart.c | 8 ++--
3 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/man/bootchart.conf.xml b/man/bootchart.conf.xml
index a364826..e11ccb5 100644
--- a/man/bootchart.conf.xml
+++ b/man/bootchart.conf.xml
@@ -124,7 +124,7 @@
varlistentry
termvarnameInit=[path]/varname/term
listitemparaConfigures bootchart to run a non-standard
-binary instead of filename/sbin/init/filename. This
+binary instead of filename/usr/lib/systemd/systemd/filename. This
option is only relevant if bootchart was invoked from the
kernel command line with
init=/usr/lib/systemd/systemd-bootchart./para/listitem
diff --git a/man/systemd-bootchart.xml b/man/systemd-bootchart.xml
index 0068e92..ff86be2 100644
--- a/man/systemd-bootchart.xml
+++ b/man/systemd-bootchart.xml
@@ -116,7 +116,7 @@
commandsystemd-bootchart/command
instead of the init process. In turn,
commandsystemd-bootchart/command
-will invoke command/sbin/init/command.
+will invoke command/usr/lib/systemd/systemd/command.
/para/listitem
/varlistentry
@@ -218,7 +218,7 @@
termoption-i/option/term
termoption--init replaceablepath/replaceable/option/term
listitemparaUse this init binary. Defaults to
-command/sbin/init/command.
+command/usr/lib/systemd/systemd/command.
/para/listitem
/varlistentry
diff --git a/src/bootchart/bootchart.c b/src/bootchart/bootchart.c
index 0808ba4..99ad745 100644
--- a/src/bootchart/bootchart.c
+++ b/src/bootchart/bootchart.c
@@ -76,7 +76,11 @@ int sysfd=-1;
#define DEFAULT_HZ 25.0
#define DEFAULT_SCALE_X 100.0 /* 100px = 1sec */
#define DEFAULT_SCALE_Y 20.0 /* 16px = 1 process bar */
-#define DEFAULT_INIT /sbin/init
+#ifdef HAVE_SPLIT_USR
+#define DEFAULT_INIT /lib/systemd/systemd
+#else
+#define DEFAULT_INIT /usr/lib/systemd/systemd
+#endif
#define DEFAULT_OUTPUT /run/log
/* graph defaults */
@@ -326,7 +330,7 @@ int main(int argc, char *argv[]) {
/*
* If the kernel executed us through init=/usr/lib/systemd/systemd-bootchart, then
* fork:
- * - parent execs executable specified via init_path[] (/sbin/init by default) as pid=1
+ * - parent execs executable specified via init_path[] (/usr/lib/systemd/systemd by default) as pid=1
* - child logs data
*/
if (getpid() == 1) {
--
2.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: Remove unnecessary blank line when configured with --disable-resolved
On Mon, 02.02.15 20:25, Sangjung Woo (sangjung@samsung.com) wrote: This patch removes unnecessary blank line in /usr/lib/tmpfiles.d/etc.conf when configured with --disable-resolved. (i.e. ENABLE_RESOLVED is not defined) Signed-off-by: Sangjung Woo sangjung@samsung.com Thanks! Applied! BTW, we don#t use S-o-b in systemd, hence I removed that line before pushing. Thanks, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH 2/2] localed: add LANGUAGE= fallback when LANG= is specified
On Sat, 31.01.15 20:20, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: For the entries listed in the first column of language-fallback-map, the entry from the second column will be used for LANGUAGE=, if LANGUAGE= is not explicitly specified. Looks conceptually OK to me, sounds like a useful addition! Thanks! 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] backlight: let udev properties override clamping
On Sat, 31.01.15 09:30, Topi Miettinen (toiwo...@gmail.com) wrote:
On 01/29/15 00:09, Lennart Poettering wrote:
On Wed, 28.01.15 23:51, Topi Miettinen (toiwo...@gmail.com) wrote:
diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c
index 1271a66..df53b75 100644
--- a/src/backlight/backlight.c
+++ b/src/backlight/backlight.c
@@ -373,6 +373,7 @@ int main(int argc, char *argv[]) {
if (streq(argv[1], load)) {
_cleanup_free_ char *value = NULL;
+const char *clamp;
if (!shall_restore_state())
return EXIT_SUCCESS;
@@ -390,7 +391,9 @@ int main(int argc, char *argv[]) {
return EXIT_FAILURE;
}
-clamp_brightness(device, value, max_brightness);
+clamp = udev_device_get_property_value(device,
ID_BACKLIGHT_CLAMP);
+if (clamp == NULL || streq(clamp, 1))
Please use parse_boolean() for this.
OK.
I think it would be better to name this ID_BACKLIGHT_CLAMP_MIN or so.
_MIN as in minimum? The brightness is also clamped to maximum brightness
advertised by the device.
Ah, I was confused for a moment, got lost between making this a prop
that ovverides the clamping parameter, and making this just a boolean
prop for turning this off and on... YOu made it the later, which is
fine, and hence disregard my comments about _MIN...
Your newer patch is merged now. THanks!
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] Ensure that systemd is the init called after using bootchart
On Mon, 02.02.15 17:03, Sebastien Bacher (seb...@ubuntu.com) wrote: Thanks Martin, I did the changes you suggested, new patch attached Cheers, Sebastien Bacher Thanks, applied! 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 0/6] Small adjustments to make QEMU tests work under Debian/Ubuntu
On Mon, 02.02.15 00:19, Martin Pitt (martin.p...@ubuntu.com) wrote: Hey all, as discussed on the hackfest, I'd like to revive the QEMU/nspawn integration tests, such as adding one for EFI or swap discovery (cf. the bugs fixed last week). As an initial step I wrote a couple of rather simple patches to make the QEMU tests work at all under Debian and derivatives (Ubuntu, Mint, etc.). Most of them aren't particularly Debian specific but rather apply to different ./configure options such as --enable-split-usr. The only truly Debian specific one is 6/6; if you really don't like that, I'm ok with carrying that in the Debian package, but (a) I think there's a certain value of making the upstream tests work under Debian (makes it *much* easier to test master often for CI), and (2) this is nothing that affects the behaviour on installations, so it should be rather harmless. Looks OK to me, but I figure Harald should have a look. Harald? 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] Added UFD (Uplink failure detection) support to networkd
On Thu, 29.01.15 14:05, Rauta, Alin (alin.ra...@intel.com) wrote: What if we don't use the * for now and document BindCarrier accordingly to be a list of port names and no wildcard ? Note that checking wildcards is really easy with glibc's fnmatch(). In fact, it's easier to do the full globbing thing than shortcutting this only for * and strcmp()... 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] Ensure that systemd is the init called after using bootchart
Thanks Martin, I did the changes you suggested, new patch attached
Cheers,
Sebastien Bacher
Le 02/02/2015 16:32, Martin Pitt a écrit :
Since ./configure allows you to specify paths independent from
--enable-split-usr, IMHO it is more robust to do
#define DEFAULT_INIT ROOTLIBDIR /systemd/systemd
From af6f3318bcad9b8c1109747b5d9f5ebed963397f Mon Sep 17 00:00:00 2001
From: Sebastien Bacher seb...@ubuntu.com
Date: Mon, 2 Feb 2015 15:48:40 +0100
Subject: [PATCH] Ensure that systemd is the init called after using bootchart
When booting with systemd-bootchart, default to call the systemd binary
rather than the init binary on disk, which might be another init system.
Collecting data only works with booting systemd.
---
man/bootchart.conf.xml| 2 +-
man/systemd-bootchart.xml | 4 ++--
src/bootchart/bootchart.c | 4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/man/bootchart.conf.xml b/man/bootchart.conf.xml
index a364826..e11ccb5 100644
--- a/man/bootchart.conf.xml
+++ b/man/bootchart.conf.xml
@@ -124,7 +124,7 @@
varlistentry
termvarnameInit=[path]/varname/term
listitemparaConfigures bootchart to run a non-standard
-binary instead of filename/sbin/init/filename. This
+binary instead of filename/usr/lib/systemd/systemd/filename. This
option is only relevant if bootchart was invoked from the
kernel command line with
init=/usr/lib/systemd/systemd-bootchart./para/listitem
diff --git a/man/systemd-bootchart.xml b/man/systemd-bootchart.xml
index 0068e92..ff86be2 100644
--- a/man/systemd-bootchart.xml
+++ b/man/systemd-bootchart.xml
@@ -116,7 +116,7 @@
commandsystemd-bootchart/command
instead of the init process. In turn,
commandsystemd-bootchart/command
-will invoke command/sbin/init/command.
+will invoke command/usr/lib/systemd/systemd/command.
/para/listitem
/varlistentry
@@ -218,7 +218,7 @@
termoption-i/option/term
termoption--init replaceablepath/replaceable/option/term
listitemparaUse this init binary. Defaults to
-command/sbin/init/command.
+command/usr/lib/systemd/systemd/command.
/para/listitem
/varlistentry
diff --git a/src/bootchart/bootchart.c b/src/bootchart/bootchart.c
index 0808ba4..b49e2c9 100644
--- a/src/bootchart/bootchart.c
+++ b/src/bootchart/bootchart.c
@@ -76,7 +76,7 @@ int sysfd=-1;
#define DEFAULT_HZ 25.0
#define DEFAULT_SCALE_X 100.0 /* 100px = 1sec */
#define DEFAULT_SCALE_Y 20.0 /* 16px = 1 process bar */
-#define DEFAULT_INIT /sbin/init
+#define DEFAULT_INIT ROOTLIBDIR /systemd/systemd
#define DEFAULT_OUTPUT /run/log
/* graph defaults */
@@ -326,7 +326,7 @@ int main(int argc, char *argv[]) {
/*
* If the kernel executed us through init=/usr/lib/systemd/systemd-bootchart, then
* fork:
- * - parent execs executable specified via init_path[] (/sbin/init by default) as pid=1
+ * - parent execs executable specified via init_path[] (/usr/lib/systemd/systemd by default) as pid=1
* - child logs data
*/
if (getpid() == 1) {
--
2.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] backlight: let udev properties override clamping
On Sun, 01.02.15 08:49, Topi Miettinen (toiwo...@gmail.com) wrote: On my computer, the minimum brightness enforced by clamping in backlight is too bright. Let udev property ID_BACKLIGHT_CLAMP control whether the brightness is clamped or not. Applied! Thanks! 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] Added UFD (Uplink failure detection) support to networkd
On Thu, 29.01.15 15:20, Andrei Borzenkov (arvidj...@gmail.com) wrote: On Wed, Jan 28, 2015 at 3:40 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 28.01.15 10:13, Rauta, Alin (alin.ra...@intel.com) wrote: Lennart, on a switch I should be able to configure more than one UFD group. What precisely does this mean? WOuld those groups be orthogonal? I really would like to avoid introdcuing the tags concept for now. Would a solution where you give the uplinks appropriate names (like uplink0, uplinkXYZ, uplink_waldo and so on) suffice, when you can then refer to them in a .network file you apply to the downlinks as BindCarrier=uplink*? This has interesting corner case. Let's say you have one interface uplink0 and one interface downstream0 that has BindCarrier=uplink*. So we bind downstream0 to uplink0 on startup. Later (online) we add second interface uplink1 and downstream1 which also has BindCarrier=uplink*. But now this one is suddenly bound to *two* interfaces instead of one; so they both behave differently. No. The matches should be reevaluated each time in full. Basically each time when we are ready to apply a .network file we should check the carrier of the interfaces that the .network's BindCarrier= matches. And each time an interface comes or goes, or changes its name, we must reevaluate the BindCarrier= settings of all other interfaces that might match now or might match no longer. This must be fully dynamic. Could also happen if interface fails on startup and is hotswaped or otherwise repaired replaced later. As such concept of uplink group abstracts away direct connection between down- and upstream. Each operation would then implicitly iterate over interfaces in group; when new interface is added, it provides natural place to adjust group monitoring (like set watch for it etc). Not so easy with your proposal. I don't see how an uplink group would get us anything here. There's effectively little difference between propagating carriers from interfaces to uplink groups to other interfaces, and propagating it directly from interfaces to other interfaces. We can do both fully dynamic, just one of them is much simpler conceptually than the other. I am still pretty convinced that a singular new option, that is BindsCarrier= would suffice to implement the usescases here. 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] cryptsetup: Do not warn If the key is /dev/*random
Lennart Poettering [2015-02-02 16:42 +0100]: I'd prefer if we'd change the check instead to only apply to S_ISREG() files. This way we wouldn't have to list all RNG device nodes. Ah, indeed. Sorry for prematurely pushing it then, I cleaned it up in http://cgit.freedesktop.org/systemd/systemd/commit/?id=3f4d56a0 This will cover regular files and symlinks, and ignore pipes and devices. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Mediacast to TV - MiracleCast - Open-Source Miracast - Wifi-Display on linux
Hi On Sun, Feb 1, 2015 at 10:50 AM, poma pomidorabelis...@gmail.com wrote: MiracleCast - Howto Current State [snip] Can folks from the NetworkManager team systemd-networkd team answer regarding the current status in this matter? As people continuously ask me about this, I'll just try to answer it on the public ML: To make Miracast work, we need access to a Wifi P2P API. The kernel implements Wifi P2P and wpa_supplicant provides access to it via it's ctrl-interface (and I think recently even gained a dbus API). In MiracleCast I wrote a miracle-wifid daemon that wraps wpa_supplicant and provides P2P to MircaleCast. However, this does not work well in parallel to NetworkManager/wicd/connman/... running. You really cannot run wpa_supplicant multiple times on the same interface. Hence, MiracleCast development is currently stalled until the different network-managers provide a P2P API. Intel recently added such an API to ConnMan and provides a WFD implementation on its own [1]. I highly recommend looking into it. It's now up to NetworkManager to catch up. systemd-networkd doesn't do L2 setup, so it's not really related. wicd is kinda dead [2], so I doubt they'll come up with something. Furthermore, P2P support is pretty limited right now. Officially, almost all recent devices support it, but it's particularly annoying to set it up, due to major bugs across all the stacks (in no way limited to linux drivers). I mean, 3 of 4 of my connection attempts between Android and Windows devices fails.. not even talking about my wpa_supplicant hacks. As I'm not really interested in hacking on network-managers, I've decided to stop working on MiracleCast. If, some day, there's a working P2P stack on linux, I might resurrect it. But it sounds more likely that I'll refer to the Intel solution (WYSIWIDI) instead. There're also gstreamer plugins for WFD now, so maybe give them a try? Thanks David [1] https://github.com/01org/wysiwidi [2] https://answers.launchpad.net/wicd/+question/227789 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What's the correct way to configure encrypted volume and mount point?
On Thu, 29.01.15 17:31, John Lane (syst...@jelmail.com) wrote: I am looking for some advice about configuring encrypted volumes with systemd that I want to open on demand (noauto). I can add entries into /etc/crypttab and /etc/fstab for the device, for example # name device password options dataUUID=deadbeef nonenoauto and # file systemdirtypeoptionsdumppass /dev/mapper/data /home/myuser/data ext4 noauto 0 0 But the device doesn't unlock when I do $ mount /home/myuser/data mount: special device /dev/mapper/keyring does not exist But it does if I use $ systemctl start home-myuser-data.mount BTW, just to mention this. You can also just write: # systemctl start /home/myuser/data This will automatically be translated to home-myuser-data.mount. systemctl has some logic built in to translate strings that don't look like unit names into unit names. Essentially this hence means that this: a) mount /home/myuser/data b) systemctl start /home/myuser/data However, the latter respects the whole systemde depency logic, while the former just tries to mount the specified dir immediately, ignoring all deps. 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 06/12] Support cancellation of fsck in progress
On Thu, 29.01.15 18:44, Didier Roche (didro...@ubuntu.com) wrote: Le 28/01/2015 15:53, Zbigniew Jędrzejewski-Szmek a écrit : On Wed, Jan 28, 2015 at 02:22:54PM +0100, Didier Roche wrote: From 104cf82ba28941e907f277a713f834ceb3d909f0 Mon Sep 17 00:00:00 2001 From: Didier Roche didro...@ubuntu.com Date: Mon, 26 Jan 2015 16:40:52 +0100 Subject: [PATCH 06/12] Support cancellation of fsck in progress Grab in fsckd plymouth watch key for C or c, and propagate this cancel request to systemd-fsck which will terminate fsck. Could we bind to ^c or if this is not possible, three c's in three seconds instead? I'm worried that before you could press anything to little effect in plymouth, and now a single key will have significant consequences. I tried to have a look at libplymouth, and if I'm correct, it's not possible to listen and get events for compose keys, so no way to get something like Control+C. As Dimitri told, it's been quite some years we are doing that in ubuntu, and that's the reason why we show a message to ensure the user is aware about that key (and that's why this patch is doing). Is it good for you this way? Hmm, I thought plymouth was listening on the tty (and not the input subsystem), which means it should deliver ctrl-C as ascii character code 3, because UNIX... 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] Added UFD (Uplink failure detection) support to networkd
On Thu, 29.01.15 11:20, Rauta, Alin (alin.ra...@intel.com) wrote: heya, Regarding the networkctl update to show the UFD groups in a user friendly fashion, what about that ? Well, I am not particularly convinced we should expose the concept of an UFD group at all. However, I think it would make a ton of sense to show which interfaces are downlinks to an uplink interface, and which interface is an uplink for a downlink interface, all based on the relation expressed with BindCarrier=. # networkctl ufd 1 ● UFD Group: 1 State: configured Uplinks: → 12: sw0p10 Downlinks: → 51: sw0p49 → 53: sw0p51 → 7: sw0p5 → 9: sw0p7 For this example, I think networkctl should show: # networkctl status sw0p10 ... Carrier Bound By: sw0p49 sw0p51 sw0p5 sw0p7 ... # netwokctl status sw0p49 ... Carrier Bound To: sw0p10 ... If that makes sense? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd
On Thu, 29.01.15 16:19, Rauta, Alin (alin.ra...@intel.com) wrote: So, we have: 1. BindCarrier=list of uplink ports 2. Network.DownlinkCarrierGroup=1 in upstream interface Network.UplinkCarrierGroup=1 in downstream interface This would mean you have to create 2 new members for the Network structure. 3. If we are to add 2 members then we can also think of adding: Network.UFDGroup = 1; Network.UFDType = uplink/downlink; For the feature to be visible I would say 3, but I'm fine with any of them. #1 appears to be the simplest concept. To consider #2 or #3 I'd really like to hear about usecases that #1 cannot cover? 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] Added UFD (Uplink failure detection) support to networkd
On Thu, 29.01.15 18:49, Andrei Borzenkov (arvidj...@gmail.com) wrote: В Thu, 29 Jan 2015 15:10:16 +0100 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет: On Thu, Jan 29, 2015 at 02:05:10PM +, Rauta, Alin wrote: What if we don't use the * for now and document BindCarrier accordingly to be a list of port names and no wildcard ? Then, if it's the case we can add such * support for BindCarrier and think about all those corner cases ? What about interpreting the wildcard dynimically instead? If eth3 goes down, look at all interfaces which have BindCarrier set, and check with glob if their BindCarrier setting matches eth3, and act accordingly. This means that every time any interface (dis)appears you must go through all existing BindCarrier statements and check whether they apply. This is really ugly. For this reasons I believe uplink group should be first class citizen also internally. Well, I really don't see how this would be ugly. When we design interfaces we primarily should keep the user's PoV in mind, and only secondarily the ease of implementation. I mean, if you are concerned about scalability (because each new interface means we need to check O(n) other interfaces), then there are certainly better ways to optimize that (for example, via a prefix hash table or so). But either way, I doubt this is really worth it for now, it would be premature optimization. We are not talking 10K of ports here for now. And if we want to support that one day, then there's ample time to add such a prefix hash table by then... And how do you set properties for it? Which of BindCarrierMode statements in different link (or are they network?) files apply if they differ? What if you need to add more properties? I am pretty sure BindCarrier= and BindCarrierMode= should be .network properties. And they only apply to each specific link the .network file is applied on. And since we only apply a single .network file per link at any time there's no ambiguity here at all. What about DownlinkCarrierGroup=1 in upstream interface UplinkCarrierGroup=1 in downstream interface This creates uplink group 1 and binds interfaces to it. Now you only need to care if there is another interface definition that has the same group number. I fully agree with Zbginiew that numeric IDs as identifiers for user objects are a bad idea. But you still need ability to set group properties (although in practice every switch I have seen is using policy all - anyone can give compelling use case for using any?), so yes, we may need support configuration object for it. But the first step could be default to policy all which does not require any configuration. I fail to see what properties these groups would require that couldn't be better be just be .network file properties... But yeah, I am pretty sure that BindCarrier= would be the first step, and BindCarrierMode= only the next step should the default policy of all not be sufficient for all usecases... 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] Added UFD (Uplink failure detection) support to networkd
On Thu, 29.01.15 17:00, Daniel Ankers (md1...@md1clv.com) wrote: The problem I see with this approach is that it allows bizarre configurations to be specified which don't make sense in practice: e.g. 1 - Loop: /etc/systemd/network/downlink0.network: BindCarrier=uplink* /etc/systemd/network/uplink0.network: BindCarrier=downlink* e.g. 2 - Chain /etc/systemd/network/downlink0.network: BindCarrier=uplink* /etc/systemd/network/uplink0.network: BindCarrier=thirdlink* I think this is not really an issue, since we'd bind the application of a .network file to the physical carrier sense of other interfaces, but not application of .network files to application of .network files. Since the the application of .network files and carrier sense are pretty much orthogonal creating a loop is not really doable, unless you actually involve physically or virtually looping back the carrier sense... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] slow systemd-networkd DHCP client on wlan0 with systemd v217
Another problem with systemd-networkd is that the lease is not renewed after sleep. This is a basic feature, a laptop is frequently physicially moved, which means another DHCP lease should be acquired, but I don't see how to do that. How can I make that happen? It's not clear to me, since systemd-networkd does not seem to support triggers. At the moment I'm back to dhcpcd5. On Mon, Feb 2, 2015 at 5:33 PM, Lennart Poettering lenn...@poettering.net wrote: On Sun, 11.01.15 18:45, Charles Devereaux (syst...@guylhem.net) wrote: What's not is the time it takes to systemd-networkd : 1 second for IPv6 is acceptable (I'm using SLAAC with radvd on the other end), but for ipv4 it's more like 3 seconds, plus another 3 to use the proper DNS server (!!) [...] So basically, I don't know why it's so slow, except that it comes from DHCP IPv4 Tom has fixed that with d4cdbea5550ae9defa1c731ffe091837d329fec7, could you please verify? 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] test-dhcp-client failing in mock builds
On Tue, Feb 03, 2015 at 02:42:36AM +0100, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Feb 02, 2015 at 08:30:43AM +0100, Jan Synacek wrote: http://lists.freedesktop.org/archives/systemd-devel/2014-December/026190.html I haven't got time to properly analyze the problem since then... It sounded familiar ;) On Mon, Feb 02, 2015 at 01:36:29PM +0200, Patrik Flykt wrote: Operation not permitted is what is printed for EPERM. But EPERM is not present in the client code itself, so I'm inclined towards a permission problem somewhere when running mock. EPERM is also returned when using /dev/null in epoll_ctl_add. I think I fixed it now. Which leads to a failure on arm in test-network: FAIL: test-network == Assertion '!address_equal(a1, a2)' failed at ../src/network/test-network.c:161, function test_address_equality(). Aborting. I got out my chromebook to see what going on here. Ha, undefined behaviour on right shift. Gotta love C ;) So the tests pass in mock on all three primary arches. I'll let it spin on arm64 just to see what comes up. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
