Bug 848903 - Any chance of moving /etc/my.cnf to /etc/mysql/my.cnf?
Any chance of moving /etc/my.cnf to /etc/mysql/my.cnf?
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: mysql (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Tom Lane
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-16 14:28 EDT by Daniel Walsh
Modified: 2012-08-20 10:30 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-20 06:20:47 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Daniel Walsh 2012-08-16 14:28:04 EDT
Trying to build containes with a shared /etc, having configuration data in the /etc dir, gets very difficult.  If you left a symbolic link from /etc/my.cnf to /etc/mysql/my.cnf, that would give you back wards compatability.

The container code then could bind mount a chroot /etc/mysql over the real /etc/mysql and allow processes within the container to write their config.
Comment 1 Tom Lane 2012-08-19 14:03:27 EDT
Hm, not sure about that.  The scenario that worries me is that somebody edits /etc/my.cnf and his editor moves the symlink to /etc/my.cnf~ and writes a plain file at /etc/my.cnf.  Emacs seems to know enough to not do that, but I don't have a lot of confidence that all other editors do too.

In general, we do not expect mysql-related processes to ever write /etc/my.cnf: it's only meant to be edited by humans.  So I'm not sure exactly what scenario you're trying to cater to?
Comment 2 Daniel Walsh 2012-08-20 06:20:47 EDT
Well as I continued to play with containers, I was able to get mysql to work without having to make this change.  I think we can close this for now.  I am not sure what was complaining about.  If it starts happening in the F18 with containers, we can look at this again.

Currently I have all containers sharing the same /etc/my.cnf.  

Tom, do you know if postgresql will set itself up on the first service start like mysql does?  I am planning on attempting to create/start postgresql within a container.
Comment 3 Tom Lane 2012-08-20 10:30:24 EDT
(In reply to comment #2)
> Tom, do you know if postgresql will set itself up on the first service start
> like mysql does?  I am planning on attempting to create/start postgresql
> within a container.

It will not --- you need to issue an explicit database initialization command first.  Either "service postgresql initdb" or "postgresql-setup initdb" should do in the latest packages; before that you need one or the other depending on how old the package is.

The lack of an auto-initdb on first start is intentional, based on upstream practice and recommendation.  Many years ago, our initscript did have auto-initdb behavior, but then there were some high-profile cases of people losing their databases to it.  (IIRC the typical mechanism was to have the database on an NFS mount that was just a tad slow to come up, so that the mount point looked empty just before initdb was called, and then at some point initdb was overwriting existing catalog files.)  So now we insist on a manual action for that.

Personally I'd make the mysql initscript act the same way for the same reason, if I thought I could get away with it.  But I think mysql users are too used to "it just works!"

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