4

my system logs of my Ubuntu 18.04 Intel NUC are getting spammed by these error messages:

udisksd[1369]: udisks_mount_get_mount_path: assertion 'mount->type == UDISKS_MOUNT_TYPE_FILESYSTEM' failed

I figured out that the spamming is due to Docker which is installed and got some containers running. But with Docker and all containers stopped the error also occurs in the syslog but not that often. Googling this error message didn't get my any help. It is not hardware related since I changed the NUC and I have a similar configured NUC running which doesn't have this errors.

Does someone have any clue how to investigate this issue?

2 Answers 2

2

I finally solved it: in my case it was in fact Docker related. I stated in my question that I stopped Docker and the problem persisted. This is still true. The problem was due to booting with Docker auto start enabled while it tried to start a container which had a volume on a LUKS device that wasn't present at boot. After stopping Docker the udisksd log spam persisted. I solved it by disabling auto start for the container which has its volume on a disk that is not present at boot time. After that no more errors appeared and I was able to manually start the container. Thanks for the input.

-1

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.

  1. On what computers does it occur? It was only on those that I recently moved to swapspace
  2. 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
  3. 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)
  4. 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)
    
  5. 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....

  6. 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)

  7. 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!

1
  • 6
    I'm having a difficult time seeing a clear answer to the OP in this wall of text. Perhaps you could remove the ranting parts? Jan 17, 2020 at 23:15

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .