What can affect a process?

I’ve been following an interesting thread on fedora-devel which set me thinking. What is the complete list of different things that can affect the way your process runs?

Here’s my list below. If you have any other ideas, post a comment and I’ll keep this list updated.

  1. Environment variables. Obviously there are direct effects, like if $PATH is different then you may end up running different sub-processes. But there are more subtle differences like what happens if the environment is too large or completely empty? Also $LD_* variables can make a big difference to what is inside your process.
  2. ulimits. Too small and your program could fail to allocate memory or fail to open a file.
  3. Signal masks. Often overlooked, but I’ve hit this one: If a signal is masked, your program can behave quite differently. There is a famous bug where SIGPIPE was masked in the whole of Fedora, because some early program (login) was using dbus which promiscuously masked the signal, then login was forking every other program with this signal masked.
  4. Program arguments. You could put this in the “too obvious” class if you want, but consider also argv[0] which might affect your program but not be an immediately visible change.
  5. The PID. I have actually seen this: a program (sshd) was trying to create some lock file, something like /var/lock/sshd.<pid> at boot time in order to ensure only one instance was running. It was consistently failing to start sshd at boot. It took me some time to work out that because the boot was exactly predictable (and thus the PID was always the same), it was falling over its own lock file left from last time the machine was shut down.
  6. The file descriptors. Does the program change behaviour if fds 0, 1, 2 (stdin, stdout, stderr) are not open? How about if other open fds are leaked from the parent process?
  7. Current working directory. Affects what files are opened by relative paths. I guess you could include the chroot here too, but that is quite an obvious change.
  8. Number of other processes. This is like an “unofficial” ulimit, since as normally configured Linux will only allow 32766(?) processes (less PID 0 which is reserved and PID 1 for init).
  9. UIDs and GIDs. If these are very large, Bad Things can happen. External utilities like cpio and tar will fail.
  10. SELinux context. (Suggested by David Malcolm) One thing to note is that the SELinux context of a root login can be different from the context of, say, a daemon started at boot.
  11. Wallclock time or other timers. (Alexander E. Patrakov)
  12. Filesystem journalling mode, filesystem type. (see Bruno Wolff’s comment)

That’s all I can think of for now. Post a comment if you can think of any more.

About these ads

10 Comments

Filed under Uncategorized

10 responses to “What can affect a process?

  1. Jim

    Some things in the same vein as what you mentioned are namespaces, process group and session IDs, cgroups, process priorities, and capabilities. But there are _infinitely_ more. For example, if your program behaves differently based on the contents of the file /etc/foobar, then /etc/foobar will affect how your process runs. If your process depends on the network, then the network setup or any firewall rules can affect how your process runs. If you’re generating keys for a SSL handshake, how much entropy is available in /dev/random can affect how your process runs. If you take keyboard input, my typos can affect how the process runs. It’s impossible to construct a complete list in the general case.

    • rich

      Maybe a better way to phrase it (considering the original thread I linked to) would be something like “what factors outside the expected inputs of a program could affect the process?”

      • Jim

        Or, to rephrase yet again, “What unexpected inputs does your program have that affect its behavior?” And it’s impossible to answer in the general case because what’s unexpected for one person might have been anticipated by another. Certainly someone using openssl to generate a key from /dev/random might not expect “whether the user is moving the mouse around” as an input to their program, but it is. To an openssl developer, that would be obvious.

        It’s the exact same as the LD_* variables. The user linked a library (glibc) without knowing what glibc used as inputs. To you, those were not expected, so “environment variables” made your list. But that’s analogous to linking against e.g. libpulse and having /etc/pulse/client.conf affect your program’s behavior — so in general, “the contents of the filesystem” should also make this list. Similar arguments could be made for just about anything.

  2. Obviuosly, you didn’t use Windows and trial software for some time. Their protection is based on time. So, please add system time to the list.

  3. Re the environment size, it can effect alignment with significant consequences to running speed. http://www-plan.cs.colorado.edu/diwan/asplos09.pdf
    It would seem like an interesting project to try and eliminate alignment differences for processes, to help with performance tweaking.

    Talking about running speed, that could trigger asynchronous issues, as could the load of other processes on the system.

  4. Bruno Wolff

    Journalling mode of a file system. I had Postgres start failing to start after changing the journalling mode of the file system the data was on. This story is described at:
    https://bugzilla.redhat.com/show_bug.cgi?id=567113

  5. Looks like Oracle pulled the documentation you linked to in #9 (UIDs and GIDs). See page 15 of this PDF of the release notes instead…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s