Why is taskset still not in util-linux?

[Mark Geisert]

Eliot Moss wrote:
> 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!

Great!
> 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.

I still don't get why these are happening for you.  You're building util-linux 
2.33.1, right?  Here's where the ionice build step is rejected by configure on 
my system (from config.log in the build directory):

| #include <sys/syscall.h>
| #include <unistd.h>
|
| int
| main ()
| {
| int test = _NR_ioprio_set;
|   ;
|   return 0;
| }
configure:30512: result: no
configure:30515: WARNING: Unable to detect syscall ioprio_set.
configure:30531: WARNING: ioprio_set syscall not found; not building ionice

As far as the missing _GNU_SOURCE #define, that same config.log just a page or 
two up lists the contents of confdefs.h and therein _GNU_SOURCE is #defined 1.

Are you doing a 'cygport clean' between build attempts?

> 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.

I don't install taskset.exe, I just manually copy the exe into /usr/local/bin. 
Not that that should matter.  The Cygwin-level affinity functions don't set 
ENOENT, but there might be an underlying Windows affinity function that returns 
an error that Cygwin maps to 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.

No idea why it runs in one place but not the other.  Other than what might be in 
your PATH.  You might try running 'ldd' on each exe and making sure they're 
using the same libraries... How could they not?  Dunno.  Also do 'echo $?' after 
a run to see what error code the exe is exiting with.

> 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.)

I ended up installing Process Lasso to follow processes among the cpus and to 
test the Cygwin affinity mask implementation.  It has a free trial period.  And 
I wrote a simple test program that just advances from one cpu to the next 
repeatedly, cpu-bound between steps, so PL can display the changing cpu.

..mark