[systemd-devel] Add filesystem paths to InaccessiblePaths globally for some paths ?

y be reproduce with something more standard like a stale /nfs. Any way to set  a default for InaccessiblePaths= or equivalent to stop these FSs being bind mounted in ever. Steve.

Re: [systemd-devel] SuccessExitStatus , user slice, SSH ?

On 31/10/2024 12:48, Lennart Poettering wrote: On Do, 31.10.24 10:20, Steve Traylen ([email protected]) wrote: Hi, I was trying to suppress user scope units that are considered failed due to them requiring a SIGKILL. Typical log might be. Oct 30 10:27:55 node989.example.ch systemd[1

[systemd-devel] SuccessExitStatus , user slice, SSH ?

timeout on shutdown of the scope. Steve (*) The fact that the login bash shell does not run inside the user service with SSH is probably the underlying problem here.   Would be more than happy to change that if possible. Alma 9, systemd-252-32.el9.

[systemd-devel] systemd-run --user when lingering is disabled.

e shot also works but then the systemd-run is sync rather than async. Motivation - Trying to move away from `echo "/usr/bin/sleep 1m" | su - eric  - & `. Steve. Tested on fedora rawhide, systemd-256.5.

Re: [systemd-devel] Is a socket with Accept=yes and ListenFIFO impossible?

nd [Service] ExecStart=/usr/bin/ls /etc/passwd /etc/notexisting StandardOutput=file:/run/emailoutput.socket StandardError=file:/run/emailoutput.socket A single email of Output and Error is generated - that's great - thanks. No more questions. Steve. On Thu, Sep 5, 2024, 13:38 Steve Tra

[systemd-devel] Is a socket with Accept=yes and ListenFIFO impossible?

Was trying to set up a trivial socket and service to process multiple inputs: # Socket emailoutput.socket [Unit] Description=Send email via a socket. [Socket] Accept=yes ListenFIFO=/run/emailoutput.socket # Service [email protected] [Unit] Description=email [Service] ExecStart=/usr/bin/mai

[systemd-devel] Forking service behind socket and service.

ubbish for obvious reasons is to use the service with Type=simple, KillMode=None to leave the forked process running. Anyway to persuade the socket service to close earlier. Presumably in the xinetd world xinetd was oblivious to this forked process. Steve.

Re: [systemd-devel] Empty journal files consume space

On 01/02/2024 14:48, Steve Traylen wrote: On 01/02/2024 13:45, Andrei Borzenkov wrote: On Thu, Feb 1, 2024 at 3:25 PM Steve Traylen wrote: Hi, I'm trying to understand why I am only retaining just a couple of days of logs when I would like to have more. The system journalctl head o

Re: [systemd-devel] Empty journal files consume space

On 01/02/2024 13:45, Andrei Borzenkov wrote: On Thu, Feb 1, 2024 at 3:25 PM Steve Traylen wrote: Hi, I'm trying to understand why I am only retaining just a couple of days of logs when I would like to have more. The system journalctl head of the logs is only today: Feb 01 10:

[systemd-devel] Empty journal files consume space

er journals are all 8.0M is size So I think I have two questions: 1) Why am I loosing old logs sooner than I would like - what limit is " fill level at 75.0 (174765 of 233016 items" 2) Is there a safe mechanism to delete those empty offline user journals? Thanks. Steve. Version an

Re: [systemd-devel] nfs-convert.service

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 ([email protected]) wrote: Hello, I'm trying to remove nfsconvert from Fedora but I'm getting the following systemd error after I r

Re: [systemd-devel] nfs-convert.service

Thanks for the reply! On 8/22/22 4:09 AM, Lennart Poettering wrote: On Fr, 19.08.22 11:21, Steve Dickson ([email protected]) 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. #

[systemd-devel] nfs-convert.service

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 h

Re: [systemd-devel] asset failure that looks like it's coming from systemd/

On Fri, 24 Dec 2021 at 10:11, Jonathan Kelly wrote: > No. I'm in the middle here ... trying to compile unicon and it borks ... the > unicon people don't know anything about random-util.c ... it not part of > their software. Only thing I can think of is that something used in the compilation pr

Re: [systemd-devel] How to disable seccomp in systemd-nspawn?

On Sun, 16 Aug 2020 at 16:32, Steve Dodd wrote: Ah, looks like we need to seccomp_attr_get(&ctx, SCMP_FLTATR_CTL_LOG, ..) > somewhere for this to work. Not sure if that should be done > unconditionally... > https://github.com/systemd/systemd/pull/16752 makes it conditional on a

Re: [systemd-devel] How to disable seccomp in systemd-nspawn?

On Sun, 16 Aug 2020 at 16:05, Steve Dodd wrote: That's interesting .. it's possible things don't work quite the way I think > they do, but I will try to find previous examples - I remember borgbackup > was affected on armhf fairly recently, for example. > Ah, the borgba

Re: [systemd-devel] How to disable seccomp in systemd-nspawn?

On Sun, 16 Aug 2020 at 15:47, Lennart Poettering wrote: I think it would be wise to use do fallback logic for EPERM too. It's > the error that nspawn uses since day #1 basically. I am a bit puzzled > noone noticed this before, afaik glibc test cases at least on Fedora > (where most glibc upstream

Re: [systemd-devel] How to disable seccomp in systemd-nspawn?

On Sun, 16 Aug 2020 at 14:54, Lennart Poettering wrote: > > I've just been bitten by this - last time I looked into a similar > problem, > > it seemed the calling code was confused by getting EPERM instead of > ENOSYS. > > Could we distinguish between these two cases and generate the right error

Re: [systemd-devel] How to disable seccomp in systemd-nspawn?

On Fri, 26 Jun 2020 at 16:53, Lennart Poettering wrote: > > We implement a system call allow list, i.e. everything that isn't > > > explicitly allowed is denied. You can use --system-call-filter=openat2 > > > to allow a specific syscall on top of our defaults, i.e. extend the > > > allow list, or

Re: [systemd-devel] MACVLAN= in .nspawn file vs command line results in /sys/class/net showing host interfaces

On Mon, 19 Aug 2019 at 14:38, Steve Dodd wrote: [..] > if I start it with systemctl start systemd-nspawn@name, all works as > expected. > > If I start manually with systemd-nspawn -M name -b, I seem to correctly > get a new network namespace (ip link output in container is cor

[systemd-devel] MACVLAN= in .nspawn file vs command line results in /sys/class/net showing host interfaces

I'm running Ubuntu bionic, with systemd 237, so I haven't filed a bug report, but I'm wondering if it rings any bells with anyone.. I've tried searching github issues, but my keywords either get too few or too many results to be useful. I have machine with the following nspawn file: -- [Network]

[systemd-devel] Fwd: nspawn blocks sync_file_range on arm

[apologies for off-list dupe, I hate gmail...] On Mon, 19 Aug 2019 at 07:56, Zbigniew Jędrzejewski-Szmek wrote: Please test https://github.com/systemd/systemd/pull/13352. > I backported to my distro's stable version and it solves the problem: https://bugs.launchpad.net/ubuntu/+source/systemd/+bu

[systemd-devel] nspawn blocks sync_file_range on arm

ARM has two sync_file_range syscalls, sync_file_range and sync_file_range2. The former is apparently not used, and glibc calls the latter whenever a userspace program calls sync_file_range. I'm guessing systemd-nspawn doesn't know this, because the follow code consistently fails in an nspawn contai

Re: [systemd-devel] systemd and chroot()

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

Re: [systemd-devel] systemd and chroot()

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

[systemd-devel] systemd and chroot()

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 com

Re: [systemd-devel] Question on Before=

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

Re: [systemd-devel] Question on Before=

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, >>>> &

Re: [systemd-devel] Question on Before=

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 regardless of b

Re: [systemd-devel] Question on Before=

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 >> >> when I

Re: [systemd-devel] Question on Before=

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

[systemd-devel] Question on Before=

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. _

Re: [systemd-devel] Many user slices created and user managers spawned on boot

On 1/26/19 10:58 AM, Mantas Mikulėnas wrote: Take a look at /var/lib/systemd/linger. Something, quite possibly X2go , is configuring systemd to start a [email protected] for every user on boot.

Re: [systemd-devel] Many user slices created and user managers spawned on boot

On 1/26/19 10:26 AM, Steve Bergman wrote: I have a Debian 9 server, fully updated (systemd 240-4) which... Oops.  My original post contained a significant error.  The version of systemd involved is "232-25+deb9u8". -Steve Bergman _

[systemd-devel] Many user slices created and user managers spawned on boot

08:22:44 hagar systemd[1]: Starting User Manager for UID 612... Jan 26 08:22:44 hagar systemd[1]: Created slice User Slice of dalparts11. ... Thanks for any feedback, Steve Bergman ___ systemd-devel mailing list [email protected]

Re: [systemd-devel] How to create minimal portable services environments?

On 29 August 2018 at 16:14, Wojtek Swiatek wrote: > Le mer. 29 août 2018 à 17:11, Steve Dodd a écrit : >> Shouldn't be that hard to adapt one of the above for nspawn? > nspawn is not the problem - portable services are. I use a minimal image > with nspawn which is OK but p

Re: [systemd-devel] How to create minimal portable services environments?

On 29 August 2018 at 15:43, Steve Dodd wrote: > I'm kind of surprised a tool for this hasn't crossed my path already, [..] I > also wonder if there might be any > Docker based tools that do this sort of inspection. Bingo: - https://github.com/djosephsen/skinnywhale/blob/ma

[systemd-devel] Fwd: How to create minimal portable services environments?

y ship a supposedly minimal OS image called Ubuntu Core which might be useful. I also wonder if there might be any Docker based tools that do this sort of inspection. Steve ___ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] forking PIDFile question

so old that it hasn't been written > > with systemd in mind so does not support PIDFile? > > PID files predate systemd. Thanks for your comments. Regards, Steve Goodey Colchester, England mailto://[email protected] Registered Linux User #372670 http:/

Re: [systemd-devel] forking PIDFile question

ght in thinking that LCDd is so old that it hasn't been written > > with systemd in mind so does not support PIDFile? > > No; it's almost the opposite. Pidfiles have been in use for several decades > with sysvinit (they were one of the primary methods of service > identi

Re: [systemd-devel] forking PIDFile question

info/systemd-devel Thanks very much Jonathan for your help and in looking through the conf files and pointing out my mistakes. I have altered them as per your instructions and all is now running fine. Thanks to all who replied and my apologies if my little problem has cluttered

[systemd-devel] forking PIDFile question

abled) Active: activating (start) since Tue 2018-02-13 09:49:03 GMT; 1min 8s ago Process: 2485 ExecStart=/usr/sbin/LCDd -c /home/steve/lcd/LCDd.conf (code=exited, status=0/SUCCESS) CGroup: /system.slice/LCDd.service └─2487 /usr/sbin/LCDd -c /home/steve/lcd/LCDd.conf Feb 13 09:

Re: [systemd-devel] [PATCH][V2] rpcbind.service: Not pulling the rpcbind.target

On 12/15/2017 09:52 AM, Lennart Poettering wrote: > On Fr, 15.12.17 08:00, Steve Dickson ([email protected]) wrote: > >> According to systemd.special(7) manpage: >> >> rpcbind.target >> The portmapper/rpcbind pulls in this target and orders itself >

[systemd-devel] [PATCH][V2] rpcbind.service: Not pulling the rpcbind.target

LSB header referring to the "$portmap" facility. Signed-off-by: Steve Dickson 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/rpcbind.service.in

Re: [systemd-devel] [PATCH] rpcbind.service: Not pulling the rpcbind.target

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 >&

Re: [systemd-devel] [PATCH] rpcbind.service: Not pulling the 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

[systemd-devel] [PATCH] rpcbind.service: Not pulling the rpcbind.target

header referring to the "$portmap" facility. Signed-off-by: Steve Dickson --- 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 100644 --- a/systemd/rpcbind.servic

Re: [systemd-devel] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.

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 rece

Re: [systemd-devel] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.

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 "

Re: [systemd-devel] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.

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 ([email protected]) wrote: >>> >>>> >>>> >>>>

Re: [systemd-devel] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.

On 06/07/2017 08:02 AM, Lennart Poettering wrote: > On Wed, 07.06.17 06:08, Steve Dickson ([email protected]) wrote: > >> >> >> On 06/06/2017 05:49 PM, NeilBrown wrote: >>> On Tue, Jun 06 2017, Steve Dickson wrote: >>> >>>> He

Re: [systemd-devel] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.

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

Re: [systemd-devel] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.

On 06/07/2017 04:12 AM, Lennart Poettering wrote: > On Tue, 06.06.17 14:07, Steve Dickson ([email protected]) wrote: > >> Hello, >> >> On 05/29/2017 06:19 PM, NeilBrown wrote: >>> >>> Systemd does not, and will not, support "bg" correctly.

Re: [systemd-devel] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.

On 06/07/2017 04:13 AM, Lennart Poettering wrote: > On Tue, 06.06.17 21:57, Michael Biebl ([email protected]) wrote: > >> 2017-06-06 20:07 GMT+02:00 Steve Dickson : >>> Finally, the whole idea of systemd randomly/silently >>> strip off mount options is crazy... IMH

Re: [systemd-devel] [PATCH] nfs.man: document incompatibility between "bg" option and systemd.

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 ke

[systemd-devel] Dropping core with Systemd.

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"

Re: [systemd-devel] nfs-server.service starts before _netdev iscsi mount completes (required)... how can I fix this?

On 11/04/2016 04:47 PM, Lennart Poettering wrote: > On Fri, 04.11.16 11:12, [email protected] ([email protected]) wrote: > >>> On Thu, Nov 03, 2016 at 04:01:15PM -0700, [email protected] wrote: >> >> so I'm using CentOS 7, and we're mounting a disk from our >> iSCSI >> >> SAN and then

Re: [systemd-devel] rpcbind.socket failing

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.

Re: [systemd-devel] rpcbind.socket failing

On 11/01/2016 11:47 AM, Lennart Poettering wrote: > On Tue, 01.11.16 11:11, Steve Dickson ([email protected]) 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) >

Re: [systemd-devel] rpcbind.socket failing

On 11/01/2016 09:31 AM, Lennart Poettering wrote: > On Mon, 31.10.16 13:19, Steve Dickson ([email protected]) wrote: > >> [Unit] >> Description=RPCbind Server Activation Socket >> DefaultDependencies=no >> RequiresMountsFor=/var/run /run >> Wants=rpc

Re: [systemd-devel] rpcbind.socket failing

On 10/31/2016 06:07 PM, Kai Krakow wrote: > Am Mon, 31 Oct 2016 13:19:24 -0400 > schrieb Steve Dickson : > >> Upstream has come up with some new rpcbind service socket files >> and I'm trying to incorporate them into f25. >> >> The rpcbind.socket is f

Re: [systemd-devel] rpcbind.socket failing

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:1

[systemd-devel] rpcbind.socket failing

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

[systemd-devel] rpc-gssd.service failure

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 2016-03-1

Re: [systemd-devel] Variables in the [Unit] section of a server

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] >>>> section of a

Re: [systemd-devel] Variables in the [Unit] section of a server

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

[systemd-devel] Variables in the [Unit] section of a server

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 argument

Re: [systemd-devel] udevd detect and list ata devices

screen out "sd" vs "sr". Don't shout me, just trying to understand. Steve ___ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] network interface renaming

On 11/24/2015 11:43 AM, Steve Abner wrote: On 11/23/2015 10:10 AM, Steven Abner wrote: systemd-networkd[260]: wlan0 : found matching network '/etc/systemd/network/11-dhcp-wlan0.network', based on potentially unpredictable ifname I assume its harmless message, b

Re: [systemd-devel] network interface renaming

On 11/23/2015 10:10 AM, Steven Abner wrote: systemd-networkd[260]: wlan0 : found matching network '/etc/systemd/network/11-dhcp-wlan0.network', based on potentially unpredictable ifname I assume its harmless message, but someone went to trouble of issuing warning in code,

Re: [systemd-devel] systemd-networkd transaction destructive

et systemd to do the first two to shut down before the socket? Or can I drop networkd and just call .socket? Haven't tried to see if dchp client will handle, new to this. Steve ___ systemd-devel mailing list [email protected] h

[systemd-devel] systemd-networkd transaction destructive

read "shutdown)." instead of "shutdow)." :) LFS system, systemd-227, kdbus, amd64. Steve ___ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl suspend

On 11/12/2015 07:56 AM, Lennart Poettering wrote: On Wed, 11.11.15 16:13, Steve Abner ([email protected]) wrote: >I have an issue of the console not turning back on. I have a new build, >linux 4.2, amd64, systemd, kdbus >on a mac mini. The first try was hybrib-sleep, failed so trie

Re: [systemd-devel] systemctl suspend

On 11/12/2015 01:04 AM, Mantas Mikulėnas wrote: On Wed, Nov 11, 2015 at 11:13 PM, Steve Abner <mailto:[email protected]>> wrote: I have an issue of the console not turning back on. I have a new build, linux 4.2, amd64, systemd, kdbus on a mac mini. The first try was hyb

[systemd-devel] systemctl suspend

I have an issue of the console not turning back on. I have a new build, linux 4.2, amd64, systemd, kdbus on a mac mini. The first try was hybrib-sleep, failed so tried suspend. From journalctl there seems to be no related errors, one: systemd-networkd[289]: wlan0: DHCPv4 address 192.168.1.82/24

Re: [systemd-devel] [PATCH] gssd: Improve scalability by not waiting for child processes

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 { >&

Re: [systemd-devel] systemd and kernel process

On 10/03/2015 08:18 AM, Lennart Poettering wrote: > On Wed, 30.09.15 16:49, Steve Dickson ([email protected]) wrote: > >> Hello, >> >> Is there a way for systemd to monitor kernel process? > > To add to what Kay said: > > No. Kernel threads cannot r

Re: [systemd-devel] systemd and kernel process

On 10/01/2015 03:50 PM, Kay Sievers wrote: > On Thu, Oct 1, 2015 at 9:30 PM, Steve Dickson wrote: >> >> >> On 10/01/2015 09:24 AM, Kay Sievers wrote: >>> On Wed, Sep 30, 2015 at 10:49 PM, Steve Dickson wrote: >>>> Is there a way for systemd to monitor

Re: [systemd-devel] systemd and kernel process

On 10/01/2015 09:24 AM, Kay Sievers wrote: > On Wed, Sep 30, 2015 at 10:49 PM, Steve Dickson 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 like that. > > Kernel task

[systemd-devel] systemd and kernel process

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 was

[systemd-devel] [PATCH] gssd: Improve scalability by not waiting for child processes

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 --- utils/gssd/gssd.c | 18 ++ utils/gssd/gssd_proc.c | 11 ++- 2 files

Re: [systemd-devel] [PATCH] systemd: Have rpc-statd-notify.service Require network.target

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_

Re: [systemd-devel] [PATCH 0/2] some systemd unit changes

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

Re: [systemd-devel] [PATCH] systemd: Have rpc-statd-notify.service Require network.target

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:

Re: [systemd-devel] [PATCH 0/1] details for starting nfs-idmapd also on clients

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 o

Re: [systemd-devel] [PATCH 2/2] systemd: Relax dependencies of services

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 vi

Re: [systemd-devel] [PATCH] systemd: Have rpc-statd-notify.service Require network.target

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 o

[systemd-devel] [PATCH] systemd: Have rpc-statd-notify.service Require network.target

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 Reported-by: Eric Work

Re: [systemd-devel] [PATCH 0/3] Miscellaneous systemd changes (v2)

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 s

Re: [systemd-devel] systemctl status not showing still running processes in inactive .mount unit cgroups (NFS specifically)

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

[systemd-devel] [PATCH 1/3] systemd: Bind rpc.idmapd to the nfs-server service

Since rpc.idmapd is only used by the nfs server, to do its id mapping, bind the rpc-idmapd service to the nfs-server service so rpc.idmapd will started and stopped with the server. Signed-off-by: Steve Dickson --- systemd/nfs-idmapd.service | 2 +- 1 file changed, 1 insertion(+), 1 deletion

[systemd-devel] [PATCH 3/3] start-statd: Use the canonical to check if systemd is running.

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 --- utils/statd/start-statd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/utils/statd/start-statd b

[systemd-devel] [PATCH 2/3] systemd: Bind the nfs-mountd service to the nfs-server service

the Requires=nfs-mountd.service in the nfs-server service Signed-off-by: Steve Dickson --- 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 --- a/systemd/nfs

[systemd-devel] [PATCH 0/3] Miscellaneous systemd changes (v2)

Steve Dickson (3): systemd: Bind rpc.idmapd to the nfs-server service systemd: Bind the nfs-mountd service to the nfs-server service start-statd: Use the canonical to check if systemd is running. systemd/nfs-idmapd.service | 2 +- systemd/nfs-mountd.service | 3 +-- utils/statd/start-statd

Re: [systemd-devel] [PATCH 1/3] systemd: Bind rpc.idmapd to the nfs-server service

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 st

[systemd-devel] [PATCH 2/3] systemd: Bind the nfs-mountd service to the nfs-server service

Requires=nfs-mountd.service in the nfs-server service Signed-off-by: Steve Dickson --- 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/nfs-mountd.service

[systemd-devel] [PATCH 1/3] systemd: Bind rpc.idmapd to the nfs-server service

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 with the nfs server. Signed-off-by: Steve Dickson --- systemd/nfs-idmapd.service | 2 +- 1 file changed, 1 insertion(+), 1

[systemd-devel] [PATCH 3/3] start-statd: Use the canonical to check if systemd is running.

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 --- utils/statd/start-statd | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/utils/statd/start-statd b

[systemd-devel] [PATCH 0/3] Miscellaneous systemd changes

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

Re: [systemd-devel] PartOf= Question

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] >

  1   2   >