Re: [systemd-devel] moving from SysV to systemd - issue with / being ro
On Thu, Oct 17, 2013 at 4:54 AM, Andrey Borzenkov arvidj...@gmail.com wrote: В Thu, 17 Oct 2013 00:07:55 +0200 Kay Sievers k...@vrfy.org пишет: typically the line looks like this UUID=b834776d-69d1-49c6-97c1-d6d758a438f0 / ext4 defaults i doubt that anything smells what none means It typically makes not much sense to specify the id of the rootfs in a file stored *on* the rootfs. You need to store it (default root device) somewhere to pass onto initrd. /etc/fstab is as good a place as any other. Not sure why you want to store the boot loader config in fstab. The boot loader can't read fstab, and if you want it to *create* the boot loader config or initrd, fstab is surely not enough information. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] moving from SysV to systemd - issue with / being ro
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, you can add /etc/systemd/system/systemd-remount-fs.service.d/90-remount.conf with [Service] ExecStartPost=mount -o remount,rw / and/or run systemd in debug mode (add systemd.log_level=debug on the kernel command line), to see what is going on. Zbyszek Adding /etc/systemd/system/systemd-remount-fs.service.d/90-remount.conf not helps. When I enable debugging by adding systemd.log_level=debug I'm receiving tons of messages about started/failed journal. Probably due / being in ro mode. Is it possible that ro issue is because I'm building systemd with minimal enabled features ? My configure line is following: --disable-nls \ --disable-gtk-doc \ --disable-gtk-doc-html \ --disable-gtk-doc-pdf \ --enable-introspection=no \ --disable-ima \ --disable-selinux \ --disable-xz \ --disable-tcpwrap \ --disable-pam \ --disable-acl \ --disable-xattr \ --disable-gcrypt \ --disable-audit \ --disable-libcryptsetup \ --disable-qrencode \ --disable-microhttpd \ --disable-binfmt \ --disable-vconsole \ --disable-readahead \ --disable-quotacheck \ --disable-randomseed \ --disable-logind \ --disable-hostnamed \ --disable-timedated \ --disable-localed \ --disable-coredump \ --disable-gudev \ --disable-keymap \ --disable-manpages \ --enable-split-usr \ --without-python \ LIBS=$(DESTDIR)$(libdir)/libcap.so ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] moving from SysV to systemd - issue with / being ro
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 up with a read-only filesystem. As a work-around, you can add /etc/systemd/system/systemd-remount-fs.service.d/90-remount.conf with [Service] ExecStartPost=mount -o remount,rw / and/or run systemd in debug mode (add systemd.log_level=debug on the kernel command line), to see what is going on. Zbyszek Adding /etc/systemd/system/systemd-remount-fs.service.d/90-remount.conf not helps. When I enable debugging by adding systemd.log_level=debug I'm receiving tons of messages about started/failed journal. Probably due / being in ro mode. Is it possible that ro issue is because I'm building systemd with minimal enabled features ? you should not disable configure options like a butcher and at least not from start normally you build software with default options and try what you can remove and change before things start to break horrible, not the other way --disable-pam --disable-acl --disable-xattr is for sure not smart adn many of the others are questionable if you are not on a embedded device My configure line is following: --disable-nls \ --disable-gtk-doc \ --disable-gtk-doc-html \ --disable-gtk-doc-pdf \ --enable-introspection=no \ --disable-ima \ --disable-selinux \ --disable-xz \ --disable-tcpwrap \ --disable-pam \ --disable-acl \ --disable-xattr \ --disable-gcrypt \ --disable-audit \ --disable-libcryptsetup \ --disable-qrencode \ --disable-microhttpd \ --disable-binfmt \ --disable-vconsole \ --disable-readahead \ --disable-quotacheck \ --disable-randomseed \ --disable-logind \ --disable-hostnamed \ --disable-timedated \ --disable-localed \ --disable-coredump \ --disable-gudev \ --disable-keymap \ --disable-manpages \ --enable-split-usr \ --without-python \ LIBS=$(DESTDIR)$(libdir)/libcap.so 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] moving from SysV to systemd - issue with / being ro
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 idea how you end up with a read-only filesystem. As a work-around, you can add /etc/systemd/system/systemd-remount-fs.service.d/90-remount.conf with [Service] ExecStartPost=mount -o remount,rw / and/or run systemd in debug mode (add systemd.log_level=debug on the kernel command line), to see what is going on. Zbyszek Adding /etc/systemd/system/systemd-remount-fs.service.d/90-remount.conf not helps. Hm. When I enable debugging by adding systemd.log_level=debug I'm receiving tons of messages about started/failed journal. Probably due / being in ro mode. That's possible. Try removing or renaming /var/log/journal... journald should then stay in /run/log/journal. Is it possible that ro issue is because I'm building systemd with minimal enabled features ? My configure line is following: ... Those shouldn't matter. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] moving from SysV to systemd - issue with / being ro
'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 have no idea how you end up with a read-only filesystem. As a work-around, you can add /etc/systemd/system/systemd-remount-fs.service.d/90-remount.conf with [Service] ExecStartPost=mount -o remount,rw / and/or run systemd in debug mode (add systemd.log_level=debug on the kernel command line), to see what is going on. Zbyszek Adding /etc/systemd/system/systemd-remount-fs.service.d/90-remount.conf not helps. 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 -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] moving from SysV to systemd - issue with / being ro
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 Kernel Filesystems... and next (after some other entries) Started Root and Kernel Filesystems... Looking on systemctl status systemd-remount-fs.service reports: Loaded: loaded Active: active (exited) (with green color) Exit code=0/SUCCESS For me this unit looks like started, executed and exited OK. My general logic is following: -let assume initrd script leaves / with mode we are not sure (ro or rw) -with SysV I don't have anywhere else remount command for / to rw - so backward logic says script provides / with rw -now I'm changing last line in script from /sbin/init to /usr/lib/systemd/systemd (script body is in OP of this thread) -I'm receiving / with ro mode. So logic says that /usr/lib/systemd/systemd process changes mode of / from rw to ro Is there way to tell to systemd not mount/remout / (ideally not touch / at all) ? br ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] moving from SysV to systemd - issue with / being ro
'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-remount-fs.service Console reports Starting Remount Root and Kernel Filesystems... This is the important one and next (after some other entries) Started Root and Kernel Filesystems... This one seems different but I guess you maybe just missed the word Remount in the retyping? Looking on systemctl status systemd-remount-fs.service reports: Loaded: loaded Active: active (exited) (with green color) Exit code=0/SUCCESS For me this unit looks like started, executed and exited OK. Yup, that looks good. FWIW, all it does is run a little utility shipped with systemd that finds / and /usr in /etc/fstab and attempts to remount them. The utility binary is [/usr]/lib/systemd/systemd-remount-fs It seems that it ran and exited with 0 which is successful, but I cannot see how it could do that unless it had trouble parsing the fstab and just couldn't spot / or /usr. My general logic is following: -let assume initrd script leaves / with mode we are not sure (ro or rw) -with SysV I don't have anywhere else remount command for / to rw OK, this did used to be done in (IIRC) rc.sysinit via initscripts package, but as you say it's not there, I'll take your word for it. - so backward logic says script provides / with rw -now I'm changing last line in script from /sbin/init to /usr/lib/systemd/systemd (script body is in OP of this thread) -I'm receiving / with ro mode. So logic says that /usr/lib/systemd/systemd process changes mode of / from rw to ro I can see why you get to this conclusion, but I'd be cautious of assuming this is how things work! Is there way to tell to systemd not mount/remout / (ideally not touch / at all) ? Technically it you can just mask the systemd-remount-fs.service which will avoid the remounts, but, if I'm honest, I suspect something in your sysvinit setup *is* doing the remount for you somehow. Here's what I would suggest: 1. Boot and get a shell where / is ro (i.e. the error state) 2. Run the [/usr]/lib/systemd/systemd-remount-fs manually and see if it corrects the mount problem. 3. If 2) does NOT solve the problem, run: /bin/mount / -o remount (including the full path). This is all that the above utility does internally, so if this fails on it's own, then running it via the utility cannot fix it. If 3 works but 2 didn't, then the only way I can see it not doing it's job, but still exiting successfully, is if it fails to properly parse your fstab. Here is the source: http://cgit.freedesktop.org/systemd/systemd/tree/src/remount-fs/remount-fs.c Even if you are not too familiar with c, it should be easy to follow. HTHs Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] moving from SysV to systemd - issue with / being ro
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 thread: systemctl status systemd-remount-fs.service Console reports Starting Remount Root and Kernel Filesystems... This is the important one and next (after some other entries) Started Root and Kernel Filesystems... This one seems different but I guess you maybe just missed the word Remount in the retyping? Looking on systemctl status systemd-remount-fs.service reports: Loaded: loaded Active: active (exited) (with green color) Exit code=0/SUCCESS For me this unit looks like started, executed and exited OK. Yup, that looks good. FWIW, all it does is run a little utility shipped with systemd that finds / and /usr in /etc/fstab and attempts to remount them. The utility binary is [/usr]/lib/systemd/systemd-remount-fs It seems that it ran and exited with 0 which is successful, but I cannot see how it could do that unless it had trouble parsing the fstab and just couldn't spot / or /usr. My general logic is following: -let assume initrd script leaves / with mode we are not sure (ro or rw) -with SysV I don't have anywhere else remount command for / to rw OK, this did used to be done in (IIRC) rc.sysinit via initscripts package, but as you say it's not there, I'll take your word for it. - so backward logic says script provides / with rw -now I'm changing last line in script from /sbin/init to /usr/lib/systemd/systemd (script body is in OP of this thread) -I'm receiving / with ro mode. So logic says that /usr/lib/systemd/systemd process changes mode of / from rw to ro I can see why you get to this conclusion, but I'd be cautious of assuming this is how things work! Is there way to tell to systemd not mount/remout / (ideally not touch / at all) ? Technically it you can just mask the systemd-remount-fs.service which will avoid the remounts, but, if I'm honest, I suspect something in your sysvinit setup *is* doing the remount for you somehow. Here's what I would suggest: 1. Boot and get a shell where / is ro (i.e. the error state) 2. Run the [/usr]/lib/systemd/systemd-remount-fs manually and see if it corrects the mount problem. 3. If 2) does NOT solve the problem, run: /bin/mount / -o remount (including the full path). This is all that the above utility does internally, so if this fails on it's own, then running it via the utility cannot fix it. If 3 works but 2 didn't, then the only way I can see it not doing it's job, but still exiting successfully, is if it fails to properly parse your fstab. Here is the source: http://cgit.freedesktop.org/systemd/systemd/tree/src/remount-fs/remount-fs.c Even if you are not too familiar with c, it should be easy to follow. HTHs Col Col, Many thx for replay. It looks like we are moving forward: 2 works. 3 always worked. So now Q is why manual launching /usr/lib/systemd/systemd-remount-fs works, and unit with this exec launched by systemd not. Restarting unit via systemctl restart also fixes problem. 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 the same. So it looks like: a\ /usr/lib/systemd/systemd-remount-fs from 1 is not doing its job, or b\ /usr/lib/systemd/systemd-remount-fs is doing its job but later / somehow is switched back to ro. Maybe issue is within my fstab? It has: none/autoremount,rw0 0 br ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] moving from SysV to systemd - issue with / being ro
'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-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 Console reports Starting Remount Root and Kernel Filesystems... This is the important one and next (after some other entries) Started Root and Kernel Filesystems... This one seems different but I guess you maybe just missed the word Remount in the retyping? Looking on systemctl status systemd-remount-fs.service reports: Loaded: loaded Active: active (exited) (with green color) Exit code=0/SUCCESS For me this unit looks like started, executed and exited OK. Yup, that looks good. FWIW, all it does is run a little utility shipped with systemd that finds / and /usr in /etc/fstab and attempts to remount them. The utility binary is [/usr]/lib/systemd/systemd-remount-fs It seems that it ran and exited with 0 which is successful, but I cannot see how it could do that unless it had trouble parsing the fstab and just couldn't spot / or /usr. My general logic is following: -let assume initrd script leaves / with mode we are not sure (ro or rw) -with SysV I don't have anywhere else remount command for / to rw OK, this did used to be done in (IIRC) rc.sysinit via initscripts package, but as you say it's not there, I'll take your word for it. - so backward logic says script provides / with rw -now I'm changing last line in script from /sbin/init to /usr/lib/systemd/systemd (script body is in OP of this thread) -I'm receiving / with ro mode. So logic says that /usr/lib/systemd/systemd process changes mode of / from rw to ro I can see why you get to this conclusion, but I'd be cautious of assuming this is how things work! Is there way to tell to systemd not mount/remout / (ideally not touch / at all) ? Technically it you can just mask the systemd-remount-fs.service which will avoid the remounts, but, if I'm honest, I suspect something in your sysvinit setup *is* doing the remount for you somehow. Here's what I would suggest: 1. Boot and get a shell where / is ro (i.e. the error state) 2. Run the [/usr]/lib/systemd/systemd-remount-fs manually and see if it corrects the mount problem. 3. If 2) does NOT solve the problem, run: /bin/mount / -o remount (including the full path). This is all that the above utility does internally, so if this fails on it's own, then running it via the utility cannot fix it. If 3 works but 2 didn't, then the only way I can see it not doing it's job, but still exiting successfully, is if it fails to properly parse your fstab. Here is the source: http://cgit.freedesktop.org/systemd/systemd/tree/src/remount-fs/remount-fs.c Even if you are not too familiar with c, it should be easy to follow. HTHs Col Col, Many thx for replay. It looks like we are moving forward: 2 works. 3 always worked. So now Q is why manual launching /usr/lib/systemd/systemd-remount-fs works, and unit with this exec launched by systemd not. Restarting unit via systemctl restart also fixes problem. 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 the same. So it looks like: a\ /usr/lib/systemd/systemd-remount-fs from 1 is not doing its job, or b\ /usr/lib/systemd/systemd-remount-fs is doing its job but later / somehow is switched back to ro. Maybe issue is within my fstab? It has: none/autoremount,rw0 0 IMO, it shouldn't have remount as the option here. I think this is only something that should be given on the command line. That said, as the tool worked properly, it would seem that *something* is re-re-mounting it ro again *after* the systemd tool runs... or for some reason, /etc/fstab is non-existent (or empty) when the systemd tool is run at boot. I doubt this is the case, but maybe. As the tool has various log_debug() calls in it, if you boot with systemd.log_level=debug, I believe you should see those messages in your log. If you don't see them, but do see them when you manually run the tool later, then this points to a problem with the /etc/fstab during early boot. HTHs col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org
[systemd-devel] issues with large number of units, systemd 204 and 208 [d10k]
--- 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 complete or times out (90s). We understand there have been some fixes in systemd 208 that address issues with dependency calculation that should help speed up daemon-reload. I have been testing systemd-208 and while I see the improvement in daemon-reload time I am also observing new issues which I believe may be related to cgroups. --- Current setup: We are currently on fedora-19 with systemd 204. A typical server for us has about 16,000 units but we would like to get to around 32,000 units which would be equivalent to about 5000 containers for our platform. These units are split up mostly even between: .mount, .automount, .socket, and .service's. Most units are inactive at any given time and started on demand via socket-activation. --- New issues with systemd 208 and (maybe) cgroup management? I am working on running a series of tests right now and hope to have more numbers for the mailing list shortly. In the meantime, here is a synopsis of what I am seeing: First - I have created a test box running f19 + systemd-20 and 16,000 units. This is split between 4000 .mounts, 4000 .automounts, 4000 .sockets, and 4000 .services (test-X.mount, test-X.automount, test-nginx-X.socket, test-nginx-X.service). `daemon-reload` takes about 15 seconds to complete with all else being relatively quiet on the server. Restart/start/stop of any given service is fast, 1s. Next - I upgrade to systemd-208, same 16,000 units. systemd completes the re-exec but sits at 100% cpu forever (or at least hours, I give up waiting). All attempts to access systemd will timeout. strace of systemd shows that it is calling open() on every object in the /sys/fs/cgroup tree. Rebooting the server results in a box that is not able to complete a boot. Console shows the server sitting very early in the boot process at the Welcome to f19 message. I suspect systemd is spinning at 100% and cannot move forward. Finally - On a hunch, based on the data observed through strace, I modify my sample units and create a new .slice for each set of units so that not all 16,000 units are placed under the default system.slice. Thus I end up with one additional unit for each set, ie: 4000 * (test-X.slice, test-X.mount, test-X.automount, test-nginx-X.socket, test-nginx-X.service), and each of the units in a set is assigned to the relevant test-X.slice. This works with systemd-204 which ignores the unknown Slice= settings, then I upgrading to systemd-208 which goes smoother, and a reboot of the server is successful. `daemon-reload` is fast now: 3s -vs- 15s. However, start/stop/restart of a service takes 25-30seconds. Strace of systemd shows a lot of open() activity across the cgroup tree. I am wondering if something significant changed between 204 and 208 with regards to handling of cgroups? Restarting a service in 204, strace shows only a handful of open() calls to cgroup nodes that are relevant to the service being restarted, but in 208 it appears that systemd may be scanning the entire cgroup tree.. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] test: test for ellipsize (manual)
On Sun, Oct 13, 2013 at 4:46 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl 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 started by running test-ellipsize under valgrind, and found that there unitialized memory was written. There was a bug in ellipsize_mem: when the string was short enough to fit whole, the middle part was used twice. E.g. abcdef was ellipsized as abcd...cdef. But space was allocated without this overlap, so valgrind was unhappy. Also, there was some overlap with existing functions, so I managed to remove a large part of the patch. I moved the new code to a separate file, to avoid mixing code written in two copletely different styles in the same file. I hope it'll make it easier to pull changes from glib in the future. I think that ellipsize_ascii should be removed, small saving in allocated memory probably isn't worth the extra scan which is done to check if the string is pure ASCII. Also, it's not nice that ellipsization is different for pure ASCII and ASCII strings. I think we should use the same character(s) in both cases. But I left it as is for now. I also optimized the function a bit, so that memory is not zeroed after allocation, and unicode verification is performed while counting the characters. I found that the COW FACE sequence is not ellipsized properly, because COW FACEs are fullwidth. I've added this whole block to the fullwidth table in a separate patch. All in all, those are pretty significant changes. Therefore, instead of pushing, I've posted the changes at http://in.waw.pl/git/systemd/ Could you have a look at the updated patches, and maybe test them a bit? Pushed now. Thanks for your work on this and sorry for not getting around to reviewing your work. Zbyszek ___ 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] issues with large number of units, systemd 204 and 208 [d10k]
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 systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
