Since I'm several years late to the party, I'll attempt to answer this more for folks coming in from search engines who are interested in the same service for the same reason (read: possibly future me?).
Note: this was not tested on an ubuntu system but should be distro-agnostic (I'm currently on Fedora if it matters). Last I checked, only questions were to be limited to ubuntu (e.g. answers can be generic/distro-agnostic) and anyway no one has even attempted to answer this in the past 4 years. This answer should be the same for most Linux distro using systemd (including Ubuntu, which I did test a derivitive distro of)
$ systemctl status systemd-udev-settle.service
● systemd-udev-settle.service - Wait for udev To Complete Device Initialization
....
The description provided by the service itself is rather vague and doesn't give much to go on.
From what I saw, there wasn't much information about this service online either.
One comment one debian bug mailing list dated May 2015 described it as:
My searches on systemd-udev-settle masked tell me it is about "fake
block device storage technology" (in my case mdadm - the raid)
Likewise the freedesktop.org systemd optimizations page (updated May 2013) says that:
- Make sure not to use any fake block device storage technology such as LVM (as installed by default by various distributions, including Fedora) they result in the systemd-udev-settle.service unit to be pulled in. Settling device enumeration is slow, racy and mostly obsolete. Since LVM (still) hasn't been updated to handle Linux' event based design properly, settling device enumeration is still required for it, but it will slow down boot substantially. On Fedora, use "systemctl mask fedora-wait-storage.service fedora-storage-init-late.service fedora-storage-init.service" to get rid of all those storage technologies. Of course, don't try this if you actually installed your system with LVM. (The only fake block device storage technology that currently handles this all properly and doesn't require settling device enumerations is LUKS disk encryption.)
From this, I get the impression that like several other services that are enabled by default on
Many of the distros I have tried have lvm2-monitor.service enabled by default which AFAIK is only useful if one is using LVM (for those unfamiliar... this may be a bit of an oversimplification but is somewhat like a software RAID or logic layer that can make several hard-drives pretend to act as if they are one hard drive -- in other words, it is not something that would likely be used by newbies or people who don't even know what LVM is). This is for sure the case in Fedora 33 and Linux Mint 19 and I suspect that it is the same for many many other distros, including ubuntu (it is listed in the OP's systemd-analyze blame output).
Similarly to lvm2-monitor.service, the systemd-udev-settle.service seems to be related to "fake block device storage technology" like LVM. The debian mailing list mentioned it having been disabled on someone's system so disabling it seems unlikely to result in major issues unless one has specifically set up LVM or similar. If you would like to disable it, I would recommend also disabling lvm2-monitor.service if you haven't already.
I am not currently using any LVM stuff in my setup and plan to test disabling it sometime in the next day or so as I get time. I will try to report back with whether any serious issues were encountered / any functionality ceases to work
Update: definitely wasn't anything system critial (didn't affect bootup/login/graphical stuff) and I can still go online/access all my mounted fstab disks just fine. ~~I did notice that my userspace time in systemd-analyze is a tiny bit higher (by 2-4s) but I'm not sure if that value is an average or only the timings for the immediately previous boot. I suspect the latter, in which case it is possible that is just minor but normal fluctuations due to hardware timings (such as fstab mounts coming online, connecting to ethernet, etc).~~
Update 2: This eventually stabilized and was about 1-2s less that my initial timings before messing with services; likely due to minor hardware time fluctuations I mentioned before. I also disabled several other services around the same time I was testing this. The full list of services I disabled on Fedora 33 (which I also tested/disabled on LM20):
# don't run the following if you are booting your os from a
# a networked drive rather than a SSD/HDD
# (very very rare for home users):
sudo systemctl disable NetworkManager-wait-online.service
don't run the following if you use dial-up internet:
sudo systemctl disable pppd-dns.service
don't run the following if you use wifi:
sudo systemctl disable wpa_supplicant.service
don't run the following 2 if you use LVM:
sudo systemctl mask lvm2-monitor.service
sudo systemctl mask systemd-udev-settle.service
Originally, I had also disabled (and masked) accounts-daemon.service as this site had listed it as "a potential security risk". However, after much debugging I eventually found that was directly responsible for breaking my cinnamon-screensaver and cinnamon lock screen under fedora-33 (cinnamon). Oddly, both of those worked just fine under LM-20. Both distros were running Cinnamon 4.8.6 during my testing.
The only clue I had for the above was a log entry in ~/.xsession-errors saying:
(cinnamon-screensaver:2381): accountsservice-WARNING **: 02:43:13.941: ActUserManager: user (null) has no username (uid: -1)
which after much searching, I saw similar error text in this redhat bug report which happened to mention account services and made a lightbulb go off. After running sudo systemctl unmask accounts-daemon.service; sudo systemctl enable accounts-daemon.service; reboot screensaver and lock screen were working fine again.
Update 3: One other thing I will mention as a related topic / that I hinted to in the previous updates is that boot timings can be impacted by hardware. Having your primary OS installed to an SSD will almost always be faster than having it on an HDD, and either of those will almost always be faster than booting off a network share. But even without SSDs, HDD RPMs (revolutions per minute) can be a factor.
But beyond that, let's assume you've installed the OS to whatever the fastest medium available to you is. You could still run into some boot delays if you have other slow responding hardware. I had a dvd drive that was glitchy once and would add about 1 min to my boot times. unplugging it helped tremendously (I can't recall if it was the drive or the cable but it is worth checking both cases). In other setups, I have seen where having many connected HDDs that have mount points defined in /etc/fstab can also cause slow down. If you have additional HDDs, I recommend defining a timeout on them in your fstab, somewhere between 2-10s.
in fstab, i mount with the following options to limit this to at most 3s per HDD (I would recommend keeping it above 2s at least):
# example, this will
# 1. mount the indicated ext4 HDD to /gaming
# 2. if the drive fails/is removed, don't abort the boot process
# 3. if the drive fails/is removed, don't spend more than 3s looking for it
# the default is that systemd will spend up to 90s PER DEVICE
# see https://wiki.archlinux.org/index.php/Fstab
# and https://www.freedesktop.org/software/systemd/man/systemd.mount.html
UUID=<my hdd's uuid> /gaming ext4 defaults,nofail,x-systemd.device-timeout=3s,nodev,user,exec 0 0
something similar but for nfts (e.g. for a windows dual-boot)
UUID=<my other hdd uuid> /media/d ntfs-3g defaults,nofail,x-systemd.device-timeout=3s,windows_names,locale=en_US.utf8,uid=1000 0 0
If you suspect this could be a factor/would like to rule it out. First, write down your current boot time. Then backup your /etc/fstab and comment out everything except the mounts for / and /home (if you have home on a different partition). Power down and unplug all dvd/hdds/usb/etc except for your main drive (and home drive if you have one) and minimum hardware - keyboard + mouse. then boot up and note your new boottime. If it is significantly different, plug things in one at a time until you find the culprit (this is what I had to do to discover my fauly dvd drive/cable).
Sources:
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786942
- https://freedesktop.org/wiki/Software/systemd/Optimizations/
