provide a dbus activation file
And then everything is race-free and robust.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Di, 01.09.20 08:57, Joshua Miller (joshuamille...@gmail.com) wrote:
> On Tue, Sep 1, 2020 at 7:30 AM Lennart Poettering
> wrote:
> > Anyway, do you want this for login users or for system services?
> > Initially your reference to User= suggests the latter, but your
&g
o, given that PAM
isn't really what system services should bother with.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
in the man page and
the docs otherwise.
And besides that, we actually push people towards using
RuntimeDirectory=, StateDirectory=, … and stuff so that these dirs are
created when the service is started and not earlier, for services
where that works.
systemd/system/ to
/etc/systemd/system/ and then fix it there. In that case the vendor
supplied version is entirely ignored and not parsed and thus the
warning goes away. If you otoh just add a extension drop-in via .d/
then the original file is read, including the legacy PIDFile= stanza,
used and fix it, or that downstrea, users notice and
complain to maintainers, and they fix it then.
There's not much point to try to fix that locally as user, it's a
warning only after all.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailin
ag", and then the software would try a restart (up to the next
> failure)
You can add a hack around everything you like. But I'd suggest fixing
the actual issue instead of taping over it...
Lennart
--
Lennart Poettering, Berlin
___
systemd-
he util-linux mount command. If you
don't use that, you are on your own.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
nts) doesn't
matter to us much, we just think it's much simpler if the paths stay
fixed and are useful universal identifiers, even if the stuff behind
them is actually placed somehere else.
Lennart
--
Lennart Poettering, Berlin
___
syste
s systemd established will come from system context and will
be disconnected from the client's context, and we think that's a good
thing, not a bad thing.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
it has to do with
> systemd - nobody forced him to read or respond at all
Yeah, but still no reason to ask people "what their f** problem" is...
Anyway, just stop this. Both posting insults like that, and then
discussing them. One more post on this and you are back on moderation.
Lennart
-
On So, 16.08.20 17:14, Reindl Harald (h.rei...@thelounge.net) wrote:
>
>
> Am 16.08.20 um 17:03 schrieb Lennart Poettering:
> > On Sa, 15.08.20 22:56, Reindl Harald (h.rei...@thelounge.net) wrote:
> >
> >> is it a bug or a concept issue that it's mounted fpr root i
On So, 16.08.20 17:16, Reindl Harald (h.rei...@thelounge.net) wrote:
>
>
> Am 16.08.20 um 17:01 schrieb Lennart Poettering:
> > On So, 16.08.20 09:05, Reindl Harald (h.rei...@thelounge.net) wrote:
> >
> >> how is it not given it#s a systemd-option and what is your f*
oot"?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On So, 16.08.20 09:05, Reindl Harald (h.rei...@thelounge.net) wrote:
> how is it not given it#s a systemd-option and what is your f**
> problem?
Reindl, I'll put you back on moderation if you write another mail like
this.
Lennart
--
Lennart Poettering,
On So, 16.08.20 15:01, Steve Dodd (steved...@gmail.com) wrote:
> 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
On Sa, 15.08.20 13:33, Steve Dodd (steved...@gmail.com) wrote:
> 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-f
's no
way around that.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Fr, 14.08.20 06:42, Harald Dunkel (harald.dun...@aixigo.com) wrote:
> On 8/13/20 11:07 AM, Lennart Poettering wrote:
> >
> > No! It's a bug. Not in systemd, but LXC. But generating errors in such
> > a borked setup is *good*, not bad, and certainly nothing to hide.
> &g
licit syscall or so. But here we have
a read() call where we get the clearly borked data from, hence we
generate this as EIO and not EINVAL.
Ultimately, which error code to generate is just bike-shedding though...
Lennart
--
Lennart Poettering, Berlin
_
og this (invalid PID and and in which
> > cgroup it was). Returning generic error message without any indication
> > what caused this error is not useful at all.
>
> I agree. Could you file a github issue for this?
Please file a bug against LXC instead. They need to set up the
envir
> what caused this error is not useful at all.
>
> Do you think it would be reasonable to silently ignore the PID = 0
> in cg_read_pid() and maybe others?
No! It's a bug. Not in systemd, but LXC. But generating errors in such
a borked setup is *good*, not bad, and certainly nothing to h
t entirely bogus. This is very
clearly documented.
It's an LXC bug, that's all. And yes, it causes weird error messages
in systemd, but that's because the setup is just so broken, and as
long as you do get *some* error messages I think we are good.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
ainer and the host run in the very same cgroup
hierarchy?
If that's the case (and it looks like it): this is not
supported. Please file a bug against LXC, it's very clearly broken.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
ing correctly we
cannot reasonably operate.
And there *is* logging about this: client side, i.e. the message that
this whole thread was started about.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
IO, since we read borked data.
I am not sure why LXC should insert random processes into random
subtrees of our cgroup tree. If it does that, this would really be a
bug...
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-
the next thing to try would be to turn on debug
logging with "systemd-analyze log-level debug" and reproduce the
issue, then check if there's anything interesting in the logs.
Please provide the relevant log excerpts here then.
Lennart
--
Lennart Poettering, Berlin
___
hile the backup is still running. Then, maybe you need some service
to be up while you are doing your backup (or a mount), and it might be
used by something else too, but should go away when not used. You can
pull it in cleanly from your timer's service now, and mark it
StopWhenUnneeded= so that it goes awa
for that as well if I name my EFI images in a similar
> naming scheme as the entries in $BOOT/loader/entries
>
> If not; is there a good reason why not and is it something that is worth
> implementing?
It should already just work. If it doesn't it would be a bug.
Lennart
--
Lennart Poetteri
uch an addition would make a ton of sense.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
stance. And there's tons of other stuff too.
i.e. it unifies how system programs are invoked, and that's a good
thing. it turns time-based activation into "just another type of activation".
Lennart
--
Lennart Poettering, Berlin
___
systemd-de
pen concurrently.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
nabled on old kernels since it's
slow there. On newer kernels we enable some accounting by default, but
not all.
For the root cgroup we can use the system resource accounting, which
is available always, hence you always see useful data for the first
line, regardless if per-unit accounting is on or not.
L
On Mo, 10.08.20 19:36, Lennart Poettering (lenn...@poettering.net) wrote:
> On Fr, 17.07.20 14:38, Xogium (cont...@xogium.me) wrote:
>
> > Hi,
> > as the subject says, I am trying to use repart to add a partition on a block
> > device, from inside the initramfs. I also m
Alternatively, file an issue, and we'll look into it, eventually (or
is there already one filed?).
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
art=on-abnormal
> RestartSec=1
> LimitSTACK=infinity
> LimitNOFILE=65535
> LimitNPROC=65535
>
> [Install]
> WantedBy=multi-user.target
Please provide the "sytemctl status" output when this happens.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
end
inhibitors so that root can't trivially override it, but so far this
hasn't been implemented.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Mi, 29.07.20 08:57, Ian Kent (ik...@redhat.com) wrote:
> On Tue, 2020-07-28 at 16:13 +0200, Lennart Poettering wrote:
> > On Mo, 27.07.20 12:57, Ian Kent (ik...@redhat.com) wrote:
> >
> > > Further to my post about using the new mount table notifications in
> &g
ing else
as negatively. This however means that if CPU/IO is scarce the
coredump processing might be delayed quite a bit.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
d-anaalyze completion does not cover log-level
Could you please file github issues about both issues?
(And ideally provide an strace of the stdio bridge thing?)
https://github.com/systemd/systemd/issues/new?template=Bug_report.md
Thank you!
Lennart
--
Lenna
=infinity
>
> found it from here
> https://github.com/systemd/systemd/issues/4997
>
> Although I'm running it from cmd and
> --property="LimitNOFILE=infinity" gives me an error.
>
Use
systemd-nspawn --rlimit=RLIMIT_NOFILE=8192:16384
l restart foo.service`, and there could be other
> things too?
Seats are a concept of grouping hardware. A seat without hardware
is pointless. If you have no hardware associated with a session then
the session is seat-less, which is totally fine.
I don't get what you are trying to d
On Di, 28.07.20 12:12, Ian Pilcher (arequip...@gmail.com) wrote:
> On 7/28/20 9:44 AM, Lennart Poettering wrote:
> > Is the service short-lived? There's a race: if a process runs very
> > quickly and logs journald might process the message after the process
> > already e
rdError=syslog
Also remove this line.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
up, and before it has started going down? Essentially, I
> want to emulate the up/down feature of ifupdown.
See systemd.special(7), look for "network-online.target".
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
sys
fically delay your service's exit (sleep 10...) but it's
still racy and sucks hard. You could issue the equivalent of
"journalctl --sync" at the end of your program...
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-deve
thub?
See:
https://systemd.io/CONTRIBUTING
https://github.com/systemd/systemd/pulls
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
d 16.5 days to the current
unix day, then break that down to the day, and use that to re-enqueue
a transient calendar event)
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
ess...
>
> How would you solve this problem?
Dou you actually men ExecStartPost=? Or is this a typo and you mean
ExecStopPost=?
How does your service definition look like otherwise?
You can query the exit code with "systemctl show -p ExecMainStatus --value
&
to-generator does by default...
My recommendation: mount the ESP to /efi, and maybe add a symlink from
/boot/efi → /efi, which makes things work with old code that insists
that the ESP must be available in /boot/efi...
Lennart
--
Lennart Poettering, Berlin
___
See:
https://www.freedesktop.org/software/systemd/man/org.freedesktop.systemd1.html
This does not go into detail how D-Bus works, but simply explains the
interfaces systemd provides via the bus.
"systemctl show" is just a thin laye
the VT100
> seem so slick and futuristic.
Our default used to be vt100 originally, but that can't do
pgup/pgdown, which people found quite annyoing. vt220 adds support for
that, and is apparently as widely supported, so we changed to that.
Lennart
--
Lennart Poette
On Mo, 20.07.20 15:03, s...@collabora.com (s...@collabora.com) wrote:
> On Sat, 11 Jul 2020 at 21:04:18 +0200, Lennart Poettering wrote:
> > widely-supported TERM value
>
> For a value of TERM to work (at all), it must be something that is reliably
> present in the terminfo/te
able one that is available widely in
termcap, that does color, and is a subset of both TERM=linux and
TERM=xterm.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
r, unicode, emoji support individually via
env vars btw, if people really want compat with such old terminals.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Di, 14.07.20 11:02, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:
> >>> Lennart Poettering schrieb am 14.07.2020 um 09:50
> in
> Nachricht <20200714075029.GC180968@gardel-login>:
> > On Di, 14.07.20 09:10, Dac Override (dac.overr...@gmail.com) wrote
an, if this all is the case, could you prep a PR?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
list defined for service, and @resources is not included 0.2
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart
--
Lennart Poettering, Berlin
__
ut we added that only in v242. See NEWS.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
ngle service, let say A.service, B.service, C.service However,
> often you want to be able to start and stop them together. There are
> two options that I am aware of: a grouping service of a grouping
> target.
Target unit's raison d'etre is grouping stuff. Use a target.
Lennart
ke an informed statement on
> that matter. Before I make the argument for it being fixed I want to be
> sure of my argument!
well, one never knows what might triger bugs somewhere, but afaics
this should be a relatively riskless fix.
Lennart
p. In that case we'd mark things as "neutral". As
soon as gdm then received user input so that the log in starts, it
would mark things as "bad" again. And when GNOME in the user's session
finally is done with everything we'd mark things as "good" and
everything is complete.
>From
the
syntax Topi suggests makes a lot of sense and is a nice extension to
what we already have in place.
I mean, I personally don't like audit very much, I'd always prefer
using something else over audit...
Lennart
--
Lennart Poettering, Berlin
___
syst
t
stuff too?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
M=xterm or TERM=linux depending if you invoke qemu on an xterm or
from a Linux console, hence the best thing we can do is stick to a
reasonably powerful subset that is likely going to exist everywhere,
and that's vt220 right now, as noone had a better suggestion so f
dev device. But if you drop that for a device and a
service has the dependency on it anyway then this will just mean it
will wait forever for it, because it never shows up then anymore.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mail
just ping that service if all is good.
The service would then become part of the usual boot process, ordered
before the boot blessing.
Wouldn#t that suffice?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
against your distro, so that they add After=network-pre.target.
My educated guess is that, it's not trvial to get this right: we
document what network-pre.target is for in systemd.special(7) man
page, but I figure not everyone looks there. And i guess one most know
a certain level of systemd to unde
; consider a dist-upgrade
This looks like dracut didn#t package the file correctly into the
initrd. Please file a bug against dracut.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedes
ter to refer to the target section directly, instead of
> referring to a section that refers to another section using a different
> keyword, too.
Send a patch as PR on github!
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
s
.device" and have a look for the
WantedBy= and RequiredBy= fields.
The unit name looks fishy, this almost certainly indicates some
incorrect unit file or other bug in the unit responsible.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing
forks a child off (callout script?) that
double forks somewhere?
I don't know your software, it's probably best to ping the authors of
it about this, they should know what their software does.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Fr, 26.06.20 21:43, Mohan R (mohan...@gmail.com) wrote:
> Hi
>
> On Fri, Jun 26, 2020 at 9:23 PM Lennart Poettering
> wrote:
> > You might need a newer libseccomp so that the syscall is actually
> > known by it. openat2 is a very recent syscall addition, and you need
On Do, 25.06.20 20:19, Mohan R (mohan...@gmail.com) wrote:
> Hi
>
> On Thu, Jun 25, 2020 at 2:17 PM Lennart Poettering
> wrote:
> > You can't disable seccomp right now.
>
> Any future plan to include a flag or some other way?
>
> > We implement a system
pping, then it gets mapped to "nobody".
If you run binaries under that UID they'll hence get access to stuff
they really should not get access to, nobody should in fact, hence
these files are actually owned by just that, a user "nobody".
If you use the "nobody" us
ance of service foo up and running. Copy the file,
> change the
No. You suddenly have to take of *one* *more* external file and break
all the usualy workflows with "systemctl edit", "systemctl revert",
"systemd-delta" and suchlike.
Lennart
--
Lennart Poettering, Ber
any environment variable being used.
> Unclear is _when_ the copy should take place however.
Just use m4 or shell. No need to duplicate in systemd what those
languages already do.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
ove, variables (specifiers, whatever you call them) are not shell
> specific.
They are not shell specific. You could also use m4 if you want a
templating language, there's no shame in that. But systemd is
certainly not in the business of inventing yet another shell or
generic templat
ut systemd has no concept of env var expansion in unit files. It's not a
> > shell.
>
> That is unfortunate (not the shell part, but the variable one), but thanks
> for the explanation, that helps.
If you want a shell, use a shell.
Lennart
--
Lennart Poettering, Berlin
__
ot part of the unit file language, but of the executor code.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
eric application code should have fallbacks in place when it comes
to new system calls such as openat2(), if they are supposed to work on
kernels that aren't the very newest or in containerized environments,
since pretty much all of them employ a syscall filter allow list these
days.
Lenna
On Mi, 24.06.20 09:02, Chris PeBenito (chpeb...@linux.microsoft.com) wrote:
> On 6/23/20 10:57 AM, Lennart Poettering wrote:
> > On Di, 23.06.20 09:41, Chris PeBenito (chpeb...@linux.microsoft.com) wrote:
> >
> > > I've got some challenges using systemd's
t way you can have
a common definition that is used by a variety of services. This is in
fact what portablectl's --profile= logic internally does: it just
symlinks a common .d/ drop-in into all service files it attaches. The
common profiles are shipped in /usr/lib/systemd/portable/profile/.
L
> Then, if nftables initialisation fails (e.g. because kernel was
> built without nftables support), fall back to libiptc/iptables-classic.
Yes, perfect!
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.fre
e interaction with the kernel side of things?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Fr, 05.06.20 15:29, Lennart Poettering (lenn...@poettering.net) wrote:
> On Do, 04.06.20 16:58, Tobias Hunger (tobias.hun...@gmail.com) wrote:
>
> > Poking around a bit more: I have 4096 unused sectors before the first
> > partiton instead of just 2048. Systemd-repart then t
s correctly, since systemd just
kills what the ExecStop= binary doesn't kill.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
e in this case we should probably generate a log message in the
main journal file, since only the user one was corrupted.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
fficult because we cannot
> conditionally decide upon the behavior in our code based on the systemd
> version, as 245 exhibits various behaviors depending on the minor version...
Please file a bug on github.
Lennart
--
Lennart Poettering, Berlin
__
ng against libsystemd.)
It will report all failed services to you. You can even add "-o
verbose" (or -o json) to get additional structure info from it.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
= n;
>
> }
>
>
>
> Is there any specific reason the “Lock” action is not handling in systemd?
>
>
>
> Is there any plan in future if the “Lock” action is handled in system?
This might be a bug. Please file a bug on github about thus. Thanks
Lennar
ed boot delay? Is rm'ing either the "Also=" or
> "WantedBy=" a reasonable band-aid?
>
> Or, some other approach?
You could use RequiredForOnline= in the bridge's .network file to mark
it as irrelevant for systemd-networ
output whatever they want onto the console.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
the CPU scheduler,
not the IO scheduler.
Also, you need to turn off RT group sched in the kernel, as otherweise
the CPU cgroup controller will disallowe rt sched all the way down the
tree unless an rt budget is configured for each cgroup in the tree.
Lennart
--
Lennart Poettering, Berlin
__
ctl --static
> set-hostname instantly sets the transient hostname to *only*
> when is not the current static hostname ?
There's a shortcut in place: if you change a hostname to what it is
already set to things are NOPs, and won't generate security incidents
and so on.
Lennart
--
Le
all the time, but then condition
them out in the environments you don't want them to run it. i.e. by
adding a drop-in with "ConditionVirtualization=" or
"ConditionKernelCommandLine="... and so on.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
:
> Invalid argument
Yes, it's a bug:
https://github.com/systemd/systemd/issues/16146
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
hether there is any
> built-in log-level style control for these systemd-generated messages.
systemd logs about everything it does. If you don#t want that, you can
turn it of. Set "systemd.log_level=notice" or so on the kernel
cmdline, or LogLevel=notice in /etc/syste
eproducer on github.
Please enable memory and IO accounting in your unit to get proper
accounting.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinf
e going on, something is reloading PID 1 configuration repeatedly
during shutdown. Please figure out what does that and fix that. It's
not how this should work...
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
801 - 900 of 8632 matches
Mail list logo
