Re: [systemd-devel] Can LSBInitScipts specify an dependency on systemd unit?

[Ross Lagerwall]

On Thu, Jun 9, 2016 at 11:00 AM, Jóhann B. Guðmundsson
<johan...@gmail.com> wrote:
> On 06/09/2016 09:02 AM, Ross Lagerwall wrote:
>
>> On Thu, Jun 9, 2016 at 9:55 AM, Bao Nguyen <bao...@gmail.com> wrote:
>> With a new enough systemd, you should be able to add a snippet to extend
>> the initscript like this:
>> $ cat /etc/systemd/system/my_lsb_service.service.d/local.conf
>> [Unit]
>> Requires=systemd_1.service
>> After=systemd_1.service
>
>
> That's just silly and introduces another level of administrator headache.
>
> What he's requesting is something that belongs as a feature request in sysv
> or the likes and never should be supported in systemd in any shape or form.
>

Maybe I wasn't clear enough. What I described already works with systemd and is
what I believe the cleanest and least risky way of adding a single
dependency to an
existing SysV initscript.

Ross
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Can LSBInitScipts specify an dependency on systemd unit?

[Ross Lagerwall]

On Thu, Jun 9, 2016 at 9:55 AM, Bao Nguyen  wrote:
> Hi everyone,
>
> I have a script written by SysVinit, can I declare ordering of this script
> with a systemd unit in "X-Start-Before:" and "X-Start-After:", for ex
>
> X-Start-Before: systemd_1.service
> X-Start-After: systemd_2.service
>
> Can it be declared like that? Can it work as expected if LSB depends on
> systemd service?
>

With a new enough systemd, you should be able to add a snippet to extend
the initscript like this:
$ cat /etc/systemd/system/my_lsb_service.service.d/local.conf
[Unit]
Requires=systemd_1.service
After=systemd_1.service

--
Ross
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] cgroup-util: Don't send SIGCONT after SIGKILL

[Ross Lagerwall]

---
 src/shared/cgroup-util.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/shared/cgroup-util.c b/src/shared/cgroup-util.c
index bc5030e..e595d89 100644
--- a/src/shared/cgroup-util.c
+++ b/src/shared/cgroup-util.c
@@ -195,7 +195,7 @@ int cg_kill(const char *controller, const char *path, int 
sig, bool sigcont, boo
 if (ret = 0  errno != ESRCH)
 ret = -errno;
 } else {
-if (sigcont)
+if (sigcont  sig != SIGKILL)
 kill(pid, SIGCONT);
 
 if (ret == 0)
-- 
2.1.2

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] TimeoutStopSec is ignored (regression)

[Ross Lagerwall]

Hi,

On recent versions of systemd, unit_kill_context doesn't set
wait_for_exit to true which means that service_enter_signal sends
SIGTERM, immediately moves into stop-sigkill and sends SIGKILL, ignoring
TimeoutStopSec and often killing processes without giving them a chance
to cleanup.

Reverting the following change, fixes the problem:

commit 1baccdda2e954214e0c5463d6ed8f06009b33c41
Author: Lennart Poettering lenn...@poettering.net
Date:   Wed Feb 5 02:22:11 2014 +0100

core: don't wait for non-control/non-main processes when killing processes 
on the host either

Since the current kernel cgroup notification logic is easily confused by
existing subgroups, let's do the same thing as in containers before. and
just not wait for non-control and non-main processes.

This should be corrected as soon as we have sane cgroup notifications
from the kernel.

Thanks
-- 
Ross Lagerwall
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] cgroup: Handle error when destroying cgroup

[Ross Lagerwall]

If a cgroup fails to be destroyed (most likely because there are still
processes running as part of a service after the main pid exits), don't
free and remove the cgroup unit from the manager.  This fixes a
regression introduced by the cgroup rework in v205 where systemd would
forget about processes still running after the unit becomes inactive.
(This can happen when the main pid exits and KillMode=process or none).
---

Not sure if this is the correct fix but it seems to fix the issue I reported.
When the issue occurs, this notice is visible in the logs:
Nov 28 22:11:32 centi7 systemd[1]: Failed to destroy cgroup 
/system.slice/tester.service: Device or resource busy

 src/core/cgroup.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/core/cgroup.c b/src/core/cgroup.c
index 70fc925..af04835 100644
--- a/src/core/cgroup.c
+++ b/src/core/cgroup.c
@@ -791,8 +791,10 @@ void unit_destroy_cgroup(Unit *u) {
 return;
 
 r = cg_trim_everywhere(u-manager-cgroup_supported, u-cgroup_path, 
!unit_has_name(u, SPECIAL_ROOT_SLICE));
-if (r  0)
+if (r  0) {
 log_debug_errno(r, Failed to destroy cgroup %s: %m, 
u-cgroup_path);
+return;
+}
 
 hashmap_remove(u-manager-cgroup_unit, u-cgroup_path);
 
-- 
2.1.2

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Processes running after a service has stopped

[Ross Lagerwall]

The handling of a service with KillMode set to something other than cgroup
is a bit confusing (as of systemd 208).

Suppose I have a service which has KillMode set to process and it happens
to leave some children behind.
# systemctl start tester
# systemctl status tester
tester.service - tester service
   Loaded: loaded (/etc/systemd/system/tester.service; static)
   Active: active (running) since Fri 2014-11-28 13:32:40 GMT; 2s ago
 Main PID: 5690 (tester)
   CGroup: /system.slice/tester.service
   ├─5690 /home/ross/tester start
   └─5691 /home/ross/tester start

# systemctl stop tester
# systemctl status tester
tester.service - tester service
   Loaded: loaded (/etc/systemd/system/tester.service; static)
   Active: inactive (dead)

Now even though there is still a process running, systemd doesn't indicate
this.  Furthermore, trying to kill these processes doesn't work because the
service is stopped:
# systemctl kill --kill-who=all tester.service
Failed to issue method call: Unit tester.service is not loaded.

Even more confusing, when the service is started again, the existing process
reappears:
# systemctl start tester
# systemctl status tester
tester.service - tester service
   Loaded: loaded (/etc/systemd/system/tester.service; static)
   Active: active (running) since Fri 2014-11-28 13:36:09 GMT; 7s ago
 Main PID: 5730 (tester)
   CGroup: /system.slice/tester.service
   ├─5691 /home/ross/tester start
   ├─5730 /home/ross/tester start
   └─5731 /home/ross/tester start

Is there a reason for the way this is handled?  Perhaps systemd could show
existing processes for a service regardless of the state the service is in?

Also, perhaps systemd could allow killing these processes even if the service
is stopped?

Regards
--
Ross Lagerwall
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Processes running after a service has stopped

[Ross Lagerwall]

On Fri, Nov 28, 2014 at 07:53:33PM +0100, Lennart Poettering wrote:
 On Fri, 28.11.14 13:42, Ross Lagerwall (rosslagerw...@gmail.com) wrote:
 
  The handling of a service with KillMode set to something other than cgroup
  is a bit confusing (as of systemd 208).
 
 Hmm, could you test this with newer systemd please? 208 is already
 quite old.
 
 Where (in terms of: which cgroup?) does systemd-cgls show the left-over 
 processes?

In it's own cgroup, as would normally be the case:

│ ├─tester.service
│ │ └─24709 /home/ross/Downloads/tester start

 
 We should show the cgroup contents regardless of the state of a
 service actually, nothing should be hidden there. If things are hidden
 just because of the service state then this would be a bug. If you can
 reproduce it with 217 or so that would be great!
 

The same behavior seems to occur with 217 (on Arch):
# systemctl start tester.service
# systemctl status tester.service
● tester.service - Tester service
   Loaded: loaded (/etc/systemd/system/tester.service; static)
   Active: active (running) since Fri 2014-11-28 19:46:21 GMT; 4s ago
 Main PID: 25067 (tester)
   CGroup: /system.slice/tester.service
   ├─25067 /home/ross/Downloads/tester start
   └─25068 /home/ross/Downloads/tester start
# systemctl stop tester
# systemctl status tester.service
● tester.service - Tester service
   Loaded: loaded (/etc/systemd/system/tester.service; static)
   Active: inactive (dead)

# ps aux | grep tester
root 25068  0.0  0.0   404876 ?S19:46   0:00 
/home/ross/Downloads/tester start

# systemctl start tester.service
# systemctl status tester.service
● tester.service - Tester service
   Loaded: loaded (/etc/systemd/system/tester.service; static)
   Active: active (running) since Fri 2014-11-28 19:50:58 GMT; 2s ago
 Main PID: 25148 (tester)
   CGroup: /system.slice/tester.service
   ├─25068 /home/ross/Downloads/tester start -- the left over process!
   ├─25148 /home/ross/Downloads/tester start
   └─25149 /home/ross/Downloads/tester start

With 217, running systemctl kill --kill-who=all -s KILL tester.service
doesn't fail, but it doesn't seem to do anything either.

Thanks,
-- 
Ross Lagerwall
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] install: make reenable work with templated units

[Ross Lagerwall]

On Sat, Jul 13, 2013 at 04:12:33PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
 On Mon, Jun 17, 2013 at 07:11:50PM +0100, Ross Lagerwall wrote:
  Before, systemctl reenable getty@tty1.service would fail with:
  Failed to issue method call: File exists
  To fix this, reimplement reenable explicitly as a disable followed by
  an enable.
  This is shorter and is how the man page documents its behavior.
  ---
   src/shared/install.c |   38 +-
   1 file changed, 5 insertions(+), 33 deletions(-)
 Hm, I don't get this error with reenable, but your patch indeed 
 simplifies things, so I don't see a reason not to apply it: applied now.


As far as I can recall, it would fail if
/etc/systemd/system/getty.target.wants/getty@tty1.service is set up as a
symlink to /usr/lib/systemd/system/getty@.service and then systemctl
reenable getty@tty1.service is run.  I can't exactly remember but I
think it would fail because reenable would try to delete the
untemplated unit getty@.service (which would not exist) but then try
to create the templated unit getty@tty1.service which would still
exist hence the File exists error.  Thanks for applying the patch
anyway.

-- 
Ross Lagerwall
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] rules: only run systemd-sysctl when a network device is added

[Ross Lagerwall]

On Mon, Jun 17, 2013 at 12:09:53AM +0200, Michał Bartoszkiewicz wrote:
 On Sun, Jun 16, 2013 at 11:58 PM, Ross Lagerwall
 rosslagerw...@gmail.com wrote:
  OK, thanks.  But my testing shows otherwise: I created a .conf file with:
  net.ipv4.conf.enp1s0.forwarding=1
  (where eth0 is the old name, enp1s0 is the new, predictable name)
  It *correctly* sets /proc/sys/net/ipv4/conf/enp1s0/forwarding=1 after
  a reboot with the patch applied.
 
 This works because systemd-sysctl runs from 99-systemd.rules, so the
 name has already been changed by earlier rules.
 

Yeah, that was what I understood to be happening but I wasn't sure if
there is another case where something can go wrong.

Thanks
-- 
Ross Lagerwall
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] install: make reenable work with templated units

[Ross Lagerwall]

Before, systemctl reenable getty@tty1.service would fail with:
Failed to issue method call: File exists
To fix this, reimplement reenable explicitly as a disable followed by
an enable.
This is shorter and is how the man page documents its behavior.
---
 src/shared/install.c |   38 +-
 1 file changed, 5 insertions(+), 33 deletions(-)

diff --git a/src/shared/install.c b/src/shared/install.c
index d2dd276..1bda79a 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -1533,43 +1533,15 @@ int unit_file_reenable(
 bool force,
 UnitFileChange **changes,
 unsigned *n_changes) {
+int r;
 
-_cleanup_lookup_paths_free_ LookupPaths paths = {};
-_cleanup_install_context_done_ InstallContext c = {};
-char **i;
-_cleanup_free_ char *config_path = NULL;
-_cleanup_set_free_free_ Set *remove_symlinks_to = NULL;
-int r, q;
-
-assert(scope = 0);
-assert(scope  _UNIT_FILE_SCOPE_MAX);
-
-r = lookup_paths_init_from_scope(paths, scope);
-if (r  0)
-return r;
-
-r = get_config_path(scope, runtime, root_dir, config_path);
+r = unit_file_disable(scope, runtime, root_dir, files, changes,
+  n_changes);
 if (r  0)
 return r;
 
-STRV_FOREACH(i, files) {
-r = mark_symlink_for_removal(remove_symlinks_to, *i);
-if (r  0)
-return r;
-
-r = install_info_add_auto(c, *i);
-if (r  0)
-return r;
-}
-
-r = remove_marked_symlinks(remove_symlinks_to, config_path, changes, 
n_changes, files);
-
-/* Returns number of symlinks that where supposed to be installed. */
-q = install_context_apply(c, paths, config_path, root_dir, force, 
changes, n_changes);
-if (r == 0)
-r = q;
-
-return r;
+return unit_file_enable(scope, runtime, root_dir, files, force,
+changes, n_changes);
 }
 
 int unit_file_set_default(
-- 
1.7.10.4

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] rules: only run systemd-sysctl when a network device is added

[Ross Lagerwall]

On Sun, Jun 16, 2013 at 07:42:03PM +0200, Kay Sievers wrote:
  Yes.  Currently, systemd-sysctl is run twice when a network device is
  added, *both* times with the new name as the prefix, like:
  systemd-sysctl --prefix=/proc/sys/net/ipv4/conf/enp0s1f3 ... (with the new 
  name)
 
  Once is caused by the add action, the other is caused by the move
  (rename) action.
 
  The patch causes it to only run the systemd-sysctl command once.
 
  Unless I'm misunderstanding what is happening?
 
 The problem Zbigniew describes is that if one adds config options with
 predictable network names used, and we do not apply the stuff at
 move, we will never apply them.
 

OK, thanks.  But my testing shows otherwise: I created a .conf file with:
net.ipv4.conf.enp1s0.forwarding=1
(where eth0 is the old name, enp1s0 is the new, predictable name)
It *correctly* sets /proc/sys/net/ipv4/conf/enp1s0/forwarding=1 after
a reboot with the patch applied.

I'm still not clear about in which situations it could fail?
-- 
Ross Lagerwall
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] rules: only run systemd-sysctl when a network device is added

[Ross Lagerwall]

On Fri, Jun 14, 2013 at 02:44:23PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
 On Thu, Jun 13, 2013 at 10:45:12AM +0100, Ross Lagerwall wrote:
  Otherwise, when a network device is renamed, systemd-sysctl is run twice
  with the same network device name: once for ACTION=add and once for
  ACTION=move.
 
 Hm, but if I have some sysctl for the network device,
 /proc/sys/net/ipv4/conf/enp0s1f3/log_martians=11 or something, aren't
 I going to have it under the *new* name, not the old name?

Yes.  Currently, systemd-sysctl is run twice when a network device is
added, *both* times with the new name as the prefix, like:
systemd-sysctl --prefix=/proc/sys/net/ipv4/conf/enp0s1f3 ... (with the new name)

Once is caused by the add action, the other is caused by the move
(rename) action.

The patch causes it to only run the systemd-sysctl command once.

Unless I'm misunderstanding what is happening?

Regards
-- 
Ross Lagerwall
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] mount: Don't add conflicts with umount.target for certain mounts

[Ross Lagerwall]

At startup, mount_enumerate is called at manager startup.
This creates a unit for each mount point in /proc/self/mountinfo.  If no
unit for the mount point has been loaded yet (which is quite possible
since mount_enumerate is called early), a unit is created and set to
conflict with umount.target.  However, this should not happen for /,
/usr and any mount point marked with x-initrd.mount.

This caused systemd to incorrectly unmount / on shutdown.
---
 src/core/mount.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/core/mount.c b/src/core/mount.c
index 10073b5..377cf44 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -1538,9 +1538,12 @@ static int mount_add_one(
 if (r  0)
 goto fail;
 
-r = unit_add_dependency_by_name(u, UNIT_CONFLICTS, 
SPECIAL_UMOUNT_TARGET, NULL, true);
-if (r  0)
-goto fail;
+if (!path_equal(where, /)  !path_equal(where, /usr) 
+!mount_test_option(options, x-initrd.mount)) {
+r = unit_add_dependency_by_name(u, UNIT_CONFLICTS, 
SPECIAL_UMOUNT_TARGET, NULL, true);
+if (r  0)
+goto fail;
+}
 
 unit_add_to_load_queue(u);
 } else {
-- 
1.8.3.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] rules: only run systemd-sysctl when a network device is added

[Ross Lagerwall]

Otherwise, when a network device is renamed, systemd-sysctl is run twice
with the same network device name: once for ACTION=add and once for
ACTION=move.
---
 rules/99-systemd.rules.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rules/99-systemd.rules.in b/rules/99-systemd.rules.in
index d17bdd9..e9b2da7 100644
--- a/rules/99-systemd.rules.in
+++ b/rules/99-systemd.rules.in
@@ -49,7 +49,7 @@ SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, 
ENV{ID_USB_INTERFACES}==*:0701??:
 
 # Apply sysctl variables to network devices (and only to those) as they appear.
 
-SUBSYSTEM==net, KERNEL!=lo, RUN+=@rootlibexecdir@/systemd-sysctl 
--prefix=/proc/sys/net/ipv4/conf/$name --prefix=/proc/sys/net/ipv4/neigh/$name 
--prefix=/proc/sys/net/ipv6/conf/$name --prefix=/proc/sys/net/ipv6/neigh/$name
+ACTION==add, SUBSYSTEM==net, KERNEL!=lo, 
RUN+=@rootlibexecdir@/systemd-sysctl --prefix=/proc/sys/net/ipv4/conf/$name 
--prefix=/proc/sys/net/ipv4/neigh/$name --prefix=/proc/sys/net/ipv6/conf/$name 
--prefix=/proc/sys/net/ipv6/neigh/$name
 
 # Asynchronously mount file systems implemented by these modules as
 # soon as they are loaded.
-- 
1.8.3.1

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-shutdown static linking (was: Please proof-read: ...)

[Ross Lagerwall]

On Mon, Jun 10, 2013 at 08:30:40PM +0200, Lennart Poettering wrote:
 Hmm, this is certainly weird. normally -.mount should not have any such
 conflicts. I really wonder where you got those from... What is the
 contents of /run/systemd/generator/-.mount for you?
 

AFAICT, mount_load_proc_self_mountinfo is called early in the boot
process and it calls mount_add_one for each filesystem in
/proc/self/mounts, including /.
If a unit does not exist already, a new unit is created and
the following lines are called (in mount_add_one):

r = unit_add_dependency_by_name(u, UNIT_BEFORE, SPECIAL_LOCAL_FS_TARGET, NULL, 
true);
if (r  0)
goto fail;

r = unit_add_dependency_by_name(u, UNIT_CONFLICTS, SPECIAL_UMOUNT_TARGET, NULL, 
true);
if (r  0)
goto fail;

While it would be easy to make the conflicts line above conditional on
the mount point not being /, I'm not sure how this interacts with
mount_load which fills in a whole bunch of stuff and
mount_add_default_dependencies which adds a conflict with umount.target
so long as the mount point is not /.

Regards
-- 
Ross Lagerwall
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-shutdown static linking

[Ross Lagerwall]

On Tue, Jun 11, 2013 at 10:59:42AM +0200, Thomas Bächler wrote:
 Am 11.06.2013 10:34, schrieb Colin Guthrie:
  Without reading the code etc., I'm running systemd with that commit
  (v204) and I don't get any conflicts for my -.mount unit...
  
  So it seems that code is not run for me for whatever reason.
  
  After a very quick glance at the code, it could just be that the unit
  already exists as it's created earlier and thus this bit of the code for
  -.mount is simply not run?
 
 I think this code is only called when there is no -.mount unit, which
 results from a missing entry for / in fstab. It is entirely possible
 that Ross didn't add / to his fstab by accident or on purpose.
 

But I do have / in my fstab, it's shown in:
http://lists.freedesktop.org/archives/systemd-devel/2013-June/011297.html

Here is part of systemctl dump:
- Unit -.mount:
Description: /
Instance: n/a
Unit Load State: loaded
Unit Active State: active
Inactive Exit Timestamp: Tue 2013-06-11 08:02:21 BST
Active Enter Timestamp: Tue 2013-06-11 08:02:21 BST
Active Exit Timestamp: n/a
Inactive Enter Timestamp: n/a
GC Check Good: yes
Need Daemon Reload: no
Name: -.mount
Fragment Path: /run/systemd/generator/-.mount
Source Path: /etc/fstab
RequiredBy: local-fs.target
...
Conflicts: umount.target
Before: local-fs.target
...
StopWhenUnneeded: no
RefuseManualStart: yes
RefuseManualStop: yes
DefaultDependencies: no
OnFailureIsolate: no
IgnoreOnIsolate: yes
IgnoreOnSnapshot: no
ControlGroup: cpu:/system/-.mount
ControlGroup: name=systemd:/system/-.mount
Mount State: mounted
Result: success
Where: /
What: /dev/sda2
File System Type: ext4
Options: rw,relatime,rw,data=ordered
From /proc/self/mountinfo: yes
From fragment: yes
DirectoryMode: 0755
UMask: 0022
WorkingDirectory: /
RootDirectory: /
NonBlocking: no
...

It has Source Path as fstab and From /proc/self/mountinfo as yes.

Regards
-- 
Ross Lagerwall
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-shutdown static linking (was: Please proof-read: ...)

[Ross Lagerwall]

On Mon, Jun 10, 2013 at 12:33:01PM +0200, Lennart Poettering wrote:
 This is really weird... (Though unrelated to systemd-shutdown, as this
 is generated before we execute it, replacing PID 1).
 
 -.mount is the mount unit is something we do not try to unmount at
 shutdown from normal systemd, as that's impossible to do at that
 point. The other file systems have a Conflicts=umount.target to get them
 unmounted at shutdown, but -.mount explicitly doesn.t 
 
 Ross, how exactly did you shutdown to get this? What does systemctl
 show -- -.mount show you? Does it any Conflicts= line?
 

As root: halt

I have attached the output of systemctl show -- -.mount and /etc/fstab
and /proc/cmdline.

I see that Conflicts=umount.target is set, though I have no idea why.

I haven't changed too much in the setup, at least not related to
mounting.

Regards
-- 
Ross Lagerwall
Id=-.mount
Names=-.mount
RequiredBy=local-fs.target proc-sys-fs-binfmt_misc.mount 
sys-kernel-config.mount dev-mqueue.mount sys-fs-fuse-connections.mount 
dev-hugepages.mount sys-kernel-debug.mount tmp.mount systemd-shutdownd.socket 
systemd-initctl.socket lvmetad.socket dmeventd.socket 
systemd-udevd-control.socket dbus.socket syslog.socket systemd-journald.socket 
systemd-ask-password-wall.path systemd-ask-password-console.path 
systemd-random-seed-load.service systemd-update-utmp.service 
systemd-random-seed-save.service proc-sys-fs-binfmt_misc.automount
Conflicts=umount.target
Before=local-fs.target proc-sys-fs-binfmt_misc.mount sys-kernel-config.mount 
dev-mqueue.mount sys-fs-fuse-connections.mount dev-hugepages.mount 
sys-kernel-debug.mount tmp.mount systemd-shutdownd.socket 
systemd-initctl.socket lvmetad.socket dmeventd.socket 
systemd-udevd-control.socket dbus.socket syslog.socket systemd-journald.socket 
systemd-ask-password-wall.path systemd-ask-password-console.path 
systemd-random-seed-load.service systemd-update-utmp.service 
systemd-random-seed-save.service proc-sys-fs-binfmt_misc.automount
Description=/
LoadState=loaded
ActiveState=active
SubState=mounted
FragmentPath=/run/systemd/generator/-.mount
SourcePath=/etc/fstab
InactiveExitTimestamp=Mon 2013-06-10 13:19:52 BST
InactiveExitTimestampMonotonic=49
ActiveEnterTimestamp=Mon 2013-06-10 13:19:52 BST
ActiveEnterTimestampMonotonic=49
ActiveExitTimestampMonotonic=0
InactiveEnterTimestampMonotonic=0
CanStart=no
CanStop=no
CanReload=yes
CanIsolate=no
StopWhenUnneeded=no
RefuseManualStart=yes
RefuseManualStop=yes
AllowIsolate=no
DefaultDependencies=no
OnFailureIsolate=no
IgnoreOnIsolate=yes
IgnoreOnSnapshot=no
NeedDaemonReload=no
JobTimeoutUSec=0
ConditionTimestampMonotonic=0
ConditionResult=no
Where=/
What=/dev/sda1
Options=rw,relatime,rw,data=ordered
Type=ext4
TimeoutUSec=1min 30s
ControlPID=0
DirectoryMode=0755
Result=success
UMask=0022
LimitCPU=18446744073709551615
LimitFSIZE=18446744073709551615
LimitDATA=18446744073709551615
LimitSTACK=18446744073709551615
LimitCORE=18446744073709551615
LimitRSS=18446744073709551615
LimitNOFILE=4096
LimitAS=18446744073709551615
LimitNPROC=16008
LimitMEMLOCK=65536
LimitLOCKS=18446744073709551615
LimitSIGPENDING=16008
LimitMSGQUEUE=819200
LimitNICE=0
LimitRTPRIO=0
LimitRTTIME=18446744073709551615
OOMScoreAdjust=0
Nice=0
IOScheduling=0
CPUSchedulingPolicy=0
CPUSchedulingPriority=0
TimerSlackNSec=5
CPUSchedulingResetOnFork=no
NonBlocking=no
StandardInput=null
StandardOutput=inherit
StandardError=inherit
TTYReset=no
TTYVHangup=no
TTYVTDisallocate=no
SyslogPriority=30
SyslogLevelPrefix=yes
SecureBits=0
CapabilityBoundingSet=18446744073709551615
MountFlags=0
PrivateTmp=no
PrivateNetwork=no
SameProcessGroup=yes
ControlGroupModify=no
ControlGroupPersistent=no
IgnoreSIGPIPE=yes
NoNewPrivileges=no
KillMode=control-group
KillSignal=15
SendSIGKILL=yes
DefaultControlGroup=name=systemd:/system/-.mount
ControlGroups=cpu:/system/-.mount name=systemd:/system/-.mount
# 
# /etc/fstab: static file system information
#
# file system dir   type  options   dump  pass
# /dev/sda1
UUID=c1213d5b-d7c8-468d-a7b1-f8618ed59c4a   /   ext4
rw,relatime,data=ordered0 1

BOOT_IMAGE=/boot/vmlinuz-linux root=UUID=c1213d5b-d7c8-468d-a7b1-f8618ed59c4a ro
/etc/systemd/system:
total 20
-rw-r--r-- 1 root root  429 Jun  6 16:43 alsa-restore.service
drwxr-xr-x 2 root root 4096 May  6 08:08 getty.target.wants
-rw-r--r-- 1 root root 1640 May  7 08:33 getty@tty1.service
drwxr-xr-x 2 root root 4096 Jun  9 17:00 multi-user.target.wants
-rw-r--r-- 1 root root  800 Jun  6 16:58 systemd-udevd.service

/etc/systemd/system/getty.target.wants:
total 0
lrwxrwxrwx 1 root root 38 May  6 08:08 getty@tty1.service - 
/usr/lib/systemd/system/getty@.service

/etc/systemd/system/multi-user.target.wants:
total 0
lrwxrwxrwx 1 root root 39 May  6 08:25 dhcpcd@enp0s3.service - 
/usr/lib/systemd/system/dhcpcd@.service
lrwxrwxrwx 1 root root 40 May 30 13:55 remote-fs.target - 
/usr/lib/systemd/system/remote-fs.target

Re: [systemd-devel] systemd-shutdown static linking (was: Please proof-read: ...)

[Ross Lagerwall]

On Mon, Jun 10, 2013 at 08:30:40PM +0200, Lennart Poettering wrote:
  As root: halt
  
  I have attached the output of systemctl show -- -.mount and /etc/fstab
  and /proc/cmdline.
  
  I see that Conflicts=umount.target is set, though I have no idea why.
  
  I haven't changed too much in the setup, at least not related to
  mounting.
 
 Hmm, this is certainly weird. normally -.mount should not have any such
 conflicts. I really wonder where you got those from... What is the
 contents of /run/systemd/generator/-.mount for you?
 

# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
DefaultDependencies=no
Before=local-fs.target

[Mount]
What=/dev/disk/by-uuid/c1213d5b-d7c8-468d-a7b1-f8618ed59c4a
Where=/
Type=ext4
FsckPassNo=1
Options=rw,relatime,data=ordered

A new freshly installed Arch VM also has Conflicts=umount.target set for
-.mount (as does my desktop).
That's after not changing the config at all.

Hope that helps,
-- 
Ross Lagerwall
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-shutdown static linking (was: Please proof-read: ...)

[Ross Lagerwall]

On Sat, Jun 08, 2013 at 05:06:50PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
 Maybe mention that systemd-shutdown is statically linked (I know it
 can be inferred from the text, but being explicit might be better).

At least on Arch, it is still statically linked to libc and udev:
$ ldd /usr/lib/systemd/systemd-shutdown
linux-vdso.so.1 (0x7fff80bff000)
libudev.so.1 = /usr/lib/libudev.so.1 (0x7f9a43582000)
librt.so.1 = /usr/lib/librt.so.1 (0x7f9a4337a000)
libc.so.6 = /usr/lib/libc.so.6 (0x7f9a42fcd000)
/lib64/ld-linux-x86-64.so.2 (0x7f9a43794000)
libdl.so.2 = /usr/lib/libdl.so.2 (0x7f9a42dc9000)
libpthread.so.0 = /usr/lib/libpthread.so.0 (0x7f9a42bad000)

And if I run pacman -S glibc and then shutdown:
-.mount mount process exited, code=exited status=32
-.mount changed unmounting - mounted
Job -.mount/stop finished, result=failed
Failed unmounting /.

Should it be completely statically linked?

-- 
Ross Lagerwall
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-cgroups-agent failed to get dbus connection

[Ross Lagerwall]

On Tue, May 07, 2013 at 09:31:58AM +0100, Ross Lagerwall wrote:
 I have noticed sometimes during shutdown, the following message appears
 on screen twice:
 systemd-cgroups-agent failed to get dbus connection: failed to connect
 to socket /org/freedesktop/systemd/private connection refused
 
 The following may be relevant from the logs:
 May 07 09:13:05 hobo login[223]: pam_unix(login:session): session closed
 for user ross
 May 07 09:13:05 hobo login[223]: pam_systemd(login:session): Failed to
 connect to system bus: Did not reply. Possible causes include: the
 remote application did not send a reply, the message bus security policy
 blocked the reply, the reply timeout expired, or the network connection
 was broken.
 May 07 09:13:05 hobo systemd[1]: Stopped Getty on tty1.

I should add that I'm using systemd 204 on Arch Linux without any major
customization to unit files.

Is there a way to debug this further?
-- 
Ross Lagerwall
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd-cgroups-agent failed to get dbus connection

[Ross Lagerwall]

Hi,

I have noticed sometimes during shutdown, the following message appears
on screen twice:
systemd-cgroups-agent failed to get dbus connection: failed to connect
to socket /org/freedesktop/systemd/private connection refused

The following may be relevant from the logs:
May 07 09:13:05 hobo login[223]: pam_unix(login:session): session closed
for user ross
May 07 09:13:05 hobo login[223]: pam_systemd(login:session): Failed to
connect to system bus: Did not reply. Possible causes include: the
remote application did not send a reply, the message bus security policy
blocked the reply, the reply timeout expired, or the network connection
was broken.
May 07 09:13:05 hobo systemd[1]: Stopped Getty on tty1.

Seems harmless enough, but there could be some sort of bug here.
-- 
Ross Lagerwall
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] man: fix typos in systemd.special

[Ross Lagerwall]

---
 man/systemd.special.xml | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/man/systemd.special.xml b/man/systemd.special.xml
index 61d45ff..7164b1e 100644
--- a/man/systemd.special.xml
+++ b/man/systemd.special.xml
@@ -784,7 +784,7 @@
 available at boot./para
 
 paraThis may be used to pull
-in printer management
+in smartcard management
 daemons dynamically when
 smartcard hardware is
 found./para
@@ -801,7 +801,7 @@
 
 paraThis may be used to pull
 in audio management daemons
-dynamically when printer
+dynamically when audio
 hardware is found./para
 /listitem
 /varlistentry
-- 
1.8.2.2

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl enable does not report all actions

[Ross Lagerwall]

On Wed, Apr 24, 2013 at 11:18:15AM +0200, Harald Hoyer wrote:
 # systemctl disable foo.service bar.service
 # systemctl enable foo.service
 
 ... reboot ...
 
 # cp /lib/systemd/system/foo.service /etc/systemd/system/foo.service
 # vi /etc/systemd/system/foo.service
 
 .. admin forgets, that the old foo.service is already enabled.
 
 # systemctl enable foo.service bar.service
 Failed to issue method call: File exists
 

I had a similar issue with reenable (and a similarly obscure error
message):
http://lists.freedesktop.org/archives/systemd-devel/2013-April/010607.html

-- 
Ross Lagerwall
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] disable/enable vs reenable

[Ross Lagerwall]

Hi,

If one executes:
$ sudo systemctl enable getty@tty1.service
ln -s '/usr/lib/systemd/system/getty@.service' 
'/etc/systemd/system/getty.target.wants/getty@tty1.service'

and then you decide to override getty@.service:
$ sudo cp /usr/lib/systemd/system/getty@.service 
/etc/systemd/system/getty@.service

the override does not work, as expected, because the symbolic link points to 
/usr..., not the
overridden service file:
$ ls -l /etc/systemd/system/getty.target.wants/
total 0
lrwxrwxrwx 1 root root 38 Apr 18 08:41 getty@tty1.service - 
/usr/lib/systemd/system/getty@.service

The documentation for reenable indicates that it should fix this problem:
 reenable NAME...
   Reenable one or more unit files, as specified on the command line. 
This is a combination
   of disable and enable and is useful to reset the symlinks a unit is 
enabled with to the
   defaults configured in the [Install] section of the unit file.

But it does not work:
$ sudo systemctl reenable getty@tty1.service
Failed to issue method call: File exists

However, disabling and enabling *does* work and gives the desired result:
$ sudo systemctl disable getty@tty1.service
rm '/etc/systemd/system/getty.target.wants/getty@tty1.service'
$ sudo systemctl enable getty@tty1.service
ln -s '/etc/systemd/system/getty@.service' 
'/etc/systemd/system/getty.target.wants/getty@tty1.service'

Is this a bug, a documentation problem or neither?

(using Arch Linux with systemd 201)

Regards
-- 
Ross Lagerwall
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel