Message boards :
Number crunching :
After switching to XFCE desktop, no Milkyway tasks showing
Message board moderation
Author | Message |
---|---|
Send message Joined: 13 Apr 11 Posts: 33 Credit: 29,568,628 RAC: 5,308 |
I run Kubuntu 14.04.5 LTS 64-bit on a Core2Quad 2.7 GHz, 8 GB RAM, nVidia GTX950 1 GB video. I installed XFCE Desktop to reduce system load for another application that needed more resources (Kerbal Space Program), and after briefly logging into the XFCE Desktop and returning to KDE Plasma, BOINC Manager shows *no tasks* -- neither running, completed, aborted, or waiting to run, and neither on Milkyway nor Einstein (which latter I run in GPU tasks only, while Milkyway runs CPU tasks only). It appears the XFCE installation may have left insufficient space in the OS partition to run BOINC (there's plenty of space in my /home) -- would it help to point BOINC storage to another, empty partition, and if so how would I do that? Alternately, I could resize partitions to make more room, but that's a time consuming operation... |
Send message Joined: 16 Mar 10 Posts: 210 Credit: 106,115,449 RAC: 23,932 |
As you still seem to be using BOINC 7.2.42 I'm not sure whether that's a repository-based BOINC install that you've never updated or not. If you have installed BOINC from the Ubuntu repositories, it should have put the vast bulk of the BOINC-related stuff in /var/lib/boinc-client. /var/log can eat a lot of space too, so it might be worth checking that out. If you definitely need more space in /var, your easiest solutions in that case are to either use a recovery disk of some sort to move the contents of /var to a free, formatted partition or (as you suggested) modify your partitions to make more room for whichever one contains your BOINC data. If you installed manually, you could possibly try moving the contents of the BOINC directory to a free, formatted partition and mounting the partition to the BOINC directory. This solution is not appropriate if the data lives in /var as if you do a system upgrade you may well lose the lot (depending on how the upgrade is done - I've just had what purported to be an upgrade do the equivalent of a "nuke and pave" on one of my machines; fortunately I'd made allowances for the possibility...) Any safe method you use to re-organize is probably going to require doing it using a recovery disk of some form (I use PartedMagic - it's usually got a fairly up-to-date kernel and hardware handling, so I reckon it's worth the small donation required); and if you are careful about moving stuff to a new partition it is going to take a while (voice of experience here!) so if you are happy with partition-juggling it might be nearly as quick! The usual caveats apply - make sure anything you're worried about is backed up before messing with your file store (and yes, I know you know that, but...), and if you aren't sure how do do something, ask (and my apologies if you're a Linux Guru already!...) I hope the above makes some sort of sense, and that you can move forwards now. If you do need to ask for more help here, please give a bit more detail about where things live, how big your partition(s) are, and perhaps the output of df -k too so actual usage can be assessed. Good luck - Al. P.S. If you did a repository install of BOINC in the first place, you should be able to get a newer version, which is probably a good idea even though it won't solve space problems! |
Send message Joined: 13 Apr 11 Posts: 33 Credit: 29,568,628 RAC: 5,308 |
First: No, I'm not a Linux guru. I've been using Linux for several years (first Mepis 11, then Kubuntu 14.04 since a few weeks after it dropped), but learning about Linux isn't a hobby or livelihood for me, and generally isn't necessary for daily use -- and I have many other things to spend my time and brain power on. So, I've learned the most common, useful stuff, but I usually have to look up the exact commands for anything more complex than ls -aw. Where possible, I do things through the GUI. That said, here's what I tried while waiting for an answer: I terminated the BOINC process(es) so they'd let go of their file locks, copied the contents of /var/lib/boinc-client/projects and /var/lib/boinc-client/slots to folders with matching names on the empty partition, and then tried to mount those folders in place of the ones on the full partition via /etc/fstab. That failed, and I'm not sure why, but I then tried to replace the originals with symlinks -- which was successful, in that references to the original folders open the ones with 20 GB of space, but boinc-client still doesn't run, shows no tasks, and BOINC Manager still reports no free space (must be reading the space for the /var/lib/boinc-client folder instead of the ~/slots and ~/projects). I haven't yet tried making the whole /var/lib/boinc-client folder a symlink or mounting the entire free partition there (the latter I'm pretty confident would work, because it's a standard operation and I can use the UUID). However, I'm no longer as sure that space is the only problem. FWIW, the OS partition that contains the space BOINC uses is 20 GB, which has been plenty for Kubuntu 14.04 over nearly three years of regular updates, until I installed the XFCE desktop. Now, however, it's showing about 960 MB free -- 19.04 GB used out of 20.0 GB total -- which ought to be enough for normal operation, but might not leave enough for BOINC. However, when I start BOINC Manager, I also have a notification that "BOINC can't access Internet - check network configuration or proxy." I have fully functioning Internet connection for everything else (wired ethernet to a router that serves the entire house -- two desktop computers, three laptops, and three active Android/iOS devices, none of which have connection issues at present). Both proxy settings tabs in BOINC manager have the enabling checkbox blank, and I've never used a proxy for general internet connection (some AV suites do this, etc. but I don't have any of those). I've just double checked, and my system wide network settings are checked for "no proxy". Here's the command output you requested: df -k Filesystem 1K-blocks Used Available Use% Mounted on udev 4065428 12 4065416 1% /dev tmpfs 817480 1592 815888 1% /run /dev/sda5 20510716 19962556 0 100% / none 4 0 4 0% /sys/fs/cgroup none 5120 0 5120 0% /run/lock none 4087400 92 4087308 1% /run/shm none 102400 32 102368 1% /run/user overflow 1024 40 984 4% /tmp /dev/sdc1 20510716 10949152 8496608 57% /mnt/sdc1 /dev/sdc6 69831768 59649860 6627932 90% /mnt/sdc6 /dev/sdc7 20504628 9668176 9788216 50% /mnt/sdc7 /dev/sdb1 102398276 43887184 58511092 43% /mnt/sdb1 /dev/sdb5 102398276 17615656 84782620 18% /mnt/sdb5 /dev/sdb6 102398276 11171760 91226516 11% /mnt/sdb6 /dev/sdb7 102398276 3128220 99270056 4% /mnt/sdb7 /dev/sdb8 204796584 191023420 13773164 94% /mnt/sdb8 /dev/sdb9 362370136 108152244 254217892 30% /mnt/sdb9 /dev/sda6 20511356 9862800 9599984 51% /mnt/sda6 /dev/sda7 20510716 227752 19218008 2% /mnt/sda7 /dev/sda8 20510716 7459392 11986368 39% /mnt/sda8 /dev/sda9 155056776 87550900 59622788 60% /home /dev/sda1 96990 2169 87515 3% /mnt/sda1 My OS is on /dev/sda5, and the empty partition I'm trying to offer to BOINC is /dev/sda7. Before posting this, I went ahead and tried moving the entire /var/lib/boinc-client folder to the empty drive, and replacing it with a symlink -- which has partially worked, in that BOINC Manager how reports oodles of free space and I'm seeing about 1.7 GB free in the OS partition now, but it's partially made things worse, in that BOINC Manager is now reporting no projects and (likely because of its lack of internet connection) won't let me connect to any projects. At this point, I suspect that reinstalling BOINC is the way to go. The version I have is the only one available from the Ubuntu repositories (they tend to be far out of date for software that isn't from Canonical and changes frequently, because of their testing and stability requirements). Is there a .deb repo available directly from the BOINC developers that would keep me more updated? |
Send message Joined: 13 Apr 11 Posts: 33 Credit: 29,568,628 RAC: 5,308 |
Woops, one error above: After moving/linking the /var/lib/boinc-client folder to the empty partition, BOINC Manager is now reporting zero space used, zero space free. It's not seeing those entries at all -- even after doing a package manager reinstall of the BOINC packages. It also still won't let me connect to a project, though I no longer have a notification about "no internet connection". |
Send message Joined: 16 Mar 10 Posts: 210 Credit: 106,115,449 RAC: 23,932 |
The below is quite long(!) and there may be information towards the end that you need to consider before acting on information in the middle! Given that I'm not sat at your computer, able to get the fine details of what's where, I can't give you a single, simple(?) script to solve your problems. Sorry about that,,, Here's the command output you requested: That is one very full root file-store! That needs sorting out, seriously! You may have ways of recovering some space. Check how much [very] old stuff you have in /var/log, for example. If not, I'd be seriously tempted to use a recovery disk to move the partitions around, as although it's time-consuming it's probably less error-prone than juggling parts of your root file-store onto other devices (which is what a lot of the rest of this post is about.) Otherwise, some content will have to move, and I'd repeat my suggestion that you move /var to another partition. You could do this on /dev/sda7 where you tried to do a symlink for /var/lib/boinc-client... (And as a side-effect you'll see how much space /var was really using!) Note: if you mount /var on a new partition and haven't cleared out the original /var before you reboot you will not have recovered the space! There are lots of ways of sorting out new partitions, of which the easiest is probably a re-install with custom configuration to get it to build a new /var (which won't contain BOINC, of course) -- it effectively trashes your system partitions and starts from scratch -- however, if you've installed lots of other stuff that won't be there after the re-install, and you may lose /home if you aren't careful. I would tend to use either a recovery disk (as mentioned in my other post) or, perhaps, a "Live CD/DVD" (and some cautious use of root) to do this. You will need to be happy mounting devices (modern recovery disks will provide a tool to do this for you, usually to /media.) If you don't have anything you would like to keep in your BOINC directories at present, sorting this out is easy as all you need to do is remove the boinc-client stuff from sda7, copy everything under /var/lib to that drive as root (example command below...). If you want to try to retain any data in your existing boinc-client directory, and you don't have another copy, either move it away (to /home, for instance) or make sure that if you're going to leave it on /dev/sda7 it's called something like boinc-client-saved to make sure it doesn't get displaced by the copy operation... Again, you need to be root (and cp -a is your friend) If you are doing the copying using your normal booted system, that might look like sudo cp -a /var/lib/* /mnt/sd7/ and if you're using a recovery disk that might look like cp -a /media/sda5/var/lib/* /media/sda7/ If, after doing that, you find you've got a /var directory in your mount-point you've copied the directory and its contents, not just the contents, and you'll need to do mv /media/sda7/var/* /media/sda7/ (or equivalent) to get rid of the extra level of directory structure! That's why my cp commands put /* on the end of the source path. You might now want to remove the symlink /media/sda7/var/lib/boinc-client (if that's the level you linked at) - it'll be meaningless once you reboot - and if you still had your boinc-client stuff on the partition (see above) you could now shift it using mv. Once you've done that you can look at /etc/fstab to see what syntax has been used to mount /home and make something equivalent for /var. Note that if it uses UUID syntax you can find out the ID by doing blkid /dev/sda7 Once you've done the above, you will need to use a recovery/Live-DVD method to remove the contents of the existing /dev/sda5/var. Things won't go well if you try to empty /var whilst you're running your live system - there are techniques for working round this, but the KISS principle should probably be applied here! After that, if you exit the recovery/Live-DVD (having edited /etc/fstab to mount the new /var) a re-boot should bring up your system using the moved /var content and having space back on your root partition. ---- Woops, one error above: After moving/linking the /var/lib/boinc-client folder to the empty partition, BOINC Manager is now reporting zero space used, zero space free. It's not seeing those entries at all -- even after doing a package manager reinstall of the BOINC packages. It also still won't let me connect to a project, though I no longer have a notification about "no internet connection". If you are symlinking to a mount-point (/var/lib/boinc-client -> /mnt/sda7) that might not work anyway(!) Otherwise, did you check to see if the symlink you made survived the package re-install? Just a thought... If you can get the symlink method to work, fine; if not, the comments above about moving all of /var might still apply, or you could try making a new version of /etc/init.d/boinc-client, changing the BOINC_DIR option to point at your alternative directory. The reason I don't like editing startup files is that one has to keep track of that if/when you update BOINC or your O/S... (Of course, if you edit a file in /etc/init.d, you should probably make a copy of the old version first; you'll need to be root to edit the file - what I do when changing files in /etc is typically: sudo cp -p /etc/init.d/file_I_want_to_edit ~/my_etc/file_I_want_to_edit.orig sudo vi /etc/file_I_want_to_edit Obviously, that's a "template"... ---- Regarding your earlier question about package versions, there's a developer's PPA for BOINC 7.6.32 which works fine on my XUbuntu 14.04 laptop and worked fine on my workstation (which has a GPU as well...) on 14.04 and still works on 16.04. To collect that: sudo add-apt-repository ppa:costamagnagianfranco/boinc sudo apt-get update after which a newer version of BOINC should show up in Synaptic (or whatever else is the package manager for KUbuntu) ---- Whatever happens next, good luck; I tackle tasks like that with some trepidation (in case I get fat-fingered...) and expect to spend lots of time on them, and (in theory, at least) I'm supposed to know what I'm doing in enough detail to spot problems before they become crises. I repeat - good luck! Cheers - Al. |
Send message Joined: 13 Apr 11 Posts: 33 Credit: 29,568,628 RAC: 5,308 |
Well, pending the Einstein client getting some tasks, I think this is sorted. Much simpler than using a recovery or install Live CD/DVD/USB, I rebooted into Kubuntu 16.04, which is in another partition on the same SSD. I used the tools in that version of Kubuntu to resize partitions to give the OS an additional 10 GB of space (repaired the damage I did to GRUB that made my system not boot), moved the boinc-client folder back to its regular location in /var/lib, and found BOINC still wouldn't cooperate, so I uninstalled BOINC entirely (using "complete uninstall"), but chose not to delete the data directory, then reinstalled from the repository. When I started BOINC manager after that completed, it seemed to see both Milkyway and Einstein, but still wouldn't communicate with them, so I removed both projects and reconnected to them from BOINC Manager -- and Milkyway, at least, almost immediately grabbed a stack of tasks. Einstein has been funny lately anyway (a coding change made it not work on my GPU, and I have it set to run only GPU tasks so it doesn't compete with Milkyway), and I'm not sure that's been fixed at the project end, so I'm not too worried about it. Thanks for spotting the error in the symlink; I may have just typed it wrong, since I used the GUI tools in Dolphin to create the link (I don't think you can make a malformed link that way). However it happens, it didn't work with that symlink. Continued: Oops, spoke too soon. Now I'm getting the following: Mon 13 Feb 2017 07:02:05 PM EST | Milkyway@Home | [error] exceeded limit of 400 slot directories Mon 13 Feb 2017 07:02:05 PM EST | Milkyway@Home | [error] Can't create task for de_modfit_fast_19_3s_140_bundle5_ModfitConstraints3_4_1484858101_10105624_2 Mon 13 Feb 2017 07:02:05 PM EST | Milkyway@Home | [error] exceeded limit of 400 slot directories Mon 13 Feb 2017 07:02:05 PM EST | Milkyway@Home | [error] Can't create task for de_modfit_fast_19_3s_140_bundle5_ModfitConstraints3_4_1484858101_10169895_0 Mon 13 Feb 2017 07:02:05 PM EST | Milkyway@Home | [error] exceeded limit of 400 slot directories Mon 13 Feb 2017 07:02:05 PM EST | Milkyway@Home | [error] Can't create task for de_modfit_fast_19_3s_140_bundle5_ModfitConstraints3_3_1484858101_10169872_0 Mon 13 Feb 2017 07:02:05 PM EST | Milkyway@Home | [error] exceeded limit of 400 slot directories Mon 13 Feb 2017 07:02:05 PM EST | Milkyway@Home | [error] Can't create task for de_modfit_fast_19_3s_140_bundle5_ModfitConstraints3_3_1484858101_10169870_0 BOINC has permission to use 1 GB, and there's almost 9 GB free on that volume. I don't know what slot directories are, nor where that limit is set... |
Send message Joined: 16 Mar 10 Posts: 210 Credit: 106,115,449 RAC: 23,932 |
I'm glad you had something more efficient than a rescue disk to help you get sorted out. At least you're "on the way", even if there's still a bump in the road... There's a known issue with certain versions of BOINC client which can result in completed tasks not freeing up their resources completely. Each job runs in a slot directory, and if the slot directory isn't flushed out properly on completion it can't be re-used. Looks like you've hit that! I gather from some stuff in the BOINC developer's forum at Berkeley, and other places (Google is my friend here!) that if the higher-numbered directories happen to be empty and you delete them it'll re-create them and use them (until they get broken again...) However, if there are directories in use above some empty ones, those empty ones won't be re-used. And deleting a chunk of directories out of the middle isn't a good idea. Apparently, sometimes completely shutting down BOINC and restarting it gets things moving again, but it's a pain if this recurs, especially if it's aborting the tasks it can't start, as the only way to stop the cycle in that case is to stop all projects from getting new tasks until you've got an empty system to shut down! Unfortunately, the issue that caused that to happen only affected users on UNIX-family machines (Mac, Linux, FreeBSD &c), and it didn't hit everyone, so it took a while to be recognized as such and solved. The fix didn't happen until version 7.6.11. So it would definitely pay you to get that repository I mentioned and load a 7.6 client if there is one. (Einstein, SETI and MilkyWay all work with 7.6.32, which is the version I've got on both XUbuntu 14.04 and XUbuntu 16.04 systems...) Hope you finish getting it sorted soon. Once again, good luck - Al. |
Send message Joined: 13 Apr 11 Posts: 33 Credit: 29,568,628 RAC: 5,308 |
There's always a way to solve the problem, and sometimes it involves a large, heavy hammer. I used Synaptic to "completely" uninstall everything related to BOINC: manager, clients, libraries, etc. and during the process, when prompted told the system to remove the data directory as well. Then I added the repository you pointed to, refreshed Synaptic, and installed the current versions of the manager (via metapackage), client, Cuda client, and dependencies. Started up BOINC Manager, it automatically offered to connect to a project; I selected Milkyway, then manually added Einstein when it was done. Both have already downloaded and started work on multiple tasks, and my CPU usage has returned to 100% for all four cores. The original problem was surely disk space, but it was probably made into a real issue by selecting a bad option (symlinks) to try to solve it. If I'd started with making more space, I'd have saved a week or so of production time. But, any landing you walk away from... |
©2024 Astroinformatics Group