[systemd-devel] [PATCH] man/systemctl: document enable on masked units
--- man/systemctl.xml | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/man/systemctl.xml b/man/systemctl.xml index b28a3b7..d2fa3b3 100644 --- a/man/systemctl.xml +++ b/man/systemctl.xml @@ -924,6 +924,9 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service the system, or for all future logins of all users, or only this boot. Note that in the last case, no systemd daemon configuration is reloaded./para + +paraUsing commandenable/command on masked units +results in an error./para /listitem /varlistentry @@ -1080,8 +1083,8 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service filename/dev/null/filename, making it impossible to start them. This is a stronger version of commanddisable/command, since it prohibits all kinds of -activation of the unit, including manual activation. Use -this option with care. This honors the +activation of the unit, including enablement and manual +activation. Use this option with care. This honors the option--runtime/option option to only mask temporarily until the next reboot of the system./para /listitem -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH, REVIEW] Added unit enabled-context cache to improve performance w/ many units.
Resubmitting using git format-patch, git imap-send ... no code changes. --- .gitignore | 1 + Makefile.am| 44 +++- src/core/dbus-manager.c| 4 +- src/core/manager.c | 6 + src/core/manager.h | 2 + src/core/unit.c| 2 +- src/shared/install.c | 268 + src/shared/install.h | 16 +- src/systemctl/systemctl.c | 4 +- src/test/test-enabled.c| 151 src/test/test-install.c| 87 --- src/test/test-unit-file.c | 2 +- .../etc/systemd/system/masked.service | 1 + .../etc/systemd/system/maskedstatic.service| 1 + .../etc/systemd/system/some.target | 11 + .../system/some.target.wants/aliased.service | 1 + .../system/some.target.wants/also_masked.service | 1 + .../system/some.target.wants/another.service | 1 + .../system/some.target.wants/different.service | 1 + .../system/some.target.wants/masked.service| 1 + .../some.target.wants/templating@four.service | 1 + .../some.target.wants/templating@one.service | 1 + .../some.target.wants/templating@three.service | 1 + .../some.target.wants/templating@two.service | 1 + .../run/systemd/system/maskedruntime.service | 1 + .../run/systemd/system/maskedruntimestatic.service | 1 + .../run/systemd/system/other.target| 14 ++ .../system/other.target.wants/runtime.service | 1 + .../usr/lib/systemd/system/another.service | 9 + .../usr/lib/systemd/system/disabled.service| 9 + .../usr/lib/systemd/system/invalid.service | 1 + .../usr/lib/systemd/system/masked.service | 9 + .../usr/lib/systemd/system/maskedruntime.service | 9 + .../lib/systemd/system/maskedruntimestatic.service | 6 + .../usr/lib/systemd/system/maskedstatic.service| 6 + .../usr/lib/systemd/system/runtime.service | 9 + .../usr/lib/systemd/system/static.service | 6 + .../usr/lib/systemd/system/templating@.service | 9 + .../lib/systemd/system/templating@three.service| 9 + .../usr/lib/systemd/system/templating@two.service | 9 + .../usr/lib/systemd/system/unique.service | 9 + 41 files changed, 626 insertions(+), 100 deletions(-) create mode 100644 src/test/test-enabled.c create mode 12 test/test-enabled-root/etc/systemd/system/masked.service create mode 12 test/test-enabled-root/etc/systemd/system/maskedstatic.service create mode 100644 test/test-enabled-root/etc/systemd/system/some.target create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/aliased.service create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/also_masked.service create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/another.service create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/different.service create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/masked.service create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/templating@four.service create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/templating@one.service create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/templating@three.service create mode 12 test/test-enabled-root/etc/systemd/system/some.target.wants/templating@two.service create mode 12 test/test-enabled-root/run/systemd/system/maskedruntime.service create mode 12 test/test-enabled-root/run/systemd/system/maskedruntimestatic.service create mode 100644 test/test-enabled-root/run/systemd/system/other.target create mode 12 test/test-enabled-root/run/systemd/system/other.target.wants/runtime.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/another.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/disabled.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/invalid.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/masked.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/maskedruntime.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/maskedruntimestatic.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/maskedstatic.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/runtime.service create mode 100644 test/test-enabled-root/usr/lib/systemd/system/static.service create mode 100644
Re: [systemd-devel] [PATCH] journal: Fix sd_journal_enumerate_unique skipping values
Gesendet: Mittwoch, 08. Oktober 2014 um 01:40 Uhr Von: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl An: Jan Janssen medhe...@web.de Cc: systemd-devel@lists.freedesktop.org Betreff: Re: [systemd-devel] [PATCH] journal: Fix sd_journal_enumerate_unique skipping values On Mon, Oct 06, 2014 at 06:57:38PM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Oct 06, 2014 at 06:36:34PM +0200, Jan Janssen wrote: *bump* Sorry, I'll look into this. Doesn't work. Both without or with your other patch sd_journal_enumerate_unique I get bogus results on my test case. It seems the issue is more complicated. That's odd. Care to elaborate what bogus results means? Are you even affected by the bug in question without the patch? Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [systemd.link] How to use NamePolicy=mac?
Hi all! In order to fix in an easily predictable manner the interfaces' names, I went and wrote the following .link file: /etc/systemd/network/00-default.link [Link] NamePolicy=mac MACAddressPolicy=persistent I daemon-reload, reboot: $ ip a [...] 4: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether b8:27:eb:aa:aa:d2 brd ff:ff:ff:ff:ff:ff [...] [...] However, $ udevadm test-builtin net_setup_link /sys/class/net/eth0 calling: test-builtin load module index timestamp of '/etc/systemd/network' changed Parsed configuration file /usr/lib/systemd/network/99-default.link Parsed configuration file /etc/systemd/network/00-default.link Created link configuration context. ID_NET_DRIVER=smsc95xx Config file /etc/systemd/network/00-default.link applies to device eth0 ID_NET_NAME=enxb827ebd2 unload module index Unloaded link configuration context. Also, # /lib/systemd/systemd-udevd --debug device 0xb78bb3f8 has devpath '/devices/virtual/block/ram9' restoring old watch on '/dev/ram9' adding watch on '/dev/ram9' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram8' restoring old watch on '/dev/ram8' adding watch on '/dev/ram8' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram7' restoring old watch on '/dev/ram7' adding watch on '/dev/ram7' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram5' restoring old watch on '/dev/ram5' adding watch on '/dev/ram5' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram14' restoring old watch on '/dev/ram14' adding watch on '/dev/ram14' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram2' restoring old watch on '/dev/ram2' adding watch on '/dev/ram2' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram15' restoring old watch on '/dev/ram15' adding watch on '/dev/ram15' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram6' restoring old watch on '/dev/ram6' adding watch on '/dev/ram6' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram4' restoring old watch on '/dev/ram4' adding watch on '/dev/ram4' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram3' restoring old watch on '/dev/ram3' adding watch on '/dev/ram3' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram13' restoring old watch on '/dev/ram13' adding watch on '/dev/ram13' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram11' restoring old watch on '/dev/ram11' adding watch on '/dev/ram11' device 0xb78bb3f8 has devpath '/devices/virtual/block/loop6' restoring old watch on '/dev/loop6' adding watch on '/dev/loop6' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram12' restoring old watch on '/dev/ram12' adding watch on '/dev/ram12' device 0xb78bb3f8 has devpath '/devices/virtual/block/loop3' restoring old watch on '/dev/loop3' adding watch on '/dev/loop3' device 0xb78bb3f8 has devpath '/devices/virtual/block/loop5' restoring old watch on '/dev/loop5' adding watch on '/dev/loop5' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram1' restoring old watch on '/dev/ram1' adding watch on '/dev/ram1' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram0' restoring old watch on '/dev/ram0' adding watch on '/dev/ram0' device 0xb78bb3f8 has devpath '/devices/virtual/block/loop7' restoring old watch on '/dev/loop7' adding watch on '/dev/loop7' device 0xb78bb3f8 has devpath '/devices/virtual/block/ram10' restoring old watch on '/dev/ram10' adding watch on '/dev/ram10' device 0xb78bb3f8 has devpath '/devices/virtual/block/loop1' restoring old watch on '/dev/loop1' adding watch on '/dev/loop1' device 0xb78bb3f8 has devpath '/devices/virtual/block/loop2' restoring old watch on '/dev/loop2' adding watch on '/dev/loop2' device 0xb78bb3f8 has devpath '/devices/virtual/block/loop4' restoring old watch on '/dev/loop4' adding watch on '/dev/loop4' device 0xb78bb3f8 has devpath '/devices/virtual/block/loop0' restoring old watch on '/dev/loop0' adding watch on '/dev/loop0' device 0xb78bb3f8 has devpath '/devices/platform/mmc- bcm2835.0/mmc_host/mmc0/mmc0:59b4/block/mmcblk0/mmcblk0p2' restoring old watch on '/dev/mmcblk0p2' adding watch on '/dev/mmcblk0p2' device 0xb78bb3f8 has devpath '/devices/platform/mmc- bcm2835.0/mmc_host/mmc0/mmc0:59b4/block/mmcblk0/mmcblk0p1' restoring old watch on '/dev/mmcblk0p1' adding watch on '/dev/mmcblk0p1' device 0xb78bb3f8 has devpath '/devices/platform/mmc- bcm2835.0/mmc_host/mmc0/mmc0:59b4/block/mmcblk0' restoring old watch on '/dev/mmcblk0' adding watch on '/dev/mmcblk0' === trie on-disk === tool version: 216 file size: 6486785 bytes header size 80 bytes strings1673705 bytes nodes 4813000 bytes load module index timestamp of '/etc/systemd/network' changed Parsed configuration file /usr/lib/systemd/network/99-default.link Parsed configuration file /etc/systemd/network/00-default.link Created link configuration context. timestamp of '/etc/udev/rules.d' changed timestamp of '/usr/lib/udev/rules.d' changed
Re: [systemd-devel] I wonder… why systemd provokes this amount of polarity and resistance
On Tue, 07.10.14 23:40, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote: On Tue, 2014-10-07 at 14:15 -0400, Rob Owens wrote: My question really isn't why are the Debian dependencies the way they are. I understand that. I was trying to highlight the strange situation of a desktop application requiring a particular init system. I *think* this is a result of the init portion of systemd being bundled together with the logind portion of systemd. To me (unfamiliar with the systemd code) those two functions seem distinct enough to merit being separate. Debian can't easily separate what the systemd devs have developed as a single binary, so we end up with these strange dependency chains. Single binary is false of course. Logind is developed as a separate program, which is why systemd-shim is possible at all. AFAIK the actual relevant dependencies go as follows: First, there's a good reason why logind requires cgroup functionality. And there's a good reason why cgroup functionality is best implemented together with init (see http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ for more info). So it's not quite directly logind has to depend on systemd as init, but logind has to depend on the system having cgroup support, and there's no equally good cgroup support available for inits other than systemd. It is possible to provide the relevant cgroup interfaces in or on top of another init, as the systemd-sysv + cgmanager combination attempts to do. But it is not trivial to do, as bugs and implementation delays with that combo have shown, and it's quite likely that there will be more problems in the future. It's not a particularly good idea to use the less-tested and less-reliable systemd-shim instead of the more reliable systemd. Thus the overall result is that yes, it does make sense to switch machines to systemd when you add certain functionality, even if that functionality does not appear to be directly tied to the init system at first glance. Also note that the systemd concepts logind makes use of are also exported in its own API. The scopes and slices that logind uses are exposed on its bus objects, and they are used by tools like loginctl to do their work. The scopes and slices concept does not exist elsewhere, and there's nothing comparable around, so even if we wanted we couldn't make logind work on anything 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] Shell expressions in EnvironmentFile
On Tue, 07.10.14 13:12, Jon Stanley (jonstan...@gmail.com) wrote: Since EnvironmentFile in a service isn't sourced by any shell, shell expressions in it will obviously not work the way that they did in a SysV style script. Nor does it seems that the environment gets preserved between ExecStartPre (where one could run a script that sets environment variables to be later used in the starting of the service) and ExecStart, so something like the following won't work: [Service] ExecStartPre=/something/that/sets/var ExecStart=/some/file $var Is there some way to get dynamically determined data into the environment such that it can be passed to the daemon at start? In such a case I'd suggest wrapping your daemon invocation in a shell script, setting the environment variables first, and then using exec to replace the shell process by the actual daemon process. ExecStartPre= and ExecStart= are run in separate, cleaned up execution contexts, in particular they do not inherit any environment variables between each other. 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] Shell expressions in EnvironmentFile
On Tue, 07.10.14 19:18, Simon Peeters (peeters.si...@gmail.com) wrote: 2014-10-07 19:12 GMT+02:00 Jon Stanley jonstan...@gmail.com: Since EnvironmentFile in a service isn't sourced by any shell, shell expressions in it will obviously not work the way that they did in a SysV style script. Nor does it seems that the environment gets preserved between ExecStartPre (where one could run a script that sets environment variables to be later used in the starting of the service) and ExecStart, so something like the following won't work: Which is logical since no system exists to modify the environment of the parent proces. [Service] ExecStartPre=/something/that/sets/var ExecStart=/some/file $var ExecStart=/bin/sh -c . /something/that/sets/var; /some/file $var THis would certainly work, but I'd strongly advise to use exec for executing /some/file at the end, so that the shell process is replaced by the actual daemon process, instead of continuing running with the demon process as child. 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] core: don't allow enabling if unit is masked
On Tue, 07.10.14 13:35, Jan Synacek (jsyna...@redhat.com) wrote:
---
src/shared/install.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/shared/install.c b/src/shared/install.c
index fa064c2..945bb27 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -1516,6 +1516,19 @@ int unit_file_enable(
return r;
STRV_FOREACH(i, files) {
+UnitFileState state;
+
+state = unit_file_get_state(scope, root_dir, *i);
+if (state 0) {
+log_error(Failed to get unit file state for %s:
%s, *i, strerror(-state));
+return state;
+}
+
+if (state == UNIT_FILE_MASKED || state ==
UNIT_FILE_MASKED_RUNTIME) {
+log_error(Failed to enable unit: Unit %s is
masked, *i);
+return -ENOTSUP;
+}
+
Looks mostly OK. However, we should probably use a more useful error
here. Maybe EADDRNOTAVAIL or so. Even better though would be to
actually change the call to take an sd_bus_error argument and then
return a proper error message that can be passed back to the bus
clients with a real explanation.
Logging about this with log_error() is probably not a good idea.
Also, the same logic should be added to unit_file_link() and
unit_file_preset() 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] [PATCH v4] systemctl: add add-wants and add-requires verbs
Zbigniew Jędrzejewski-Szmek píše v Út 07. 10. 2014 v 23:11 +0200: On Tue, Oct 07, 2014 at 05:46:48PM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Oct 07, 2014 at 02:09:37PM +0200, Lukas Nykryn wrote: --- Changes in v4 - renamed install_dependency - dependency - removed the enum with dependencies and used the general one instead This part should really be a separate commit. It moves a lot of code around and makes it harder to see what is going on. done - add an error meesage in the case that --root is used and it fails - changes in manpage Looks good, please push. done Jan Synacek's patch f7101b7368 adds a check to unit_file_enable(). An identical check should be applied to the code path you are adding. done Zbyszek Thanks for reviews! Lukas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/4] mount-setup: introduce mount_setup_run_dirs()
On Tue, 07.10.14 14:14, Michal Sekletar (msekl...@redhat.com) wrote: Hence, if a container manager mounts everything properly, then mount_setup() should be a NOP anyway... In theory yes, but in fact not having /run mounted as tmpfs is default in the docker container. I have no strong opinion on whether this is sensible or not, however I think that systemd can be made more resilient and handle such cases. Sorry, but no. /run should be pre-mounted, and if it isn't we need the rights to mount it. We will not boot up a system without /run. That's part of the API for programs, and we will not avoid it. Please ask Docker to premount /run. All distros need /run anyway these days, Debian does, Ubuntu does, Fedora does. Now systemd will try to mount /run on tmpfs, such attempt will fail because of missing capability and then systemd will just hang. Well, just sticking the head in the sand won't help. If we don't have /run mounted, then things will break later on. We cannot ignore that. Sorry, 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 3/4] shutdown: don't do final unmounting when inside the container and running without CAP_SYS_ADMIN
On Tue, 07.10.14 14:17, Michal Sekletar (msekl...@redhat.com) wrote:
On Thu, Oct 02, 2014 at 12:04:02PM +0200, Lennart Poettering wrote:
On Thu, 02.10.14 09:57, Michal Sekletar (msekl...@redhat.com) wrote:
#define FINALIZE_ATTEMPTS 50
@@ -207,7 +208,11 @@ int main(int argc, char *argv[]) {
in_container = detect_container(NULL) 0;
-need_umount = true;
+if (in_container !have_effective_cap(CAP_SYS_ADMIN))
+need_umount = false;
+else
+need_umount = true;
+
need_swapoff = !in_container;
need_loop_detach = !in_container;
need_dm_detach = !in_container;
Hmm, I think we should just do need_umount = !in_container, like we
do for the other things like loopback detaching, dm detaching or
swapoff. After all, if we run in a container we run in a mount
namespace anyway, so unmounting things is done by the kernel
implicitly if the namespace dies. At least in theory this means we can
simply skip the unmounting in all containers, but I must admit that I
am not entirely clear on this one, so this needs to be tested in the
common container managers really, I figure...
Do you mind if I push just need_umount = !in_container then?
Well, yes.
I'd be thankful if you'd test this a bit first, so that this doesn't
break anything. Testing nspawn and on bare-metal should be 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] [PATCH 2/2] sysusers.d: split files to cope with split packages.
On Tue, 07.10.14 04:54, Barbieri, Gustavo (gustavo.barbi...@intel.com) wrote: -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Thursday, October 02, 2014 4:19 AM To: Barbieri, Gustavo Cc: Zbigniew Jędrzejewski-Szmek; systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] [PATCH 2/2] sysusers.d: split files to cope with split packages. On Tue, 30.09.14 14:44, Gustavo Sverzut Barbieri (gustavo.barbi...@intel.com) wrote: systemd-timesyncd is ~400kb. Other binaries aren't too big either. Splitting everything up complicated things, and I'm not convinced that this is a useful change. indeed they are not big per se, but see my other email about tmpfiles, they contribute to a misinterpretation of systemd. since they are optional I want to make that clear and help the user to choose. I do have a complete set of packages for yocto that generates that nicely and the final system size difference is huge: 7.5 to 30Mb (whole system, not just systemd, but the dependencies, etc -- in contrast sysvinit + busybox is 6.5Mb). as I wrote in the other email, I'll make sure that some packages are highly recommended (ie: journal, udev, sysctl...), but forcing We don't support builds without journal or udev. We simply don't. I'm not trying to build without, just running without. Actually I'm not using any of --disable-SERVICE_OR_DAEMON, I build with all of them and let the user install or not the package -- thus the need for different *files* :-) Well, no, we don't support that either. (With one exception: on systems that have no physical devices -- i.e. containers -- we skip udev.) Yes, timesyncd should definitely be optional, and so should resolved, that's true. I'd be OK with splitting those out on tmpfiles/sysusers, but would really prefer this to be done via m4, rather than in seperate files. As per above, I don't want to build without, rather build with all and just package them in separate. In the recommended setup users will get all they need. Just in cases where they remove (blacklist) the systemd-services-essential they can run without those (tmpfiles, sysusers...), I guess the name makes it clear they are not something to mess with if you are unsure. Please help, this will be for good. The m4 macros just makes the build system and packaging more difficult. It would only be useful for systems like Gentoo. I'd be willing to merge a patch that splits this up for resolved, timesyncd. But not for udev or journald, sorry. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] tmpfiles.d: split files to cope with split packages.
On Tue, 07.10.14 04:59, Barbieri, Gustavo (gustavo.barbi...@intel.com) wrote: -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Thursday, October 02, 2014 4:16 AM To: Barbieri, Gustavo Cc: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] [PATCH 1/2] tmpfiles.d: split files to cope with split packages. On Thu, 25.09.14 18:12, Gustavo Sverzut Barbieri (gustavo.barbi...@intel.com) wrote: etc.conf was selectively (using m4) using resolved link, now this is moved to systemd-resolved.conf file. The etc.conf can be static and does not need to be generated anymore. systemd.conf was doing all the journal setup, now this is moved to systemd-journald.conf file. journald is not optional. And it won't be. Sorry. Got it, but clarity sake having it in a different file wouldn't hurt. But is not a big deal if you are completely against it. +z /var/log/journal/remote 2755 root systemd-journal-remote - - +z /run/log/journal/remote 2755 root systemd-journal-remote - - I am not convinced this is really worth it. This line has no effect anyway if the dir is missing... You mean the dir in systemd.conf? The dirs /var/log/journal/remote and /run/log/journal/remote I meant. The z lines just fix perms on files/dirs that exist. If they don't they don't do anything. 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] dbus-manager: don't allow enabling if unit is masked
On Tue, 07.10.14 08:23, Jan Synacek (jsyna...@redhat.com) wrote: Lennart Poettering lenn...@poettering.net writes: On Mon, 06.10.14 13:21, Jan Synacek (jsyna...@redhat.com) wrote: Hmm with this change in place we'd have different behaviour for the cases where systemctl executes the operation client-side, and when it goes via the bus. We really should keep those differences in behaviour to a minimum. I figure the verification for this really needs to be moved a few levels down, somewhere into unit_file_enable() and friends, so that all code paths behave the same. But that wouldn't fix a scenario where one uses just dbus to call the method, would it? Maybe I'm missing something, but that's how I understood the code so far. However, I agree that the fix is incomplete and I'll try to fix that. unit_file_enable() is what is used by both codepaths: the one via dbus, and the one executed directly in systemctl, from the client side. If you change unit_file_enable() you hence did the work for both sides. While I'm at it, what about disable? Should it behave in the same way, i.e. return error when the unit is masked? My guess is that yes, but I'm not sure. disable, reenable, mask, unmask, should not be changed. Only enable, link and preset should get this check. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/4] mount-setup: introduce mount_setup_run_dirs()
On 10/08/2014 07:40 AM, Lennart Poettering wrote: On Tue, 07.10.14 14:14, Michal Sekletar (msekl...@redhat.com) wrote: Hence, if a container manager mounts everything properly, then mount_setup() should be a NOP anyway... In theory yes, but in fact not having /run mounted as tmpfs is default in the docker container. I have no strong opinion on whether this is sensible or not, however I think that systemd can be made more resilient and handle such cases. Sorry, but no. /run should be pre-mounted, and if it isn't we need the rights to mount it. We will not boot up a system without /run. That's part of the API for programs, and we will not avoid it. Please ask Docker to premount /run. All distros need /run anyway these days, Debian does, Ubuntu does, Fedora does. Now systemd will try to mount /run on tmpfs, such attempt will fail because of missing capability and then systemd will just hang. Well, just sticking the head in the sand won't help. If we don't have /run mounted, then things will break later on. We cannot ignore that. Sorry, Lennart We have a patch for this. In the past docker has bocked/removed the patch because there is no concept of systemd-tmpfs inside a container to pre-populate /run. So images came with content in their /run. Alex wrote a patch to scan the /run on the image and create the content in a tmpfs /run. I will attempt to push this patch again to docker. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-nspawn: Cannot create tun device in container
On Fri, 03.10.14 10:46, James Lott (ja...@lottspot.com) wrote: Hello, list! In some work I've been doing with systemd-nspawn containers, I've been trying to connect one of my containers to an openvpn network. This conteiner is being run with the --network-bridge flag to setup its networking, so according to the documentation, should retain CAP_NET_ADMIN capabilities. However, the container appears to be unable to create a new tun device [root@lanvpn ~]# ip tuntap add dev tun0 mode tun open: No such file or directory Can you check with strace what precisely fails 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] man/systemctl: document enable on masked units
On Wed, Oct 08, 2014 at 08:04:52AM +0200, Jan Synacek wrote: --- man/systemctl.xml | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/man/systemctl.xml b/man/systemctl.xml index b28a3b7..d2fa3b3 100644 --- a/man/systemctl.xml +++ b/man/systemctl.xml @@ -924,6 +924,9 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service the system, or for all future logins of all users, or only this boot. Note that in the last case, no systemd daemon configuration is reloaded./para + +paraUsing commandenable/command on masked units +results in an error./para /listitem /varlistentry @@ -1080,8 +1083,8 @@ kobject-uevent 1 systemd-udevd-kernel.socket systemd-udevd.service filename/dev/null/filename, making it impossible to start them. This is a stronger version of commanddisable/command, since it prohibits all kinds of -activation of the unit, including manual activation. Use -this option with care. This honors the +activation of the unit, including enablement and manual +activation. Use this option with care. This honors the option--runtime/option option to only mask temporarily until the next reboot of the system./para /listitem -- Yep, applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC] Mounting $XGD_RUNTIME_DIR with units instead of logind code.
Hello, Lately I've been working on updating systemd (currently 208) in Tizen. One of problems we've stumbled upon was with user@.service failing. Problem was on SMACK-enabled system, caused by 1c231f5 (logind: make $XDG_RUNTIME_DIR a per-user tmpfs). When $XDG_RUNTIME_DIR is mounted it inherits logind label, which in turn forbid users to access theirs directories. One solution would be to add if (use_smack()) mount(...smackfsroot=*...) in logind-user.c, but it would also require to add CAP_MAC_ADMIN to systemd-logind.service. Another solution would be to remove mounting logic from logind-user.c completely and add run-user@.mount. user@.service would gain following lines: Requires=run-user@%I.mount After=run-user@%I.mount Unfortunately, currently it's not possible. First problem is that unit isn't named after path, so that requirement needs to be removed first. Second - we don't have gid, but it doesn't seem to be an issue, as mode is set to 0700. Then, in Tizen we could just add smackfsroot to options. Alternatively SmackLabel= option could be added for mount units, which would automatically append smackfsroot to options, when SMACK is enabled. How should we solve this issue? regards, -- Maciej Wereski Samsung RD Institute Poland Samsung Electronics m.were...@partner.samsung.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journal: Fix sd_journal_enumerate_unique skipping values
On Wed, Oct 08, 2014 at 08:24:49AM +0200, Jan Janssen wrote: Gesendet: Mittwoch, 08. Oktober 2014 um 01:40 Uhr Von: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl An: Jan Janssen medhe...@web.de Cc: systemd-devel@lists.freedesktop.org Betreff: Re: [systemd-devel] [PATCH] journal: Fix sd_journal_enumerate_unique skipping values On Mon, Oct 06, 2014 at 06:57:38PM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Oct 06, 2014 at 06:36:34PM +0200, Jan Janssen wrote: *bump* Sorry, I'll look into this. Doesn't work. Both without or with your other patch sd_journal_enumerate_unique I get bogus results on my test case. It seems the issue is more complicated. That's odd. Care to elaborate what bogus results means? Are you even affected by the bug in question without the patch? Yes, I have a VM where I get a smaller number from -F _BOOT_ID than from --list-boots (w/o your patches), and then the same smaller number with one or two of your patches. So results become consistent, but equally bad. Of course I can't know if this is exactly the same bug, but it certainly looks like it. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] consoled vs vlock -a
Hi, will a transition to consoled affect `vlock -a` which uses ioctl(...VT_SETMODE...) to prevent switching to another terminal? Will this functionality still work? -- Marcin Szewczyk http://wodny.org mailto:marcin.szewc...@wodny.borg - remove b / usuń b xmpp:wo...@ubuntu.pl xmpp:wo...@jabster.pl ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: don't allow enabling if unit is masked
On Wed, Oct 08, 2014 at 11:54:19AM +0200, Lennart Poettering wrote:
On Tue, 07.10.14 13:35, Jan Synacek (jsyna...@redhat.com) wrote:
---
src/shared/install.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/shared/install.c b/src/shared/install.c
index fa064c2..945bb27 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -1516,6 +1516,19 @@ int unit_file_enable(
return r;
STRV_FOREACH(i, files) {
+UnitFileState state;
+
+state = unit_file_get_state(scope, root_dir, *i);
+if (state 0) {
+log_error(Failed to get unit file state for %s:
%s, *i, strerror(-state));
+return state;
+}
+
+if (state == UNIT_FILE_MASKED || state ==
UNIT_FILE_MASKED_RUNTIME) {
+log_error(Failed to enable unit: Unit %s is
masked, *i);
+return -ENOTSUP;
+}
+
Looks mostly OK. However, we should probably use a more useful error
here. Maybe EADDRNOTAVAIL or so. Even better though would be to
actually change the call to take an sd_bus_error argument and then
return a proper error message that can be passed back to the bus
clients with a real explanation.
Yes, EADDRNOTAVAIL is used in another place where the unit is masked.
I'm not sure which one is more useful :). But hopefully this will be
an internal-only thing once meaningful dbus error messages are provided.
The problem with passing dbus *error into the lower levels is that
the functions live in src/share/, and were so far not linked with the
bus libraries. I think that the best way to handle this would be to
use a temporary structure like
{ char *unit_name; char *error_message; int code}
and use this to pass the information about the error from the lower
to the upper levels. But maybe I'm overcomplicating things.
--
A related thing: there's a mapping bus-error - errno implemented,
but it only works for the errors defined in the library itself. It
would be nice to extend this mapping to the user defined errors,
e.g. in core/. Would you be amenable to adding a mechianism to
register additional mappings like bus-error-mapping.gperf so that they
are used by the library?
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-detect-virt and vendors
Hi Bringing up here for discussion as suggested in https://bugzilla.redhat.com/show_bug.cgi?id=1150477 Just for the background, I was checking to see if systemd-detect-virt supported virtualbox and grepped the man page and concluded it didn't since I didn't find the term. I was going to write up a patch to support it but a recheck in the man page showed support for oracle and microsoft. Grepping through the source, confirmed this actually means virtualbox and hyper-v respectively. Using vendor names like this is pretty confusing. Not everyone knows that say virtualbox is owned by Oracle (It was a startup, acquired by Sun which itself was acquired by Oracle) and worse still, Oracle supports multiple virtualization technologies included a variant of Xen rebranded as Oracle VM. We really should be more specific and call it virtualbox and hyper-v instead, similar to say virt-what and other similar tools. I will be happy write the patches if this makes sense. Rahul ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to exclusively toggle between two systemd instances of a single daemon?
On Wed, Oct 08, 2014 at 06:30:51AM -0700, terrygalant.li...@fastest.cc wrote: Hi I have 2 installed instances of a single daemon. 1 is from distro-installed packages, installed into standard default OS locations with unit files in /usr/lib/systemd/system/. The other is installed under /opt, with unit files currently in /opt/mydaemon/systemd/system/, which can be (un)symlinked as needed into /etc/systemd/system/multi-user.target.wants/ to disable or enable. I want to be able to occasionally toggle between use of the 2. Is the right systemd way to do manage this toggle to just name the 2 instances' unit files differently, put a Conflicts= in each for the other, and just use 'enable' for whichever I want active? That would work. You can also make a symlink from /etc/systemd/system/xxx.service to either of the two files and manage it by hand, calling systemctl daemon-reload afterwards. I think this should work. If other systemd units have a Requires= dependency on this daemon, how do I deal with the toggle? Is there a Require=this-instance-OR-that-instance equivalent? No. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-detect-virt and vendors
On Wed, 08.10.14 09:38, Rahul Sundaram (methe...@gmail.com) wrote: Hi Bringing up here for discussion as suggested in https://bugzilla.redhat.com/show_bug.cgi?id=1150477 Just for the background, I was checking to see if systemd-detect-virt supported virtualbox and grepped the man page and concluded it didn't since I didn't find the term. I was going to write up a patch to support it but a recheck in the man page showed support for oracle and microsoft. Grepping through the source, confirmed this actually means virtualbox and hyper-v respectively. Using vendor names like this is pretty confusing. Not everyone knows that say virtualbox is owned by Oracle (It was a startup, acquired by Sun which itself was acquired by Oracle) and worse still, Oracle supports multiple virtualization technologies included a variant of Xen rebranded as Oracle VM. We really should be more specific and call it virtualbox and hyper-v instead, similar to say virt-what and other similar tools. I will be happy write the patches if this makes sense. These things changed names a couple of times. As such I tried to stay out of any such games, and just named it after the primary company, under the assumption that would be slightly more stable. The IDs are ultimately just tokens to identify things with, they are not pretty, descriptive strings that are supposed to be shown to the users. They also are API, since people use them in unit files (ConditionVirtualization=) and shell scripts, as such I am not too enthusiastic about changing them. I think what would make a lot of sense though is to add a section to the man page somewhere, that explains which ID refers to which software from which vendor. Also, it might make sense to add a new switch to the tool, that dumps the table of known identifiers plus some description. 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] How to exclusively toggle between two systemd instances of a single daemon?
Hi Zbigniew On Wed, Oct 8, 2014, at 06:39 AM, Zbigniew Jędrzejewski-Szmek wrote: You can also make a symlink from /etc/systemd/system/xxx.service to either of the two files and manage it by hand, calling systemctl daemon-reload afterwards. I think this should work. If other systemd units have a Requires= dependency on this daemon, how do I deal with the toggle? Is there a Require=this-instance-OR-that-instance equivalent? No. I think then this is the right, or only?, way to deal with the toggle AND handle the Requires=. Set the other units' dependency to the **symlink**'s name Requires=xxx.service then manually change the symlink source AND daemon-reload to effect the toggle. Did I understand correctly? TerryG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-nspawn: Cannot create tun device in container
On Fri, Oct 3, 2014 at 7:46 PM, James Lott ja...@lottspot.com wrote: Hello, list! In some work I've been doing with systemd-nspawn containers, I've been trying to connect one of my containers to an openvpn network. This conteiner is being run with the --network-bridge flag to setup its networking, so according to the documentation, should retain CAP_NET_ADMIN capabilities. However, the container appears to be unable to create a new tun device Hi James, Thanks for the report, and sorry for the late reply. I just pushed a fix to git which creates /dev/net/tun in the container (if it exists on the host) and it appears to work for me. Please let me know whether this solves your problem. Cheers, Tom [root@lanvpn ~]# ip tuntap add dev tun0 mode tun open: No such file or directory I tried retaining the CAP_MKNOD capability for this container using the -- capability flag as well, and this met with the same result. I also tried binding the /dev/net device directory from the parent to the /dev/net device directory of the child container, and added the following line to the systemd-nspawn service file of the container [root@host01 ~]# grep Device /etc/systemd/system/lanvpn.service DeviceAllow=/dev/net/tun rwm This resulted in the error [root@lanvpn ~]# ip tuntap add tun0 mode tun open: Operation not permitted Is there any way to run my containers which will allow them to create tun/tap devices? System is arch linux arm, running systemd 216-r3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to exclusively toggle between two systemd instances of a single daemon?
On Wed, Oct 08, 2014 at 06:45:48AM -0700, terrygalant.li...@fastest.cc wrote: Hi Zbigniew On Wed, Oct 8, 2014, at 06:39 AM, Zbigniew Jędrzejewski-Szmek wrote: You can also make a symlink from /etc/systemd/system/xxx.service to either of the two files and manage it by hand, calling systemctl daemon-reload afterwards. I think this should work. If other systemd units have a Requires= dependency on this daemon, how do I deal with the toggle? Is there a Require=this-instance-OR-that-instance equivalent? No. I think then this is the right, or only?, way to deal with the toggle AND handle the Requires=. Set the other units' dependency to the **symlink**'s name The symlink is supposed to have the same name as the symlink target. Requires=xxx.service then manually change the symlink source AND daemon-reload to effect the toggle. Yes. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-detect-virt and vendors
Hi On Wed, Oct 8, 2014 at 9:46 AM, Lennart Poettering lenn...@poettering.net wrote: I think what would make a lot of sense though is to add a section to the man page somewhere, that explains which ID refers to which software from which vendor. Also, it might make sense to add a new switch to the tool, that dumps the table of known identifiers plus some description. Fair enough. I will see if I can do that. Would it be ok to add appropriate aliases to existing terms, virtualbox - oracle and hyperv - microsoft and mark the vendor names as deprecated? That way we retain compatibility while having the consistency (this is more than just about being pretty!) that everything is named after the technology and not the mismash of vendors names (oracle, microsoft) and technology names (kvm...) in a list. I will write up some patches to see if I can implement this cleanly and we will see how it goes. Rahul ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-detect-virt and vendors
On Wed, Oct 08, 2014 at 10:35:25AM -0400, Rahul Sundaram wrote: Hi On Wed, Oct 8, 2014 at 9:46 AM, Lennart Poettering lenn...@poettering.net wrote: I think what would make a lot of sense though is to add a section to the man page somewhere, that explains which ID refers to which software from which vendor. Also, it might make sense to add a new switch to the tool, that dumps the table of known identifiers plus some description. Fair enough. I will see if I can do that. Would it be ok to add appropriate aliases to existing terms, virtualbox - oracle and hyperv - microsoft and mark the vendor names as deprecated? That way we retain This would break compatibility, because systemd-detect-virt would have to start returning different strings. Zbyszek compatibility while having the consistency (this is more than just about being pretty!) that everything is named after the technology and not the mismash of vendors names (oracle, microsoft) and technology names (kvm...) in a list. I will write up some patches to see if I can implement this cleanly and we will see how it goes. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-detect-virt and vendors
Hi On Wed, Oct 8, 2014 at 10:37 AM, Zbigniew Jędrzejewski-Szmek wrote: This would break compatibility, because systemd-detect-virt would have to start returning different strings. Ah, I was thinking more about ConditionVirtualization but I guess we are kinda struck with what we already have for command line use. I guess I will just send some patches to clarify things in the man page and add a --list command and leave the rest as it is? Rahul ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-detect-virt and vendors
On Wed, Oct 08, 2014 at 10:42:21AM -0400, Rahul Sundaram wrote: Hi On Wed, Oct 8, 2014 at 10:37 AM, Zbigniew Jędrzejewski-Szmek wrote: This would break compatibility, because systemd-detect-virt would have to start returning different strings. Ah, I was thinking more about ConditionVirtualization but I guess we are kinda struck with what we already have for command line use. I guess I will just send some patches to clarify things in the man page and add a --list command and leave the rest as it is? Yeah, sounds good. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/4] shutdown: don't do final unmounting when inside the container and running without CAP_SYS_ADMIN
On Wed, Oct 08, 2014 at 01:41:16PM +0200, Lennart Poettering wrote:
On Tue, 07.10.14 14:17, Michal Sekletar (msekl...@redhat.com) wrote:
On Thu, Oct 02, 2014 at 12:04:02PM +0200, Lennart Poettering wrote:
On Thu, 02.10.14 09:57, Michal Sekletar (msekl...@redhat.com) wrote:
#define FINALIZE_ATTEMPTS 50
@@ -207,7 +208,11 @@ int main(int argc, char *argv[]) {
in_container = detect_container(NULL) 0;
-need_umount = true;
+if (in_container !have_effective_cap(CAP_SYS_ADMIN))
+need_umount = false;
+else
+need_umount = true;
+
need_swapoff = !in_container;
need_loop_detach = !in_container;
need_dm_detach = !in_container;
Hmm, I think we should just do need_umount = !in_container, like we
do for the other things like loopback detaching, dm detaching or
swapoff. After all, if we run in a container we run in a mount
namespace anyway, so unmounting things is done by the kernel
implicitly if the namespace dies. At least in theory this means we can
simply skip the unmounting in all containers, but I must admit that I
am not entirely clear on this one, so this needs to be tested in the
common container managers really, I figure...
Do you mind if I push just need_umount = !in_container then?
Well, yes.
I'd be thankful if you'd test this a bit first, so that this doesn't
break anything. Testing nspawn and on bare-metal should be enough.
Works just fine on F21 KVM guest and in rawhide nspawn container.
Michal
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 3/4] shutdown: don't do final unmounting when inside the container and running without CAP_SYS_ADMIN
On Wed, 08.10.14 16:49, Michal Sekletar (msekl...@redhat.com) wrote: Hmm, I think we should just do need_umount = !in_container, like we do for the other things like loopback detaching, dm detaching or swapoff. After all, if we run in a container we run in a mount namespace anyway, so unmounting things is done by the kernel implicitly if the namespace dies. At least in theory this means we can simply skip the unmounting in all containers, but I must admit that I am not entirely clear on this one, so this needs to be tested in the common container managers really, I figure... Do you mind if I push just need_umount = !in_container then? Well, yes. I'd be thankful if you'd test this a bit first, so that this doesn't break anything. Testing nspawn and on bare-metal should be enough. Works just fine on F21 KVM guest and in rawhide nspawn container. THen please, go ahead, commit with a good commit msg explaining things, maybe even referencing this discussion. 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-detect-virt and vendors
On Wed, 08.10.14 09:57, Rahul Sundaram (methe...@gmail.com) wrote: Hi On Wed, Oct 8, 2014 at 9:46 AM, Lennart Poettering wrote: I think what would make a lot of sense though is to add a section to the man page somewhere, that explains which ID refers to which software from which vendor. Also, it might make sense to add a new switch to the tool, that dumps the table of known identifiers plus some description. Fair enough. I will see if I can do that. Would it be ok to add appropriate aliases to existing terms, virtualbox - oracle and hyperv - microsoft and mark the vendor names as deprecated? That way we retain compatibility while having the consistency (this is more than just about being pretty!) that everything is named after the technology and not the mismash of vendors names (oracle, microsoft) and technology names (kvm...) in a list. Well, systemd-detect-virt outputs an id. People use it like so: if [ `systemd-detect-virt` = microsoft ] ; then ... fi THis really shouldn't get broken. In general I am against such redundancies of duplicate entries, unless we have a really strong reason. 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] core: don't allow enabling if unit is masked
On Wed, 08.10.14 15:29, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
On Wed, Oct 08, 2014 at 11:54:19AM +0200, Lennart Poettering wrote:
On Tue, 07.10.14 13:35, Jan Synacek (jsyna...@redhat.com) wrote:
---
src/shared/install.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/shared/install.c b/src/shared/install.c
index fa064c2..945bb27 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -1516,6 +1516,19 @@ int unit_file_enable(
return r;
STRV_FOREACH(i, files) {
+UnitFileState state;
+
+state = unit_file_get_state(scope, root_dir, *i);
+if (state 0) {
+log_error(Failed to get unit file state for %s:
%s, *i, strerror(-state));
+return state;
+}
+
+if (state == UNIT_FILE_MASKED || state ==
UNIT_FILE_MASKED_RUNTIME) {
+log_error(Failed to enable unit: Unit %s is
masked, *i);
+return -ENOTSUP;
+}
+
Looks mostly OK. However, we should probably use a more useful error
here. Maybe EADDRNOTAVAIL or so. Even better though would be to
actually change the call to take an sd_bus_error argument and then
return a proper error message that can be passed back to the bus
clients with a real explanation.
Yes, EADDRNOTAVAIL is used in another place where the unit is masked.
I'm not sure which one is more useful :). But hopefully this will be
an internal-only thing once meaningful dbus error messages are provided.
The problem with passing dbus *error into the lower levels is that
the functions live in src/share/, and were so far not linked with the
bus libraries.
Hmm, yeah, and if we did it would be cyclic and stuff...
I think that the best way to handle this would be to
use a temporary structure like
{ char *unit_name; char *error_message; int code}
and use this to pass the information about the error from the lower
to the upper levels. But maybe I'm overcomplicating things.
Hmm, maybe a simply solution would be to convert EADDRNOTAVAIL into a
proper sd_bus_error on the calling side, that shouldn't be too
difficult.
A related thing: there's a mapping bus-error - errno implemented,
but it only works for the errors defined in the library itself. It
would be nice to extend this mapping to the user defined errors,
e.g. in core/. Would you be amenable to adding a mechianism to
register additional mappings like bus-error-mapping.gperf so that they
are used by the library?
Maybe have internal versions of the conversion calls that allow
passing in an additional table?
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] Mounting $XGD_RUNTIME_DIR with units instead of logind code.
On Wed, 08.10.14 14:44, Maciej Wereski (m.were...@partner.samsung.com) wrote: Hello, Lately I've been working on updating systemd (currently 208) in Tizen. One of problems we've stumbled upon was with user@.service failing. Problem was on SMACK-enabled system, caused by 1c231f5 (logind: make $XDG_RUNTIME_DIR a per-user tmpfs). When $XDG_RUNTIME_DIR is mounted it inherits logind label, which in turn forbid users to access theirs directories. One solution would be to add if (use_smack()) mount(...smackfsroot=*...) in logind-user.c, but it would also require to add CAP_MAC_ADMIN to systemd-logind.service. This sounds like an OK solution to me. Another solution would be to remove mounting logic from logind-user.c completely and add run-user@.mount. user@.service would gain following lines: Requires=run-user@%I.mount After=run-user@%I.mount Unfortunately, currently it's not possible. First problem is that unit isn't named after path, so that requirement needs to be removed first. Second - we don't have gid, but it doesn't seem to be an issue, as mode is set to 0700. Then, in Tizen we could just add smackfsroot to options. Alternatively SmackLabel= option could be added for mount units, which would automatically append smackfsroot to options, when SMACK is enabled. How should we solve this issue? systemd .mount units are great for many things, but I am not sure I would bother with them in this case. I mean, they have the advantage of being integrated in the full dependency logic between mounts and devices and stuff, and that they can be introspected, enumerated, disabled, individually mounted and so on. But in this case nothing of this really matters, the mounting is always fully automatic, and it's a virtual file system, not backed by anything. THus, I'd really stick to raw mount() calls for this. I understand that this is not that great on smack systems, but that's how it is then... Maybe a better option would be to implement a mount wrapper call in util.c or so that takes the same arguments as mount() but internally does the SMACK logic so that we don't have to litter the smack code all over the place? THis would allow us to unify the smack related code in logind and PID1? 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] [Question/bug] Timeout after bus_event_loop_with_idle() change.
On Fri, 03.10.14 22:00, Daniel Buch (boogiewasth...@gmail.com) wrote: Hi, With current git and since 430e21c2f7e77d600257ead56419f51 i keep on getting timeout on these units dbuch@dbuch-laptop ~/dev/systemd (git)-[master] % systemctl --failed UNIT LOAD ACTIVE SUBDESCRIPTION ● systemd-hostnamed.service loaded failed failed Hostname Service ● systemd-localed.service loaded failed failed Locale Service ● systemd-timedated.service loaded failed failed Time Date Service My build config looks like this: --libexecdir=/usr/lib \ --localstatedir=/var \ --sysconfdir=/etc \ --enable-introspection \ --enable-gtk-doc \ --enable-kdbus \ --enable-compat-libs \ --enable-timesyncd \ --enable-lz4 \ --enable-terminal \ --enable-resolved \ --disable-audit \ --disable-ima \ --disable-multi-seat-x \ --disable-smack \ --with-sysvinit-path= \ --with-sysvrcnd-path= \ --with-firmware-path=/usr/lib/firmware/updates:/usr/lib/firmware \ Am i missing something? I havn't yet found any solution yet, and journal isn't helping me much here. Is this with kdbus enabled (in systemd, kernel, runtime)? 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] core: don't allow enabling if unit is masked
On Wed, Oct 08, 2014 at 05:02:31PM +0200, Lennart Poettering wrote:
On Wed, 08.10.14 15:29, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
On Wed, Oct 08, 2014 at 11:54:19AM +0200, Lennart Poettering wrote:
On Tue, 07.10.14 13:35, Jan Synacek (jsyna...@redhat.com) wrote:
---
src/shared/install.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/src/shared/install.c b/src/shared/install.c
index fa064c2..945bb27 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -1516,6 +1516,19 @@ int unit_file_enable(
return r;
STRV_FOREACH(i, files) {
+UnitFileState state;
+
+state = unit_file_get_state(scope, root_dir, *i);
+if (state 0) {
+log_error(Failed to get unit file state for
%s: %s, *i, strerror(-state));
+return state;
+}
+
+if (state == UNIT_FILE_MASKED || state ==
UNIT_FILE_MASKED_RUNTIME) {
+log_error(Failed to enable unit: Unit %s is
masked, *i);
+return -ENOTSUP;
+}
+
Looks mostly OK. However, we should probably use a more useful error
here. Maybe EADDRNOTAVAIL or so. Even better though would be to
actually change the call to take an sd_bus_error argument and then
return a proper error message that can be passed back to the bus
clients with a real explanation.
Yes, EADDRNOTAVAIL is used in another place where the unit is masked.
I'm not sure which one is more useful :). But hopefully this will be
an internal-only thing once meaningful dbus error messages are provided.
The problem with passing dbus *error into the lower levels is that
the functions live in src/share/, and were so far not linked with the
bus libraries.
Hmm, yeah, and if we did it would be cyclic and stuff...
I think that the best way to handle this would be to
use a temporary structure like
{ char *unit_name; char *error_message; int code}
and use this to pass the information about the error from the lower
to the upper levels. But maybe I'm overcomplicating things.
Hmm, maybe a simply solution would be to convert EADDRNOTAVAIL into a
proper sd_bus_error on the calling side, that shouldn't be too
difficult.
You can convert to an error, sure, but it is really nice to deliver
a specific message like Unit boo.service is masked, instead of
A unit is masked.
A related thing: there's a mapping bus-error - errno implemented,
but it only works for the errors defined in the library itself. It
would be nice to extend this mapping to the user defined errors,
e.g. in core/. Would you be amenable to adding a mechianism to
register additional mappings like bus-error-mapping.gperf so that they
are used by the library?
Maybe have internal versions of the conversion calls that allow
passing in an additional table?
That is not as convenient. E.g. sd_bus_error_set
internally calls bus_error_name_to_errno. Currently, this always
returns EIO for errors unknown to the library, and then the caller
does it own lookup (e.g. looking at transaction_add_job_and_dependencies()).
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Shell expressions in EnvironmentFile
Lennart Poettering wrote in message 20141008094838.GB26284@gardel-login: On Tue, 07.10.14 19:18, Simon Peeters (peeters.si...@gmail.com) wrote: ExecStart=/bin/sh -c . /something/that/sets/var; /some/file $var THis would certainly work, but I'd strongly advise to use exec for executing /some/file at the end, so that the shell process is replaced by the actual daemon process, instead of continuing running with the demon process as child. I am hijacking the thread because one minor inconvenience I have with sh -c 'exec foo' is that in journalctl the logging refers to 'sh': For instance: [Unit] Description=Git backup ConditionPathIsDirectory=%h/backups/gitbackup [Service] Type=simple ExecStart=/bin/sh -c 'exec %h/mine/script/gitbackup -v save' Nice=19 IOSchedulingClass=best-effort IOSchedulingPriority=7 gives me the log: Oct 08 21:35:43 mithrim sh[9680]: [master 54c23ae] Oct 08 21:35:43 mithrim sh[9680]: 2 files changed, 3 insertions(+), 3 deletions(-) Do you know of any way to get 'gitbackup' in the log rather than 'sh'? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Shell expressions in EnvironmentFile
On Wed, 08.10.14 18:07, Damien Robert (damien.olivier.robert+gm...@gmail.com) wrote: Lennart Poettering wrote in message 20141008094838.GB26284@gardel-login: On Tue, 07.10.14 19:18, Simon Peeters (peeters.si...@gmail.com) wrote: ExecStart=/bin/sh -c . /something/that/sets/var; /some/file $var THis would certainly work, but I'd strongly advise to use exec for executing /some/file at the end, so that the shell process is replaced by the actual daemon process, instead of continuing running with the demon process as child. I am hijacking the thread because one minor inconvenience I have with sh -c 'exec foo' is that in journalctl the logging refers to 'sh': For instance: [Unit] Description=Git backup ConditionPathIsDirectory=%h/backups/gitbackup [Service] Type=simple ExecStart=/bin/sh -c 'exec %h/mine/script/gitbackup -v save' Nice=19 IOSchedulingClass=best-effort IOSchedulingPriority=7 gives me the log: Oct 08 21:35:43 mithrim sh[9680]: [master 54c23ae] Oct 08 21:35:43 mithrim sh[9680]: 2 files changed, 3 insertions(+), 3 deletions(-) Do you know of any way to get 'gitbackup' in the log rather than 'sh'? SyslogIdentifier= should do it. See systemd.exec(5) for details. 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] journal: Fix sd_journal_enumerate_unique skipping values
On 2014-10-08 14:59, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Oct 08, 2014 at 08:24:49AM +0200, Jan Janssen wrote: Gesendet: Mittwoch, 08. Oktober 2014 um 01:40 Uhr Von: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl An: Jan Janssen medhe...@web.de Cc: systemd-devel@lists.freedesktop.org Betreff: Re: [systemd-devel] [PATCH] journal: Fix sd_journal_enumerate_unique skipping values On Mon, Oct 06, 2014 at 06:57:38PM +0200, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Oct 06, 2014 at 06:36:34PM +0200, Jan Janssen wrote: *bump* Sorry, I'll look into this. Doesn't work. Both without or with your other patch sd_journal_enumerate_unique I get bogus results on my test case. It seems the issue is more complicated. That's odd. Care to elaborate what bogus results means? Are you even affected by the bug in question without the patch? Yes, I have a VM where I get a smaller number from -F _BOOT_ID than from --list-boots (w/o your patches), and then the same smaller number with one or two of your patches. So results become consistent, but equally bad. Of course I can't know if this is exactly the same bug, but it certainly looks like it. Sounds like maybe one of those calls end up interleaving journals from different machines? Also, does removing the call to journal_file_object_release() in sd_journal_enumerate_unique() improve things or not? How about moving it after the if(found) where it was before the patch? I'd love to investigate this, but I sadly don't have any journals that triggers this :( Jan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v3] sd-dhcp-client: support non-Ethernet hardware addresses
Like Infiniband. See RFC 4390 section 2.1 for details on DHCP
and Infiniband; chaddr is zeroed, hlen is set to 0, and htype
is set to ARPHRD_INFINIBAND because IB hardware addresses
are 20 bytes in length.
---
v3: use arp_type for identifying client MAC address types, and
fix non-Ethernet hardware addresses in sd-dhcp6-client
src/libsystemd-network/dhcp-internal.h | 10 ++--
src/libsystemd-network/dhcp-network.c | 54 ++
src/libsystemd-network/dhcp-packet.c | 8 ++--
src/libsystemd-network/sd-dhcp-client.c| 74 +++---
src/libsystemd-network/sd-dhcp-server.c| 8 ++--
src/libsystemd-network/sd-dhcp6-client.c | 34 ++
src/libsystemd-network/test-dhcp-client.c | 14 --
src/libsystemd-network/test-dhcp-option.c | 2 +-
src/libsystemd-network/test-dhcp6-client.c | 8 +++-
src/network/networkd-dhcp4.c | 4 +-
src/network/networkd-link.c| 12 +++--
src/systemd/sd-dhcp-client.h | 4 +-
src/systemd/sd-dhcp6-client.h | 4 +-
13 files changed, 178 insertions(+), 58 deletions(-)
diff --git a/src/libsystemd-network/dhcp-internal.h
b/src/libsystemd-network/dhcp-internal.h
index 1069c8a..d358a49 100644
--- a/src/libsystemd-network/dhcp-internal.h
+++ b/src/libsystemd-network/dhcp-internal.h
@@ -20,22 +20,25 @@
You should have received a copy of the GNU Lesser General Public License
along with systemd; If not, see http://www.gnu.org/licenses/.
***/
#include stdint.h
#include linux/if_packet.h
+#include net/if_arp.h
#include net/ethernet.h
#include socket-util.h
#include sd-dhcp-client.h
#include dhcp-protocol.h
-int dhcp_network_bind_raw_socket(int index, union sockaddr_union *link,
uint32_t xid, struct ether_addr mac_addr);
+int dhcp_network_bind_raw_socket(int index, union sockaddr_union *link,
+ uint32_t xid, const uint8_t *mac_addr,
+ size_t mac_addr_len, uint16_t arp_type);
int dhcp_network_bind_udp_socket(be32_t address, uint16_t port);
int dhcp_network_send_raw_socket(int s, const union sockaddr_union *link,
const void *packet, size_t len);
int dhcp_network_send_udp_socket(int s, be32_t address, uint16_t port,
const void *packet, size_t len);
int dhcp_option_append(DHCPMessage *message, size_t size, size_t *offset,
uint8_t overload,
@@ -43,16 +46,17 @@ int dhcp_option_append(DHCPMessage *message, size_t size,
size_t *offset, uint8_
typedef int (*dhcp_option_cb_t)(uint8_t code, uint8_t len,
const uint8_t *option, void *user_data);
int dhcp_option_parse(DHCPMessage *message, size_t len,
dhcp_option_cb_t cb, void *user_data);
-int dhcp_message_init(DHCPMessage *message, uint8_t op, uint32_t xid, uint8_t
type,
- size_t optlen, size_t *optoffset);
+int dhcp_message_init(DHCPMessage *message, uint8_t op, uint32_t xid,
+ uint8_t type, uint16_t arp_type, size_t optlen,
+ size_t *optoffset);
uint16_t dhcp_packet_checksum(uint8_t *buf, size_t len);
void dhcp_packet_append_ip_headers(DHCPPacket *packet, be32_t source_addr,
uint16_t source, be32_t destination_addr,
uint16_t destination, uint16_t len);
diff --git a/src/libsystemd-network/dhcp-network.c
b/src/libsystemd-network/dhcp-network.c
index 1ced5cf..29e9993 100644
--- a/src/libsystemd-network/dhcp-network.c
+++ b/src/libsystemd-network/dhcp-network.c
@@ -18,27 +18,31 @@
***/
#include errno.h
#include sys/types.h
#include sys/socket.h
#include string.h
#include linux/if_packet.h
+#include linux/if_infiniband.h
#include net/ethernet.h
#include net/if_arp.h
#include stdio.h
#include unistd.h
#include linux/filter.h
#include socket-util.h
#include dhcp-internal.h
-int dhcp_network_bind_raw_socket(int ifindex, union sockaddr_union *link,
- uint32_t xid, struct ether_addr mac_addr) {
-
+static int _bind_raw_socket(int ifindex, union sockaddr_union *link,
+uint32_t xid, const uint8_t *mac_addr,
+size_t mac_addr_len,
+const uint8_t *bcast_addr,
+const struct ether_addr *eth_mac,
+uint16_t arp_type, uint8_t dhcp_hlen) {
struct sock_filter filter[] = {
BPF_STMT(BPF_LD + BPF_W + BPF_LEN, 0),
/* A - packet length */
BPF_JUMP(BPF_JMP + BPF_JGE + BPF_K, sizeof(DHCPPacket), 1, 0),
/* packet = DHCPPacket ? */
BPF_STMT(BPF_RET + BPF_K, 0),
/* ignore */
BPF_STMT(BPF_LD + BPF_B + BPF_ABS, offsetof(DHCPPacket,
Re: [systemd-devel] [systemd-commits] src/libsystemd
On Wed, 08.10.14 08:30, Daniel Mack (zon...@kemper.freedesktop.org) wrote:
-/* The higher 32bit of the flags field are considered
- * 'incompatible flags'. Refuse them all for now. */
-if (make-flags 0xULL) {
+/* The features field are considered 'incompatible flags'.
+ * Refuse them all for now. */
+if (make-features) {
safe_close(fd);
return -ENOTSUP;
This appears the wrong way around, we discussed in Berlin yesterday
that features should be the compatible bitmask, and flags should
be the incompatible 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] [PATCH] core: don't allow enabling if unit is masked
On Wed, 08.10.14 17:24, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
I think that the best way to handle this would be to
use a temporary structure like
{ char *unit_name; char *error_message; int code}
and use this to pass the information about the error from the lower
to the upper levels. But maybe I'm overcomplicating things.
Hmm, maybe a simply solution would be to convert EADDRNOTAVAIL into a
proper sd_bus_error on the calling side, that shouldn't be too
difficult.
You can convert to an error, sure, but it is really nice to deliver
a specific message like Unit boo.service is masked, instead of
A unit is masked.
Well, true, but then again, it's not thaat much worse...
A related thing: there's a mapping bus-error - errno implemented,
but it only works for the errors defined in the library itself. It
would be nice to extend this mapping to the user defined errors,
e.g. in core/. Would you be amenable to adding a mechianism to
register additional mappings like bus-error-mapping.gperf so that they
are used by the library?
Maybe have internal versions of the conversion calls that allow
passing in an additional table?
That is not as convenient. E.g. sd_bus_error_set
internally calls bus_error_name_to_errno. Currently, this always
returns EIO for errors unknown to the library, and then the caller
does it own lookup (e.g. looking at transaction_add_job_and_dependencies()).
What precisely are you proposing instead?
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] core: map the 'rescue' argument to rescue.target
On Tue, 07.10.14 14:55, Mantas Mikulėnas (graw...@gmail.com) wrote:
Even though the 'emergency' and 'single' aliases come from sysvinit, the
lack of 'rescue' is still quite confusing (caught me by surprise for the
9th time yet) and inconsistent with `systemctl rescue` as well.
Hmm, so I am normally conservative for adding non-prefixed new command
line arguments. THe ones we support exclusively exist for compat with
sysvinit.
However, you got me with the systemctl comparison, so I did merge
this now. We should be very careful though to add even more.
---
src/core/main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/core/main.c b/src/core/main.c
index 1a62e04..44373cc 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -272,6 +272,7 @@ static int parse_proc_cmdline_item(const char *key, const
char *value) {
static const char * const rlmap[] = {
emergency, SPECIAL_EMERGENCY_TARGET,
-b,SPECIAL_EMERGENCY_TARGET,
+rescue,SPECIAL_RESCUE_TARGET,
single,SPECIAL_RESCUE_TARGET,
-s,SPECIAL_RESCUE_TARGET,
s, SPECIAL_RESCUE_TARGET,
--
2.1.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] sd-event: be more careful when enabling/disabling signals
On Sun, 05.10.14 20:42, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
@@ -626,11 +634,13 @@ static void source_disconnect(sd_event_source *s) {
case SOURCE_SIGNAL:
if (s-signal.sig 0) {
-if (s-signal.sig != SIGCHLD ||
s-event-n_enabled_child_sources == 0)
-assert_se(sigdelset(s-event-sigset,
s-signal.sig) == 0);
-
if (s-event-signal_sources)
s-event-signal_sources[s-signal.sig] =
NULL;
+
+/* If the signal was on and now it is off... */
+if (s-enabled != SD_EVENT_OFF
!need_signal(s-event, s-signal.sig)) {
+assert_se(sigdelset(s-event-sigset,
s-signal.sig) == 0);
+}
Coding style: the extra {} should go.
s-event-n_enabled_child_sources--;
-}
-if (!s-event-signal_sources ||
!s-event-signal_sources[SIGCHLD])
-assert_se(sigdelset(s-event-sigset,
SIGCHLD) == 0);
+/* We know the signal was on, if it is off
now... */
+if (!need_signal(s-event, SIGCHLD)) {
+
assert_se(sigdelset(s-event-sigset, SIGCHLD) == 0);
+}
+}
Same here.
Patch looks good to me. If all tests pass and the system still boots
looks good to commit to me.
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] Incorrect logic when /etc/machine-id is missing
On Fri, 03.10.14 07:07, Jan Synacek (jsyna...@redhat.com) wrote: Now I was determined to fix this bug, however I'm left clueless as to how this is actually supposed to work. Is the entire logic in this piece of code wrong, or am I missing something? How is the (re)generating/mounting of machine-id supposed to work? I am pretty sure we *should* fail to boot if /etc/machine-id cannot be initialized because the root dir is read-only. However, we probably should print a good messages in this case, explaining the rationale. Thanks for the explanation! And yes, Cannot open %s isn't that helpful in this case. I'd be delighted to take a 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] [PATCH] journalctl: make --utc work everywhere
On Fri, 03.10.14 09:51, Jan Synacek (jsyna...@redhat.com) wrote:
The --utc option was introduced by commit
9fd290443f5f99fca0dcd4216b1de70f7d3b8db1.
Howerver, the implementation was incomplete.
---
src/journal/journalctl.c | 14 +++---
src/shared/logs-show.c | 2 +-
src/shared/time-util.c | 19 +++
src/shared/time-util.h | 3 ++-
4 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
index 395f85c..816934e 100644
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -890,8 +890,8 @@ static int list_boots(sd_journal *j) {
printf(% *i SD_ID128_FORMAT_STR %s—%s\n,
w, i - count + 1,
SD_ID128_FORMAT_VAL(id-id),
- format_timestamp(a, sizeof(a), id-first),
- format_timestamp(b, sizeof(b), id-last));
+ format_timestamp_internal(a, sizeof(a), id-first,
arg_utc),
+ format_timestamp_internal(b, sizeof(b), id-last,
arg_utc));
}
return 0;
@@ -1502,8 +1502,8 @@ static int verify(sd_journal *j) {
if (arg_verify_key
JOURNAL_HEADER_SEALED(f-header)) {
if (validated 0) {
log_info(= Validated from %s to
%s, final %s entries not sealed.,
- format_timestamp(a,
sizeof(a), first),
- format_timestamp(b,
sizeof(b), validated),
+
format_timestamp_internal(a, sizeof(a), first, arg_utc),
+
format_timestamp_internal(b, sizeof(b), validated, arg_utc),
format_timespan(c,
sizeof(c), last validated ? last - validated : 0, 0));
} else if (last 0)
log_info(= No sealing yet, %s of
entries not sealed.,
@@ -1898,11 +1898,11 @@ int main(int argc, char *argv[]) {
if (r 0) {
if (arg_follow)
printf(-- Logs begin at %s. --\n,
- format_timestamp(start_buf,
sizeof(start_buf), start));
+ format_timestamp_internal(start_buf,
sizeof(start_buf), start, arg_utc));
else
printf(-- Logs begin at %s, end at %s.
--\n,
- format_timestamp(start_buf,
sizeof(start_buf), start),
- format_timestamp(end_buf,
sizeof(end_buf), end));
+ format_timestamp_internal(start_buf,
sizeof(start_buf), start, arg_utc),
+ format_timestamp_internal(end_buf,
sizeof(end_buf), end, arg_utc));
}
}
diff --git a/src/shared/logs-show.c b/src/shared/logs-show.c
index d5d9d09..e30e686 100644
--- a/src/shared/logs-show.c
+++ b/src/shared/logs-show.c
@@ -447,7 +447,7 @@ static int output_verbose(
}
fprintf(f, %s [%s]\n,
-format_timestamp_us(ts, sizeof(ts), realtime),
+format_timestamp_us(ts, sizeof(ts), realtime, flags
OUTPUT_UTC),
cursor);
JOURNAL_FOREACH_DATA_RETVAL(j, data, length, r) {
diff --git a/src/shared/time-util.c b/src/shared/time-util.c
index 066ef97..09f4a21 100644
--- a/src/shared/time-util.c
+++ b/src/shared/time-util.c
@@ -152,7 +152,7 @@ struct timeval *timeval_store(struct timeval *tv, usec_t
u) {
return tv;
}
-char *format_timestamp(char *buf, size_t l, usec_t t) {
+char *format_timestamp_internal(char *buf, size_t l, usec_t t, bool utc) {
struct tm tm;
time_t sec;
@@ -164,13 +164,21 @@ char *format_timestamp(char *buf, size_t l, usec_t t) {
sec = (time_t) (t / USEC_PER_SEC);
-if (strftime(buf, l, %a %Y-%m-%d %H:%M:%S %Z, localtime_r(sec,
tm)) = 0)
+if (utc)
+gmtime_r(sec, tm);
+else
+localtime_r(sec, tm);
+if (strftime(buf, l, %a %Y-%m-%d %H:%M:%S %Z, tm) = 0)
return NULL;
return buf;
}
-char *format_timestamp_us(char *buf, size_t l, usec_t t) {
+char *format_timestamp(char *buf, size_t l, usec_t t) {
+return format_timestamp_internal(buf, l, t, false);
+}
+
+char *format_timestamp_us(char *buf, size_t l, usec_t t, bool utc) {
struct tm tm;
time_t sec;
@@ -181,7 +189,10 @@ char *format_timestamp_us(char *buf, size_t l, usec_t t)
{
return NULL;
sec = (time_t) (t / USEC_PER_SEC);
-
Re: [systemd-devel] [PATCH] core: don't allow enabling if unit is masked
On Wed, Oct 08, 2014 at 09:28:39PM +0200, Lennart Poettering wrote:
On Wed, 08.10.14 17:24, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
I think that the best way to handle this would be to
use a temporary structure like
{ char *unit_name; char *error_message; int code}
and use this to pass the information about the error from the lower
to the upper levels. But maybe I'm overcomplicating things.
Hmm, maybe a simply solution would be to convert EADDRNOTAVAIL into a
proper sd_bus_error on the calling side, that shouldn't be too
difficult.
You can convert to an error, sure, but it is really nice to deliver
a specific message like Unit boo.service is masked, instead of
A unit is masked.
Well, true, but then again, it's not thaat much worse...
Yeah, I guess now its time to do a proof-of-concept implementation to
see how it works in practice.
A related thing: there's a mapping bus-error - errno implemented,
but it only works for the errors defined in the library itself. It
would be nice to extend this mapping to the user defined errors,
e.g. in core/. Would you be amenable to adding a mechianism to
register additional mappings like bus-error-mapping.gperf so that they
are used by the library?
Maybe have internal versions of the conversion calls that allow
passing in an additional table?
That is not as convenient. E.g. sd_bus_error_set
internally calls bus_error_name_to_errno. Currently, this always
returns EIO for errors unknown to the library, and then the caller
does it own lookup (e.g. looking at transaction_add_job_and_dependencies()).
What precisely are you proposing instead?
typedef const name_error_mapping*
(*bus_error_mapping_lookup_t) (const char *str, size_t len);
int bus_error_add_mapping(bus_error_mapping_lookup_t mapping);
This could be used to register a custom function similar to our
bus_error_mapping_lookup(). It would get stored in a global table (of
fixed size?), and bus_error_mapping_lookup would be the first slot in
this table and the calls to bus_error_mapping_lookup would be
replace by a function which iterates over this table and
returns the first successful lookup.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: don't allow enabling if unit is masked
On Wed, 08.10.14 23:07, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
A related thing: there's a mapping bus-error - errno implemented,
but it only works for the errors defined in the library itself. It
would be nice to extend this mapping to the user defined errors,
e.g. in core/. Would you be amenable to adding a mechianism to
register additional mappings like bus-error-mapping.gperf so that they
are used by the library?
Maybe have internal versions of the conversion calls that allow
passing in an additional table?
That is not as convenient. E.g. sd_bus_error_set
internally calls bus_error_name_to_errno. Currently, this always
returns EIO for errors unknown to the library, and then the caller
does it own lookup (e.g. looking at
transaction_add_job_and_dependencies()).
What precisely are you proposing instead?
typedef const name_error_mapping*
(*bus_error_mapping_lookup_t) (const char *str, size_t len);
int bus_error_add_mapping(bus_error_mapping_lookup_t mapping);
This could be used to register a custom function similar to our
bus_error_mapping_lookup(). It would get stored in a global table (of
fixed size?), and bus_error_mapping_lookup would be the first slot in
this table and the calls to bus_error_mapping_lookup would be
replace by a function which iterates over this table and
returns the first successful lookup.
I am really not a fan of global variables for things like this... If
it would be marked as TLS I'd feel a bit more comfortable though...
I wonder what it would take to make this work without any registration
code. i.e. we could use some executbale section tricks hidden in some
macros to allow any module to register mappings, and simply by being
compiled in we'd find them.
In such a scheme the registration race and scope issues should go
away, since everything is always registered in all threads.
To define a map array, in as many .c files as desired:
__attribute((__section__(errnomap))) __attribute((__used__)) const struct
struct my_errno_map[] = { };
And then, use this to find the section:
extern struct my_errno_map[] __start_errnomap;
extern struct my_errno_map[] __stop_errnomap;
gcc supposedly maps this automatically to the start and end of the
section we defined above (yes, __start_ and __stop_ is magic), and
then we can just enumerate through them. And any .c module that
defines more maps transparently is found.
Or something 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] [question] networkd: Any support for hooks?
On Thu, 02.10.14 19:48, Cameron Norman (camerontnor...@gmail.com) wrote: On Wed, Oct 1, 2014 at 10:36 PM, Tom Gundersen t...@jklm.no wrote: Hi Cameron, On Thu, Oct 2, 2014 at 6:36 AM, Cameron Norman camerontnor...@gmail.com wrote: ifupdown [1], NetworkManager, and WICD all support hooks for when a network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? I am sceptical to adding hooks, so would need a lot of convincing. What we do, however, is to expose the configuration state using the sd-network C API, which external programs can watch and react on (see how timesyncd and resolved currently works). Does the C API allow programs to temporarily stall bringing up or down the interface, or does it only deliver signals of if state? No it does not allow synchronous hooks. Only asynchronous notification is supported. Out of curiosity, where does your aversion to hooks come from? Does it add significant complication code wise, or is it more with respect to using networkd before any filesystems are mounted (thus the hook files would not be present)? Well, we want networkd to be clean and properly written, and I simply have the suspicion that if start allowing glueing in badly integrated stuff via shell scripts, we'll have a hard time to ever fix this again. I mean, network management solutions that shell out to external tools we have enough, but networkd is really not supposed to be like that. It shouldn't just be a glued together thing, but somewhat uniform. 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] [feature request] allow instances in file.preset
On Fri, 03.10.14 19:18, Damien Robert (damien.olivier.rob...@gmail.com) wrote: From Lennart Poettering, Thu 02 Oct 2014 at 16:48:19 (+0200) : Well, but from somewhere systemctl preset-all needs to be able to discover the bar string... How is that supposed to work? preset-all just enumerates all unit files that are installed and enables/disables them according to the preset file. But this means it would only find the template, and the instance would have to come from somewhere else, but where? From the preset file? I agree that since the enable/disable directive denotes glob, they are not well suited for instances services. Maybe add a No, we enumerate the installed unit files, and then look them up in the preset files. new directive: instanciate foo@bar.service uninstanciate foo@bar.service (the uninstanciate is because disable does not disable instancied service for the same reason enable doe not enable them). I do not feel too strongly on this feature, afterwards it might as well be easier to call systemctl enable directly... I have the impression that the current scheme already does everything what you need, no? I mean, if you list the template unit file in the preset file, and we enumerate such a template unit file, we end up enabling it's DefaultInstance=, which should be enough for you? Or am I missing something? 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] journalctl: allow customizable output formats
On Mon, 22.09.14 16:33, Daniel P. Berrange (berra...@redhat.com) wrote:
The current '--output FORMAT' argument defines a number of
common output formats, but there are some useful cases it
does cover. In particular when reading application logs it
is often desirable to display the code file name, line number
and function name. Rather than defining yet more fixed output
formats, this patch introduces user defined output formats.
The format string is an arbitrary string which contains a
mixture of literal text and variable subsistitions. Each
variable name corresponds to a journal field name. A variable
name can be optionally followed by a data type, and in the
case of string types, a length limit.
Hmm, hmm, hmm.
I am quite afraid about inventing a new template language for this. I
can see the usecase though, and I sympasize with it.
I am particularly afraid of the entire type thing. The fact that the
journal is more or less typeless is after all by design: i really
didn't want to invent a new type system. Adding this to the formatter
now, kinda feels like adding it after all, but through the backdoor...
So, I am not against this in general, but I'd really be careful with
the language we define here, and try to make this as similar to an
existing language (like the python/java one Zbigniew mentioned) as we
can.
Or even better, we already have a very limited formatting language in
place, which is the specifier logic, that can replace %i, %f and
such things in unit files, maybe we can build on this, and allow
specifiers to take a field name as parameter. Then, if we really need
formatters for different field types, we could just give them
high-level characters or so?
Hmm, also, we already have a really bad formatter in place for the
journal catalog files (which only replaces @foo@ by the value of field
foo). We should probably use the same code for this new journalctl
formatter and the catalog code. In fact the catalog formatter could
really use some improvement...
Maybe something like this:
journalctl -O %t %s{CODE_FILE}:%s{CODE_LINE} %d{_SOURCE_REALTIME_TIMESTAMP}
or something like that, where %t would simply map to the timestamp,
and %s{} maps to a field name, and %d{} the same, but reformats the
field as timestamp, assuming it is a UNIX timestamp formatted as
number...
Or something like that...
Other ideas?
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] [question] networkd: Any support for hooks?
On Wed, Oct 8, 2014 at 2:26 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 02.10.14 19:48, Cameron Norman (camerontnor...@gmail.com) wrote: On Wed, Oct 1, 2014 at 10:36 PM, Tom Gundersen t...@jklm.no wrote: Hi Cameron, On Thu, Oct 2, 2014 at 6:36 AM, Cameron Norman camerontnor...@gmail.com wrote: ifupdown [1], NetworkManager, and WICD all support hooks for when a network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? I am sceptical to adding hooks, so would need a lot of convincing. What we do, however, is to expose the configuration state using the sd-network C API, which external programs can watch and react on (see how timesyncd and resolved currently works). Does the C API allow programs to temporarily stall bringing up or down the interface, or does it only deliver signals of if state? No it does not allow synchronous hooks. Only asynchronous notification is supported. Out of curiosity, where does your aversion to hooks come from? Does it add significant complication code wise, or is it more with respect to using networkd before any filesystems are mounted (thus the hook files would not be present)? Well, we want networkd to be clean and properly written, and I simply have the suspicion that if start allowing glueing in badly integrated stuff via shell scripts, we'll have a hard time to ever fix this again. I mean, network management solutions that shell out to external tools we have enough, but networkd is really not supposed to be like that. It shouldn't just be a glued together thing, but somewhat uniform. Ok, that is a good reason, what I had slightly imagined. Now that I have looked in the hook dirs of ifupdown more closely, I have noticed pretty much only async stuff, except for some ethtool, wpasupplicant, and avahi-autoipd scripts. The avahi-autoipd one seems like it may be misplaced, and is probably just fine in post-down (which is async, compared to down). Thank you, -- Cameron Norman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-detect-virt and vendors
From: Rahul Sundaram methe...@gmail.com We really should be more specific and call it virtualbox and hyper-v instead, similar to say virt-what and other similar tools. I will be happy write the patches if this makes sense. At the least, we need documentation that tells the user what name systemd uses, based on the name(s) that the user is likely to know the product by (which may not be the current name of the product). This would work reasonably well: The following technologies are currently identified: qemu, kvm, vmware, microsoft (a/k/a Hyper-V, Viridian, Windows Server Virtualization), oracle (a/k/a VirtualBox), xen, bochs, chroot, openvz, lxc, lxc-libvirt, systemd-nspawn. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: don't allow enabling if unit is masked
On Wed, Oct 08, 2014 at 11:23:51PM +0200, Lennart Poettering wrote:
On Wed, 08.10.14 23:07, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
A related thing: there's a mapping bus-error - errno implemented,
but it only works for the errors defined in the library itself. It
would be nice to extend this mapping to the user defined errors,
e.g. in core/. Would you be amenable to adding a mechianism to
register additional mappings like bus-error-mapping.gperf so that
they
are used by the library?
Maybe have internal versions of the conversion calls that allow
passing in an additional table?
That is not as convenient. E.g. sd_bus_error_set
internally calls bus_error_name_to_errno. Currently, this always
returns EIO for errors unknown to the library, and then the caller
does it own lookup (e.g. looking at
transaction_add_job_and_dependencies()).
What precisely are you proposing instead?
typedef const name_error_mapping*
(*bus_error_mapping_lookup_t) (const char *str, size_t len);
int bus_error_add_mapping(bus_error_mapping_lookup_t mapping);
This could be used to register a custom function similar to our
bus_error_mapping_lookup(). It would get stored in a global table (of
fixed size?), and bus_error_mapping_lookup would be the first slot in
this table and the calls to bus_error_mapping_lookup would be
replace by a function which iterates over this table and
returns the first successful lookup.
I am really not a fan of global variables for things like this... If
it would be marked as TLS I'd feel a bit more comfortable though...
I wonder what it would take to make this work without any registration
code. i.e. we could use some executbale section tricks hidden in some
macros to allow any module to register mappings, and simply by being
compiled in we'd find them.
In such a scheme the registration race and scope issues should go
away, since everything is always registered in all threads.
To define a map array, in as many .c files as desired:
__attribute((__section__(errnomap))) __attribute((__used__)) const struct
struct my_errno_map[] = { };
And then, use this to find the section:
extern struct my_errno_map[] __start_errnomap;
extern struct my_errno_map[] __stop_errnomap;
gcc supposedly maps this automatically to the start and end of the
section we defined above (yes, __start_ and __stop_ is magic), and
then we can just enumerate through them. And any .c module that
defines more maps transparently is found.
That would be lovely. Last time I checked, a custom linker
script was also necessary, but this was a long time ago, so maybe
things have changed.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)
On Sun, 21.09.14 23:40, Alexander Groleau (awg...@xbetanet.com) wrote: Hello systemd users, I have been trying desperately for weeks to get my simple shutdown script for a Libvirt guest to run before libvirtd is shut down, without success. Essentially, I need the libvirt-windows.sh script to run before the libvirtd service is terminated (which occurs right after systemd-logind outputs its reboot message). How can I get my script into this initial section of daemon shutdowns, at the top? If you want to something to have something executed before another unit is stopped, then write a service that has: [Unit] After=otherservice.service [Service] Type=oneshot RemainAfterExit=true ExecStart=/bin/true ExecStop=/your/code [Install] WantedBy=otherservice.service Explanation: The ExecStart=/bin/true we just add because current systemd versions refuse to run service units that have no ExecStart= set. It is on the TODO list to allow services also when they have no ExecStart= but with an ExecStop=, but this has not been implemented yet. The ExecStop= is where you place your code. Type=oneshot + RemainAfterExit=true make sure the service gets started properly and then stays around without any processes. The After= orders the unit after the unit you want to be stopped before. Note that in systemd the shutdown order is always the inverse of the startup order. Hence, if you order your new unit with After= after the unit you want to be stopped before, then this has the desired effect. Finally, WantedBy= makes sure you can enable your new unit with systemctl enable, and the right thing will 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] journal repair
On Fri, 19.09.14 10:00, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: Is the plan to introduce an repair switch or is the plan to inform the users how they should proceed if that is not the case since users are getting confused when they encounter journal errors like these Data object missing from hash at entry... Data object references invalid entry at... Invalid tail monotonic timestamp... Invalid object contents at... File corruption detected at... etc. And are wasting their time on the internet searching for means to fix those errors. I think we need to somehow provide the end user with the next step once a corruption of anykind has been detected in the relevant journal file even if it's just. FAIL: corruption detected, your logs are fucked delete the file. There isn't really any point in deleting them. journalctl salvages automatically everything it can when reading them. Since the files are mostly append-only the corruptions usually only affect half-written entries at the end, and hence all earlier once should just work. I am pretty sure we simply need to document this in more detail, and clarify that corrupted journal files are nothing to act on, and the journalctl recovers what it can on read, implicitly, with no fsck-like tool being necessary, and without requiring people to manually delete anything. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] sd-event: be more careful when enabling/disabling signals
On Wed, Oct 08, 2014 at 09:44:33PM +0200, Lennart Poettering wrote:
On Sun, 05.10.14 20:42, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
@@ -626,11 +634,13 @@ static void source_disconnect(sd_event_source *s) {
case SOURCE_SIGNAL:
if (s-signal.sig 0) {
-if (s-signal.sig != SIGCHLD ||
s-event-n_enabled_child_sources == 0)
-assert_se(sigdelset(s-event-sigset,
s-signal.sig) == 0);
-
if (s-event-signal_sources)
s-event-signal_sources[s-signal.sig] =
NULL;
+
+/* If the signal was on and now it is off... */
+if (s-enabled != SD_EVENT_OFF
!need_signal(s-event, s-signal.sig)) {
+assert_se(sigdelset(s-event-sigset,
s-signal.sig) == 0);
+}
Coding style: the extra {} should go.
This was in preparation for the next patch, which adds more the body.
Wonders of 'git add -p' :)
s-event-n_enabled_child_sources--;
-}
-if (!s-event-signal_sources ||
!s-event-signal_sources[SIGCHLD])
-assert_se(sigdelset(s-event-sigset,
SIGCHLD) == 0);
+/* We know the signal was on, if it is off
now... */
+if (!need_signal(s-event, SIGCHLD)) {
+
assert_se(sigdelset(s-event-sigset, SIGCHLD) == 0);
+}
+}
Same here.
Patch looks good to me. If all tests pass and the system still boots
looks good to commit to me.
Yeah, it boots. Pushed.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] booting A/B rootfs
Hi, I have limited knowledge of the boot process. I'm wondering if the following is possible with systemd. Imagine you have 2 rootfs partitions. You build a new rootfs on a security update or when a new version of a listed package that has dependencies is released and extract this on either A or B partition (A if B is the current rootfs, B if A is the current rootfs) The idea is, with systemd you can isolate targets. I assume you could shutdown all services so that nothing but systemd is running. Then unmount the current rootfs and mount the new rootfs and boot to default target. All without needing to poweroff or physically reboot the system. Only if you install a new kernel a real reboot would be required. Would this be possible with systemd in its current state? Why? Minimal downtime and if the new rootfs fails for whatever reason you could revert to the old rootfs but have a consistent userspace. Or you could run a testing system and if the new image reports no errors flag it stable and distribute to clients. And if this is possible, what if... you could shutdown the current running kernel and boot a new kernel which would in turn again run init and boot targets. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to exclusively toggle between two systemd instances of a single daemon?
On Wed, Oct 8, 2014 at 4:39 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Wed, Oct 08, 2014 at 06:30:51AM -0700, terrygalant.li...@fastest.cc wrote: Hi I have 2 installed instances of a single daemon. 1 is from distro-installed packages, installed into standard default OS locations with unit files in /usr/lib/systemd/system/. The other is installed under /opt, with unit files currently in /opt/mydaemon/systemd/system/, which can be (un)symlinked as needed into /etc/systemd/system/multi-user.target.wants/ to disable or enable. I want to be able to occasionally toggle between use of the 2. Is the right systemd way to do manage this toggle to just name the 2 instances' unit files differently, put a Conflicts= in each for the other, and just use 'enable' for whichever I want active? That would work. You can also make a symlink from /etc/systemd/system/xxx.service to either of the two files and manage it by hand, calling systemctl daemon-reload afterwards. I think this should work. Hmm, isn't this basically the same as adding identical [Install] Alias= entries, and using `systemctl enable -f` to manage them? -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to exclusively toggle between two systemd instances of a single daemon?
On Thu, Oct 09, 2014 at 07:51:32AM +0300, Mantas Mikulėnas wrote: On Wed, Oct 8, 2014 at 4:39 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Wed, Oct 08, 2014 at 06:30:51AM -0700, terrygalant.li...@fastest.cc wrote: Hi I have 2 installed instances of a single daemon. 1 is from distro-installed packages, installed into standard default OS locations with unit files in /usr/lib/systemd/system/. The other is installed under /opt, with unit files currently in /opt/mydaemon/systemd/system/, which can be (un)symlinked as needed into /etc/systemd/system/multi-user.target.wants/ to disable or enable. I want to be able to occasionally toggle between use of the 2. Is the right systemd way to do manage this toggle to just name the 2 instances' unit files differently, put a Conflicts= in each for the other, and just use 'enable' for whichever I want active? That would work. You can also make a symlink from /etc/systemd/system/xxx.service to either of the two files and manage it by hand, calling systemctl daemon-reload afterwards. I think this should work. Hmm, isn't this basically the same as adding identical [Install] Alias= entries, and using `systemctl enable -f` to manage them? In some cases yes, but his unit files are outside of the normal search paths, so I don't this would work. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: don't allow enabling if unit is masked
Lennart Poettering lenn...@poettering.net writes:
On Wed, 08.10.14 17:24, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
I think that the best way to handle this would be to
use a temporary structure like
{ char *unit_name; char *error_message; int code}
and use this to pass the information about the error from the lower
to the upper levels. But maybe I'm overcomplicating things.
Hmm, maybe a simply solution would be to convert EADDRNOTAVAIL into a
proper sd_bus_error on the calling side, that shouldn't be too
difficult.
You can convert to an error, sure, but it is really nice to deliver
a specific message like Unit boo.service is masked, instead of
A unit is masked.
Well, true, but then again, it's not thaat much worse...
A related thing: there's a mapping bus-error - errno implemented,
but it only works for the errors defined in the library itself. It
would be nice to extend this mapping to the user defined errors,
e.g. in core/. Would you be amenable to adding a mechianism to
register additional mappings like bus-error-mapping.gperf so that they
are used by the library?
Maybe have internal versions of the conversion calls that allow
passing in an additional table?
That is not as convenient. E.g. sd_bus_error_set
internally calls bus_error_name_to_errno. Currently, this always
returns EIO for errors unknown to the library, and then the caller
does it own lookup (e.g. looking at transaction_add_job_and_dependencies()).
What precisely are you proposing instead?
What about extending usage of errno with systemd specific errors?
Something like EUNITMASKED or Eanything systemd specific? Plus,
implementing extended version of strerror(), which would use the
standard stderror() for the standard errno?
--
Jan Synacek
Software Engineer, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [question] networkd: Any support for hooks?
Hi Cameron, ifupdown [1], NetworkManager, and WICD all support hooks for when a network interface is configured or deconfigured (before and after these actions). Are there any plans to support something along these lines? If so, what will that look like? If there are no plans, how do networkd's developers feel about adding the feature (will not merge, or will accept patches, etc.) ? I am sceptical to adding hooks, so would need a lot of convincing. What we do, however, is to expose the configuration state using the sd-network C API, which external programs can watch and react on (see how timesyncd and resolved currently works). Does the C API allow programs to temporarily stall bringing up or down the interface, or does it only deliver signals of if state? No it does not allow synchronous hooks. Only asynchronous notification is supported. Out of curiosity, where does your aversion to hooks come from? Does it add significant complication code wise, or is it more with respect to using networkd before any filesystems are mounted (thus the hook files would not be present)? Well, we want networkd to be clean and properly written, and I simply have the suspicion that if start allowing glueing in badly integrated stuff via shell scripts, we'll have a hard time to ever fix this again. I mean, network management solutions that shell out to external tools we have enough, but networkd is really not supposed to be like that. It shouldn't just be a glued together thing, but somewhat uniform. Ok, that is a good reason, what I had slightly imagined. Now that I have looked in the hook dirs of ifupdown more closely, I have noticed pretty much only async stuff, except for some ethtool, wpasupplicant, and avahi-autoipd scripts. The avahi-autoipd one seems like it may be misplaced, and is probably just fine in post-down (which is async, compared to down). actually not using avahi-autoipd is the way you really want to go. Especially since networkd will do IPv4LL setup for you anyway. Same applies to ethtool hooks since they should be done by link files and configured by udev. For the wpa_supplicant, we are going to fix that one with a proper daemon soon. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journalctl: make --utc work everywhere
Lennart Poettering lenn...@poettering.net writes:
On Fri, 03.10.14 09:51, Jan Synacek (jsyna...@redhat.com) wrote:
The --utc option was introduced by commit
9fd290443f5f99fca0dcd4216b1de70f7d3b8db1.
Howerver, the implementation was incomplete.
---
src/journal/journalctl.c | 14 +++---
src/shared/logs-show.c | 2 +-
src/shared/time-util.c | 19 +++
src/shared/time-util.h | 3 ++-
4 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
index 395f85c..816934e 100644
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -890,8 +890,8 @@ static int list_boots(sd_journal *j) {
printf(% *i SD_ID128_FORMAT_STR %s—%s\n,
w, i - count + 1,
SD_ID128_FORMAT_VAL(id-id),
- format_timestamp(a, sizeof(a), id-first),
- format_timestamp(b, sizeof(b), id-last));
+ format_timestamp_internal(a, sizeof(a), id-first,
arg_utc),
+ format_timestamp_internal(b, sizeof(b), id-last,
arg_utc));
}
return 0;
@@ -1502,8 +1502,8 @@ static int verify(sd_journal *j) {
if (arg_verify_key
JOURNAL_HEADER_SEALED(f-header)) {
if (validated 0) {
log_info(= Validated from %s to
%s, final %s entries not sealed.,
- format_timestamp(a,
sizeof(a), first),
- format_timestamp(b,
sizeof(b), validated),
+
format_timestamp_internal(a, sizeof(a), first, arg_utc),
+
format_timestamp_internal(b, sizeof(b), validated, arg_utc),
format_timespan(c,
sizeof(c), last validated ? last - validated : 0, 0));
} else if (last 0)
log_info(= No sealing yet, %s of
entries not sealed.,
@@ -1898,11 +1898,11 @@ int main(int argc, char *argv[]) {
if (r 0) {
if (arg_follow)
printf(-- Logs begin at %s. --\n,
- format_timestamp(start_buf,
sizeof(start_buf), start));
+ format_timestamp_internal(start_buf,
sizeof(start_buf), start, arg_utc));
else
printf(-- Logs begin at %s, end at %s.
--\n,
- format_timestamp(start_buf,
sizeof(start_buf), start),
- format_timestamp(end_buf,
sizeof(end_buf), end));
+ format_timestamp_internal(start_buf,
sizeof(start_buf), start, arg_utc),
+ format_timestamp_internal(end_buf,
sizeof(end_buf), end, arg_utc));
}
}
diff --git a/src/shared/logs-show.c b/src/shared/logs-show.c
index d5d9d09..e30e686 100644
--- a/src/shared/logs-show.c
+++ b/src/shared/logs-show.c
@@ -447,7 +447,7 @@ static int output_verbose(
}
fprintf(f, %s [%s]\n,
-format_timestamp_us(ts, sizeof(ts), realtime),
+format_timestamp_us(ts, sizeof(ts), realtime, flags
OUTPUT_UTC),
cursor);
JOURNAL_FOREACH_DATA_RETVAL(j, data, length, r) {
diff --git a/src/shared/time-util.c b/src/shared/time-util.c
index 066ef97..09f4a21 100644
--- a/src/shared/time-util.c
+++ b/src/shared/time-util.c
@@ -152,7 +152,7 @@ struct timeval *timeval_store(struct timeval *tv, usec_t
u) {
return tv;
}
-char *format_timestamp(char *buf, size_t l, usec_t t) {
+char *format_timestamp_internal(char *buf, size_t l, usec_t t, bool utc) {
struct tm tm;
time_t sec;
@@ -164,13 +164,21 @@ char *format_timestamp(char *buf, size_t l, usec_t t) {
sec = (time_t) (t / USEC_PER_SEC);
-if (strftime(buf, l, %a %Y-%m-%d %H:%M:%S %Z, localtime_r(sec,
tm)) = 0)
+if (utc)
+gmtime_r(sec, tm);
+else
+localtime_r(sec, tm);
+if (strftime(buf, l, %a %Y-%m-%d %H:%M:%S %Z, tm) = 0)
return NULL;
return buf;
}
-char *format_timestamp_us(char *buf, size_t l, usec_t t) {
+char *format_timestamp(char *buf, size_t l, usec_t t) {
+return format_timestamp_internal(buf, l, t, false);
+}
+
+char *format_timestamp_us(char *buf, size_t l, usec_t t, bool utc) {
struct tm tm;
time_t sec;
@@ -181,7 +189,10 @@ char *format_timestamp_us(char *buf, size_t l, usec_t
t) {
return NULL;
