Re: [systemd-devel] Fedpra 32 NIS with systemd-logind.service: start operation timed out. Terminating. Got lookup error: io.systemd.TimedOut

2020-05-20 Thread Lennart Poettering 
On Mi, 20.05.20 11:07, Robert Kudyba (rkud...@fordham.edu) wrote:

> >
> >
> > On Di, 19.05.20 23:36, Robert Kudyba (rkud...@fordham.edu) wrote:
> >
> > > Just upgraded for Fedora 32, still running NUS/ypserv, now getting
> > > very slow logins and systemd-logind is not starting. I enabled debug
> > > logs and am seeing the below logs. I don't think
> > >
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_systemd_systemd_issues_7074=DwIBAg=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY=g-sQXgHR3VJuVTBfUvADrmjl8NIsPaBKboi8ZUH0gOA=X94m6OxWpvg9NhGqgPLaACIrMX1q1gleuH8E5qtUR3U=
> > is back with the
> > > nss-nis bug but I made sure that IPAddress= is set (to nothing).
> >
> > Make sure to turn the sandboxing off for systemd-userdb.service too if
> > you want to use NIS.
> >
>
> OK this wasn't obvious to me but I believe I found it. How does one know
> how to turn off sandboxing for this service? Is there a document that
> mentions IPAddress = achieves this?

You shouldn't have to do that manually. Packages that require to
do networking from inside NSS modules (which is pretty much NIS,
because it's so old) should ship a drop-in for systemd-userdbd.service
and systemd-logind.service to punch a hole into the sandboxing.

Quite frankly: NSS modules should not do networking directly in
2020. Let them talk to a local service that does it, but doing it
inside of any frickin process that calls getpwnam() is just very very
wrong, and a security hole.

In the interest of building a secure OS system generally locks most
its services into a tight sandbox, and that means we turn off
networking for most of them since they generally don#t need
that. Except they do if nss-nis is used which wants that. But if you
do something dangerous like that it's really on you that the sandbox
must be turned off.

> https://bugzilla.redhat.com/show_bug.cgi?id=1837808

File it against the NIS packages, they should carry the drop-in for
these two services that turn of the sandbox. That way the majority
people can enjoy a tightly locked sandbox for these services, and only
those who actually run NIS opt into non-sandboxed operation.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Fedpra 32 NIS with systemd-logind.service: start operation timed out. Terminating. Got lookup error: io.systemd.TimedOut

2020-05-20 Thread Robert Kudyba 
One more question, any reason for these error messages in the logs after
restarting systemd-logind?

May 20 11:12:50 secondary systemd-logind[382684]: New seat seat0.
May 20 11:12:50 secondary systemd-logind[382684]: User or group name "0"
starts with a digit, accepting for compatibility.
May 20 11:12:50 secondary systemd-logind[382684]: Failed to add user by
file name 0, ignoring: Invalid argument
May 20 11:12:50 secondary systemd-logind[382684]: User enumeration failed:
Invalid argument

May 20 11:13:41 primary systemd[1]: Starting Login Service...
May 20 11:13:41 primary systemd-logind[110604]: New seat seat0.
May 20 11:13:41 primary systemd-logind[110604]: User or group name "199"
starts with a digit, accepting for compatibility.
May 20 11:13:41 primary systemd-logind[110604]: Failed to add user by file
name 199, ignoring: Invalid argument
May 20 11:13:41 primary systemd-logind[110604]: User or group name "6105"
starts with a digit, accepting for compatibility.
May 20 11:13:41 primary systemd-logind[110604]: Failed to add user by file
name 6105, ignoring


On Wed, May 20, 2020 at 11:07 AM Robert Kudyba  wrote:

>
>> On Di, 19.05.20 23:36, Robert Kudyba (rkud...@fordham.edu) wrote:
>>
>> > Just upgraded for Fedora 32, still running NUS/ypserv, now getting
>> > very slow logins and systemd-logind is not starting. I enabled debug
>> > logs and am seeing the below logs. I don't think
>> >
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_systemd_systemd_issues_7074=DwIBAg=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY=g-sQXgHR3VJuVTBfUvADrmjl8NIsPaBKboi8ZUH0gOA=X94m6OxWpvg9NhGqgPLaACIrMX1q1gleuH8E5qtUR3U=
>> is back with the
>> > nss-nis bug but I made sure that IPAddress= is set (to nothing).
>>
>> Make sure to turn the sandboxing off for systemd-userdb.service too if
>> you want to use NIS.
>>
>
> OK this wasn't obvious to me but I believe I found it. How does one know
> how to turn off sandboxing for this service? Is there a document that
> mentions IPAddress = achieves this?
>
> In /usr/lib/systemd/system/systemd-userdbd.service I set IPAddress= (again
> blank it did have "Any" set). I restarted that service (after
> running systemctl daemon-reload). That also took about a minute. Then
> restarting systemd-logind.service worked and logins are now quick. I
> created a Bugzilla for this
> https://bugzilla.redhat.com/show_bug.cgi?id=1837808
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Fedpra 32 NIS with systemd-logind.service: start operation timed out. Terminating. Got lookup error: io.systemd.TimedOut

2020-05-20 Thread Robert Kudyba 
>
>
> On Di, 19.05.20 23:36, Robert Kudyba (rkud...@fordham.edu) wrote:
>
> > Just upgraded for Fedora 32, still running NUS/ypserv, now getting
> > very slow logins and systemd-logind is not starting. I enabled debug
> > logs and am seeing the below logs. I don't think
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_systemd_systemd_issues_7074=DwIBAg=aqMfXOEvEJQh2iQMCb7Wy8l0sPnURkcqADc2guUW8IM=X0jL9y0sL4r4iU_qVtR3lLNo4tOL1ry_m7-psV3GejY=g-sQXgHR3VJuVTBfUvADrmjl8NIsPaBKboi8ZUH0gOA=X94m6OxWpvg9NhGqgPLaACIrMX1q1gleuH8E5qtUR3U=
> is back with the
> > nss-nis bug but I made sure that IPAddress= is set (to nothing).
>
> Make sure to turn the sandboxing off for systemd-userdb.service too if
> you want to use NIS.
>

OK this wasn't obvious to me but I believe I found it. How does one know
how to turn off sandboxing for this service? Is there a document that
mentions IPAddress = achieves this?

In /usr/lib/systemd/system/systemd-userdbd.service I set IPAddress= (again
blank it did have "Any" set). I restarted that service (after
running systemctl daemon-reload). That also took about a minute. Then
restarting systemd-logind.service worked and logins are now quick. I
created a Bugzilla for this
https://bugzilla.redhat.com/show_bug.cgi?id=1837808
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Fedpra 32 NIS with systemd-logind.service: start operation timed out. Terminating. Got lookup error: io.systemd.TimedOut

2020-05-20 Thread Lennart Poettering 
On Di, 19.05.20 23:36, Robert Kudyba (rkud...@fordham.edu) wrote:

> Just upgraded for Fedora 32, still running NUS/ypserv, now getting
> very slow logins and systemd-logind is not starting. I enabled debug
> logs and am seeing the below logs. I don't think
> https://github.com/systemd/systemd/issues/7074 is back with the
> nss-nis bug but I made sure that IPAddress= is set (to nothing).

Make sure to turn the sandboxing off for systemd-userdb.service too if
you want to use NIS.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd update "forgets" ordering for shutdown

2020-05-20 Thread Frank Steiner 

I missed this mail, sorry!

Andrei Borzenkov wrote:


16.05.2020 19:28, Frank Steiner пишет:

Hi Andrei,

Andrei Borzenkov wrote:
  

Can you reproduce it by simply running "systemctl daemon-reexec" without
any package update?


Yes, indeed! This is enough to destroy the ordering for the next
shutdown.



Do

systemctl show your-unit.service

before and after daemon-reexec. Is there any difference?


Only in the order dependencies are listed:

< Requires=sysinit.target system.slice
< After=sysinit.target system.slice basic.target systemd-journald.socket 
multi-user.target
---

Requires=system.slice sysinit.target
After=systemd-journald.socket sysinit.target basic.target multi-user.target 
system.slice


I guess this is not relevant...

--
Dipl.-Inform. Frank Steiner   Web:  http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. BioinformatikMail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr. 17   Phone: +49 89 2180-4049
80333 Muenchen, Germany   Fax:   +49 89 2180-99-4049
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [systemd-level]: how to config and enable systemd help to create coredump file when the process crashes ？

2020-05-20 Thread Zbigniew Jędrzejewski-Szmek 
On Wed, May 20, 2020 at 04:22:35PM +0800, www wrote:
> Dear all,
> 
> 
> how to config  and enable systemd help to create coredump file when the 
> process crashes ？

See http://www.freedesktop.org/software/systemd/man/coredumpctl.html.

Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to use systemd-repart partitions?

2020-05-20 Thread Lennart Poettering 
On Mi, 20.05.20 14:29, Arian Van Putten (ar...@wire.com) wrote:

> > gpt-auto is not enough. I will want to set up pretty complex things
> like dm/crypto/etc.
>
> Note that gpt-auto-generator will detect if the partition is a LUKS
> partition or has dm-verity, and will set up a `/dev/mapper/root` device
> automatically.
> But I don't think more complex devicemapper setups are supported like
> dm-raid are supported.

Correct.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to use systemd-repart partitions?

2020-05-20 Thread Lennart Poettering 
On Mi, 20.05.20 13:58, Tobias Hunger (tobias.hun...@gmail.com) wrote:

> > To deliver the others, I want to add Encrypt= and Format= as
> > mentioned. To cover the 2nd usecase I then also want to provide
> > CopyBlocks= and CopyFiles=.
>
> I assume CopyBlocks= will just dd and so does not need a formatted
> partition?

Correct.

> CopyFiles= obviously does.

Yes.

> > The former would stream data into a
> > partition that is created on the block level. Primary usecase would be
> > to copy a partition 1:1 from the installer medium onto the host
> > medium. The latter would copy in a file tree on the fs level.
>
> What about things like create subvolumes on BTRFS? systemd-tmpfiles
> does support that.

If this is desirable we could probably add MakeSubvolume= or so which
is applied before CopyFiles= is run, or so.

> > Well, my thinking was to mostly rely on the "gpt-auto" logic,
> > i.e. that simply because they carry correct gpt type uuids systemd
> > would discover and find them.
>
> gpt-auto is not enough. I will want to set up pretty complex things
> like dm/crypto/etc.

gpt-auto can cover LUKS/dm-crypt as well as dm-verity just fine. What
else do you need?

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to use systemd-repart partitions?

2020-05-20 Thread Arian Van Putten 
> gpt-auto is not enough. I will want to set up pretty complex things
like dm/crypto/etc.

Note that gpt-auto-generator will detect if the partition is a LUKS
partition or has dm-verity, and will set up a `/dev/mapper/root` device
automatically.
But I don't think more complex devicemapper setups are supported like
dm-raid are supported.

On Wed, May 20, 2020 at 1:58 PM Tobias Hunger 
wrote:

> Hi Lennart,
>
> On Wed, May 20, 2020 at 12:01 PM Lennart Poettering
>  wrote:
> > On Mi, 20.05.20 00:12, Tobias Hunger (tobias.hun...@gmail.com) wrote:
> > > The one thing that is frustrating is to get a machine image generated
> > > by my build server onto a new piece of hardware. So I wanted to see
> > > how far I can get with systemd-repart and co. to get this initial
> > > deployment to new hardware more automated after booting with the
> > > machine image from an USB stick.
> >
> > So I eventually want to cover three usecases with systemd-repart:
> >
> > 1. building OS images
> > 2. installing an OS from an installer medium onto a host medium
> > 3. adapting an OS images to the medium it has been dd'ed to on first
> >boot
> >
> > I think the 3rd usecase we already cover quite OK.
>
> Yeap.
>
> > To deliver the others, I want to add Encrypt= and Format= as
> > mentioned. To cover the 2nd usecase I then also want to provide
> > CopyBlocks= and CopyFiles=.
>
> I assume CopyBlocks= will just dd and so does not need a formatted
> partition?
>
> CopyFiles= obviously does.
>
> > The former would stream data into a
> > partition that is created on the block level. Primary usecase would be
> > to copy a partition 1:1 from the installer medium onto the host
> > medium. The latter would copy in a file tree on the fs level.
>
> What about things like create subvolumes on BTRFS? systemd-tmpfiles
> does support that.
>
> > Image builder tools such as "mkosi" could make use of this to be
> > simplified a bit: an invocation of "systemd-repart" will set up the
> > basic partition layout and file systems. "systemd-dissect --mount"
> > would then mount this, before dnf/apt/… are run. "bootctl --image=…"
> > would then install the boot loader (that switch doesn't exist yet, but
> > is on the todo list, too).
>
> Yes, I am considering to move my image generation over to
> systemd-repart as well.
>
> > This sounds for the perfect usecase for systemd-repart.
> >
> > > With your extended systemd-repart: How can I reference these newly
> > > created filesystems in /etc/fstab?
> >
> > Well, my thinking was to mostly rely on the "gpt-auto" logic,
> > i.e. that simply because they carry correct gpt type uuids systemd
> > would discover and find them.
>
> gpt-auto is not enough. I will want to set up pretty complex things
> like dm/crypto/etc.
>
> > > So how can I reliably reference filesystems newly created by
> > > systemd-repart in /etc/fstab?
> >
> > So, if the gpt auto logic doesn't suffice, then probably labels. Or
> > you come up with your own UUIDs for the partitions.
>
> I opened a PR for custom partition UUIDs.
>
> > So I'd not discount labels. I think we should start supporting
> > specifier expansion in the label strings, so that we can generate them
> > somewhat automatically, derived from environment parameters.
>
> I will probably prefer UUIDs to uniquely identify something over labels:-)
>
> > > PS: Is systemd-tmpfiles run after mounts with --prefix=/mnt/point? Or
> > > how do you see people populating the newly created filesystems?
> >
> > As indicated above with CopyBlocks= and CopyFiles= if this shall be
> > done during image creation. Copying in blocks and files is probably a
> > 20 line patch or so only (we have helpers for it in place anyway, we
> > just need to call them), and has again this nice benefit that we can
> > schedule it so that the partitions pop up fully populated and there's
> > no time where they are half initialized. This means you can abort an
> > installer any time and the disk will appear as it was before, only
> > when it comes to the very latest step the partitions suddenly pop into
> > existance, fully populated with whatever they shall contain.
>
> Nice, but what about btrfs subvolumes? I will probably end up needing
> those:-)
>
> Best Regards,
> Tobias
>
> > That said, I also want to add an --image= switch to "systemd-tmpfiles"
> > and "systemd-sysusers" so that you can run them easily offline too if
> > you want, just by pointing them to some disk image.
>
> Good idea!
>
> Best Regards,
> Tobias
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>


-- 



*Zeta Project Germany GmbH  *l  Rosenthaler Straße 40,
10178
Berlin,

Germany

Re: [systemd-devel] How to use systemd-repart partitions?

2020-05-20 Thread Tobias Hunger 
Hi Lennart,

On Wed, May 20, 2020 at 12:01 PM Lennart Poettering
 wrote:
> On Mi, 20.05.20 00:12, Tobias Hunger (tobias.hun...@gmail.com) wrote:
> > The one thing that is frustrating is to get a machine image generated
> > by my build server onto a new piece of hardware. So I wanted to see
> > how far I can get with systemd-repart and co. to get this initial
> > deployment to new hardware more automated after booting with the
> > machine image from an USB stick.
>
> So I eventually want to cover three usecases with systemd-repart:
>
> 1. building OS images
> 2. installing an OS from an installer medium onto a host medium
> 3. adapting an OS images to the medium it has been dd'ed to on first
>boot
>
> I think the 3rd usecase we already cover quite OK.

Yeap.

> To deliver the others, I want to add Encrypt= and Format= as
> mentioned. To cover the 2nd usecase I then also want to provide
> CopyBlocks= and CopyFiles=.

I assume CopyBlocks= will just dd and so does not need a formatted partition?

CopyFiles= obviously does.

> The former would stream data into a
> partition that is created on the block level. Primary usecase would be
> to copy a partition 1:1 from the installer medium onto the host
> medium. The latter would copy in a file tree on the fs level.

What about things like create subvolumes on BTRFS? systemd-tmpfiles
does support that.

> Image builder tools such as "mkosi" could make use of this to be
> simplified a bit: an invocation of "systemd-repart" will set up the
> basic partition layout and file systems. "systemd-dissect --mount"
> would then mount this, before dnf/apt/… are run. "bootctl --image=…"
> would then install the boot loader (that switch doesn't exist yet, but
> is on the todo list, too).

Yes, I am considering to move my image generation over to
systemd-repart as well.

> This sounds for the perfect usecase for systemd-repart.
>
> > With your extended systemd-repart: How can I reference these newly
> > created filesystems in /etc/fstab?
>
> Well, my thinking was to mostly rely on the "gpt-auto" logic,
> i.e. that simply because they carry correct gpt type uuids systemd
> would discover and find them.

gpt-auto is not enough. I will want to set up pretty complex things
like dm/crypto/etc.

> > So how can I reliably reference filesystems newly created by
> > systemd-repart in /etc/fstab?
>
> So, if the gpt auto logic doesn't suffice, then probably labels. Or
> you come up with your own UUIDs for the partitions.

I opened a PR for custom partition UUIDs.

> So I'd not discount labels. I think we should start supporting
> specifier expansion in the label strings, so that we can generate them
> somewhat automatically, derived from environment parameters.

I will probably prefer UUIDs to uniquely identify something over labels:-)

> > PS: Is systemd-tmpfiles run after mounts with --prefix=/mnt/point? Or
> > how do you see people populating the newly created filesystems?
>
> As indicated above with CopyBlocks= and CopyFiles= if this shall be
> done during image creation. Copying in blocks and files is probably a
> 20 line patch or so only (we have helpers for it in place anyway, we
> just need to call them), and has again this nice benefit that we can
> schedule it so that the partitions pop up fully populated and there's
> no time where they are half initialized. This means you can abort an
> installer any time and the disk will appear as it was before, only
> when it comes to the very latest step the partitions suddenly pop into
> existance, fully populated with whatever they shall contain.

Nice, but what about btrfs subvolumes? I will probably end up needing those:-)

Best Regards,
Tobias

> That said, I also want to add an --image= switch to "systemd-tmpfiles"
> and "systemd-sysusers" so that you can run them easily offline too if
> you want, just by pointing them to some disk image.

Good idea!

Best Regards,
Tobias
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to use systemd-repart partitions?

2020-05-20 Thread Lennart Poettering 
On Mi, 20.05.20 00:12, Tobias Hunger (tobias.hun...@gmail.com) wrote:

>
> The one thing that is frustrating is to get a machine image generated
> by my build server onto a new piece of hardware. So I wanted to see
> how far I can get with systemd-repart and co. to get this initial
> deployment to new hardware more automated after booting with the
> machine image from an USB stick.

So I eventually want to cover three usecases with systemd-repart:

1. building OS images
2. installing an OS from an installer medium onto a host medium
3. adapting an OS images to the medium it has been dd'ed to on first
   boot

I think the 3rd usecase we already cover quite OK.

To deliver the others, I want to add Encrypt= and Format= as
mentioned. To cover the 2nd usecase I then also want to provide
CopyBlocks= and CopyFiles=. The former would stream data into a
partition that is created on the block level. Primary usecase would be
to copy a partition 1:1 from the installer medium onto the host
medium. The latter would copy in a file tree on the fs level.

Image builder tools such as "mkosi" could make use of this to be
simplified a bit: an invocation of "systemd-repart" will set up the
basic partition layout and file systems. "systemd-dissect --mount"
would then mount this, before dnf/apt/… are run. "bootctl --image=…"
would then install the boot loader (that switch doesn't exist yet, but
is on the todo list, too).

Installer tools would just need one invocation of "systemd-repart" to
make the basic partitions, and stream in the OS. This is then followed
by "bootctl --image=…" to install the boot loader. Possibly
"systemd-firstboot --image=…" is finally used to set root pw and such
(yeah, this optoin doesn't exist yet either, but you get the idea).

On first boot, "systemd-repart" would run to add in swap or so, maybe
scaled by RAM size or so, and maybe format and encrypt /home.

> I would -- if I was sure what the best solution for the problem is:-)
>
> I have an immutable image on an USB stick that I boot from. That
> contains systemd-repart files in /usr/lib/repart.d, /etc/fstab,
> /etc/crypttab and whatever else that is needed. I want to boot from
> that USB stick, use it to partition hardware as configured in the
> image and then copy the image over to the hdd. Think of it as
> auto-install:-)

This sounds for the perfect usecase for systemd-repart.

> With your extended systemd-repart: How can I reference these newly
> created filesystems in /etc/fstab?

Well, my thinking was to mostly rely on the "gpt-auto" logic,
i.e. that simply because they carry correct gpt type uuids systemd
would discover and find them.

> Labels suck, UUIDs are generated and not known before they are written
> to disk (and not even then, since systemd-repart might skip some
> partitions, changing UUIDs of those with the same type that come
> later) and partition numbers are not fixed as systemd-repart may leave
> out low-priority partitions.
>
> So how can I reliably reference filesystems newly created by
> systemd-repart in /etc/fstab?

So, if the gpt auto logic doesn't suffice, then probably labels. Or
you come up with your own UUIDs for the partitions.

> Is providing UUIDs (both for filesystems as well as for partitions) in
> addition to labels (both for filesystems once that becomes available
> or for partitions) the best approach? I can't think of something
> better, but that does not mean there is nothing;-)

So I'd not discount labels. I think we should start supporting
specifier expansion in the label strings, so that we can generate them
somewhat automatically, derived from environment parameters.

> PS: Is systemd-tmpfiles run after mounts with --prefix=/mnt/point? Or
> how do you see people populating the newly created filesystems?

As indicated above with CopyBlocks= and CopyFiles= if this shall be
done during image creation. Copying in blocks and files is probably a
20 line patch or so only (we have helpers for it in place anyway, we
just need to call them), and has again this nice benefit that we can
schedule it so that the partitions pop up fully populated and there's
no time where they are half initialized. This means you can abort an
installer any time and the disk will appear as it was before, only
when it comes to the very latest step the partitions suddenly pop into
existance, fully populated with whatever they shall contain.

That said, I also want to add an --image= switch to "systemd-tmpfiles"
and "systemd-sysusers" so that you can run them easily offline too if
you want, just by pointing them to some disk image.

Lennart

--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [systemd-level]: how to config and enable systemd help to create coredump file when the process crashes ？

2020-05-20 Thread www 
Dear all,


how to config  and enable systemd help to create coredump file when the process 
crashes ？


thanks,
Byron___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel