knotify4 going crazy & breeding like rabbits (+ linguistic discussion of the role of "greetings")

gene heskett gheskett at
Wed Feb 22 06:33:05 GMT 2012

On Wednesday, February 22, 2012 01:16:28 AM Duncan did opine:

> gene heskett posted on Mon, 20 Feb 2012 20:29:31 -0500 as excerpted:
> > On Monday, February 20, 2012 08:08:28 PM Chuck Burns did opine:
> >> On 2/20/2012 5:00 PM, gene heskett wrote:
> >> > Greetings;
> ... and salutations! =:^)
> (Completely OT I know, but while I understand the role of greetings IRL,
> at least in part, from the newcomer to signal the event and focus
> attention on the his arrival (among other things, serving notice that
> intended private conversations may need to stop temporarily), I never
> quite understood the role on lists, newsgroups, forums and the like,
> where one presumably /knows/ when one starts a new message or thread,
> and that doing so signals the same functional type of "context switch"
> that "greetings" does IRL.  As such, for lists, newsgroups and the
> like, I'm accustomed to simply starting my question/answer/whatever, no
> greeting or similar redundancies.  I know a lot of others do likewise,
> while others include it as they would IRL or in formal non-electronic
> written correspondence.  But at times I've simultaneously wondered
> bemusedly at a "Hi", "Greetings", etc, opening, and whether my omission
> thereof inadvertently causes mild offense.  This is obviously one of
> those times...
> The wictionary entry for "greeting" notes that it's less common in
> email, etc, as well.  So... why /do/ you (plural "you", addressed to
> anyone who wishes to respond) include such an opening in electronic
> messages such as lists, email and news messages?  Have you even ever
> thought about it before?  Do you get offended if others don't as well? 
> Are these questions just really strange and off the wall, making me
> look crazy? "Inquiring minds want to know!" =:^)
> >> > I have so far today, killed around 75 copies of /usr/bin/knotify4
> >> > which is pegging out all 4 cores of my phenom, and running it up to
> >> > 70C+.
> >> > 
> >> > Killing all copies (which is puzzling because killall can't find
> >> > them but htop can) cleans the system up&  brings back normal
> >> > operation.
> Which killall form did you use?  Quoting the killall (1) manpage:
> killall  sends  a signal to all processes running any of the specified
> commands[.]  If the command name is not regular expression (option -r)
> and contains a slash (/), processes executing that particular file will
> be selected for killing, independent of their name.
> <<<<<
> Note that kde uses a special launcher, kdeinit4, to launch many of its
> "core" programs.  The commandline for these will be kdeinit4 <appname>
> <app-parameters>.  The reasoning is that this allows more efficient
> shared-objects loading, so faster launching and more efficient memory
> usage.
> I'm not sure that's exactly what's going on here (my single knotify4
> instance appears to be a direct child of init, pid 1, and it doesn't
> appear with the kdeinit4 prefixed on its command line), but it is indeed
> quite possible for applications to be launched such that the name and
> the command-line don't match, such that a killall without -r or / won't
> see it.
> As mentioned in the manpage quote above, the absolute executable file
> path (detected by the presence of a / in the name) or a regular
> expression (using -r) can be used instead.  It's possible these would
> get the ones a standard killall misses.
> Of course, the other possibility is that killall sends the signal, but
> the process ignores it, especially if the process is hung.  The default
> SIGTERM (-15) would allow this.  SIGHUP/-1, SIGINT/-2, SIGSEGV/-11, and
> finally SIGKILL/-9, in order of increasing severity, can be used
> instead, with SIGKILL being "kill with predjudice", that is, don't give
> the app a chance to clean up or to say no, just kill it.  Of course,
> this last one can leave half-written files and the like around.  The
> kernel will close them and return memory resources to the system, but
> if it was a config file or the like, it could cause problems at the
> next start, so SIGKILL/-9 should always be used as a last resort.
> Of course signal types is pretty basic Unix, so you probably knew that
> bit, but others reading might not.
> But if killall found at least one process to deliver the signal to, it
> returns success whether or not the process actually responded, while if
> it didn't find a process at all, it returns failure status and complains
> to STDERR, and it's likely that complaint that you were indicating with
> the "killall can't find them" bit.  Just covering the bases, in case...
> >> > But in half an hour I am back to 4 to 6 copies and a pegged cpu.
> >> > 
> >> > This seems to go along with an uptime of 10 days or more, currently
> >> > at 18 days.
> It's likely that few enough people run kde for that long at a time, so
> bugs aren't as likely to be reported.  I happen to run git kernels here,
> and even the kernel merge window (during which I don't normally rebuild
> and test new kernels, just in case there's a crazy "eats filesystems" or
> "eats md/raids" bug during that time, that presumably I'd know about by
> a few days after the merge window closes if I decide to bisect
> something) is only two weeks, so 18 days is likely at the long end for
> no-reboots, here, at least on my main machine.  (My netbook can go much
> longer, but it can spend a month or six weeks in suspend-to-disk
> hibernation, too; it's not like it's actually /running/ more than
> perhaps 24 hours of that.)
> On Linux, that's not an excuse.  On Linux, if it can't handle at least
> six months uptime, it's considered seriously bugged, and rightfully so.
> However, it /is/ a fact.  Long uptime bugs simply won't get as much
> reporting, as fewer people see them, simple as that.
> >> > Is there a permanent fix for this other than switching to (I'd
> >> > rather just have somebody shoot me) gnome or even (quite a bit
> >> > better IMO) xfce?
> >> 
> >> I hate to sound like a smartass..
> > 
> > Not at all.
> > 
> >> but have you tried logging out of kde,
> >> and back in? Your uptime won't suffer, and KDE will be able to
> >> completely refresh.. There may some sort of leak somewhere..
> > 
> > I suspect there is, but running it down seems nearly impossible when
> > it doesn't show up for 2 weeks.
> > 
> >> AFAIK, no one has reported a bug about this.. perhaps if you have
> >> time, you can try to narrow it down to exactly what.
> See what I said above about long-uptime-bugs.  If it's possible to do
> something with it... the whole kde ecosystem should thank you, because
> good bug reporting is rare enough, and good bug reporting of long uptime
> bugs even rarer, but getting them fixed helps stability even for shorter
> uptime people, so it's a good thing... where it's at all possible, of
> course.
> >> You can also try disabling all notifications.. ymmv
> > 
> > I do use inotifywait
> Entirely different kind of notification! =;^)
> Inotify and similar "file event" notifications are often what kernel and
> sometimes app developers mean when they talk about notifications.  They
> notify an APP (not the user, tho the app could potentially notify the
> user if appropriate) about file accesses, changes, etc.  At a similar
> level, udev notifies apps such as kde's device notifier (which in turn
> notifies the user if appropriate) when devices appear or disappear, etc.
> knotify4, OTOH, deals entirely with user-level-app-to-user event
> notifications for things like mail delivery, media changes in the media
> player, keyboard shift-level changes, etc.  These "user notifications"
> are most often either sound events or popup dialogs (now often handled
> by the notifier icon in the systray, tho I'm not sure all such dialogs
> are handled that way yet), but can also involve marking/flashing a
> taskbar entry, logging the event to a file, or running some other
> command.
> It's generally that first one, playing a sound, that causes problems, on
> systems where either the sound system isn't properly configured or where
> it otherwise isn't entirely reliable.  This is almost CERTAINLY what's
> happening in your case.
> > I note that I found another copy of it the 2nd time I went on
> > a killing rampage today, about 75 processes down from the top, killed
> > it too, and the problem has not come back, but something has called
> > up 2 copies of it since I nuked them all.
> > 
> > If that had a visible link to whatever restarts it, that would help
> > considerably in tracking this down, but apparently no one knows what
> > (re)starts it.
> knotify4 is part of kde's internals.  Any time an event occurs that's
> configured to play a sound, popup a notice window, etc, knotify should
> respond with the appropriate action.  But as I said, sound in particular
> can be somewhat problematic.  If the sound doesn't play as knotify is
> configured to play it, that instance of knotify will hang, waiting for
> the event to finish, and at the next such event, kde (kded, maybe? I'm
> not sure exactly which component; maybe it's invoked by the triggering
> app directly, using a library that's part of kdelibs and thus available
> to any kde app?) will find no responding knotify4 and thus will spawn
> another one.
> But if the one is hung waiting on a resource lock it can't get
> (typically it can't open the sound device), and the next one needs it
> too, guess what, the next one gets in line behind the first.
> Lather, rinse, repeat.
> When you notice and start killing all of them, once you kill the one
> that was originally hung (probably one of the oldest, or as you
> mention, one without a lot of CPU time, as it was hung, while the
> others were CPU-poll spinning, waiting on the resource to become
> available), the kernel releases that resource with the killing of the
> hung process, pulling the plug on the waiting queue of all the others,
> thus draining it.
> And since the problem with the sound device that actually hung the
> original knotify4 often has something to do with it suspending after an
> idle timeout, or with something grabbing the sound device exclusively
> (some hardware can cope with multiple streams, some not, thus the use of
> sound servers or alsa's software stream mixer device, dstream or some
> such, I think it's called), but in some cases an app will apparently
> still try to do an exclusive lock on an otherwise sharable device), thus
> triggering the original problem when the original knotify4 tried to
> access the sound device, by the time the original locked-up knotify4 is
> killed, the intermittent problem has generally gone away, so pulling the
> plug allows all those spawned knotify4s to do their thing one right
> after the other, without the problem reoccurring immediately.
> But then later on, when the sound device suspends or something else
> grabs exclusive access again, the whole thing is setup for another
> go-round.
> > But:
> > [root at coyote eagle]# lsof |grep knotify4|wc -l 1198
> > 
> > How the heck can you separate the wheat from the chaff in a list that
> > long..  :(
> FWIW, 1317 here, and to my knowledge, everything's working fine, here,
> just one pid listed for all those, etc.  So 1000+ open files for knotify
> would seem to be normal.
> > Half of that is vlc linked:
> > [root at coyote eagle]# lsof |grep knotify4|grep vlc|wc -l 604
> > 
> > And I haven't specifically used vlc that I know of in months, so I
> > assume a news site I have visited must have called it up.
> Taking a look thru the 1317 listed files, it seems that most of them are
> *.so shared-objects aka libraries with FD=mem, TYPE=REG.
> That many of those shared-objects are vlc related is almost certainly
> due to your use of the phonon-vlc backend -- phonon is how kde handles
> sound, and if it's configured to use the phonon-vlc backend, with all
> the plugins that vlc has, and the fact that knotify4 is responsible for
> kde's sound effects...
> FWIW, 699 appear to be vlc related, here.
> Then there's the other usual X and kde libraries in the list...
> Try this, the grep -v excludes any line with "lib":
> lsof | grep knotify4 | grep -v lib | wc -l
> FWIW, 87, here.  That look a bit more reasonable? =:^)
lsof | grep knotify4 | grep -v lib | wc -l

> There's the current working directory (FD=cwd, TYPE=DIR), the root
> directory (FD=rtd, TYPE=DIR, NAME=/), the executable itself (FD=txt,
> TYPE=REG), several memory-mapped font resources (it's an X app, after
> all)
> Then there's the various filedescriptors (FD=0r 1w 2w... etc,
> filedescriptor, read/write/u=both, TYPE=CHR/REG/0000/FIFO/unix/netlink,
> character-device, regular file, unknown/(anon-inode),
> first-in-first-out, unix socket, netlink socket, respectively).  It's
> interesting to note that STDIN is
> /dev/null and STDOUT and STDERR are mapped to $HOME/.xsession-errors, as
> might be expected for an X app.  15 (numbered 0-14) filedescriptors are
> open in this way.  Other than the first three STD*, the rest are various
> fifos, pipes, anon-inodes, unix sockets, etc.  Of interest are FD=8r,
> the kde system config cache (ksycoca4) regular file, FD=9u, netlink
> KOBJECT_UEVENT, and FD=13r, the /dev/urandom character-device.
> Here, the same set (same pid for all) is listed three times, once
> without a "task ID" following the PID, and once each for two different
> task-IDs. I don't have much of a clue what task-id is. (??)
> But it's worth noting that it's the same PID and the same set of open
> files, three times.  87/3=29.  29 actual non-library files... listed
> three times each.
> If the same applies to the 1317, I didn't rigorously check, but it
> looked that way, then it's 439 files, listed three times each, 410
> shared objects (libraries and plugins), 29 other files.  And the vlc
> files are all shared objects, 699/3=233 of them, 233 of the 410 shared
> objects.
> > ATM, I have an eagle session on a pcb going in another window, pending
> > info that I screwed the moose, so I would rather get that fixed before
> > I reboot kde.
> That's semi-gobbledegook, here, but given that in previous mails you've
> mentioned some sort of CAD/CAM setup, I'll assume that's what you're
> referring to.  Yeah, letting it finish doing whatever it's monitoring/
> controlling before a reboot might indeed be useful.

eagle is a pcb design package. With various feature sets, free to about 
$2500 a seat.  Obviously I'm using the free version.  I am taking its 
output, running that through pcb2gcode, and then etching the pcb on my toy 
milling machine.  ATM I am making the sensor board for a position encoder, 
which in turn will tell LinuxCNC where in the rotation my equally toy 
lathes spindle is, and knowing that, LinuxCNC can drive the carriage, 
either for a shaped normal turning, or even, using a single toothed tool, 
carve threads at even non-integer threads per inch (or cm)

That should explain some of the gobbledegook :)

> Meanwhile...
> Some kde settings experimentation may be useful here, but one or more of
> the following should help.  Some are short term workarounds, some longer
> term potential fixes:
> Short term: Under common appearance and behavior, application and system
> notifications, manage notifications, on the player settings tab, try
> setting no audio output.  This may or may not kill the existing locked
> up knotify4s, I'm not sure, but it should prevent the problem from
> reoccurring, assuming I'm correct and it is an audio issue of some
> sort, at least, because it simply no-ops the problematic calls.
> Medium/long term:  In the same place, you can try setting an external
> player instead of kde's normal (phonon-based) sound system.  Back in
> kde3, I did this for awhile when arts was hopelessly screwed up, but
> I've not had to resort to it in kde4.
> The trick is finding an appropriate player, probably setting it to
> no-gui if it's a gui player, etc.  I tried a couple things before I
> found a solution that "just worked" for me.  It involved the playsound
> binary from the sdl-sound package (installed here for something
> unrelated), but played at full volume, the sound effects overpowered
> whatever else I happened to be playing, so I ended up setting up a
> script that played it at reduced volume.
> Here's $HOME/bin/ (vol can be set up or down if necessary,
> but .5 was a good balance for me):
> #!/bin/bash
> # To play something at a bit lower volume (1=100%, normal volume)
> vol=.5
> playsound --volume $vol $@
> Then I just set as the player, and it worked.
> Short term, could be longer term if you like it, or QUICKLY shut off if
> you don't!:  Use a "visual bell" instead of sound effects.  This
> involves two configuration changes:
> Under common appearance and behavior, application and system
> notifications, system bell, check use system bell instead of system
> notifications.
> Under workspace appearance and behavior, workspace appearance,
> accessibility, on the bell tab:  Check use visible bell, and experiment
> with invert and flash screen, with timing, as desired.  You can set an
> audible bell as well, but you may not avoid the sound lockups, that way.
> FWIW, I've used this before.  The effect can be disconcerting at first,
> especially if it happens when you're concentrating on something and have
> forgotten all about setting this up.  But it DOES tend to get your
> attention, as long as you're looking at the screen, of course.  The
> feature is designed for deaf folks (thus accessibility) or for use in
> meetings, etc, where a sound would be disruptive.  But it's a nice
> option to have.  Just don't have a heart attack the first time you're
> concentrating on something and the screen inverts/flashes!  As I said,
> it CAN be disconcerting, but forewarned is forearmed.
> The proper (user/admin-level) fix:  Depending on the exact nature of the
> problem and your hardware, this could take several forms.
> As mentioned above, one trigger of the problem can be sound device power
> saving mode.
> On a laptop that's battery powered much of the time, you probably want
> to keep that on to save power when you're not playing anything.  In
> that case, setting visual bell for notifications as suggested above is
> a good idea, since (a) that way you don't have to wake up the sound
> device just to play a notification ding, and (b), laptop/netbook use is
> far more likely to include use in meetings, etc, where the sound isn't
> desirable anyway.
> If you do want to keep sound notifications on a laptop/netbook/etc, but
> still don't want to use too much battery running the sound device when
> there's nothing playing, playing around with its power-saving settings
> may be useful.  Setting a too short (say 1 second) idle-timeout is known
> to be highly problematic on some hardware.  It wasn't kde context, more
> like general alsa and kernel device driver context, but I happened upon
> this I think just yesterday, and it makes sense, 10 seconds is the
> recommended MINIMUM.  I'd actually suggest something like 30 seconds to
> perhaps even five minutes (or even 15, consider how much power those
> 100% CPU cycle apps will use!), since I believe part of the problem is
> race conditions where it gets a wakeup just as it was powering down,
> potentially leaving the app trying to play the sound thinking the
> device is responding, but it just powered down instead, so the app ends
> up waiting forever, especially if the device doesn't signal the app
> correctly when it does wake back up.
> On a desktop/workstation that's on A/C power all the time, just disable
> audio device power saving entirely.
> Unfortunately, directions for setting/disabling audio device power
> saving aren't something I can deal with here.  If kde deals with it at
> all, I don't have that bit of it installed, and individual device
> driver settings are likely to be just that, individual.  Check the docs
> or try posting to your distro's lists/forums.
KDE doesn't handle that at all well yet IMO.
> Another possible fix is device preference order.  This is in kde
> settings, hardware, multimedia, phonon.  When I first switched to the
> phonon-vlc backend, everything seemed to work great (far better than the
> phonon-xine backend, now not even available on some distros as upstream
> kde dropped support for it).  But somewhere in the 4.7 or 4.8 timeframe
> (I ran the 4.8 betas and rcs and don't remember exactly when it showed
> up), the previous config quit working so well.  Sound continued to work,
> but I'd get popups saying it was falling back to a different device as
> the preferred device wasn't working.
> The fix was to select every possible device (unless you have multiple
> physical devices and want some routed differently, do this for audio
> playback itself, not the individual purposes, notifications, music, etc)
> and hit the test button.  If it works well, move it up.  If it doesn't,
> move it down.  Do this when you're having problems (sometimes, like
> right now, all devices test as working here, they didn't when I did the
> testing and reordered them when I had the problem).
> My list of devices has four listed for one physical device, Default,
> which will play thru the alsa default device, normally the first one
> detected if there's multiple physical devices, and three different
> listings for the hardware (AMD AMD8111, in my case, one saying /just/
> that, one with the name twice, with "(Default Audio Device)" in
> parenthesis, one with the name twice, and "(hw:0,0)" in parenthesis).
> I ended up with Default (no hardware name) at the top of the list.  The
> twice-listing with (Default Audio Device) next, the single-listing
> third, and the twice-listing with (hw:0,0) last.
> Since then, I've had no more phonon-fallback notification popups. =:^)
> But I'm not entirely sure if I really fixed it, or if that was a beta/rc
> problem that was fixed with kde 4.8.0, or if I just haven't hit the
> conditions that triggered it again.  Whatever, I'm just happy to not be
> seeing those popups and thus worrying about sound (tho as I said, it did
> continue to work, I just saw the popups sometimes, and got worried).
> Note that I didn't have the "breeding like rabbits" knotify4 problem
> here, at least that I noted (as I said I don't tend to stay up for more
> than a few days at a time, testing kernels, etc), only the irritating
> popup problem.  However, it could still be a device order issue, just
> with a slightly different manifestation than I had.
> Finally, it's also possible to switch phonon backends.  You apparently
> have phonon-vlc configured, as do I.  There's also the phonon-gstreamer
> backend, if you wish to try it.  The phonon-gstreamer backend /does/
> happen to be the kde (and gentoo) default, so it might be worth trying.
> But I haven't tried it, mostly because I have bad memories about trying
> to get gstreamer to work a long time ago due to problems that are almost
> certainly long gone, so it'd probably work just fine now, but I've just
> never actually needed to install gstreamer as there have always been
> other alternatives that worked, so I haven't.  (Of course, the fact that
> I'm on gentoo and would thus have to build all those extra components
> just to try gstreamer out... when it would at least at first be for just
> one thing since I have alternatives to gstreamer installed for
> everything else, is part of the picture as well.  That's a big barrier
> to cross just to try it out.  If I were on a binary distro and all
> trying out gstreamer involved was downloading and installing pre-built
> binaries, the barrier would be lower, and there's a fair chance I'd
> have tried it again by now.)
> Anyway, I can't say what the phonon-gstreamer backend might do
> different, but it could be worth trying, if you're having problems with
> phonon-vlc, especially if you're on a binary distro so don't have the
> high barrier to trying it out that I do, and/or if you already have
> gstreamer itself installed, as many binary distro users as well as
> gnome users, for other reasons.

Much of the above I skimmed through, but nothing went ding.  It hasn't come 
back again either, and I'm up 19.5 days now.  I will, the next time it 
happens, have htop sort on time and see if I can make any sense of it that 
way.  Sound was however, working all the way through that kill session.  
Still is.

Thanks Duncan

Cheers, Gene
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
My web page: <>
The probability of someone watching you is proportional to the
stupidity of your action.
This message is from the kde mailing list.
Account management:
More info:

More information about the kde mailing list