Bug 127552 - after full install, postgresql starts on boot
Summary: after full install, postgresql starts on boot
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: postgresql
Version: rawhide
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Tom Lane
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-07-09 17:17 UTC by Alexandre Oliva
Modified: 2013-07-03 03:01 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-08-05 19:51:54 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Alexandre Oliva 2004-07-09 17:17:09 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510

Description of problem:
Daemons shouldn't start by default just because they were installed.

Version-Release number of selected component (if applicable):
postgresql-7.4.3-2

How reproducible:
Always

Steps to Reproduce:
1.Full install
2.Reboot

Actual Results:  postgres creates a database and starts postmaster

Expected Results:  It shouldn't

Additional info:

Comment 1 Tom Lane 2004-07-10 19:58:27 UTC
> Daemons shouldn't start by default just because they were installed.

Why not?  There are an awful lot of daemons running on my system that I can't recall 
having explicitly asked to start.  sendmail is an immediate counterexample.

Comment 2 Alexandre Oliva 2004-07-10 20:55:41 UTC
Sendmail does nothing unless you actually send messages through it. 
In the default configuration, it doesn't listen to the external
network, just sits there waiting for something to do.  And there
*will* be something to do, because cron jobs send email and sendmail
is what delivers it.

postgresql, OTOH, is a database server.  There's no point in running
it on every machine, just because you happen to do a full install on
all of them.  It shouldn't create a local database that nobody's going
to use.  It shouldn't accept connections, especially if there was no
action to control access to the database.  And if nobody bothered to
set up database accounts, nobody is going to use the database, so it
shouldn't be there taking up swap and disk space nor slowing the boot
down.

There's a security principle that says that what isn't strictly
necessary shoudln't be running.  People published a lot of articles
back when we shipped with everything enabled by default just because
it was convenient.  Firewalls solve only a very small part of the
problem.  Not running it in the first place, unless you want to, is
far safer.  Sure enough, not having it installed is even more secure.
 But lots of people will just do full installs because it's simpler. 
There's no reason to make their boxes even more of a swiss cheese.

Note that apache or squid aren't enabled by default, even though lots
of people use it.  NFS servers don't run unless you set them up.  Most
daemons don't run by default.  sendmail is the exception, because
there are very good reasons to have an MTA available by default.  But
there's no good reason to have a database server running by default. 
Not these days, anyway.

Comment 3 Tom Lane 2004-07-11 02:54:26 UTC
I have built new RPMs without the chkconfig change, but for now they are just in -HEAD.

Comment 4 Bill Nottingham 2004-08-05 19:51:54 UTC
Should be in rawhide now, then.

Comment 5 Alexandre Oliva 2004-09-05 06:13:09 UTC
Confirmed, thanks.


Note You need to log in before you can comment on or make changes to this bug.