Initial perf results confirm cgroups rework as the culprit. We're
seeing huge time spent in unit_get_members_mask,
cgroup_context_get_mask, and unit_get_cgroup_context.
___
systemd-devel mailing list
[email protected]
http://lists.freede
On Sun, Oct 13, 2013 at 4:46 PM, Zbigniew Jędrzejewski-Szmek <
[email protected]> wrote:
> On Sun, Oct 06, 2013 at 05:20:58AM +0200, Zbigniew Jędrzejewski-Szmek
> wrote:
> > Hi,
> >
> > sorry for the long delay. I was expecting this review to take
> > some time, and I was right :)
> >
> > I start
--- Quick background:
I work with David Strauss @ Pantheon and systemd is a core part of our
platform. Recently we have been running into some scalability issues with
systemd with the time required for `daemon-reload` to complete. We are
seeing situations where this takes a long time (~ 50s) to com
'Twas brillig, and Warpme at 17/10/13 20:25 did gyre and gimble:
> On 10/17/13 7:59 PM, Colin Guthrie wrote:
>> 'Twas brillig, and Warpme at 17/10/13 18:15 did gyre and gimble:
>>> On 10/17/13 4:27 PM, Colin Guthrie wrote:
Perhaps a dumb question but are you 100% certain that
systemd-remo
Am 17.10.2013 21:25, schrieb Warpme:
> So summarizing:
> 1.systemd-remount-fs.service status from boot sequence is OK - but / is ro
> 2.starting /usr/lib/systemd/systemd-remount-fs switches / to rw
> 3.systemctl restart systemd-remount-fs.service switches / to rw
>
> Console output from 1 & 3 is
On 10/17/13 7:59 PM, Colin Guthrie wrote:
'Twas brillig, and Warpme at 17/10/13 18:15 did gyre and gimble:
On 10/17/13 4:27 PM, Colin Guthrie wrote:
Perhaps a dumb question but are you 100% certain that
systemd-remount-fs.service has been run? I've not seen any debug about
it so far on this thr
'Twas brillig, and Warpme at 17/10/13 18:15 did gyre and gimble:
> On 10/17/13 4:27 PM, Colin Guthrie wrote:
>> Perhaps a dumb question but are you 100% certain that
>> systemd-remount-fs.service has been run? I've not seen any debug about
>> it so far on this thread:
>>
>> systemctl status systemd
On 10/17/13 4:27 PM, Colin Guthrie wrote:
Perhaps a dumb question but are you 100% certain that
systemd-remount-fs.service has been run? I've not seen any debug about
it so far on this thread:
systemctl status systemd-remount-fs.service
Col
Col,
Console reports "Starting Remount Root and Ke
'Twas brillig, and Warpme at 17/10/13 13:59 did gyre and gimble:
> On 10/16/13 9:46 PM, Zbigniew Jędrzejewski-Szmek wrote:
>> On Wed, Oct 16, 2013 at 09:19:43PM +0200, Warpme wrote:
>>> Maybe we should disable [re]mounting / by systemd at all?
>> All systemd does, is call 'mount -o remount /'. I ha
On Thu, Oct 17, 2013 at 02:59:37PM +0200, Warpme wrote:
> On 10/16/13 9:46 PM, Zbigniew Jędrzejewski-Szmek wrote:
> >On Wed, Oct 16, 2013 at 09:19:43PM +0200, Warpme wrote:
> >>Maybe we should disable [re]mounting / by systemd at all?
> >All systemd does, is call 'mount -o remount /'. I have no ide
Am 17.10.2013 14:59, schrieb Warpme:
> On 10/16/13 9:46 PM, Zbigniew Jędrzejewski-Szmek wrote:
>> On Wed, Oct 16, 2013 at 09:19:43PM +0200, Warpme wrote:
>>> Maybe we should disable [re]mounting / by systemd at all?
>> All systemd does, is call 'mount -o remount /'. I have no idea how you end
>>
On 10/16/13 9:46 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Oct 16, 2013 at 09:19:43PM +0200, Warpme wrote:
Maybe we should disable [re]mounting / by systemd at all?
All systemd does, is call 'mount -o remount /'. I have no idea how you end
up with a read-only filesystem.
As a work-around,
On Thu, Oct 17, 2013 at 4:54 AM, Andrey Borzenkov wrote:
> В Thu, 17 Oct 2013 00:07:55 +0200
> Kay Sievers пишет:
>
>> > typically the line looks like this
>> > UUID=b834776d-69d1-49c6-97c1-d6d758a438f0 / ext4 defaults
>> >
>> > i doubt that anything smells what "none" means
>>
>> It typically m
13 matches
Mail list logo
