Re: [systemd-devel] Fwd: best way to handle service restarts after hibernate/suspend?

2013-08-08 Thread 孙冰
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
-

___
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?

2013-08-08 Thread Mathijs Kwik
孙冰 subi.the.dream.wal...@gmail.com writes:

 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
 -

Clever :)

It turns out I always misinterpreted the documentation for
StopWhenUnneeded. I never read past the first sentence and assumed this
option was only going to stop services when it felt like it.

But this is a very nice solution, still stateful (remainafterexit) but
by focusing on the sleep-state instead of the before-sleep and
after-sleep it nicely works around cyclic/conflicting dependencies.

Thanks!

___
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

2013-08-08 Thread WANG Chao
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 chaow...@redhat.com
---

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


Re: [systemd-devel] How to delete device units presented in systemd-analyze plot.

2013-08-08 Thread Mantas Mikulėnas
On Thu, Aug 8, 2013 at 4:10 AM, Tony Seo tonys...@gmail.com 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 graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] Have 'session' keyrings per service

2013-08-08 Thread Stef Walter
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] Fwd: best way to handle service restarts after hibernate/suspend?

2013-08-08 Thread killermoehre
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


Re: [systemd-devel] Fwd: best way to handle service restarts after hibernate/suspend?

2013-08-08 Thread 孙冰
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


[systemd-devel] [PATCHv4] tmpfiles, man: Add xattr support to tmpfiles

2013-08-08 Thread Maciej Wereski
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/programlisting
 place of normal path
 names./para/listitem
 /varlistentry
+
+varlistentry
+termvarnamet/varname/term
+listitemparaSet 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 commandsystemd-tmpfiles
+/command will try to set extended
+attributes on specified path.
+This can be especially used to set
+SMACK labels.
+/para/listitem
+/varlistentry
 /variablelist
 /refsect2
 
@@ -242,7 +257,7 @@ L/tmp/foobar ----   
/dev/null/programlisting
 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./para
+R, L, t lines./para
 /refsect2
 
 refsect2
@@ -254,7 +269,7 @@ L/tmp/foobar ----   
/dev/null/programlisting
 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./para
+These parameters are ignored for x, r, R, L, t 
lines./para
 /refsect2
 
 refsect2
@@ -307,8 +322,10 @@ L/tmp/foobar ----   
/dev/null/programlisting
 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./para
+
 /refsect2
 
 /refsect1
@@ -320,7 +337,8 @@ L/tmp/foobar ----   
/dev/null/programlisting
 paracommandscreen/command needs two directories 
created at boot with specific modes and ownership./para
 
 programlistingd /var/run/screens  1777 root root 10d
-d /var/run/uscreens 0755 root root 10d12h/programlisting
+d /var/run/uscreens 0755 root root 10d12h
+t /var/run/screen - - - - user.name=John Koval 
security.SMACK64=screen/programlisting
 /example
 /refsect1
 
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 glob.h
 #include fnmatch.h
 #include sys/capability.h
+#ifdef HAVE_XATTR
+#include attr/xattr.h
+#endif
 
 #include log.h
 #include util.h
@@ -75,7 +78,10 @@ typedef enum ItemType {
 REMOVE_PATH = 'r',
 RECURSIVE_REMOVE_PATH = 'R',
 RELABEL_PATH = 

[systemd-devel] [PATCH 2/3] install: don't allow to enable/disable templates

2013-08-08 Thread 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.
---
 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] [PATCH 1/3] systemctl: check for triggering units before calling StopUnit

2013-08-08 Thread Michal Sekletar
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 3/3] TODO: don't allow to enable/disable template

2013-08-08 Thread Michal Sekletar
---
 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


Re: [systemd-devel] [PATCH 2/3] install: don't allow to enable/disable templates

2013-08-08 Thread Tom Gundersen
Hi Michal,

On Thu, Aug 8, 2013 at 3:19 PM, Michal Sekletar msekl...@redhat.com 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


Re: [systemd-devel] [PATCH 1/3] systemctl: check for triggering units before calling StopUnit

2013-08-08 Thread Václav Pavlín
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 1/3] systemctl: check for triggering units before calling StopUnit

2013-08-08 Thread Michal Sekletar
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] FUSE mount cannot be started on boot

2013-08-08 Thread Tom Gundersen
On Thu, Aug 8, 2013 at 2:00 PM, Jan Engelhardt jeng...@inai.de 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] FUSE mount cannot be started on boot

2013-08-08 Thread Jan Engelhardt

On Thursday 2013-08-08 16:26, Tom Gundersen wrote:
On Thu, Aug 8, 2013 at 2:00 PM, Jan Engelhardt jeng...@inai.de 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] [PATCH 2/3] install: don't allow to enable/disable templates

2013-08-08 Thread Thomas Bächler
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

2013-08-08 Thread Tom Gundersen
On 8 Aug 2013 17:10, Jan Engelhardt jeng...@inai.de wrote:


 On Thursday 2013-08-08 16:26, Tom Gundersen wrote:
 On Thu, Aug 8, 2013 at 2:00 PM, Jan Engelhardt jeng...@inai.de 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

2013-08-08 Thread Tom Gundersen
On 8 Aug 2013 17:57, Thomas Bächler tho...@archlinux.org 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] [PATCH 2/3] install: don't allow to enable/disable templates

2013-08-08 Thread Zbigniew Jędrzejewski-Szmek
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] fstab-generator: why nofail=true removes Before=$post in .mount

2013-08-08 Thread Tom Gundersen
On Thu, Aug 8, 2013 at 7:35 AM, WANG Chao chaow...@redhat.com 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