Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
Dne 01. 07. 20 v 10:29 Zbigniew Jędrzejewski-Szmek napsal(a): On Tue, Jun 30, 2020 at 11:04:26AM +0200, Zdenek Kabelac wrote: Dne 30. 06. 20 v 10:57 Vitaly Zaitsev via devel napsal(a): On 29.06.2020 22:04, Ben Cotton wrote: Fedora only support these RAID sets when they are already configured in the BIOS at installation time. So we can solve the problem of dmraid.service still depending on the obsolete udev-settle service by making dmraid.service disable itself if no supported RAID sets are found on its first run. We also shouldn't be lightly recommending masking or uninstalling of packages because unexperienced users see such recommendations and may follow them without fully understanding what the effect is. Instead, services should be smart enough to exit quickly if they have nothing to manage (which lvm2-monitor already does). And ideally, storage services should only be started in response to hotplug events that detect given hardware type to exist (which apparently could be improved a bit, but as long as the noop cost is small, this is not a such a big issue). Hi And this is exactly what is our lvm2 service doing - it exits when it's being idle for some tens of seconds. Yep I also believe 'default' should just work in most configuration - even when it's not always the top most optimal way to handle things. Then skilled admins should be capable to set more optimal setups. But I also believe making the lvm2 installation more 'optional' would be good thing in making i.e. VM/container images actually smaller - as those often do not need to have these tools & service installed at all - they just got a single storage device to be on. But since currently lot of package now get transient dependecy chains - lvm2 is often sucked-in even when there is clearly no use for it at all. So that's why having better 'package dependency' design matter - and the size and efficiency still is important for some of us Zdenek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Tue, Jun 30, 2020 at 11:04:26AM +0200, Zdenek Kabelac wrote: > Dne 30. 06. 20 v 10:57 Vitaly Zaitsev via devel napsal(a): > >On 29.06.2020 22:04, Ben Cotton wrote: > >>Fedora only support these RAID sets when they are already configured in > >>the BIOS at installation time. So we can solve the problem of > >>dmraid.service still depending on the obsolete udev-settle service by > >>making dmraid.service disable itself if no supported RAID sets are found > >>on its first run. > > > >+1 for this change. > > > >Also the LVM monitor can be disabled too if LVM is not used in current > >Fedora installation. > > > >LVM monitor: -2.01 seconds. > >RAID: -2.41 seconds. > > If the user does not need lvm2, then the package should not be installed/ > However when lvm2 is installed - lvm2 monitoring service is supposed to > be there and enabled - it should not impact load time all that much... [The details have been discussed in some newer messages in the thread, so I'm making just a general comment here:] I don't think uninstalling packages or disabling services is the way to go. Ideally, we should have packages for all frequently used storage stacks installed by default, and all services required to support such stacks also enabled by default when installed. Having things "just work" by default makes the user experience vastly better. We also shouldn't be lightly recommending masking or uninstalling of packages because unexperienced users see such recommendations and may follow them without fully understanding what the effect is. Instead, services should be smart enough to exit quickly if they have nothing to manage (which lvm2-monitor already does). And ideally, storage services should only be started in response to hotplug events that detect given hardware type to exist (which apparently could be improved a bit, but as long as the noop cost is small, this is not a such a big issue). Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disabling lvm2-monitor.service (was Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal)
Dne 30. 06. 20 v 14:08 Hans de Goede napsal(a): Hi, On 6/30/20 1:27 PM, Zdenek Kabelac wrote: Dne 30. 06. 20 v 12:43 Hans de Goede napsal(a): Hi, On 6/30/20 12:27 PM, Zdenek Kabelac wrote: Dne 30. 06. 20 v 12:18 Hans de Goede napsal(a): Hi, On 6/30/20 11:42 AM, Zdenek Kabelac wrote: Dne 30. 06. 20 v 11:34 Vitaly Zaitsev via devel napsal(a): On 30.06.2020 11:23, Igor Raits wrote: Sadly you can't have lvm2 not installed: Yes, but it can be disabled. I'm sorry but e.g. dmraid-activation still running on every Fedora Workstation install, instead of it being event activated does not give the impression of you paying attention. Yes - you are most likely missing that 'lvm2-monitoring' does something only when it's in-use. Ok, so I just checked an you are right, in my memory I was disabling this because it kept a running process around doing nothing, but now I see: [hans@x1 ~]$ sudo systemctl status lvm2-monitor.service ● lvm2-monitor.service - Monitoring of LVM2 mirrors, snapshots etc. using dmeve> Loaded: loaded (/usr/lib/systemd/system/lvm2-monitor.service; enabled; ven> Active: active (exited) since Tue 2020-06-30 10:37:37 CEST; 3h 20min ago Docs: man:dmeventd(8) man:lvcreate(8) man:lvchange(8) man:vgchange(8) Main PID: 903 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 18803) Memory: 0B CPU: 0 CGroup: /system.slice/lvm2-monitor.service Ideally this would not start at all when not necessary, but yes there is lower hanging fruit, sorry for the noise. > Well there can be some extras bit of settings tuned slightly better - but overall I believe we do a pretty good here - service is automatically exiting also when last user goes away for a longer period of time - so really lvm2-monitoring as long as is not in-use shouldn't be bothering users. For me lvm2-monitor.service quickly exits using just 34mS CPU time. ATM we are not recommending users to enable services themselves once the come to conclusion they need it - we consider them granted from installation of package. 1.) If the user does not need lvm2 - it should not be installed. Well this one is a bit tricky, for one because even basic lvm support (just VGs and LVs and nothing else) brings in support for all the other less basic features which lvm/dm has. And with livecd installs, the package-set which is on the livecd is also what will end up being installed, even if the user has chosen to use a raw partition (note since lvm is the default this is not a big issue I guess). It's probably still valuable to i.e. get notification in syslog about full snapshot or thin-pool - so I'd say 34mS is reasonable compromise, compared with the complexity we would have put on users to play with services themself. But it's good we came to conclusion lvm2-monitor service is not a problem ;) Regards Zdenek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disabling lvm2-monitor.service (was Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal)
Hi, On 6/30/20 1:27 PM, Zdenek Kabelac wrote: Dne 30. 06. 20 v 12:43 Hans de Goede napsal(a): Hi, On 6/30/20 12:27 PM, Zdenek Kabelac wrote: Dne 30. 06. 20 v 12:18 Hans de Goede napsal(a): Hi, On 6/30/20 11:42 AM, Zdenek Kabelac wrote: Dne 30. 06. 20 v 11:34 Vitaly Zaitsev via devel napsal(a): On 30.06.2020 11:23, Igor Raits wrote: Sadly you can't have lvm2 not installed: Yes, but it can be disabled. I'm sorry but e.g. dmraid-activation still running on every Fedora Workstation install, instead of it being event activated does not give the impression of you paying attention. Hi dmraid has been obsoleted already many Fedoras back - why it's still installed on any LiveCD I've no idea... AFAIK dmraid can probably handle a few very exotic hw raid devices which are not supported by mdraid. But as said dmraid has been put into dust many years back, and there is zero activity put into this package. Hmm, well on one hand that is good to know OTOH I'm pretty sure that if we drop it we will cause issues for some users who rely on it, it is basically needed for any kind of BIOS/firmware RAID which is not Intel BIOS/firmware RAID. So it is e.g. needed for AMD BIOS/firmware RAID. Unless this has changed ? But problems need to be solved properly - not by 'ad-hock' hijacking correct configuration. On a default Fedora install with typically either a single sata or NVME disk, with a VG with a single PV on that single disk + 3 LVs for / /home and swap, lvm2-monitor.service is simply not necessary. It does not do do anything useful as per the dmeventd manpage. On default - UNTIL lvm2 command contacts monitoring and asks to monitor a device, moniting service does precisely nothing - so nothing is really wasted in terms of CPU cycles. BTW - if someone really DOES care about CPU - I'd probably recommend to focus on packages like dnf/rpm/Firefox/Chrome/Thunderbird/cups and lot's of other where the amount of wasted energy is really high - and I can continue with large amount of network traffic with package upgrading... but let's not side-track this discussion too much. In this case disk failure simply is fatal, as it is with a raw partition install and there is no provisioning / snapshotting which can run out of overcomitted diskspace. Have I misunderstood something here, is my analysis correct that in this case starting dmeventd has 0 added value ? Yes - you are most likely missing that 'lvm2-monitoring' does something only when it's in-use. Ok, so I just checked an you are right, in my memory I was disabling this because it kept a running process around doing nothing, but now I see: [hans@x1 ~]$ sudo systemctl status lvm2-monitor.service ● lvm2-monitor.service - Monitoring of LVM2 mirrors, snapshots etc. using dmeve> Loaded: loaded (/usr/lib/systemd/system/lvm2-monitor.service; enabled; ven> Active: active (exited) since Tue 2020-06-30 10:37:37 CEST; 3h 20min ago Docs: man:dmeventd(8) man:lvcreate(8) man:lvchange(8) man:vgchange(8) Main PID: 903 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 18803) Memory: 0B CPU: 0 CGroup: /system.slice/lvm2-monitor.service Ideally this would not start at all when not necessary, but yes there is lower hanging fruit, sorry for the noise. In the old history days without the systemd world - these monitoring service were forked exactly at the moment user has activated them - now in the systemd world where the services are supposed to be handled by systemd - lvm2 simply follows given rules - and we have the service which is contacted by lvm2 and service starts to work at the moment there is something to monitor. Well it does start, only to immediately exit afterwards, which is ok, but as mentioned ideally it would not start at all. But I agree that there are bigger things to worry about then this. With that said I can file a bug for this if you think that that will help. Yes please - if you have a system which does not need monitoring and the monitoring slows down your boot considerably - then surely open BZ. It should not be happening and it's likely a bug somewhere. But that needs logs & analysis. So I was under the impressions that dmeventd (or some other process) was always running, but I was wrong (and/or things have changed since I last checked), sorry. For me lvm2-monitor.service quickly exits using just 34mS CPU time. monitoring of non-existent raid-sets and non-existent thin-provisioning should be disabled. The problem is that the lvm2-monitor.service runs even if there are no dm raid sets and no thin-provisioning/snapshotting clearly in that case the right thing would be to not run it? ATM we are not recommending users to enable services themselves once the come to conclusion they need it - we consider them granted from installation of package. 1.) If the user does not need lvm2 - it should not be installed. Well this one is a b
Re: Disabling lvm2-monitor.service (was Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal)
Dne 30. 06. 20 v 12:43 Hans de Goede napsal(a): Hi, On 6/30/20 12:27 PM, Zdenek Kabelac wrote: Dne 30. 06. 20 v 12:18 Hans de Goede napsal(a): Hi, On 6/30/20 11:42 AM, Zdenek Kabelac wrote: Dne 30. 06. 20 v 11:34 Vitaly Zaitsev via devel napsal(a): On 30.06.2020 11:23, Igor Raits wrote: Sadly you can't have lvm2 not installed: Yes, but it can be disabled. I'm sorry but e.g. dmraid-activation still running on every Fedora Workstation install, instead of it being event activated does not give the impression of you paying attention. Hi dmraid has been obsoleted already many Fedoras back - why it's still installed on any LiveCD I've no idea... AFAIK dmraid can probably handle a few very exotic hw raid devices which are not supported by mdraid. But as said dmraid has been put into dust many years back, and there is zero activity put into this package. But problems need to be solved properly - not by 'ad-hock' hijacking correct configuration. On a default Fedora install with typically either a single sata or NVME disk, with a VG with a single PV on that single disk + 3 LVs for / /home and swap, lvm2-monitor.service is simply not necessary. It does not do do anything useful as per the dmeventd manpage. On default - UNTIL lvm2 command contacts monitoring and asks to monitor a device, moniting service does precisely nothing - so nothing is really wasted in terms of CPU cycles. BTW - if someone really DOES care about CPU - I'd probably recommend to focus on packages like dnf/rpm/Firefox/Chrome/Thunderbird/cups and lot's of other where the amount of wasted energy is really high - and I can continue with large amount of network traffic with package upgrading... but let's not side-track this discussion too much. In this case disk failure simply is fatal, as it is with a raw partition install and there is no provisioning / snapshotting which can run out of overcomitted diskspace. Have I misunderstood something here, is my analysis correct that in this case starting dmeventd has 0 added value ? Yes - you are most likely missing that 'lvm2-monitoring' does something only when it's in-use. In the old history days without the systemd world - these monitoring service were forked exactly at the moment user has activated them - now in the systemd world where the services are supposed to be handled by systemd - lvm2 simply follows given rules - and we have the service which is contacted by lvm2 and service starts to work at the moment there is something to monitor. Has this design changed again? AFAIK there is nothing wasted - service is there (just like gazzilion of other systemd services nowadays). As mentioned before - if someone is worried about having systemd lvm2 monitoring service in the system - he likely doesn't want to have lvm2 on his system at all - then the correct fix is to make sure - packages are properly packaged in a way they also work without lvm2 installed on system. What is surely not our plan is that with each activation lvm2 command would be reevaulating systemd services and would be notifying users that their systems needs service enabling - lvm2 considers user has simply prohibited monitoring - such usage is supported - user will just miss important modification or some functionality. Installed lvm2 simply means present lvm2 services - nothing more nothing less. Maybe we could provide some 'explicit' package for such services - but we would surely like to have such package installed by default. But this is not about udev-settle, this is about lvm2-monitor.service running on millions of systems where it really is not necessary. IMHO see the above where the energy (and outcomes) are way more valuable With that said I can file a bug for this if you think that that will help. Yes please - if you have a system which does not need monitoring and the monitoring slows down your boot considerably - then surely open BZ. It should not be happening and it's likely a bug somewhere. But that needs logs & analysis. monitoring of non-existent raid-sets and non-existent thin-provisioning should be disabled. The problem is that the lvm2-monitor.service runs even if there are no dm raid sets and no thin-provisioning/snapshotting clearly in that case the right thing would be to not run it? ATM we are not recommending users to enable services themselves once the come to conclusion they need it - we consider them granted from installation of package. 1.) If the user does not need lvm2 - it should not be installed. 2.) If the skilled! user is 100% sure he does not need monitoring while he uses lvm2 - he can disable service - that's out current default view. If there something is wrong in those 2 statements - let's open BZ and discuss the issues. Zdenek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code
Re: Disabling lvm2-monitor.service (was Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal)
Hi, On 6/30/20 12:27 PM, Zdenek Kabelac wrote: Dne 30. 06. 20 v 12:18 Hans de Goede napsal(a): Hi, On 6/30/20 11:42 AM, Zdenek Kabelac wrote: Dne 30. 06. 20 v 11:34 Vitaly Zaitsev via devel napsal(a): On 30.06.2020 11:23, Igor Raits wrote: Sadly you can't have lvm2 not installed: Yes, but it can be disabled. Of course, you can disable this yourself if you are skilled admin and you do not need it or use it (you can mask it which is even better). Default for unskilled users who may use lvm2 - should remain enabled. So I just did some research on this and the lvm2-monitor.service name is somewhat misleading. This service starts dmeventd (through lvm commands) and on most normal lvm setups, as we create them with anaconda's default auto-partitioning dmeventd is not necessary at all. Actually I use the auto-partitioning on all my systems and I always disable lvm2-monitor.service without any bad side-effects. man dmeventd helps a lot here, dmeventd monitors events on devices used by device-mapper and acts on them through plugins the following plugins are available (see man dmeventd and then the "LVM PLUGINS" section) : mirrorring/raid -> In this case dmeventd attempts to handle device failure, this is definitely good to have but only if mirroring/raid is used, which in practice means that dmraid is used. snapshot/thin/vdo -> dmeventd monitors if the storage pool is running out of space and if it is it sends a warning to syslog. This maybe is somewhat useful but only in combination with another monitoring system monitoring syslog for these messages and pro-actively contacting the admin; and this is only relevant if snapshot/thin/vdo lvm features are used, which in a default Fedora install they are not. So this is a third case (next to dmraid and device-mapper-multipath) of a device-mapper/lvm related service which is always starting itself (taking time and resources) needlessly on 99.9% of all Fedora workstation installs. I really wish that the lvm/device-mapper team would pay more attention to this. As Lennart mentioned in the thread, the dmraid issue has been a known issue for 10 years now and dmraid really need to be changed to be activated based on blkid results rather then always start and scan all disks. My proposal for now for the lvm2-monitor.service is to change the Workstation pre`set to disabled and to make dmraid-activation.service have a Requires= on it. This way for dmraid setups we keep the code attempting to deal with disk-failure. As for snapshot/thin/vdo we do not use that by default in Fedora workstation and as mentioned logging a warning to syslog is not all that useful anyways unless additional manual setup is done to automatically monitor syslog for this, in which case enabling the service is just a tiny extra step when already manually setting up the monitoring. Hi Of course we DO PAY attention (me being member of lvm2 team)! I'm sorry but e.g. dmraid-activation still running on every Fedora Workstation install, instead of it being event activated does not give the impression of you paying attention. But problems need to be solved properly - not by 'ad-hock' hijacking correct configuration. On a default Fedora install with typically either a single sata or NVME disk, with a VG with a single PV on that single disk + 3 LVs for / /home and swap, lvm2-monitor.service is simply not necessary. It does not do do anything useful as per the dmeventd manpage. In this case disk failure simply is fatal, as it is with a raw partition install and there is no provisioning / snapshotting which can run out of overcomitted diskspace. Have I misunderstood something here, is my analysis correct that in this case starting dmeventd has 0 added value ? There are many different types of configuration and each need to be taken care separately. ATM - if you do not have lvmetad (which has been used on older Fedoras for auto-actvation) there should not be a settle dependency on your boot path. dmraid and device-mapper-multipath (bot also lvm2 team projects) both bring in systemd-udev-settle.service. The plan for those for livecds is to have anaconda disable them if they are unused, see the dmraid thread. But this is not about udev-settle, this is about lvm2-monitor.service running on millions of systems where it really is not necessary. So if we want to track this out properly - I'd simply highly recommend to open BZ for the issue and provide correct logs for analysis. There are no case specific logs here any default Fedora Workstation install has lvm2-monitor.service running, where as I tried to explain above with the lvm features used by the default install, this is not necessary and has 0 added value. With that said I can file a bug for this if you think that that will help. It's not solving any issue if you just stating 'monitoring should be disable by default' - as monitoring itself should simply not slow down anything and for some use case it's prett
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On 30.06.2020 12:16, Zdenek Kabelac wrote: > The right plan is to fix all packaged dependencies and allow > installation of packages without lvm2. +1. This will be the best solution, I think. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disabling lvm2-monitor.service (was Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal)
Dne 30. 06. 20 v 12:18 Hans de Goede napsal(a): Hi, On 6/30/20 11:42 AM, Zdenek Kabelac wrote: Dne 30. 06. 20 v 11:34 Vitaly Zaitsev via devel napsal(a): On 30.06.2020 11:23, Igor Raits wrote: Sadly you can't have lvm2 not installed: Yes, but it can be disabled. Of course, you can disable this yourself if you are skilled admin and you do not need it or use it (you can mask it which is even better). Default for unskilled users who may use lvm2 - should remain enabled. So I just did some research on this and the lvm2-monitor.service name is somewhat misleading. This service starts dmeventd (through lvm commands) and on most normal lvm setups, as we create them with anaconda's default auto-partitioning dmeventd is not necessary at all. Actually I use the auto-partitioning on all my systems and I always disable lvm2-monitor.service without any bad side-effects. man dmeventd helps a lot here, dmeventd monitors events on devices used by device-mapper and acts on them through plugins the following plugins are available (see man dmeventd and then the "LVM PLUGINS" section) : mirrorring/raid -> In this case dmeventd attempts to handle device failure, this is definitely good to have but only if mirroring/raid is used, which in practice means that dmraid is used. snapshot/thin/vdo -> dmeventd monitors if the storage pool is running out of space and if it is it sends a warning to syslog. This maybe is somewhat useful but only in combination with another monitoring system monitoring syslog for these messages and pro-actively contacting the admin; and this is only relevant if snapshot/thin/vdo lvm features are used, which in a default Fedora install they are not. So this is a third case (next to dmraid and device-mapper-multipath) of a device-mapper/lvm related service which is always starting itself (taking time and resources) needlessly on 99.9% of all Fedora workstation installs. I really wish that the lvm/device-mapper team would pay more attention to this. As Lennart mentioned in the thread, the dmraid issue has been a known issue for 10 years now and dmraid really need to be changed to be activated based on blkid results rather then always start and scan all disks. My proposal for now for the lvm2-monitor.service is to change the Workstation pre`set to disabled and to make dmraid-activation.service have a Requires= on it. This way for dmraid setups we keep the code attempting to deal with disk-failure. As for snapshot/thin/vdo we do not use that by default in Fedora workstation and as mentioned logging a warning to syslog is not all that useful anyways unless additional manual setup is done to automatically monitor syslog for this, in which case enabling the service is just a tiny extra step when already manually setting up the monitoring. Hi Of course we DO PAY attention (me being member of lvm2 team)! But problems need to be solved properly - not by 'ad-hock' hijacking correct configuration. There are many different types of configuration and each need to be taken care separately. ATM - if you do not have lvmetad (which has been used on older Fedoras for auto-actvation) there should not be a settle dependency on your boot path. So if we want to track this out properly - I'd simply highly recommend to open BZ for the issue and provide correct logs for analysis. It's not solving any issue if you just stating 'monitoring should be disable by default' - as monitoring itself should simply not slow down anything and for some use case it's pretty mandatory to have this service enabled. Zdenek. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disabling lvm2-monitor.service (was Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal)
Hi, On 6/30/20 11:42 AM, Zdenek Kabelac wrote: Dne 30. 06. 20 v 11:34 Vitaly Zaitsev via devel napsal(a): On 30.06.2020 11:23, Igor Raits wrote: Sadly you can't have lvm2 not installed: Yes, but it can be disabled. Of course, you can disable this yourself if you are skilled admin and you do not need it or use it (you can mask it which is even better). Default for unskilled users who may use lvm2 - should remain enabled. So I just did some research on this and the lvm2-monitor.service name is somewhat misleading. This service starts dmeventd (through lvm commands) and on most normal lvm setups, as we create them with anaconda's default auto-partitioning dmeventd is not necessary at all. Actually I use the auto-partitioning on all my systems and I always disable lvm2-monitor.service without any bad side-effects. man dmeventd helps a lot here, dmeventd monitors events on devices used by device-mapper and acts on them through plugins the following plugins are available (see man dmeventd and then the "LVM PLUGINS" section) : mirrorring/raid -> In this case dmeventd attempts to handle device failure, this is definitely good to have but only if mirroring/raid is used, which in practice means that dmraid is used. snapshot/thin/vdo -> dmeventd monitors if the storage pool is running out of space and if it is it sends a warning to syslog. This maybe is somewhat useful but only in combination with another monitoring system monitoring syslog for these messages and pro-actively contacting the admin; and this is only relevant if snapshot/thin/vdo lvm features are used, which in a default Fedora install they are not. So this is a third case (next to dmraid and device-mapper-multipath) of a device-mapper/lvm related service which is always starting itself (taking time and resources) needlessly on 99.9% of all Fedora workstation installs. I really wish that the lvm/device-mapper team would pay more attention to this. As Lennart mentioned in the thread, the dmraid issue has been a known issue for 10 years now and dmraid really need to be changed to be activated based on blkid results rather then always start and scan all disks. My proposal for now for the lvm2-monitor.service is to change the Workstation pre`set to disabled and to make dmraid-activation.service have a Requires= on it. This way for dmraid setups we keep the code attempting to deal with disk-failure. As for snapshot/thin/vdo we do not use that by default in Fedora workstation and as mentioned logging a warning to syslog is not all that useful anyways unless additional manual setup is done to automatically monitor syslog for this, in which case enabling the service is just a tiny extra step when already manually setting up the monitoring. Regards, Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
Dne 30. 06. 20 v 11:53 Vitaly Zaitsev via devel napsal(a): On 30.06.2020 11:42, Zdenek Kabelac wrote: Default for unskilled users who may use lvm2 - should remain enabled. If LVM was not used during installation => Anakonda can automatically disable it. Hmm - I don't think this is a good plan - it would be then different how the package is installed. The right plan is to fix all packaged dependencies and allow installation of packages without lvm2. If lvm2 is installed on system - it should have one 'default' installed configation. What you are proposing is - when user would deploy lvm2 DURING anaconda time - it would behave the way A), but if user would just attach lvm2 storage later one - it would behave in a way B). So personally - the only way is to have fixed inter-package deps - and when user does not want to have lvm2 on his system - he simply should not be installing it - that's IMHO the correct solution here. Zdenek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On 30.06.2020 11:42, Zdenek Kabelac wrote: > Default for unskilled users who may use lvm2 - should remain enabled. If LVM was not used during installation => Anakonda can automatically disable it. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
Dne 30. 06. 20 v 11:34 Vitaly Zaitsev via devel napsal(a): On 30.06.2020 11:23, Igor Raits wrote: Sadly you can't have lvm2 not installed: Yes, but it can be disabled. Of course, you can disable this yourself if you are skilled admin and you do not need it or use it (you can mask it which is even better). Default for unskilled users who may use lvm2 - should remain enabled. Zdenek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On 30.06.2020 11:23, Igor Raits wrote: > Sadly you can't have lvm2 not installed: Yes, but it can be disabled. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-30 at 11:04 +0200, Zdenek Kabelac wrote: > Dne 30. 06. 20 v 10:57 Vitaly Zaitsev via devel napsal(a): > > On 29.06.2020 22:04, Ben Cotton wrote: > > > Fedora only support these RAID sets when they are already > > > configured in > > > the BIOS at installation time. So we can solve the problem of > > > dmraid.service still depending on the obsolete udev-settle > > > service by > > > making dmraid.service disable itself if no supported RAID sets > > > are found > > > on its first run. > > > > +1 for this change. > > > > Also the LVM monitor can be disabled too if LVM is not used in > > current > > Fedora installation. > > > > LVM monitor: -2.01 seconds. > > RAID: -2.41 seconds. > > If the user does not need lvm2, then the package should not be > installed/ > However when lvm2 is installed - lvm2 monitoring service is supposed > to > be there and enabled - it should not impact load time all that > much... ❯ systemd-analyze blame | grep lvm 4.103s lvm2-monitor.service Sadly you can't have lvm2 not installed: lvm2 is needed by (installed) libvirt-daemon-driver-storage- logical-6.4.0-1.fc33.x86_64 that is required by other libvirt stuff which ends up with gnome-boxes. > > Zdenek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl77BK0ACgkQEV1auJxc Hh4V8hAApS1m1x4gqE66qQZuf81bcHPU3wTYYgLvzqVr69eq25hzu1pIQDT1oXJH WgHuucYKCQjr2JO9dv2Amil0hNlnrRP6AONJ28f22xUnUHoM93vYi7Y6Ba5sbGh6 31DRf5FEgfcBODXmB4XVGm2vXxlWeMYVnR9ujKHvnl/8ODrI6jLrvIDl02rFq3eT Gym144modLy6cKVaUBRO8q6n26A8wHXKQ+9Gj7h95c5vHZzZd3QReITxsim+Lxee 3iVPI7sRPI6VYZFvtsG+sLJgQlUvrcD1pjkCUJDwIPQG8cnvmfUk8L1TtDOfeRZK Uzn/NQgx8WNAcpOJtE3PrqDLRQl7jVHwulwXP+181RYSAeuX5z69qXZZ+7kq2lVh OtTRKQbfed2VYdrd0emOizZH92zGNR8gtJ4PkCu3ThWEaYnH3eJ5r8FM/znoFOI1 P+rkllVce8AJ0+V+ZJOR3/hLQSN8bcOREm9shxWz7TixUPbkzsRUh4EAWamznyKL ZUHQbv9MZZ5HEvw2+7Ukb8tULsXNBWm1mSMVMhE92XueTaavAkY6E1iPmWaZ1R7y Tvmh1Gmq6Hk/DNb6qQtBPESKHGT9Y4T+8wbKDm8YilotwEZpQ0B1T7W/oTS+ZHKu 0woM7DnULdbtGaPcH1DM+3Q9XTkDWTbxVF3kG90f6oKezSpmntg= =hlFt -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On 30.06.2020 11:04, Zdenek Kabelac wrote: > If the user does not need lvm2, then the package should not be installed/ > However when lvm2 is installed - lvm2 monitoring service is supposed to > be there and enabled - it should not impact load time all that much... I use classic partitions, but lvm2-monitor.service is still enabled: 2.129s lvm2-monitor.service -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Mo, 29.06.20 16:04, Ben Cotton (bcot...@redhat.com) wrote: > https://fedoraproject.org/wiki/Changes/DisableDmraidOnFirstRun > > == Summary == > The Fedora workstation livecd is the default Fedora variant getfedora.org > advices people to download. > As such most Fedora workstation installs will be done from the livecd. This > means that any package which is part of the livecd will be part of the > default install for most users. > > Dmraid is 1 of only 2 packages in the default install which still Requires > the long obsoleted systemd-udev-settle.service, which waits for all > device-detection to be done + some extra waiting just to be sure. This > significantly slows down booting on various systems. Oh yes, please remove this. It's a shame that dmraid still requires this, it's broken since 10 years to do this, and the maintainers know it. The dmraid people had ample time to fix their code. It's really time this has to go. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Tue, Jun 30, 2020 at 10:30 AM José Abílio Matos wrote: > > IIRC this is probably related with the dependencies of anaconda: Is there an easy suggestion we can make to our users other than play with "rpm -e" or nuking dnf's database? There's a bunch of threads over at askfedora where people are killing services left and right, without knowing what they do, in order to shave off a few milliseconds. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
Dne 30. 06. 20 v 10:57 Vitaly Zaitsev via devel napsal(a): On 29.06.2020 22:04, Ben Cotton wrote: Fedora only support these RAID sets when they are already configured in the BIOS at installation time. So we can solve the problem of dmraid.service still depending on the obsolete udev-settle service by making dmraid.service disable itself if no supported RAID sets are found on its first run. +1 for this change. Also the LVM monitor can be disabled too if LVM is not used in current Fedora installation. LVM monitor: -2.01 seconds. RAID: -2.41 seconds. If the user does not need lvm2, then the package should not be installed/ However when lvm2 is installed - lvm2 monitoring service is supposed to be there and enabled - it should not impact load time all that much... Zdenek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On 29.06.2020 22:04, Ben Cotton wrote: > Fedora only support these RAID sets when they are already configured in > the BIOS at installation time. So we can solve the problem of > dmraid.service still depending on the obsolete udev-settle service by > making dmraid.service disable itself if no supported RAID sets are found > on its first run. +1 for this change. Also the LVM monitor can be disabled too if LVM is not used in current Fedora installation. LVM monitor: -2.01 seconds. RAID: -2.41 seconds. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
Hi, On 6/30/20 12:59 AM, Michael Catanzaro wrote: On Mon, Jun 29, 2020 at 3:37 pm, Samuel Sieb wrote: But that should be running concurrently. Does the plot show anything important waiting for it? Your desktop should be able to load before that service is finished starting. Well notably: plymouth-quit-wait.service. Surely plymouth keeps running until everything else has finished, right? plymouth-quit-wait.service is special. On gdm startup the following happens: 1. gdm tells plymouth to deactivate, at this point it release its drm-master ownership of /dev/dri/card0, but does keep it open because otherwise the kernel will automatically free the framebuffer installed by plymouth and that would cause a flicker 2. gdm starts the greeter session 3. the greeter session lets gdm know that it has fully started, this means that gdm now knows that either Xorg or mutter(Wayland) has /dev/dri/card0 open and has installed its own framebuffer 4. gdm tells plymouth it is ok to quit know (and thus close /dev/dri/card0) Step 2 / reaching step 3. is what can take a long time here. This should normally not be dependent on NetworkManager-wait-online.service though. I guess the two just overlap. Regards, Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Tuesday, 30 June 2020 00.56.23 WEST Alexander Ploumistos wrote: > I just tested it on F32 Workstation and for me it does. Have you > cleaned dnf's databases by any chance? I think either that or having > the packages as dependencies of something that was installed by the > user would prevent them from going away with dmraid. IIRC this is probably related with the dependencies of anaconda: # repoquery --whatrequires 'dmraid' --recursive Last metadata expiration check: 0:14:34 ago on Tue 30 Jun 2020 09:14:30 AM WEST. anaconda-0:32.24.5-1.fc32.x86_64 anaconda-0:32.24.7-1.fc32.x86_64 anaconda-0:32.24.7-2.fc32.x86_64 anaconda-install-env-deps-0:32.24.5-1.fc32.x86_64 anaconda-install-env-deps-0:32.24.7-1.fc32.x86_64 anaconda-install-env-deps-0:32.24.7-2.fc32.x86_64 anaconda-realmd-0:0.2-12.fc32.noarch dmraid-0:1.0.0.rc16-44.fc32.i686 dmraid-0:1.0.0.rc16-44.fc32.x86_64 dmraid-devel-0:1.0.0.rc16-44.fc32.x86_64 dmraid-events-0:1.0.0.rc16-44.fc32.x86_64 dmraid-events-logwatch-0:1.0.0.rc16-44.fc32.x86_64 kdump-anaconda-addon-0:005-8.20200220git80aab11.fc32.noarch libblockdev-dm-0:2.23-2.fc32.i686 libblockdev-dm-0:2.23-2.fc32.x86_64 libblockdev-dm-0:2.24-1.fc32.i686 libblockdev-dm-0:2.24-1.fc32.x86_64 libblockdev-dm-devel-0:2.23-2.fc32.i686 libblockdev-dm-devel-0:2.23-2.fc32.x86_64 libblockdev-dm-devel-0:2.24-1.fc32.i686 libblockdev-dm-devel-0:2.24-1.fc32.x86_64 libblockdev-plugins-all-0:2.23-2.fc32.x86_64 libblockdev-plugins-all-0:2.24-1.fc32.x86_64 oscap-anaconda-addon-0:1.0-6.fc32.noarch -- José Abílio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Tuesday, 30 June 2020 00.56.23 WEST Alexander Ploumistos wrote: > I just tested it on F32 Workstation and for me it does. Have you > cleaned dnf's databases by any chance? I think either that or having > the packages as dependencies of something that was installed by the > user would prevent them from going away with dmraid. I tried a reverse stance, notice that I have all the package that you mentioned installed: [root@myth ~]# dnf install gdb dbus-x11 python3-pwquality tigervnc-server-minimal tmux Last metadata expiration check: 0:03:44 ago on Tue 30 Jun 2020 09:14:30 AM WEST. Package gdb-9.1-5.fc32.x86_64 is already installed. Package dbus-x11-1:1.12.18-1.fc32.x86_64 is already installed. Package python3-pwquality-1.4.2-2.fc32.x86_64 is already installed. Package tigervnc-server-minimal-1.10.1-5.fc32.x86_64 is already installed. Package tmux-3.0a-2.fc32.x86_64 is already installed. Dependencies resolved. Nothing to do. Complete! [root@myth ~]# dnf remove dmraid No match for argument: dmraid No packages marked for removal. Dependencies resolved. Nothing to do. Complete! -- José Abílio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Tue, Jun 30, 2020 at 1:35 AM José Abílio Matos wrote: > > On Monday, 29 June 2020 22.23.00 WEST Alexander Ploumistos wrote: > > This tends to take with it many things that it shouldn't, like gdb, > > dbus-x11, python3-pwquality, tigervnc-server-minimal and tmux - among > > others. > > I noticed that before but at least on F32 it does not do it anymore. I have > removed dmraid and I still have gdb and tmux installed. I just tested it on F32 Workstation and for me it does. Have you cleaned dnf's databases by any chance? I think either that or having the packages as dependencies of something that was installed by the user would prevent them from going away with dmraid. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Monday, 29 June 2020 22.23.00 WEST Alexander Ploumistos wrote: > This tends to take with it many things that it shouldn't, like gdb, > dbus-x11, python3-pwquality, tigervnc-server-minimal and tmux - among > others. I noticed that before but at least on F32 it does not do it anymore. I have removed dmraid and I still have gdb and tmux installed. -- José Abílio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On 6/29/20 3:59 PM, Michael Catanzaro wrote: On Mon, Jun 29, 2020 at 3:37 pm, Samuel Sieb wrote: But that should be running concurrently. Does the plot show anything important waiting for it? Your desktop should be able to load before that service is finished starting. Well notably: plymouth-quit-wait.service. Surely plymouth keeps running until everything else has finished, right? I would hope that gdm tells plymouth to go away or starts a new console anyway, but that would be good to find out. There's no reason for anything to be waiting for abrt to finish loading. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Monday, June 29, 2020 1:57:55 PM MST Michael Catanzaro wrote: > On Mon, Jun 29, 2020 at 3:45 pm, Michael Catanzaro > wrote: > > > We might need to explicitly disable systemd-udev-settle.service > > during the system upgrade to turn it off? > > > Doesn't work... I tried 'systemctl disable systemd-udev-settle.service' > and rebooted again, and it's still running. I tried 'systemd-analyze > plot' and I see it takes 11 seconds during boot! I think the culprit is > dmraid-activation.service (not dmraid.service). Did you get the name of > the service wrong in the change proposal, or have I misunderstood? > > Unrelated: looking at my systemd-analyze plot, other startup time > offenders are NetworkManager-wait-online.service (9.5 seconds, seems > egregious, I wonder why this is necessary?) and grand prize winner > abrtd.service (requiring an amazing 30 seconds!) Well, disabling it on upgrade might be fine, so long as you check that it's not actually in use. Please keep in mind that dmraid is required for, for example, Intel firmware RAID, and so simply disabling this would mean that users' workstations or servers using firmware RAID wouldn't be able to boot.. -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Mon, Jun 29, 2020 at 3:37 pm, Samuel Sieb wrote: But that should be running concurrently. Does the plot show anything important waiting for it? Your desktop should be able to load before that service is finished starting. Well notably: plymouth-quit-wait.service. Surely plymouth keeps running until everything else has finished, right? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On 6/29/20 1:57 PM, Michael Catanzaro wrote: On Mon, Jun 29, 2020 at 3:45 pm, Michael Catanzaro wrote: We might need to explicitly disable systemd-udev-settle.service during the system upgrade to turn it off? Doesn't work... I tried 'systemctl disable systemd-udev-settle.service' and rebooted again, and it's still running. I tried 'systemd-analyze plot' and I see it takes 11 seconds during boot! I think the culprit is dmraid-activation.service (not dmraid.service). Did you get the name of the service wrong in the change proposal, or have I misunderstood? Unrelated: looking at my systemd-analyze plot, other startup time offenders are NetworkManager-wait-online.service (9.5 seconds, seems egregious, I wonder why this is necessary?) and grand prize winner abrtd.service (requiring an amazing 30 seconds!) But that should be running concurrently. Does the plot show anything important waiting for it? Your desktop should be able to load before that service is finished starting. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Mon, Jun 29, 2020 at 11:09 PM Hans de Goede wrote: > > I fix this on my > own systems with "dnf remove dmraid" This tends to take with it many things that it shouldn't, like gdb, dbus-x11, python3-pwquality, tigervnc-server-minimal and tmux - among others. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Mon, Jun 29, 2020 at 11:09 pm, Hans de Goede wrote: I got the name of the unit wrong in the change proposal, sorry. I fix this on my own systems with "dnf remove dmraid", but unlike multipath some desktop machines may actually have a BIOS/firmware RAID set configured which needs dmraid and we do want to support those setups with the workstation livecd. I'll re-install dmraid and correct the proposal text when I can find some time for that. OK cool. I just wanted to add, I tested and confirmed that if I 'systemctl disable dmraid-activation.service', it does indeed cause systemd-udev-settle.service to no longer run, so seems to work nicely. Next, I will test disabling ABRT and confirm we'll boot twice as fast without it. :( ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Mon, Jun 29, 2020 at 2:58 PM Michael Catanzaro wrote: > > On Mon, Jun 29, 2020 at 3:45 pm, Michael Catanzaro > wrote: > > We might need to explicitly disable systemd-udev-settle.service > > during the system upgrade to turn it off? > > Doesn't work... I tried 'systemctl disable systemd-udev-settle.service' > and rebooted again, and it's still running. I tried 'systemd-analyze > plot' and I see it takes 11 seconds during boot! I think the culprit is > dmraid-activation.service (not dmraid.service). Did you get the name of > the service wrong in the change proposal, or have I misunderstood? > > Unrelated: looking at my systemd-analyze plot, other startup time > offenders are NetworkManager-wait-online.service (9.5 seconds, seems > egregious, I wonder why this is necessary?) and grand prize winner > abrtd.service (requiring an amazing 30 seconds!) Many activate and run in parallel, including NetworkManager-wait-online, and don't directly contribute to startup delays. That one should really just be waiting for all the network configuration to really happen before trying things that depend on the network: e.g. NFS and maybe some kind of network login. Some services can stuck much longer if they try to connect before there's a connection available. But yeah all of the enabled by default services probably need a review for F33 to make sure they're intentionally enabled. /me not a fan of startup delays, I really wanna be under 10s. Right now I'm at 19s and that's on NVMe with no external devices or services to connect to. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
Hi, On 6/29/20 10:57 PM, Michael Catanzaro wrote: On Mon, Jun 29, 2020 at 3:45 pm, Michael Catanzaro wrote: We might need to explicitly disable systemd-udev-settle.service during the system upgrade to turn it off? Doesn't work... I tried 'systemctl disable systemd-udev-settle.service' and rebooted again, and it's still running. I tried 'systemd-analyze plot' and I see it takes 11 seconds during boot! I think the culprit is dmraid-activation.service (not dmraid.service). Did you get the name of the service wrong in the change proposal, or have I misunderstood? I got the name of the unit wrong in the change proposal, sorry. I fix this on my own systems with "dnf remove dmraid", but unlike multipath some desktop machines may actually have a BIOS/firmware RAID set configured which needs dmraid and we do want to support those setups with the workstation livecd. I'll re-install dmraid and correct the proposal text when I can find some time for that. Regards, Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Mon, Jun 29, 2020 at 3:45 pm, Michael Catanzaro wrote: We might need to explicitly disable systemd-udev-settle.service during the system upgrade to turn it off? Doesn't work... I tried 'systemctl disable systemd-udev-settle.service' and rebooted again, and it's still running. I tried 'systemd-analyze plot' and I see it takes 11 seconds during boot! I think the culprit is dmraid-activation.service (not dmraid.service). Did you get the name of the service wrong in the change proposal, or have I misunderstood? Unrelated: looking at my systemd-analyze plot, other startup time offenders are NetworkManager-wait-online.service (9.5 seconds, seems egregious, I wonder why this is necessary?) and grand prize winner abrtd.service (requiring an amazing 30 seconds!) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
So, in relation to the device-mapper-multipath change in the other thread, I ran 'sudo dnf remove device-mapper-multipath'. Then I ran 'systemctl status dmraid.service' and saw "Unit dmraid.service could not be found," so I must not have that installed at all. Then I rebooted. When I run 'systemctl status systemd-udev-settle.service' I see it's still active and exited after my reboot. I see the vendor preset is disabled, so I guess it should be OK for fresh installs, but maybe the current proposals won't be enough for upgraded systems? We might need to explicitly disable systemd-udev-settle.service during the system upgrade to turn it off? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Mon, Jun 29, 2020 at 4:05 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/DisableDmraidOnFirstRun > > == Summary == > The Fedora workstation livecd is the default Fedora variant getfedora.org > advices people to download. > As such most Fedora workstation installs will be done from the livecd. This > means that any package which is part of the livecd will be part of the > default install for most users. > > Dmraid is 1 of only 2 packages in the default install which still Requires > the long obsoleted systemd-udev-settle.service, which waits for all > device-detection to be done + some extra waiting just to be sure. This > significantly slows down booting on various systems. > > Fedora only support these RAID sets when they are already configured in the > BIOS at installation time. So we can solve the problem of dmraid.service > still depending on the obsolete udev-settle service by making dmraid.service > disable itself if no supported RAID sets are found on its first run. > Yay! +1 -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Mon, Jun 29, 2020 at 2:06 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/DisableDmraidOnFirstRun > Fedora only support these RAID sets when they are already configured in the > BIOS at installation time. So we can solve the problem of dmraid.service > still depending on the obsolete udev-settle service by making dmraid.service > disable itself if no supported RAID sets are found on its first run. Hurray! +1 -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
https://fedoraproject.org/wiki/Changes/DisableDmraidOnFirstRun == Summary == The Fedora workstation livecd is the default Fedora variant getfedora.org advices people to download. As such most Fedora workstation installs will be done from the livecd. This means that any package which is part of the livecd will be part of the default install for most users. Dmraid is 1 of only 2 packages in the default install which still Requires the long obsoleted systemd-udev-settle.service, which waits for all device-detection to be done + some extra waiting just to be sure. This significantly slows down booting on various systems. Fedora only support these RAID sets when they are already configured in the BIOS at installation time. So we can solve the problem of dmraid.service still depending on the obsolete udev-settle service by making dmraid.service disable itself if no supported RAID sets are found on its first run. == Owner == * Name: [[User:jwrdegoede| Hans de Goede]] * Email: hdego...@redhat.com == Detailed Description == Dmraid is 1 of only 2 packages in the default install which still Requires the long obsoleted systemd-udev-settle.service. The other package is device-mapper-multipath see [[Changes/RemoveDeviceMapperMultipathFromWorkstationLiveCD|Remove device-mapper-multipath from the Fedora workstation livecd]]. Dmraid is necessary to support firmware-raid (motherboard BIOS built-in RAID support) for non Intel firmware RAID sets. These RAID sets are quite rare and we have never supported configuring these RAID sets after the installation without manually setting it up. Since we only support these sets when they are already configured in the BIOS at installation time, we can solve the problem of dmraid.service still depending on the obsolete udev-settle service by making dmraid.service disable itself if no supported RAID sets are found on its first run. Note then when installing from the server or everything netboot isos, dmraid depending on the obsolete udev-settle service is not a problem, because then it will not be installed at all. Anaconda (the installer) adds storage related packages such as dmraid to the installation package-set as necessary for the storage found at installation time. This means that for such installs, if a dmraid set is later configured, the user manually needs to install dmraid to be able to use the RAID set. This change adds a similar requirement to livecd installs, there the user will now need to do a "systemctl enable dmraid.service" if a dmraid set is added to the system later. There has been [https://bugzilla.redhat.com/show_bug.cgi?id=1795014 a bug] open against dmraid for this issue for a while now. As pointed out there, this change can easily be implemented with some small changes to the shell script which gets started by the dmraid service. == Benefit to Fedora == systemd-udev-settle.service causes a significant and sometimes quite long delay during boot. Removing / disabling the last 2 services depending on this long obsolete helper service will remove the unnecessary boot delay. == Scope == * Proposal owners: ** Prepare the suggested dmraid activation script changes and push out a new dmraid package with these changes added ** Coordinate this with the dmraid maintainers * Other developers: ** I will make sure that the dmraid maintainers are aware of and agree with these changes. I will take care of these changes myself. * Release engineering: [https://pagure.io/releng/issue/9559 #9559] (a check of an impact with Release Engineering is needed) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == After upgrading, if no dmraid sets are found on the first boot with the new package, the dmraid service will disable itself, just as it will on new F33 installs. == How To Test == # Install F33 on a machine / VM without dmraid # Boot the installed system # Reboot the installed system # Do "systemctl status dmraid.service", the output should be "loaded (...; disabled; ...)" and "inactive (dead)" == User Experience == Faster booting Fedora when installed from the livecd. == Dependencies == There are no other changes / package updates this Change depends on; or which this change impacts. == Contingency Plan == * Contingency mechanism: Revert the activation script changes if they cause problems * Blocks release? No == Documentation == This change does not require any documentation. -- Ben Cotton He / Him / His Senior Program Manager, Fedora & CentOS Stream Red Hat TZ=America/Indiana/Indianapolis ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/arch
