librelist archives

Unix processes and their attributes

From:

Eric Wong

Date:

2011-11-11 @ 21:37

Processes are kernel objects that run user space code.  As we've
established before, each Unix process is identified by an integer
process identifer (PID) and has a file descriptor table.

PIDs
----

Each process knows two PIDs: its own and its parent's (PPID).

Process.pid and $$ are wrappers for the getpid(2) syscall and
Process.ppid is a wrapper for getppid(2).  While the PID of a process
never changes, its parent PID (PPID) may change.

$0 / $PROGRAM_NAME
------------------

Each process has a name, this variable may be reassigned to change
the name of this process in the output in tools like ps(1).

Ruby does not expose $EXECUTABLE_NAME ($^X) like Perl does, however
$PROGRAM_NAME is set to the executable name for Ruby programs at
startup.

ARGV
----

This is an Array of command-line arguments given to a process.  ARGV[0]
in Ruby is the first argument given to the executable, not the
executable name.  Thus "ARGV[0]" in Ruby is "argv[1]" to C programmers.

Modifying this array will not affect the name of the process in tools
like ps(1).  Command-line option parsing libraries like 'optparse' and
'getoptlong' in the Ruby standard library may modify ARGV.

Signal mask/handlers
--------------------

Ruby implementations have internal system-level signal handlers that may
later dispatch Ruby code (registered via Signal.trap).  Signal handlers
written in Ruby are not subject to the limitations of system-level
signal handlers.

ENV
---

This Hash-like object holds process environment variables.
Environment variables are global to the process and are used to share
information with system libraries and child processes in a
language-independent manner.

Null-terminated C strings are mapped to Ruby Strings in both the keys
and values of this Hash-like object.

While the system environment appears Hash-like, but it is not exposed as
a hash to user space, so it does not have the same
performance/algorithmic complexity as a Ruby Hash.

Working directory (Dir.pwd, Dir.chdir)
--------------------------------------

All processes have a working directory it runs in.

Process.times
-------------

Each process keeps track of CPU time spent in user space and the system
(kernel) as well as the accumulated times of its children.
Process.times is used to implement the Benchmark module in the Ruby
standard library.

Usage counters (getrusage(2))
-----------------------------

There is no Ruby API for getrusage(2), unfortunately, however some GC
implementations may use it to provide profiling statistics.

Process.getrlimit / Process.setrlimit
-------------------------------------

These get and set process resource limits such as the maximum number
of open file descriptors, resident set size, niceness, CPU time, etc.
They are wrappers for the respective getrlimit(2) and setrlimit(2)
syscalls.

User IDs / Group IDs
--------------------

Each process has a real, effective and saved UID and GIDs.

Process::UID.change_privilege and Process::GID.change_privilege are the
most portable and easiest ways to change the UID(s) and GID(s) of a
process.

umask (File.umask)
------------------

The umask is the file mode creation mask of the process.  This governs
the filesystem permissions of newly-created files (File.open) and
directories (Dir.mkdir).



(I don't plan to write much about Unix credentials/permissions, if
 anybody else wants to contribute an article it would be greatly
 appreciated.  It's not a subject that's ever interested me.

 On the other hand, part of me dies whenever I see a directory
 tree where somebody ran "chmod -R 777 ." on because they didn't
 understand Unix permissions...)


License: GPLv3 (or later, at the discretion of Eric Wong)
         http://www.gnu.org/licenses/gpl-3.0.txt
-- 
Eric Wong

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 11.11.2011 22:37, schrieb Eric Wong:
> Ruby does not expose $EXECUTABLE_NAME ($^X) like Perl does,
> however $PROGRAM_NAME is set to the executable name for Ruby
> programs at startup.

That’s a misleading statement I think. This looks as if $0 is set to
the name of the Ruby executable on startup (i.e. "ruby" in most
cases), but a few tests show it’s set to the name of the first script
loaded by the interpreter.

==========================================================
√ quintus@hades => ~
$ ruby -e 'puts $0'
- -e
√ quintus@hades => ~
$ cat test.rb
puts $0
√ quintus@hades => ~
$ ruby test.rb
test.rb
√ quintus@hades => ~
$ irb
irb(main):001:0> $0
=> "irb"
irb(main):002:0> exit

√ quintus@hades => ~
$ cat test.rb
puts $0
require_relative "test2"
√ quintus@hades => ~
$ cat test2.rb
puts $0
√ quintus@hades => ~
$ ruby test.rb
test.rb
test.rb
√ quintus@hades => ~
$ ruby -v
ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-linux]
==========================================================

Valete,
Marvin
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOvlAoAAoJELh1XLHFkqhaV4sH/2+RufrZewCUNUjRVtkiGbQp
rF/D8e98IBpztST6PK3g4Ec219XVTwCCZrZSD05riJQQX/xIiIsUybZqywKJZQQ/
vE8bUseh6ErfWe0qVwoUCb7NIRuI0ice2wPf6dN2gIwOSJtjya6dzvU4wf38Hpxd
RgMEEyux2v7knZXow9ANLC7pGfjQ0vEWHVVwfUZHZM59c1ey2+ePKLcO+UfD4K6Z
w7YMlVOkrpzeP40sd4MFpXGUXAJnU5PiOhgtgMIu6a4xQCdu37+widIInf4x6iNp
uGAuRGyRXcYK/mrxCNT1o2RYvrr+iDd6a+hjI6JR3CnIFLdo04fR88gb6vR16fI=
=ZUoh
-----END PGP SIGNATURE-----

Quintus <sutniuq@gmx.net> wrote:
> Am 11.11.2011 22:37, schrieb Eric Wong:
> > Ruby does not expose $EXECUTABLE_NAME ($^X) like Perl does,
> > however $PROGRAM_NAME is set to the executable name for Ruby
> > programs at startup.
> 
> That’s a misleading statement I think. This looks as if $0 is set to
> the name of the Ruby executable on startup (i.e. "ruby" in most
> cases), but a few tests show it’s set to the name of the first script
> loaded by the interpreter.

Correct, I was thinking more along the lines of Ruby scripts run
with shebangs.

Also, $^X in Perl contains the full path to the interpreter, where
$0 does not (in both Perl and Ruby).  I've also noticed RbConfig.ruby
in Ruby 1.9.2+ appears to be the equivalent of $^X in Perl.

On Sat, Nov 12, 2011 at 11:20 PM, Eric Wong <normalperson@yhbt.net> wrote:
> Quintus <sutniuq@gmx.net> wrote:
>> Am 11.11.2011 22:37, schrieb Eric Wong:
>> > Ruby does not expose $EXECUTABLE_NAME ($^X) like Perl does,
>> > however $PROGRAM_NAME is set to the executable name for Ruby
>> > programs at startup.
>>
>> That’s a misleading statement I think. This looks as if $0 is set to
>> the name of the Ruby executable on startup (i.e. "ruby" in most
>> cases), but a few tests show it’s set to the name of the first script
>> loaded by the interpreter.
>
> Correct, I was thinking more along the lines of Ruby scripts run
> with shebangs.

What exactly do you mean by that?  Behavior with regard to $0 and
$PROGRAM_NAME is the same, regardless whether you invoke "ruby
your_script" or "./your_script".

$ ./x.rb
./x.rb
./x.rb
$ cat -n x.rb
     1	#!/usr/local/bin/ruby19
     2	
     3	puts $0, $PROGRAM_NAME
     4	
$

Or did you mean that the executable name is the name that the user
uses when invoking?

Kind regards

robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

Robert Klemme <shortcutter@googlemail.com> wrote:
> On Sat, Nov 12, 2011 at 11:20 PM, Eric Wong <normalperson@yhbt.net> wrote:
> > Quintus <sutniuq@gmx.net> wrote:
> >> Am 11.11.2011 22:37, schrieb Eric Wong:
> >> > Ruby does not expose $EXECUTABLE_NAME ($^X) like Perl does,
> >> > however $PROGRAM_NAME is set to the executable name for Ruby
> >> > programs at startup.
> >>
> >> That’s a misleading statement I think. This looks as if $0 is set to
> >> the name of the Ruby executable on startup (i.e. "ruby" in most
> >> cases), but a few tests show it’s set to the name of the first script
> >> loaded by the interpreter.
> >
> > Correct, I was thinking more along the lines of Ruby scripts run
> > with shebangs.
> 
> What exactly do you mean by that?  Behavior with regard to $0 and
> $PROGRAM_NAME is the same, regardless whether you invoke "ruby
> your_script" or "./your_script".

Yes, but using "ruby your_script" makes using $0/$PROGRAM_NAME to
have "your_script re-run itself.  So, using something like:

   system($0, "additional-args")

to have your process call itself is less-reliable if you ran
"ruby your_script" instead of a shebang in the the original process.
You don't know if $0 is executable or even in your $PATH.

The above example is also totally broken with "ruby -e" for one-liners.
I've never used/considered using $0 for one-liners.

> Or did you mean that the executable name is the name that the user
> uses when invoking?

Along those lines.  Without a shebang, I don't think there's a reliable
way to reproduce the original command-line for that process in Ruby.

With the following C example, I can reproduce the exact command
down to whether I invoked with "./" or "/absolute/path/to/executable"
or if I relied on $PATH to search:

ew@box:/tmp$ cat t.c
#include <stdio.h>

int main(int argc, char *argv[])
{
	int i;
	for (i = 0; i < argc; i++)
		printf("%s ", argv[i]);

	printf("\n");

	return 0;
}
ew@box:/tmp$ gcc -o t t.c -Wall
ew@box:/tmp$ ./t a s d f
./t a s d f 
ew@box:/tmp$ /tmp/t a s d f
/tmp/t a s d f 
ew@box:/tmp$ PATH=$PWD:PATH t a s d f
t a s d f 

But of course, there are more ways to invoke a Ruby script (or anything
having a seperate interpreter) than a compiled executable.

On Nov 11, 2011, at 10:37 PM, Eric Wong <normalperson@yhbt.net> wrote:

> (I don't plan to write much about Unix credentials/permissions, if
> anybody else wants to contribute an article it would be greatly
> appreciated.  It's not a subject that's ever interested me.

I find this FreeBSD handbook page a good read on the subject:

  http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/permissions.html

> On the other hand, part of me dies whenever I see a directory
> tree where somebody ran "chmod -R 777 ." on because they didn't
> understand Unix permissions...)

:-)

Thank you for writing Unicorn, Eric.

~ Marcello (via iPad)
-- 
~ vjt@openssl.it
~ http://sindro.me/

On Sat, 2011-11-12 at 01:10 +0100, Marcello Barnaba (void) wrote:
> On Nov 11, 2011, at 10:37 PM, Eric Wong <normalperson@yhbt.net> wrote:
> 
> > (I don't plan to write much about Unix credentials/permissions, if
> > anybody else wants to contribute an article it would be greatly
> > appreciated.  It's not a subject that's ever interested me.
> 
> I find this FreeBSD handbook page a good read on the subject:
> 
>   http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/permissions.html

I just did some searching around this topic also and came across this
article:


http://timetobleed.com/5-things-you-dont-know-about-user-ids-that-will-destroy-you/

-- 
http://jonathanleighton.com/