Nginx source code analysis-core module callback

Author: APO
Link: http://blog.csdn.net/livelylittlefish/article/details/7262750

Content
0. Order
1. Core module configuration structure
2. create_conf Analysis
3. init_conf Analysis
4. Summary

0. Order

In <nginx source code analysis-initialization of the global variable ngx_cycle>, this article briefly introduces how to call the callback of the core module and briefly lists its definition and initialization. This article will focus on what callback does.

1. Core module configuration structure

As mentioned above, the callback of the core module has two create_conf () and init_conf (). You can see from the name that one creates the configuration structure and the other initializes the configuration structure. The Configuration Structure of the core module is as follows: it stores core commands in the configuration file, such as deamon and master.

./Src/CORE/ngx_cycle.h

Typedef struct {mongodaemon; mongomaster; zookeeper; ngx_int_t worker_processes; includebug_points; datagrlimit_nofile; commandid; off_t rlimit_core; int priority; commandid; u_long * cpu_affinity; char * username;/* username */ngx_uid_t user;/* User ID */ngx_gid_t group;/* Group ID */ngx_str_t working_directory;/**/ngx_str_t lock_file; /* username */ngx_str_t PID; ngx_str_t oldpid;/* use '. oldbin 'end */ngx_array_t env; char ** environment; # If (ngx_threads) ngx_int_t worker_threads; size_t thread_stack_size; # endif} ngx_core_conf_t;

2. create_conf Analysis

Create_conf is just a pointer. The create_conf of the core module points to the ngx_core_module_init_conf () function, which creates the ngx_core_conf_t configuration structure.

static void *ngx_core_module_create_conf(ngx_cycle_t *cycle){    ngx_core_conf_t  *ccf;    ccf = ngx_pcalloc(cycle->pool, sizeof(ngx_core_conf_t));    if (ccf == NULL) {        return NULL;    }    /*     * set by ngx_pcalloc()     *     *     ccf->pid = NULL;     *     ccf->oldpid = NULL;     *     ccf->priority = 0;     *     ccf->cpu_affinity_n = 0;     *     ccf->cpu_affinity = NULL;     */    ccf->daemon = NGX_CONF_UNSET;    ccf->master = NGX_CONF_UNSET;    ccf->timer_resolution = NGX_CONF_UNSET_MSEC;    ccf->worker_processes = NGX_CONF_UNSET;    ccf->debug_points = NGX_CONF_UNSET;    ccf->rlimit_nofile = NGX_CONF_UNSET;    ccf->rlimit_core = NGX_CONF_UNSET;    ccf->rlimit_sigpending = NGX_CONF_UNSET;    ccf->user = (ngx_uid_t) NGX_CONF_UNSET_UINT;    ccf->group = (ngx_gid_t) NGX_CONF_UNSET_UINT;#if (NGX_THREADS)    ccf->worker_threads = NGX_CONF_UNSET;    ccf->thread_stack_size = NGX_CONF_UNSET_SIZE;#endif    if (ngx_array_init(&ccf->env, cycle->pool, 1, sizeof(ngx_str_t))        != NGX_OK)    {        return NULL;    }    return ccf;}

This function is very simple. It initializes fields of the Configuration Structure to unset values. As follows.

#define NGX_CONF_UNSET       -1#define NGX_CONF_UNSET_UINT  (ngx_uint_t) -1#define NGX_CONF_UNSET_PTR   (void *) -1#define NGX_CONF_UNSET_SIZE  (size_t) -1#define NGX_CONF_UNSET_MSEC  (ngx_msec_t) -1

3. init_conf Analysis

Init_conf is the true initialization of this structure.

(1) initialize daemon and master

Assign values directly.

(2) initialize PID and oldpid

Call the ngx_conf_full_name () function to initialize the PID. In fact, the ngx_prefix is added before the PID string to obtain the full path of the PID. The ngx_prefix is defined as follows.

#ifndef NGX_PREFIX#define NGX_PREFIX  "/usr/local/nginx/"#endif

For example, the content of the CCF-> PID before ngx_conf_full_name () is called is as follows.

(gdb) p ccf->pid $2 = {  len = 14,   data = 0x4727ff "logs/nginx.pid"}

After ngx_conf_full_name () is called, the content of CCF-> PID is as follows.

(gdb) p ccf->pid $3 = {  len = 31,   data = 0x6cce78 "/usr/local/nginx/logs/nginx.pid"}

(3) initialize username, user, group

The initialization is completed by calling the system functions getpwnam () and getgrnam. The data structure is as follows.

The getpwnam () function returns a pointer to a structure containing the broken-out fields of the record in the password database (e.g ., the local password file/etc/passwd, NIS, and LDAP) that matches the username
Name.
The passwd structure is defined in <PWD. h> as follows:
Struct passwd {
Char * pw_name;/* username */
Char * pw_passwd;/* User Password */
Uid_t pw_uid;/* User ID */
Gid_t pw_gid;/* Group ID */
Char * pw_gecos;/* User information */
Char * pw_dir;/* home directory */
Char * pw_shell;/* shell program */
};

The getgrnam () function returns a pointer to a structure containing the broken-out fields of the record in the Group database (e.g ., the local group file/etc/group, NIS, and LDAP) that matches the group name.
The group structure is defined in <GRP. h> as follows:
Struct Group {
Char * gr_name;/* group name */
Char * gr_passwd;/* group password */
Gid_t gr_gid;/* Group ID */
Char ** gr_mem;/* Group members */
};

The obtained data is as follows.

(gdb) p *pwd$5 = {  pw_name = 0x6b82a0 "nobody",   pw_passwd = 0x6b82a7 "x",   pw_uid = 99,   pw_gid = 99,   pw_gecos = 0x6b82af "Nobody",   pw_dir = 0x6b82b6 "/",   pw_shell = 0x6b82b8 "/sbin/nologin"}(gdb) p *grp$6 = {  gr_name = 0x6c3bf0 "nobody",   gr_passwd = 0x6c3bf7 "x",   gr_gid = 99,   gr_mem = 0x6c3c00}

(4) initialize lock_file

Same as the initialization PID, call the ngx_conf_full_name () function to initialize lock_file. That is, add ngx_prefix before the lock_file string to obtain the full path. The full path is as follows.

(gdb) p ccf->lock_file $6 = {  len = 32,   data = 0x6ccebf "/usr/local/nginx/logs/nginx.lock"}

(5) initialize ngx_cycle-> lock_file

The initialization of ngx_cycle-> lock_file is to copy the content of CCF-> lock_file and link it to ". Accept ".

(6) ngx_cpymem and ngx_memcpy

Ngx_cpymem (DST, SRC, n): copy the SRC content n to DST and return the address DST + n

Ngx_memcpy (DST, SRC, n): Copy SRC content n to DST

(7) content after Configuration Structure Initialization

You can obtain the Configuration Structure of the core module ngx_core_module after tracking and debugging, as shown below.

(gdb) p *ccf$12 = {  daemon = 1,   master = 1,   timer_resolution = 0,   worker_processes = 1,   debug_points = 0,   rlimit_nofile = -1,   rlimit_sigpending = -1,   rlimit_core = -1,   priority = 0,   cpu_affinity_n = 0,   cpu_affinity = 0x0,   username = 0x47280e "nobody",   user = 99,   group = 99,   working_directory = {    len = 0,     data = 0x0  },   lock_file = {    len = 32,     data = 0x6ccebf "/usr/local/nginx/logs/nginx.lock"  },   pid = {    len = 31,     data = 0x6cce78 "/usr/local/nginx/logs/nginx.pid"  },   oldpid = {    len = 39,     data = 0x6cce98 "/usr/local/nginx/logs/nginx.pid.oldbin"  },   env = {    elts = 0x6b12a0,     nelts = 0,     size = 16,     nalloc = 1,     pool = 0x6b0280  },   environment = 0x0}

4. Summary

This article mainly analyzes the callback of the core module, and further analyzes the configuration file parsing.

To read and analyze excellent open-source code, you must operate and debug it yourself to deeply understand the call path and data flow. Of course, the author has not started to analyze the core function code of nginx. I think that will be a very enjoyable code journey.

 

Reference

# Man getpwnam

# Man getgrnam