I've got a problem that I think I may have encountered before a few
years back, but don't recall what the underlying cause was.

I'm using uschedule, and of course it uses chpst to run the logging
service under the user.  The log/run script looks like this:

#! /bin/sh
exec 2>&1
cd '/home/vdanen/.uschedule/log' || exit 1
exec \
/sbin/chpst -m 800000 -o 400 -p 40 \
chpst -u vdanen \
./run


and the /home/vdanen/.uschedule/log/run script looks like:

#! /bin/sh
exec \
/sbin/chpst -m 500000 -o 200 -p 20 \
/sbin/svlogd -tt \
./

It's a little ugly, yes, but uschedule was written for djb's stuff so I
ported it and left as much "intact" as possible.

Anyways, if I try to run uschedule like this, I get:

[root@artemis log]# ./run
Killed

If I ommit the -m call to set the memory limits, it works fine.
Thinking maybe it was trying to exceed what it could get (via ulimit
settings), I tried this:

[root@artemis log]# chpst -m 100000 -u vdanen /bin/sh
Killed
[root@artemis log]# chpst -u vdanen /bin/sh
sh: /root/.bashrc: Permission denied
[vdanen@artemis log]$ ulimit -a
core file size          (blocks, -c) 1000000
data seg size           (kbytes, -d) 12288
scheduling priority             (-e) 20
file size               (blocks, -f) unlimited
pending signals                 (-i) 16375
max locked memory       (kbytes, -l) 32
max memory size         (kbytes, -m) unlimited
open files                      (-n) 256
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 100
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

That memory setting should be well under the established limits.  An
strace shows me:

[root@artemis log]# strace chpst -m 100000 -u vdanen /bin/sh
execve("/sbin/chpst", ["chpst", "-m", "100000", "-u", "vdanen", "/bin/sh"], [/* 41 vars */]) = 0
open("/dev/urandom", O_RDONLY)          = 3
read(3, "\216\266\246\243\vp\245\242", 8) = 8
close(3)                                = 0
open("/etc/passwd", O_RDONLY)           = 3
lseek(3, 0, SEEK_END)                   = 1486
mmap(NULL, 1486, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2b5440b0a000
close(3)                                = 0
munmap(0x2b5440b0a000, 1486)            = 0
setgroups(1, [1001])                    = 0
setgid(1001)                            = 0
setuid(1001)                            = 0
getrlimit(RLIMIT_DATA, {rlim_cur=12288*1024, rlim_max=RLIM_INFINITY}) = 0
setrlimit(RLIMIT_DATA, {rlim_cur=100000, rlim_max=RLIM_INFINITY}) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
setrlimit(RLIMIT_STACK, {rlim_cur=100000, rlim_max=RLIM_INFINITY}) = 0
getrlimit(RLIMIT_MEMLOCK, {rlim_cur=32*1024, rlim_max=32*1024}) = 0
setrlimit(RLIMIT_MEMLOCK, {rlim_cur=32*1024, rlim_max=32*1024}) = 0
getrlimit(RLIMIT_AS, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
setrlimit(RLIMIT_AS, {rlim_cur=100000, rlim_max=RLIM_INFINITY}) = 0
execve("/bin/sh", ["/bin/sh"], [/* 41 vars */]) = -1 ENOMEM (Cannot allocate memory)
+++ killed by SIGKILL +++


Does anyone know why this is happening?  If I'm recalling correctly, I
think dietlibc or a change in dietlibc was the culprit before, but I
can't remember.

Removing the memory restrictions to the chpst calls works well enough,
but it would be nice to be able to use them since they are there.

-- 
Vincent Danen @ http://linsec.ca/