system stop in reached targets sockets boot process

mfaridi · 2013-09-26 10:43:16

it is 4 days when I boot my stsrem and want use it.I see boot process ,but my system hang for 2min when i see this message

 Reached Targets Sockets

and my system hang in this message for 2min and after 2 min .I can see login manager and I can use my XFCE .
I donot know why it stop in this stage of boot for 2min
howI can solve this problem ?

Last edited by mfaridi (2013-09-26 10:45:47)

mfaridi · 2013-09-27 09:10:07

any suggestions and help

mfaridi · 2013-09-28 10:19:37

today my system stop in this stage for 2min

 Reached Targest Timers

my system boot slowly

mfaridi · 2013-09-30 10:02:21

any help

Lone_Wolf · 2013-09-30 12:08:18

Have you checked the troubleshooting section of the systemd wiki page ?

The systemd-analyze command may also be useful.

mfaridi · 2013-09-30 12:35:06

Lone_Wolf wrote:

Have you checked the troubleshooting section of the systemd wiki page ?
The systemd-analyze command may also be useful.

I see this with systemd-analyze command

 Startup finished in 4.259s (kernel) + 1min 12.007s (userspace) = 1min 16.266s

ebal · 2013-09-30 13:27:14

how about

systemd-analyze blame

mfaridi · 2013-09-30 19:44:35

ebal wrote:

how about
systemd-analyze blame

this is output

5.556s dhcpcd@enp0s10.service
          2.302s upower.service
          1.664s home.mount
           770ms kmod-static-nodes.service
           739ms systemd-udev-trigger.service
           681ms polkit.service
           645ms systemd-readahead-replay.service
           644ms systemd-readahead-collect.service
           642ms sys-kernel-debug.mount
           641ms dev-mqueue.mount
           641ms dev-hugepages.mount
           439ms udisks2.service
           241ms systemd-sysctl.service
           215ms systemd-udevd.service
           213ms systemd-binfmt.service
           209ms systemd-tmpfiles-setup-dev.service
           208ms systemd-vconsole-setup.service
           190ms systemd-journal-flush.service
           187ms user@1000.service
           168ms systemd-tmpfiles-setup.service
           164ms systemd-tmpfiles-clean.service
           156ms sys-kernel-config.mount
           130ms systemd-remount-fs.service
           128ms systemd-random-seed.service
            95ms systemd-fsck-root.service
            77ms dhcpd4.service
            65ms iptables.service
            53ms bluetooth.service
            51ms systemd-update-utmp.service
            49ms dev-sdb5.swap
            39ms systemd-user-sessions.service
            35ms systemd-logind.service
            15ms hostapd.service
             5ms tmp.mount
             3ms rtkit-daemon.service
             2ms sys-fs-fuse-connections.mount
             1ms systemd-readahead-done.service
             1ms proc-sys-fs-binfmt_misc.mount

Pse · 2013-09-30 21:40:02

That output seems to be missing something. Or perhaps the system booted normally in that case? You need to post the output of 'systemd-analyze blame' and 'systemd-analyze critical-chain' after the system boots slowly.

mfaridi · 2013-10-04 17:53:57

Pse wrote:

That output seems to be missing something. Or perhaps the system booted normally in that case? You need to post the output of 'systemd-analyze blame' and 'systemd-analyze critical-chain' after the system boots slowly.

this is out put of systemd-analyze critical-chain'

he time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @1min 6.049s
`-multi-user.target @1min 6.048s
  `-tor.service @1min 5.938s
    `-network.target @1min 5.938s
      `-dhcpcd@enp0s10.service @1min 477ms +5.460s
        `-basic.target @1min 467ms
          `-timers.target @6.385s
            `-systemd-tmpfiles-clean.timer @6.385s
              `-sysinit.target @6.371s
                `-systemd-update-utmp.service @6.309s +57ms
                  `-systemd-tmpfiles-setup.service @6.237s +61ms
                    `-local-fs.target @6.227s
                      `-home.mount @5.237s +985ms
                        `-dev-sdb6.device @5.227s

and this output of systemd-analyze blame

[mostafa@mfaridi ~]$ systemd-analyze blame
          5.460s dhcpcd@enp0s10.service
          3.345s upower.service
          1.434s kmod-static-nodes.service
           985ms home.mount
           817ms systemd-udev-trigger.service
           774ms systemd-readahead-replay.service
           773ms systemd-readahead-collect.service
           771ms sys-kernel-debug.mount
           770ms dev-hugepages.mount
           769ms dev-mqueue.mount
           406ms dev-sdb5.swap
           278ms user@1000.service
           274ms polkit.service
           127ms systemd-logind.service
           106ms udisks2.service
           106ms dhcpd4.service
            91ms systemd-binfmt.service
            80ms systemd-journal-flush.service
            71ms systemd-remount-fs.service
            61ms systemd-tmpfiles-setup.service
            57ms systemd-update-utmp.service
            46ms sys-kernel-config.mount
            42ms systemd-fsck-root.service
            42ms iptables.service
            30ms systemd-random-seed.service
            27ms proc-sys-fs-binfmt_misc.mount
            18ms bluetooth.service
            15ms systemd-vconsole-setup.service
            14ms systemd-sysctl.service
            13ms systemd-readahead-done.service
             9ms systemd-user-sessions.service
             8ms hostapd.service
             5ms tmp.mount
             4ms systemd-udevd.service
             2ms rtkit-daemon.service
             2ms sys-fs-fuse-connections.mount
             1ms systemd-tmpfiles-setup-dev.service

elotgamu · 2013-10-31 05:17:58

I have the same trouble, in the kernel log when it reach the messague: "Reached target sockets" my laptop pass 13 seconds after get the next stage of booting. After taht i can boot normal in my system. If i execute "journalctl --this-boot" I cannot find error in the section "reached target sockets" but I see that this step takes 13 second.

WonderWoofy · 2013-10-31 05:36:13

Can you find a gap in the logging time when it might be stalling on something?

elotgamu · 2013-10-31 06:31:25

Well watching my journalctl log the problem isnot in "reached target sockets" the problem is in "Starting Daily Cleanup of Temporary Directories" that is the step after "reached target sockets"

js · 2013-11-01 06:46:39

This sounds similar to a problem I have been troubleshooting. I would get to the stage where systemd says that it Reached Target Sockets and then sit there for several(10-20 seconds) all of the while churning hard drive activity. My systemd-analyze was stating that my total boot time from firmware to userspace was taking about 30 seconds. However, with either bootchart or systemd-analyze plot, I noticed that a bunch of tasks were waiting until systemd-journal-flush.service completed and it was taking up about 15 seconds of time, though I believe systemd-analyze blame was only showing it taking a few milliseconds. As a troubleshooting step, I decided to remove my /var/log/journal directory to stop the journal from making a persistant copy of itself. Upon my next reboot, my boot time was down to about 15 seconds. Reinstalled systemd to recover the /var/log/journal directory and my next boot went back up to 30 seconds. I have not done testing yet as to if the problem is with the flush itself or if it has to do with something going on with systemd's readahead beyond a few test boots where my time was in the mid 20 second range.

I am still trying to find a more elegant solution and more information about what is going on.

thiagowfx · 2013-11-14 22:54:54

I also have this problem. My systemd-analyze output is really strange:

Startup finished in 584542y 2w 2d 20h 1min 44.866s (loader) + 4.857s (kernel) + 20.988s (userspace) = 25.846s

Years? Really? The Kernel + Userspace combination looks correct, but the loader is clearly wrong.

Output of systemd-analyze blame:

           722ms systemd-fsck@dev-disk-by\x2duuid-ab12af74\x2dfa34\x2d4b3f\x2d818c\x2d64189604c083.service
           516ms udisks2.service
           483ms systemd-fsck@dev-disk-by\x2duuid-6e01e9a1\x2de79e\x2d40f5\x2d8acc\x2d5ffbca965d03.service
           377ms systemd-update-utmp.service
           372ms var.mount
           352ms NetworkManager.service
           351ms home.mount
           225ms systemd-binfmt.service
           170ms systemd-tmpfiles-setup.service
           146ms systemd-backlight@acpi_video0.service
           133ms systemd-random-seed.service
           125ms systemd-udev-trigger.service
           119ms kmod-static-nodes.service
            83ms tmp.mount
            80ms systemd-vconsole-setup.service
            73ms zramswap.service
            60ms systemd-logind.service
            53ms systemd-tmpfiles-clean.service
            52ms systemd-fsck@dev-disk-by\x2duuid-ee8611dc\x2d0021\x2d4bdb\x2db85a\x2d2f6853489c94.service
            50ms systemd-remount-fs.service
            48ms polkit.service

Look at my systemd-analyze plot (alert: huge image): http://img.susepaste.org/images/17c6a24e.svg

Is 'journal-flush' the problem? I'll try to find a solution; if I discover one I'll share it here.

Last edited by thiagowfx (2013-11-14 23:26:36)

thiagowfx · 2013-11-14 23:02:43

Oh, here is systemd-analyze critical-chain also, I forgot it:

The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @20.987s
└─multi-user.target @20.986s
  └─ntpd.service @20.971s +14ms
    └─network.target @20.959s
      └─NetworkManager.service @20.605s +352ms
        └─basic.target @20.599s
          └─timers.target @20.592s
            └─systemd-tmpfiles-clean.timer @20.591s
              └─sysinit.target @3.026s
                └─systemd-update-utmp.service @2.645s +377ms
                  └─systemd-tmpfiles-setup.service @2.471s +170ms
                    └─local-fs.target @2.470s
                      └─var.mount @2.096s +372ms
                        └─systemd-fsck@dev-disk-by\x2duuid-ab12af74\x2dfa34\x2d4b3f\x2d818c\x2d64189604c083.service @1.
                          └─dev-disk-by\x2duuid-ab12af74\x2dfa34\x2d4b3f\x2d818c\x2d64189604c083.device @976ms

WonderWoofy · 2013-11-14 23:16:08

@thiagowfx, your issue has absolutely nothing to do with the topic of this thread. This is what is referred to as thread hijacking. Additionally, the shot of your systemd-analyze plot is likely too large for these forums.

thiagowfx · 2013-11-14 23:25:24

@WonderWoofy Really? I'm sorry so, wasn't my intention to 'hijack' the thread. I just posted here because of

(1) this

elotgamu wrote:

I have the same trouble, in the kernel log when it reach the messague: "Reached target sockets" my laptop pass 13 seconds after get the next stage of booting. After taht i can boot normal in my system. If i execute "journalctl --this-boot" I cannot find error in the section "reached target sockets" but I see that this step takes 13 second.

and

(2) this

elotgamu wrote:

Well watching my journalctl log the problem isnot in "reached target sockets" the problem is in "Starting Daily Cleanup of Temporary Directories" that is the step after "reached target sockets"

Also, I haven't said explicitly, but my system bootup hangs exactly on "reached target sockets" too. I thought this was clear by my plot image (you can see 'sockets' is the last target before the long waiting time). So I don't think I've really hijacked the thread.

I'll edit the image, sorry for that.

Last edited by thiagowfx (2013-11-14 23:28:19)

WonderWoofy · 2013-11-14 23:34:20

My bad, I thought your were referencing the crazy firmware time (which is not indicative of anything actually wrong with Arch BTW).

0x29a · 2013-12-05 07:43:24

Hello there!

Same thing on my laptop. Reached target Sockets and...

Startup finished in 3.677s (kernel) + 34.690s (userspace) = 38.368s

It should be like... Dunno... Two times faster...

          1.667s laptop-mode.service
          1.658s wicd.service
          1.638s systemd-logind.service
          1.280s systemd-fsck@dev-sda1.service
           949ms systemd-remount-fs.service
           941ms dev-hugepages.mount
           934ms systemd-tmpfiles-setup-dev.service
           914ms boot.mount
           750ms sys-kernel-debug.mount
           743ms dev-mqueue.mount
           733ms tmp.mount
           590ms home.mount
           570ms systemd-readahead-collect.service
           559ms systemd-readahead-replay.service
           550ms systemd-networkd.service
           536ms systemd-udev-trigger.service
           453ms kmod-static-nodes.service
           368ms systemd-update-utmp.service
           342ms systemd-tmpfiles-setup.service
           306ms sys-kernel-config.mount
           306ms systemd-vconsole-setup.service
           278ms systemd-sysctl.service
           265ms systemd-fsck@dev-sda4.service
           212ms alsa-restore.service
           193ms ntpd.service
           186ms hdapsd.service
           129ms polkit.service
           123ms systemd-backlight@backlight:acpi_video0.service
            50ms systemd-backlight@backlight:intel_backlight.service
            27ms dev-sda5.swap
            17ms systemd-rfkill@rfkill0.service
            12ms systemd-random-seed.service
             5ms systemd-user-sessions.service
             4ms systemd-udevd.service
             3ms systemd-journal-flush.service
             3ms systemd-rfkill@rfkill1.service
             2ms systemd-rfkill@rfkill2.service
             1ms systemd-readahead-done.service

graphical.target @34.689s
`-multi-user.target @34.688s
  `-ntpd.service @34.492s +193ms
    `-network.target @34.386s
      `-wicd.service @32.120s +1.658s
        `-basic.target @32.095s
          `-timers.target @32.091s
            `-systemd-tmpfiles-clean.timer @9.161s
              `-sysinit.target @9.157s
                `-systemd-update-utmp.service @8.787s +368ms
                  `-systemd-tmpfiles-setup.service @8.440s +342ms
                    `-local-fs.target @8.435s
                      `-boot.mount @7.519s +914ms
                        `-systemd-fsck@dev-sda1.service @6.159s +1.280s
                          `-dev-sda1.device @6.156s

_______________________________________________________________________________________________________

E D I T :

Turned off readahead.

Startup finished in 3.363s (kernel) + 10.607s (userspace) = 20.803s

Last edited by 0x29a (2013-12-11 08:08:27)

Arch Linux

#1 2013-09-26 10:43:16

system stop in reached targets sockets boot process

#2 2013-09-27 09:10:07

Re: system stop in reached targets sockets boot process

#3 2013-09-28 10:19:37

Re: system stop in reached targets sockets boot process

#4 2013-09-30 10:02:21

Re: system stop in reached targets sockets boot process

#5 2013-09-30 12:08:18

Re: system stop in reached targets sockets boot process

#6 2013-09-30 12:35:06

Re: system stop in reached targets sockets boot process

#7 2013-09-30 13:27:14

Re: system stop in reached targets sockets boot process

#8 2013-09-30 19:44:35

Re: system stop in reached targets sockets boot process

#9 2013-09-30 21:40:02

Re: system stop in reached targets sockets boot process

#10 2013-10-04 17:53:57

Re: system stop in reached targets sockets boot process

#11 2013-10-31 05:17:58

Re: system stop in reached targets sockets boot process

#12 2013-10-31 05:36:13

Re: system stop in reached targets sockets boot process

#13 2013-10-31 06:31:25

Re: system stop in reached targets sockets boot process

#14 2013-11-01 06:46:39

Re: system stop in reached targets sockets boot process

#15 2013-11-14 22:54:54

Re: system stop in reached targets sockets boot process

#16 2013-11-14 23:02:43

Re: system stop in reached targets sockets boot process

#17 2013-11-14 23:16:08

Re: system stop in reached targets sockets boot process

#18 2013-11-14 23:25:24

Re: system stop in reached targets sockets boot process

#19 2013-11-14 23:34:20

Re: system stop in reached targets sockets boot process

#20 2013-12-05 07:43:24

Re: system stop in reached targets sockets boot process

Board footer