Description of problem: Systemd won't start mysql correctly. I only checked max open files, but I suppose there are problems with all custom values from my.cnf that require root privileges. Due to this permission issue, open_files_limit is not processed and value for max open files remains default 1024-4096 (soft-hard), even after changing the limit with ulimit -n or editing /etc/security/limits.conf. Also, if you delete the log file, on mysqld restart by systemctl it won't be automatically created and server won't start. Disabling mysqld.service in systemd and using the old init system will solve these problems. Version-Release number of selected component (if applicable): How reproducible: try to increase open files using configuration file, the values will not be processed. Also, just delete your mysqld.log file and it won't be automatically created. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Fix systemd to give enough permissions for services. Additional info:
mysqld.service specifies: User=mysql Group=mysql so the intention of the maintainer was clearly for mysql to be started unprivileged. Resource limits for a service can be set by systemd if needed. See "LimitNOFILE=" in "man systemd.exec". The mysql-server package ships an empty log file with the right permissions. If it's deleted, "rpm -V mysql-server" will notice the problem: missing c /var/log/mysqld.log It would be possible to add a service unit to start before mysqld.service and ensure that the log file exists and has the right permissions, but maybe just saying "Don't delete the log file, but feel free to truncate it" is the right solution. Reassigning to mysql for consideration.
(In reply to comment #1) > It would be possible to add a service unit to start before mysqld.service and > ensure that the log file exists and has the right permissions, but maybe just > saying "Don't delete the log file, but feel free to truncate it" is the right > solution. Indeed. The file is created by the RPM, and I don't see why someone would expect that randomly deleting it has no consequences for the service. Now, having said that, the systemd-based service is more fragile than the initscript-based one, because the initscript would recreate the file at need; this was trivial to do in the initscript since it launched as root. AFAIK it's not possible to do that in the systemd unit file because it will run all commands as the specified user (correct?). We could, as Michal says, invent a separate root-privileged unit file with no purpose other than to recreate the log file ... but that seems like overkill, and besides it's got failure modes of its own, like the user not choosing to enable the other service. So I'm not inclined to do anything about this. "Don't do that" seems sufficient.
I guess that can be done with: PermissionsStartOnly=
(In reply to comment #3) > I guess that can be done with: > PermissionsStartOnly= hmm ... if we could apply that to *some* ExecStartPre commands, and not others, it might help. As is, though, it's not nearly flexible enough.
(In reply to comment #2) > it's got failure modes of its own, like the user not choosing to enable > the other service. This is not a problem as the main service can pull the other service using "Wants=". Still I don't think it should be done.
You closed the report without giving a solution for the main problem. Can you please make a fix for systemd running mysqld or similar services to load variables correctly? At this time, because it's starting unprivileged, mysqld will not process my.cnf variables that require root privileges. They are simply not loaded.
On the whole, I think it's a security improvement that we are no longer starting mysqld as root. So I'm disinclined to undo that. Exactly which configuration variables are you talking about, and what is the use-case for setting them?
For example, open_files_limit in my.cnf can not be processed by mysql and daemon complains in log file as soft/hard limits for mysql will not go over 1024/4096. Even using ulimit or /etc/security/limits.conf to increase the limits will not help. This is a big problem in my opinion. That variable is just an example, actually anything requiring root privileges will not be processed. Just check please.
Well, it does seem like a reasonable feature request that a unit file be able to set the ulimit limits for the daemon it's about to launch. If that's not supported at the unit-file level, the only way to be able to do it is to launch the daemon as root, which surely isn't a desirable solution. Bouncing this back to the systemd queue ...
(In reply to comment #9) > Well, it does seem like a reasonable feature request that a unit file be able > to set the ulimit limits for the daemon it's about to launch. Perfectly reasonable indeed. And as I mentioned in comment #1, it is already possible: Resource limits for a service can be set by systemd if needed. See "LimitNOFILE=" in "man systemd.exec". To set it on your system, you can add a /etc/systemd/system/mysqld.service unit where you include the original unit: .include /lib/systemd/system/mysqld.service and then add the options you need. (The ".include" mechanism is documented "man systemd.unit").