3

I've been trying to use proftpd on Arm7 Embedded linux.

After starting the execution, it delivers this message:

error: getrlimit(RLIMIT_CORE): Operation not permitted

The Proftpf version is 1.3.4b. Any clue about whatever could cause getrlimit fail?

Thank you very much.

DBeltran
  • 31
  • 2
  • privileges? does it work with `root` user? – Sebastian Sep 26 '14 at 09:06
  • It doesnt worked for root user. I've checked also the RLIMIT_CORE, and was set to 'unlimited' by a collegue – DBeltran Sep 26 '14 at 09:14
  • 1
    EPERM is weird for `getrlimit`. You [aren't the only one to have observed this](http://lists.busybox.net/pipermail/buildroot/2011-April/042860.html): it seems that some libc return this error to say “not implemented”. What libc are you using? – Gilles 'SO- stop being evil' Sep 27 '14 at 02:54
  • This should hopefully be fixed in the next proftpd release; see [this commit](https://github.com/proftpd/proftpd/commit/e9920eb5639835222783ebabc7cceaadf408f959). – Castaglia Feb 17 '16 at 22:35

1 Answers1

1

In my case the EPERM error was caused by Large Files support enabled in build configuration. It caused _FILE_OFFSET_BITS to be defined as 64 and therefore getrlimit() call became actually a getrlimit64() call, which failed (see below). Disabling Large File support fixed the issue. I'm working on an embedded ARM application, so hopefully disabling Large File support won't hurt me much.

Update half a year later:

As it turned out, I needed Large File support even on the embedded system, to be able to use mmap() with addresses > 2GB (to access hardware registers). To allow this, but still avoid calling getrlimit64 instead of getrlimit, I defined _FILE_OFFSET_BITS=64 project wide, and in the single unit where I called getrlimit, I redefined _FILE_OFFSET_BITS before including <sys/resource.h>:

#if _FILE_OFFSET_BITS == 64
# undef _FILE_OFFSET_BITS
# define _FILE_OFFSET_BITS 32
#endif
#include <sys/resource.h> 
//...
//call getrlimit()

But why getrlimit64() failed with EPERM:

As per Gilles comment to the original question above, this is probably a way my libc returns "not implemented" error. See this thread for another example of the same EPERM usage.

Alex Che
  • 261
  • 2
  • 9