Re: [systemd-devel] [feature request] allow instances in file.preset
From Lennart Poettering, Wed 08 Oct 2014 at 23:33:13 (+0200) : On Fri, 03.10.14 19:18, Damien Robert (damien.olivier.rob...@gmail.com) wrote: 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? No, we enumerate the installed unit files, and then look them up in the preset files. Yes, I meant you can't do the otherway around anyway (enumerate lines in preset files and enable/disable them accordingly) because the preset information is given by globs. 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? For preset-all: - I may want to enable an instance different from the default instance. For example wpa_supplicant@.service does not have a default instance. (I could change the file but in this case I might as well write directly a non template service file) - I may want to enable different instances of the same template file. - disable * does not disable instanciated templates (except the ones with a default instance). But as you said, I do not see an easy way to do that the way preset-all works. Damien -- Damien Robert http://www.normalesup.org/~robert/pro ___ 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 Thu, 09.10.14 11:42, Damien Robert (damien.olivier.rob...@gmail.com) wrote: From Lennart Poettering, Wed 08 Oct 2014 at 23:33:13 (+0200) : On Fri, 03.10.14 19:18, Damien Robert (damien.olivier.rob...@gmail.com) wrote: 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? No, we enumerate the installed unit files, and then look them up in the preset files. Yes, I meant you can't do the otherway around anyway (enumerate lines in preset files and enable/disable them accordingly) because the preset information is given by globs. This feels wrong. The preset files are actually globs, not full file names. They are not really suitable as a list of filenames, but only as something to match file names against... 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
From Lennart Poettering, Thu 09 Oct 2014 at 16:44:42 (+0200) : 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? No, we enumerate the installed unit files, and then look them up in the preset files. Yes, I meant you can't do the otherway around anyway (enumerate lines in preset files and enable/disable them accordingly) because the preset information is given by globs. This feels wrong. The preset files are actually globs, not full file names. They are not really suitable as a list of filenames, but only as something to match file names against... Yes, this is exactly what I was saying, sorry for the miscommunication... -- Damien Robert http://www.normalesup.org/~robert/pro ___ 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] [feature request] allow instances in file.preset
From Lennart Poettering, Thu 02 Oct 2014 at 17:42:36 (+0200) : Hence so far the idea was to look for the presets only in the dirs where we look for static data, but not for configuration. We can certainly revisit this though. This makes sense for system services, but for user services it is a bit strange that a user cannot modify its own preset files. I'll be happy to provide a patch, but I must test the behavior of systemd more carefully because user preset files in /etc/systemd/user-preset/*.preset does not seem to work in systemd master [but maybe my testing was too hasty, I'll keep you updated]. Thanks, Damien Robert ___ 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
From Lennart Poettering, Thu 02 Oct 2014 at 17:32:07 (+0200) : Would it be possible for the .preset file to just specify foo@.service and then the code that actually enables it just process the DefaultInstance rule as normal? That should already work, no? Yes it works: in 90-systemd.preset, the line enable getty@.service correctly enables getty@tty1.service -- Damien Robert ___ 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
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 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... Thanks, Damien Robert ___ 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
From Damien Robert, Fri 03 Oct 2014 at 19:18:31 (+0200) : 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 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). Or activate/desactivate. But whatever the name, there is going to be some ugly interactions with enable/disable. (We would want desactivate to match globs too in order to be able to desactivate older instances, but then how do we check which has precedence between enable/disable/activate/desactivate). Maybe it is instead way easier to just directly call systemctl enable. Still, one feature missing is the ability to desactivate all services files (systemctl preset-all leaves the instances alone even with a disable *) in order to go back to a 'pristine' state from which one can call systemctl preset-all and then enable the instances. -- Damien Robert ___ 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 Thu, 25.09.14 19:45, Damien Robert (damien.olivier.robert+gm...@gmail.com) wrote: I really like the new preset directive, and I plan to use preset files to synchronise the services I launch at boot across my computers. However it is a bit cumbersome that preset files do not parse instanced services files. I could play with DefaultInstance in foobar@.service.d/ droplets This wouldn't actually work as [Install] cannot be extended with .d/ drop-ins. Only the other sections can be. and add foobar@.service in the preset file (this works); but this only allow to configure one instance. How precisely would you envision this to work? I mean, so far systemctl preset foo@bar.service will precisely enable foo@bar.service, but you are expecting that systemctl preset foo@.service would somehow result in enablement of foo@bar.service or so? How would we even denote that in the rules files? 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
From Lennart Poettering, Thu 02 Oct 2014 at 16:07:03 (+0200) : How precisely would you envision this to work? I mean, so far systemctl preset foo@bar.service will precisely enable foo@bar.service That's exactly what I want; I have not tried systemctl preset foo@bar.service, but in 'systemctl preset-all' it does not work (it only enables services that exist, not instanciated service). , but you are expecting that systemctl preset foo@.service would somehow result in enablement of foo@bar.service or so? How would we even denote that in the rules files? No, I just want that enable foo@bar.service in a preset rule works with systemctl preset-all. Maybe I missed something and it already works? Thanks, Damien Robert ___ 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 Thu, 02.10.14 16:36, Damien Robert (damien.olivier.rob...@gmail.com) wrote: From Lennart Poettering, Thu 02 Oct 2014 at 16:07:03 (+0200) : How precisely would you envision this to work? I mean, so far systemctl preset foo@bar.service will precisely enable foo@bar.service That's exactly what I want; I have not tried systemctl preset foo@bar.service, but in 'systemctl preset-all' it does not work (it only enables services that exist, not instanciated service). 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? 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
Lennart Poettering wrote on 02/10/14 15:48: On Thu, 02.10.14 16:36, Damien Robert (damien.olivier.rob...@gmail.com) wrote: From Lennart Poettering, Thu 02 Oct 2014 at 16:07:03 (+0200) : How precisely would you envision this to work? I mean, so far systemctl preset foo@bar.service will precisely enable foo@bar.service That's exactly what I want; I have not tried systemctl preset foo@bar.service, but in 'systemctl preset-all' it does not work (it only enables services that exist, not instanciated service). 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? Would it be possible for the .preset file to just specify foo@.service and then the code that actually enables it just process the DefaultInstance rule as normal? As you mentioned earlier, the [Install] section cannot be overridden via drop-ins, but shouldn't systemctl preset-all honour DefaultInstance= directive properly without having to duplicate that info into a .preset file? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [feature request] allow instances in file.preset
On Thu, 02.10.14 16:28, Colin Guthrie (gm...@colin.guthr.ie) wrote: 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? Would it be possible for the .preset file to just specify foo@.service and then the code that actually enables it just process the DefaultInstance rule as normal? That should already work, no? As you mentioned earlier, the [Install] section cannot be overridden via drop-ins, but shouldn't systemctl preset-all honour DefaultInstance= directive properly without having to duplicate that info into a .preset file? Yes, it should. 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 Thu, 25.09.14 20:29, Damien Robert (damien.olivier.robert+gm...@gmail.com) wrote: Damien Robert wrote in message m01rcj$dhh$2...@ger.gmane.org: I really like the new preset directive, and I plan to use preset files to synchronise the services I launch at boot across my computers. Also according to the man file systemd.preset and my test, while user systemd units are looked in user folders: $XDG_CONFIG_HOME/systemd/user/* $HOME/.config/systemd/user/* ... preset files are only looked in system folders: /etc/systemd/user-preset/*.preset ... Is there a reason for that? Well kinda. The idea is that preset files are static data that contain a suggested configuration, but that are not configuration itself. If you apply the presets then you turn them into a configuration, but they themselves are little more than just a suggestion. Hence so far the idea was to look for the presets only in the dirs where we look for static data, but not for configuration. We can certainly revisit this though. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [feature request] allow instances in file.preset
I really like the new preset directive, and I plan to use preset files to synchronise the services I launch at boot across my computers. However it is a bit cumbersome that preset files do not parse instanced services files. I could play with DefaultInstance in foobar@.service.d/ droplets and add foobar@.service in the preset file (this works); but this only allow to configure one instance. Thanks! ___ 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
Damien Robert wrote in message m01rcj$dhh$2...@ger.gmane.org: I really like the new preset directive, and I plan to use preset files to synchronise the services I launch at boot across my computers. Also according to the man file systemd.preset and my test, while user systemd units are looked in user folders: $XDG_CONFIG_HOME/systemd/user/* $HOME/.config/systemd/user/* ... preset files are only looked in system folders: /etc/systemd/user-preset/*.preset ... Is there a reason for that? Thanks, Damien Robert ___ 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 Thu, Sep 25, 2014 at 08:29:46PM +, Damien Robert wrote: Damien Robert wrote in message m01rcj$dhh$2...@ger.gmane.org: I really like the new preset directive, and I plan to use preset files to synchronise the services I launch at boot across my computers. Also according to the man file systemd.preset and my test, while user systemd units are looked in user folders: $XDG_CONFIG_HOME/systemd/user/* $HOME/.config/systemd/user/* ... preset files are only looked in system folders: /etc/systemd/user-preset/*.preset ... Is there a reason for that? This seems to be a mis-design. I'm pretty sure we should allow users to set their own presets, so those directories underneath the home dir should be added. Zbyszek ___ 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 Thu, Sep 25, 2014 at 07:45:23PM +, Damien Robert wrote: I really like the new preset directive, and I plan to use preset files to synchronise the services I launch at boot across my computers. However it is a bit cumbersome that preset files do not parse instanced services files. I could play with DefaultInstance in foobar@.service.d/ droplets and add foobar@.service in the preset file (this works); but this only allow to configure one instance. Sounds like a useful feature. I don't see any reason why we shouldn't allow that. Zbyszek ___ 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
Zbigniew Jędrzejewski-Szmek wrote in message
20140925211702.gv29...@in.waw.pl:
This seems to be a mis-design. I'm pretty sure we should allow users
to set their own presets, so those directories underneath the home
dir should be added.
Ok great! I'll be happy to provide a patch but I have never hacked systemd
before. Would something like that be ok? (not tested, just to see if I am
in the right direction)
Thanks,
Damien Robert
-- 8 -
From 7755e4afc3dc24f50c97c28fd7c00fd576d882cc Mon Sep 17 00:00:00 2001
From: Damien Robert damien.olivier.robert+...@gmail.com
Date: Fri, 26 Sep 2014 00:34:46 +0200
Subject: [PATCH 1/1] preset: read files in
$XDG_CONFIG_HOME/systemd/user-preset/*
This is the only way for a user to modify preset files as the other
directory read
/run/systemd/user-preset/*.preset
/usr/lib/systemd/user-preset/*.preset
are not user owned.
---
man/systemd.preset.xml | 1 +
src/shared/install.c | 24 ++--
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/man/systemd.preset.xml b/man/systemd.preset.xml
index 55cb4de..9d414f4 100644
--- a/man/systemd.preset.xml
+++ b/man/systemd.preset.xml
@@ -49,6 +49,7 @@
parafilename/etc/systemd/system-preset/*.preset/filename/para
parafilename/run/systemd/system-preset/*.preset/filename/para
parafilename/usr/lib/systemd/system-preset/*.preset/filename/para
+
paraliterallayoutfilename$XDG_CONFIG_HOME/systemd/user-preset/*/filename
parafilename/etc/systemd/user-preset/*.preset/filename/para
parafilename/run/systemd/user-preset/*.preset/filename/para
parafilename/usr/lib/systemd/user-preset/*.preset/filename/para
diff --git a/src/shared/install.c b/src/shared/install.c
index 61e572b..7981556 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -1769,6 +1769,7 @@ UnitFileState unit_file_get_state(
int unit_file_query_preset(UnitFileScope scope, const char *root_dir, const
char *name) {
_cleanup_strv_free_ char **files = NULL;
+_cleanup_free_ char *user_preset = NULL;
char **p;
int r;
@@ -1786,12 +1787,23 @@ int unit_file_query_preset(UnitFileScope scope, const
char *root_dir, const char
#endif
NULL);
else if (scope == UNIT_FILE_GLOBAL)
-r = conf_files_list(files, .preset, root_dir,
-/etc/systemd/user-preset,
-/usr/local/lib/systemd/user-preset,
-/usr/lib/systemd/user-preset,
-NULL);
-else
+if (user_config_home(user_preset) = 0) {
+user_preset = strappend(user_preset, -preset);
+if (!user_preset)
+return -ENOMEM;
+r = conf_files_list(files, .preset, root_dir,
+user_preset,
+/etc/systemd/user-preset,
+
/usr/local/lib/systemd/user-preset,
+/usr/lib/systemd/user-preset,
+NULL);
+}
+else
+r = conf_files_list(files, .preset, root_dir,
+/etc/systemd/user-preset,
+
/usr/local/lib/systemd/user-preset,
+/usr/lib/systemd/user-preset,
+NULL);
return 1;
if (r 0)
--
Patched on top of v216-385-g79d80fc (git version 2.1.0)
___
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 Thu, Sep 25, 2014 at 10:44:35PM +, Damien Robert wrote:
Zbigniew Jędrzejewski-Szmek wrote in message
20140925211702.gv29...@in.waw.pl:
This seems to be a mis-design. I'm pretty sure we should allow users
to set their own presets, so those directories underneath the home
dir should be added.
Ok great! I'll be happy to provide a patch but I have never hacked systemd
before. Would something like that be ok? (not tested, just to see if I am
in the right direction)
In general yes. Some specific notes below.
-- 8 -
From 7755e4afc3dc24f50c97c28fd7c00fd576d882cc Mon Sep 17 00:00:00 2001
From: Damien Robert damien.olivier.robert+...@gmail.com
Date: Fri, 26 Sep 2014 00:34:46 +0200
Subject: [PATCH 1/1] preset: read files in
$XDG_CONFIG_HOME/systemd/user-preset/*
This is the only way for a user to modify preset files as the other
directory read
/run/systemd/user-preset/*.preset
/usr/lib/systemd/user-preset/*.preset
are not user owned.
---
man/systemd.preset.xml | 1 +
src/shared/install.c | 24 ++--
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/man/systemd.preset.xml b/man/systemd.preset.xml
index 55cb4de..9d414f4 100644
--- a/man/systemd.preset.xml
+++ b/man/systemd.preset.xml
@@ -49,6 +49,7 @@
parafilename/etc/systemd/system-preset/*.preset/filename/para
parafilename/run/systemd/system-preset/*.preset/filename/para
parafilename/usr/lib/systemd/system-preset/*.preset/filename/para
+
paraliterallayoutfilename$XDG_CONFIG_HOME/systemd/user-preset/*/filename
parafilename/etc/systemd/user-preset/*.preset/filename/para
parafilename/run/systemd/user-preset/*.preset/filename/para
parafilename/usr/lib/systemd/user-preset/*.preset/filename/para
You seem to open an xml element, without closing it.
diff --git a/src/shared/install.c b/src/shared/install.c
index 61e572b..7981556 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -1769,6 +1769,7 @@ UnitFileState unit_file_get_state(
int unit_file_query_preset(UnitFileScope scope, const char *root_dir, const
char *name) {
_cleanup_strv_free_ char **files = NULL;
+_cleanup_free_ char *user_preset = NULL;
You can define this below, where it is used.
char **p;
int r;
@@ -1786,12 +1787,23 @@ int unit_file_query_preset(UnitFileScope scope, const
char *root_dir, const char
#endif
NULL);
else if (scope == UNIT_FILE_GLOBAL)
-r = conf_files_list(files, .preset, root_dir,
-/etc/systemd/user-preset,
-/usr/local/lib/systemd/user-preset,
-/usr/lib/systemd/user-preset,
-NULL);
-else
+if (user_config_home(user_preset) = 0) {
+user_preset = strappend(user_preset, -preset);
+if (!user_preset)
+return -ENOMEM;
+r = conf_files_list(files, .preset, root_dir,
+user_preset,
+/etc/systemd/user-preset,
+
/usr/local/lib/systemd/user-preset,
+/usr/lib/systemd/user-preset,
+NULL);
+}
+else
+r = conf_files_list(files, .preset, root_dir,
+/etc/systemd/user-preset,
+
/usr/local/lib/systemd/user-preset,
+/usr/lib/systemd/user-preset,
+NULL);
Please align all the if's at the same level, not nested.
Zbyszek
___
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
[Resending to the list since I was not posting through gmane but through
gmail this time and my post was rejected because I was not subscribed to
the list. Sorry for the spam]
From Zbigniew Jędrzejewski-Szmek, Fri 26 Sep 2014 at 01:00:11 (+0200) :
+
paraliterallayoutfilename$XDG_CONFIG_HOME/systemd/user-preset/*/filename
You seem to open an xml element, without closing it.
Oups! A hasty copy and paste from systemd.unit
+_cleanup_free_ char *user_preset = NULL;
You can define this below, where it is used.
According to CODING_STYLE it is better to declare all variables at the top
of the function.
-else
+if (user_config_home(user_preset) = 0) {
+user_preset = strappend(user_preset, -preset);
+if (!user_preset)
+return -ENOMEM;
+r = conf_files_list(files, .preset, root_dir,
+user_preset,
+/etc/systemd/user-preset,
+
/usr/local/lib/systemd/user-preset,
+/usr/lib/systemd/user-preset,
+NULL);
+}
+else
+r = conf_files_list(files, .preset, root_dir,
+/etc/systemd/user-preset,
+
/usr/local/lib/systemd/user-preset,
+/usr/lib/systemd/user-preset,
+NULL);
Please align all the if's at the same level, not nested.
In fact they are part of the outer 'else if () {' and i was missing some
brackets. Here is an updated patch, but I really need to test it inside a
container first; I'll send you a real version asap.
Thanks for your comments!
-- 8 ---
From: Damien Robert damien.olivier.robert+...@gmail.com
Date: Fri, 26 Sep 2014 00:34:46 +0200
Subject: [PATCH 1/1] preset: read files in
$XDG_CONFIG_HOME/systemd/user-preset/*
This is the only way for a user to modify preset files as the other
directory read
/run/systemd/user-preset/*.preset
/usr/lib/systemd/user-preset/*.preset
are not user owned.
Signed-off-by: Damien Robert damien.olivier.robert+...@gmail.com
---
man/systemd.preset.xml | 1 +
src/shared/install.c | 26 --
2 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/man/systemd.preset.xml b/man/systemd.preset.xml
index 55cb4de..3a45cbd 100644
--- a/man/systemd.preset.xml
+++ b/man/systemd.preset.xml
@@ -49,6 +49,7 @@
parafilename/etc/systemd/system-preset/*.preset/filename/para
parafilename/run/systemd/system-preset/*.preset/filename/para
parafilename/usr/lib/systemd/system-preset/*.preset/filename/para
+
paraliterallayoutfilename$XDG_CONFIG_HOME/systemd/user-preset/*/filename/literallayout/para
parafilename/etc/systemd/user-preset/*.preset/filename/para
parafilename/run/systemd/user-preset/*.preset/filename/para
parafilename/usr/lib/systemd/user-preset/*.preset/filename/para
diff --git a/src/shared/install.c b/src/shared/install.c
index 61e572b..b666b96 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -1769,6 +1769,7 @@ UnitFileState unit_file_get_state(
int unit_file_query_preset(UnitFileScope scope, const char *root_dir, const
char *name) {
_cleanup_strv_free_ char **files = NULL;
+_cleanup_free_ char *user_preset = NULL;
char **p;
int r;
@@ -1785,12 +1786,25 @@ int unit_file_query_preset(UnitFileScope scope, const
char *root_dir, const char
/lib/systemd/system-preset,
#endif
NULL);
-else if (scope == UNIT_FILE_GLOBAL)
-r = conf_files_list(files, .preset, root_dir,
-/etc/systemd/user-preset,
-/usr/local/lib/systemd/user-preset,
-/usr/lib/systemd/user-preset,
-NULL);
+else if (scope == UNIT_FILE_GLOBAL) {
+if (user_config_home(user_preset) = 0) {
+user_preset = strappend(user_preset, -preset);
+if (!user_preset)
+return -ENOMEM;
+r = conf_files_list(files, .preset, root_dir,
+user_preset,
+/etc/systemd/user-preset,
+
/usr/local/lib/systemd/user-preset,
+
