ps: ps command implementation#30
ps: ps command implementation#30devimc wants to merge 3 commits intoclearcontainers:0.7.0-clearcontainersfrom
Conversation
|
Not sure it's a good idea to keep adding features here. We're happy to have feature-parity with 2.1 as far as hyperstart is concerned for 3.0. |
|
@dlespiau what do you mean? should I add this new feature in master? I thought cc 3.0 was using hyperstart 0.7.0 |
|
I hadn't noticed samuel had added docker ps support in the beta project. I guess we need that. The point is we should try to limit new features: we're not properly upstreaming - which creates a lot of technical debt - and we'd like to use our own agent at some point. |
96a3f0e to
46b1878
Compare
| /** | ||
| * line to process, it contains information about a process | ||
| * for example: | ||
| * root 5123 2 0 09:51 ? 00:00:00 [kworker/2:0] |
There was a problem hiding this comment.
I like the example, but since this is at the top of the file, it would be good to explain that the format will vary, depending on the value of psargs.
| char **array = NULL; | ||
| char *new_line = NULL; | ||
| int ret = -1; | ||
| const char* pid_str = "PID"; |
There was a problem hiding this comment.
I'm wondering if it might be better to:
- Require
psargsto specify the output format such that the first field must be thepid. - If no
psargsare specified, make hyperstart specify the format in the same way:
ps -o pid,ppid,pgrp,session,tpgid,tty,comm -eor something).
The advantage of doing that:
- You could remove
pid_indexfromhyper_ps_data. - It would be easy to reject the
PSCONTAINERcommand if the first field wasn't purely numeric on every line. - You wouldn't need this function.
- The code would be safer since what happens if
psargsis just--no-headersat the moment?
There was a problem hiding this comment.
it is a good idea indeed, but -o option will override all other options, for example:
$ ps -ef
UID PID PPID C STIME TTY TIME CMD
ps -o pid,ppid,pgrp,session,tpgid,tty -ef
PID PPID PGRP SESS TPGID TT
src/init.c
Outdated
| /* +1 for \n */ | ||
| size_t line_len = ps_data->line_len + 1; | ||
| size_t output_len = *ps_data->output_len; | ||
| const size_t buf_size = 1024; |
There was a problem hiding this comment.
This limit might be too low: on a test box, I've got a qemu cmdline that is 2634 bytes long.
There was a problem hiding this comment.
1024 is the initial size for the buffer, the size will increase by 1024 in each successive realloc
There was a problem hiding this comment.
Of course. Might be a good idea to put a comment above it for clarity (or even call it initial_buf_size or buf_size_increment maybe).
|
wouldn't it be possible/better to do an "exec" with the ps command instead of introducing a new command that doesn't seem to add value compared to an exec? what am I missing? |
|
Ah, answering to myself. We don't necessarily have ps in the container rootfs. This adds a new dependency for the guest OS though. |
|
@dlespiau yes, is not a guarantee that container rootfs will have the ps command |
| * | ||
| * \return pid index on success, else -1 | ||
| */ | ||
| static int hyper_get_pid_index(const char *line) |
There was a problem hiding this comment.
Missing a check on line being NULL.
| * | ||
| * \return true on success, else false | ||
| */ | ||
| static bool hyper_append_ps_line(struct hyper_ps_data *ps_data) |
There was a problem hiding this comment.
Check ps_data against NULL before dereferencing.
| * | ||
| * \return true on success, else false | ||
| */ | ||
| static bool hyper_process_ps_line(struct hyper_ps_data *ps_data) |
| array = hyper_line_to_array(new_process_line, &array_size, ps_data->pid_index+1); | ||
| if (array == NULL) { | ||
| free_if_set(new_process_line); | ||
| fprintf(stderr, "can not convert line to array: %s\n", new_process_line); |
There was a problem hiding this comment.
The fprintf() needs to be before the free_if_set().
src/init.c
Outdated
| } | ||
|
|
||
| /* processes less than container pid are not part of the container */ | ||
| if (pid < ps_data->container_pid) { |
There was a problem hiding this comment.
Is this test reliable I wonder? The container_pid is in a separate namespace so might be 1 inside the container and 999 outside it in the VM context.
What if the container creates lots of processes and reaches the limit of a pid_t. Will the next pid be guaranteed to be > container_pid (>999 in the VM context in this example)?
There was a problem hiding this comment.
you're right it is not a valid condition once limit is reached it is restarted
| * | ||
| * \return 0 on success, else -1 | ||
| */ | ||
| static int hyper_ps_container(char *json, int length, uint32_t *datalen, uint8_t **data) |
| size_t bufsize = 512; | ||
| uint8_t *buffer = NULL; | ||
|
|
||
| buffer = calloc(bufsize, sizeof(*buffer)); |
| buffer = calloc(bufsize, sizeof(*buffer)); | ||
|
|
||
| do { | ||
| bytes_read = read(stdout_pipe, |
There was a problem hiding this comment.
The tests in this block do seem safe, but I'd still suggest checking if bytes_read < 0 and handling that immediately rather than implicitly.
| } | ||
| if (total_bytes_read >= bufsize-1) { | ||
| uint8_t *tmp = NULL; | ||
| bufsize+=bufsize; |
There was a problem hiding this comment.
Just a check: do you intend to double the size (I suspect so), or do you want to add 512?
| * | ||
| * \return 0 on success, else -1 | ||
| */ | ||
| static int hyper_read_cmd_stdout(int stdout_pipe, uint8_t **output, size_t *size) |
There was a problem hiding this comment.
Missing checks on stdout_pipe and output params.
00d77b5 to
ea192fb
Compare
|
|
||
| if (buffer == NULL) { | ||
| /* try once again */ | ||
| buffer = calloc(bufsize, sizeof(*buffer)); |
There was a problem hiding this comment.
If calloc fails, it usually indicates OOM. No point trying again.
There was a problem hiding this comment.
I prefer to keep it, if OOM occurs hyperstart will fail any way
src/util.c
Outdated
|
|
||
| if (bytes_read > 0) { | ||
| total_bytes_read += bytes_read; | ||
| buffer[total_bytes_read] = '\0'; |
There was a problem hiding this comment.
This assignment can be moved out of the loop I think to perform it just once
src/util.c
Outdated
| buffer[total_bytes_read] = '\0'; | ||
| } | ||
|
|
||
| if (total_bytes_read >= bufsize-1) { |
There was a problem hiding this comment.
Does this have to be > rather than >= check here?
this patch adds two extra parameters to hyper_cmd for saving command stdout and a new function to read and save the data from command stdout fd Signed-off-by: Julio Montes <julio.montes@intel.com>
…er_cmd Signed-off-by: Julio Montes <julio.montes@intel.com>
this patch adds the implementation for ps command, ps output will be parsed to see what processes are running inside the given container therefore a list of processes that belong to the container is returned Signed-off-by: Julio Montes <julio.montes@intel.com>
|
can we close this? :) |
this patch adds the implementation for ps command, ps output will
be parsed to see what processes are running inside the given
container therefore a list of processes that belong to the container
is returned
Signed-off-by: Julio Montes julio.montes@intel.com