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:
Created attachment 494289 [details] /etc/sysconfig/nfs Minor changes needed for nfslock
Created attachment 494290 [details] Native systemd service file for rpcgssd
Created attachment 494291 [details] Native systemd service file for rpcidmapd
Created attachment 494292 [details] Native systemd service file for rpcsvcgssd
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.
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
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
(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.
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 ).
+ 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?
(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.
(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
(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?
(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
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.
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?
(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.
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"
(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...
Created attachment 510715 [details] nfs-secure.service Sample service that starts both rpc gssd and rpc svcgssd.
(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
(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!
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...
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..
(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?
/etc/sysconfig is the fedora/rhel thing I think debian puts it into another place and suse the third if I'm not mistaken..
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?
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
(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?
> 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?
(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...
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...
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...
> > 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?
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...
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?
(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?
(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....
> > 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 ?
(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
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.
(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.
(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!
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
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"
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
(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...
Created attachment 512273 [details] nfslock.service 3000 now even leaner and meaner..
Now that we have a working nfslock.service what's next ?
(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
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
(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...
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...
You arent going to build this for F16?
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
*** Bug 722795 has been marked as a duplicate of this bug. ***
*** Bug 725259 has been marked as a duplicate of this bug. ***
Flagged done on https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd
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).
(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.
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".
(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.
(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
(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?
(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.
(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...
(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.
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
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. :-)
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.
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.
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.
(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.
(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...
(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.
Fixes to both issue in Comment 69 and Comment 72 should be fixed in build: http://koji.fedoraproject.org/koji/taskinfo?taskID=3313263
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
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).
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.
(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.
(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?
(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.
(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.
(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.
(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?
(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.
Created attachment 521733 [details] dmesg and tail Info related to comments 85 and 86
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.
> 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?
(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.
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.