Opened 10 years ago

Closed 15 months ago

#3811 closed bug (fixed)

System enters "shutdown mode" too early

Reported by: axeld Owned by: bonefish
Priority: normal Milestone: R1
Component: Servers/registrar Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

When shutting down the system, the registrar does not allow to start any new application anymore. This is understandable, but the way it does it now can easily get annoying: if an application needs user interaction to be quit (like manually deciding wether or not to save an open document), it doesn't make any sense to forbid the user to open new applications.

The system should only prevent new apps from being started after all user apps has been successfully quit.

Attachments (1)

0001-Shutdown-Process-Applications-can-now-be-launched-in.patch (1.6 KB) - added by hrily 16 months ago.
Patch

Download all attachments as: .zip

Change History (29)

comment:1 Changed 17 months ago by hrily

I would like to fix this bug...

Any suggestions to get me started?

comment:2 Changed 17 months ago by pulkomandy

Hi,

The code responsible for this seems to be src/servers/registrar/ShutdownProcess.cpp.

There is an USER_APP_TERMINATION_PHASE, in which it should be allowed to start new apps. The shutdown process should try to kill all applications one by one (possibly with "the document has unsaved changes" alerts interrupting it - try it with an unsaved file in StyledEdit for example). After all apps have been terminated, we will enter SYSTEM_APP_TERMINATION_PHASE. In this phase, all system applications (servers, etc) will be terminated. The user should not be allowed to start new apps.

I don't know the code further so I will let you study how this works. Let us know if you have more specific questions.

comment:3 Changed 17 months ago by hrily

Thank you for the insight

I'll go through the code

comment:4 Changed 16 months ago by hrily

Sorry for the delayed patch, ended up reading the whole file...

But it was really great reading to know how an OS shuts down.

comment:5 Changed 16 months ago by pulkomandy

We are now using Gerrit for patch review. It would be appreciated if you could read through https://dev.haiku-os.org/wiki/CodingGuidelines/SubmittingPatches again and send your patch to the new review system:

https://review.haiku-os.org

comment:6 Changed 16 months ago by hrily

I don't know if this is silly to ask, but is the source of git repo same as before?

I can't seem to push to it... :(

comment:7 Changed 16 months ago by pulkomandy

Yes, the git repo is the same. The instructions at "submitting patches" should get you started with submitting, but this is all very new so maybe the instructions are not clear. Let me know what you did and the error you get and I'll see how to fix it and how to improve the document.

comment:8 Changed 16 months ago by hrily

Steps I followed:

$ git push origin master:refs/for/master
XML error: undefined entity
error: no DAV locking support on https://git.haiku-os.org/haiku/
fatal: git-http-push failed
error: failed to push some refs to 'https://git.haiku-os.org/haiku'

comment:9 Changed 16 months ago by pulkomandy

Ah yes, to be able to push you need to switch to ssh instead of https, and upload your public key to the gerrit server.

comment:10 Changed 16 months ago by hrily

Okay

Thank you... :)

Uploaded changes at https://review.haiku-os.org/62

comment:11 Changed 15 months ago by waddlesplash

Resolution: fixed
Status: newclosed

Merged in hrev51833. Thanks!

comment:12 Changed 15 months ago by T.Knez

Shutting down the system has become a lot slower since I updated to the latest nightly. Tested on a Thinkpad X220 and X61s with the same results. The time it takes from pushing "shut down" in the menu until the system is dead is a good while longer, pretty much 3 to 4 times longer. It's still measured in seconds, but it's really noticable.

comment:13 Changed 15 months ago by humdinger

Resolution: fixed
Status: closedreopened

comment:14 Changed 15 months ago by diver

I also see a significant slowdown at reboot/shutdown. Most of the icons are also missing from the shutdown window.

comment:15 Changed 15 months ago by hrily

This might be due to the looping added to check user apps.

Can anything be done to optimize the runtime of the loop?

I would also like to know the time taken at each step in the loop. Can this be done using debugger or something?

comment:16 Changed 15 months ago by pulkomandy

It will be hard to use the debugger during the shutdown phase. However, you should be able to use the syslog() and then look at /var/log/syslog after a reboot to see the information stored there.

comment:17 Changed 15 months ago by hrily

Okay

I'll try to do that and see what part is exactly causing the delay.

That might help in further optimization.

comment:18 Changed 15 months ago by hrily

I tried logging the times at each step in ShutdownProcess::_WorkerDoShutdown

It's really strange that the added lines (i.e. from https://git.haiku-os.org/haiku/tree/src/servers/registrar/ShutdownProcess.cpp#n1303 to https://git.haiku-os.org/haiku/tree/src/servers/registrar/ShutdownProcess.cpp#n1333 OR from line 1303 to line 1333) take less than a millisecond.

And for some reason I can't get logs after line 1333 (they don't appear in /var/log/syslog). Maybe logging daemon is shut down at that point.

comment:19 Changed 15 months ago by pulkomandy

Yes, of course _QuitApps(fSystemApps, true); will quit the system apps, including the logger. In case you need to log things after that point, you could create a file yourself (using BFile or classical fopen, fprint) and log there.

comment:20 Changed 15 months ago by bruno

Hello with your changes I know that wpa_supplicant wont shutdown and so Haiku wont shutdown if I dont kill application wpa_supplicant... relevant to ticket I added some time ago: Haiku wont shut down... can you make wpa_supplicant to close at shutdown? Maybe you solve my bug by doing so... thx Bruno

Last edited 15 months ago by bruno (previous) (diff)

comment:21 in reply to:  19 Changed 15 months ago by hrily

Replying to PulkoMandy:

Yes, of course _QuitApps(fSystemApps, true); will quit the system apps, including the logger. In case you need to log things after that point, you could create a file yourself (using BFile or classical fopen, fprint) and log there.

I tried this, still there isn't any significant time that I see. Max time I see is just over a millisecond. Maybe I'm calculating the time wrong.

What I did was, after each 2-3 statement, I printed the difference in timestamps (using clock() from time.h). Is there a better method for this?

comment:22 Changed 15 months ago by pulkomandy

clock() only shows the CPU time used by the running process. This means it does not count time where the process is waiting on something else.

You could use real_time_clock_usecs from https://www.haiku-os.org/legacy-docs/bebook/TheKernelKit_Time.html#real_time_clock to get the real elapsed time.

comment:23 Changed 15 months ago by hrily

You could use real_time_clock_usecs from ​https://www.haiku-os.org/legacy-docs/bebook/TheKernelKit_Time.html#real_time_clock to get the real elapsed time.

If I do a difference of real_time_clock_usecs() at different steps, Will I get the time difference in microseconds or any other unit???

Because when I used this, I'm getting 0 for every step except for _QuitApps(fSystemApps, true); where it is 27.

Last edited 15 months ago by hrily (previous) (diff)

comment:24 Changed 15 months ago by korli

A bit of trace in the kernel lets me know that the launch_daemon keeps relaunching daemons (net_server, syslog_daemon, mount_server, package_daemon, power_daemon). It seems the launch_daemon handles this incorrectly when the system shutdowns.

comment:25 Changed 15 months ago by pulkomandy

real_time_clock is in seconds, which is why I suggested real_time_clock_usecs which is the same in microseconds.

comment:26 in reply to:  25 Changed 15 months ago by hrily

Replying to PulkoMandy:

real_time_clock is in seconds, which is why I suggested real_time_clock_usecs which is the same in microseconds.

I'm sorry, I used real_time_clock_usecs() only. Typing mistake :D.

comment:27 Changed 15 months ago by korli

I changed the logic in hrev51845 to avoid retrieving the app lists multiple times. It fixes the long shutdown issue at the same time.

comment:28 Changed 15 months ago by korli

Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.