On 06/05/13 06:29, Jóhann B. Guðmundsson wrote:
On 05/06/2013 09:27 AM, Colin Guthrie wrote:
Hi,
Just trying to work out a few problems on our (Mageia's) NFS packages.
As with a lot of things we often take the units from Fedora (we will
soon have a nicer way to share units I hope - need
On 06/05/13 15:36, Guillaume Rousse wrote:
Le 06/05/2013 11:27, Colin Guthrie a écrit :
Also, It is my understanding (and feel free to correct me here) but
nfs-idmap is often needed on client systems also? I'm sure I had to
configure a client in the past to ensure idmap was running in order
On 06/05/13 05:27, Colin Guthrie wrote:
Hi,
Just trying to work out a few problems on our (Mageia's) NFS packages.
As with a lot of things we often take the units from Fedora (we will
soon have a nicer way to share units I hope - need to get release out
the way before I can help and put
Hello,
Doing a 'systemctl show' it appears my EnvironmentFile
is being ignored
EnvironmentFile=/etc/sysconfig/nfs (ignore=yes)
Why is this happening?
steved.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
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
On 08/01/2011 05:43 PM, Lennart Poettering wrote:
On Fri, 29.07.11 11:16, Steve Dickson (ste...@redhat.com) wrote:
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
Hello,
I noticed that the ypbind.service used multiple
EnvironmentFile lines so thought this would be a
good way to build command lines to daemons on the fly...
So the nfs-server.service looks like:
[Unit]
Description=NFS Protocol Daemon
After=network.target rpcbind.service
On 08/02/2011 08:55 AM, Mirco Tischler wrote:
2011/8/2 Steve Dickson ste...@redhat.com:
On 08/02/2011 04:35 AM, Mirco Tischler wrote:
2011/8/2 Steve Dickson ste...@redhat.com:
On 08/01/2011 09:10 PM, Mirco Tischler wrote:
Hi
2011/8/2 Steve Dickson ste...@redhat.com:
Yes, this looks
On 08/02/2011 03:17 PM, Jóhann B. Guðmundsson wrote:
On 08/02/2011 07:11 PM, Mantas Mikulėnas wrote:
t doesn't make much sense for me to run nfsd, mountd, rquotad and everything
from a single .service unit - after all, they are separate services with
their own protocols... I might want to
This is a re-post of Tom's patch he posted a while back.
I made the following changes.
* Reorganized the changes so the diff is more readable
by using a goto instead of indenting 268 lines.
* Removed the systemd scripts because they just didn't
work and won't going to work. I did spend some
Hello,
On 11/22/2014 09:24 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Nov 21, 2014 at 11:43:47AM -0500, Steve Dickson wrote:
From: Tom Gundersen t...@jklm.no
Making rpcbind sockect activated will greatly simplify
its integration in systemd systems. In essence, other services
may now
dependencies.
Original-patch-by: Lennart Poettering lenn...@poettering.net
Cc: systemd-devel@lists.freedesktop.org
Acked-by: Cristian Rodríguezcrrodrig...@opensuse.org
Signed-off-by: Tom Gundersen t...@jklm.no
Signed-off-by: Steve Dickson ste...@redhat.com
---
Makefile.am | 6 +
configure.ac
This is based on a patch originally posted by Lennart Poettering:
http://permalink.gmane.org/gmane.linux.nfs/33774.
That patch was not merged due to the lack of a shared library and
as systemd was seen to be too Fedora specific.
Systemd now provides a shared library, and it is (or very soon will
On 11/25/2014 05:40 PM, J. Bruce Fields wrote:
On Tue, Nov 25, 2014 at 12:05:32PM -0500, Steve Dickson wrote:
This is based on a patch originally posted by Lennart Poettering:
http://permalink.gmane.org/gmane.linux.nfs/33774.
Have you run this by the reporter
of https
On 11/25/2014 12:05 PM, Steve Dickson wrote:
From: Tom Gundersen t...@jklm.no
Making rpcbind sockect activated will greatly simplify
its integration in systemd systems. In essence, other services
may now assume that rpcbind is always available, even during very
early boot. This means
Hello,
On 01/12/2015 04:43 PM, Colin Guthrie wrote:
But FWIW, your check for whether systemctl is installed via calling
systemctl --help is IMO not very neat.
If you're using bash here anyway, you might as well just do a:
if [ -d /sys/fs/cgroup/systemd ]; then
type check or if you
On 01/14/2015 10:46 AM, Steve Dickson wrote:
v2:
* Corrected the numerous BindTo typos
Here are a few systemd changes that were suggested
by the systemd folks:
* Bind the nfs-idmap service to the nfs server.
* Correctly bind nfs-mountd service to the nfs server.
* Used
to the Requires=nfs-mountd.service in
the nfs-server service
Signed-off-by: Steve Dickson ste...@redhat.com
---
systemd/nfs-mountd.service | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/systemd/nfs-mountd.service b/systemd/nfs-mountd.service
index 7ccc0f7..d908afe 100644
Hello
On 01/12/2015 05:34 AM, Colin Guthrie wrote:
Hi,
Looking into a thoroughly broken nfs-utils package here I noticed a
quirk in systemctl status and in umount behaviour.
In latest nfs-utils there is a helper binary shipped upstream called
/usr/sbin/start-statd (I'll send a separate
Hello,
On 01/13/2015 08:27 AM, Steve Dickson wrote:
Here is what I have now in nfs-idmap.service:
[Unit]
Description=NFSv4 ID-name mapping service
BindTo=nfs-server.service
Wants=nfs-config.service
After=nfs-config.service
[Service]
EnvironmentFile=-/run/sysconfig/nfs-utils
Type
do.
Steve Dickson wrote on 12/01/15 19:58:
Hello,
The nfs-server service starts both the rpc-mountd service
and the rpc-idmapd service when the server is started.
But only brings down the rpc-mountd service when
the NFS server is stopped.
I want nfs-server service to bring both
On 01/12/2015 05:40 PM, Colin Guthrie wrote:
Steve Dickson wrote on 12/01/15 20:31:
Hello
On 01/12/2015 05:37 AM, Colin Guthrie wrote:
Hi,
On a related note to my previous message (subject systemctl status not
showing still running processes in inactive .mount unit cgroups (NFS
On 01/14/2015 04:46 AM, Michal Sekletar wrote:
On Tue, Jan 13, 2015 at 03:37:35PM -0500, Steve Dickson wrote:
Since rpc.idmapd is only used by the nfs server, to do
its id mapping, bind the nfs-idmapd service to the
nfs-server service so rpc.idmapd will be started
and stopped
On 03/03/2015 01:36 PM, Steve Dickson wrote:
Its been reported that having the rpc-statd-notify service
depend on network.target instead network-online.target
decrease boot times as much as 10 seconds on some
installs
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1183293
Signed
On 03/03/2015 12:28 PM, Martin Pitt wrote:
Hello NFS developers,
reposting the two patches inline as requested by Steve.
I'm currently systemd-ifying our nfs-utils Ubuntu package. For testing I put
the NFS server and client (i. e. localhost:/foo/bar mounts) on the same
machine. With
Hello,
On 03/06/2015 06:15 AM, Martin Pitt wrote:
Hello all,
Steve Langasek pointed out in [1] that idmapd is also necessary on the client
side. It isn't for my very simple NFSv4 test, but then again I don't know that
much about the various other modes of operation.
This patch starts
On 03/03/2015 05:51 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Mar 03, 2015 at 04:37:24PM -0500, Steve Dickson wrote:
On 03/03/2015 02:18 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Mar 03, 2015 at 10:06:57PM +0300, Andrei Borzenkov wrote:
Indeed. From the man page:
-m retry-time
Its been reported that having the rpc-statd-notify service
depend on network.target instead network-online.target
decrease boot times as much as 10 seconds on some
installs
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1183293
Signed-off-by: Steve Dickson ste...@redhat.com
Reported-by: Eric
On 03/03/2015 02:18 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Mar 03, 2015 at 10:06:57PM +0300, Andrei Borzenkov wrote:
Indeed. From the man page:
-m retry-time
Specifies the length of time, in minutes, to continue retry‐
ing notifications to unresponsive hosts. If this
On 03/03/2015 03:12 PM, Martin Pitt wrote:
Hello all,
Zbigniew Jędrzejewski-Szmek [2015-03-03 19:08 +0100]:
Are you sure that all of those nfs daemons do not require
sockets.target and other stuff provided by basic.target to be ready?
The corresponding upstart jobs trigger on virtual
Here are a few systemd changes that were suggested
by the systemd folks:
* Bind the nfs-idmap service to the nfs server.
* Correctly bind nfs-mountd service to the nfs server.
* Used approved way to check if systemd is install and running
Steve Dickson (3):
systemd: Bind rpc.idmapd
to the Requires=nfs-mountd.service in the
nfs-server service
Signed-off-by: Steve Dickson ste...@redhat.com
---
systemd/nfs-mountd.service | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/systemd/nfs-mountd.service b/systemd/nfs-mountd.service
index 7ccc0f7..c16af57 100644
--- a/systemd
Use the approved way, define in
http://www.freedesktop.org/software/systemd/man/sd_booted.html
to check if systemd is installed and running
Signed-off-by: Steve Dickson ste...@redhat.com
---
utils/statd/start-statd | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/utils
Hello,
Is there a way for systemd to monitor kernel process?
By monitor I mean the existence.
Here the story... a systemd service calls a command
that creates a number kernel process/threads
then the command exits.
Is there a way for systemd to monitor those kernel process
even though it
On 10/01/2015 09:24 AM, Kay Sievers wrote:
> On Wed, Sep 30, 2015 at 10:49 PM, Steve Dickson <ste...@redhat.com> wrote:
>> Is there a way for systemd to monitor kernel process?
>> By monitor I mean the existence.
>
> No, and there is no plan to do anything l
On 10/01/2015 03:50 PM, Kay Sievers wrote:
> On Thu, Oct 1, 2015 at 9:30 PM, Steve Dickson <ste...@redhat.com> wrote:
>>
>>
>> On 10/01/2015 09:24 AM, Kay Sievers wrote:
>>> On Wed, Sep 30, 2015 at 10:49 PM, Steve Dickson <ste...@redhat.com> wrote:
On 10/03/2015 08:18 AM, Lennart Poettering wrote:
> On Wed, 30.09.15 16:49, Steve Dickson (ste...@redhat.com) wrote:
>
>> Hello,
>>
>> Is there a way for systemd to monitor kernel process?
>
> To add to what Kay said:
>
> No. Kernel threads cannot r
Instead of waiting on every fork, which would
become a bottle neck during a mount storm, simply
set a SIGCHLD signal handler to do the wait on
the child process
Signed-off-by: Steve Dickson <ste...@redhat.com>
---
utils/gssd/gssd.c | 18 ++
utils/gssd/gssd_proc.
On 10/04/2015 04:19 AM, Florian Weimer wrote:
> * Steve Dickson:
>
>> +static void
>> +sig_child(int signal)
>> +{
>> +int err;
>> +pid_t pid;
>> +
>> +/* Parent: just wait on child to exit and return */
>> +do {
>> +
Hello,
Is is possible to set a variable in the [Unit]
section of a service?
For example in rpc-gssd.service there is
ConditionPathExists=/etc/krb5.keytab
but for some installation the krb5.keytab
is in a different place. The rpc.gssd daemon
can be told this by setting a command line
On 01/23/2016 11:33 AM, Armin K. wrote:
> On 23.01.2016 17:28, Armin K. wrote:
>>> On 01/13/2016 10:51 AM, Steve Dickson wrote:
>>>> Hello,
>>>>
>>>> Is is possible to set a variable in the [Unit]
>>>> sec
Thank for the discussion... It was very helpful!
steved.
On 01/13/2016 10:51 AM, Steve Dickson wrote:
> Hello,
>
> Is is possible to set a variable in the [Unit]
> section of a service?
>
> For example in rpc-gssd.service there is
> ConditionPathExists=/etc/krb5.key
Hello all,
When systemd starts the rpc.gssd.service, the service fails with:
* rpc-gssd.service - RPC security service for NFS client and server
Loaded: loaded (/usr/lib/systemd/system/rpc-gssd.service; static; vendor
preset: disabled)
Active: failed (Result: exit-code) since Wed
On 11/04/2016 04:47 PM, Lennart Poettering wrote:
> On Fri, 04.11.16 11:12, c...@endlessnow.com (c...@endlessnow.com) wrote:
>
>>> On Thu, Nov 03, 2016 at 04:01:15PM -0700, c...@endlessnow.com wrote:
>> >> so I'm using CentOS 7, and we're mounting a disk from our
>> iSCSI
>> >> SAN and
On 11/01/2016 09:31 AM, Lennart Poettering wrote:
> On Mon, 31.10.16 13:19, Steve Dickson (ste...@redhat.com) wrote:
>
>> [Unit]
>> Description=RPCbind Server Activation Socket
>> DefaultDependencies=no
>> RequiresMountsFor=/var/run /run
>> Wants=rpc
On 10/31/2016 03:40 PM, Michael Biebl wrote:
> Why is it using /var/run (where /var could be on a separate partition)
> and not /run for the socket files?
Historical reasons?? I guess that's way its always been
and never caused a problem...
steved.
>
> 2016-10-31 18:19 GMT
On 10/31/2016 06:07 PM, Kai Krakow wrote:
> Am Mon, 31 Oct 2016 13:19:24 -0400
> schrieb Steve Dickson <ste...@redhat.com>:
>
>> Upstream has come up with some new rpcbind service socket files
>> and I'm trying to incorporate them into f25.
>>
>> T
On 11/01/2016 11:47 AM, Lennart Poettering wrote:
> On Tue, 01.11.16 11:11, Steve Dickson (ste...@redhat.com) wrote:
>
>>
>>
>> On 10/31/2016 03:40 PM, Michael Biebl wrote:
>>> Why is it using /var/run (where /var could be on a separate partition)
>
On 11/01/2016 12:14 PM, Reindl Harald wrote:
>
>
> Am 01.11.2016 um 17:05 schrieb Steve Dickson:
>> and I still getting the following errors
>>
>> rpcbind.socket: Failed to listen on sockets: No such file or directory
I though this was talking about /run/rpcbind.
Hello,
Upstream has come up with some new rpcbind service socket files
and I'm trying to incorporate them into f25.
The rpcbind.socket is failing to come up
rpcbind.socket: Failed to listen on sockets: No such file or directory
Failed to listen on RPCbind Server Activation Socket.
But the
Hey Neil,
On 07/04/2017 06:20 PM, NeilBrown wrote:
> On Tue, May 30 2017, NeilBrown wrote:
>
>> Systemd does not, and will not, support "bg" correctly.
>> It has other, better, ways to handle "background" mounting.
>
> For those who aren't closely watching systemd development, a
> patch was
Hello,
I want rpcbind to drop core so I can debug
something but systemd keeps getting in the way
systemd: rpcbind.service: Main process exited, code=killed, status=6/ABRT
audit: ANOM_ABEND auid=4294967295 uid=32 gid=32 ses=4294967295
subj=system_u:system_r:rpcbind_t:s0 pid=2787 comm="rpcbind"
On 06/07/2017 08:02 AM, Lennart Poettering wrote:
> On Wed, 07.06.17 06:08, Steve Dickson (ste...@redhat.com) wrote:
>
>>
>>
>> On 06/06/2017 05:49 PM, NeilBrown wrote:
>>> On Tue, Jun 06 2017, Steve Dickson wrote:
>>>
>>>> He
On 06/07/2017 04:13 AM, Lennart Poettering wrote:
> On Tue, 06.06.17 21:57, Michael Biebl (mbi...@gmail.com) wrote:
>
>> 2017-06-06 20:07 GMT+02:00 Steve Dickson <ste...@redhat.com>:
>>> Finally, the whole idea of systemd randomly/silently
>>> stri
On 06/07/2017 04:12 AM, Lennart Poettering wrote:
> On Tue, 06.06.17 14:07, Steve Dickson (ste...@redhat.com) wrote:
>
>> Hello,
>>
>> On 05/29/2017 06:19 PM, NeilBrown wrote:
>>>
>>> Systemd does not, and will not, support "bg" correctly.
On 06/06/2017 05:49 PM, NeilBrown wrote:
> On Tue, Jun 06 2017, Steve Dickson wrote:
>
>> Hello,
>>
>> On 05/29/2017 06:19 PM, NeilBrown wrote:
>>>
>>> Systemd does not, and will not, support "bg" correctly.
>>> It has other, bett
On 06/08/2017 01:16 AM, NeilBrown wrote:
> On Wed, Jun 07 2017, Steve Dickson wrote:
>
>> On 06/07/2017 08:02 AM, Lennart Poettering wrote:
>>> On Wed, 07.06.17 06:08, Steve Dickson (ste...@redhat.com) wrote:
>>>
>>>>
>>>>
>>>>
On 06/07/2017 12:08 PM, J. Bruce Fields wrote:
> On Wed, Jun 07, 2017 at 06:04:12AM -0400, Steve Dickson wrote:
>> # ps ax | grep mount
>> 980 ?Ss 0:00 /sbin/mount.nfs nfssrv:/home/tmp /mnt/tmp -o rw,bg
>
> Right, but I think we also need to see a "
Hello,
On 05/29/2017 06:19 PM, NeilBrown wrote:
>
> Systemd does not, and will not, support "bg" correctly.
> It has other, better, ways to handle "background" mounting.
The only problem with this is bg mounts still work at least
up to 4.11 kernel...
It appears there is a problem with a 4.12
header referring to the "$portmap" facility.
Signed-off-by: Steve Dickson <ste...@redhat.com>
---
systemd/rpcbind.service.in | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/systemd/rpcbind.service.in b/systemd/rpcbind.service.in
index f8cfa9f..2b49c24 1006
On 12/14/2017 01:47 PM, Uoti Urpala wrote:
> On Thu, 2017-12-14 at 13:24 -0500, Steve Dickson wrote:
>>
>> On 12/14/2017 12:48 PM, Uoti Urpala wrote:
>>> On Thu, 2017-12-14 at 12:05 -0500, Steve Dickson wrote:
>>>> +Wants=rpcbind.socket rpcbind.target
>&
On 12/14/2017 12:48 PM, Uoti Urpala wrote:
> On Thu, 2017-12-14 at 12:05 -0500, Steve Dickson wrote:
>> According to systemd.special(7) manpage:
>>
>> rpcbind.target
>> The portmapper/rpcbind pulls in this target and orders itself
>> before it, to i
with an LSB header
referring to the "$portmap" facility.
Signed-off-by: Steve Dickson <ste...@redhat.com>
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1431574
---
systemd/rpcbind.service.in | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/systemd/rpcb
On 12/15/2017 09:52 AM, Lennart Poettering wrote:
> On Fr, 15.12.17 08:00, Steve Dickson (ste...@redhat.com) wrote:
>
>> According to systemd.special(7) manpage:
>>
>> rpcbind.target
>> The portmapper/rpcbind pulls in this target and orders itself
>
On 2/2/19 4:03 PM, Tomasz Torcz wrote:
> On Sat, Feb 02, 2019 at 03:03:22PM -0500, Steve Dickson wrote:
>>
>>
>> On 2/2/19 2:48 PM, Tomasz Torcz wrote:
>>> On Sat, Feb 02, 2019 at 02:42:15PM -0500, Steve Dickson wrote:
>>>> Hello,
>>>>
&
Hello,
In a.service I have
[Unit]
Before=b.service
[Install]
RequiredBy=b.service
when I systemd start b.service (which happens to fail)
but... a.service is not being run.
So I guess my question is what do I have to do
to ensure a.service is *always* run before b.service?
tia,
steved.
On 2/2/19 2:48 PM, Tomasz Torcz wrote:
> On Sat, Feb 02, 2019 at 02:42:15PM -0500, Steve Dickson wrote:
>> Hello,
>>
>> In a.service I have
>>
>> [Unit]
>> Before=b.service
>>
>> [Install]
>> RequiredBy=b.service
&g
On 2/2/19 3:44 PM, Reindl Harald wrote:
>
>
> Am 02.02.19 um 21:05 schrieb Steve Dickson:
>> On 2/2/19 2:52 PM, Reindl Harald wrote:
>>> Am 02.02.19 um 20:42 schrieb Steve Dickson:
>>>> Hello,
>>>>
>>>> In a.service I have
On 2/2/19 2:52 PM, Reindl Harald wrote:
>
>
> Am 02.02.19 um 20:42 schrieb Steve Dickson:
>> Hello,
>>
>> In a.service I have
>>
>> [Unit]
>> Before=b.service
>>
>> [Install]
>> RequiredBy=b.service
>>
>>
On 2/2/19 4:07 PM, Uoti Urpala wrote:
> On Sat, 2019-02-02 at 15:03 -0500, Steve Dickson wrote:
>>> Have you enabled a.service?
>>>
>> No... I did not think I had to... I figured
>> when b.service was started, a.service would be
>> run
Hello,
We are adding some new functionality to the NFS server that
will make it a bit more container friendly...
This new functionality needs to do a chroot(2) system call.
This systemcall is failing with EPERM due to the
following AVC error:
AVC avc: denied { sys_chroot } for pid=2919
On 6/4/19 12:45 PM, Matthew Garrett wrote:
> On Tue, Jun 4, 2019 at 9:42 AM Steve Dickson wrote:
>> AVC avc: denied { sys_chroot } for pid=2919 comm="rpc.mountd"
>> capability=18 scontext=system_u:system_r:nfsd_t:s0
>> tcontext=system_u:system_r:nfsd_t:s0
On 6/4/19 1:14 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Tue, Jun 04, 2019 at 12:42:35PM -0400, Steve Dickson wrote:
>> Hello,
>>
>> We are adding some new functionality to the NFS server that
>> will make it a bit more container friendly...
>>
>> This
Hello,
I'm trying to remove nfsconvert from Fedora but I'm
getting the following systemd error after I removed
the command and the service file.
# systemctl restart nfs-server
Failed to restart nfs-server.service: Unit nfs-convert.service not found
There is nothing in the nfs-utils files that
Thanks for the reply!
On 8/22/22 4:09 AM, Lennart Poettering wrote:
On Fr, 19.08.22 11:21, Steve Dickson (ste...@redhat.com) wrote:
Hello,
I'm trying to remove nfsconvert from Fedora but I'm
getting the following systemd error after I removed
the command and the service file.
# systemctl
On 8/22/22 9:46 AM, Steve Dickson wrote:
Thanks for the reply!
On 8/22/22 4:09 AM, Lennart Poettering wrote:
On Fr, 19.08.22 11:21, Steve Dickson (ste...@redhat.com) wrote:
Hello,
I'm trying to remove nfsconvert from Fedora but I'm
getting the following systemd error after I removed
76 matches
Mail list logo
