ok I ran this command as sudo and it did work the output was :
Vacuuming done, freed 0B of archived journals from /var/log/journal.
Vacuuming done, freed 0B of archived journals from /run/log/journal.
Deleted archived journal /firstname.lastname@example.org~ (8.0M).
Deleted archived journal /email@example.com (8.0M).
Deleted archived journal /firstname.lastname@example.org~ (8.0M).
Deleted archived journal /email@example.com (16.0M).
Deleted archived journal /firstname.lastname@example.org (8.0M).
Deleted archived journal /email@example.com~ (16.0M).
Deleted archived journal /firstname.lastname@example.org~ (24.0M).
Deleted archived journal /email@example.com~ (8.0M).
Deleted archived journal /firstname.lastname@example.org~ (8.0M).
Deleted archived journal /email@example.com~ (56.0M).
Deleted archived journal /firstname.lastname@example.org~ (80.0M).
Deleted archived journal /email@example.com~ (40.0M).
Deleted archived journal /firstname.lastname@example.org~ (128.0M).
Vacuuming done, freed 408.1M of archived journals from /var/log/journal/41403e33a01f47df84fdd965cca1305e.
OK, df doesk’t show any lvm partitions, so you’re not using it. Go ahead and nuke lvm2-monitor.service.
I suffer from this issue also. I disabled the following services:
- avahi-daemon (service & socket)
I disabled them by “sudo systemctl disable foo” command where “foo” is the name of service to be disabled. However, I did not “mask” any of them …
Does “mask” these service needed to get decrease in booting time ? Do I need to “mask” these services to gain decrease in booting time ?
And, kindly, just issuer me that if I “mask” any of those services, then in future I need to enabled them again, then I should do the following in sequence:
sudo systemctl unmask foo
sudo systemctl start foo
sudo systemctl enable foo
Is the above sequence correct or not ? I imagined the above sequence based upon the fact that when user need to disable service she/he perform the following:
sudo systemctl stop foo
sudo systemctl disable foo
& then after - if need to mask service - should do
sudo systemctl mask foo
Only if these services keep appearing in your systemd-analyze commands (and they do delay your boot).
If you only need to run a service once, unmask it and then start it. If you want it to run automatically, enable it as well.
Enabling the service can be done before or after starting the service, it doesn’t affect running it.
Good questions. If you disable a service, it won’t automatically start at boot, but some other service or program can start it. Masking the service makes it impossible to start. If you think of disabling the service as killing it, masking it is rather like adding, “…and STAY dead!”
And yes, if you’ve masked a service and change your mind, you have to start out by unmasking it.
Thank you for explanation.
Only one concern, you said:
“… but some other service or program can start it.”
Exactly, when this could happened, during booting process or after finishing booting process ?
It could be either. If you’ve disabled a service but another service needs it, that service and still start the disabled one, or if you run a program later that needs it, it can get started. Once you’ve masked it, that can’t happen.
@sideburns I don’t understand what’s happening to my system
I disabled and masked ModemManager.service
Also i cleared old journal logs as @blueshurricane4 said
but this time my system took even more time than before to boot
It took about 2 min 5 sec this time
[nrj@localhost ~]$ systemd-analyze time
Startup finished in 4.201s (firmware) + 3.100s (loader) + 1.710s (kernel) + 5.996s (initrd) + 1min 50.205s (userspace) = 2min 5.214s
graphical.target reached after 1min 50.187s in userspace
Also systemd-journal-flush.service took about 31.9 seconds to complete.
33.117s plymouth-quit-wait.service >
31.912s systemd-journal-flush.service >
20.677s firewalld.service >
17.750s upower.service >
16.587s sssd.service >
14.957s systemd-udev-settle.service >
13.370s udisks2.service >
12.785s libvirtd.service >
9.242s initrd-switch-root.service >
7.892s fwupd.service >
5.631s unbound-anchor.service >
5.580s chronyd.service >
5.180s systemd-udevd.service >
5.128s bolt.service >
4.040s abrtd.service >
3.218s lm_sensors.service >
3.174s packagekit.service >
3.071s avahi-daemon.service >
2.887s switcheroo-control.service >
2.882s bluetooth.service >
2.659s rtkit-daemon.service >
2.651s systemd-homed.service >
2.627s dnf-makecache.service >
2.199s systemd-tmpfiles-setup-dev.service >
2.105s dbus-broker.service >
1.453s systemd-tmpfiles-setup.service >
1.275s systemd-fsck@dev-disk-by\x2duuid-D679\x2d8769.service >
1.118s NetworkManager.service >
1.007s polkit.service >
966ms dracut-initqueue.service >
837ms geoclue.service >
703ms import-state.service >
688ms var-lib-nfs-rpc_pipefs.mount >
637ms gdm.service >
636ms systemd-logind.service >
603ms systemd-sysctl.service >
596ms systemd-journald.service >
585ms dmraid-activation.service >
543ms systemd-udev-trigger.service >
503ms plymouth-switch-root.service >
480ms systemd-rfkill.service >
454ms gssproxy.service >
452ms systemd-userdbd.service >
439ms systemd-backlight@backlight:intel_backlight.service >
420ms rpc-statd-notify.service >
415ms systemd-random-seed.service >
404ms plymouth-read-write.service >
363ms boot-efi.mount >
356ms initrd-parse-etc.service >
308ms systemd-modules-load.service >
307ms systemd-repart.service >
247ms systemd-update-utmp.service >
223ms accounts-daemon.service >
220ms email@example.com >
216ms systemd-vconsole-setup.service >
212ms kmod-static-nodes.service >
205ms systemd-remount-fs.service >
194ms nfs-convert.service >
173ms systemd-fsck-root.service >
161ms dev-hugepages.mount >
160ms dev-mqueue.mount >
159ms sys-kernel-debug.mount >
158ms sys-kernel-tracing.mount >
149ms colord.service >
80ms dracut-cmdline.service >
77ms dracut-shutdown.service >
76ms systemd-user-sessions.service >
75ms dracut-pre-pivot.service >
66ms netcf-transaction.service >
55ms livesys.service >
55ms sys-fs-fuse-connections.mount >
54ms initrd-cleanup.service >
46ms dracut-pre-udev.service >
36ms livesys-late.service >
33ms sysroot.mount >
27ms firstname.lastname@example.org >
17ms plymouth-start.service >
13ms initrd-udevadm-cleanup-db.service >
12ms systemd-update-utmp-runlevel.service >
6ms iscsi-shutdown.service >
5ms tmp.mount >
This was the output of systemd-analyze blame
That’s strange, unless something’s been writing quite a bit to your journal. The plymouth-quit-wait.service doesn’t do anything except wait for boot to complete. Please post the results of
[nrj@localhost ~]$ systemd-analyze critical-chain
The time when unit became active or started is printed after the “@” character.
The time the unit took to start is printed after the “+” character.
graphical.target @1min 32.073s
└─multi-user.target @1min 32.073s
└─plymouth-quit-wait.service @55.992s +36.079s
└─systemd-user-sessions.service @55.819s +130ms
└─sssd.service @40.751s +15.056s
└─dbus-broker.service @40.989s +9.550s
└─systemd-userdbd.service @1min 2.698s +489ms
I suggest the user should have more control over the services active upon installation or even later with a GUI tool, who in all world is still using a analogue modem connected to the PC/Laptop?
What puzzles me is that
sssd.service sticks out like a sore thumb. Are you using this laptop in an enterprise setting (i.e. centralised LDAP or Active Directory login)? If not, you could probably disable
sssd and shave about half a minute off of your boot. I do have to use
sssd for example, but it is up in less than a second (776ms).
Is this a device with spinning disks or SSD?
It’s an HDD.
I just read about sssd.service and what I understood is that it is required when one is using his/her system as a Linux server. Please correct me if I am wrong.
As I am not using my system as a server, should I disable sssd.service also??
Sorry but I didn’t understand what you said.
If you are asking me if I use an analogue modem then no I don’t.
But that’s the point, vitually nobody is using a modem but everybody has this service enabled by default, which is peculiar…
ModemManager handles various types of devices, among them mobile broadband modems. I find it problematic that people recommend to new users to disable a service, without knowing what it actually does.
sssd service is System Security Services Daemon. You only really need it if your system uses external login services. My company laptop, for example, is enrolled in an (Microsoft) Active Directory domain, so in order for me to login with my company credentials, the
sssd service on my laptop handles the authentication/authorisation communication with Active Directory (including Kerberos tickets, etc.).
If you only use your computer as a standalone workstation (or even as a standalone server), then you don’t need
Since you indicate you have an HDD, I guess that that is the bottleneck in your startup sequence. In that case, your best bet is to disable as many startup services in the critical path towards a graphical login screen. Judging from the
systemd-analyze output above, it’s already pretty minimal, except for the
sssd service which you probably don’t need.
Other processes (such as
systemd-journal-flush.service) can be competing for disk access, slowing down the execution of the parallel chain that leads to the graphical login screen. I don’t think there’s much you can do about that…
Many thanks for information about “sssd” service !
How many Linux users do you know that have a broadband modem in their computer and use it?