Opened 9 years ago
Last modified 8 years ago
#12636 new bug
The notification server starts to peg one core of the cpu
Reported by: | Giova84 | Owned by: | pulkomandy |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Servers/notification_server | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | x86 |
Description
Hi, is the second time in three days which I see this behaviour from the notification server: suddenly, regardless from the presence of active notifications, the notification server starts to peg one core of the cpu.
If i quit the notification_server (eg. using "hey") after the issue and then I start it again, notifications no longer work: I have to reboot Haiku to see again the notifications (I can confirm this behaviour by using the "notify" command).
Unfortunately, due to the ticket:12634 I am not able to investigate into the syslog file.
IIRC (I'm back on Haiku recently) under "/home/config/settings" there was some setting/preference file of the notification server, but I don't see nothing of related (maybe I'm wrong).
Change History (3)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
Well, I've done a search for the file "notifications" using the Tracker's Find utility, but it wasn't present on my disk. Then I opened the Notification preflet, I selected both checkboxes and now this file is present.
But the troubles which I described are still present: suddenly and randomly, the notification_server starts to peg the cpu, and to activate the notifications again, I have to reboot Haiku (manually restart the notification_server doesn't re-enable the notifications); maybe is related to the launch_daemon?
If I kill or quit the notification_server after the cpu issue, and then I manually restart the notification server, eg via the following command
~> open /boot/system/servers/notification_server
Or by a simple double click on notification_server in Tracker, this action doesn't reenable the notifications.
But after a reboot, notifications works again. (at the boot, the notification_server is started by the launch daemon, by the file "system" located in "/boot/system/data/launch")
There is a "new way", using the launch daemon, to manually start (on user's demand) app and services?
comment:3 by , 8 years ago
Can you still reproduce this? If so, could you attach Debugger to the notification server while it is in that state, then save a report for it?
You can control daemons using the launch_roster command, but most of the time, the launch daemon should relaunch crashed apps automatically.
The settings files should be at /boot/home/config/settings/system/notifications/.