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

From Amit Kapila
Subject Re: pg_ctl status with nonexistent data directory
Date
Msg-id CAA4eK1Jv_WYco6Nk8chSve6EH0zAc7JO_7QXxs9-j24UsmkPQw@mail.gmail.com
Whole thread Raw
In response to Re: pg_ctl status with nonexistent data directory  (Bruce Momjian <bruce@momjian.us>)
Responses Re: pg_ctl status with nonexistent data directory  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Thu, Mar 6, 2014 at 4:38 AM, Bruce Momjian <bruce@momjian.us> wrote:
> On Mon, Nov  4, 2013 at 11:31:30AM -0500, Robert Haas wrote:
>> On Sat, Nov 2, 2013 at 3:32 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>> > This doesn't seem right:
>> >
>> > $ pg_ctl -D /nowhere status
>> > pg_ctl: no server running
>> >
>> > It does exit with status 3, so it's not all that broken, but I think the
>> > error message could be more accurate.
>>
>> I doubt anyone will object if you feel the urge to fix it.  I won't, anyway.
>
> 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'.

But for such cases, isn't the status 4 more appropriate?
As per above link "4 program or service status is unknown"

status 1 - "1 program is dead and /var/run pid file exists"
Going by this definition, it seems status 1 means, someone
has forcefully killed the server and pid file still remains.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Kouhei Kaigai
Date:
Subject: Re: Custom Scan APIs (Re: Custom Plan node)
Next
From: Peter Geoghegan
Date:
Subject: Re: jsonb and nested hstore