Re: [systemd-devel] Can LSBInitScipts specify an dependency on systemd unit?
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?
On Thu, Jun 9, 2016 at 9:55 AM, Bao Nguyenwrote: > 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
--- 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)
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
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
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
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
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
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
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
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
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
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
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: ...)
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
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: ...)
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: ...)
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: ...)
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
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
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
--- 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
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
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