[Bug 1166680] New: Postfix fails to start - missing /etc/services
http://bugzilla.suse.com/show_bug.cgi?id=1166680 Bug ID: 1166680 Summary: Postfix fails to start - missing /etc/services Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs@suse.de Reporter: william.brown@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- Postfix fails to start with: Mar 15 05:29:14 adularia postfix/master[9632]: fatal: 0.0.0.0:smtp: Servname not supported for ai_socktype Mar 15 05:29:15 adularia postfix/master[9631]: fatal: daemon initialization failure This is due to missing /etc/services: # ls -al /etc/services ls: cannot access '/etc/services': No such file or directory # ls -al /usr/etc/services -rw-r--r-- 1 root root 868252 Feb 6 12:16 /usr/etc/services Which was moved to /usr as part of https://kubic.opensuse.org/blog/2019-12-05-usr-etc/ Host: Tumbleweed Server openSUSE-release-20200312-486.1.x86_64 The following workaround is viable: ln -s /usr/etc/services /etc/services ● postfix.service - Postfix Mail Transport Agent Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2020-03-15 05:34:45 UTC; 5s ago -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166680 http://bugzilla.suse.com/show_bug.cgi?id=1166680#c1 Thorsten Kukuk <kukuk@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |william.brown@suse.com Flags| |needinfo?(william.brown@sus | |e.com) --- Comment #1 from Thorsten Kukuk <kukuk@suse.com> --- If you did take care about *.rpmsave and *.rpmnew files as documented everywhere, you don't need symlinks breaking your system later. Beside that, aaa_base should adjust /etc/nsswitch.conf, did you apply all updates (zypper dup) and what does the log says about your aaa_base update? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166680 http://bugzilla.suse.com/show_bug.cgi?id=1166680#c2 William Brown <william.brown@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(william.brown@sus | |e.com) | --- Comment #2 from William Brown <william.brown@suse.com> --- The system is fully patched. I will need to check the nsswitch though because that's the most likely culprit - I'm deploying an nsswitch through ansible to provide my sssd/kanidm config, and likely that has changes that are affecting it. It seems like that's a potential hiccup that can happen though, many people will have a /etc/nsswitch they'll push from a config management system, and will blow away whatever settings are there to adjust for this /etc/services business. Maybe a better or more transparent solution can be found? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166680 http://bugzilla.suse.com/show_bug.cgi?id=1166680#c3 --- Comment #3 from William Brown <william.brown@suse.com> --- Right, I see the problem. What I deployed: passwd: compat kanidm group: compat kanidm shadow: compat kanidm hosts: files mdns_minimal [NOTFOUND=return] dns networks: files dns services: files protocols: files rpc: files ethers: files netmasks: files netgroup: files nis publickey: files bootparams: files automount: files nis aliases: files What's on a "clean install" passwd: compat group: compat shadow: compat # Allow initgroups to default to the setting for group. # initgroups: compat hosts: files dns networks: files dns aliases: files usrfiles ethers: files usrfiles gshadow: files usrfiles netgroup: files nis protocols: files usrfiles publickey: files rpc: files usrfiles services: files usrfiles automount: files nis bootparams: files netmasks: files I think that it's going to happen that people absolutely will deploy their "as is" configs like I did, and they'll trip up over this issue. It's probably fine to ask me to "fix" this to usrfiles, but I think realistically that the solution should be that the "files" module should be updated to route these requests between /etc/services and /usr/etc/services instead, rather than rely on nsswitch here. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166680 http://bugzilla.suse.com/show_bug.cgi?id=1166680#c4 --- Comment #4 from William Brown <william.brown@suse.com> --- Another consideration here is people will zypper upgrade with a customised /etc/nsswitch.conf, and the usrfiles line won't be added which will also cause silent breakage. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166680 http://bugzilla.suse.com/show_bug.cgi?id=1166680#c5 --- Comment #5 from Thorsten Kukuk <kukuk@suse.com> --- (In reply to William Brown from comment #4)
Another consideration here is people will zypper upgrade with a customised /etc/nsswitch.conf, and the usrfiles line won't be added which will also cause silent breakage.
This cannot happen. And it is not a silent breakage, as you notice it through failing services. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=1166680 http://bugzilla.suse.com/show_bug.cgi?id=1166680#c6 Thorsten Kukuk <kukuk@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #6 from Thorsten Kukuk <kukuk@suse.com> --- (In reply to William Brown from comment #2)
It seems like that's a potential hiccup that can happen though, many people will have a /etc/nsswitch they'll push from a config management system, and will blow away whatever settings are there to adjust for this /etc/services business. Maybe a better or more transparent solution can be found?
We have a transparent, working solution. But if you overwrite the file afterwards with an outdated version, there is nothing we can do. This is Ok on openSUSE Leap or SLE, were we try to maintain compatibility and try to avoid such breakage during one release (but not with SP or major version updates), but with an rolling release distribution like Tumbleweed you need to expect such a breakage with every release and you need to adjust your configuration. Or fix your ansible setup to not overwrite nsswitch.conf with an outdated version, but only to modify the entries you want to change. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com