Re: pg_ctl status with nonexistent data directory - Mailing list pgsql-hackers

From Florian Pflug
Subject Re: pg_ctl status with nonexistent data directory
Date
Msg-id 6D88966E-6D28-477F-B09C-AE1EBE0A6548@phlo.org
Whole thread Raw
In response to Re: pg_ctl status with nonexistent data directory  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Mar6, 2014, at 00:08 , Bruce Momjian <bruce@momjian.us> wrote:
> I have addressed this issue with the attached patch:
>
>     $ pg_ctl -D /lkjasdf status
>     pg_ctl: directory "/lkjasdf" does not exist
>     $ pg_ctl -D / status
>     pg_ctl: directory "/" is not a database cluster directory
>
> One odd question is that pg_ctl status has this comment for reporting
> the exit code for non-running servers:
>
>    printf(_("%s: no server running\n"), progname);
>
>    /*
>     * The Linux Standard Base Core Specification 3.1 says this should return
>     * '3'
>     * https://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
>     */
>    exit(3);
>
> If they haven't passed us a data directory, we don't really know if the
> server is running or not, so the patch just returns '1'.

Why change the exit code at all in the ENOENT-case? If the directory
does not exist, it's fairly certain that the server is not running, so
"3" seems fine. Technically, changing the return value is an API change
and might break things, so why do it if there's no clear benefit?

In the EPERM case (or, rather the non-ENOENT case), I agree with Amit
that "4" (meaning "program or service status is unknown") fits much better
than "1" (meaning "program is dead and /var/run pid file exists"). So *if*
we change it at all, we should change it to 4, not to some other, equally
arbitrary value.

best regards,
Florian Pflug








pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: jsonb and nested hstore
Next
From: Alvaro Herrera
Date:
Subject: Re: pg_ctl status with nonexistent data directory