Why is taskset still not in util-linux?

[Eliot Moss]

On 3/20/2020 1:54 AM, Mark Geisert wrote:

 > I've reproduced your snags.  It/they are due to my having forgotten another tiny update that should
 > have been part of the 2.33.1-cygwin-cpuset.patch file.  If you 'echo "#define SYS_sched_getaffinity
 > 42" > /usr/local/include/sys/syscall.h' and then back out your other fix attempts, the build using
 > cygport should work.

Dear Mark:

Once I did that properly, it built without commenting out that test.  Yay!

We still need to suppress building ionice, which requires patching
configure.ac to provide a separate flag for that.  And we still need to
#define _GNU_SOURCE before the #include <sched.h> to make the
sched_get/setaffinity calls visible.  I intend to patch that into taskset.c
unless you have a better way of doing it.

When I do all this and use 'cygport compile', I get a taskset that appears to
work ...  as long as I run it in the place where it was built.  When I install
it, it fails, pretty silently.  I have strace outputs from the two cases, but
don't know enough about internals to interpret them.  It seems that the
failure is errno 2, ENOENT.

The permissions on the file in the build area and the one in /usr/bin are the
same (according to both getfacl and icacls) and they are on the same drive.
'cmp' indicates that the file contents are the same.  It's pretty confusing.
I've never seen anything like it.  It doesn't matter if I give the full path
'/usr/bin/taskset' or the shorter 'taskset'.  The containing directories have
slightly different permissions, but lots of other files in /usr/bin load and
run.

By running the version in the build directory on a somewhat long-running ls
command, and using taskset -p on that running ls from another window, I
verified that the affinity mask is indeed getting set.  (It was less obvious
to me how to tell which cpu it was actually running on.)

Your thoughts about not being able to run the installed version?

Eliot