Re: pg_ctl status with nonexistent data directory

Поиск
Список
Период
Сортировка
От Florian Pflug
Тема Re: pg_ctl status with nonexistent data directory
Дата
Msg-id 6D88966E-6D28-477F-B09C-AE1EBE0A6548@phlo.org
обсуждение исходный текст
Ответ на Re: pg_ctl status with nonexistent data directory  (Bruce Momjian <bruce@momjian.us>)
Список 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 по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: jsonb and nested hstore
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: pg_ctl status with nonexistent data directory