Hi Vladimir,
well, I was seeing that the nfs-server was not
starting, on boot, in spite of having the "nfs-server"
enabled in systemd.   I could start the nfs-server
(and all the various nfs-related services) manually
with no problem. 

In /etc/systemd/system/multi-user.target.wants
there was a broken link from nfs.target to the
/usr/lib/systemd/system/nfs.target 

I put back a nfs.target file, and a reboot started
the nfs system, as it should. 

Some of  my other SL7 systems were not booted after
upgrading nfs-utils, so didn't show the problem, and
it's all to easy to assume "some startup glitch" 
start things manually, and not track down the cause.


On Mon, 18 May 2015 14:14:38 +0300
Vladimir Mosgalin <[log in to unmask]> wrote:

> Hi Chuck Lane!
> 
>  On 2015.05.17 at 14:53:12 -0500, Chuck Lane wrote next:
> 
> > between /local-repo/base/nfs-utils-1.3.0-0
> > and nfs-utils-1.3.0-0.8, the "nfs.target" file in
> > /usr/lib/systemd/system/ was removed.
> 
> It's not present in current version, yes.
> They changed service files itself so it's not used anymore. There've
> been some changes in that area, e.g. there is no explicit need to
> enable nfs secure services (gssd, svcgssd), systemd starts them
> automatically if needed.
> 
> > 
> > The effect is that the nfs server does not automatically start 
> > after a boot. 
> > 
> > The simple workaround that I used was to just copy the nfs.target
> > file from the older package.
> 
> This is wrong workaround. The correct is to remove nfs target from
> systemd and enable nfs-server.service
> 
> Like, remove all nfs services symlinks from
> /etc/systemd/system/multi-user.target.wants/
> 
> and do "systemctl enable nfs-server" if you need a server and
> "nfs-client" if you need a client.
> 



-- 
 Drexel University    \V               --Chuck Lane
======]---------->-----*------<--------[===========
     (215) 895-1545   / \_/*~~~~~  Particle Physics
FAX: (215) 895-1281  [log in to unmask]