s, e.g. both at boot
and regularly at some specific time.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
irectory name it was not
> properly found by the timer-triggered service run.
As mentioned this doesn#t have anything to do with timers or no
timers. The rule is just that the ".d/" must be append to the unit or
template name, i.e. after the ".service", as you noticed.
Lennart
iggred. i.e. if timer activated or activated as dep or
at boot should not matter at all.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
rate
timestamps we generate them when we flush that. So maybe that flushing
happens after the fake rtc thing?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
me way as
/dev/urandom is kernel API /proc/sys/kernel/random/boot_id is kernel
API and we should rely on it to work and if it doesn't then it needs
to be fixed in the kernel.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@
bugreport.cgi?bug=963977
Umpf, that's a bad kernel bug. It suggests the boot_id is picked
before the random pool is fully initialized.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
es what fake-hwclock does automatically, and
also does SNTP. it should be fine for most usecases, no need to resort
to fake-hwclock)
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
lder versions of the
OS/kernel if it doesn't boot. Thus some form of write access is
necessary if you care about robustness.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
ample
Fedora does that since 2011:
https://bugzilla.redhat.com/show_bug.cgi?id=707917
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
lrwxrwxrwx 1 root root9 2020-08-24 12:47 systemd-userdbd.socket ->
> /dev/null
Well knock yourself out, but masking is not necessary, you can just
disable homed/userdbd/timesyncd if you don#t want it, and repart is
conditioned out anyway, so masking doesn't really get you much.
Lennart
--
L
where persistant configuration is supposed to be.
I am sorry, but /etc on Linux is a single directory, and you can only
cleanly choose between all configuration read only or none, there's no
nice way for a middle ground. Sorry.
Lennart
--
Lennart Poettering, Berlin
__
also interfering with received RAs?
we bind per interface, there should not be a conflict.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
e ones (i.e. Conflicts=).
Sorry,
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
in the status of "starting" the
> service when the core dump happened when stopping the service, and why isn't
> the original core dump message included as well?
I cannot parse this, and I cannot tell you how you configured your
syslog and why it shows less data.
Lennar
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
l
> ext4 partition or is it required that the kernel and initrd live on the
> EFI partition too?
No, that's not supported in sd-boot. A boot loader is a boot loader,
it should contain a fragile storage stack. It's kinda what sd-boot is
supposed to do better than grub.
Lennart
--
Lennart Poett
on XBOOTLDR and combine them.
XBOOTLDR is supposed to be used only if you have an existing ESP that
is too small to carry kernels, and you'd rather not resize it.
XBOOTLDR should be vfat too, as with sd-boot you still need an fs the
firmware can read.
Lennart
--
Le
ogind with some new concept, no suggestion. Or
simply bypassing logind and opening the devices directly with root
privs? or test this in virtualization?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@
check if number of active sessions is > 0.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
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
801 - 900 of 8651 matches
Mail list logo