Possible and useful to disable `dev-ttyS0.device`and such?

English Install/Boot/Login
1

Dear all,

I just recently got to know systemd-analyze blame.

So, I tried it and got:

~> systemd-analyze blame
1min 28.361s flatpak-system-update.service
     15.572s sys-devices-platform-serial8250-tty-ttyS3.device
     15.572s dev-ttyS3.device
     15.562s dev-ttyS1.device
     15.562s sys-devices-platform-serial8250-tty-ttyS1.device
     15.561s dev-ttyS2.device
     15.561s sys-devices-platform-serial8250-tty-ttyS2.device
     15.549s dev-ttyS0.device
     15.549s sys-devices-pnp0-00:01-tty-ttyS0.device
     15.397s dev-nvme0n1p1.device
     […]

I now wonder is it possible and useful to disable dev-ttyS[0-3].device, sys-devices-pnp0-00:01-tty-ttyS0.device, sys-devices-platform-serial8250-tty-ttyS[1-3].device?

I would guess I don’t make use of that stuff… Or is it essential for something I don’t know, yet? I really don’t know…

If it is dispensable, can it be disabled safely? And if yes, then how?

Thank you! Any comments appreciated very much!

2

Nothing to hide or disable…

3

Thank you for that info!

Good to know about. So that I don’t dare to delete essential stuff on my own. Would be a pity to screw up the system.

4

Specially not if the gain is only a dozen of milliseconds

1 Like
5

Well…

compared to

         4ms systemd-user-sessions.service
       479us snapd.socket
6

But anyway?! “Serial”-something? Today?

7

You misunderstand the output.

This says ttyS0-3 takes 0.023 seconds. (15.572 - 15.549)

8

Is this really true? (No offence, just asking.)

Like

~> systemd-analyze blame | grep "flatpak"
1min 28.361s flatpak-system-update.service

I only get 1 single time information in total.

And why actually

     15.572s sys-devices-platform-serial8250-tty-ttyS3.device

(or the such)
MINUS

     15.549s sys-devices-pnp0-00:01-tty-ttyS0.device

(tty-ttyS0.device, so “0”)

And also:

~> systemd-analyze --help | grep "blame"
  blame                      Print list of running units ordered by
[…]
                             time to init

as well as

~> man -L=EN systemd-analyze

providing

   systemd-analyze blame
       This command prints a list of all running units, ordered by the time they took to initialize. This information may be used to optimize boot-up times. Note that the output might
       be misleading as the initialization of one service might be slow simply because it waits for the initialization of another service to complete. Also note: systemd-analyze blame
       doesn't display results for services with Type=simple, because systemd considers such services to be started immediately, hence no measurement of the initialization delays can
       be done. Also note that this command only shows the time units took for starting up, it does not show how long unit jobs spent in the execution queue. In particular it shows the
       time units spent in "activating" state, which is not defined for units such as device units that transition directly from "inactive" to "active". This command hence gives an
       impression of the performance of program code, but cannot accurately reflect latency introduced by waiting for hardware and similar events.

       Example 2. Show which units took the most time during boot

           $ systemd-analyze blame
                    32.875s pmlogger.service
                    20.905s systemd-networkd-wait-online.service
                    13.299s dev-vda1.device
                    ...
                       23ms sysroot.mount
                       11ms initrd-udevadm-cleanup-db.service
                        3ms sys-kernel-config.mount

I am just a little bit confused and questioning.

9

You could also examine the results from
systemd-analyze critical-chain
That can be a better measure of boot performance / issues because it specifically highlights the services that are on the critical path, (as they directly impact the overall boot time by causing delays for subsequent services due to their dependencies). The ‘blame’ option shows the list of services ordered by how long they took to start individually, but doesn’t necessarily reflect their impact on the overall boot time if they are not on the critical path. (Many services are started in parallel during the boot sequence.)

1 Like
10 
# 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 @4.625s
└─multi-user.target @4.624s
  └─chronyd.service @4.371s +251ms
    └─nss-lookup.target @4.363s
      └─dnsmasq.service @3.732s +630ms
        └─network.target @3.722s
          └─NetworkManager.service @3.314s +407ms
            └─network-pre.target @3.300s
              └─wpa_supplicant.service @3.037s +262ms
                └─dbus.service @3.019s
                  └─basic.target @2.997s
                    └─sockets.target @2.997s
                      └─dbus.socket @2.997s
                        └─sysinit.target @2.994s
                          └─systemd-vconsole-setup.service @4.131s +319ms
                            └─systemd-journald.socket
                              └─system.slice
                                └─-.slice

Your machine is really slow. Did you replace the hard disc by a SSD?

11

By what detail do you know that? — I provided just minimal output…

Drives:
Local Storage: total: 476.94 GiB used: 273.15 GiB (57.3%)
SMART Message: Unable to run smartctl. Root privileges required.
ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Samsung model: SSD 970 PRO 512GB
size: 476.94 GiB block-size: physical: 512 B logical: 512 B speed: 31.6 Gb/s

is my sole mass storage. I am satisfied with overall performance.

12

By what detail do you know that? — I provided just minimal output…

# systemd-analyze blame |grep -i ttyS3 |grep -i platform
     2.973s sys-devices-platform-serial8250-tty-ttyS3.device
13

Well, OK then.

my

~> 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 @3.931s
└─display-manager.service @3.120s +811ms
  └─time-sync.target @3.116s
    └─chronyd.service @2.984s +131ms
      └─nss-lookup.target @2.982s
        └─unbound.service @2.944s +37ms
          └─network.target @2.893s
            └─NetworkManager.service @2.142s +748ms
              └─network-pre.target @2.141s
                └─wpa_supplicant.service @2.947s +76ms
                  └─dbus.service @1.807s
                    └─basic.target @1.803s
                      └─sockets.target @1.803s
                        └─snapd.socket @1.802s +492us
                          └─sysinit.target @1.798s
                            └─systemd-update-utmp.service @1.792s +5ms
                              └─auditd.service @1.725s +44ms
                                └─systemd-tmpfiles-setup.service @1.692s +31ms
                                  └─run-credentials-systemd\x2dtmpfiles\x2dsetu>
lines 1-22/22 (END)

compared to your

is even a bit faster, more than 0.5s.

But on the other hand my

~> systemd-analyze blame | grep -i ttyS3 | grep -i platform
14.998s sys-devices-platform-serial8250-tty-ttyS3.device

compared to your

is pretty lame!

Does anyone know what this means and would could be the reason and the consequences? — But boot sequence is within just a very few seconds, please compare to the output above. I am satisfied with my system and don’t experience any poor performance in general use. It’s just not sufficient for running a local LLM due to my Intel Core i3-9100 and no dedicated GPU or NPU at all.

And anyway, what is that serialstuff? Do I really need it? Do I depend on? So far, I haven’t even known about any serial"devices" in my PC…

14

As explained in the bugreport, systemd-analyze is a debugging tool. systemd-analyze blame is complete irrelevant for your use case (all device/serial/platform are processed in parallel and only add up some microseconds to the boot time) . NO, you can’t remove the device/serial/platform.

The more important informations for normal users are gathered via the pure systemd-analyze or systemd-analyze critical-chain commands.

systemd-analyze without any additional options, shows the time until the system start is finished (Desktop reached)

systemd-analyze blame shows the time for all processes which are started when you start your machine even the ones which are still running after your system start finished. That is why you see the flatpak update service in your output with over a minute.

This is easily confused by some users.

1 Like
15

@hui Thank you!

16

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.