Summary: | KDE Partition Manager taking an extremely long time to start | ||
---|---|---|---|
Product: | [Applications] partitionmanager | Reporter: | Dal Monico <dal.delmonico> |
Component: | general | Assignee: | Andrius Štikonas <andrius> |
Status: | RESOLVED WORKSFORME | ||
Severity: | minor | ||
Priority: | LO | ||
Version: | 3.3 | ||
Target Milestone: | --- | ||
Platform: | Manjaro | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Dal Monico
2018-11-01 04:39:20 UTC
Can anybody retest this bug with KPM from git? There were a lot of changes which might affect it (libparted backend was replaced with sfdisk). fstab is not used at by KPM during the scan (but maybe some of the tools like libparted could have used it...). KPM only checks whether partition is mounted during the scan, it shouldn't try to mount it. Thank you for your attention on this matter. I installed kpmcore-git and partitionmanager-git. The newer version ran fine without the NFS entries in fstab. Unfortunately, when the NFS entries were returned to fstab the exact same delays were experienced when starting Partition Manager. I can't thank you enough for your rapid response. KDE definitely has a hard working team of developers in place. Please let me know if there are any further diagnostics you would like run. (In reply to Dal Monico from comment #2) > I installed kpmcore-git and partitionmanager-git. The newer version ran fine > without the NFS entries in fstab. Unfortunately, when the NFS entries were > returned to fstab the exact same delays were experienced when starting > Partition Manager. > Sorry to ask again but can you please double check that it's running sfdisk backend? You can go to Setings->Configure->Advanced and it should show. Or if you enable log in Settings->Panels Shown->Log output. Anyway, I have some idea how we can debug this a bit. But it would be much better if you are actually able to compile kpmcore and partition manager from git. I can help you with that if you are unsure. My idea is to print all commands that are executed to standard output, so that you can see which commands are run (if you run partitionmanager from the terminal). Then we can see what is outputed just before it starts automounting, so that we know which command triggers systemd automount. Then depending on our findings we can thing how to avoid that. So, do you think you'll be able to help me with that? (I have no NFS setup here, so it would be hard for me to solve this without help) Sorry I did not see your message until just now. I checked and it was indeed running the fsdisk backend. I am going to see if I can get KPM to start properly with a systemd mount unit. I will get back to you with the results. I will try my best to work with you on this issue. I greatly appreciate your efforts to improve KPM. Well I'm happy to report good news. I found a solution for this by writing a systemd mount unit. I only just now wrote the unit and tested it out briefly. It seems absolutely problem free in my limited testing so far. KDE Partition Manager starts up immediately now. There is no delay when booting with the server offline using systemd to mount the NFS share. NFS share mount unit: ``` /etc/systemd/system/media-nfs-3tb.mount ``` ``` # /etc/systemd/system/media-nfs-3tb.mount # sudo systemctl enable media-nfs-3tb.mount # sudo systemctl start media-nfs-3tb.mount # sudo systemctl daemon-reload # sudo systemctl status media-nfs-3tb.mount # sudo systemctl is-enabled media-nfs-3tb.mount [Unit] Description=Mount 3tb NFS Share Documentation=man systemd.unit man systemd.mount man systemd.special After=remote-fs-pre.target After=network.target Wants=network.target After=network-online.target Wants=network-online.target After=NetworkManager-wait-online.service Wants=NetworkManager-wait-online.service Conflicts=umount.target Before=umount.target DefaultDependencies=no [Mount] Where=/media/nfs/3tb What=192.168.0.102:/srv/nfs/3tb Type=nfs Options=noauto,noatime,nodiratime,x-systemd.automount,x-gvfs-hide,timeo=14,x-systemd.idle-timeout=1min [Install] WantedBy=multi-user.target ``` NFS Automount Unit: ``` /etc/systemd/system/media-nfs-3tb.automount ``` ``` # /etc/systemd/system/media-nfs-3tb.automount # sudo systemctl enable media-nfs-3tb.automount # sudo systemctl start media-nfs-3tb.automount # sudo systemctl daemon-reload # sudo systemctl status media-nfs-3tb.automount # sudo systemctl is-enabled media-nfs-3tb.automount [Unit] Documentation=man systemd.unit man systemd.mount man systemd.special Description=Automount 3tb NFS Share Before=remote-fs.target [Automount] Where=/media/nfs/3tb TimeoutIdleSec=1min ``` I'm sure I probably listed far more services and targets than necessary in the unit. I wanted to make sure that the mount wasn't attempted till much later in the boot process so that the program wouldn't hang. If you do not use ```NetworkManager-wait-online.service``` then remove it's entry (or substitute the service you use in it's place). If you feel this is only a workaround and not a fix, then let me know if you need me to perform further steps. Thank you so much for your quick assistence. Glad to hear that you found a workaround. I'll lower the importance of the bug since you have a workaround it's a fairly rare setup. In principle it would be good to investigate it a bit more and find what was causing that slow down before. It might be quicker if you can at some point (but maybe not this weekend) join IRC on Freenode #partitionmanager or #calamares channel. This may be kernel related. There was a similar report just made on the Manjaro forum regarding gparted. The user reported the same long start time on kernels above 4.17. I can't shut down to test different kernels presently as I'm in the middle of an operation on my server that will require it being up for at least 12 hours. https://forum.manjaro.org/t/gparted-scanning-all-devices-in-4-19/64170 (In reply to Dal Monico from comment #7) > This may be kernel related. There was a similar report just made on the > Manjaro forum regarding gparted. The user reported the same long start time > on kernels above 4.17. I can't shut down to test different kernels presently > as I'm in the middle of an operation on my server that will require it being > up for at least 12 hours. > > https://forum.manjaro.org/t/gparted-scanning-all-devices-in-4-19/64170 Indeed, could be something in the kernel. We might still be able to pinpoint what causes it. GParted uses libparted for a lot of jobs just as KPM 3.3. On the other hand you saw the same problem in kpmcore-git/partitionmanager-git. And this version does not use any libraries and just calls various linux command line programs. I'll try to write a small patch that outputs commands that are being executed to terminal. It's probably a good idea to just include it by default and hide it behind some shell variable. e.g. "KPMCORE_DEBUG=1 partitionmanager" would enable more verbose output. After that you can ask maintainer of kpmcore-git/partitionmanager-git packages to rebuild those. Then you wouldn't need to compile it yourself. It took me a long time to complete the operations with my server so I just got a chance to test the different kernel theory. I was using kernel 4.18, so it was possible older kernels did not display this behavior. To test, I disabled my mount and automount units I'd created for my NFS shares and disconnected from the server. Then I re-enabled my NFS shares in FSTAB, and rebooted into kernel 4.14. Sadly, the old kernel produced exactly the same behaviour with KPM for me as with the newer kernel. So, the kernel being a factor for this behaviour with KPM seems disproved. Perhaps that may be a factor with the gparted symptoms, but the person who reported the gparted issue has not provided the logs I requested to determine the cause. My computer is almost 10 years old, so compiling on it is not great (and I would rather avoid it). Generally, I try to avoid installing packages outside of my package manager entirely if at all possible. Please advise as to what you think would be best at this point. (In reply to Dal Monico from comment #9) > My computer is almost 10 years old, so compiling on it is not great (and I > would rather avoid it). Generally, I try to avoid installing packages > outside of my package manager entirely if at all possible. Yeah, I try to avoid that too. Although, on Gentoo it's much easier to apply patches :), I can apply patches inside my package manager. > > Please advise as to what you think would be best at this point. See my previous comment, I will write a patch and we'll try to ask kpmcore-git package maintainer to recompile. I've now pushed change that prints commands to terminal if KPMCORE_DEBUG shell variable is set. Sof if you run KPMCORE_DEBUG=y partitionmanager, you'll see what commands are being run and maybe you'll spot the command that takes a long time. Just need to get some packager to build a binary for you... Thank you (In reply to Dal Monico from comment #12) > Thank you Do you want to debug this further now that KPM 4.0 is released? Or should I close this as won't fix? Without knowing which command exactly causes long executable, there isn't much I can do... Running KPMCORE_DEBUG=y partitionmanager can output commands which are executed to stdout. Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone! This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone! |