[SERVER-33319] Systemd startup should not always be "forking". Created: 14/Feb/18 Updated: 19/Mar/18 Resolved: 19/Mar/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Packaging |
| Affects Version/s: | 3.4.11, 3.4.12, 3.4.13 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Max Allan | Assignee: | Mathew Robinson (Inactive) |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||
| Operating System: | ALL | ||||||||||||||||
| Steps To Reproduce: | Install an affected version of mongo. Set "fork: false" in your mongod.conf and start mongo with systemd. Wait a few minutes and systemd will kill it. |
||||||||||||||||
| Sprint: | Build 2018-03-12, Build 2018-03-26 | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
In ticket
And then your server starts and after a while systemd notices it hasn't forked and kills it. |
| Comments |
| Comment by Max Allan [ 19/Mar/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
"We have to ship our service file assuming that you're using our default configurations." Changing the default startup script when people will already have an unmodified startup script and working deployment will only cause you support hassle not me. It's up to you if you want to maintain this I'm not sure why you're trying to demonstrate that a modified systemd script will not be changed, I know, I haven't modified the script (I didn't need to, before you made this change, it worked) , so it gets upgraded by yum. This is a good thing, any new changes you add to the script will get made during updates. By forcing some people to change their startup script because they have made valid config changes to the product, they are now going to have to compare all future changes you make and retrofit them to their own startup script. This is probably not great.
yum WILL update an unmodified systemd script. That's its job. So your statement "Second, our RPM's do not overwrite existing systemd service files" is wrong (and your apostrophe is superfluous). Are you seriously saying customers should not change mongod.conf ? | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Mathew Robinson (Inactive) [ 19/Mar/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Hey Max, so a couple of quick notes. First, we ship with fork: true because we have to support some older init systems for our older RHEL and SUSE versions. Second, our RPMs do not overwrite existing systemd service files or existing /etc/mongod.conf files. As an example I spun up a RHEL 7.0 server and installed MongoDB 3.4:
As you can see our fake files in /etc/systemd/system and /etc/mongod.conf, are unchanged:
and just to verify myself I went ahead and upgraded from MongoDB 3.4 to 3.6:
and the files were still unchanged:
If you have a custom service file in /etc/systemd/system it will take precedence over /usr/lib/systemd/system, so you can see if I run systemctl start mongod:
It started my fake service file instead of the one that we ship which installs in /usr/lib/systemd/system/mongod.service.
When there is a conflict between an existing file and a file inside the package, rpm creates a new version (you can see this in the rpm output) called filename.rpmnew and leaves the existing file alone. So in short, since we aren't overriding any user files I see no reason to change our systemd service file. If you are customizing your systemd service file it's best practice to put it in /etc/systemd/system per the systemd docs and if you're customizing your mongod.conf but not the service file we leave that to our customers to resolve. We have to ship our service file assuming that you're using our default configurations. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Max Allan [ 14/Feb/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Apologies. I have no edit permission and couldn't set the OS field to "RedHat" when creating the ticket. Could someone with privs update it? |