Opened 3 years ago

Last modified 2 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:
Has a Patch: no Platform: x86

Description

hrev50067

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 Changed 3 years ago by humdinger

The settings files should be at /boot/home/config/settings/system/notifications/.

comment:2 Changed 3 years ago by Giova84

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 Changed 2 years ago by pulkomandy

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.

Note: See TracTickets for help on using tickets.