On 02/06/2012 06:50 AM, Peter Krempa wrote:
> This patch changes behavior of virPidFileRead to enable passing NULL as
> path to the binary the pid file should be checked against to skip this
> check. This enables using this function for reading files that have same
> semantics as pid files, but belong to unknown processes.
> ---
> src/util/virpidfile.c | 21 +++++++++++++--------
> 1 files changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/src/util/virpidfile.c b/src/util/virpidfile.c
> index 1fd6318..f1f721f 100644
> --- a/src/util/virpidfile.c
> +++ b/src/util/virpidfile.c
> @@ -184,6 +184,9 @@ int virPidFileRead(const char *dir,
> * resolves to @binpath. This adds protection against
> * recycling of previously reaped pids.
> *
> + * If @binpath is NULL the check for the executable path
> + * is skipped.
> + *
> * Returns -errno upon error, or zero on successful
> * reading of the pidfile. If the PID was not still
> * alive, zero will be returned, but @pid will be
> @@ -209,16 +212,18 @@ int virPidFileReadPathIfAlive(const char *path,
> }
> #endif
>
> - if (virAsprintf(&procpath, "/proc/%d/exe", *pid) < 0) {
> - *pid = -1;
> - return -1;
> - }
> + if (binpath) {
> + if (virAsprintf(&procpath, "/proc/%d/exe", *pid) < 0) {
This will need to be rebased if my pid_t cleanup patches go in first:
https://www.redhat.com/archives/libvir-list/2012-February/msg00560.html
My ACK from v3 still stands.
Also, I'm torn on whether this still qualifies for 0.9.10 (it's a useful
feature fix, but due to slow reviews, we've let it slip pretty far past
the freeze date). Thoughts?
--
Eric Blake eblake@xxxxxxxxxx +1-919-301-3266
Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list