Re: [systemd-devel] [PATCH] fstab-generator: respect noauto/nofail when adding sysroot mount
On 08/09/13 at 02:08am, Tom Gundersen wrote: > On Thu, Aug 8, 2013 at 9:18 AM, WANG Chao wrote: > > Currently we don't respect noauto/nofail root mount options (from > > rootflags kernel cmdline). We should map these two flags to the > > corresponding boolean variable noauto and nofail when calling > > add_mount(). > > Thanks for the patch. We need some more work to make this actually > useful, but there is no reason to treat rootflags different from > regular mount options so I have applied the patch. Actually it does useful in kdump when I set rootflags=nofail that I can avoid failure on sysroot.mount, and reach initrd-root-fs.target But for a normal boot, I don't think anyone would use nofail/noauto... > > > Signed-off-by: WANG Chao > > For the future, no need to do s-o-b in systemd. I dropped the line > before applying. Thanks. Any story here? WANG Chao ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] fstab-generator: why nofail=true removes "Before=$post" in .mount
On Thu, Aug 8, 2013 at 7:35 AM, WANG Chao wrote: > In add_mount(), if nofail=true, "Before=$post" won't be added to > xxx.mount: > > [..] > if (post && !noauto && !nofail && !automount) > fprintf(f, > "Before=%s\n", > post); > > why doing this? The way things currently work you can use 'nofail' when you want your boot to be unaffected by a missing device. If we change this as you suggest, then a missing device will lead to a long timeout (which delays boot by a couple of minutes). That's not really wrong (it doesn't contradict the fstab manpage), but would obviously limit the usefulness of 'nofail'. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: respect noauto/nofail when adding sysroot mount
On Thu, Aug 8, 2013 at 9:18 AM, WANG Chao wrote: > Currently we don't respect noauto/nofail root mount options (from > rootflags kernel cmdline). We should map these two flags to the > corresponding boolean variable noauto and nofail when calling > add_mount(). Thanks for the patch. We need some more work to make this actually useful, but there is no reason to treat rootflags different from regular mount options so I have applied the patch. > Signed-off-by: WANG Chao For the future, no need to do s-o-b in systemd. I dropped the line before applying. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC v1] crontab-generator: new generator for crontab(5) support
0001-crontab-generator-new-generator-for-crontab-5-suppor.patch Description: Binary data ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] FUSE mount cannot be started on boot
On Thursday 2013-08-08 18:03, Tom Gundersen wrote: > >/dev/fuse is a static node created unconditionally by udev as part of udevd >startup (and not due to an uevent), so this should be guaranteed. > >Are you certain that a race with mknod is the problem? What output do you >get? It used to be systemd[1]: Mounting /home/www... mount[1893]: fuse: device not found, try 'modprobe fuse' first systemd[1]: home-www.mount mount process exited, code=exited status=1 systemd[1]: Failed to mount /home/www. systemd[1]: Unit home-www.mount entered failed state and because the entry in fstab was not marked as "nofail", things stopped real early at boot (pre ssh). It may be conceivable that I had an older modules.devname where /dev/fuse was in fact not listed, though that seems unlikely to me (module-init-tools did not change, nor did the grand kernel version, meaning that any old initrd must have already had modules.devname with fuse in it). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/3] install: don't allow to enable/disable templates
On Thu, Aug 08, 2013 at 03:19:09PM +0200, Michal Sekletar wrote:
> Calling enable on template units doesn't make sense since it is possible
> to enable instances directly and users are not forced to use Alias=
> trickery anymore.
Hm, I'm having trouble with parsing this commit message. Can you
explicitly say what this patch changes (remembering that git log
is read by people who are not familiar with the codebase and just
care about the changes in semantics)?
Zbyszek
> ---
> src/shared/install.c | 20 ++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/src/shared/install.c b/src/shared/install.c
> index 07e06c4..5cda794 100644
> --- a/src/shared/install.c
> +++ b/src/shared/install.c
> @@ -1470,9 +1470,11 @@ int unit_file_enable(
>
> _cleanup_lookup_paths_free_ LookupPaths paths = {};
> _cleanup_install_context_done_ InstallContext c = {};
> -char **i;
> +InstallInfo *v;
> +char **i, *k;
> _cleanup_free_ char *config_path = NULL;
> int r;
> +Iterator j;
>
> assert(scope >= 0);
> assert(scope < _UNIT_FILE_SCOPE_MAX);
> @@ -1491,6 +1493,12 @@ int unit_file_enable(
> return r;
> }
>
> +HASHMAP_FOREACH_KEY(v, k, c.will_install, j) {
> +r = unit_name_is_valid(k, false);
> +if (!r)
> +return -EINVAL;
> +}
> +
> /* This will return the number of symlink rules that were
> supposed to be created, not the ones actually created. This is
> useful to determine whether the passed files had any
> @@ -1509,10 +1517,12 @@ int unit_file_disable(
>
> _cleanup_lookup_paths_free_ LookupPaths paths = {};
> _cleanup_install_context_done_ InstallContext c = {};
> -char **i;
> +InstallInfo *v;
> +char **i, *k;
> _cleanup_free_ char *config_path = NULL;
> _cleanup_set_free_free_ Set *remove_symlinks_to = NULL;
> int r, q;
> +Iterator j;
>
> assert(scope >= 0);
> assert(scope < _UNIT_FILE_SCOPE_MAX);
> @@ -1531,6 +1541,12 @@ int unit_file_disable(
> return r;
> }
>
> +HASHMAP_FOREACH_KEY(v, k, c.will_install, j) {
> +r = unit_name_is_valid(k, false);
> +if (!r)
> +return -EINVAL;
> +}
> +
> r = install_context_mark_for_removal(&c, &paths,
> &remove_symlinks_to, config_path, root_dir);
>
> q = remove_marked_symlinks(remove_symlinks_to, config_path, changes,
> n_changes, files);
> --
> 1.8.3.1
>
> ___
> 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] [PATCH 2/3] install: don't allow to enable/disable templates
On 8 Aug 2013 17:57, "Thomas Bächler" wrote: > > Am 08.08.2013 15:19, schrieb Michal Sekletar: > > Calling enable on template units doesn't make sense since it is possible > > to enable instances directly and users are not forced to use Alias= > > trickery anymore. > > Actually, it would make sense to do this instead: > http://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg09244.html Yes, we should do this too. But we still need to solve the case when DefaultInstance is not specified. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] FUSE mount cannot be started on boot
On 8 Aug 2013 17:10, "Jan Engelhardt" wrote: > > > On Thursday 2013-08-08 16:26, Tom Gundersen wrote: > >On Thu, Aug 8, 2013 at 2:00 PM, Jan Engelhardt wrote: > >> > >> With systemd 195, an /etc/fstab line like > >> > >> /srv/www /home/www fuse.bindfs auto,group=foo,perms=g+rw 0 0 > >> > >> can fail to start if /dev/fuse does not exist yet. > > > >/dev/fuse should be created by udev (in 195, and by > >systemd-tmpflise-setup-dev in more recent versions), and this happens > >before the mounts from fstab are started. Can you verify that the > >ordering is correct for you with "systemctl show home-www.mount | grep > >After" (and so on until you hopefully find systemd-udevd.service)? > > home-www.mount: > After=local-fs-pre.target systemd-journald.socket -.mount > > local-fs-pre.target: > After=systemd-remount-fs.service md.service lvm.service dmraid.service > systemd-udevd.service > > > Even if systemd-udevd was listed in After=, there is not a guarantee > that udevd has already processed the event and managed to create > /dev/fuse, is there? /dev/fuse is a static node created unconditionally by udev as part of udevd startup (and not due to an uevent), so this should be guaranteed. Are you certain that a race with mknod is the problem? What output do you get? This was all recently refactored, so there is a small chance the problem will go away if you use a more recent version, but my guess is that something else is wrong... Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/3] install: don't allow to enable/disable templates
Am 08.08.2013 15:19, schrieb Michal Sekletar: > Calling enable on template units doesn't make sense since it is possible > to enable instances directly and users are not forced to use Alias= > trickery anymore. Actually, it would make sense to do this instead: http://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg09244.html signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] FUSE mount cannot be started on boot
On Thursday 2013-08-08 16:26, Tom Gundersen wrote: >On Thu, Aug 8, 2013 at 2:00 PM, Jan Engelhardt wrote: >> >> With systemd 195, an /etc/fstab line like >> >> /srv/www /home/www fuse.bindfs auto,group=foo,perms=g+rw 0 0 >> >> can fail to start if /dev/fuse does not exist yet. > >/dev/fuse should be created by udev (in 195, and by >systemd-tmpflise-setup-dev in more recent versions), and this happens >before the mounts from fstab are started. Can you verify that the >ordering is correct for you with "systemctl show home-www.mount | grep >After" (and so on until you hopefully find systemd-udevd.service)? home-www.mount: After=local-fs-pre.target systemd-journald.socket -.mount local-fs-pre.target: After=systemd-remount-fs.service md.service lvm.service dmraid.service systemd-udevd.service Even if systemd-udevd was listed in After=, there is not a guarantee that udevd has already processed the event and managed to create /dev/fuse, is there? >Also, do you have the correct entry for fuse in /lib/module/`uname >-r`/modules.devname ? fuse fuse c10:229 is in there. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] FUSE mount cannot be started on boot
On Thu, Aug 8, 2013 at 2:00 PM, Jan Engelhardt wrote: > > With systemd 195, an /etc/fstab line like > > /srv/www /home/www fuse.bindfs auto,group=foo,perms=g+rw 0 0 > > can fail to start if /dev/fuse does not exist yet. This sounds strange. /dev/fuse should be created by udev (in 195, and by systemd-tmpflise-setup-dev in more recent versions), and this happens before the mounts from fstab are started. Can you verify that the ordering is correct for you with "systemctl show home-www.mount | grep After" (and so on until you hopefully find systemd-udevd.service)? Also, do you have the correct entry for fuse in /lib/module/`uname -r`/modules.devname ? I tried to reproduce this with current git, and it seems to work correctly here. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] systemctl: check for triggering units before calling StopUnit
On Thu, Aug 08, 2013 at 03:57:20PM +0200, Václav Pavlín wrote:
> Michal Sekletar píše v Čt 08. 08. 2013 v 15:19 +0200:
> > Rearranging the code in a way that we always check for triggers
> > before we issue StopUnit D-Bus call will make behavior consistent,
> > thus triggers are always checked.
> >
>
> The patch looks good, but I struggled to get through the commit message
> - it might make more sense if you split it into two sentences:
>
> Rearranging the code in a way that we always check for triggers before
> we issue StopUnit D-Bus call. This will make behavior consistent,
> because triggers are always checked.
>
I agree. Message makes more sense when we'll split it into two
sentences.
Thanks,
Michal
> > https://bugzilla.redhat.com/show_bug.cgi?id=908690
> > ---
> > src/systemctl/systemctl.c | 20 ++--
> > 1 file changed, 10 insertions(+), 10 deletions(-)
> >
> > diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
> > index 8ec1824..ee47841 100644
> > --- a/src/systemctl/systemctl.c
> > +++ b/src/systemctl/systemctl.c
> > @@ -1980,6 +1980,16 @@ static int start_unit(DBusConnection *bus, char
> > **args) {
> > return log_oom();
> > }
> >
> > +/* When stopping units, warn if they can still be triggered by
> > + * another active unit (socket, path, timer) */
> > +if (!arg_quiet && streq(method, "StopUnit")) {
> > +if (one_name)
> > +check_triggering_units(bus, one_name);
> > +else
> > +STRV_FOREACH(name, args+1)
> > +check_triggering_units(bus, *name);
> > +}
> > +
> > if (one_name) {
> > ret = start_unit_one(bus, method, one_name, mode, &error,
> > s);
> > if (ret < 0)
> > @@ -1998,16 +2008,6 @@ static int start_unit(DBusConnection *bus, char
> > **args) {
> > r = wait_for_jobs(bus, s);
> > if (r < 0)
> > return r;
> > -
> > -/* When stopping units, warn if they can still be
> > triggered by
> > - * another active unit (socket, path, timer) */
> > -if (!arg_quiet && streq(method, "StopUnit")) {
> > -if (one_name)
> > -check_triggering_units(bus, one_name);
> > -else
> > -STRV_FOREACH(name, args+1)
> > -check_triggering_units(bus, *name);
> > -}
> > }
> >
> > return ret;
>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] systemctl: check for triggering units before calling StopUnit
Michal Sekletar píše v Čt 08. 08. 2013 v 15:19 +0200:
> Rearranging the code in a way that we always check for triggers
> before we issue StopUnit D-Bus call will make behavior consistent,
> thus triggers are always checked.
>
The patch looks good, but I struggled to get through the commit message
- it might make more sense if you split it into two sentences:
Rearranging the code in a way that we always check for triggers before
we issue StopUnit D-Bus call. This will make behavior consistent,
because triggers are always checked.
> https://bugzilla.redhat.com/show_bug.cgi?id=908690
> ---
> src/systemctl/systemctl.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
>
> diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
> index 8ec1824..ee47841 100644
> --- a/src/systemctl/systemctl.c
> +++ b/src/systemctl/systemctl.c
> @@ -1980,6 +1980,16 @@ static int start_unit(DBusConnection *bus, char
> **args) {
> return log_oom();
> }
>
> +/* When stopping units, warn if they can still be triggered by
> + * another active unit (socket, path, timer) */
> +if (!arg_quiet && streq(method, "StopUnit")) {
> +if (one_name)
> +check_triggering_units(bus, one_name);
> +else
> +STRV_FOREACH(name, args+1)
> +check_triggering_units(bus, *name);
> +}
> +
> if (one_name) {
> ret = start_unit_one(bus, method, one_name, mode, &error, s);
> if (ret < 0)
> @@ -1998,16 +2008,6 @@ static int start_unit(DBusConnection *bus, char
> **args) {
> r = wait_for_jobs(bus, s);
> if (r < 0)
> return r;
> -
> -/* When stopping units, warn if they can still be triggered
> by
> - * another active unit (socket, path, timer) */
> -if (!arg_quiet && streq(method, "StopUnit")) {
> -if (one_name)
> -check_triggering_units(bus, one_name);
> -else
> -STRV_FOREACH(name, args+1)
> -check_triggering_units(bus, *name);
> -}
> }
>
> return ret;
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/3] install: don't allow to enable/disable templates
Hi Michal, On Thu, Aug 8, 2013 at 3:19 PM, Michal Sekletar wrote: > Calling enable on template units doesn't make sense since it is possible > to enable instances directly and users are not forced to use Alias= > trickery anymore. It actually might make sense to still call enable on a template unit with an Alias: Imagine foo@.service with Alias=bar@.service. In this case you want to be able to do "systemctl enable foo@.service", and then "systemctl start bar@baz.service" should start the instance foo@baz.service. An example where this would be useful is for "systemctl enable kmsconvt@.service" to make the kmsconvt template override the autovt template. However, we definitely don't want to allow a template name in WantedBy= or RequiredBy= (this doesn't make any sense as "systemctl start foo@.service" is invalid). Currently we don't really verify what is given in Alias/WantedBy/RequiredBy at all at enable time (only at runtime), but I think we should do this using unit_name_is_valid(name,true) for Alias and unit_name_is_valid(name,false) for the other two. What do you think? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/3] TODO: don't allow to enable/disable template
--- TODO | 5 - 1 file changed, 5 deletions(-) diff --git a/TODO b/TODO index ead699c..884acd6 100644 --- a/TODO +++ b/TODO @@ -2,11 +2,6 @@ Bugfixes: * the running hwdb seems not to pick up updated database files without an explicit: udevadm control --reload -* enabling an instance unit creates pointless link, and - the unit will be started with getty@getty.service: -$ systemctl enable getty@.service -ln -s '/usr/lib/systemd/system/getty@.service' '/etc/systemd/system/getty.target.wants/getty@.service' - * check systemd-tmpfiles for selinux context hookup for mknod(), symlink() and similar * swap units that are activated by one name but shown in the kernel under another are semi-broken -- 1.8.3.1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/3] systemctl: check for triggering units before calling StopUnit
Rearranging the code in a way that we always check for triggers
before we issue StopUnit D-Bus call will make behavior consistent,
thus triggers are always checked.
https://bugzilla.redhat.com/show_bug.cgi?id=908690
---
src/systemctl/systemctl.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 8ec1824..ee47841 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -1980,6 +1980,16 @@ static int start_unit(DBusConnection *bus, char **args) {
return log_oom();
}
+/* When stopping units, warn if they can still be triggered by
+ * another active unit (socket, path, timer) */
+if (!arg_quiet && streq(method, "StopUnit")) {
+if (one_name)
+check_triggering_units(bus, one_name);
+else
+STRV_FOREACH(name, args+1)
+check_triggering_units(bus, *name);
+}
+
if (one_name) {
ret = start_unit_one(bus, method, one_name, mode, &error, s);
if (ret < 0)
@@ -1998,16 +2008,6 @@ static int start_unit(DBusConnection *bus, char **args) {
r = wait_for_jobs(bus, s);
if (r < 0)
return r;
-
-/* When stopping units, warn if they can still be triggered by
- * another active unit (socket, path, timer) */
-if (!arg_quiet && streq(method, "StopUnit")) {
-if (one_name)
-check_triggering_units(bus, one_name);
-else
-STRV_FOREACH(name, args+1)
-check_triggering_units(bus, *name);
-}
}
return ret;
--
1.8.3.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/3] install: don't allow to enable/disable templates
Calling enable on template units doesn't make sense since it is possible
to enable instances directly and users are not forced to use Alias=
trickery anymore.
---
src/shared/install.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/src/shared/install.c b/src/shared/install.c
index 07e06c4..5cda794 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -1470,9 +1470,11 @@ int unit_file_enable(
_cleanup_lookup_paths_free_ LookupPaths paths = {};
_cleanup_install_context_done_ InstallContext c = {};
-char **i;
+InstallInfo *v;
+char **i, *k;
_cleanup_free_ char *config_path = NULL;
int r;
+Iterator j;
assert(scope >= 0);
assert(scope < _UNIT_FILE_SCOPE_MAX);
@@ -1491,6 +1493,12 @@ int unit_file_enable(
return r;
}
+HASHMAP_FOREACH_KEY(v, k, c.will_install, j) {
+r = unit_name_is_valid(k, false);
+if (!r)
+return -EINVAL;
+}
+
/* This will return the number of symlink rules that were
supposed to be created, not the ones actually created. This is
useful to determine whether the passed files had any
@@ -1509,10 +1517,12 @@ int unit_file_disable(
_cleanup_lookup_paths_free_ LookupPaths paths = {};
_cleanup_install_context_done_ InstallContext c = {};
-char **i;
+InstallInfo *v;
+char **i, *k;
_cleanup_free_ char *config_path = NULL;
_cleanup_set_free_free_ Set *remove_symlinks_to = NULL;
int r, q;
+Iterator j;
assert(scope >= 0);
assert(scope < _UNIT_FILE_SCOPE_MAX);
@@ -1531,6 +1541,12 @@ int unit_file_disable(
return r;
}
+HASHMAP_FOREACH_KEY(v, k, c.will_install, j) {
+r = unit_name_is_valid(k, false);
+if (!r)
+return -EINVAL;
+}
+
r = install_context_mark_for_removal(&c, &paths, &remove_symlinks_to,
config_path, root_dir);
q = remove_marked_symlinks(remove_symlinks_to, config_path, changes,
n_changes, files);
--
1.8.3.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] FUSE mount cannot be started on boot
With systemd 195, an /etc/fstab line like
/srv/www /home/www fuse.bindfs auto,group=foo,perms=g+rw 0 0
can fail to start if /dev/fuse does not exist yet. Is this systemctl
could handle for me, or am I left to manually replace it by a
dedicated mount unit that properly depends on {some fuse unit}?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCHv4] tmpfiles, man: Add xattr support to tmpfiles
This patch makes it possible to set extended attributes on files created
by tmpfiles. This can be especially used to set SMACK security labels on
volatile files and directories.
It is done by adding new line of type "t". Such line should contain
attributes in Argument field, using following format:
name=value
All other fields are ignored.
If value contains spaces, then it must be surrounded by quotation marks.
User can also put quotation mark in value by escaping it with backslash.
Example:
D /var/run/cups - - - -
t /var/run/cups - - - - security.SMACK64=printing
---
v4:
* grammar fix in man
* style fix
v3:
* "may be used" instead of "should be used" in manpage
* use strv_isempty() instead of != NULL
* rework item_set_xattrs() with split_pair()
* remove copy_item_contents()
* use hashmap_replace() instead of removed copy_item_contents()
* use strv_extend() instead of strv_append()
* cleanup
---
man/tmpfiles.d.xml | 26 ++-
src/tmpfiles/tmpfiles.c | 203 +---
2 files changed, 213 insertions(+), 16 deletions(-)
diff --git a/man/tmpfiles.d.xml b/man/tmpfiles.d.xml
index 6a2193d..41226c3 100644
--- a/man/tmpfiles.d.xml
+++ b/man/tmpfiles.d.xml
@@ -229,6 +229,21 @@ L/tmp/foobar ----
/dev/null
place of normal path
names.
+
+
+t
+Set extended
+attributes on item. It may be
+used in conjunction with other
+types (only d, D, f, F, L, p, c, b, z
+makes sense). If used as a standalone
+line, then systemd-tmpfiles
+ will try to set extended
+attributes on specified path.
+This can be especially used to set
+SMACK labels.
+
+
@@ -242,7 +257,7 @@ L/tmp/foobar ----
/dev/null
objects. For z, Z lines if omitted or when set
to - the file access mode will not be
modified. This parameter is ignored for x, r,
-R, L lines.
+R, L, t lines.
@@ -254,7 +269,7 @@ L/tmp/foobar ----
/dev/null
omitted or when set to - the default 0 (root)
is used. For z, Z lines when omitted or when set to -
the file ownership will not be modified.
-These parameters are ignored for x, r, R, L
lines.
+These parameters are ignored for x, r, R, L, t
lines.
@@ -307,8 +322,10 @@ L/tmp/foobar ----
/dev/null
minor formatted as integers, separated by :,
e.g. "1:3". For f, F, w may be used to specify
a short string that is written to the file,
-suffixed by a newline. Ignored for all other
+suffixed by a newline. Fot t determines extended
+attributes to be set. Ignored for all other
lines.
+
@@ -320,7 +337,8 @@ L/tmp/foobar ----
/dev/null
screen needs two directories
created at boot with specific modes and ownership.
d /var/run/screens 1777 root root 10d
-d /var/run/uscreens 0755 root root 10d12h
+d /var/run/uscreens 0755 root root 10d12h
+t /var/run/screen - - - - user.name="John Koval"
security.SMACK64=screen
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 5eca82a..a6594b1 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -39,6 +39,9 @@
#include
#include
#include
+#ifdef HAVE_XATTR
+#include
+#endif
#include "log.h"
#include "util.h"
@@ -75,7 +78,10 @@ typedef enum ItemType {
REMOVE_PATH = 'r',
RECURSIVE_REMOVE_PATH = 'R',
RELABEL_PATH = 'z',
-RECURSIVE_RELABEL_PATH = 'Z'
+RECURSIVE_RELABEL_PATH = 'Z',
+
+/* These ones are options/additional operations */
+SET_XATTR = 't'
} ItemType;
typedef struct Item {
@@ -83,6 +89,7 @@ typedef struct Item {
char *path;
char *argument;
+char **xattrs;
uid_t uid;
gid_t gid;
mode_t mode;
@@ -448,6 +455,45 @@ stati
Re: [systemd-devel] Fwd: best way to handle service restarts after hibernate/suspend?
Hi, Yep. I have the exact same sleep@.service and it works. BTW, sleep.target is pulled in by both suspend.target and hibernate.target. There are some use cases that a hook should be only invoked by suspend.target (or hibernate.target). For instance, I have a hook used with the tuxoniceui: [Unit] Description=tuxoniceui hibernate hook Before=hibernate.target StopWhenUnneeded=yes [Service] Type=oneshot RemainAfterExit=yes ExecStartPre=/bin/bash -c "echo `fgconsole` > %t/tuxoniceui" ExecStart=/bin/chvt 63 ExecStop=-/bin/bash -c "chvt `< %t/tuxoniceui`" ExecStopPost=-/bin/rm -rf %t/tuxoniceui [Install] WantedBy=hibernate.target Obviously I don't want it to be called for suspend.target. The problem is, by default, suspend.target/hibernate.target is not a StopWhenUnneeded service. I have to overwrite it in /etc/systemd/system/hibernate.target.d. It's completely OK for me to do this. What I wonder is, what is the reason by they are not StopWhenUnneeded services? Uh, seems overly off-topic... Regards. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: best way to handle service restarts after hibernate/suspend?
Am 08.08.2013 08:12, schrieb 孙冰: > I use this: > > [Unit] > Description=Wicd sleep hook > Before=sleep.target > StopWhenUnneeded=yes > > [Service] > Type=oneshot > RemainAfterExit=yes > ExecStart=-/usr/share/wicd/daemon/suspend.py > ExecStop=-/usr/share/wicd/daemon/autoconnect.py > > [Install] > WantedBy=sleep.target > - Thank you very much for this idea. I think it can be expressed in a more generic way: [Unit] Description=%I sleep hook Before=sleep.target StopWhenUnneeded=yes [Service] Type=oneshot RemainAfterExit=yes ExecStart=-/usr/bin/systemctl stop %I ExecStop=-/usr/bin/systemctl start %I [Install] WantedBy=sleep.target - It would be invoked from sleep-hook@.service. What do you think? signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Have 'session' keyrings per service
Hey guys. I'm trying to figure out details for: http://www.freedesktop.org/wiki/Specifications/login-unlock/ Lennart we talked about this briefly in Brno ... basically the concept is that when systemd does cryptsetup, it'll stash away the password it successfully used in the kernel keyring, and then the PAM stack in GDM will use it to try and log the user in. One thing we should work out is how to avoid having any uid 0 process accessing that password at will. By: 1. Obviously, a kernel keyring timeout. 2. Putting it in a keyring that only certain services have access to. The second is why I'm writing... I'm thinking about the idea of defining a named session keyring per systemd unit (kernel 'session keyrings' have nothing to do with user login sessions, overloaded term, :S ). On its own this makes a lot of sense, since we essentially make a per-cgroup keyring for services, which becomes really useful. Then also have the ability to in a .service file to define additional named keyrings that are searchable for the service. So perhaps cryptsetup would put the password in its own named keyring, and then gdm.service would have: [Service] Keyrings=@cryptsetup Which tells systemd to link the cryptsetup keyring into the gdm (session) keyring. That makes gdm be able to find and use keys in the cryptsetup keyring. I think I've figured out a way to implement the above. But anyone already thought about this? Other use cases? Cheers, Stef ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to delete device units presented in systemd-analyze plot.
On Thu, Aug 8, 2013 at 4:10 AM, Tony Seo wrote: > > I understand what you mean, but I think that I will cut the time for > loading device unit if I keep those from appearing on my plot. No, just hiding them will not change anything. > What do think that loading time for device units doesn't affect to boot > speed at machine? It doesn't, because the units do not *exist*. That's the part you keep misunderstanding. Device units by themselves will not *make* systemd wait for a device. They exist only to *show* that systemd *knows about* that device. If you turn on the computer, and it takes several seconds for a device like /sys/devices/platform/soc-audio/sound/card0 to appear, then it *will* take several seconds for that device to appear, whether a systemd shows it as a .device unit or not. /sys/devices/platform/soc-audio/sound/card0 /sys/devices/platform/tcc-gmac/net/eth0 /sys/devices/platform/tcc-uart.0/tty/ttyTCC0 /sys/devices/platform/dwc_otg.0/gadget/tty/ttyGS0 ...what kind of a device is it, anyway? A raspberryπ? -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] fstab-generator: respect noauto/nofail when adding sysroot mount
Currently we don't respect noauto/nofail root mount options (from
rootflags kernel cmdline). We should map these two flags to the
corresponding boolean variable noauto and nofail when calling
add_mount().
Signed-off-by: WANG Chao
---
Days ago, I sent a patch to add rd.weak_sysroot. It seems you guys don't like
it, even me neither :(
So I come up with this update. It looks more reasonable. With this patch, I can
set rootflags=nofail to bypass sysroot failure, which blocking
initrd-root-fs.target.
Please put your comments. Thanks!
src/fstab-generator/fstab-generator.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index c17299f..87b17cd 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -492,6 +492,7 @@ static int parse_new_root_from_proc_cmdline(void) {
char *w, *state;
int r;
size_t l;
+bool noauto, nofail;
r = read_one_line_file("/proc/cmdline", &line);
if (r < 0) {
@@ -547,6 +548,9 @@ static int parse_new_root_from_proc_cmdline(void) {
}
}
+noauto = !!strstr(opts, "noauto");
+nofail = !!strstr(opts, "nofail");
+
if (!what) {
log_debug("Could not find a root= entry on the kernel
commandline.");
return 0;
@@ -558,7 +562,7 @@ static int parse_new_root_from_proc_cmdline(void) {
}
log_debug("Found entry what=%s where=/sysroot type=%s", what, type);
-r = add_mount(what, "/sysroot", type, opts, 0, false, false, false,
+r = add_mount(what, "/sysroot", type, opts, 0, noauto, nofail, false,
false, NULL, NULL, NULL, SPECIAL_INITRD_ROOT_FS_TARGET,
"/proc/cmdline");
return (r < 0) ? r : 0;
--
1.8.3.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
