Poor shutdown: A stop job is running...

[der_bud]

Sometimes on shutdown or reboot my december-kde32 virtualbox really hangs up with messages like

Code Auswählen Erweitern

A stop job is running for LSB: Adaptive readahead daemon
A stop job is running for LSB: daemon to balance interrupts for SMP systems
A stop job is running for LSB: Start acpi_fakekey daemon
A stop job is running for LSB: A server to start shell scripts in the background
A stop job is running for LSB: Simple webserver for static html and CGI

These are rotating on and on and on with a red (*) in front, have never waited longer than 10 Minutes until hardreset.
Anyone else with this observations or an idea to cure this?

System is a guest in 32 bit Virtualbox, inxi -v3

Code Auswählen Erweitern


System:    Host: sidbox Kernel: 3.13-0.towo-siduction-686 i686 (32 bit, gcc: 4.8.2)
           Desktop: KDE 4.12.1 (Qt 4.8.6) Distro: siduction 13.2.0 December - kde - (201312310247)
Machine:   System: innotek product: VirtualBox version: 1.2
           Mobo: Oracle model: VirtualBox version: 1.2 Bios: innotek version: VirtualBox date: 12/01/2006
CPU:       Dual core Intel Core2 CPU 6600 (-MCP-) cache: 6144 KB flags: (nx pae sse sse2 sse3 ssse3) bmips: 9600.8
           Clock Speeds: 1: 2400.201 MHz 2: 2400.201 MHz
Graphics:  Card: InnoTek Systemberatung VirtualBox Graphics Adapter bus-ID: 00:02.0
           X.Org: 1.14.5 drivers: ati,vboxvideo (unloaded: fbdev,vesa) Resolution: 1152x864@60.0hz
           GLX Renderer: Chromium GLX Version: 2.1 Chromium 1.9 Direct Rendering: Yes
Network:   Card: Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE] driver: pcnet32 port: d020 bus-ID: 00:03.0
           IF: eth0 state: unknown speed: 100 Mbps duplex: full mac: 08:00:27:d1:50:0e
Info:      Processes: 130 Uptime: 2 min Memory: 201.3/1604.2MB Runlevel: 5 Gcc sys: 4.8.2
           Client: Shell (bash 4.2.45) inxi: 1.9.17


(edit: hm, this is in Hardware-Support now, thought I started in Software...)

[ralul]

purge some of
- fedora-readahead
- irqbalance
- acpi-support
- acpi-fakekey

Why these tools in a virtualbox?
(I don't have them on my plain install)

[der_bud]

...Why these tools in a virtualbox?
(I don't have them on my plain install)

Never thought about it, as they came with a plain standard install. And I didn't have these issues earlier (before december/systemd/3.13), but i'll give purging them a try, as its only a vm-testsystem. (Btw, it's not fedora-readahead, must be the systemd one).

[melmarker]

it is fedora-readahead - btw. systemd don't come with a own readahead

[der_bud]

it is fedora-readahead -...

Then something is strange with naming because

Code Auswählen Erweitern

dpkg -l | grep readahead
ii  preload    0.6.4-2    i386    adaptive readahead daemon

vs

Code Auswählen Erweitern

apt-cache policy readahead-fedora
  Installiert:  (keine)
  Installationskandidat: 2:1.5.6-5
 
And preload vs readahead-fedora have different maintainers...

But, doesn't matter, this goes offtopic. Will watch the systems behaviour after purging the acpi and irq stuff ralul mentioned

[melmarker]

der_bud: hab mich verlesen - der readahead ist wirklich von fedora, dass preload als adaptives readahead bezeichnet wird, wusste ich bisher nicht . Die acpi-Sachen sind im Umfeld von VBox sicher nicht wirklich sinnvoll, der readahead und preload schon.

Warum auch immer das abgestürzt ist - keine Ahnung, bei mir tuts. Was sagt eigentlich das Log dazu?

[der_bud]

... Was sagt eigentlich das Log dazu?

Nix  . Hab in dem System heftigst mit journalctl, dessen Schaltern und .conf rumgespielt und /var/log mehrmals geputzt. Werde gucken wenn das Problem wieder erscheint, zuletzt war Ruhe.

[pjnsmb]

For information
quote :

it is fedora-readahead - btw. systemd don't come with a own readahead


From Arch wiki :
Readahead
Systemd comes with its own readahead implementation, this should in principle improve boot time. However, depending on your kernel version and the type of your hard drive, your mileage may vary (i.e. it might be slower). To enable, do:

# systemctl enable systemd-readahead-collect systemd-readahead-replay

Remember that in order for the readahead to work its magic, you should reboot a couple of times.

I have tried this in siduction December by enabling both and found it slowed down my boot time...........

[melmarker]

Maybe you don't understand the principles of preload and readahead - i've had a lenghty discussion over that in the german arch forum times ago. Long story short: sure readahead-fedora "slow down" your boot time - but that not really matters, because the resulting booted system is more responsive and all common used libs and programs already loaded to ram And that gives a better experience at usage time, because often needed applications start directly from ram.

YMMV - if you have a really old system with slow drives and only 1G ram i would suggest not to use readahead and/or preload.

PPS: Äh - i'm wrong again - in that case i would suggest a current system.

[pjnsmb]

Sorry melmarker


I was just trying to clarify and learn from your comment :


it is fedora-readahead - btw. systemd don't come with a own readahead


It appears to me that systemd does have readahead if you enable :


systemd-readahead-collect  and    systemd-readahead-replay


I tried enabling both (without  installing fedora-readahead) without any improvement....


With both the above disabled and fedora-readahead installed I do see an improvement in boot time.