My workstation took more than a minute to boot into X
$ systemd-analyze time Startup finished in 1.890s (kernel) + 4.702s (initrd) + 1min 20.163s (userspace) = 1min 26.756s graphical.target reached after 58.148s in userspace
By disable plymouth at boot and in the initrd, I got much better result
$ systemd-analyze time Startup finished in 1.911s (kernel) + 4.646s (initrd) + 37.884s (userspace) = 44.442s graphical.target reached after 37.870s in userspace
Pfu.. seem size limit of journal log are almost reaching 2 GB
$ du -h /var/log/journal/ | tail -n 1 1.8G /var/log/journal/
I want to clean this logs. Now flush all journal data from
$ journalctl --flush
Check and verify our logs condition are
$ journalctl --verify
How was the result? Looking good? let’s free some space of archived journal files and only store 1 week logs
$ journalctl --vacuum-size=30M $ journalctl --vacuum-time=1weeks
By default the global journal configuration of The maximum size of the persistent journal aka
SystemMaxUse are commented
$ grep SystemMaxUse /etc/systemd/journald.conf #SystemMaxUse=
You can uncommenting and put some value, eg
SystemMaxUse=30M, but I prefer to use the drop-in snippets configuration override mechanism rather than editing the global configuration file.
$ sudo mkdir -p /etc/systemd/journald.conf.d/ $ sudo touch /etc/systemd/journald.conf.d/00-journal-size.conf $ sudo bash -c 'cat > /etc/systemd/journald.conf.d/00-journal-size.conf << 'EOF' [Journal] SystemMaxUse=30M EOF'
You can change the value
30M to what ever size you prefered. To apply the new limit, you need to restart the services as superuser.
$ systemctl status systemd-journald.service $ sudo systemctl restart systemd-journald.service $ systemctl status systemd-journald.service
Hurm.. I notice slow boot startup on my Fedora 28 workstation
[rnm@robbinespu (/home/rnm)] $ systemd-analyze time Startup finished in 1.890s (kernel) + 4.702s (initrd) + 1min 20.163s (userspace) = 1min 26.756s graphical.target reached after 58.148s in userspace
So plymouth-quit-wait service took more than 25 seconds and.. bolt services also part of the culprit
[rnm@robbinespu (/home/rnm)] $ systemd-analyze blame | head 25.124s bolt.service 25.118s plymouth-quit-wait.service 13.389s firewalld.service 12.672s akmods.service 11.922s udisks2.service 11.453s accounts-daemon.service 9.690s vmware.service 9.125s lvm2-monitor.service 8.730s dkms.service 8.085s systemd-udev-settle.service
I never heard of bolt.services , it’s apparently a Thunderbolt system deamon to manage thunderbolt 3 devices.
[rnm@robbinespu (/home/rnm)] $ dnf info bolt Last metadata expiration check: 2 days, 6:51:24 ago on Sat 01 Sep 2018 09:06:59 AM +08. Installed Packages Name : bolt Version : 0.4 Release : 1.fc28 Arch : x86_64 Size : 281 k Source : bolt-0.4-1.fc28.src.rpm Repo : @System From repo : updates-testing Summary : Thunderbolt device manager URL : https://github.com/gicmo/bolt License : LGPLv2+ Description : bolt is a system daemon to manage thunderbolt 3 devices via a D-BUS : API. Thunderbolt 3 features different security modes that require : devices to be authorized before they can be used. The D-Bus API can be : used to list devices, enroll them (authorize and store them in the : local database) and forget them again (remove previously enrolled : devices). It also emits signals if new devices are connected (or : removed). During enrollment devices can be set to be automatically : authorized as soon as they are connected. A command line tool, called : boltctl, can be used to control the daemon and perform all the above : mentioned tasks.
I don’t know and where it comes and apparently active on my system
[rnm@robbinespu (/home/rnm)] $ systemctl status bolt.service ● bolt.service Loaded: masked (/dev/null; masked) Active: active (running) since Mon 2018-09-03 14:11:53 +08; 1h 50min ago Main PID: 1946 (boltd) Tasks: 3 (limit: 4915) Memory: 1.7M CGroup: /system.slice/bolt.service └─1946 /usr/libexec/boltd Sep 03 14:11:28 robbinespu systemd: Starting Thunderbolt system service... Sep 03 14:11:28 robbinespu boltd: bolt 0.4 starting up. Sep 03 14:11:28 robbinespu boltd: config: loading user config Sep 03 14:11:53 robbinespu boltd: store: loading devices Sep 03 14:11:53 robbinespu boltd: power: force_power support: no Sep 03 14:11:53 robbinespu boltd: udev: enumerating devices Sep 03 14:11:53 robbinespu systemd: Started Thunderbolt system service. Sep 03 15:58:43 robbinespu systemd: bolt.service: Current command vanished from the unit file, execution of the command list won't be resumed.
Even though I don’t appear to have any Thunderbolt devices…
[rnm@robbinespu (/home/rnm)] $ boltctl list
As quick solution let just permanently disable the service.
[rnm@robbinespu (/home/rnm)] $ systemctl mask bolt Created symlink /etc/systemd/system/bolt.service → /dev/null
There is a way but it quite complicated and people tend to do mistake when handling lot of files / directory but sometimes developer don’t have connection to VCS and we don’t have any option.. ;d
I face difficult situation during previous project to deploy changes on AIX machine when unlucky we don’t have VPN access to our CVS. I learn something and let me show you the harder way to manage you source code.
Good employees are usually the first ones to leave. The bad employees are the ones you need to lay off or fire or get rid of somehow. So, why do they leave?
They leave because of one or more of the following reasons:
Being underpaid - As an extreme example, an about-to-graduate PhD student that I worked with was offered 67k over the phone. He was ecstatic but when he told his advisor, the advisor told him to call them back and tell them 167k. He was shocked but did as told and the hiring manager agreed on the spot!
I wonder how high the manager was willing to go.