Re: [systemd-devel] udevadm settle takes too long to finish
On Dec 9, 2013, at 11:47 PM, Andrey Borzenkov wrote: > В Mon, 9 Dec 2013 12:42:21 -0700 > Chris Murphy пишет: > >> >> On Dec 9, 2013, at 3:33 AM, Thomas Bächler wrote: >> >> I'm finding that plymouth-start.service uses ExecStartPost= to call udevadm >> settle twice. >> >> The actual culprit though is dmraid-activation.service which is enabled by >> default (why?) and Wants=systemd-udev-settle.service. >> dmraid.activation.service also has the #2 biggest blame hit: >> 4.551s dmraid-activation.service >> > > There is no such service on openSUSE, which OP has :) Right, sorry this is Fedora 20, specifically the live install. > >> So why is this enabled by default when there's no dmraid at all, and never >> has been dmraid metadata on any attached device? >> > > The obvious question is - and how should system know it? Who is > responsible for activating it again after you have added dmraid devices? The argument being used in this bug: https://bugzilla.redhat.com/show_bug.cgi?id=964172 Is that the dmraid package isn't installed if the user hasn't created a dmraid device at install time; except with live installs which will always have it installed (and enabled) and the user is expected to disable dmraid if they don't use it. It doesn't work this way for XFS devices, or md devices, or LVM devices. So this is pretty puzzling that by design the user is responsible. Maybe it just makes it easier for dmraid to go away. > > Is it possible to trigger dmraid from some udev rule similar to what > mdadm currently does? Sure, that seems to work pretty well. It's fast whether md devices exist or not. Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevadm settle takes too long to finish
Am 10.12.2013 18:37, schrieb Lennart Poettering: >> What's the distribution you are using? Using udevadm settle for lvm is a >> waste of boot time and isn't even guaranteed to work (ask Lennart, Kay >> or Greg K-H for the full speech). It's a hackish workaround for LVM's >> inability to activate volumes automatically. > > afaik on very recent fedora lvm has been fixed to now require udevadm > settle anymore, one of my favourite issues with LVM is gone now... > > That said I have not looked into it in detail, so I don't know if this > is all good now. (I sure I won't let LVM anywhere near my systems...) The rest of my email actually has some of the details on the improved mechanisms. 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] udevadm settle takes too long to finish
On Mon, 09.12.13 11:33, Thomas Bächler (tho...@archlinux.org) wrote: > Am 07.12.2013 22:29, schrieb Robert Milasan: > > From systemd-analyze dump: > > > > Wants: systemd-udevd.service > > WantedBy: lvm2-activation-early.service > > WantedBy: lvm2-activation.service > > Before: lvm2-activation-early.service > > Before: sysinit.target > > After: systemd-udev-trigger.service > > After: systemd-journald.socket > > References: systemd-udevd.service > > References: systemd-udev-trigger.service > > References: sysinit.target > > References: systemd-journald.socket > > ReferencedBy: lvm2-activation-early.service > > ReferencedBy: lvm2-activation.service > > What's the distribution you are using? Using udevadm settle for lvm is a > waste of boot time and isn't even guaranteed to work (ask Lennart, Kay > or Greg K-H for the full speech). It's a hackish workaround for LVM's > inability to activate volumes automatically. afaik on very recent fedora lvm has been fixed to now require udevadm settle anymore, one of my favourite issues with LVM is gone now... That said I have not looked into it in detail, so I don't know if this is all good now. (I sure I won't let LVM anywhere near my systems...) (What I did see though is that they still use a pair of FIFOs as daemon IPC. Which doesn't really enhance my trust in the new LVM code that much.) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevadm settle takes too long to finish
El 10/12/13 03:47, Andrey Borzenkov escribió: There is no such service on openSUSE, which OP has :) Yes there is :-) but in factory only. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevadm settle takes too long to finish
В Mon, 9 Dec 2013 12:42:21 -0700 Chris Murphy пишет: > > On Dec 9, 2013, at 3:33 AM, Thomas Bächler wrote: > > > Am 07.12.2013 22:29, schrieb Robert Milasan: > >> From systemd-analyze dump: > >> > >>Wants: systemd-udevd.service > >>WantedBy: lvm2-activation-early.service > >>WantedBy: lvm2-activation.service > >>Before: lvm2-activation-early.service > >>Before: sysinit.target > >>After: systemd-udev-trigger.service > >>After: systemd-journald.socket > >>References: systemd-udevd.service > >>References: systemd-udev-trigger.service > >>References: sysinit.target > >>References: systemd-journald.socket > >>ReferencedBy: lvm2-activation-early.service > >>ReferencedBy: lvm2-activation.service > > > > What's the distribution you are using? Using udevadm settle for lvm is a > > waste of boot time and isn't even guaranteed to work (ask Lennart, Kay > > or Greg K-H for the full speech). It's a hackish workaround for LVM's > > inability to activate volumes automatically. > > I'm finding that plymouth-start.service uses ExecStartPost= to call udevadm > settle twice. > > The actual culprit though is dmraid-activation.service which is enabled by > default (why?) and Wants=systemd-udev-settle.service. > dmraid.activation.service also has the #2 biggest blame hit: > 4.551s dmraid-activation.service > There is no such service on openSUSE, which OP has :) > So why is this enabled by default when there's no dmraid at all, and never > has been dmraid metadata on any attached device? > The obvious question is - and how should system know it? Who is responsible for activating it again after you have added dmraid devices? Is it possible to trigger dmraid from some udev rule similar to what mdadm currently does? > If I systemctl disable dmraid-activation.service both the > dmraid-activation.service hit goes away, as does systemd-udev-settle.service. > > > Chris Murphy > ___ > 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] udevadm settle takes too long to finish
On Dec 9, 2013, at 3:33 AM, Thomas Bächler wrote: > Am 07.12.2013 22:29, schrieb Robert Milasan: >> From systemd-analyze dump: >> >>Wants: systemd-udevd.service >>WantedBy: lvm2-activation-early.service >>WantedBy: lvm2-activation.service >>Before: lvm2-activation-early.service >>Before: sysinit.target >>After: systemd-udev-trigger.service >>After: systemd-journald.socket >>References: systemd-udevd.service >>References: systemd-udev-trigger.service >>References: sysinit.target >>References: systemd-journald.socket >>ReferencedBy: lvm2-activation-early.service >>ReferencedBy: lvm2-activation.service > > What's the distribution you are using? Using udevadm settle for lvm is a > waste of boot time and isn't even guaranteed to work (ask Lennart, Kay > or Greg K-H for the full speech). It's a hackish workaround for LVM's > inability to activate volumes automatically. I'm finding that plymouth-start.service uses ExecStartPost= to call udevadm settle twice. The actual culprit though is dmraid-activation.service which is enabled by default (why?) and Wants=systemd-udev-settle.service. dmraid.activation.service also has the #2 biggest blame hit: 4.551s dmraid-activation.service So why is this enabled by default when there's no dmraid at all, and never has been dmraid metadata on any attached device? If I systemctl disable dmraid-activation.service both the dmraid-activation.service hit goes away, as does systemd-udev-settle.service. Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevadm settle takes too long to finish
On Mon, 09 Dec 2013 11:33:03 +0100 "Thomas Bächler" wrote: > Am 07.12.2013 22:29, schrieb Robert Milasan: > > From systemd-analyze dump: > > > > Wants: systemd-udevd.service > > WantedBy: lvm2-activation-early.service > > WantedBy: lvm2-activation.service > > Before: lvm2-activation-early.service > > Before: sysinit.target > > After: systemd-udev-trigger.service > > After: systemd-journald.socket > > References: systemd-udevd.service > > References: systemd-udev-trigger.service > > References: sysinit.target > > References: systemd-journald.socket > > ReferencedBy: lvm2-activation-early.service > > ReferencedBy: lvm2-activation.service > > What's the distribution you are using? Using udevadm settle for lvm > is a waste of boot time and isn't even guaranteed to work (ask > Lennart, Kay or Greg K-H for the full speech). It's a hackish > workaround for LVM's inability to activate volumes automatically. > > Instead, a socket-activated lvmetad service should be used in > combination with the correct udev rules. The service files are > provided by LVM, but they reference weird redhat-specific units and > from what I saw have too many orderings, which results in slowing > everything down needlessly. > > Currently, I use 69-dm-lvm-metad.rules provided by LVM in combination > with the unit files [1] and [2] (derived from the redhat units > included in LVM). This is fast and works great for me, although > lvmetad has some annoying bugs which have been reported to me, but > which I could never reproduce. > > There is no way to make udevadm settle "faster" and the only solution > is (as Kay said already) is not using it. > > [1] > https://projects.archlinux.org/svntogit/packages.git/tree/trunk/lvmetad.service?h=packages/lvm2 > [2] > https://projects.archlinux.org/svntogit/packages.git/tree/trunk/lvmetad.socket?h=packages/lvm2 > The distro is openSUSE and we are using lvm2-activation-generator which comes with lvm2 package: https://git.fedorahosted.org/cgit/lvm2.git/tree/scripts/lvm2_activation_generator_systemd_red_hat.c -- Robert Milasan L3 Support Engineer SUSE Linux (http://www.suse.com) email: rmila...@suse.com GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevadm settle takes too long to finish
Am 07.12.2013 22:29, schrieb Robert Milasan: > From systemd-analyze dump: > > Wants: systemd-udevd.service > WantedBy: lvm2-activation-early.service > WantedBy: lvm2-activation.service > Before: lvm2-activation-early.service > Before: sysinit.target > After: systemd-udev-trigger.service > After: systemd-journald.socket > References: systemd-udevd.service > References: systemd-udev-trigger.service > References: sysinit.target > References: systemd-journald.socket > ReferencedBy: lvm2-activation-early.service > ReferencedBy: lvm2-activation.service What's the distribution you are using? Using udevadm settle for lvm is a waste of boot time and isn't even guaranteed to work (ask Lennart, Kay or Greg K-H for the full speech). It's a hackish workaround for LVM's inability to activate volumes automatically. Instead, a socket-activated lvmetad service should be used in combination with the correct udev rules. The service files are provided by LVM, but they reference weird redhat-specific units and from what I saw have too many orderings, which results in slowing everything down needlessly. Currently, I use 69-dm-lvm-metad.rules provided by LVM in combination with the unit files [1] and [2] (derived from the redhat units included in LVM). This is fast and works great for me, although lvmetad has some annoying bugs which have been reported to me, but which I could never reproduce. There is no way to make udevadm settle "faster" and the only solution is (as Kay said already) is not using it. [1] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/lvmetad.service?h=packages/lvm2 [2] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/lvmetad.socket?h=packages/lvm2 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] udevadm settle takes too long to finish
On Dec 7, 2013, at 2:47 PM, Cristian Rodríguez wrote: > > apparently the generator is not yet smart enough to figure out that no > runtime units shall be generated if no LVM around.. the generator is > part of the LVM package so we are off-topic here now ;-) Ahh OK, so that's probably the same answer to my case. When I cat /usr/lib/systemd/system/lvm2-monitor.service I see this comment: # The lvmetad must be disabled here, it needs https://bugzilla.redhat.com/show_bug.cgi?id=843587 to be resolved first. What I don't understand is that lvmetad is merely a 68ms hit, yet lvm2-monitor.service is a huge 1.2s hit and I can't tell what it's waiting for, certainly not lvmetad. Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevadm settle takes too long to finish
On Dec 7, 2013, at 2:39 PM, Robert Milasan wrote: > > Well that didn't help, but this did: > > systemctl mask lvm2-activation.service > systemctl mask lvm2-activation-early.service > > If I only mask lvm2-activation.service, then it doesn't make much > difference, but masking both it works better. > > My question is: why does this happen, if lvm is not in use at all? Right. And on Fedora 20 I don't have those two lvm2 services, instead I have lvm2-monitor.service being pulled in even though LVM isn't being used at all. 1.270s lvm2-monitor.service 1.267s systemd-udev-settle.service [root@f20s ~]# systemctl status lvm2-monitor.service lvm2-monitor.service - Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling Loaded: loaded (/usr/lib/systemd/system/lvm2-monitor.service; enabled) Active: active (exited) since Sat 2013-12-07 12:25:57 MST; 2h 23min ago Docs: man:dmeventd(8) man:lvcreate(8) man:lvchange(8) man:vgchange(8) Process: 226 ExecStart=/usr/sbin/lvm vgchange --monitor y (code=exited, status=0/SUCCESS) Main PID: 226 (code=exited, status=0/SUCCESS) Dec 07 12:25:56 f20s.localdomain lvm[226]: /dev/sr0: open failed: No medium found Dec 07 12:25:57 f20s.localdomain lvm[226]: No volume groups found Dec 07 12:25:57 f20s.localdomain systemd[1]: Started Monitoring of LVM2 mirrors, snapshots etc. using dmeventd or progress polling. So is the correct question, why is this service enabled by default? And what enables such things? Is this an installer just doing the easy thing and setting it to be enabled just in case the user chose an LVM install (which is the Fedora 20 default) rather than making it a conditional monitoring? Or is the correct question why is this one command to monitor taking even 1.2 seconds to do what it needs to do? That's a long time. The other thing is that on baremetal I get 30 second boot times according to blame. However the exact same install parameters in qemu/kvm on that same baremetal machine and I'm getting 4 second boot times. Why is the baremetal sooo much slower in user space? I can understand optimization of the kernel and initrd being loaded but I don't understand the performance of userspace going from 22 seconds to 3 seconds. Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevadm settle takes too long to finish
El 07/12/13 18:39, Robert Milasan escribió: > On Sat, 07 Dec 2013 18:35:38 -0300 > "Cristian Rodríguez" wrote: > >> >> I have the same "issue" ..(not much of a problem actually) it is >> caused by the LVM activator that (in openSUSE at least) runs even >> when you are not using lvm.. the units are autogenerated ones.. >> >> systemctl mask lvm2-activation.service >> >> made the issue go away. >> > > Well that didn't help, but this did: > > systemctl mask lvm2-activation.service > systemctl mask lvm2-activation-early.service > > If I only mask lvm2-activation.service, then it doesn't make much > difference, but masking both it works better. > > My question is: why does this happen, if lvm is not in use at all? apparently the generator is not yet smart enough to figure out that no runtime units shall be generated if no LVM around.. the generator is part of the LVM package so we are off-topic here now ;-) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevadm settle takes too long to finish
On Sat, 07 Dec 2013 18:35:38 -0300 "Cristian Rodríguez" wrote: > > I have the same "issue" ..(not much of a problem actually) it is > caused by the LVM activator that (in openSUSE at least) runs even > when you are not using lvm.. the units are autogenerated ones.. > > systemctl mask lvm2-activation.service > > made the issue go away. > Well that didn't help, but this did: systemctl mask lvm2-activation.service systemctl mask lvm2-activation-early.service If I only mask lvm2-activation.service, then it doesn't make much difference, but masking both it works better. My question is: why does this happen, if lvm is not in use at all? -- Robert Milasan L3 Support Engineer SUSE Linux (http://www.suse.com) email: rmila...@suse.com GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevadm settle takes too long to finish
El 07/12/13 16:46, Robert Milasan escribió: > I'm running systemd 208 and I've noticed that the service that > takes the most time to finish is 'systemd-udev-settle.service': > > rmilasan@coolcat:~> systemd-analyze blame|head > 1.890s systemd-udev-settle.service > 1.804s NetworkManager.service > 1.447s ModemManager.service > 1.410s kmod-static-nodes.service > 1.408s systemd-udev-root-symlink.service > 1.042s dev-mqueue.mount > 1.041s sys-kernel-debug.mount > 1.041s dev-hugepages.mount > > Note: I'm not using raid nor lvm and biosdevname package is not > installed. > > Can anyone clarify why does udevadm settle takes so long to finish? > I have the same "issue" ..(not much of a problem actually) it is caused by the LVM activator that (in openSUSE at least) runs even when you are not using lvm.. the units are autogenerated ones.. systemctl mask lvm2-activation.service made the issue go away. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevadm settle takes too long to finish
On Sat, 7 Dec 2013 22:12:38 +0100 "Kay Sievers" wrote: > > Something on your system pulls it in, it should look like: > # systemctl status systemd-udev-settle.service > systemd-udev-settle.service - udev Wait for Complete Device > Initialization Loaded: loaded > (/usr/lib/systemd/system/systemd-udev-settle.service; static) Active: > inactive (dead) Docs: man:udev(7) >man:systemd-udevd.service(8) > > Maybe check in the output of: > systemd-analyze dump > if it shows up somewhere, if you don't find it in the filesystem. > > Kay > >From systemd-analyze dump: Wants: systemd-udevd.service WantedBy: lvm2-activation-early.service WantedBy: lvm2-activation.service Before: lvm2-activation-early.service Before: sysinit.target After: systemd-udev-trigger.service After: systemd-journald.socket References: systemd-udevd.service References: systemd-udev-trigger.service References: sysinit.target References: systemd-journald.socket ReferencedBy: lvm2-activation-early.service ReferencedBy: lvm2-activation.service rmilasan@coolcat:~> systemctl status systemd-udev-settle.service systemd-udev-settle.service - udev Wait for Complete Device Initialization Loaded: loaded (/usr/lib/systemd/system/systemd-udev-settle.service; static) Active: active (exited) since Sat 2013-12-07 21:48:22 CET; 40min ago Docs: man:udev(7) man:systemd-udevd.service(8) Process: 349 ExecStart=/usr/bin/udevadm settle (code=exited, status=0/SUCCESS) Main PID: 349 (code=exited, status=0/SUCCESS) -- Robert Milasan L3 Support Engineer SUSE Linux (http://www.suse.com) email: rmila...@suse.com GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevadm settle takes too long to finish
On Sat, Dec 7, 2013 at 9:51 PM, Robert Milasan wrote: > On Sat, 7 Dec 2013 21:48:14 +0100 > "Kay Sievers" wrote: > >> Then grep all service files for "settle", and find out which one of it >> pulls it in, and then get rid of that package. :) > I've checked and was plymouth the only one to blame for it so I've > dropped it, but still udevadm settle takes the most time: > > rmilasan@coolcat:~> systemd-analyze blame|head > 2.381s systemd-udev-settle.service Something on your system pulls it in, it should look like: # systemctl status systemd-udev-settle.service systemd-udev-settle.service - udev Wait for Complete Device Initialization Loaded: loaded (/usr/lib/systemd/system/systemd-udev-settle.service; static) Active: inactive (dead) Docs: man:udev(7) man:systemd-udevd.service(8) Maybe check in the output of: systemd-analyze dump if it shows up somewhere, if you don't find it in the filesystem. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevadm settle takes too long to finish
On Sat, 7 Dec 2013 21:48:14 +0100 "Kay Sievers" wrote: > > Then grep all service files for "settle", and find out which one of it > pulls it in, and then get rid of that package. :) > > Kay > I've checked and was plymouth the only one to blame for it so I've dropped it, but still udevadm settle takes the most time: rmilasan@coolcat:~> systemd-analyze blame|head 2.381s systemd-udev-settle.service -- Robert Milasan L3 Support Engineer SUSE Linux (http://www.suse.com) email: rmila...@suse.com GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevadm settle takes too long to finish
On Sat, Dec 7, 2013 at 9:32 PM, Robert Milasan wrote: > On Sat, 7 Dec 2013 21:09:39 +0100 > "Kay Sievers" wrote: >> >> It is not used by default, not enabled. >> >> You probably have legacy tools running/installed pulling it in, like >> dmraid installed? If it's something else, grep through the service >> files. You might be able to just get rid of some old stuff, if you >> don't use it. > dmraid is installed, but has nothing to do with systemd nor udev and I > can't remove it. I have no seen any service files or udev rules coming > from dmraid package. Then grep all service files for "settle", and find out which one of it pulls it in, and then get rid of that package. :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevadm settle takes too long to finish
On Sat, 7 Dec 2013 21:09:39 +0100 "Kay Sievers" wrote: > > It is not used by default, not enabled. > > You probably have legacy tools running/installed pulling it in, like > dmraid installed? If it's something else, grep through the service > files. You might be able to just get rid of some old stuff, if you > don't use it. > > Kay > dmraid is installed, but has nothing to do with systemd nor udev and I can't remove it. I have no seen any service files or udev rules coming from dmraid package. -- Robert Milasan L3 Support Engineer SUSE Linux (http://www.suse.com) email: rmila...@suse.com GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevadm settle takes too long to finish
On Sat, Dec 7, 2013 at 8:46 PM, Robert Milasan wrote: > I'm running systemd 208 and I've noticed that the service that > takes the most time to finish is 'systemd-udev-settle.service': > > rmilasan@coolcat:~> systemd-analyze blame|head > 1.890s systemd-udev-settle.service > 1.804s NetworkManager.service > 1.447s ModemManager.service > 1.410s kmod-static-nodes.service > 1.408s systemd-udev-root-symlink.service > 1.042s dev-mqueue.mount > 1.041s sys-kernel-debug.mount > 1.041s dev-hugepages.mount > > Note: I'm not using raid nor lvm and biosdevname package is not > installed. > > Can anyone clarify why does udevadm settle takes so long to finish? It is not used by default, not enabled. You probably have legacy tools running/installed pulling it in, like dmraid installed? If it's something else, grep through the service files. You might be able to just get rid of some old stuff, if you don't use it. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] udevadm settle takes too long to finish
I'm running systemd 208 and I've noticed that the service that takes the most time to finish is 'systemd-udev-settle.service': rmilasan@coolcat:~> systemd-analyze blame|head 1.890s systemd-udev-settle.service 1.804s NetworkManager.service 1.447s ModemManager.service 1.410s kmod-static-nodes.service 1.408s systemd-udev-root-symlink.service 1.042s dev-mqueue.mount 1.041s sys-kernel-debug.mount 1.041s dev-hugepages.mount Note: I'm not using raid nor lvm and biosdevname package is not installed. Can anyone clarify why does udevadm settle takes so long to finish? -- Robert Milasan L3 Support Engineer SUSE Linux (http://www.suse.com) email: rmila...@suse.com GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
