This happens when some application is not putting in a valid/correct file system type into things like statvfs.
Eventually this will bubble up to udisksd if the storage in question is handled by the udisk subsystem.
I had this occur when installing 'swapspace' on Ubuntu 18.04 (from the repo, confirmed with a current build from source zip).
How to find whodunnit: here is what I did.
- On what computers does it occur?
It was only on those that I recently moved to swapspace
- In what log files does it occur? The usual log files, but also in messages
who writes to messages on an Ubuntu system... a flag goes up: bad
coding somewhere, someone released something not properly coded
do run on Ubuntu/Debian
- When does the message appear?
In my case a flurry of those every 5 minutes, only on hosts that did
recently receive swapspace (to prevent browser lockup and virtual image
size overgrowth for browser images, manage swapspace better)
Once you have determined which one of your apps is causing the appearance of
invalid file system descriptors in a storage related call:
stop the application (I mounted a swap partition and emptied all swapfile
files into it)
remove files the app is creating if possible, or move everything over,
get to a clean environment where the app starts up 'new' (I deleted all
swap files after everything was offloaded again to the traditional swap
partition)
Start the offending application.
In my case nothing happened at first, it has to first do some swap files
before losing its marbles. In the swapfile case it is the use of a
glibc internal variable for the allocated swap file types, well, glibc
may have a use for its variable and change the content, or even use it....
use what swapspace put in there?
also other errors in swapspace made that the issued type actually can
never be correct....
Make the application generate the error.
I did create a situation where swapspace does actually have to do what
it says it does
once swap files were there, the messages did appear (it does not matter if
the messages in this case relate to files owned by swapspace, it could be
a consequence of swapspace actually changing that varialble, luckily here
it was simple, they were all related to the swap files)
Find out under which conditions the errors appear.
In my case: every 5 minutes when the swapspace cron ran, and
each time I manipulated the swap files (through proper swapspace commands).
A lot of things do happen before a call bubbles up to the udisks subsystem.
The message says udisk received an invalid code in a call.
There is a whole call tree before that which ends up in udisks.
It did take a lot of log file digging, clean startups (once I had swapspace identified, with and without, comparing recently changed systems to 'ran forever' ones), then I did go into the swapspace source and looked where there is a file system interaction that could cause this, and found a big pile of poo left by some ego programmer and never checked nor tested properly....
The more important question is then: what now, the dog caught the bus and what next.
I do not fight with them open source ego thin-skinned overambitious with no backing open source ID-10ts.
The real reason I use open source:
not quality, oh no, most is hobby typists trying to do open source to impress girls, so it seems.
In a closed system I would now be back to square one (need to fix my swapping)
in open source: it will take me less than an hour to check the current source, replace all deprecated system calls, and (about 10 minutes) find all illegal uses of a particular glibc variable in there and work around it.
so yep, while open source is very low quality, done by ego maniacs who have no clue about design, test, verify, pilot, and for who context and scope are no words: I don't need to wait for someone to fix anything for me.
However, insisting on 'proper submission' for a big blooper like this will make that the usual happens: people will be frustrated with 'open source does not work' and we all lose. Because this particular thing I ran into can actually cause severe 'unrelated' data loss, system hangup, mayhem and destruction, the world comes to an end. (remember, alters a glibc internal variable.).
my wish:
change open source:
no accepting of any code unless peer reviewed and signed off, between peers at least one qualified peer (computer science degree, math, physics go too). No hobby programmers on system critical items. Doing something wrong for a long time and not getting caught does make nobody an expert.
.. and define peer review ..
make sure the work is done, this means:
symptom, error impact analysis, fix, correctness, impact analysis, verification, unit testing, system testing, release testing, all need to be fully protocoled, and the test protocols need to be properly documented
a coder may never certify their own work!