On Fri, 21 Nov 2014 20:20:45 + Simon McVittie wrote:
> dependency: systemd logs that there was a loop, and which arbitrary point
> it tried to use to break it. However, it does not log (an example of) the
> whole path around the loop before it started trying to break it.
IIRC it does log that
On Wed, 22 Oct 2014 18:23:54 +1100 Marc Bonnor wrote:
> The command ls -l /tmp also blocks ...
That pretty much confirms that it is a filesystem problem not directly
related to systemd.
> The line before the lines shown in the file extract has an odd looking
> path "//tmp", do you think this may
Marc Bonnor wrote:
> I have run the strace command as suggested and attached the output.
> 18:58:28 open("/tmp",
> O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_NOFOLLOW|O_NOATIME|O_CLOEXEC) = 4
> 18:58:28 fstat(4, {st_mode=S_IFDIR|S_ISVTX|0777, st_size=117604352, ...}) = 0
> 18:58:28 fcntl(4, F_GETFL)
Marc Bonnor wrote:
> I have also poked around in the debug shell during boot and there is almost no
> cpu activity and the systemd-tmpfiles command has statuts 'D' uniteruptable
> sleep.
>
> I used iotop to view io activity during the boot and this 'Executing: /bin
> /systemd-tmpfiles --create --r
Marco d'Itri wrote:
> On Sep 23, 積丹尼 Dan Jacobson wrote:
> > Why the \x2d in one 'slice' but not the other?
> Because one contains / and the other does not.
2d hex is '-', not '/'. The actual reason is that '-' in slice names has
a special meaning to separate hierarchical components, and '-' with
I checked that this did not happen on a system I just updated from 204
to 215; contents of /run/user/1000 remained unchanged after the upgrade.
Are you sure that the upgrade actually *removed* contents? A possibly
relevant change is that logind started to mount a per-user tmpfs
in /run/user/* (for
Sjoerd Simons wrote:
> * e366cac Rework the semantics of restart job deadlock avoidance during early
> boot and shutdown.
>
> The main patch here was sent to the systemd list, from the discussion it
> seems upstream doesn't like that approach. I don't think this is an area
> where we should diver
to systemd could help. I haven't tried running it at
all, but at least the existing code looks suspicious, so if correct the
patch could fix the same issue.
>From 6d575f18437dd5bfd02c4736dbd3e6a8a1286ab2 Mon Sep 17 00:00:00 2001
From: Uoti Urpala
Date: Mon, 23 Jun 2014 08:14:22 +0300
Sub
Ed Swierk wrote:
> I found that adding RemainAfterExit=yes to the service file prevents
> this from happening. But nothing in the systemd documentation (nor in
> the code, to the extent I understand it) indicates that this is
> necessary for oneshot services.
This has been a known issue for some s
