Description of problem: When trying to find a reason why ABRT did not report any issue with unbound for bug #1562594, I found dropping user privileges from unbound without fork prevents kernel dumps of unbound. Version-Release number of selected component (if applicable): unbound-1.8.1-1.fc30 How reproducible: reliable Steps to Reproduce: 1. dnf install unbound abrt-cli-ng 2. systemctl restart unbound 3. kill -SIGSEGV $(systemctl -p MainPID show unbound | cut -d= -f2) 4. abrt list Actual results: No crash is recorded, kernel or abrt does not report anything Expected results: Crash with backtrace is recorder and can be submitted as bug. Additional info: Upstream added some neat features to unbound. I think --enable-systemd should be added to build and systemd service type changed from Type=simple to Type=notify. It would be able to report failed start of a service and state changes. Also it is desirable to drop most of privileges before even running unbound. It would require change from username: "unbound" to username: "". Then add into systemd service something like this: [Service] User=unbound CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_SYS_CHROOT CAP_SYS_RESOURCE CAP_NET_ADMIN CAP_DAC_READ_SEARCH AmbientCapabilities=CAP_NET_BIND_SERVICE CAP_SYS_CHROOT CAP_SYS_RESOURCE CAP_NET_ADMIN CAP_DAC_READ_SEARCH Such default configuration would enable ABRT reporting. And it would be more secure at the same time. When process changes effective uid, then it would no longer dump on crash. Unless workaround mentioned in bug #1562594 comment #34 is used.
Note: CAP_DAC_READ_SEARCH is probably unnecessary, but it is required for now because of bug #1640259. When it is fixed, it should no longer be necessary. It should be possible to use systemd Limits setting to not require CAP_SYS_RESOURCE as well. Not sure if it is worth the hassle.
I have to check if systemd support can be compiled in without enabling socket activation support (which is broken causing crashes, and makes no sense) It seems the config only has one option, use-systemd: yes|no which claims to enable socket activation.
This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.
I don't think anything has changed yet (just reproduced it still). But I still believe socket activation is really bad and it was causing crashes. If someone wants to split the --use-systemd into two, one for core systemd and one for socket activation, we could enable parts of this to fix the core dump issue
Guess it was done anyway so I'll close this bug as current release. This might trigger new issues where various DNS deaemons fight over who gets to run when multiple ones do socket activation, and lets hope socket activation no longer causes crashes.