Command line too long

When a collegue asked me how to get the full cmdline of a process, I simply replied:

#ps -fewww # as many w as lines you need

When he told me it was not enough I was confident to have the right answer:

# cat /proc/$PID/cmdline

I didn’t know  that /proc/cmdline is limited, and the limit is lower than argv length. Specifically it’s the output of

# getconf PAGE_SIZE


Enjoy with this script

# cat > /tmp/ << EOF


sleep 10


# chmod +x /tmp/; /tmp/ {0..2000} &

# cat /proc/${!}/cmdline | wc -c


PAGE_SIZE is the kernel defined page size, and to grow it you have to rebuild your kernel… but you may find some drawbacks ;)

To know something more about argv length – as it depends on POSIX and linux kernel version – you can see:

# man 2 execve

An accepted value is usually 32*PAGE_SIZE = 128k, but some parameters like

#ulimit -s  # stack size

# getconf ARG_MAX

may influence the allowed size.

If you’re interested you can look at the exec() source code ;)

Nested man exception

While updating keycluster to RHEL5 I stumbled upon some strange behavior.

A service didn’t start due a failure to mount a dummy filesystem. Browsing the code I found that the error was raised by a
system(“/bin/mount”) call.

To avoid issues with the shell environment, I re-implemented with fork()+execv(“/bin/mount”, …).
Still errors, this time it was a execv(): Permission Denied.

Again I read # man execv; without finding any particular issues …

First step: reproduce

wraping the execv() in a standalone executables, like the following, gave no issues


execv(“/bin/mount”, …)

Second Step: suid-bit

as the error happened only with /bin/mount which has the suid-bit set, I tried

#chmod u-s /bin/mount

and BINGO: it worked. This lead me to think to…

Third step: selinux

I thought that it could be a selinux issue: tried

  1. checking selinux logs (audit)
  2. tuning selinux (I learned something about context – this was good!)
  3. disabling selinux

no way

The old good times: Recursive RTFM

I was bored, and started to play seriously: I did what I should have done since the first time.
1. man execv() referred to man execve()

All of these functions may fail and set errno for any of the errors specified for the library function execve(2).

2. man execve() has EPERM error

EPERM The file system is mounted nosuid, the user is not the superuser, and the file has an SUID or SGID bit set.

EPERM The process is being traced, the user is not the superuser and the file has an SUID or SGID bit set.

3. and suddenly I remember: the guilty program was running under valgrind (I’m in test environment!). Well, even Valgrind was running as root, but I don’t effectively know what happens into valgrind

The solution: that kind of test shouldn’t use valgrind. I’ll investigate further whether valgrind drops roots privileges while running its children.