The following bug has been logged online:

Bug reference: 2327
Logged by: Tom Hollins
Email address: tom.hollins@sherwin.com
PostgreSQL version: 8.1.3
Operating system: Linux (Fedora Core 4)
Description: Startup script for FC4 with selinux
Details:

It was in a previous version of the init scripts. Not sure if those came
with the OS release or whether I installed it. However, if you want to
release the script for FC4 just edit your ../contrib/startup-scripts/linux
and replace all su commands with runuser commands.

I just thought you might want to know this. And hopefully it helps you with
your paying support customers.

Good luck, great product,
-T-

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

"Tom Hollins" <tom.hollins@sherwin.com> writes:
> It was in a previous version of the init scripts. Not sure if those came
> with the OS release or whether I installed it. However, if you want to
> release the script for FC4 just edit your ../contrib/startup-scripts/linux
> and replace all su commands with runuser commands.

Actually, I'm wondering why we have the contrib/startup-scripts/linux
file in there at all, when it is several years behind the initscript
that ships with the RPM distributions (either PGDG or Red Hat).

We could push the RPM initscript into the contrib item, but I fear we'd
forget again to keep it up to date.

Comments anyone?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Hi,

On Fri, 2006-03-17 at 00:31 -0500, Tom Lane wrote:
> We could push the RPM initscript into the contrib item, but I fear
> we'd
> forget again to keep it up to date.
>
> Comments anyone?

We don't change initscript so often, so keeping it up2date will not be
hard -- I'll remind you when we change the initscript in PGDG RPMS.

Regards,
--
The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: PL/php, plPerlNG - http://www.commandprompt.com/


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Tom Lane wrote:
> We could push the RPM initscript into the contrib item, but I fear
> we'd forget again to keep it up to date.

I doubt that the RPM init script is going to be portable to all Linux
systems. I think it's useful to have a generic script there for people
doing source installations.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane wrote:
>> We could push the RPM initscript into the contrib item, but I fear
>> we'd forget again to keep it up to date.

> I doubt that the RPM init script is going to be portable to all Linux
> systems. I think it's useful to have a generic script there for people
> doing source installations.

Well, the other side of that coin is that an unmaintained script isn't
going to be portable to all Linux systems either, as per the OP's point
that what's there now simply does not work on a SELinux-enabled machine.
At least the RPM script gets tested regularly.

I will grant you that the contrib script ought to default to assuming
installation paths under /usr/local instead of where the RPMs put
things, but beyond that I'm not sure what's unportable in the current
RPM init scripts.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

Am Freitag, 17. März 2006 15:25 schrieb Tom Lane:
> I will grant you that the contrib script ought to default to assuming
> installation paths under /usr/local instead of where the RPMs put
> things, but beyond that I'm not sure what's unportable in the current
> RPM init scripts.

Assuming that /etc/rc.d exists. (fails on Debian)

Assuming that /etc/rc.d/init.d/functions exist. (fails on Debian and SuSE)
(Later on I see a number of functions I don't recognize that probably come
from here.)

Assuming that a command named "typeset" exists. (fails on Debian and SuSE)

Assuming that a file named /etc/sysconfig/network exists. (fails on Debian and
SuSE)

Location of data and log directories are handled differently on other systems.

Various bashisms. Yes, I've seen people use the contrib script on systems
where bash != sh.

Assuming that /var/lock/subsys exists. (fails on Debian)

The one thing that really bugs me about this init script is that it tries to
run initdb if it doesn't find the data directory. This is really trouble on
the type of HA systems that people (should) use. I don't want that sort of
thing in the PostgreSQL source distribution.

So, if there is a problem with the start script in contrib, let's fix it, but
I think it's obvious that the Red Hat RPM start script should remain just
that.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

I hope I'm not overstepping here, and not sure if I'm allowed to reply,
but here goes:
It looks like there are two approaches to this:
1) Unify the init scripts so they work all the time everywhere.
2) Generate the scripts as needed per distribution and risk being out of
date.

Option 1 seems like more work for overworked Open Source developers so I
wouldn't choose that.

Option 2 seems more logical since they are in the contrib directory, it
is assumed they could be out of date. I approach contrib as a "This is a
good starting point but I may have to modify what is here." If it can
be kept up to date, that's fine, but shouldn't be a priority. Besides,
if someone (business) really needs this, then they can pay your support
staff for on the spot fixes and installation knowledge.

IMHO
Tom Hollins
-T-


Tom Lane wrote:

>Peter Eisentraut <peter_e@gmx.net> writes:
>
>
>>Tom Lane wrote:
>>
>>
>>>We could push the RPM initscript into the contrib item, but I fear
>>>we'd forget again to keep it up to date.
>>>
>>>
>
>
>
>>I doubt that the RPM init script is going to be portable to all Linux
>>systems. I think it's useful to have a generic script there for people
>>doing source installations.
>>
>>
>
>Well, the other side of that coin is that an unmaintained script isn't
>going to be portable to all Linux systems either, as per the OP's point
>that what's there now simply does not work on a SELinux-enabled machine.
>At least the RPM script gets tested regularly.
>
>I will grant you that the contrib script ought to default to assuming
>installation paths under /usr/local instead of where the RPMs put
>things, but beyond that I'm not sure what's unportable in the current
>RPM init scripts.
>
> regards, tom lane
>
>
>


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly