Opened 16 years ago
Closed 7 years 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: | ||
| 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)
Change History (29)
comment:1 by , 7 years ago
comment:2 by , 7 years 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.
by , 7 years ago
| Attachment: | 0001-Shutdown-Process-Applications-can-now-be-launched-in.patch added |
|---|
Patch
comment:4 by , 7 years 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 , 7 years 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:
comment:6 by , 7 years 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 , 7 years 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 , 7 years ago
Steps I followed:
- Cloned repo using 'git clone https://git.haiku-os.org/haiku'
- Made the changes, git add, git commit.
- And following:
$ 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 , 7 years 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 , 7 years ago
comment:12 by , 7 years 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 , 7 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
comment:14 by , 7 years ago
I also see a significant slowdown at reboot/shutdown. Most of the icons are also missing from the shutdown window.
comment:15 by , 7 years 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 , 7 years 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 , 7 years 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 , 7 years 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.
follow-up: 21 comment:19 by , 7 years 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 , 7 years 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
comment:21 by , 7 years 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 , 7 years 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 , 7 years 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() 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.
comment:24 by , 7 years 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.
follow-up: 26 comment:25 by , 7 years ago
real_time_clock is in seconds, which is why I suggested real_time_clock_usecs which is the same in microseconds.
comment:26 by , 7 years 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 , 7 years 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 , 7 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
I would like to fix this bug...
Any suggestions to get me started?