Advanced Programming in the UNIX® Environment

ptg10805159

Section 8.15 User Identification 275

Section 8.6. The only information in this byte is a core-flag bit (usually the high-order

bit) and the signal number (usually the seven low-order bits), if the process terminated

abnormally.Ifthe process terminated normally, we are not able to obtain theexit

status from the accounting file. For the first child, this value is 128+6. The 128 is the

coreflag bit, and 6 happens to be the value on this system forSIGABRT,which is

generated by the call toabort.The value 9 for the fourth child corresponds to the

value ofSIGKILL.Wecan’t tell from the accounting data that the parent’s argument to

exitwas 2 and that the thirdchild’s argument toexitwas 0.

The size of the file/etc/passwdthat theddprocess copies in the second child is

777 bytes. The number of characters of I/O is just over twice this value. It is twice the

value, as 777 bytes areread in, then 777 bytes arewritten out. Even though the output

goes to the null device, the bytes arestill accounted for.The 31 additional bytes come

from theddcommand reporting the summary of bytes read and written, which it prints

tostdout.

Theac_flagvalues areare what we would expect. TheFflag is set for all the

child processes except the second child, which does theexecl.TheFflag is not set for

the parent, because the interactive shell that executed the parent did aforkand then an

execof thea.outfile. The first child process callsabort,which generates aSIGABRT

signal to generate the coredump. Note that neither theXflag nor theDflag is on, as

they arenot supported on Solaris; the information they represent can be derived from

theac_stat field. The fourth child also terminates because of a signal, but the

SIGKILLsignal does not generate a coredump; it just terminates the process.

As a final note, the first child has a 0 count for the number of characters of I/O, yet

this process generated acorefile. It appears that the I/O required to write thecore

file is not charged to the process.

8.15 User Identification

Any process can find out its real and effective user ID and group ID. Sometimes,

however, we want to find out the login name of the user who’s running the program.

We could callgetpwuid(getuid()),but what if a single user has multiple login

names, each with the same user ID? (A person might have multiple entries in the

passwordfile with the same user ID to have a different login shell for each entry.) The

system normally keeps track of the name we log in under (Section 6.8), and the

getloginfunction provides a way to fetch that login name.

#include <unistd.h>

char *getlogin(void);

Returns: pointer to string giving login name if OK,NULLon error

This function can fail if the process is not attached to a terminal that a user logged in to.

We normally call these processesdaemons.Wediscuss them in Chapter 13.