issue, i.e. the
upper part of the screen shows kernel debug output that happens on
kernel oops.
i.e. it's a driver issue, and systemd hangs simply because the kernel
hangs/crashed.
Please work with your distro, they might be able to
help. Kernel/driver issues like this are out of scope for systemd
t
do in mout
mount.fuse.s3fs wrapper script really, PID 1 won't do that for you.
Lennart
--
Lennart Poettering, Berlin
things that logs its log output to
stdout/stderr
which you want to invoke from the shell, but still have the logs go to
the journal:
myscript | systemd-cat
Lennart
--
Lennart Poettering, Berlin
log messages to go kmsg, except for a bunch where we know
for sure they aren#t immediate effect of an attempt to write a log
message, and thus won't result in a cycle.
Lennart
--
Lennart Poettering, Berlin
; space or something like that), then it can't really *rely* on journal still
> working...
>
> Afaik, messages written to kmsg will be imported back into the journal
> anyway, but that happens asynchronously so it's fine.
The above describes exactly how it is, and why journald turns of
logging via IPC. journald should not be a client to itself.
Lennart
--
Lennart Poettering, Berlin
t pick up messages from another syslog service, only from
syslog clients. Thus, there is no loop.
Lennart
--
Lennart Poettering, Berlin
ways how log messages are delivered to journald.
Lennart
--
Lennart Poettering, Berlin
as
> dropped off the bus and is never going to return a response? If that were
> possible we could possibly rely on that rather than an explicit timeout. I
> think the answer to this question might be "no" though...
it detects that out-of-the-box.
Lennart
--
Lennart Poettering, Berlin
On Mo, 16.08.21 17:31, Amish (anon.am...@gmail.com) wrote:
>
> On 16/08/21 5:25 pm, Lennart Poettering wrote:
> > On Mo, 16.08.21 16:09, Amish (anon.am...@gmail.com) wrote:
> >
> > > Some old scripts that we have expect interface names starting with eth.
piface | sed s/tmpeth/eth/)"; done
>
> This ensures that I have predictable names starting with eth*. And it is
> working fine from 2-3 years. Even with current issue, name assignment is
> working fine.
This cannot work and is necesarily race. Stay out of the ethXYZ
namespace, that's the kernel's namespace. Pick any other names,
i.e. "foobar0", "foobar1", but otherwise you just have a racy racy
mess, because the kernel might take the name whenever it pleases.
Lennart
--
Lennart Poettering, Berlin
minified on logout. But in my case it's not
> at all. Here is my executed command and output.
I thought I had fixed that issue. Which systemd version is this?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.
logs should explain why.
"systemd-analyze log-level debug" is the command to do that during runtime.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
ill implicitly then do a "systemctl daemon-reload" for
you, too. You can also do that part manually, maybe after you actually
removed the unit files from disk.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-d
e?
It's not available right now. Please file an RFE issue on github so
that we can look into it. Or provide a patch that adds it.
We nowadays have the Varlink IPC API in journald, it should be pretty
straight-forward adding this logic there.
Lennart
--
Lennart Poettering, Berlin
ur support for C++ goes.
I have no experience with C++ exceptions and C stack frames. We have
no explicit support for any of it, so they are handled like in any
program where C++ is called from C contexts, and I figure there will
be plenty docs about that.
Lennart
--
shot down any attempt to optionally attach more
metadata to AF_UNIX datagrams (if we had just the cgroup this would
already make things *so* much better for us).
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freede
v1 and cgroupvs2 when we added it, even
though not strictly necessary on the former, to minimize behavioural
differences.
maybe your old systemd is just +that* old?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
sy
.
This would mean we'd scale the safety net by the amount of physical
memory in the system. i.e. 2% of physical RAM, but 16M at most. This
should then cover your case too? i.e. enforce a lower limit on smaller
systems, and the existing 16M limit
don't?
You configured your unit to prohibit that via the start limits you
defined. If you want to allow quick, repeated starts then raise the
limit.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
after 1 Seconds with resultcode 0).
Raise the start limit?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
is, but your distro
might add that.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
person. Ideally this would be the default setup of Docker, but well,
apparently it isn't.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
We have no such target upstream, and I am not sure we should add
that. Maybe your downstream distro has that though.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
1 the SELinux context is not computed. Text like
> this would have saved a lot of head scratching and code reading :(
We should probably make this work for any service that is instantiated
with a single fd. Can you file a bug on github asking for this?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
collision
attacks.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
gt; container and start dhclient at your own from a trivial systemd-unit?
Reindl, I warned you very explicitly not to behave like this:
https://lists.freedesktop.org/archives/systemd-devel/2021-February/046028.html
You ignored that now. You are now blocked on this mail
heading in the wrong direction?
Let's follow up on the PR, it's the better place to development
discussions on specific bugs or problems. I replied on it the other
day.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
s very old. You might want to switch to a newer OS for this
anyway.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
tate and is stuck forever. In the mail I have attached
> a minimalistic reproduction of the issue seen.
Are you running systemd inside of a Docker container on Ubuntu 16.04?
Docker isn't really up to that. In particular not 5y old versions of it.
Lennart
-
ld follow the documented behaviour of
machine-id, because if you don't then things will break all over the
place.
Please see machine-id(5) for details about the file.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@li
rovide the full
logs off that unit. "journalctl -u ".
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
this might
delay delivery of the events to PID 1. However, there's certainly some
relationship here: if certain devices are the ones we start processing
first thy are likely also the devices where we finish processing them
first, even if there's no strict guarantee for that.
Lennart
--
Lennart Poetter
e does not see, mark that one device as "failed"
> and I have no idea why systemd would do that for that one device.
> Would somebody care to share so ideas?
I am not sure I properly grok what you are trying to say, but: did you
check the logs?
Lennart
--
Lennart Poettering, B
elf din't reveal
anything?
Anyway, please consider submitting the addition as a PR if it's indeed
unlikely linux-usb.org comes back as a maintainer for this.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.fr
x checker tool" to
> generate a summary of the overhead, errors, dependencies
> etc., before running the daemon into the new configuration
> setting...
"systemd-analyze verify"
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel
On Di, 01.06.21 14:33, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:
> >>> Lennart Poettering schrieb am 01.06.2021 um 13:39
> in
> Nachricht :
> > On Di, 01.06.21 12:42, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
> wrote:
> >
> >>
3) Can I avoid that problem?
Figure out which kernel driver/subsystem is responsible.
You could also enlarge the kernel log buffer, see log_buf_mem= kernel
cmdline switch.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel
executed at that time.
Thus, if you intend to drop in additional files as services you should
ideally do so before PID 1 initializes, i.e. in the initrd.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists
t; hing is that if say cage or vte takes a segfault during say an apt-get
> install,
> the running command doesn't die...
The service that implements your terminal emulator could upload the
pty master fds to systemd via the fdstore logic. That way the master
will stay open across resta
o grant that to your terminal app's user. THe polkit auth
request carries the unit name as additional metadata, hence that
should be pretty easily done with some minimal polkit JS.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
were:
I still donÄt get what the "end goal" is. You start with the tools you
want to reach your end goal, but never specify what precisely that end
goal is.
Do you intend to replace the Linux VT with a userspace implementation
of the same concept?
Or do you want to run a full-screen g
ee for you. You may request a
delegated subtree you can manage your own stuff in, but the top-level
of the tree is always owned and controlled by systemd and if you
interfere with it, you get to keep the pieces.
This is explained here:
https://systemd.io/CGROUP_DELEGATION
Sorry if this is disappo
n their own, so I have registered it there as well (as a
> "community" since I'm ~not really~ a representative). So if there are no
> objections I'll make a PR to update systemd's README files to "s/
> freenode.org/libera.chat/g" sometime later.
S
user to run unpriv
commands, but it's a all-or-nothing thing.
> The second thing: Things like nmtui need a full logind session to be able to
> run, and do polkit actions. However on seat0, it seems you need to decide on a
> empty TTY to use, which while you can use TTY63, that doesn't seem t
'll really just get the naked devicenodes and not
more. This is typically not enough to run any non-trivial software
that wants to to device management, since the enumerate/monitor
devices via sysfs/uevents/udev and that kind of stuff simply doesn't
work
documented on the
journald man page.
Verification is only available in journalctl.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
gt;
> Someone would care to decipher that for me or/and shed bit more light on
> possible troubleshooting?
which host OS, which payload OS? which host systemd, which payload
systemd? is this an nspawn container? is the container fully booted up?
Lennart
writable.
The main difference I that in the second case the configuration is
immutable too, while the firt case allows it to be changed locally.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
ions on whether we shouldn't require
/var to be mounted from initrd, but so far we didn't decide that this
was necessary, given the political effort this would take to require)
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel
happens, while sometimes it does reboot during my local
> testing. Is there a way/command to make sure system get rebooted?
Check the logs?
https://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1
Lennart
--
Lennart Poettering, Berlin
___
file.
> Not seeing this issue before /sbin/telinit becomes a softlink to
> systemctl.
vmtoolsd.service is probably asked to shutdown because of the system
shutdown, and the forked off /sbin/telinit is part of that service, so
it gets terminated too?
Lennart
--
Lennart Poettering, Berlin
_
m
processes, of course.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
tailed systemd log?
man 5 journald.conf
Maybe your distro didn't enable persistent storage of journald, and
thus journald uses only in-memory storage in /run, and is thus
constrained by its diminutive size?
Lennart
--
Lennart Poettering, Berlin
___
sys
tall a signal handler or anything like that.
> It looks like a stronger memory model is needed here (not volatile).
> Other projects use __atomic builtins for this.
All of sd-event's data structures should be accessed from a single
thread only, in a single non-signal execution context.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
of systemctl on the client side? I was
more interested int the logs of systemd, i.e. of PID 1.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
n run this script
during boot, and order it before networkd, so that the conversion is
completed on each boot, before networkd is run.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Mo, 19.04.21 20:19, Tia, Javier (javier@hpe.com) wrote:
> Hi,
>
> Is there a way to know inside of systemd if it's in a reboot state?
systemctl is-system-running
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing lis
.org/viewtopic.php?pid=196#p196 -- please
> ignore the starting comment, the last 3 are the most relevant. See
> some system info below the mail.
Maybe your local hostname or an /etc/hosts entry exist that match the
domain name you are looking up?
Le
r upstream or by the distro. If you do it
downstream you might run into issues like this.
The idea of @system-service is that it mostly tries to isolate you
from this, but in your case you overrode what it does, so it fell apart.
Lennart
--
Lennart Poettering, Berlin
__
atever you want.
Anyway, the upstream systemd project is the wrong forum to discuss any
of this. You are apparently upset by a RHEL decision. While I
sympathize with the decision, it's not a decision the systemd project
took, but RHEL did, and technically nothing in systemd mandates
this.
Lennart
--
Le
tall a signal handler for SIGTERM via sigaction, and
look into the .si_pid field of the siginfo_t you can receive in the
handler. It tells you which processes sent the SIGTERM.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
syst
ld be cleaner (ie.
> hooking it up in service files).
>
> What are the best option(s) here?
Use logind's D-Bus APIs. It's the cleanest way to reboot, as it
honours inhibitors and stuff.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
s, as that leaks
pretty sensitive information about the local network infrastructur
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Do, 08.04.21 17:19, Hadrien Grasland (hadrien.grasl...@ijclab.in2p3.fr)
wrote:
> Le 08/04/2021 à 16:11, Lennart Poettering a écrit :
> > On Do, 08.04.21 12:24, Hadrien Grasland (hadrien.grasl...@ijclab.in2p3.fr)
> > wrote:
> >
> > > Hi everyone,
> >
rks are running, in order to improve
> the stability of said benchmark's I/O performance.
Is this on cgroupsv1 or cgroupsv2?
IIRC there was some issue that the block io controller wasn't fully
recursive on cgroupsv1. It should work on cgroupsv2.
Lennart
--
Lennart
On Mi, 07.04.21 12:17, Carlo Wood (ca...@alinoe.com) wrote:
> On Tue, 6 Apr 2021 18:41:21 +0200
> Lennart Poettering wrote:
>
> > EBADMSG usually means that somehow an invalid dbus packet we couldn't
> > parse entered the stream. maybe some memory corruption thing? or ma
ng this in a threaded env without locking?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
er on cgroupsv1, it's just too messy
of an interface.
It's supported fine on cgroupsv2 with a recent systemd version, where
you'll have "systemctl freeze", and things should just work.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel m
ation. Please provide "systemctl status" info
on the relevant units and jobs, please provide a dump of the output.
And most importantly, always start with the systemd version number you
are using, and whether you have any weird udev rules or so, or just
plain
for devices like this was just tooo large for the kernel to
carry, but that's not the case here either: it's two devices afaik,
and such an issue wasn't seen elswhere.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
when running on a console.
Maybe update to something less ancient, or ask your distro to backport
the fix.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
l deps. The normal dep
should be totally sufficient. But only declare a ExecStop= line.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
a new compression and other stuff in
246. If these features are used in a file you need a client library
that supports them to access the features.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.o
ng the same code on my host machine correctly yields the log files.
Does "journalctl --file=…" work?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Mo, 08.03.21 18:29, Christian Kastner (c...@debian.org) wrote:
> On 07.03.21 23:34, Lennart Poettering wrote:
> > Right now whether to require the FIDO2 PIN is not configurable. We
> > could make it configurable though, so that you could use it in 1FA
> > situations.
he PIN stuff is not an optional FIDO2 feature IIRC this is 2FA in
all cases.
Right now whether to require the FIDO2 PIN is not configurable. We
could make it configurable though, so that you could use it in 1FA
situations.
Lennart
--
Lennart Poettering,
e errnos instead, and ignore them, and never forget
that the mapping logic is not a D-Bus invention but an sd-bus one.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
but more of a D-Bus issue hence.
Which systemd version is this?
Please contact your distro for help first.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman
s present in the host mount namespace, then this one is
> likely a "foreign" mountpoint, and shouldn't be unmounted.
Not sure I follow. We'd need this from inside the container, so that
we don't even try to unmount the file system. But from "inside" we
have no outside to the hos
d in the worst case time-set.target will catch this and be
delayed for the time necessary to make the timestamps accurate. But if
the RTC is quick to be probed then you get correct timestamps as early
as possible.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
he clock before journald
> first starts should make journal times correct.
> Or I am wrong?
kmsg comes with monotonic timestamps only. journald stores that away
but generally uses its own acquired timestamps, since it needs to
guarantee monotonicity and thi
Maybe the service actually checks if getppid() == 1 or so?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
k sucks then they'll look
differently than you might expect.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Mo, 01.03.21 14:52, Michał Zegan (webczat_...@poczta.onet.pl) wrote:
> Someone should really find a way to make it cooperate well with modular
> rtcs.
> It's popping up over and over and over and over again and no one is/will
> build all rtc drivers into the kernel.
To my knowledge the kernel
we provide, via sd-event. Use
sd_bus_get_fd()/sd_bus_get_events()/sd_bus_get_timeout() for
integration to foreign event loops.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
k of my wording and go from there.
Already done:
https://github.com/systemd/systemd/commit/3acf00a5a4ff656e2799f7f3e2544891b09bbc35
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.
nd of status log messages, that
tell you what the tool is doing.
You can turn off logging if you like by setting
SYSTEMD_LOG_TARGET=null if you like. In that case all log output is
suppressed and you'll only see the actual output being generated.
Lennart
--
Lennart Poettering, Berlin
_
t just a technical difficulty but
given the maintainer of said interfaces also a political one.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
modifying)
> to generate those .conf files and call daemon-reload during boot? If the
> latter, are there any expected risks associated with calling daemon-reload
> during boot?
Doing this with a generator sounds perfect to me.
Lennart
--
Lennart Poettering, Berlin
_
/etc/machine-id from the initrd, right
before transitioning to the real OS, by overmounting it. If it's
already initialized PID 1 will happy use it after all.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
ick around on login sessions
under some conditions. We added workarounds later on for that. But
seriously, this is so long ago... no idea.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https:/
else?
Figure out which software actually listens to those RA messages and
then propagates it to resolved. And then figure out why it does that,
i.e. whether it was configured that way.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
;
> So, now my question, why wasn't the dnsmasq server found/configured as had
> been the case?
> An intentional change or unintentional change?
I am not sure which software manages that interface, but it would be
worth figuring that out, and then checking w
On Fr, 19.02.21 18:09, Mantas Mikulėnas (graw...@gmail.com) wrote:
> On Fri, Feb 19, 2021 at 4:49 PM Lennart Poettering
> wrote:
>
> > On Fr, 19.02.21 09:28, Robert P. J. Day (rpj...@crashcourse.ca) wrote:
> >
> > > i guess i expected that the CVE identifier would
ge git commits, that's just not
how this works.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Fr, 19.02.21 08:44, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:
> >>> Lennart Poettering schrieb am 18.02.2021 um 19:30
> in
> Nachricht :
> ...
> > entry instead of asking for new memory again. This allocation cache is
> > a bit quicker th
do not need to communicate their main PID explicitly.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
ListenStream=socketpair or so as another value, which would
then do the right thing.
I kinda like this model, I must say.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
even though there
isn't really, the memory is not lost after all, and will be reused
eventually if we need it.
You may use the env var SYSTEMD_MEMPOOL=0 to turn this logic off, but
not sure v230 already knew that env var.
Lennart
--
Lennart Poettering, Berlin
___
syst
pace exhaustion. if it had, we could certainly hook things up with
that…
Does that make any sense?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
501 - 600 of 8632 matches
Mail list logo
