icecc always running with max_jobs=0

[Aloisio Almeida Jr]

icecc version: 0.9.8~git2012121601-0ubuntu2
Ubuntu 13.04

* How to reproduce:
1. Install icecc
2. Edit /etc/icecc/icecc.conf:
2a. Set the ICECC_NETNAME properly
2b. Set ICECC_MAX_JOBS to be greater then 0 (I've set 4)
2c. Set ICECC_ALLOW_REMOTE to "yes"

* What you expected to happen
You should be able to send and receive jobs

* What happened instead
The icecc cannot receive jobs. Icemon always report "Speed: 0". Iceberg reports "Max Jobs: 0"

Technical explanation:

At the login time, the node sends the chroot_possible parameter. If the scheduler receives chroot_possible set as false, the max_jobs is overwritten to zero and the node will not receive any jobs. This icecc version is calculating chroot_possible value by doing:

chroot_possible = ( geteuid() == 0 );

As the daemon does not run as root anymore, chroot_possible will be set as false.

There is already a patch upstream to solve this problem. It uses libcap_ng instead of check uid:
https://github.com/icecc/icecream/commit/3f1ddaff89eec9421c9ab730baaff3d6471c271f

### A new bug after solving the first one... ###

After apply this patch locally, the icecc started to receive jobs. But unfortunately the daemon was exiting when installing the remote environment:

[7393] 10:18:39: handle_transfer_env
[7393] 10:18:39: chown,chmod target Operation not permitted
[7393] 10:18:39: handle_transfer_env_done
[7393] 10:18:39: exit code: 0

Again a bug related to daemon uid. There is also a patch upstream that solves the problem:
https://github.com/icecc/icecream/commit/6913f480b56594c4b6d888c18efd2312ba6d06be

I have applied both patches locally and now my icecc is working as expected.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Thiago Marcos P. Santos (tmpsantos)]

I would say that icecc is broken on 13.04. It was not distributing my jobs and neither receiving jobs from the cluster. It was showing up at the scheduler as 0/0 jobs as described by this bug.

Downgrading to the icecc shipped by 12.10 "fixed" the problem.

[Steffen Kittel (steki)]

Using packages from debian jessie [1] or sid [2] also works fine.
Please import those for the next LTS-Version.

[1] http://packages.debian.org/jessie/icecc
[2] http://packages.debian.org/sid/icecc

[Andres Gomez (Tanty) (tanty)]

I can confirm the bug and the solution applying both commits in github.

[Andres Gomez (Tanty) (tanty)]

Both attached patches, extracted from github, can be applied directly to the source of the Ubuntu package for 13.04 in order to fix this problem.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "with cap-ng geteuid() is not a sign of being able to do chroot" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Jonathan Riddell (jr)]

should be fixed in new version in trusty

[Andres Gomez (Tanty) (tanty)]

So, as this doesn't seem going to be fixed for "raring" nor "saucy" I've uploaded the patched package to my own PPA.

Although the package in the PPA is for "saucy", it can probably be also used in "raring".

Just do:

$ sudo add-apt-repository ppa:tanty/ppa
$ sudo apt-get update
$ sudo apt-get install icecc

Or just go to

https://launchpad.net/~tanty/+archive/ppa/+sourcepub/4026933/+listing-archive-extra

And download and install by hand (for example, for "raring")