Welcome to MilkyWay@home

After switching to XFCE desktop, no Milkyway tasks showing


Advanced search

Message boards : Number crunching : After switching to XFCE desktop, no Milkyway tasks showing
Message board moderation

To post messages, you must log in.

AuthorMessage
Donald Qualls

Send message
Joined: 13 Apr 11
Posts: 33
Credit: 16,413,428
RAC: 12,369
10 million credit badge8 year member badge
Message 66178 - Posted: 11 Feb 2017, 13:47:14 UTC

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...
ID: 66178 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
alanb1951

Send message
Joined: 16 Mar 10
Posts: 41
Credit: 31,922,145
RAC: 12,081
30 million credit badge9 year member badgeextraordinary contributions badge
Message 66181 - Posted: 12 Feb 2017, 9:31:40 UTC - in response to Message 66178.  

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!
ID: 66181 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Donald Qualls

Send message
Joined: 13 Apr 11
Posts: 33
Credit: 16,413,428
RAC: 12,369
10 million credit badge8 year member badge
Message 66183 - Posted: 12 Feb 2017, 12:59:11 UTC - in response to Message 66181.  

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?
ID: 66183 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Donald Qualls

Send message
Joined: 13 Apr 11
Posts: 33
Credit: 16,413,428
RAC: 12,369
10 million credit badge8 year member badge
Message 66184 - Posted: 12 Feb 2017, 13:06:26 UTC - in response to Message 66183.  

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".
ID: 66184 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
alanb1951

Send message
Joined: 16 Mar 10
Posts: 41
Credit: 31,922,145
RAC: 12,081
30 million credit badge9 year member badgeextraordinary contributions badge
Message 66187 - Posted: 13 Feb 2017, 4:36:36 UTC - in response to Message 66184.  

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:
 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% /
...

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.
ID: 66187 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Donald Qualls

Send message
Joined: 13 Apr 11
Posts: 33
Credit: 16,413,428
RAC: 12,369
10 million credit badge8 year member badge
Message 66190 - Posted: 14 Feb 2017, 0:19:28 UTC - in response to Message 66187.  

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...
ID: 66190 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
alanb1951

Send message
Joined: 16 Mar 10
Posts: 41
Credit: 31,922,145
RAC: 12,081
30 million credit badge9 year member badgeextraordinary contributions badge
Message 66192 - Posted: 14 Feb 2017, 15:30:15 UTC - in response to Message 66190.  

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.
ID: 66192 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote
Donald Qualls

Send message
Joined: 13 Apr 11
Posts: 33
Credit: 16,413,428
RAC: 12,369
10 million credit badge8 year member badge
Message 66205 - Posted: 18 Feb 2017, 18:47:43 UTC - in response to Message 66192.  

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...
ID: 66205 · Rating: 0 · rate: Rate + / Rate - Report as offensive     Reply Quote

Message boards : Number crunching : After switching to XFCE desktop, no Milkyway tasks showing

©2019 Astroinformatics Group