Opened 10 years ago

Closed 19 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 20 months ago.
Patch

Download all attachments as: .zip

Change History (29)

comment:1 by hrily, 21 months ago

I would like to fix this bug...

Any suggestions to get me started?

comment:2 by pulkomandy, 21 months ago

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 by hrily, 21 months ago

Thank you for the insight

I'll go through the code

comment:4 by hrily, 20 months ago

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 by pulkomandy, 20 months ago

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 by hrily, 20 months ago

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 by pulkomandy, 20 months ago

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 by hrily, 20 months ago

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 by pulkomandy, 20 months ago

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 by hrily, 20 months ago

Okay

Thank you... :)

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

comment:11 by waddlesplash, 19 months ago

Resolution: fixed
Status: newclosed

Merged in hrev51833. Thanks!

comment:12 by T.Knez, 19 months ago

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 by humdinger, 19 months ago

Resolution: fixed
Status: closedreopened

comment:14 by diver, 19 months ago

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

comment:15 by hrily, 19 months ago

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 by pulkomandy, 19 months ago

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 by hrily, 19 months ago

Okay

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

That might help in further optimization.

comment:18 by hrily, 19 months ago

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 by pulkomandy, 19 months ago

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 by bruno, 19 months ago

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 19 months ago by bruno (previous) (diff)

in reply to:  19 comment:21 by hrily, 19 months ago

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 by pulkomandy, 19 months ago

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 by hrily, 19 months ago

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 19 months ago by hrily (previous) (diff)

comment:24 by korli, 19 months ago

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 by pulkomandy, 19 months ago

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

in reply to:  25 comment:26 by hrily, 19 months ago

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 by korli, 19 months ago

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 by korli, 19 months ago

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