Bug 699040 - Providing native systemd file for upcoming F15 Feature Systemd
Providing native systemd file for upcoming F15 Feature Systemd
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: nfs-utils (Show other bugs)
rawhide
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Steve Dickson
Fedora Extras Quality Assurance
: Reopened
: 722795 725259 (view as bug list)
Depends On:
Blocks: SysVtoSystemd
  Show dependency treegraph
 
Reported: 2011-04-22 14:49 EDT by Jóhann B. Guðmundsson
Modified: 2011-09-13 07:59 EDT (History)
8 users (show)

See Also:
Fixed In Version: nfs-utils-1.2.4-8.fc16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-09-09 13:12:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Native systemd service file for nfslock service (337 bytes, text/plain)
2011-04-22 14:49 EDT, Jóhann B. Guðmundsson
no flags Details
/etc/sysconfig/nfs (1.82 KB, text/plain)
2011-04-22 14:50 EDT, Jóhann B. Guðmundsson
no flags Details
Native systemd service file for rpcgssd (256 bytes, text/plain)
2011-04-22 14:52 EDT, Jóhann B. Guðmundsson
no flags Details
Native systemd service file for rpcidmapd (229 bytes, text/plain)
2011-04-22 14:53 EDT, Jóhann B. Guðmundsson
no flags Details
Native systemd service file for rpcsvcgssd (262 bytes, text/plain)
2011-04-22 14:54 EDT, Jóhann B. Guðmundsson
no flags Details
All service daemon merged back into the nfs.service (794 bytes, text/plain)
2011-06-29 16:19 EDT, Jóhann B. Guðmundsson
no flags Details
nfs-secure.service (336 bytes, text/plain)
2011-06-30 12:22 EDT, Jóhann B. Guðmundsson
no flags Details
New nfslock.service (496 bytes, text/plain)
2011-07-08 03:12 EDT, Jóhann B. Guðmundsson
no flags Details
nfslock.service 3000 now even leaner and meaner.. (538 bytes, text/plain)
2011-07-11 14:30 EDT, Jóhann B. Guðmundsson
no flags Details
dmesg and tail (7.41 KB, text/plain)
2011-09-06 14:34 EDT, Tom H
no flags Details

  None (edit)
Description Jóhann B. Guðmundsson 2011-04-22 14:49:28 EDT
Created attachment 494288 [details]
Native systemd service file for nfslock service

Description of problem:

The attached file is a native systemd file for upcoming F15 Feature [1]

Please read [2] on how to packaging and installing systemd Service files.

To learn more about Systemd daemon see [3].

To view old SysV with the new Systemd site by site see for your component see [4]

If you have any question dont hesitate to ask them on this bug report.

1.http://fedoraproject.org/wiki/Features/systemd

2.https://fedoraproject.org/wiki/Systemd_Packaging_Draft

3.http://0pointer.de/public/systemd-man/daemon.html

4.https://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability 

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Jóhann B. Guðmundsson 2011-04-22 14:50:48 EDT
Created attachment 494289 [details]
/etc/sysconfig/nfs

Minor changes needed for nfslock
Comment 2 Jóhann B. Guðmundsson 2011-04-22 14:52:17 EDT
Created attachment 494290 [details]
Native systemd service file for rpcgssd
Comment 3 Jóhann B. Guðmundsson 2011-04-22 14:53:14 EDT
Created attachment 494291 [details]
Native systemd service file for rpcidmapd
Comment 4 Jóhann B. Guðmundsson 2011-04-22 14:54:37 EDT
Created attachment 494292 [details]
Native systemd service file for rpcsvcgssd
Comment 5 Jóhann B. Guðmundsson 2011-04-22 14:59:33 EDT
Just getting the ball rolling on nfs I'll probably end up splitting out rpc.mountd into seperate service then it's also if we want to create service nfs-server and nfs-client.
Comment 6 Bill Nottingham 2011-04-26 13:35:47 EDT
Moving systemd service RFEs to rawhide.

At this point, it is not appropriate in the Fedora 15 cycle to add these. Furthermore, at this point, we are still finalizing the packaging guidelines to handle SysV -> systemd upgrades.

We therefore request:
- wait until there are packaging guidelines (this will be announced on the devel list). This ensures that upgrades will work smoothly and we/you won't have to do multiple sets of changes.
- work on these sorts of changes for Fedora 16 where necessary, not Fedora 15, as we're trying to fix things for release.
- do *not* change a service from SysV to systemd in an existing release (such as Fedora 15), as this is the sort of behavior change that goes against our update policy, documented as https://fedoraproject.org/wiki/Updates_Policy
Comment 7 Jóhann B. Guðmundsson 2011-06-27 10:39:59 EDT
What's the current status on this?

We need this in rawhide as soon as possible unless ofcourse you guys want to
block alpha.. 

https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd
https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd
http://fedoraproject.org/wiki/Packaging:Tmpfiles.d
Comment 8 Steve Dickson 2011-06-28 17:10:40 EDT
(In reply to comment #5)
> Just getting the ball rolling on nfs I'll probably end up splitting out
> rpc.mountd into seperate service then it's also if we want to create service
> nfs-server and nfs-client.

There is nothing that really has to happen on the nfs-client
side and moving rpc.mountd out of an nfs-server service 
simply make no sense... One can not live without the other.
Comment 9 Jóhann B. Guðmundsson 2011-06-28 17:51:01 EDT
It's propably going take some time to get my head back into this anywho the reason I'm splitting this out is to simplify the services we can always bind them together and order the service startup between them as we see fit with BindTo= or Requires= followed by Before=, After= for startup ordering them ( man systemd.units for details on those two ).
Comment 10 Jóhann B. Guðmundsson 2011-06-28 17:58:28 EDT
+ I think it's easier that we split them apart to get the desired behaviour out of each daemon by it self once that is done I think we can considered merging service files together if needed right?
Comment 11 Steve Dickson 2011-06-29 11:14:21 EDT
(In reply to comment #10)
> + I think it's easier that we split them apart to get the desired behaviour out
> of each daemon by it self once that is done I think we can considered merging
> service files together if needed right?
Is it now a violation to start two daemons from one service? If not
that again, it make no sense split rpc.mountd out the nfs server
service for the simple fact rpc.mount need for the nfs server 
service to function at all...

IMHO splitting them apart will *not* make things similar since
now there are two services have to be started synchronous way, 
which make  things more complicated.
Comment 12 Jóhann B. Guðmundsson 2011-06-29 11:35:22 EDT
(In reply to comment #11)
> (In reply to comment #10)
> > + I think it's easier that we split them apart to get the desired behaviour out
> > of each daemon by it self once that is done I think we can considered merging
> > service files together if needed right?

> Is it now a violation to start two daemons from one service? If not
> that again, it make no sense split rpc.mountd out the nfs server
> service for the simple fact rpc.mount need for the nfs server 
> service to function at all...

? 

I set split them apart test them separately then put them back together anywho there is not need for you to use the provided service files they only exist to assist/aid in the converting process so feel free to come up with your own they just need to be packaged and ready before we start composing alpha
Comment 13 Steve Dickson 2011-06-29 13:48:58 EDT
(In reply to comment #11)
> (In reply to comment #10)
> > + I think it's easier that we split them apart to get the desired behaviour out
> > of each daemon by it self once that is done I think we can considered merging
> > service files together if needed right?
> Is it now a violation to start two daemons from one service? 
I think I found the answer to my question... It appears its
impossible (or at least nobody does) to have one .service file
start up multiple daemons or do multiple commands... 

So I guess the reason behind split out rpc.mountd, nfsd, and
exportfs into different service is because it is the *only*
way to do it, correct? Or am I missing something?
Comment 14 Jóhann B. Guðmundsson 2011-06-29 14:16:57 EDT
(In reply to comment #13)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > + I think it's easier that we split them apart to get the desired behaviour out
> > > of each daemon by it self once that is done I think we can considered merging
> > > service files together if needed right?
> > Is it now a violation to start two daemons from one service? 
> I think I found the answer to my question... It appears its
> impossible (or at least nobody does) to have one .service file
> start up multiple daemons or do multiple commands... 

Well we usually make one service file per daemon ( as it should be ) but each service file is capable of starting multiple commands you just add more Exec* line and they get executed in the order you put them like

ExecStart=/command 1
ExecStart=/command 2
etc.. 

> 
> So I guess the reason behind split out rpc.mountd, nfsd, and
> exportfs into different service is because it is the *only*
> way to do it, correct? Or am I missing something?

Nope it's not the *only* way of doing it but it's the *correct* way of doing it ( one service file for each daemon )  and all you need to tie them to the nfs.service is to add BindTo=nfs.service to the [Unit] section of those service file you want started or stopped when you start or stop the nfs.service  

We only have left to split out nfsd and rpc.mountd and rpc.rquotad into seperated systemd service file.

Exportfs is a part of the nfsd startup hence we just call 

"ExecStartPre=/usr/sbin/exportfs -r"

Before running

"ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS $RPCNFSDCOUNT"

which will reexport  all  directories before starting the daemon
Comment 15 Jóhann B. Guðmundsson 2011-06-29 16:19:02 EDT
Created attachment 510532 [details]
All service daemon merged back into the nfs.service

I merged back all services into one big nfs.service after I had tested them individually with systemd this is something probably more in line with what you were thinking note that you probably will need adjust /etc/sysconfig/nfs to make this work.
Comment 16 Jóhann B. Guðmundsson 2011-06-29 16:25:16 EDT
Btw afaik modules should be loaded via autoloading based on bus information, or via /etc/modules-load.d/*.conf. and unloading a module from the kernel should not
be done except for debugging purposes so loading all these modules is it really necessary?
Comment 17 Steve Dickson 2011-06-30 10:14:49 EDT
(In reply to comment #15)
> Created attachment 510532 [details]
> All service daemon merged back into the nfs.service
> 
> I merged back all services into one big nfs.service after I had tested them
> individually with systemd this is something probably more in line with what you
> were thinking note that you probably will need adjust /etc/sysconfig/nfs to
> make this work.

Question, is a way to conditionally start daemons from .service files?
The reason being, rpc.svcgssd only needs to be started when
   1) The nfs server is started
   2) When SECURE_NFS is set in /etc/sysconf/nfs

Similar with rpc.gssd. It only needs to be started
when SECURE_NFS is set in /etc/sysconf/nfs.
Comment 18 Jóhann B. Guðmundsson 2011-06-30 10:32:36 EDT
Not that i'm aware of and the point is that if you want to start/enable a service daemon you simply start and enable that service daemon ( in this case rpc.svcgssd and rpc.gssd ) 

You can simply work around it by adding ExecStartPre=-$SRPCSVCGSSD and have users unhash SRPCSVCGSSD="/usr/sbin/rpc.svcgssd" and the same for rpc.gssd line in /etc/sysconf/nfs as opposed to have them unhash "#SECURE_NFS="yes"" 

From my pov users/admins should just run

systemctl start rpcsvcgssd.service rpcgssd.service && systemctl enable rpcsvcgssd.service rpcgssd.service 

if they have any intention of "securing nfs"
Comment 19 Steve Dickson 2011-06-30 12:10:15 EDT
(In reply to comment #18)
> Not that i'm aware of and the point is that if you want to start/enable a
> service daemon you simply start and enable that service daemon ( in this case
> rpc.svcgssd and rpc.gssd ) 
Well if an environment is not setup correctly "simply start and enable that 
service daemon" will cause needless failures.... 
 
> 
> You can simply work around it by adding ExecStartPre=-$SRPCSVCGSSD and have
> users unhash SRPCSVCGSSD="/usr/sbin/rpc.svcgssd" and the same for rpc.gssd line
> in /etc/sysconf/nfs as opposed to have them unhash "#SECURE_NFS="yes"" 
So you are saying they will have to edit both the rpcgssd.service
and rpcsvcgss.service file to enable these servers.. Will his be a 
common practice having people edit these files?


> 
> From my pov users/admins should just run
> 
> systemctl start rpcsvcgssd.service rpcgssd.service && systemctl enable
> rpcsvcgssd.service rpcgssd.service 
> 
> if they have any intention of "securing nfs"
hmm... IMHO, at least with NFS, this is a major step backwards 
WRT ease of use.... Not being able to do conditional daemon
start are defined by one file is is a major whole in the 
design of systemd... Hopefully that will be address in the 
very near feature.. 

Hmm, maybe can come up with a 'nfs-secure' command to hide 
all this ugliness...
Comment 20 Jóhann B. Guðmundsson 2011-06-30 12:22:42 EDT
Created attachment 510715 [details]
nfs-secure.service

Sample service that starts both rpc gssd and rpc svcgssd.
Comment 21 Jóhann B. Guðmundsson 2011-06-30 12:31:22 EDT
(In reply to comment #19)
> (In reply to comment #18)

> So you are saying they will have to edit both the rpcgssd.service
> and rpcsvcgss.service file to enable these servers.. Will his be a 
> common practice having people edit these files?

No what I'm saying is that you have to add 

"SRPCSVCGSSD="/usr/sbin/$foo" in /etc/sysconfig/nfs 
"SRPCGSSD="/usr/sbin/$bar" in /etc/sysconfig/nfs 

Then add

ExecStartPre=-$SRPCSVCGSSD
ExecStartPre=-$SRPCGSSD

Into the nfs.service file if as a work around 


> 
> 
> > 
> > From my pov users/admins should just run
> > 
> > systemctl start rpcsvcgssd.service rpcgssd.service && systemctl enable
> > rpcsvcgssd.service rpcgssd.service 
> > 
> > if they have any intention of "securing nfs"
> hmm... IMHO, at least with NFS, this is a major step backwards 
> WRT ease of use.... Not being able to do conditional daemon
> start are defined by one file is is a major whole in the 
> design of systemd... Hopefully that will be address in the 
> very near feature.. 

No relevant daemon/service code needs to be properly addressed and fixed 

> Hmm, maybe can come up with a 'nfs-secure' command to hide 
> all this ugliness...

Added a sample nfs-secure.service that starts both those daemons.

Anyway I'm not seeing this making any headway no matter how much I provide or try to explain to you and I need to pay attention to other services which have actual real problems so do as you think is the best just have it ready before alpha gets composed thanks
Comment 22 Steve Dickson 2011-06-30 12:38:26 EDT
(In reply to comment #21)
> (In reply to comment #19)
> > (In reply to comment #18)
> 
> > So you are saying they will have to edit both the rpcgssd.service
> > and rpcsvcgss.service file to enable these servers.. Will his be a 
> > common practice having people edit these files?
> 
> No what I'm saying is that you have to add 
> 
> "SRPCSVCGSSD="/usr/sbin/$foo" in /etc/sysconfig/nfs 
> "SRPCGSSD="/usr/sbin/$bar" in /etc/sysconfig/nfs 
> 
> Then add
> 
> ExecStartPre=-$SRPCSVCGSSD
> ExecStartPre=-$SRPCGSSD
> 
> Into the nfs.service file if as a work around 
Ah... 

> 
> 
> > 
> > 
> > > 
> > > From my pov users/admins should just run
> > > 
> > > systemctl start rpcsvcgssd.service rpcgssd.service && systemctl enable
> > > rpcsvcgssd.service rpcgssd.service 
> > > 
> > > if they have any intention of "securing nfs"
> > hmm... IMHO, at least with NFS, this is a major step backwards 
> > WRT ease of use.... Not being able to do conditional daemon
> > start are defined by one file is is a major whole in the 
> > design of systemd... Hopefully that will be address in the 
> > very near feature.. 
> 
> No relevant daemon/service code needs to be properly addressed and fixed 
> 
> > Hmm, maybe can come up with a 'nfs-secure' command to hide 
> > all this ugliness...
> 
> Added a sample nfs-secure.service that starts both those daemons.
> 
> Anyway I'm not seeing this making any headway no matter how much I provide or
> try to explain to you and I need to pay attention to other services which have
> actual real problems so do as you think is the best just have it ready before
> alpha gets composed thanks
Understood... thanks for your cycles!
Comment 23 Steve Dickson 2011-07-05 11:35:23 EDT
Question:

how should I covert the following case statement which
is in the current nfs init script:


	case $MOUNTD_NFS_V2 in
	no|NO)
	    RPCMOUNTDOPTS="$RPCMOUNTDOPTS --no-nfs-version 2" ;;
	esac

	case $MOUNTD_NFS_V3 in
	no|NO)
	    RPCMOUNTDOPTS="$RPCMOUNTDOPTS --no-nfs-version 3" ;;
	esac

Into systemd language? Is there away to added on arguments? 


tia...
Comment 24 Jóhann B. Guðmundsson 2011-07-05 11:42:11 EDT
You cant 

you have to pass all arguments as is to the daemon as in most likely add those lines into sysconfig/nfs and have the user uncomment either one..
Comment 25 Steve Dickson 2011-07-05 11:52:25 EDT
(In reply to comment #24)
> You cant 
Ok... 

> 
> you have to pass all arguments as is to the daemon as in most likely add those
> lines into sysconfig/nfs and have the user uncomment either one..

Actually I've decided not to mess with /etc/sysconf/nfs and 
just create a new EnvironmentFile called /etc/sysconf/nfsserivces
that will have every thing set that is needed... 

So is there a better place these days for this new EnvironmentFile to live
other than /etc/sysconfig?
Comment 26 Jóhann B. Guðmundsson 2011-07-05 11:58:57 EDT
/etc/sysconfig is the fedora/rhel thing I think debian puts it into another place and suse the third if I'm not mistaken..
Comment 27 Steve Dickson 2011-07-05 14:15:18 EDT
This is the error I'm getting: 

nfslock.service has more than one ExecStart setting, which is only allowed for Type=oneshot services. Refusing.

Which would make sense if Type was onshot in the nfslock.service file
but its not:
[Unit]
Description=NFS file locking service.
After=syslog.target network.target rpcbind.service
ConditionPathIsDirectory=/sys/module/sunrpc

[Service]
Type=forking
PIDFile=/var/run/sm-notify.pid
EnvironmentFile=/etc/sysconfig/nfsservices
ExecStartPre=/sbin/modprobe -q lockd $LOCKDARG
ExecStartPre=/sbin/rm -f /var/run/sm-notify.pid
ExecStart=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT
ExecStart=/sbin/sysctl -w fs.nfs.nlm_udpport=$LOCKD_UDPPORT
ExecStart=/sbin/rpc.statd $RPCSTATDARS
ExecStartPost=/sbin/sysctl -w fs.nfs.nlm_tcpport=0
ExecStartPost=/sbin/sysctl -w fs.nfs.nlm_udpport=0

[Install]
WantedBy=multi-user.target
Also=rpcbind.socket

any ideas?
Comment 28 Jóhann B. Guðmundsson 2011-07-05 14:42:34 EDT
you have Type=forking <-- hence you cannot have more than one ExecStart= lines there just as the message says.. 

Changes these from

ExecStart=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT
ExecStart=/sbin/sysctl -w fs.nfs.nlm_udpport=$LOCKD_UDPPORT

to 

ExecStartPre=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT
ExecStartPre=/sbin/sysctl -w fs.nfs.nlm_udpport=$LOCKD_UDPPORT
Comment 29 Steve Dickson 2011-07-05 16:56:46 EDT
(In reply to comment #28)
> you have Type=forking <-- hence you cannot have more than one ExecStart= lines
> there just as the message says.. 
> 
> Changes these from
> 
> ExecStart=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT
> ExecStart=/sbin/sysctl -w fs.nfs.nlm_udpport=$LOCKD_UDPPORT
> 
> to 
> 
> ExecStartPre=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT
> ExecStartPre=/sbin/sysctl -w fs.nfs.nlm_udpport=$LOCKD_UDPPORT

That's how you originally had it but the sysct appears to 
be racing with the 'ExecStartPre=/sbin/modprobe -q lockd $LOCKDARG'
because the sysctl was failing with an exit status of 255. But
if I did the sysct by hand, the command worked just fine... 

Is there any way to order the ExecStartPre commands or
be able to do more than one ExecStart start?
Comment 30 Jóhann B. Guðmundsson 2011-07-06 04:21:53 EDT
> That's how you originally had it but the sysct appears to 
> be racing with the 'ExecStartPre=/sbin/modprobe -q lockd $LOCKDARG'
> because the sysctl was failing with an exit status of 255. But
> if I did the sysct by hand, the command worked just fine... 

The proper command would be ExecStartPre=-/sbin/modprobe -qab <module> 

My best bet is that's probably because the module had not finished loading before /sbin/sysctl -w got executed.

> Is there any way to order the ExecStartPre commands or
> be able to do more than one ExecStart start?

As I mentioned in comment 14 that commands get executed/ordered in the sequence you put them in the service file.

As in 

ExecStartPre=/command 1
ExecStartPre=/command 2
ExecStart=/command 1
ExecStart=/command 2
etc.. 

Afaik this does not belong in a service file and needs to be fixed properly.. 

ExecStartPre=/sbin/modprobe -q lockd $LOCKDARG
ExecStart=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT
ExecStart=/sbin/sysctl -w fs.nfs.nlm_udpport=$LOCKD_UDPPORT

Propably admins should drop a conf file into /etc/modules-load.d containing 

# Load lockd module at boot  
 
lockd ARGS 

To load this add boot 

Then run /sbin/modprobe -qab lockd ARGS from cli 

Then add the relevant entry to /etc/sysctl.conf 

fs.nfs.nlm_tcpport = ARGS

Or

fs.nfs.nlm_udpport = ARGS

Then run sysctl -p /etc/sysctl.conf

Why was this put in the legacy sysv init script in the first place?

Are administrator changing the value of those arguments that frequently that warrants it to be done this way?
Comment 31 Steve Dickson 2011-07-06 08:53:14 EDT
(In reply to comment #30)
> > That's how you originally had it but the sysct appears to 
> > be racing with the 'ExecStartPre=/sbin/modprobe -q lockd $LOCKDARG'
> > because the sysctl was failing with an exit status of 255. But
> > if I did the sysct by hand, the command worked just fine... 
> 
> The proper command would be ExecStartPre=-/sbin/modprobe -qab <module> 
> 
> My best bet is that's probably because the module had not finished loading
> before /sbin/sysctl -w got executed.
I agree.... So in theory the following sequence should work... 
    ExecStartPre=modprobe; 
    ExecStartPre=sysctl
    ExecStartPre=sysctl


> 
> Afaik this does not belong in a service file and needs to be fixed properly.. 
> 
> ExecStartPre=/sbin/modprobe -q lockd $LOCKDARG
> ExecStart=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT
> ExecStart=/sbin/sysctl -w fs.nfs.nlm_udpport=$LOCKD_UDPPORT
This how I have it... but when do a systemctl daemon-reload I 
get the following error
    nfslock.service has more than one ExecStart setting, which is only allowed 
    for Type=oneshot services. Refusing.
Even when I remove the Type=forking line I get the same error.


> 
> Why was this put in the legacy sysv init script in the first place?
Yes. Admins would be able change one file /etc/sysconf/nfs build
the configuration they needed. This is goal I'm working for with
these new systemd services. They change one file /etc/sysconf/nfsserves
to again build their need NFS configuration.

> 
> Are administrator changing the value of those arguments that frequently that
> warrants it to be done this way?
I would guess once they get a working configuration they don't change
it much... But its a easy-of-use thing... It's much easer to tweak a couple 
variables in one configuration file than to files in numerous places
in the system,

Again, thanks your time...
Comment 32 Steve Dickson 2011-07-07 12:06:46 EDT
Once again I've looked around but are unable to find 
the answer to: what is the difference between

EnvironmentFile=-/etc/sysconfig/nfsservices

and 

EnvironmentFile=/etc/sysconfig/nfsservices

What is the meaning of the '=-'?

tia...
Comment 33 Jóhann B. Guðmundsson 2011-07-07 12:16:11 EDT
path beginning with "-" will result in the exit code to be ignored basically 
if /etc/sysconfig/nfsservices does not exist the service wont go into failed state without "-" it would...
Comment 34 Steve Dickson 2011-07-07 14:27:12 EDT
> 
> Well we usually make one service file per daemon ( as it should be ) but each
> service file is capable of starting multiple commands you just add more Exec*
> line and they get executed in the order you put them like
> 
> ExecStart=/command 1
> ExecStart=/command 2
This must not be the case with ExecStartPre because I have 
following lines in my .service file

ExecStartPre=/sbin/modprobe -q lockd $LOCKDARG
ExecStartPre=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT

and the failure is:

systemctl status nfslock.service
nfslock.service - NFS file locking service.
	  Loaded: loaded (/lib/systemd/system/nfslock.service)
	  Active: failed since Thu, 07 Jul 2011 14:35:39 -0400; 28s ago
	 Process: 2186 ExecStartPre=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT (code=exited, status=255)
	 Process: 2184 ExecStartPre=/sbin/modprobe -q lockd $LOCKDARG (code=exited, status=0/SUCCESS)

Which clearly show the sysctl is happening before the modprobe
which is causing the failure.

I there a way to synchronise the  ExecStartPre calls?
Comment 35 Steve Dickson 2011-07-07 14:48:47 EDT
Ordering does seems to be a bit broken

The service file looks like:

ExecStartPre=/sbin/modprobe -q lockd $LOCKDARG
ExecStart=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT

and the failure is

Process: 2561 ExecStart=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT (code=exited, status=255)
Process: 2559 ExecStartPre=/sbin/modprobe -q lockd $LOCKDARG (code=exited, status=0/SUCCESS)

So the ExecStart command are actually being started before the 
ExecStartPre command it finishing...
Comment 36 Steve Dickson 2011-07-07 14:58:16 EDT
Hmm... the man page states 

"more than one ExecStart= line is accepted which are then invoked one
 by one, sequentially in the order they appear in the unit file."

Which I guess is what happening, looking at the pids in the 
systemctl status output. But the man page does not say anything
about the processes being synchronous... Which obviously is not
the case.

So is there a way to synchronize either the  ExecStartPre or 
ExecStart commands?
Comment 37 Jóhann B. Guðmundsson 2011-07-07 16:12:53 EDT
(In reply to comment #36)
> Hmm... the man page states 
> 
> "more than one ExecStart= line is accepted which are then invoked one
>  by one, sequentially in the order they appear in the unit file."
> 
> Which I guess is what happening, looking at the pids in the 
> systemctl status output. But the man page does not say anything
> about the processes being synchronous... Which obviously is not
> the case.
> 
> So is there a way to synchronize either the  ExecStartPre or 
> ExecStart commands?

Nope not that I'm aware of and I think the problem is else where.

Why are you so stuck on that this is a systemd error not an real actual error

How does your /etc/sysconfig file look like basically 

/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT <--- what's being passed here? and do admin always configure both these entries or do they just use tcp or udp?
Comment 38 Steve Dickson 2011-07-07 18:54:18 EDT
(In reply to comment #37)
> (In reply to comment #36)
> > Hmm... the man page states 
> > 
> > "more than one ExecStart= line is accepted which are then invoked one
> >  by one, sequentially in the order they appear in the unit file."
> > 
> > Which I guess is what happening, looking at the pids in the 
> > systemctl status output. But the man page does not say anything
> > about the processes being synchronous... Which obviously is not
> > the case.
> > 
> > So is there a way to synchronize either the  ExecStartPre or 
> > ExecStart commands?
> 
> Nope not that I'm aware of and I think the problem is else where.
Where?

> 
> Why are you so stuck on that this is a systemd error not an real actual error
I guess I'm so stuck is because when I run the sysctl by hand, after
the module is loaded, the command works. Every single time.... Plus
it pretty obvious systemd is firing off commands in the order
the they are given but not waiting for one command to finish before
the next command is finish. 

This is probably ok if all the the ExecStartPre and ExecStart command
are run in this manner, but as soon as systemd crosses the boundary of not
wait for all the ExecStartPre commands to finish before starting 
the ExecStart commands will make it very painful for any 
complicated system, like NFS, to start up in a stable matter. 

There has to be some boundary where one part of the start up
is finished before other is started...  

> 
> How does your /etc/sysconfig file look like basically 
why does this matter? Its the default one that is installed...

> 
> /sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT <--- what's being passed
> here? and do admin always configure both these entries or do they just use tcp
> or udp?
Zero is being passed which tells the kernel to use a random port
Yes, admins set this all the time. This is how they make NFS play
nicely with firewalls....
Comment 39 Jóhann B. Guðmundsson 2011-07-07 19:13:41 EDT
> > How does your /etc/sysconfig file look like basically 
> why does this matter? Its the default one that is installed...

Please provide me with the content of the file exactly as you are using it along with content of the systemd unit file you have created exactly as you are using it.

By the way are you the only nfs maintainer ?
Comment 40 Steve Dickson 2011-07-07 19:41:28 EDT
(In reply to comment #39)
> > > How does your /etc/sysconfig file look like basically 
> > why does this matter? Its the default one that is installed...
> 
> Please provide me with the content of the file exactly as you are using it
> along with content of the systemd unit file you have created exactly as you are
> using it.
> 
> By the way are you the only nfs maintainer ?
Yes.... Why?

nfslock.service:
[Unit]
Description=NFS file locking service.
After=syslog.target network.target rpcbind.service
ConditionPathIsDirectory=/sys/module/sunrpc

[Service]
Type=oneshot
EnvironmentFile=-/etc/sysconfig/nfsservices
ExecStartPre=/sbin/modprobe -q lockd $LOCKDARG
ExecStart=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT
ExecStart=/sbin/sysctl -w fs.nfs.nlm_udpport=$LOCKD_UDPPORT
ExecStart=/sbin/rpc.statd $RPCSTATDARS
ExecStartPost=/sbin/sysctl -w fs.nfs.nlm_tcpport=0
ExecStartPost=/sbin/sysctl -w fs.nfs.nlm_udpport=0

[Install]
WantedBy=multi-user.target
Also=rpcbind.socket

/etc/sysctl.conf:
# Kernel sysctl configuration file
#
# For binary values, 0 is disabled, 1 is enabled.  See sysctl(8) and
# sysctl.conf(5) for more details.

# Controls IP packet forwarding
net.ipv4.ip_forward = 0

# Controls source route verification
net.ipv4.conf.default.rp_filter = 1

# Do not accept source routing
net.ipv4.conf.default.accept_source_route = 0

# Controls the System Request debugging functionality of the kernel
kernel.sysrq = 0

# Controls whether core dumps will append the PID to the core filename.
# Useful for debugging multi-threaded applications.
kernel.core_uses_pid = 1

# Disable netfilter on bridges.
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0
Comment 41 Jóhann B. Guðmundsson 2011-07-07 20:45:40 EDT
Seriously you cant be helped I asked for the files you are using and you deliberately skip the environment file the commands in the unit file are using.

I'm going to speak with fesco and see if they cant/supply an individual capable of working on this.
Comment 42 Steve Dickson 2011-07-07 21:57:43 EDT
(In reply to comment #41)
> Seriously you cant be helped I asked for the files you are using and you
> deliberately skip the environment file the commands in the unit file are using.
What "you cant be helped"?? Look at the log.. I have be trying to
make this work for close to a week...

Your words "Please provide me with the content of the file exactly as you are 
using" I post posted the nfslock.service as well as the syscntl.conf I 
thought you asked for?? What more are you looking for? 

> 
> I'm going to speak with fesco and see if they cant/supply an individual capable
> of working on this.
Fine... Please be sure I am involved in that discussion... I will not
allow you or anybody else to introduce instability into my subsystem
due to your theories verses facts derived from experience.
Comment 43 Jóhann B. Guðmundsson 2011-07-07 23:41:40 EDT
(In reply to comment #42)
> (In reply to comment #41)
> > Seriously you cant be helped I asked for the files you are using and you
> > deliberately skip the environment file the commands in the unit file are using.
> What "you cant be helped"?? Look at the log.. I have be trying to
> make this work for close to a week...
> 
> Your words "Please provide me with the content of the file exactly as you are 
> using" I post posted the nfslock.service as well as the syscntl.conf I 
> thought you asked for?? What more are you looking for? 
> 
> > 
> > I'm going to speak with fesco and see if they cant/supply an individual capable
> > of working on this.
> Fine... Please be sure I am involved in that discussion... I will not
> allow you or anybody else to introduce instability into my subsystem
> due to your theories verses facts derived from experience.

So I qoute my self from comment 37 

"How does your /etc/sysconfig file look like basically 

/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT <--- what's being passed
here?"

What is failing 

/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT

Now let's look at that command with no value submitted to it...

[root@valhalla system]# /sbin/sysctl -w fs.nfs.nlm_tcpport=
error: Malformed setting "fs.nfs.nlm_tcpport="

What do I need to know to diagnose this further.. 

The contents of /etc/sysconfig/nfsservices which I asked for

For the first part are you providing any value in $LOCKD_TCPPORT <--- 

" guess I'm so stuck is because when I run the sysctl by hand, after
the module is loaded, the command works. Every single time...."

The command will fail if the value of the variable for one reason or another is not being passed to /sbin/sysctl -w fs.nfs.nlm_tcpport= thus the service will fail to start and there is only one way to solve that and that is to pass ExecStartPre=/sbin/sysctl -w $PRANDPORT and you add entry like #PRANDPORT="fs.nfs.nlm_tcpport=12345 to /etc/sysconfig/nfsservices

Now let's look at how I handled the sysctl command in the "All service daemon merged back into the nfs.service" which I submitted a 8 days ago it looks --> ExecStartPre=/sbin/sysctl -w $PRANDPORT <---  What does this tell me.. 
THAT YOU DID NOT EVEN BOTHER LOOKING AT THE FILE I SUBMITTED TO YOU NOT EVEN AFTER I SPEND SEVERAL HOURS SPLITTING THE SERVICES APART AND PUTTING THEM BACK TOGETHER AT YOUR OWN REQUEST!
Comment 44 Jóhann B. Guðmundsson 2011-07-08 02:17:59 EDT
I apologies for snapping at you I've slept total of 8 hours the last four days ( and been up 24 hours now ) and have been under heavy stress from work with an added stress of getting ready/packaged/shipped the native systemd service for core + base + base -x + few extra service from the livecd before we start ( the sooner the better ) compose alpha so we disrupt the normal QA process as little as possible it was unprofessional of me so I hope you accept my apologies. 

Now that I have returned back to planet earth..

modify $LOCKD_TCPPORT and $LOCKD_UDPPORT the /etc/sysconfig/nfsservices to look like this.. 

#LOCKD_TCPPORT="fs.nfs.nlm_tcpport=12345"
#LOCKD_UDPPORT="fs.nfs.nlm_udpport=12345"


Then try this unit file  

[Unit]
Description=NFS file locking service.
After=syslog.target network.target rpcbind.service
ConditionPathIsDirectory=/sys/module/sunrpc

[Service]
Type=oneshot
EnvironmentFile=-/etc/sysconfig/nfsservices
ExecStartPre=/sbin/modprobe -q lockd $LOCKDARG
ExecStartPre=/sbin/sysctl -w $LOCKD_TCPPORT
ExecStartPre=/sbin/sysctl -w $LOCKD_UDPPORT
ExecStart=/sbin/rpc.statd $RPCSTATDARS
ExecStopPost=-/sbin/sysctl -w fs.nfs.nlm_tcpport=0
ExecStopPost=-/sbin/sysctl -w fs.nfs.nlm_udpport=0
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target
Also=rpcbind.socket

I modified the ExecStartPost= to be ExecStopPost= since I'm pretty sure you meant to reset the sysctl settings once the service had been stopped not after it had been started you can just reverse that if that was the intention

This starts cleanly for me atleast and value get passed to sysctl if line is uncommented and get reset when the service is stopped back to 0 

[root@valhalla system]# systemctl start nfslock.service 
[root@valhalla system]# systemctl status nfslock.service 
nfslock.service - NFS file locking service.
	  Loaded: loaded (/lib/systemd/system/nfslock.service)
	  Active: active (exited) since Fri, 08 Jul 2011 05:30:39 +0000; 2s ago
	 Process: 5896 ExecStart=/sbin/rpc.statd $RPCSTATDARS (code=exited, status=0/SUCCESS)
	 Process: 5895 ExecStartPre=/sbin/sysctl -w $UDPPORT (code=exited, status=0/SUCCESS)
	 Process: 5893 ExecStartPre=/sbin/sysctl -w $TCPPORT (code=exited, status=0/SUCCESS)
	 Process: 5892 ExecStartPre=/sbin/modprobe -q lockd $LOCKDARG (code=exited, status=0/SUCCESS)
	  CGroup: name=systemd:/system/nfslock.service
		  └ 5897 /sbin/rpc.statd
[root@valhalla system]# sysctl -a | grep fs.nfs.nlm_tcpport
fs.nfs.nlm_tcpport = 12345

And stops cleanly as well..
 
[root@valhalla system]# systemctl stop nfslock.service
[root@valhalla system]# systemctl status nfslock.service 
nfslock.service - NFS file locking service.
	  Loaded: loaded (/lib/systemd/system/nfslock.service)
	  Active: inactive (dead) since Fri, 08 Jul 2011 05:30:53 +0000; 1s ago
	 Process: 5906 ExecStopPost=/sbin/sysctl -w fs.nfs.nlm_udpport=0 (code=exited, status=0/SUCCESS)
	 Process: 5904 ExecStopPost=/sbin/sysctl -w fs.nfs.nlm_tcpport=0 (code=exited, status=0/SUCCESS)
	 Process: 5896 ExecStart=/sbin/rpc.statd $RPCSTATDARS (code=exited, status=0/SUCCESS)
	 Process: 5895 ExecStartPre=/sbin/sysctl -w $UDPPORT (code=exited, status=0/SUCCESS)
	 Process: 5893 ExecStartPre=/sbin/sysctl -w $TCPPORT (code=exited, status=0/SUCCESS)
	 Process: 5892 ExecStartPre=/sbin/modprobe -q lockd $LOCKDARG (code=exited, status=0/SUCCESS)
	  CGroup: name=systemd:/system/nfslock.service
[root@valhalla system]# sysctl -a | grep fs.nfs.nlm_tcpport
fs.nfs.nlm_tcpport = 0
Comment 45 Jóhann B. Guðmundsson 2011-07-08 03:12:08 EDT
Created attachment 511858 [details]
New nfslock.service

Minor cleanup to proposal in comment to save os 2 fork 

And remember to change the line in /etc/sysconfig/nfsservices

#LOCKD_TCPPORT="fs.nfs.nlm_tcpport=12345"
#LOCKD_UDPPORT="fs.nfs.nlm_udpport=12345"
Comment 46 jurek.bajor 2011-07-08 09:10:53 EDT
Johann,
I think you are "fixing" it to work according to your world view :-)

$ man sysctl
...
SYNOPSIS
...
       sysctl [-n] [-e] [-q] -w variable=value ...
...

So, if nfslock.service file contains:
...
ExecStart=/sbin/sysctl -w fs.nfs.nlm_tcpport=$LOCKD_TCPPORT
...

then this is the correct syntax.

If this does not work as processed by systemd, then that means a bug ...

JB
Comment 47 Steve Dickson 2011-07-09 22:56:46 EDT
(In reply to comment #45)
> Created attachment 511858 [details]
> New nfslock.service
> 
> Minor cleanup to proposal in comment to save os 2 fork 
> 
> And remember to change the line in /etc/sysconfig/nfsservices
> 
> #LOCKD_TCPPORT="fs.nfs.nlm_tcpport=12345"
> #LOCKD_UDPPORT="fs.nfs.nlm_udpport=12345"
So the bottom line is this.... Integer values can not be passed 
from  EnvironmentFile files to .server files. *Only* character 
strings are valid arguments to any and all ExecStartPre or 
ExecStart commands

If this is the case, the you really needed to document this 
in very bold letters in the man page because it totally unexpected
or concede its a bug and fix it.... I personally can live with 
either one... 

As far as that other noise... accepted... basically it just show 
your youth and inexperience which hopefully someday you'll grow 
out of it...
Comment 48 Jóhann B. Guðmundsson 2011-07-11 14:30:19 EDT
Created attachment 512273 [details]
nfslock.service 3000 now even leaner and meaner..
Comment 49 Jóhann B. Guðmundsson 2011-07-11 14:53:45 EDT
Now that we have a working nfslock.service what's next ?
Comment 50 jurek.bajor 2011-07-11 15:27:52 EDT
(In reply to comment #48)
> Created attachment 512273 [details]
> nfslock.service 3000 now even leaner and meaner..

I think you should correct this

ExecStartPre=/sbin/sysctl -w fs.nfs.nlm_tcpport=${LOCKD_UDPPORT} fs.nfs.nlm_tcpport=${LOCKD_TCPPORT}

to this

ExecStartPre=/sbin/sysctl -w fs.nfs.nlm_udpport=${LOCKD_UDPPORT} fs.nfs.nlm_tcpport=${LOCKD_TCPPORT}

JB
Comment 51 Fedora Update System 2011-07-12 08:45:21 EDT
cifs-utils-4.8.1-6.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/cifs-utils-4.8.1-6.fc14
Comment 52 Jeff Layton 2011-07-12 08:47:29 EDT
(In reply to comment #51)
> cifs-utils-4.8.1-6.fc14 has been submitted as an update for Fedora 14.
> https://admin.fedoraproject.org/updates/cifs-utils-4.8.1-6.fc14

Please disregard this comment. I put the wrong bug number in bodhi...
Comment 53 Steve Dickson 2011-07-28 15:33:41 EDT
I'm trying to automount /var/lib/nfs/rpc_pipefs
for the nfs-idmap.service


var-lib-nfs-rpc_pipefs.mount is:
[Unit]
Description=RPC Pipe File System
DefaultDependencies=no

[Mount]
What=sunrpc
Where=/var/lib/nfs/rpc_pipefs
Type=rpc_pipefs

var-lib-nfs-rpc_pipefs.automount is:
[Unit]
Description=RPC Pipe File System
DefaultDependencies=no

[Automount]
Where=/var/lib/nfs/rpc_pipefs

and the nfs-idmap.service is:
[Unit]
Description=Name to UID/GID mapping for NFSv4.
After=syslog.target network.target var-lib-nfs-rpc_pipefs.automount
ConditionPathIsDirectory=/sys/module/sunrpc

[Service]
Type=forking
EnvironmentFile=-/etc/sysconfig/nfs
ExecStart=/usr/sbin/rpc.idmapd $RPCIDMAPDARGS

[Install]
WantedBy=multi-user.target


Now I know a fact that /var/lib/nfs/rpc_pipefs
is being mount *after* the nfs-idmap.service 
is run, because:

rpc.idmapd is failing because 
     rpc.idmapd[819]: main: open(/var/lib/nfs/rpc_pipefs//nfs): No such file or directory

and the startup message clearly show the service is being
run before the mount:

Starting Name to UID/GID mapping for NFSv4....
Starting OpenSSH server daemon....
Started OpenSSH server daemon..
Starting RPC bind service...
Starting Sendmail Mail Transport Agent...
Started LSB: Mount and unmount network filesystems..
[   25.803165] RPC: Registered named UNIX socket transport module.
[   25.804236] RPC: Registered udp transport module.
[   25.805327] RPC: Registered tcp transport module.
[   25.806283] RPC: Registered tcp NFSv4.1 backchannel transport module.
[   25.889822] SELinux: initialized (dev rpc_pipefs, type rpc_pipefs), uses genfs_contexts

So any idea what is going on?

tia...
Comment 54 Jóhann B. Guðmundsson 2011-08-03 06:48:16 EDT
You arent going to build this for F16?
Comment 55 Fedora Update System 2011-08-03 07:07:22 EDT
nfs-utils-1.2.4-4.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/nfs-utils-1.2.4-4.fc16
Comment 56 Steve Dickson 2011-08-03 07:11:36 EDT
*** Bug 722795 has been marked as a duplicate of this bug. ***
Comment 57 Steve Dickson 2011-08-03 07:11:43 EDT
*** Bug 725259 has been marked as a duplicate of this bug. ***
Comment 58 Jóhann B. Guðmundsson 2011-08-03 07:15:51 EDT
Flagged done on https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd
Comment 59 Fedora Update System 2011-08-03 15:14:40 EDT
Package nfs-utils-1.2.4-4.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing nfs-utils-1.2.4-4.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/nfs-utils-1.2.4-4.fc16
then log in and leave karma (feedback).
Comment 60 Michal Jaegermann 2011-08-04 16:05:48 EDT
(In reply to comment #59)
> Package nfs-utils-1.2.4-4.fc16:
> * should fix your issue,

On the current rawhide with nfs-utils-1.2.4-5.fc17 I see the following:

# systemctl -a list-units | grep nfs
nfs.service               error  inactive   dead            nfs.service
nfslock.service           error  inactive   dead            nfslock.service

Check with 'systemctl status nfs.service' does not bring much of an information:

nfs.service
          Loaded: error
          Active: inactive (dead)

Well, that much I already know. With:

# systemctl list-units | grep rpc
rpcbind.service           loaded active     running         RPC bind service
rpcbind.socket            loaded active     listening       RPCbind Server Activation Socket

attempt to start by hand gives that:

# systemctl start nfs.service
Failed to issue method call: Unit nfs.service failed to load: No such file or directory. See system logs and 'systemctl status nfs.service' for details.

Status - see above.  Nothing I can find in system logs from that attempt.
The same with nfslock.service.

At least a half an hour ago the following showed up:

Aug  4 13:36:24 localhost rpcbind: Cannot open '/var/lib/rpcbind/rpcbind.xdr' file for reading, errno 2 (No such file or directory)
Aug  4 13:36:24 localhost rpcbind: Cannot open '/var/lib/rpcbind/portmap.xdr' file for reading, errno 2 (No such file or directory)

Indeed, such files do not exist.  Relevant?

AFAICS this is a sharp regress as before I was able at least to start
nfslock.service and nfs.service myself and now this is gone.
Comment 61 Michal Jaegermann 2011-08-04 17:20:15 EDT
I should add that right after a reboot running
# systemctl -a list-units | egrep 'rpc|nfs'
is not finding anything. Only after I will try 'systemctl start rpcbind.service'
I can notice rpcbind.service and rpcbind.socket respectively "running" and "listening".
Comment 62 Steve Dickson 2011-08-04 22:15:21 EDT
(In reply to comment #60)
> (In reply to comment #59)
> > Package nfs-utils-1.2.4-4.fc16:
> > * should fix your issue,
> 
> On the current rawhide with nfs-utils-1.2.4-5.fc17 I see the following:
> 
> # systemctl -a list-units | grep nfs
> nfs.service               error  inactive   dead            nfs.service
> nfslock.service           error  inactive   dead            nfslock.service
> 
> Check with 'systemctl status nfs.service' does not bring much of an
> information:
> 
> nfs.service
>           Loaded: error
>           Active: inactive (dead)
> 
> Well, that much I already know. With:
> 
> # systemctl list-units | grep rpc
> rpcbind.service           loaded active     running         RPC bind service
> rpcbind.socket            loaded active     listening       RPCbind Server
> Activation Socket
> 
> attempt to start by hand gives that:
> 
> # systemctl start nfs.service
> Failed to issue method call: Unit nfs.service failed to load: No such file or
> directory. See system logs and 'systemctl status nfs.service' for details.
> 
> Status - see above.  Nothing I can find in system logs from that attempt.
> The same with nfslock.service.
> 
> At least a half an hour ago the following showed up:
> 
> Aug  4 13:36:24 localhost rpcbind: Cannot open '/var/lib/rpcbind/rpcbind.xdr'
> file for reading, errno 2 (No such file or directory)
> Aug  4 13:36:24 localhost rpcbind: Cannot open '/var/lib/rpcbind/portmap.xdr'
> file for reading, errno 2 (No such file or directory)
> 
> Indeed, such files do not exist.  Relevant?
NO... it should not be a show stopper...


> 
> AFAICS this is a sharp regress as before I was able at least to start
> nfslock.service and nfs.service myself and now this is gone.
If rpcbind is not running then nfs.server will not run..

what is the output of 'ps ax | grep rpcbind' and 'rpcinfo -p'?

Also, just for package sanity sake are nfs-idmap.service 
and nfs-lock.servers up and running?

Please Note, I will be taking tomorrow (Fri Aug 4) off
so I my not be able to reply until after the weekend.
Comment 63 Michal Jaegermann 2011-08-05 14:23:34 EDT
(In reply to comment #62)

> If rpcbind is not running then nfs.server will not run..

Yes. I realize that.  Only as noted in comment 60 rpcbind IS running and NFS refuses to start without telling much why.  It is true that rpcbind is not
starting by itself, even if one can reasonably expect it to do that after upgrading, but I did start it explicitely myself.

> what is the output of 'ps ax | grep rpcbind' and 'rpcinfo -p'?

Before it was started then not very much; but after I started it:

# ps ax | grep [r]pcbind
1396 ?        Ss     0:00 /sbin/rpcbind -w

Also 'systemctl status rpcbind.service' says "active (running)" but
'systemctl start nfs.service' fails with "Unit nfs.service failed to load".

> Also, just for package sanity sake are nfs-idmap.service 
> and nfs-lock.servers up and running?

# systemctl status nfs-idmap.service
nfs-idmap.service - NFSv4 ID-name mapping daemon
          Loaded: loaded (/lib/systemd/system/nfs-idmap.service)
          Active: inactive (dead)
          CGroup: name=systemd:/system/nfs-idmap.service
# systemctl status nfs-lock.servers
Failed to issue method call: Unit name nfs-lock.servers is not valid.

You probably meant 'nfs-lock.service', right?

# systemctl status nfs-lock.service
nfs-lock.service - NFS file locking service.
          Loaded: loaded (/lib/systemd/system/nfs-lock.service)
          Active: inactive (dead)
          CGroup: name=systemd:/system/nfs-lock.service

With 'rpcbind.service' already started manually both 'nfs-idmap.service' and 'nfs-lock.service' can be succesfully started.  This is not of any help to 'nfs.service' which fails the same way as before.

On the top of it 'man systemctl' describes '--all, -a' as "When listing units, show all units, regardless of their state, including inactive units" and '--failed' as "When listing units, show only failed units".  Despite of that
anything "nfs" shows in an output of 'systemctl list-units -a' only after an attempt to start it and 'systemctl list-units -a --failed' says "0 units listed" even if 'nfs.service' can be found now with "error  inactive   dead".

OTOH now I can manually start 'nfs-server.service' but how one can "discover" such things without poking around in subdirectories of /lib/systemd/ and guessing what may possibly fit; and also why an upgrade leaves previously
working services as dead?

After all this mucking around and starting services manually now I have:

# systemctl -a list-units | egrep 'rpc|nfs'
proc-fs-nfsd.mount        loaded active     mounted         /proc/fs/nfsd
nfs-idmap.service         loaded active     running         NFSv4 ID-name mapping daemon
nfs-lock.service          loaded active     running         NFS file locking service.
nfs-server.service        loaded active     running         NFS Protocol Daemon
nfs.service               error  inactive   dead            nfs.service
rpcbind.service           loaded active     running         RPC bind service
rpcbind.socket            loaded active     listening       RPCbind Server Activation Socket
Comment 64 Steve Dickson 2011-08-08 13:21:20 EDT
(In reply to comment #63)
> (In reply to comment #62)
> 
> > If rpcbind is not running then nfs.server will not run..
> 
> Yes. I realize that.  Only as noted in comment 60 rpcbind IS running and NFS
> refuses to start without telling much why.  It is true that rpcbind is not
> starting by itself, even if one can reasonably expect it to do that after
> upgrading, but I did start it explicitely myself.
> 
> > what is the output of 'ps ax | grep rpcbind' and 'rpcinfo -p'?
> 
> Before it was started then not very much; but after I started it:
> 
> # ps ax | grep [r]pcbind
> 1396 ?        Ss     0:00 /sbin/rpcbind -w
> 
> Also 'systemctl status rpcbind.service' says "active (running)" but
> 'systemctl start nfs.service' fails with "Unit nfs.service failed to load".
> 
> > Also, just for package sanity sake are nfs-idmap.service 
> > and nfs-lock.servers up and running?
> 
> # systemctl status nfs-idmap.service
> nfs-idmap.service - NFSv4 ID-name mapping daemon
>           Loaded: loaded (/lib/systemd/system/nfs-idmap.service)
>           Active: inactive (dead)
>           CGroup: name=systemd:/system/nfs-idmap.service
> # systemctl status nfs-lock.servers
> Failed to issue method call: Unit name nfs-lock.servers is not valid.
> 
> You probably meant 'nfs-lock.service', right?
> 
> # systemctl status nfs-lock.service
> nfs-lock.service - NFS file locking service.
>           Loaded: loaded (/lib/systemd/system/nfs-lock.service)
>           Active: inactive (dead)
>           CGroup: name=systemd:/system/nfs-lock.service
Yeah... this is what I meant... but this is not good... 
Both these services should be started and running on
every boot...

> 
> With 'rpcbind.service' already started manually both 'nfs-idmap.service' and
> 'nfs-lock.service' can be succesfully started.  This is not of any help to
> 'nfs.service' which fails the same way as before.
What is the error message in /var/log/messages and the output
of systemctl status nfs-server when the failure occurs?


> 
> On the top of it 'man systemctl' describes '--all, -a' as "When listing units,
> show all units, regardless of their state, including inactive units" and
> '--failed' as "When listing units, show only failed units".  Despite of that
> anything "nfs" shows in an output of 'systemctl list-units -a' only after an
> attempt to start it and 'systemctl list-units -a --failed' says "0 units
> listed" even if 'nfs.service' can be found now with "error  inactive   dead".
I'm not sure I understand what you are saying here...

> 
> OTOH now I can manually start 'nfs-server.service' but how one can "discover"
> such things without poking around in subdirectories of /lib/systemd/ and
> guessing what may possibly fit; and also why an upgrade leaves previously
> working services as dead?
Hmm... I have the following %poustun rule:
%postun

if [ "$1" -ge 1 ]; then
    # Package upgrade, not uninstall
    for service in %{nfs_services} ; do
        /bin/systemctl try-restart $service >/dev/null 2>&1 || :
    done
fi
/bin/systemctl --system daemon-reload >/dev/null 2>&1 || :

So those service should be restarted... unless I',m missing
something.. 

> 
> After all this mucking around and starting services manually now I have:
> 
> # systemctl -a list-units | egrep 'rpc|nfs'
> proc-fs-nfsd.mount        loaded active     mounted         /proc/fs/nfsd
> nfs-idmap.service         loaded active     running         NFSv4 ID-name
> mapping daemon
> nfs-lock.service          loaded active     running         NFS file locking
> service.
> nfs-server.service        loaded active     running         NFS Protocol Daemon
> nfs.service               error  inactive   dead            nfs.service
> rpcbind.service           loaded active     running         RPC bind service
> rpcbind.socket            loaded active     listening       RPCbind Server
> Activation Socket
What happens when you reboot? Do all the services come up as expected?
Comment 65 Michal Jaegermann 2011-08-08 22:28:22 EDT
(In reply to comment #64)

> What is the error message in /var/log/messages and the output
> of systemctl status nfs-server when the failure occurs?

There are no traces of anything "rpc" or "nfs" in /var/log/messages.
If you will try to check status the this shows up:

# systemctl status nfs-server.service
nfs-server.service - NFS Protocol Daemon
          Loaded: loaded (/lib/systemd/system/nfs-server.service)
          Active: inactive (dead)
          CGroup: name=systemd:/system/nfs-server.service


> > On the top of it 'man systemctl' describes '--all, -a' as "When listing units,
> > show all units, ....
.....
> I'm not sure I understand what you are saying here...

I am saying that I have no idea how to _guess_ what services I may want to activate without traipsing around in directories with names my wife will surely not guess, while she is a very inteligent person, and I would be in a big trouble if I would have to explain that to her over a phone.  Try to imagine yourself running such "over a phone" experiment; especially if you do not have handy a reference machine to check things.


> Hmm... I have the following %poustun rule:
> %postun
> 
> if [ "$1" -ge 1 ]; then
>     # Package upgrade, not uninstall
>     for service in %{nfs_services} ; do
>         /bin/systemctl try-restart $service >/dev/null 2>&1 || :
>     done
> fi
> /bin/systemctl --system daemon-reload >/dev/null 2>&1 || :
> 
> So those service should be restarted... unless I',m missing
> something.. 

Oh, I guess that I see at least some problems.  If you will do
'rpm -q --scripts nfs-utils' then, among other things, the following shows up in various places:

   for service in /builddir/build/SOURCES/nfs-lock.service \
/builddir/build/SOURCES/nfs-secure.service  .... (and so on)

Those clearly do not exist. It appears that you are expanding some package macros in a wrong moment.

Now a question remains that if you are upgrading from some sane state, and not necessarily from I have installed right now, if an old configuration what is running and what is not will get "carried over"? 'chkconfig --list' already "lost" an information how nfs and nfslock were configured.  OTOH in package scripts for 'rpcbind' I see for upgrade:

  /bin/systemctl try-restart rpcbind.service

but that one on a startup is dead as well.

Yes, I know that I can reconfigure services from scratch but that means a serious breakage on an upgrade if I have to do that.
Comment 66 Steve Dickson 2011-08-09 16:17:06 EDT
(In reply to comment #65)
> (In reply to comment #64)
> 
> > What is the error message in /var/log/messages and the output
> > of systemctl status nfs-server when the failure occurs?
> 
> There are no traces of anything "rpc" or "nfs" in /var/log/messages.
> If you will try to check status the this shows up:
> 
> # systemctl status nfs-server.service
> nfs-server.service - NFS Protocol Daemon
>           Loaded: loaded (/lib/systemd/system/nfs-server.service)
>           Active: inactive (dead)
>           CGroup: name=systemd:/system/nfs-server.service
Well the NFS server should not be enabled by default. So
the above state is expected. when you start the service
(aka systemctl start nfs-server.service) are there errors?


> 
> 
> > > On the top of it 'man systemctl' describes '--all, -a' as "When listing units,
> > > show all units, ....
> .....
> > I'm not sure I understand what you are saying here...
> 
> I am saying that I have no idea how to _guess_ what services I may want to
> activate without traipsing around in directories with names my wife will surely
> not guess, while she is a very inteligent person, and I would be in a big
> trouble if I would have to explain that to her over a phone.  Try to imagine
> yourself running such "over a phone" experiment; especially if you do not have
> handy a reference machine to check things.
Well services like rpcbind.service, nfs-lock.service and nfs-idmap should
start up automatically since they are  enabled by default. Now the
other three service, nfs-server.service, nfs-secure.service and 
nfs-secure-server.service, that will have to be enabled by hand
I'm hopeful will be obvious to system admins... Would some type
of documentation help? Maybe a systemd.nfs man page? 


> 
> 
> > Hmm... I have the following %poustun rule:
> > %postun
> > 
> > if [ "$1" -ge 1 ]; then
> >     # Package upgrade, not uninstall
> >     for service in %{nfs_services} ; do
> >         /bin/systemctl try-restart $service >/dev/null 2>&1 || :
> >     done
> > fi
> > /bin/systemctl --system daemon-reload >/dev/null 2>&1 || :
> > 
> > So those service should be restarted... unless I',m missing
> > something.. 
> 
> Oh, I guess that I see at least some problems.  If you will do
> 'rpm -q --scripts nfs-utils' then, among other things, the following shows up
> in various places:
> 
>    for service in /builddir/build/SOURCES/nfs-lock.service \
> /builddir/build/SOURCES/nfs-secure.service  .... (and so on)
> 
> Those clearly do not exist. It appears that you are expanding some package
> macros in a wrong moment.
Of course they exist, look in /lib/systemd/system/.

But I'm wonder if I the %post and %postun section wrong.

The %post section is 
if [ $1 -eq 1 ]; then
    # Package install, not upgrade
    /bin/systemctl enable nfs-idmap.service >/dev/null 2>&1 || :
    /bin/systemctl enable nfs-lock.service >/dev/null 2>&1 || :
fi

which I believe means on an upgrade those service will
not be enabled. The %postun section is:

if [ "$1" -ge 1 ]; then
    # Package upgrade, not uninstall
    for service in %{nfs_services} ; do
        /bin/systemctl try-restart $service >/dev/null 2>&1 || :
    done
fi

Which assumes the services are already enabled.... 

So I'm wondering just go a head and always enable the services 
in the %post section which would validate the assume in 
the  %postun section

> 
> Now a question remains that if you are upgrading from some sane state, and not
> necessarily from I have installed right now, if an old configuration what is
> running and what is not will get "carried over"? 'chkconfig --list' already
> "lost" an information how nfs and nfslock were configured. 
Yes... this has to be a smooth transition... I do have the 
following  %triggerun 

%triggerun -- nfs < 1.2.4-4
if /sbin/chkconfig --level 3 nfs ; then
    /bin/systemctl --no-reload enable nfsserver.service >/dev/null 2>&1 || :
fi

Which does test for the running of the NFS server, but I'm thinking
I should throw in some nfs-lock and nfs-idmap enables plus
check for the existence the secure nfs daemon as well..
 
> OTOH in package scripts for 'rpcbind' I see for upgrade:
> 
>   /bin/systemctl try-restart rpcbind.service
> 
> but that one on a startup is dead as well.
The rppbind.service not starting is a major problem... Any
clue as to why its not starting? 

> 
> Yes, I know that I can reconfigure services from scratch but that means a
> serious breakage on an upgrade if I have to do that.
I agree...
Comment 67 Michal Jaegermann 2011-08-09 17:29:14 EDT
(In reply to comment #66)
>
> > # systemctl status nfs-server.service
> > nfs-server.service - NFS Protocol Daemon
> >           Loaded: loaded (/lib/systemd/system/nfs-server.service)
> >           Active: inactive (dead)
> >           CGroup: name=systemd:/system/nfs-server.service
> Well the NFS server should not be enabled by default. So
> the above state is expected.

It was enabled before an "update" hit.  Are you telling me that a package update is supposed to break the current configuration of a system?

> when you start the service
> (aka systemctl start nfs-server.service) are there errors?

See comment 63 about that. Quite detailed, I would think.

> Well services like rpcbind.service, nfs-lock.service and nfs-idmap should
> start up automatically since they are  enabled by default.

I do not see any evidence that those are starting automatically.
Quite to the contrary, I would say.

> Now the
> other three service, nfs-server.service, nfs-secure.service and 
> nfs-secure-server.service, that will have to be enabled by hand

At least some of them were enabled already and now you came and you broke it.

> I'm hopeful will be obvious to system admins.

In reality those "system admins" could be somebody who set a working system in the first place a while ago and now he/she can be far away or busy with other things.  You still seem to think in terms of an IT center manned by some "gurus".  A reality is very far from that.  Maybe even a machine owner set up a suitable set of services with a help of previously available GUI tools and a loss of functionality will come as a huge and nasty surprise and surely far from  "obvious".

Besides I was asking how to even start to guess what you are supposed to enable. Outside of GUI there was 'chkconfig --list' but now it does not work.  What is a replacement? 'systemctl --all list-units' clearly does not cut.  What else? Yes, myself I know how to hack my way around with all this but that is not a general answer.

> > in various places:
> > 
> >    for service in /builddir/build/SOURCES/nfs-lock.service \
> > /builddir/build/SOURCES/nfs-secure.service  .... (and so on)
> > 
> > Those clearly do not exist. It appears that you are expanding some package
> > macros in a wrong moment.
> Of course they exist, look in /lib/systemd/system/.

And I will find there /builddir/build/SOURCES/nfs-lock.service ?
You have to be kidding.  At least on my machine there is no /builddir/
directory so there is no chance to find anything there. :-)  I was quoting literally what I am getting with '--scripts' to rpm and an existing package.
Comment 68 Fedora Update System 2011-08-10 18:28:37 EDT
nfs-utils-1.2.4-6.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/nfs-utils-1.2.4-6.fc16
Comment 69 Michal Jaegermann 2011-08-12 16:41:07 EDT
I still see in package scripts from nfs-utils-1.2.4-6.fc17 this:

for service in /builddir/build/SOURCES/nfs-lock.service /builddir/build/SOURCES/nfs-secure.service /builddir/build/SOURCES/nfs-secure-server.service /builddir/build/SOURCES/nfs-server.service /builddir/build/SOURCES/nfs-idmap.service /builddir/build/SOURCES/var-lib-nfs-rpc_pipefs.mount ; do
....
done

If you will try, like one of those scripts:

/bin/systemctl try-restart /builddir/build/SOURCES/nfs-lock.service

then a response, really unsurprisingly, is:

Failed to issue method call: Unit name /builddir/build/SOURCES/nfs-lock.service is not valid.

You just do not observe it as package scripts are sending that to /dev/null

That, and similar, should work 

   /bin/systemctl try-restart $(basename $service) >/dev/null 2>&1 || :

but I doubt that such hack is a proper answer. :-)
Comment 70 Fedora Update System 2011-08-23 16:28:18 EDT
nfs-utils-1.2.4-6.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 71 Michal Jaegermann 2011-08-27 11:53:17 EDT
Contrary to a claim that this is "Fixed In Version nfs-utils-1.2.4-4.fc17" in version nfs-utils-1.2.4-7.fc17 this is still broken.  Both "Package upgrade, not uninstall" and "Package removal, not upgrade" package scripts attempt to operate on /builddir/build/SOURCES/nfs-lock.service and similar for other service entries (cf. comment 65) and this is not going to work.
Comment 72 Michal Jaegermann 2011-08-27 12:42:43 EDT
On the top of problems from comment 71 there is also the following.  In nfs-util package scripts one can find:

if [ $1 -eq 1 ]; then
        # Package install, not upgrade
    /bin/systemctl enable nfs-idmap.service >/dev/null 2>&1 || :
    /bin/systemctl enable nfs-lock.service >/dev/null 2>&1 || :
fi

This was supposed to be on, but it is not, so let's enable these "manually".  with these enabled 'systemctl start nfs-lock.service' quietly returns but
'systemctl status nfs-lock.service' tells me "Active: failed" and

         Process: 15408 ExecStart=/sbin/rpc.statd $STATDARG (code=exited, status=1/FAILURE)
         Process: 15401 ExecStartPre=/usr/lib/nfs-utils/scripts/nfs-lock.preconfig (code=exited, status=0/SUCCESS)

with no process 15401 around despite of this "status=0/SUCCESS".

All of that was just working before these ill-fated upgrades.

If running rpcbind.service is a precondition to a working nfs-lock.service then it seems that it needs to be enabled too.  The only trouble is that any attempts to manipulate rpcbind.service without a reboot seem to end up with:
"Failed to get D-Bus connection: Failed to connect to socket /run/systemd/private: Connection refused" (which is possibly a side-effect of bug 732020).  In other words the whole thing is thorougly broken.
Comment 73 Steve Dickson 2011-08-30 09:05:05 EDT
(In reply to comment #69)
> I still see in package scripts from nfs-utils-1.2.4-6.fc17 this:
> 
> for service in /builddir/build/SOURCES/nfs-lock.service
> /builddir/build/SOURCES/nfs-secure.service
> /builddir/build/SOURCES/nfs-secure-server.service
> /builddir/build/SOURCES/nfs-server.service
> /builddir/build/SOURCES/nfs-idmap.service
> /builddir/build/SOURCES/var-lib-nfs-rpc_pipefs.mount ; do
> ....
> done
> 
> If you will try, like one of those scripts:
> 
> /bin/systemctl try-restart /builddir/build/SOURCES/nfs-lock.service
Why are you trying to install things from "/builddir/build/SOURCES/"?

All that loop does is install the scripts from 
"/builddir/build/SOURCES/" into  $RPM_BUILD_ROOT/lib/systemd/system
during the building of the rpm. Instead of explicitly installing
each script, I put it into a loop. 

If there was a problem here, the service scripts would 
not exist in /lib/systemd/system after the rpm installation
but they clearly do.
Comment 74 Steve Dickson 2011-08-30 09:24:45 EDT
(In reply to comment #73)
> (In reply to comment #69)
> > I still see in package scripts from nfs-utils-1.2.4-6.fc17 this:
> > 
> > for service in /builddir/build/SOURCES/nfs-lock.service
> > /builddir/build/SOURCES/nfs-secure.service
> > /builddir/build/SOURCES/nfs-secure-server.service
> > /builddir/build/SOURCES/nfs-server.service
> > /builddir/build/SOURCES/nfs-idmap.service
> > /builddir/build/SOURCES/var-lib-nfs-rpc_pipefs.mount ; do
> > ....
> > done
> > 
> > If you will try, like one of those scripts:
> > 
> > /bin/systemctl try-restart /builddir/build/SOURCES/nfs-lock.service
> Why are you trying to install things from "/builddir/build/SOURCES/"?
> 
I see what you are talking about... I was looking at the
loop in %install, but you were talking about the loop in
%postun... I see the problem...
Comment 75 Michal Jaegermann 2011-08-30 12:27:20 EDT
(In reply to comment #73)
>
> Why are you trying to install things from "/builddir/build/SOURCES/"?

Sorry, was this a question for me?  This is not me trying to do that but
package scripts; currently in parts used in removal and _updates_.  'systemctl' called there does not react on this very kindly. That particular point is obviously some mess in specs and/or build process.

AFAICT this is not the only issue.
Comment 76 Steve Dickson 2011-08-30 17:02:38 EDT
Fixes to both issue in Comment 69 and Comment 72 should be 
fixed in build:
    http://koji.fedoraproject.org/koji/taskinfo?taskID=3313263
Comment 77 Fedora Update System 2011-08-30 17:23:19 EDT
nfs-utils-1.2.4-8.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/nfs-utils-1.2.4-8.fc16
Comment 78 Fedora Update System 2011-08-31 17:44:50 EDT
Package nfs-utils-1.2.4-8.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing nfs-utils-1.2.4-8.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/nfs-utils-1.2.4-8.fc16
then log in and leave karma (feedback).
Comment 79 Michal Jaegermann 2011-08-31 20:40:14 EDT
AFAICS nfs-utils-1.2.4-9.fc17 at last is loosing those unfortunate "/builddir/build/SOURCES/" prefixes from package scripts.

Still those scripts have:

postinstall scriptlet (using /bin/sh):
/bin/systemctl enable nfs-idmap.service >/dev/null 2>&1 || :
/bin/systemctl enable nfs-lock.service >/dev/null 2>&1 || :

That is fine but not particularly helpful.  As noted before nfs-lock.service will refuse to start unless there is rpcbind.service already enabled and *running*.  I do not see anything which would ensure that. Tests show that systemd is clearly not starting rpcbind.service just because it is required.

In "old" /etc/init.d/nfslock you would find a line:

# Required-Start: $network $syslog $rpcbind

Also '$rpcbind' is in "Required-Start" for /etc/init.d/nfs too.
Comment 80 Steve Dickson 2011-09-01 11:14:24 EDT
(In reply to comment #79)
> AFAICS nfs-utils-1.2.4-9.fc17 at last is loosing those unfortunate
> "/builddir/build/SOURCES/" prefixes from package scripts.
> 
> Still those scripts have:
> 
> postinstall scriptlet (using /bin/sh):
> /bin/systemctl enable nfs-idmap.service >/dev/null 2>&1 || :
> /bin/systemctl enable nfs-lock.service >/dev/null 2>&1 || :
> 
> That is fine but not particularly helpful.  As noted before nfs-lock.service
> will refuse to start unless there is rpcbind.service already enabled and
> *running*.  I do not see anything which would ensure that. Tests show that
> systemd is clearly not starting rpcbind.service just because it is required.
I
n the nfs-lock.service there is a 
   After=network.target rpcbind.service
Which I thought would add a dependency on rpcbind being running 

> 
> In "old" /etc/init.d/nfslock you would find a line:
> 
> # Required-Start: $network $syslog $rpcbind
> 
> Also '$rpcbind' is in "Required-Start" for /etc/init.d/nfs too.
The nfs-server.service also has a 
    After=network.target rpcbind.service proc-fs-nfsd.mount
which again should add a dependency on rpcbind being running.
Comment 81 Michal Jaegermann 2011-09-01 11:58:42 EDT
(In reply to comment #80)

> In the nfs-lock.service there is a 
>    After=network.target rpcbind.service
> Which I thought would add a dependency on rpcbind being running

OK.  Did not seem to work when I stopped and disabled related services and later tried:

systemctl enable nfs-idmap.service
systemctl enable nfs-lock.service
systemctl start nfs-lock.service

That was failing until I explicitely enabled and started rpcbind.service.
After that starting nfs-lock.service was not an issue.  Do you see something different?
Comment 82 Steve Dickson 2011-09-01 13:51:19 EDT
(In reply to comment #81)
> (In reply to comment #80)
> 
> > In the nfs-lock.service there is a 
> >    After=network.target rpcbind.service
> > Which I thought would add a dependency on rpcbind being running
> 
> OK.  Did not seem to work when I stopped and disabled related services and
> later tried:
> 
> systemctl enable nfs-idmap.service
> systemctl enable nfs-lock.service
> systemctl start nfs-lock.service
> 
> That was failing until I explicitely enabled and started rpcbind.service.
> After that starting nfs-lock.service was not an issue.  Do you see something
> different?
Yes, I am not see any failures like that... but... 

When I upgrading from nfs-utils-1.2.4-1.fc15 to nfs-utils-1.2.4-8.fc16
on a full updated f15 box, all the process that should exist do but there
was a problem with the nfs server. None of the nfsd kernel process were 
started. The reason was because of this warning:

     warning: /etc/sysconfig/nfs created as /etc/sysconfig/nfs.rpmnew

In nfs.rpmnew the actual number of nfsd threads are set (RPCNFSDCOUNT=8),
in the old sysconfig/nfs they are not. So when the nfs-server.service 
was started no nfsd no kernel process were created.

When I upgrade from nfs-utils-1.2.4-6.fc16.x86_64 nfs-utils-1.2.4-8.fc16
on a full updated f16 box I saw no errors.
Comment 83 Michal Jaegermann 2011-09-01 14:53:01 EDT
(In reply to comment #82)
> The reason was because of this warning:
> 
>      warning: /etc/sysconfig/nfs created as /etc/sysconfig/nfs.rpmnew

I am looking at all this on a rawhide installation and I have only /etc/sysconfig/nfs with a datestamp from "Aug 30" and which came from nfs-utils-1.2.4-9.fc17.x86_64 package.  Even with enabled but stopped rpcbind.service if I will try ' systemctl start nfs-lock.service' then I see

Job failed. See system logs and 'systemctl status' for details.

and 'systemctl status nfs-lock.service' reports:

nfs-lock.service - NFS file locking service.
          Loaded: loaded (/lib/systemd/system/nfs-lock.service; enabled)
          Active: failed since Thu, 01 Sep 2011 12:31:57 -0600; 30s ago
         Process: 1410 ExecStopPost=/sbin/sysctl -w fs.nfs.nlm_tcpport=0 fs.nfs.nlm_udpport=0 (code=exited, status=0/SUCCESS)
         Process: 1438 ExecStart=/sbin/rpc.statd $STATDARG (code=exited, status=1/FAILURE)
         Process: 1435 ExecStartPre=/usr/lib/nfs-utils/scripts/nfs-lock.preconfig (code=exited, status=0/SUCCESS)
        Main PID: 1262 (code=exited, status=1/FAILURE)
          CGroup: name=systemd:/system/nfs-lock.service

In /var/log/messages I can find:

rpc.statd[1439]: failed to create RPC listeners, exiting

and not much more.

Also after all these updates I had to explicitely enable rpcbind.service
before I could get anything to work.

With all required services enabled after a reboot they will be running. Also starting these in a "proper order" will work.
Comment 84 Tom H 2011-09-04 13:13:49 EDT
(In reply to comment #83)

As a partial confirmation of Michal's problem. I can post more info if requested.

I have a similar issue on F16 (installed from F16alpha5 DVD).

I only had to enable nfs-server.service to enable nfs but I have to restart rpcbind.service before restarting nfs-server.service and nfs-lock.service for nfs to run.
Comment 85 Steve Dickson 2011-09-06 10:11:47 EDT
(In reply to comment #84)
> (In reply to comment #83)
> 
> As a partial confirmation of Michal's problem. I can post more info if
> requested.
> 
> I have a similar issue on F16 (installed from F16alpha5 DVD).
> 
> I only had to enable nfs-server.service to enable nfs but I have to restart
> rpcbind.service before restarting nfs-server.service and nfs-lock.service for
> nfs to run.

Where there any error messages in /var/log/messages talking about
rpcbind failing?
Comment 86 Tom H 2011-09-06 14:27:19 EDT
(In reply to comment #85)

> Where there any error messages in /var/log/messages talking about
> rpcbind failing?

I've had to re-install from F16beta DVD.

I still have the same issue. There are a few AVCs in the dmesg output that I don't remember from before but I might simply not have noticed them.

Attaching relevant dmesg output (starting from the first nfs/rpc log) and tail of "/var/log/messages" after restarting nfs.service, etc.
Comment 87 Tom H 2011-09-06 14:34:15 EDT
Created attachment 521733 [details]
dmesg and tail

Info related to comments 85 and 86
Comment 88 Fedora Update System 2011-09-09 13:12:03 EDT
nfs-utils-1.2.4-8.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 89 Michael Schwendt 2011-09-12 11:09:52 EDT
> postinstall scriptlet (using /bin/sh):
> /bin/systemctl enable nfs-idmap.service >/dev/null 2>&1 || :
> /bin/systemctl enable nfs-lock.service >/dev/null 2>&1 || :

This would re-enable both services on every package update and in turn start them at reboot. I couldn't find a rationale for that in this ticket. What is it?
Comment 90 Michal Jaegermann 2011-09-12 12:31:04 EDT
(In reply to comment #89)
> > postinstall scriptlet (using /bin/sh):
> > /bin/systemctl enable nfs-idmap.service >/dev/null 2>&1 || :
> > /bin/systemctl enable nfs-lock.service >/dev/null 2>&1 || :
> 
> This would re-enable both services on every package update and in turn start
> them at reboot.

AFAICT not really.  Not until rpcbind.service is running.  That is possibly another bug but I am really lost how all of this is _supposed_ to work.

> I couldn't find a rationale for that in this ticket. What is it?

Already configured and running services should not have their status changed by upgrades; and that includes distro upgrades.  It does look to me that the above in this respect is neither here not there but how upgrades are supposed to be handled I have no idea.
Comment 91 Michael Schwendt 2011-09-12 13:23:43 EDT
rpcbind enables itself automatically on first-install (in %post). So, if user keeps rpcbind enabled and running (for anything that may need it), nfs-utils %post script would re-enable the two services on every package update (comment 89). That isn't correct.

Note You need to log in before you can comment on or make changes to this bug.