Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM
On Fri, Oct 10, 2014 at 11:54 PM, Anatol Pomozov wrote: > 1) Why not to make the timeout configurable through config file? There > is already udev.conf you can put config option there. Thus people with > modprobe issues can easily "fix" the problem. And then decrease > default timeout back to 30 seconds. I agree that long module loading > (more than 30 secs) is abnormal and should be investigated by driver > authors. We can already configure this either on the udev or kernel commandline, is that not sufficient (I don't object to also adding it to the config file, just asking)? > 2) Could you add 'echo w > /proc/sysrq-trigger' to udev code right > before killing the "modprobe" thread? sysrq will print information > about stuck threads (including modprobe itself) this will make > debugging easier. e.g. dmesg here > https://bugs.archlinux.org/task/40454 says nothing where the threads > were stuck. Are the current warnings (in udev git) sufficient (should tell you which module is taking long, but still won't tell you which kernel thread of course)? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC v2 3/6] kthread: warn on kill signal if not OOM
Hi On Fri, Sep 12, 2014 at 1:09 PM, Luis R. Rodriguez wrote: > On Thu, Sep 11, 2014 at 10:48 PM, Tom Gundersen wrote: >> On Fri, Sep 12, 2014 at 12:26 AM, Luis R. Rodriguez >> wrote: >>> On Thu, Sep 11, 2014 at 2:43 PM, Tom Gundersen wrote: How about simply introducing a new flag to finit_module() to indicate that the caller does not care about asynchronicity. We could then pass this from udev, but existing scripts calling modprobe/insmod will not be affected. >>> >>> Do you mean that you *do want asynchronicity*? >> >> Precisely, udev would opt-in, but existing scripts etc would not. > > Sure that's the other alternative that Tejun was mentioning. > But isn't finit_module() taking a long time a serious problem given that it means no other module can be loaded in parallel? >>> >>> Indeed but having a desire to make the init() complete fast is >>> different than the desire to have the combination of both init and >>> probe fast synchronously. >> >> I guess no one is arguing that probe should somehow be required to be >> fast, but rather: >> >>> If userspace wants init to be fast and let >>> probe be async then userspace has no option but to deal with the fact >>> that async probe will be async, and it should then use other methods >>> to match any dependencies if its doing that itself. >> >> Correct. And this therefore likely needs to be opt-in behaviour per >> finit_module() invocation to avoid breaking old assumptions. > > Sure. > >>> For example >>> networking should not kick off after a network driver is loaded but >>> rather one the device creeps up on udev. We should be good with >>> networking dealing with this correctly today but not sure about other >>> subsystems. depmod should be able to load the required modules in >>> order and if bus drivers work right then probe of the remnant devices >>> should happen asynchronously. The one case I can think of that is a >>> bit different is modules-load.d things but those *do not rely on the >>> timeout*, but are loaded prior to a service requirement. Note though >>> that if those modules had probe and they then run async'd then systemd >>> service would probably need to consider that the requirements may not >>> be there until later. If this is not carefully considered that could >>> introduce regression to users of modules-load.d when async probe is >>> fully deployed. The same applies to systemd making assumptions of kmod >>> loading a module and a dependency being complete as probe would have >>> run it before. >> >> Yeah, these all needs to be considered when deciding whether or not to >> enable async in each specific case. > > Yes and come to think of it I'd recommend opting out of async > functionality for modules-load.d given that it does *not* hooked with > the timeout and there is a good chances its users likely do want to > wait for probe to run at this point. > > Given this I also am inclined now for the per module request to be > async or not (default) from userspace. The above would be a good > example starting use case. > >>> I believe one concern here lies in on whether or not userspace >>> is properly equipped to deal with the requirements on module loading >>> doing async probing and that possibly failing. Perhaps systemd might >>> think all userspace is ready for that but are we sure that's the case? >> >> There almost certainly are custom things out there relying on the >> synchronous behaviour, but if we make it opt-in we should not have a >> problem. We recently discussed this "timeout module loading" issue in Arch IRC and here are few more ideas: 1) Why not to make the timeout configurable through config file? There is already udev.conf you can put config option there. Thus people with modprobe issues can easily "fix" the problem. And then decrease default timeout back to 30 seconds. I agree that long module loading (more than 30 secs) is abnormal and should be investigated by driver authors. 2) Could you add 'echo w > /proc/sysrq-trigger' to udev code right before killing the "modprobe" thread? sysrq will print information about stuck threads (including modprobe itself) this will make debugging easier. e.g. dmesg here https://bugs.archlinux.org/task/40454 says nothing where the threads were stuck. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bus-proxyd: fix compatibility with old dbus-1
On 10/10/2014 04:42 PM, Lukasz Skalski wrote:
> 'ListQueuedOwners' method should return 'NameHasNoOwner' error
> if chosen name is not available on bus.
Applied, thanks!
>
> ---
> src/bus-proxyd/bus-proxyd.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/src/bus-proxyd/bus-proxyd.c b/src/bus-proxyd/bus-proxyd.c
> index 4f44825..52498f3 100644
> --- a/src/bus-proxyd/bus-proxyd.c
> +++ b/src/bus-proxyd/bus-proxyd.c
> @@ -733,6 +733,7 @@ static int process_driver(sd_bus *a, sd_bus *b,
> sd_bus_message *m) {
> struct kdbus_cmd_free cmd_free;
> struct kdbus_cmd_name *name;
> _cleanup_strv_free_ char **owners = NULL;
> +_cleanup_bus_error_free_ sd_bus_error error =
> SD_BUS_ERROR_NULL;
> char *arg0;
> int err = 0;
>
> @@ -743,6 +744,14 @@ static int process_driver(sd_bus *a, sd_bus *b,
> sd_bus_message *m) {
> if (!service_name_is_valid(arg0))
> return synthetic_reply_method_errno(m, -EINVAL,
> NULL);
>
> +r = sd_bus_get_owner(a, arg0, 0, NULL);
> +if (r == -ESRCH || r == -ENXIO) {
> +sd_bus_error_setf(&error,
> SD_BUS_ERROR_NAME_HAS_NO_OWNER, "Could not get owners of name '%s': no such
> name.", arg0);
> +return synthetic_reply_method_errno(m, r, &error);
> +}
> +if (r < 0)
> +return synthetic_reply_method_errno(m, r, NULL);
> +
> cmd.flags = KDBUS_NAME_LIST_QUEUED;
> r = ioctl(a->input_fd, KDBUS_CMD_NAME_LIST, &cmd);
> if (r < 0)
>
___
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?
> From: Tom Gundersen > 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). In a situation where one wants to do what a "hook" does, having a separate daemon program that watches for an event and then invokes the hook when the event happens is not a good solution -- it replaces the hook with an entire daemon. I am not experienced, but from what little I know about systemd, the "natural" way would seem to be to write a new unit file with the appropriate dependencies. The event that should call the hook is when some unit finishes starting, and then the new unit would then be started. The new unit's ExecStart command would be the desired invocation of the hook. Does that make sense? If it does, it might be useful to write a beginner's guide on how to construct and insert such a unit into a system. Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Request for clarification of use & implementation of new (systemd >= v214) "network-pre.target"
В Fri, 10 Oct 2014 10:14:47 -0700 PGNd пишет: > systemd v214 introduced the new network-related target, "network-pre.target". > > It cleanly provides a convenient and timley pre-network state trigger for > Before= use in unit ordering. > > As originally conceived, and currently implemented, it's of particular use > for secure, early init of firewalls, > > > http://lists.freedesktop.org/archives/systemd-commits/2014-June/006332.html > commit a4a878d04045b46fa9783664e3643a890b356790 > Author: Lennart Poettering > Date: Wed Jun 11 11:33:02 2014 +0200 > > units: introduce network-pre.target as place to hook in > firewalls > ... > > This target, specifically, started interest/discussion in its correct use for > shorewall > > SW 4.6.4+' systemd service files' Before=/After= dependency on > 'network.target' -- should that be 'network-pre.target' and > 'network-online.target'? > http://comments.gmane.org/gmane.comp.security.shorewall/31879 > > It was pointed out later in that same thread, > > http://permalink.gmane.org/gmane.comp.security.shorewall/31885 > > that not all distros have currently, nor in the immediate future, plans for > up-to-date systemd. > > openSUSE, e.g., has available, &/or will use, v210 for openSUSE versions > 13.1, 13.2 & Factory. > > Reviewing the commit implementing network-pre.target, above, it looks > relatively simple, and was suggested in #systemd to apply the change as a > patch to existing systemd implementation. > > To that end, I raised a request at the distro to do so, > > https://bugzilla.suse.com/show_bug.cgi?id=900505 > Bug 900505 - Base:System/systemd: Bug Request to add upstream's patch > to include v214's new 'network-pre.target' for early/secure pre-network > dependency activation of firewall services > > Atm in that discussion, there's some confusion. If there's any possibilty of > participation from here at/about that bug to help clarify what can/should be > done, it'd be appreciated. > > At the very least, it'd be helpful to get some specific clarification here re: > > (1) Can the aforementioned patch be safely/cleanly applied to a v210 tree? I'd say yes, all that it does is adding couple of dependencies to existing targets. Actually, for openSUSE the only relevant one is network.target Note that commit has some seemingly unrelated changes. > (2) Is systemd-networkd service required to be active to correctly > support/detect network state on system startup, and properly trigger > network-pre.target at the right time? It does not appear to be required for > either network.target, or network-online.target ... No. As explained in accompanying documentation patch, network-pre.target must be pulled in by consumer - if service wants to be started before network it is expected to say so by using Wants=network-pre.target, Before=network-pre.target. Of course, any actual implementation of networking (like systemd-networkd.service) must also be ordered *after* network-pre.target. Above commit alone does not do it for openSUSE specific services (like wicked). > (3) This > > https://wiki.archlinux.org/index.php/systemd-networkd > > but not these > > > http://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html > http://www.freedesktop.org/software/systemd/man/systemd.network.html > > explicitly states that > > " ... > This service (systemd-networkd) can run alongside your usual network > management tool > ... " > > IIUC, that suggests that systemd-networkd can be started in a detect-only > mode, e.g., if no .network or .netdev are specified, leaving network & > interface startup to ohter mechanisms (not theat I see the benefit in doing > so; nonetheless ...). Is that correct? > May be, but this is irrelevant. > Thanks. > > ___ > 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] Request for clarification of use & implementation of new (systemd >= v214) "network-pre.target"
On Fri, Oct 10, 2014 at 7:14 PM, PGNd wrote: > (2) [systemd-networkd] does not appear to be required for either > network.target, or network-online.target ... Correct. The point of network-pre.target is that whatever network manager you are using must be ordered After= it, so that your firewall setup can be ordered Before= it and be set up correctly before any network connectivity is established. This applies the same to NetworkManager, systemd-networkd, or anything else. > (3) This [...] suggests that systemd-networkd can be started in a detect-only > mode, e.g., if no .network or .netdev are specified, leaving network & > interface startup to ohter mechanisms (not theat I see the benefit in doing > so; nonetheless ...). Is that correct? Yes. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Request for clarification of use & implementation of new (systemd >= v214) "network-pre.target"
systemd v214 introduced the new network-related target, "network-pre.target". It cleanly provides a convenient and timley pre-network state trigger for Before= use in unit ordering. As originally conceived, and currently implemented, it's of particular use for secure, early init of firewalls, http://lists.freedesktop.org/archives/systemd-commits/2014-June/006332.html commit a4a878d04045b46fa9783664e3643a890b356790 Author: Lennart Poettering Date: Wed Jun 11 11:33:02 2014 +0200 units: introduce network-pre.target as place to hook in firewalls ... This target, specifically, started interest/discussion in its correct use for shorewall SW 4.6.4+' systemd service files' Before=/After= dependency on 'network.target' -- should that be 'network-pre.target' and 'network-online.target'? http://comments.gmane.org/gmane.comp.security.shorewall/31879 It was pointed out later in that same thread, http://permalink.gmane.org/gmane.comp.security.shorewall/31885 that not all distros have currently, nor in the immediate future, plans for up-to-date systemd. openSUSE, e.g., has available, &/or will use, v210 for openSUSE versions 13.1, 13.2 & Factory. Reviewing the commit implementing network-pre.target, above, it looks relatively simple, and was suggested in #systemd to apply the change as a patch to existing systemd implementation. To that end, I raised a request at the distro to do so, https://bugzilla.suse.com/show_bug.cgi?id=900505 Bug 900505 - Base:System/systemd: Bug Request to add upstream's patch to include v214's new 'network-pre.target' for early/secure pre-network dependency activation of firewall services Atm in that discussion, there's some confusion. If there's any possibilty of participation from here at/about that bug to help clarify what can/should be done, it'd be appreciated. At the very least, it'd be helpful to get some specific clarification here re: (1) Can the aforementioned patch be safely/cleanly applied to a v210 tree? (2) Is systemd-networkd service required to be active to correctly support/detect network state on system startup, and properly trigger network-pre.target at the right time? It does not appear to be required for either network.target, or network-online.target ... (3) This https://wiki.archlinux.org/index.php/systemd-networkd but not these http://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html http://www.freedesktop.org/software/systemd/man/systemd.network.html explicitly states that " ... This service (systemd-networkd) can run alongside your usual network management tool ... " IIUC, that suggests that systemd-networkd can be started in a detect-only mode, e.g., if no .network or .netdev are specified, leaving network & interface startup to ohter mechanisms (not theat I see the benefit in doing so; nonetheless ...). Is that correct? Thanks. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Bug? /dev/disk/by-path symlinks disappear for iSCSI targets
Ping? I will submit a patch that fixes this regression for SCSI, but I suspect other transports will have problems, too, since the by-path links will now be missing. On 10/07/2014, I wrote: > Date: Tue, 07 Oct 2014 21:21:11 +0500 > From: Lee Duncan > To: systemd-devel@lists.freedesktop.org > Subject: [systemd-devel] Bug? /dev/disk/by-path symlinks disappear for > iSCSI targets > Message-ID: <543412f7.1060...@suse.com> > Content-Type: text/plain; charset=utf-8 > > Hi: > > I am debugging a problem where the symlinks in /dev/disk/by-path > disappeared for iSCSI target devices. > > It looks like it's from systemd/udev commit > e98bbfd2074e2b1079b7059341eac25741baf319 > > udev: path_id - suppress ID_PATH for devices with an unknown parent device > type > > I believe the worry was that if you allowed pathnames based on a > parent bus that did not supply unique IDs, then you could end up with > duplicate paths, since this references a bug: > > https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1321816 > > But, looking at the code, this change seems to have assumed SCSI was > not a "supported parent". I am not aware of any cases where SCSI has > given duplicate names to devices > > Before submitting a patch to fix this for SCSI, I wanted to make sure > I understood the intent correctly. > > Thank you for your help. > -- Lee Duncan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Should user mode linux register with machined?
Lennart, Am 10.10.2014 um 18:44 schrieb Lennart Poettering: > It's a bit more complex. While UML, qemu, kvm, currently don't, LXC, > systemd-nspawn and libvirt-lxc all do talk directly to machined. (Note > that LXC and libvirt-lxc are separate codebases, the latter is *not* a > wrapper around the former). > > So, dunno, it really is up to how you intend UML to be used. If UML > shall be nice and useful without libvirt, then it's worth doing the > registration natively, but it's also OK to just leave this to libvirt, > if that's your primary envisioned usecase... What is the benefit of this registration? I boot all day long UML and qemu-kvm VMs without registering them to systemd, so I don't really know what I'm missing. :-) But if there is a nice use case I'll happily add the registration to UML. Thanks, //richard ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Should user mode linux register with machined?
On Wed, 17.09.14 10:24, Richard Weinberger (richard.weinber...@gmail.com) wrote: > On Wed, Sep 17, 2014 at 1:09 AM, Zbigniew Jędrzejewski-Szmek > wrote: > > On Tue, Sep 16, 2014 at 05:31:05PM +0200, Thomas Meyer wrote: > >> Hi, > >> > >> I wrote a small patch for user-mode linux to register with machined by > >> calling "CreateMachine". Is this a good idea to do so? > > Yes, this sounds useful. After all is just another mechanism of > > virtualization, and in this case can be treated similarly to > > containers and vms. > > I still want a sane reason and a usecase for that. > Can someone please educate me? :-) > > Please note that also qemu does not register itself to systemd. > libvirt does. I think going down this path makes also sense for UML > as libvirt has a UML driver too. > qemu and the UML ELF image are the low level building blocks. > Managers like libvirt should register the virtual machines created by > LXC, UML, qemu, etc.. to systemd. It's a bit more complex. While UML, qemu, kvm, currently don't, LXC, systemd-nspawn and libvirt-lxc all do talk directly to machined. (Note that LXC and libvirt-lxc are separate codebases, the latter is *not* a wrapper around the former). So, dunno, it really is up to how you intend UML to be used. If UML shall be nice and useful without libvirt, then it's worth doing the registration natively, but it's also OK to just leave this to libvirt, if that's your primary envisioned usecase... 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] Should user mode linux register with machined?
On Tue, 16.09.14 17:31, Thomas Meyer (tho...@m3y3r.de) wrote: Heya, > I wrote a small patch for user-mode linux to register with machined by > calling "CreateMachine". Is this a good idea to do so? Well, this depends, how UML positions itself. If it's just a tool that other management software should wrap and manage then the CreateMachine() invocation should probably be in that other management software. However, if it is mostly used outside of any such management context, and usually invoked stand-alone, then doing CreateMachine from UML itself certainly makes sense. > I think machined gives you a nice overview over all running UML > instances, also you get the scope unit and the control groups with above > registration to machined. anything else on the plus side? Most of the benefits of doing CreateMachine() you get for containers, not for UML-style virtualization, however, there are some benefits for UML-style stuff too: "ps -e" knows a column "machine" for the UML processes, and so does gnome-system-monitor. I am pretty sure there are a number of other process management tools too this day that make use of this information. Also, after registration with machined we provide local name resolution on the host for IP addresses of all local machines without any further doing. This works for containers only right now (since we simply enter the container's network namespace to gather the IP config), but I want to open this up for real VMs too (by looking into the DHCP pool of networkd for the same information). > PS: I wonder what happens when I write a service unit file that starts > an user mode linux instance and that instance will register with > machined? won't both control groups overlap, i.e. the scope unit and the > service unit? or is this not a problem? THis should work fine, but we have a RegisterMachine() call precisely for this case, but it's a bit, well, ... "underdocumented" right now ;-) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] bus-proxyd: fix compatibility with old dbus-1
'ListQueuedOwners' method should return 'NameHasNoOwner' error
if chosen name is not available on bus.
---
src/bus-proxyd/bus-proxyd.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/src/bus-proxyd/bus-proxyd.c b/src/bus-proxyd/bus-proxyd.c
index 4f44825..52498f3 100644
--- a/src/bus-proxyd/bus-proxyd.c
+++ b/src/bus-proxyd/bus-proxyd.c
@@ -733,6 +733,7 @@ static int process_driver(sd_bus *a, sd_bus *b,
sd_bus_message *m) {
struct kdbus_cmd_free cmd_free;
struct kdbus_cmd_name *name;
_cleanup_strv_free_ char **owners = NULL;
+_cleanup_bus_error_free_ sd_bus_error error =
SD_BUS_ERROR_NULL;
char *arg0;
int err = 0;
@@ -743,6 +744,14 @@ static int process_driver(sd_bus *a, sd_bus *b,
sd_bus_message *m) {
if (!service_name_is_valid(arg0))
return synthetic_reply_method_errno(m, -EINVAL, NULL);
+r = sd_bus_get_owner(a, arg0, 0, NULL);
+if (r == -ESRCH || r == -ENXIO) {
+sd_bus_error_setf(&error,
SD_BUS_ERROR_NAME_HAS_NO_OWNER, "Could not get owners of name '%s': no such
name.", arg0);
+return synthetic_reply_method_errno(m, r, &error);
+}
+if (r < 0)
+return synthetic_reply_method_errno(m, r, NULL);
+
cmd.flags = KDBUS_NAME_LIST_QUEUED;
r = ioctl(a->input_fd, KDBUS_CMD_NAME_LIST, &cmd);
if (r < 0)
--
1.9.3
___
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, Oct 09, 2014 at 07:24:07AM +0200, Marcel Holtmann wrote: > For the wpa_supplicant, we are going to fix that one with a proper daemon > soon. Interesting. Can you shed some light on this? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Honor mount.usr*= on kernel command line
Thanks to everybody for taking the time to review this (and to explain git over email to me!). I know all of you -- and especially Lennart -- are pressed for time with that LibreOffice merge:-) Best Regards, Tobias On Fri, Oct 10, 2014 at 12:57 PM, Lennart Poettering wrote: > On Thu, 09.10.14 21:37, Tobias Hunger (tobias.hun...@gmail.com) wrote: > >> This allows to configure boot loader entries for systems where the >> root and usr filesystems are in different subvolumes (or even on >> different drives). > > Thanks! Applied! > > Lennart > > -- > Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd service for kinit
On Wed, 17.09.14 12:44, Günther J. Niederwimmer (g...@gjn.priv.at) wrote: > Hello, > > I have a problem with kinit (krb5) > before on my old system this works with a cron file > > @reboot root /usr/bin/sleep 120 && /usr/bin/kinit -k host/. > > now with systemd I can't say why, the extra characters don't work > "@reboot" > > Is there a way to configure this with systemd ? cron is an independent project. Please ask the cron project for help. systemd does not read crontabs and is not involved in executing cron's commands. 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 00/25] Compile against the musl libc
On Thu, 18.09.14 21:21, Emil Renner Berthing (syst...@esmil.dk) wrote: > Hi Tom, > > On 18 September 2014 18:29, Tom Gundersen wrote: > > In general, I don't think we should add patches for the sole purpose > > of non-glibc compatibility. You would in most cases be much better > > served by adding the missing functionality to your libc, rather than > > to each of the project requiring the functionality. > > Thank you for looking through these. The problem is that musl is aiming > at making a lean and efficient posix libc, not a glibc clone. So stuff > like parse_printf_format and canonicalize_file_name is not a fix, but > unnecessary bloat. So it seems I'm stuck between a rock and a hard place. Well, "bloat" is a misleading term here. canonicalize_file_name() you can implement via a macro hence costs pretty much nothing. And parse_printf_format() is genuinely useful, that's why we make use of it. It's also something that can only be reasonably implemented at the same place your printf() implementaton is maintained, since it needs to stay compatible with that. In general I think it's a very weird approach to have a non-useful libc and then claim things would be less bloated because every user of a variety of useful GNU APIs is supposed to reimplement everything from scracth, so that we have a multitude of different, crappy implementations in a variety of projects, instead of a single one in the libc. Your overall footprint will be larger. Also, the entire dance around "POSIX is awesome and what we thrive for, and GNU is bad" is just nonsense. It shows that your libc was created for religious reasons, not for practical ones. If you want to create something useful, create something useful, but don't cut off useful functionality people use just because it was introduced by GNU, not by POSIX. The POSIX API alone does not cover many many things anyway. POSIX doesn't know epoll, pivot_root(), memfd, fanotify, inotify and all those other Linux-specific syscalls, that solve real problems. Don't tell me musl refuses to support those too? Or is Linux good, just GNU bad, hence Linux extensions are well supported, just not the ones from GNU? We will not take part in this game. Yes, we tend to gravitate more towards POSIX interfaces, if both a GNU and a POSIX version exists and both are equivalent in their functionality. But also: we will make use of GNU extensions and of Linux extensions if they are useful. And since these ultimately are part of the Linux API, that is the right thing to do. Anyway, regardless what the goal of the patches people sent us are and whether we sympasize with them, we'll always merge the ones that make sense to us. We are not married to GNU, but we are married to the idea that we will rely on good APIs exposed in the generally accepted Linux API which is the one glibc exposes. Hope that makes sense, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] journalctl: Unify boot id lookup into common function get_boots
---
src/journal/journalctl.c | 133 +--
1 file changed, 58 insertions(+), 75 deletions(-)
diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
index 328e40b..550b610 100644
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -824,28 +824,31 @@ static int boot_id_cmp(const void *a, const void *b) {
return _a < _b ? -1 : (_a > _b ? 1 : 0);
}
-static int list_boots(sd_journal *j) {
+static int get_boots(sd_journal *j,
+ boot_id_t **boots,
+ unsigned int *count,
+ boot_id_t *query_ref_boot) {
int r;
const void *data;
-unsigned int count = 0;
-int w, i;
size_t length, allocated = 0;
-boot_id_t *id;
-_cleanup_free_ boot_id_t *all_ids = NULL;
+
+assert(j);
+assert(boots);
+assert(count);
r = sd_journal_query_unique(j, "_BOOT_ID");
if (r < 0)
return r;
-pager_open_if_enabled();
-
SD_JOURNAL_FOREACH_UNIQUE(j, data, length) {
+boot_id_t *id;
+
assert(startswith(data, "_BOOT_ID="));
-if (!GREEDY_REALLOC(all_ids, allocated, count + 1))
+if (!GREEDY_REALLOC(*boots, allocated, *count + 1))
return log_oom();
-id = &all_ids[count];
+id = *boots + *count;
r = sd_id128_from_string(((const char *)data) +
strlen("_BOOT_ID="), &id->id);
if (r < 0)
@@ -869,26 +872,48 @@ static int list_boots(sd_journal *j) {
if (r < 0)
return r;
-r = sd_journal_seek_tail(j);
-if (r < 0)
-return r;
+if (query_ref_boot) {
+id->last = 0;
+if (sd_id128_equal(id->id, query_ref_boot->id))
+*query_ref_boot = *id;
+} else {
+r = sd_journal_seek_tail(j);
+if (r < 0)
+return r;
-r = sd_journal_previous(j);
-if (r < 0)
-return r;
-else if (r == 0)
-goto flush;
+r = sd_journal_previous(j);
+if (r < 0)
+return r;
+else if (r == 0)
+goto flush;
-r = sd_journal_get_realtime_usec(j, &id->last);
-if (r < 0)
-return r;
+r = sd_journal_get_realtime_usec(j, &id->last);
+if (r < 0)
+return r;
+}
-count++;
+(*count)++;
flush:
sd_journal_flush_matches(j);
}
-qsort_safe(all_ids, count, sizeof(boot_id_t), boot_id_cmp);
+qsort_safe(*boots, *count, sizeof(boot_id_t), boot_id_cmp);
+return 0;
+}
+
+static int list_boots(sd_journal *j) {
+int r, w, i;
+unsigned int count;
+boot_id_t *id;
+_cleanup_free_ boot_id_t *all_ids = NULL;
+
+assert(j);
+
+r = get_boots(j, &all_ids, &count, NULL);
+if (r < 0)
+return r;
+
+pager_open_if_enabled();
/* numbers are one less, but we need an extra char for the sign */
w = DECIMAL_STR_WIDTH(count - 1) + 1;
@@ -906,76 +931,34 @@ static int list_boots(sd_journal *j) {
return 0;
}
-static int get_relative_boot_id(sd_journal *j, sd_id128_t *boot_id, int
relative) {
+static int get_boot_id_by_offset(sd_journal *j, sd_id128_t *boot_id, int
offset) {
int r;
-const void *data;
-unsigned int count = 0;
-size_t length, allocated = 0;
-boot_id_t ref_boot_id = {SD_ID128_NULL}, *id;
+unsigned int count;
+boot_id_t ref_boot_id = {}, *id;
_cleanup_free_ boot_id_t *all_ids = NULL;
assert(j);
assert(boot_id);
-r = sd_journal_query_unique(j, "_BOOT_ID");
+ref_boot_id.id = *boot_id;
+r = get_boots(j, &all_ids, &count, &ref_boot_id);
if (r < 0)
return r;
-SD_JOURNAL_FOREACH_UNIQUE(j, data, length) {
-if (length < strlen("_BOOT_ID="))
-continue;
-
-if (!GREEDY_REALLOC(all_ids, allocated, count + 1))
-return log_oom();
-
-id = &all_ids[count];
-
-r = sd_id128_from_string(((const char *)data) +
strlen("_BOOT_ID="), &id->id);
-if (r < 0)
-continue;
-
-r = sd_journal_add_match(j, data, length);
-if (r < 0)
-
Re: [systemd-devel] [RFC 21/25] make sure basename that doesn't alter it's argument
On Thu, 18.09.14 15:24, Emil Renner Berthing (syst...@esmil.dk) wrote:
What's the rationale here? The GNU version of basename() appears a lot
more useful than the POSIX. I am find with switching to the POSIX
version of libc calls if both have more or less equivalent
functionality or they are used very seldom only, but in this case the
GNU logic seems so much more useful and we use the call all the
time.
> ---
> src/core/execute.c | 6 +++---
> src/core/load-fragment.c| 2 +-
> src/core/manager.c | 2 +-
> src/core/unit.c | 4 ++--
> src/delta/delta.c | 14 +++---
> src/journal/journalctl.c| 2 +-
> src/locale/localectl.c | 2 +-
> src/login/logind-inhibit.c | 2 +-
> src/login/logind-seat.c | 2 +-
> src/login/logind-session.c | 2 +-
> src/nspawn/nspawn.c | 2 +-
> src/shared/cgroup-show.c| 4 ++--
> src/shared/conf-files.c | 4 ++--
> src/shared/install.c| 14 +++---
> src/shared/path-util.c | 8
> src/shared/path-util.h | 5 +
> src/shared/util.c | 4 ++--
> src/shared/utmp-wtmp.c | 2 +-
> src/systemctl/systemctl.c | 12 ++--
> src/sysv-generator/sysv-generator.c | 4 ++--
> src/test/test-install.c | 18 +-
> src/test/test-path-util.c | 8
> 22 files changed, 68 insertions(+), 55 deletions(-)
>
> diff --git a/src/core/execute.c b/src/core/execute.c
> index e73eb8e..77724ce 100644
> --- a/src/core/execute.c
> +++ b/src/core/execute.c
> @@ -912,7 +912,7 @@ static void rename_process_from_path(const char *path) {
> /* This resulting string must fit in 10 chars (i.e. the length
> * of "/sbin/init") to look pretty in /bin/ps */
>
> -p = basename(path);
> +p = path_basename(path);
> if (isempty(p)) {
> rename_process("(...)");
> return;
> @@ -1331,13 +1331,13 @@ static int exec_child(ExecCommand *command,
> return err;
> }
>
> -err = setup_output(context, STDOUT_FILENO, socket_fd,
> basename(command->path), params->unit_id, params->apply_tty_stdin);
> +err = setup_output(context, STDOUT_FILENO, socket_fd,
> path_basename(command->path), params->unit_id, params->apply_tty_stdin);
> if (err < 0) {
> *error = EXIT_STDOUT;
> return err;
> }
>
> -err = setup_output(context, STDERR_FILENO, socket_fd,
> basename(command->path), params->unit_id, params->apply_tty_stdin);
> +err = setup_output(context, STDERR_FILENO, socket_fd,
> path_basename(command->path), params->unit_id, params->apply_tty_stdin);
> if (err < 0) {
> *error = EXIT_STDERR;
> return err;
> diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c
> index 0620882..61db112 100644
> --- a/src/core/load-fragment.c
> +++ b/src/core/load-fragment.c
> @@ -3322,7 +3322,7 @@ static int open_follow(char **filename, FILE **_f, Set
> *names, char **_final) {
> /* Add the file name we are currently looking at to
> * the names of this unit, but only if it is a valid
> * unit name. */
> -name = basename(*filename);
> +name = path_basename(*filename);
>
> if (unit_name_is_valid(name, TEMPLATE_VALID)) {
>
> diff --git a/src/core/manager.c b/src/core/manager.c
> index 88d660d..22a9c89 100644
> --- a/src/core/manager.c
> +++ b/src/core/manager.c
> @@ -1217,7 +1217,7 @@ int manager_load_unit_prepare(
> return sd_bus_error_setf(e, SD_BUS_ERROR_INVALID_ARGS, "Path
> %s is not absolute.", path);
>
> if (!name)
> -name = basename(path);
> +name = path_basename(path);
>
> t = unit_name_to_type(name);
>
> diff --git a/src/core/unit.c b/src/core/unit.c
> index def5c36..c14859e 100644
> --- a/src/core/unit.c
> +++ b/src/core/unit.c
> @@ -2170,7 +2170,7 @@ static const char *resolve_template(Unit *u, const char
> *name, const char*path,
> assert(p);
>
> if (!name)
> -name = basename(path);
> +name = path_basename(path);
>
> if (!unit_name_is_template(name)) {
> *p = NULL;
> @@ -2941,7 +2941,7 @@ UnitFileState unit_get_unit_file_state(Unit *u) {
> if (u->unit_file_state < 0 && u->fragment_path)
> u->unit_file_state = unit_file_get_state(
> u->manager->running_as == SYSTEMD_SYSTEM ?
> UNIT_FILE_SYSTEM : UNIT_FILE_USER,
> -NULL, basename(u->fragment_path));
> +NULL, path_basename(u->fragment_path)
Re: [systemd-devel] [RFC 19/25] mount-setup: skip relabelling when SELinux and SMACK not supported
On Thu, 18.09.14 15:24, Emil Renner Berthing (syst...@esmil.dk) wrote:
> This is also the only place where FTW_ACTIONRETVAL is used, so
> this makes systemd compile without SELinux or SMACK support
> when the standard library doesn't support this extension.
I applied this one. It's probably a good idea to avoid building this
bit of code if neither selinux nor SMACK are enabled. I generally
don't like littering code with #ifdefs so much, but for this one I
couldn't think of a better way.
> ---
> src/core/mount-setup.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
> index 23a66d2..8e91217 100644
> --- a/src/core/mount-setup.c
> +++ b/src/core/mount-setup.c
> @@ -351,6 +351,7 @@ int mount_cgroup_controllers(char ***join_controllers) {
> return 0;
> }
>
> +#if defined(HAVE_SELINUX) || defined(HAVE_SMACK)
> static int nftw_cb(
> const char *fpath,
> const struct stat *sb,
> @@ -372,6 +373,7 @@ static int nftw_cb(
>
> return FTW_CONTINUE;
> };
> +#endif
>
> int mount_setup(bool loaded_policy) {
> int r;
> @@ -384,6 +386,7 @@ int mount_setup(bool loaded_policy) {
> return r;
> }
>
> +#if defined(HAVE_SELINUX) || defined(HAVE_SMACK)
> /* Nodes in devtmpfs and /run need to be manually updated for
> * the appropriate labels, after mounting. The other virtual
> * API file systems like /sys and /proc do not need that, they
> @@ -402,6 +405,7 @@ int mount_setup(bool loaded_policy) {
> log_info("Relabelled /dev and /run in %s.",
> format_timespan(timespan, sizeof(timespan),
> after_relabel - before_relabel, 0));
> }
> +#endif
>
> /* Create a few default symlinks, which are normally created
> * by udevd, but some scripts might need them before we start
> --
> 2.1.0
>
> ___
> 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] kdbus: fix buffer overflow in bus_get_owner_kdbus() function
On 10/10/2014 12:29 PM, Lukasz Skalski wrote:
> Commit 710fc9779b7c (kdbus repo) introduced attaching items[]
> instead of name[] in kdbus_cmd_conn_info struct. Commit 581fe6c81
> (systemd repo) caught up with this change, but item size was not
> properly calculated.
Thanks for spotting this!
Applied.
>
> ---
> src/libsystemd/sd-bus/bus-control.c | 11 +--
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
> diff --git a/src/libsystemd/sd-bus/bus-control.c
> b/src/libsystemd/sd-bus/bus-control.c
> index dbd94fc..7b106a3 100644
> --- a/src/libsystemd/sd-bus/bus-control.c
> +++ b/src/libsystemd/sd-bus/bus-control.c
> @@ -398,7 +398,7 @@ static int bus_get_owner_kdbus(
> struct kdbus_cmd_conn_info *cmd;
> struct kdbus_conn_info *conn_info;
> struct kdbus_item *item;
> -size_t size;
> +size_t size, l;
> uint64_t m, id;
> int r;
>
> @@ -410,13 +410,12 @@ static int bus_get_owner_kdbus(
> cmd = alloca0_align(size, 8);
> cmd->id = id;
> } else {
> -size_t item_size = KDBUS_ITEM_HEADER_SIZE + strlen(name) + 1;
> -
> -size = offsetof(struct kdbus_cmd_conn_info, items) +
> item_size;
> +l = strlen(name) + 1;
> +size = offsetof(struct kdbus_cmd_conn_info, items) +
> KDBUS_ITEM_SIZE(l);
> cmd = alloca0_align(size, 8);
> -cmd->items[0].size = item_size;
> +cmd->items[0].size = KDBUS_ITEM_HEADER_SIZE + l;
> cmd->items[0].type = KDBUS_ITEM_NAME;
> -strcpy(cmd->items[0].str, name);
> +memcpy(cmd->items[0].str, name, l);
> }
>
> cmd->size = size;
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] kdbus: fix buffer overflow in bus_get_owner_kdbus() function
Commit 710fc9779b7c (kdbus repo) introduced attaching items[]
instead of name[] in kdbus_cmd_conn_info struct. Commit 581fe6c81
(systemd repo) caught up with this change, but item size was not
properly calculated.
---
src/libsystemd/sd-bus/bus-control.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/src/libsystemd/sd-bus/bus-control.c
b/src/libsystemd/sd-bus/bus-control.c
index dbd94fc..7b106a3 100644
--- a/src/libsystemd/sd-bus/bus-control.c
+++ b/src/libsystemd/sd-bus/bus-control.c
@@ -398,7 +398,7 @@ static int bus_get_owner_kdbus(
struct kdbus_cmd_conn_info *cmd;
struct kdbus_conn_info *conn_info;
struct kdbus_item *item;
-size_t size;
+size_t size, l;
uint64_t m, id;
int r;
@@ -410,13 +410,12 @@ static int bus_get_owner_kdbus(
cmd = alloca0_align(size, 8);
cmd->id = id;
} else {
-size_t item_size = KDBUS_ITEM_HEADER_SIZE + strlen(name) + 1;
-
-size = offsetof(struct kdbus_cmd_conn_info, items) + item_size;
+l = strlen(name) + 1;
+size = offsetof(struct kdbus_cmd_conn_info, items) +
KDBUS_ITEM_SIZE(l);
cmd = alloca0_align(size, 8);
-cmd->items[0].size = item_size;
+cmd->items[0].size = KDBUS_ITEM_HEADER_SIZE + l;
cmd->items[0].type = KDBUS_ITEM_NAME;
-strcpy(cmd->items[0].str, name);
+memcpy(cmd->items[0].str, name, l);
}
cmd->size = size;
--
1.9.3
___
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 Fri, 10.10.14 01:35, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > On Thu, Oct 09, 2014 at 01:41:24AM +0200, Lennart Poettering wrote: > > 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. > Isn't this it: > > commit 96fb8242cc1ef6b0e28f6c86a4f57950095dd7f1 > Author: Lennart Poettering > Date: Thu Aug 21 18:50:42 2014 +0200 > > service: allow services of Type=oneshot that specify no ExecStart= > commands > > This is useful for services that simply want to run something on > shutdown, but not at bootup. They should only set ExecStop= but leave > ExecStart= unset. Oh! Indeed! I am getting old! I start getting forgetful! 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] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)
On Thu, 09.10.14 20:28, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: > > On 10/09/2014 02:26 PM, Lennart Poettering wrote: > >On Thu, 09.10.14 12:14, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: > > > >>On 10/08/2014 11:41 PM, Lennart Poettering wrote: > >>>TODO list to allow services also when they have no ExecStart= but with > >>>an ExecStop=, but this has not been implemented yet. > >>What's the usecase for this behaviour? > >Precisely cases like the one described earlier in this thread: when > >you want to run something only at shutdown, properly ordered against > >other units that are also shut down. > > To me that already works just fine. > > [Unit] > Description=My Shutdown Test > Before=shutdown.target > DefaultDependencies=no > > [Service] > Type=oneshot > ExecStart=/bin/systemd-cat -t "SHUTDOWN" /bin/echo "Systemd shutdown test-2" > > [Install] > WantedBy=shutdown.target It's not that easy. Note that in systemd we have the rule that if two units are ordered against each other, and one is started and one is stopped the stop will always be executed first, the start second, regardless if the actual ordering is After= or Before=. Now, this means unless you want to run your code only after some other service shut down, everything is good. But if you want your code to run before some other unit is shut down, then you cannot express this with a service that is started at shutdown. Thus the recommended way to implement services that are execute right at the appropriate place in the shutdown order is to make it a service that is a NOP at start, and only contains ExecStop=. It's not particularly pretty, but not that bad either. And better than the other options we saw... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Systemd-nspawn: Cannot create tun device in container
On Thu, 09.10.14 23:53, James Lott (ja...@lottspot.com) wrote: > I am using a setup which retains the CAP_NET_ADMIN capability inside the > container and allows openvpn to setup the device. No persistent devices are > involved. Below, I have included a snippet from a shell session which shows > the command used to invoke nspawn and then the openvpn command executed > within > the container which fails. The "devices" cgroup controller is used by nspawn to ensure code running inside the container cannot freely create arbitrary device nodes and then open them. What was missing here is to actually update the policy for it to allow access to /dev/net/tun. I made that change now, please check with the git version for nspawn if everything works now. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] socket-proxyd: Unchecked return value from library
On Fri, 10.10.14 05:57, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> On Thu, Oct 09, 2014 at 07:01:11PM +0530, Susant Sahani wrote:
> > CID 1237543 (#1 of 1): Unchecked return value from library
> > (CHECKED_RETURN)
> > ---
> > src/socket-proxy/socket-proxyd.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/socket-proxy/socket-proxyd.c
> > b/src/socket-proxy/socket-proxyd.c
> > index ff2b24f..3041903 100644
> > --- a/src/socket-proxy/socket-proxyd.c
> > +++ b/src/socket-proxy/socket-proxyd.c
> > @@ -125,7 +125,7 @@ static int connection_create_pipes(Connection *c, int
> > buffer[2], size_t *sz) {
> > return -errno;
> > }
> >
> > -fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
> > +(void) fcntl(buffer[0], F_SETPIPE_SZ, BUFFER_SIZE);
> >
> > r = fcntl(buffer[0], F_GETPIPE_SZ);
> > if (r < 0) {
> For the sake of ML archives...
>
> this was pushed by David.
So, according to the archives David actually did post a message where
he said he merged it:
http://lists.freedesktop.org/archives/systemd-devel/2014-October/023822.html
There appears to be something really wrong with mail delivery on fdo
currently, a couple of messages never got delivered to me, and I
checked with Kay and Daniel and they didn't get them either, thoug
they show up in the archives.
Usually I pinged Tollef about things like this, but I am not entirely
sure who to ping these days...
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] Cannot get Shutdown Script to Run (Libvirt Virtual Machine Shutdown)
On 10/09/2014 11:35 PM, Zbigniew Jędrzejewski-Szmek wrote: On Thu, Oct 09, 2014 at 01:41:24AM +0200, Lennart Poettering wrote: 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. Isn't this it: commit 96fb8242cc1ef6b0e28f6c86a4f57950095dd7f1 Author: Lennart Poettering Date: Thu Aug 21 18:50:42 2014 +0200 service: allow services of Type=oneshot that specify no ExecStart= commands This is useful for services that simply want to run something on shutdown, but not at bootup. They should only set ExecStop= but leave ExecStart= unset. Confused, Zbyszek Yeah this was a weird commit and arguably this should be reverted unless Lennart explain why we need this in the first place. Users should be able to install their units into the shutdown target and use existing ( After/Before ) ordering and an simply "ExecStart" to start unit(s) and have them executed in expected order during the shutdown sequence. If they cannot something bigger is broken and need fixing. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
