Giters

xrmx / bootchart

merge of bootchart-collector and pybootchartgui

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

mounting/unmounting of /lib/bootchart/tmpfs{,*}

Xake opened this issue · comments

commented

So I have noticed a little message on my fedora rawhide machine and on my gentoo machie when trying to use bootchart:
[ 48.712853] bootchart-collector unmounted proc / clean exit
[ 48.712855] umount /lib/bootchart/tmpfs: Device or resource busy

And mount shows:
$ mount | grep bootc
none on /lib64/bootchart/tmpfs type tmpfs (rw,nosuid,noexec,relatime)
none on /lib64/bootchart/tmpfs/proc type proc (rw,nosuid,nodev,noexec,relatime)

However bootchart is not running anywhere.

This seems to be because of bootchart-collector always mounts and umounts /lib/boostchart/tmpfs{/,/*} no matter really what options is passed.
The problem with this seems to be here the following:

  1. bootchart-collector starts by bootchartd ad mounts everything
  2. "bootchart-collector --dump" mounts everything again, and then tries to umount it
  3. something fails

This also got me thinking, does --dump really even need to mount this structure all over again? As long as the initial bootchart-collector it should dump data from is running, this env should already be there.

So maybe this is two issues, bootchart-collector fails to clean up after itself, and bootchart-collector should not mount everything all over again.

commented

Cool analysis, this was already reported in debian and verified ehre locally too http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604634 . I've done some work on this some times ago without satisfactory results, i.e. removing only one in three mount leaks. Will try to give another stab at it in the weekend. Thanks.

commented

One problem may also be that it seems like bootchart2 does not always know what it wants to do.

for example "bootchart-collector --dump" tells you that it it dumps the information and then exit, just like it tells you for --usleep. It does not tell you however that it kills the bollector after it have dumped all the information from it.

So what do we want bootchart-collector --dump to do? Only dump the information, and then implement another function that exits the background-collector? Or do we want "bootchart-collector --dump" to still kill the one in background, but then clean upp after it?

commented

I have looked a bit at the code, and got a question:

Why do we not TERM the bootchart-collector (instead of kill it), and trap that signal so that bootchart-collector unmounts and cleans up after itself on shutdown?
If I was to propose this changes in patches, would they be turned down?

commented

I won't turn down any patch that works fine :)

BTW umounting manually the proc dir after every bootchart collector has exited does work no? So some bruteforce umounting instead of poking with signals may work too? Ugly i know.

commented

Ugly indeed, and as far as I can tell only the collector itself knows where the tmpfs is currently mounted (as bootchart may have moved itself into /dev because of ramdisk, or at least there is at least code for something like that).
Currently even "bootchart-collector --dump" fails to clean up after itself because it holds /lib/bootchart/tmpfs busy while trying to umount.

That is why I think the most clean way would be to when the env has been mounted trap TERM, and have term_cleanup() or something like that unlink kmsg and umount everything delayed (so that all current refs into the mount may stay alive as long as the process holding them are, but no new processes may use the mount).

commented

This should be fixed with your latest commit series starting from e8fe096