An open community 
of Macintosh users,
for Macintosh users.

FineTunedMac Dashboard widget now available! Download Here

Previous Thread
Next Thread
Print Thread
Strange "diagnostic messages"
#31220 09/18/14 03:24 PM
Joined: Aug 2009
Likes: 4
grelber Offline OP
OP Offline

Joined: Aug 2009
Likes: 4
On a fairly frequent basis I've been getting diagnostic messages by the hundreds in batches (via Console), such as the following:

14-09-17 8:01:53.000 kernel: add_fsevent: unable to get path for vp 0xffffff8012f7de08 (ImapMail; ret 22; type 2)
14-09-17 8:01:53.000 kernel: add_fsevent: unabled to get a path for vp 0xffffff8012f7de08. dropping the event.

14-09-18 9:38:46.000 kernel: add_fsevent: unable to get path for vp 0xffffff80125a2f80 (crls; ret 22; type 2)
14-09-18 9:38:46.000 kernel: add_fsevent: unabled to get a path for vp 0xffffff80125a2f80. dropping the event.

I have no idea what they refer to and whether they represent something I should be concerned about and, if so, how to fix the issue.

Anybody have a clue?

iMac (mid-2011, 2.5 GHz Intel Core i5), Mac OS X Lion (10.7.5)

Re: Strange "diagnostic messages"
grelber #31243 09/21/14 11:54 PM
Joined: Aug 2009
Likes: 4
grelber Offline OP
OP Offline

Joined: Aug 2009
Likes: 4
Nobody know nothin'?! confused
That's even stranger than the query. frown

Re: Strange "diagnostic messages"
grelber #31252 09/22/14 12:59 PM
Joined: Aug 2009
Likes: 16
Moderator
Online
Moderator

Joined: Aug 2009
Likes: 16
I suspect you are going to have to talk to a software developer to get the answer. It could be a malformed call to an API or even an out of date API. From the couplets you provided we cannot even tell what application or kext is involved. All we know is that it is occurring in the kernel.

Last edited by joemikeb; 09/22/14 01:01 PM.

If we knew what it was we were doing, it wouldn't be called research, would it?

— Albert Einstein
Re: Strange "diagnostic messages"
joemikeb #31254 09/22/14 01:24 PM
Joined: Aug 2009
Likes: 4
grelber Offline OP
OP Offline

Joined: Aug 2009
Likes: 4
Thanks for the input. Unless there's a software developer lurking in the FTM wings, that's not likely going to happen.
Since this has been going on for years and doesn't seem to be causing any noticeable problems (other than 'clogging up' the diagnostic messages in Console), I'm just going to accept it as benign albeit annoying and move on.

Re: Strange "diagnostic messages"
grelber #31256 09/22/14 03:10 PM
Joined: Aug 2009
Likes: 16
Moderator
Online
Moderator

Joined: Aug 2009
Likes: 16
Originally Posted By: grelber
Thanks for the input. Unless there's a software developer lurking in the FTM wings, that's not likely going to happen.

Not just any developer it would have to be a developer working on the offending software. Try grabbing a half dozen or so log file lines before and after the offending message and maybe we could at least identify the offending app or kext.

By-the-way, I just scanned my log file (this is in Yosemite) for fsevents and the only entries I found were warnings for applications using API calls that have been deprecated and those all specified the API the call should be migrated to. So I am confident you have an app or kext with a malformed API call. You may just have an out-of-date app or kernel extension.

Last edited by joemikeb; 09/22/14 03:19 PM. Reason: add comment

If we knew what it was we were doing, it wouldn't be called research, would it?

— Albert Einstein
Re: Strange "diagnostic messages"
joemikeb #31257 09/22/14 03:24 PM
Joined: Aug 2009
Likes: 4
grelber Offline OP
OP Offline

Joined: Aug 2009
Likes: 4
It would seem that it has to do with Time Machine backup.
All those messages appear (but not every time) sandwiched between the following:

14-09-21 12:37:51.646 com.apple.backupd: Starting standard backup
14-09-21 12:37:52.142 com.apple.backupd: Backing up to: /Volumes/XYZ Backup/Backups.backupdb

14-09-21 12:38:38.068 com.apple.backupd: Backup completed successfully.

So even though there are all those "dropped events", the backup seems to have been successfully accomplished.



Re: Strange "diagnostic messages"
grelber #31266 09/22/14 07:53 PM
Joined: Aug 2009
Likes: 16
Moderator
Online
Moderator

Joined: Aug 2009
Likes: 16
Sounds reasonable, but could you send the entire thread (if there are too many repetitions delete the ones in the middle and annotate with <snip>)


If we knew what it was we were doing, it wouldn't be called research, would it?

— Albert Einstein
Re: Strange "diagnostic messages"
joemikeb #31269 09/22/14 08:45 PM
Joined: Aug 2009
Likes: 4
grelber Offline OP
OP Offline

Joined: Aug 2009
Likes: 4
Here's one of the smaller sets, from beginning to end of backup:

14-09-21 9:03:37.611 com.apple.backupd: Backing up to: /Volumes/XYZ Backup/Backups.backupdb
14-09-21 9:03:52.073 com.apple.backupd: 2.77 GB required (including padding), 802.28 GB available
14-09-21 9:04:04.000 kernel: add_fsevent: unable to get path for vp 0xffffff801556da28 (ujb90daz.default; ret 22; type 2)
14-09-21 9:04:04.000 kernel: add_fsevent: unabled to get a path for vp 0xffffff801556da28. dropping the event.
14-09-21 9:04:05.000 kernel: add_fsevent: unable to get path for vp 0xffffff801556da28 (ujb90daz.default; ret 22; type 2)
14-09-21 9:04:05.000 kernel: add_fsevent: unabled to get a path for vp 0xffffff801556da28. dropping the event.
14-09-21 9:04:05.000 kernel: add_fsevent: unable to get path for vp 0xffffff801556da28 (ujb90daz.default; ret 22; type 2)
14-09-21 9:04:05.000 kernel: add_fsevent: unabled to get a path for vp 0xffffff801556da28. dropping the event.

< snip – 14 items = 7 identical pairs omitted >

14-09-21 9:04:06.000 kernel: add_fsevent: unable to get path for vp 0xffffff801556da28 (ujb90daz.default; ret 22; type 2)
14-09-21 9:04:06.000 kernel: add_fsevent: unabled to get a path for vp 0xffffff801556da28. dropping the event.
14-09-21 9:04:06.000 kernel: add_fsevent: unable to get path for vp 0xffffff801556da28 (ujb90daz.default; ret 22; type 2)
14-09-21 9:04:06.000 kernel: add_fsevent: unabled to get a path for vp 0xffffff801556da28. dropping the event.
14-09-21 9:04:06.000 kernel: add_fsevent: unable to get path for vp 0xffffff801556da28 (ujb90daz.default; ret 22; type 2)
14-09-21 9:04:06.000 kernel: add_fsevent: unabled to get a path for vp 0xffffff801556da28. dropping the event.
14-09-21 9:04:08.454 com.apple.backupd: Copied 1231 files (12.4 MB) from volume XYZ.
14-09-21 9:04:08.634 com.apple.backupd: 2.76 GB required (including padding), 802.26 GB available
14-09-21 9:04:12.166 com.apple.backupd: Copied 578 files (717 KB) from volume XYZ.
14-09-21 9:04:13.602 mds: (Error) Volume: Could not find requested backup type:2 for volume
14-09-21 9:04:13.604 com.apple.backupd: Starting post-backup thinning
14-09-21 9:04:13.604 com.apple.backupd: No post-back up thinning needed: no expired backups exist
14-09-21 9:04:13.988 com.apple.backupd: Backup completed successfully.

Re: Strange "diagnostic messages"
grelber #31275 09/23/14 03:06 PM
Joined: Aug 2009
Likes: 16
Moderator
Online
Moderator

Joined: Aug 2009
Likes: 16
I can't tell you exactly what is going on, but now there is enough information to go on to draw reasonable conclusions…
  • Originally Posted By: your log file
    14-09-21 9:04:13.988 com.apple.backupd: Backup completed successfully.
    The backup is completing successfully so you still have a good Time Machine backup.
  • Originally Posted By: your log file
    14-09-21 9:04:04.000 kernel: add_fsevent: unable to get path for vp 0xffffff801556da28 (ujb90daz.default; ret 22; type 2)
    14-09-21 9:04:04.000 kernel: add_fsevent: unabled to get a path for vp 0xffffff801556da28. dropping the event.
    There is a glitch in your volume directory with an entry or entries with either non-existent or invalid file paths. backupd is making several attempts to resolve the issue(s) and then giving up and continues backing up the rest of the files.

If I were in your shoes I would run a version of DiskWarrior, TechTool Pro, Drive Genius, or even as a last resort Disk Utility apropos to your version of OS X to repair or rebuild your volume directory. If errors are found (and hopefully repaired), and if I had TechTool Pro or Drive Genius I would then invest the time to run a full surface scan of the hard drive. The surface scan is probably unnecessary, but given its proven efficacy in anticipating future drive failures (far superior to S.M.A.R.T.) it would make me feel more confident in my drive's health.


If we knew what it was we were doing, it wouldn't be called research, would it?

— Albert Einstein
Re: Strange "diagnostic messages"
joemikeb #31279 09/23/14 06:20 PM
Joined: Aug 2009
Likes: 4
grelber Offline OP
OP Offline

Joined: Aug 2009
Likes: 4
Once again, many thanks for your taking the time and trouble to assess the situation.

I ran Verify Disk under Disk Utility's First Aid with the following results:

Verifying volume “XYZ”
Checking file system
Performing live verification.
Checking Journaled HFS Plus volume.
Checking extents overflow file.
Checking catalog file.
Checking multi-linked files.
Checking catalog hierarchy.
Checking extended attributes file.
Checking volume bitmap.
Checking volume information.
The volume XYZ appears to be OK.

Under the circumstances (ie, no apparent issues requiring repair) I saw no point to running off Recovery HD in order to use the Repair Disk function to repair or rebuild the volume directory (and I don't even know if such is an option there, but I haven't looked).

As for performing a surface scan, I don't have a clue where I'd even start, and Pogue's Missing Manual doesn't even mention such.

Since my hard drive was replaced less than a year ago and since nothing truly wonky is happening, I think that I may take the 'wait and see' approach.

Time for a nice glass of Grenache/Shiraz/Mourvèdre, while I flip my latest batch from the primary to the secondary.

Re: Strange "diagnostic messages"
joemikeb #31281 09/23/14 06:50 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
If (as it appears) add_fsevent is running into a problem during a TM backup, the problem must be on the backup volume. TM wouldn't be adding a FileSystem Event to the volume it's backing up. It is creating files/folders on the backup volume, and each such creation would be an FSEvent.

Try verifying the backup disk. Be prepared to wait a while. You should probably temporarily disable automatic TM backups while doing the verify.

Re: Strange "diagnostic messages"
ganbustein #31283 09/23/14 10:40 PM
Joined: Aug 2009
Likes: 4
grelber Offline OP
OP Offline

Joined: Aug 2009
Likes: 4
Thanks for another place to look.
A while is right: it took about 2 hours to run Verify and Repair the backup disk. Disk Utility found nothing to repair.
Quo vādīmus?

Re: Strange "diagnostic messages"
grelber #31288 09/24/14 01:59 PM
Joined: Aug 2009
Likes: 4
grelber Offline OP
OP Offline

Joined: Aug 2009
Likes: 4
Add this to that:
Since running Disk Utility's First Aid (Verify on hard drive, Verify and Repair on the backup drive), even though nothing requiring repair was found, no more items of the ilk "kernel: add_fsevent ..." have shown up during TM backups. But only time will tell.
The only item which consistently continues to show up in the process is
14-09-21 9:04:13.602 mds: (Error) Volume: Could not find requested backup type:2 for volume .

ADDENDUM: Well, I was wrong: They're baaack. Another whack of "kernel: add_fsevent ..." items during the last backup.

Screw it! They're not interfering with operability, so I'm not going to pursue the issue (unless and until they do). Likewise for the mds error item noted above (which never disappeared).

Merci to all who contributed to the debate/effort.

Last edited by grelber; 09/24/14 04:24 PM. Reason: Addendum
Re: Strange "diagnostic messages"
grelber #31375 10/02/14 01:10 AM
Joined: Aug 2009
Offline

Joined: Aug 2009
I know this is not the case you are having but I did once have a weird error where the file count could not be resolved to the disk directory, resulting in a "Lost + Found" folder mysteriously appearing on the root level of the disk and every time I ran Disk Utility an entry to the folder was added. The SMS on the drive was incompatible with the SMS built into the computer resulting in an inconsistent count because the drive head would lock twice on movement. Maybe some kind of inconsistency in your case between the TM drive directory and the internal drive directory, a shot in the dark here.

Re: Strange "diagnostic messages"
slolerner #31384 10/02/14 11:44 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
SMS?

Maybe I'm having a senior moment (and will slap myself in the forehead immediately after posting this message), but I can't think of what SMS might stand for if not Short Message Service (the way text messages are sent on a cellular network), and that has nothing whatsoever to do with drives or filesystems or Lost + Found.

I also cannot fathom what you mean by "an inconsistency between the TM drive directory and the internal drive directory". Do you mean the file catalogs on the respective disk volumes? They need to be internally consistent, but don't need to be consistent with each other.

On an HFS+ volume, each folder has a link back to its parent. If, while checking the disk catalog, a folder is found whose parent does not exist, a "Lost + Found" folder will be created if necessary, and the orphan folder will have its parent set to that. Similarly for a file whose parent folder does not exist. These are both, of course, situations that should never happen. Disk Repair is paying homage to Murphy's Meta-law: Even things that cannot go wrong, will go wrong.

Re: Strange "diagnostic messages"
ganbustein #31385 10/03/14 12:08 AM
Joined: Aug 2009
Offline

Joined: Aug 2009
Sudden Motion Sensor. The Seagate drives that originally shipped with 2010 Macs, I think they were the Momentus, were eventually found to be incompatible and resulted in Lost + Found folders. I had never seen that error before. The computer and the drive had duplicate but out of sync actions when locking the drive head if the computer was moved quickly while running. This error was not explained to me completely but I was told it was an error in the directory matching the contents of the drive. People tell me things, it's not my fault if they aren't true! There was no more Lost + Found folder once I swapped out the internal drive for a WD and used the Seagate as an external. Seagate had it posted later on their website that this particular drive was incompatible for that reason.

As you ought to know by now, I am a TM noob and always will be. I thought perhaps there was some type of check-sum between the internal drive and TM. You know, to keep things from going wrong...

Re: Strange "diagnostic messages"
slolerner #31388 10/03/14 01:55 AM
Joined: Aug 2009
Offline

Joined: Aug 2009
Thanks. Having never owned a portable computer, I keep forgetting all their niceties.

Still, Journaling should be adequate defense against sudden drive disconnects, and Time Machine will flat out refuse to back up to a disk volume that is not journaled. Methinks there is something else going on.

Although...

It could be a poorly designed drive. The way journaling works is, before making any change to the disk catalog, it first writes to the journal a description of what it's going to do. Then it asks the drive for confirmation that the intent has been physically written to the disk. Only then does it begin the change. That way, the data on the disk is (or can be made) valid no matter when a disconnect should happen. If it disconnects before the journal entry is written, the action never gets performed, and the disk catalog is still as consistent as it ever was. If it disconnects during the change, when the OS remounts the disk volume, it notices the entry in the journal, and completes any partial change, bringing the catalog back to a consistent state. If it disconnects after the change, the catalog is again consistent.

But there's a potential failure point. If, when the OS asks the drive "Are you sure this journal entry has been written to disk", a poorly designed drive may think to itself "Well, it hasn't, but it's in my cache and I plan to write it. Even if I lose power, I have enough energy stored in the spinning platter to finish the write, so for all practical purposes, it's written." Based on that (faulty) reasoning, the firmware on the drive responds "Yeah, yeah. I got it. Consider it written."

The drive has lied. It's a lie that won't be found out if the drive merely loses power, and that's why they think they can get away with it, but it's a lie. For journaling to work the way it's supposed to, the drive must not say something has been written until it truly has been written. (Even if it's just a power failure, the drive is gambling that it has enough stored energy to not only write what's in the cache but also do any necessary error recovery in the case of write errors. Seems like pretty flakey logic to me.)

So, OK, I see what seems to be happening. And you're right. The cure is to replace the drive by one with honest (aka non-buggy) firmware.

Re: Strange "diagnostic messages"
ganbustein #31390 10/03/14 12:17 PM
Joined: Aug 2009
Offline

Joined: Aug 2009
Got it. Thanks.


Mid 2010 MacBook Pro 13"
2.4GHz, 750GB SATA HD, 8 GB RAM, OS 10.7.5
1 HDX1500 2TB Ext.HD, 2 HDX1500 1TB Ext.HD
HP Laserjet 6MP printing postscript via 10/100 Intel print server
Netgear WN2500RP Range Extender (Ira rocks!)
Linksys WRT1900AC Wireless Router
Brother MFC-9340CDW Color Laser
iPad Air

Moderated by  alternaut, dkmarsh, joemikeb 

Link Copied to Clipboard
Powered by UBB.threads™ PHP Forum Software 7.7.4
(Release build 20200307)
Responsive Width:

PHP: 7.4.33 Page Time: 0.037s Queries: 50 (0.029s) Memory: 0.6680 MB (Peak: 0.8044 MB) Data Comp: Zlib Server Time: 2024-03-28 19:45:37 UTC
Valid HTML 5 and Valid CSS