Bug 127552 - after full install, postgresql starts on boot
after full install, postgresql starts on boot
Product: Fedora
Classification: Fedora
Component: postgresql (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Tom Lane
Depends On:
  Show dependency treegraph
Reported: 2004-07-09 13:17 EDT by Alexandre Oliva
Modified: 2013-07-02 23:01 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-05 15:51:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2004-07-09 13:17:09 EDT
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):

How reproducible:

Steps to Reproduce:
1.Full install

Actual Results:  postgres creates a database and starts postmaster

Expected Results:  It shouldn't

Additional info:
Comment 1 Tom Lane 2004-07-10 15:58:27 EDT
> 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 16:55:41 EDT
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

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-10 22:54:26 EDT
I have built new RPMs without the chkconfig change, but for now they are just in -HEAD.
Comment 4 Bill Nottingham 2004-08-05 15:51:54 EDT
Should be in rawhide now, then.
Comment 5 Alexandre Oliva 2004-09-05 02:13:09 EDT
Confirmed, thanks.

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