s its "leader" and binds the session's
lifetime to that leader process lifetime. Except of course you are
using some distro that turns KillUserProcesses= off, which disables
this logic for compat with legacy.
Lennart
--
Lennart Poettering, Berlin
at properly fscks
the rootfs before mounting it and you definitely know you want the
rootfs writable and mutable (i.e. your OS doesn't support immutable
operation), then just drop "ro" from the kernel cmdline together,
there's really no point in first mounting it read-only just to
ename to ensure
that the tools always use the library built from basically the same
sources.
hence, what you are trying to do is expressly against what this
library is.
Lennart
--
Lennart Poettering, Berlin
ets a SIGHUP because of that.
>
> Brian M also suggested that might be the cause, but I don't see any
> ttys when I do "ls -l /proc//fd".
it's not so much about that, but about which ctty your process has.
Lennart
--
Lennart Poettering, Berlin
idea, there's not
sane authentication let alone encryption. It's not built for
that.
If you want remoting, then connect to a remote bus via ssh, systemd's
sd-bus makes that reasonably easy. See sd_bus_open_system_remote().
But please, don't do unencrypted D-Bus remotely.
xLennart
--
Lennart Poettering, Berlin
HUP to the child?
Are you sure you are setting argv[0][0] properly? the killing spree we
do on switch root should exclude processes marked like that.
Note that we'll also possibly reinitialize the tty on switch root,
maybe your tool has the tty open and gets a SIGHUP because of that.
Lennart
--
Lennart Poettering, Berlin
you have your culprit.
Lennart
--
Lennart Poettering, Berlin
undamental units of systemd:
> LoadError=org.freedesktop.systemd1.UnitMasked "Unit cryptsetup.target
> is masked."
This disables key synchronization points, and the things just fail.
Lennart
--
Lennart Poettering, Berlin
%N, %o, %p, %u, %U, %v, %w, %W, %%"
>
> But I think some are valid in (some) directives of the [Unit] or [Service]
> section.
>
> My use case would be to express a dynamic activation and order dependency on
> a device name known only at boot time.
Please provide a minimal example of a unit file you think should work
but doesn't.
Lennart
--
Lennart Poettering, Berlin
think you can invest a bit of time every now and
then to maintain the tool in the future I'd be happy to pass over
maintainership to you, if you are interested?
Lennart
--
Lennart Poettering, Berlin
than
/var/lib/crash?
If you use the latter you can use StateDirectory=crash instead.
> /proc/vmcore "/var/crash/crashdump-$$(date +%%F-%%T)"'
> ExecStartPost=reboot
Note that "reboot" is actually a sysv legacy command. The most elegant
way to reboot after the service is complete is via
SuccessAction=reboot in the [Unit] section. See systemd.unit(5) man
page for more info.
Lennart
--
Lennart Poettering, Berlin
doesn't sound like a systemd issue, but like maybe some kind of
configuration management tool's work? Are you running something like
that? please contact your OS vendor for help.
Lennart
--
Lennart Poettering, Berlin
ou use very old versions, then please ask the
maintainer of that old version for help, not us upstream.
Lennart
--
Lennart Poettering, Berlin
approach impact
> portable services in systemd? Could it cause any issues with how
> portable service images are accessed or made visible, especially if
> they depend on shared mount propagation?
Lennart
--
Lennart Poettering, Berlin
se this functionality via Varlink too, so that you can just do a
method call to get a list of all local Varlink sockets, from where you
could then go on.
Lennart
--
Lennart Poettering, Berlin
th it because it forces so many roundtrips and a
single data pipe through the broker process. Roundtrips kill your
performance, JSON marshalling is entirely irrelevant for that.
People have done profiling on this. For example zbus' Zeeshan Ali
posted about this on Mastodon some time ago, where
ce units actually
*does* suppport MOVE_MOUNT_BENEATH already, it's only the system-wide
concept that doesn't. And we really should change that.)
Lennart
--
Lennart Poettering, Berlin
quite problematic I would say. What's the
rationale for that?
Note that systemd sends SIGABRT for various reasons on its own, for
example in context of the per-service watchdog logic. Hence,
redefining locally what it means substantially changes the contract
between services and the service manager.
Lennart
--
Lennart Poettering, Berlin
is not available yet, and read-only. hence, it's almost
certainly *wrong* to allow applications to see the real-one: they
should not expect they can write there, and its a terrible place to
read information from (since it's an unmanaged shared namespace).
Hence, you probably will have a ve
(logind will re-retrigger relevant devices whenever the fg
session changes, so that the udev rules are rerun and apps are
notified about the new situation via udev events)
Lennart
--
Lennart Poettering, Berlin
ntry to ^WHATEVER\+\d+(-\d+)?.conf$ ?
See loader.conf(5). It supports globs, it's literally in the first
sentence. (i.e. * and ?)
That said, i think we actually should check the glob against the
string where we stripped away the counters. Could you file a bug
against that?
Lennart
--
Lennart Poettering, Berlin
reply.
>
> Is my second statement also correct?
>
> i.e. is there no way to prevent mounting a private /tmp when executing
> generators using something like an environment variable or config setting?
There is none.
Lennart
--
Lennart Poettering, Berlin
cally can use sd_varlink_server_loop_auto() as blue print
for this, but you drop the exit on idle stuff, and instead of the
sd_event_loop() at the end you do what the sd_event_get_fd() man page
explains.
Lennart
--
Lennart Poettering, Berlin
On Di, 19.11.24 01:45, Nils Kattenbeck (nilskem...@gmail.com) wrote:
> On Tue, Nov 19, 2024 at 1:00 AM Lennart Poettering
> wrote:
> >
> > On Do, 14.11.24 14:25, Phillip Susi (ph...@thesusis.net) wrote:
> >
> > > Lennart Poettering writes:
> > >
> &g
nce generators do not have access to the system's /tmp/
and get a transient one.
Lennart
--
Lennart Poettering, Berlin
On Do, 14.11.24 14:25, Phillip Susi (ph...@thesusis.net) wrote:
> Lennart Poettering writes:
>
> > the BLKFLSBUF ioctl() works fine on block device fds open for read only.
>
> Oh, I might have to change that to use a read only open then.
>
> > I am not following a
have a useful checksum
covering enough relevant data, and it can never really catch scenarios
where a disk is comprehensively repartitioned, i.e. one or more fs and
partition metadata changed at the same time...
Lennart
--
Lennart Poettering, Berlin
On Mo, 11.11.24 08:34, Phillip Susi (ph...@thesusis.net) wrote:
> Lennart Poettering writes:
>
> >> I'm reading between the lines a bit, but my guess is that libparted
> >> always opens the device writable in case you start issuing actual
> >> partitionin
On Do, 31.10.24 12:08, Dan Nicholson (d...@endlessos.org) wrote:
> On Thu, Oct 31, 2024 at 10:23 AM Lennart Poettering
> wrote:
> >
> > On Do, 31.10.24 09:03, Phillip Susi (ph...@thesusis.net) wrote:
> >
> > > Lennart Poettering writes:
> > >
>
On Do, 31.10.24 09:03, Phillip Susi (ph...@thesusis.net) wrote:
> Lennart Poettering writes:
>
> > Doing the locking on the fd you use for writing makes things a lot
> > easier, because as mentioned udev will automatically retrigger block
> > devices if an inotify
ll have running processes, sorry. And
I am pretty sure we should not support this.
I'd recommend figuring out why these processes do not react to SIGKILL
instead of hiding the issue.
Lennart
--
Lennart Poettering, Berlin
#x27;s Tomcat.
Lennart
--
Lennart Poettering, Berlin
On Di, 29.10.24 08:28, Phillip Susi (ph...@thesusis.net) wrote:
> Lennart Poettering writes:
>
> > It prevents it fully. However, udev installs an inotify watch on all
> > relevant block devices, which watches for IN_CLOSE_WRITE events, and
> > then triggers the device
> start a session, but not close it.
>
> How can I get these 2 processes to shutdown?
They are part of the per-user service manager we are maintaining. They
go away once the user fully logged out, after a brief time-out (which
can be controlled via UserStopDelaySec= (only since v240).
Lennart
--
Lennart Poettering, Berlin
On Do, 24.10.24 15:43, Phillip Susi (ph...@thesusis.net) wrote:
> Lennart Poettering writes:
>
> > systemd is downstream to udev. If udev doesn't process a block device
> > because of the taken BSD file lock on the main block device, then
> > systemd (and other d
n the Linux kernel command line, that
> is passed to systemd/the OS somehow?
There's systemd.clock-usec=. See kernel-command-line(7) man page for details.
Lennart
--
Lennart Poettering, Berlin
u think of any other way to prevent this unwanted auto mounting
> besides masking the mount units?
systemd is downstream to udev. If udev doesn't process a block device
because of the taken BSD file lock on the main block device, then
systemd (and other downstreams of udev) won't g
hat this seems not perfect
> either.
I don#t follow? What do you mean by "systemd --user" is not
"-/bin/bash"?
Lennart
--
Lennart Poettering, Berlin
t it does, you
are *asking* for the rootfs to be replaced by a minimal tmpfs.
Lennart
--
Lennart Poettering, Berlin
use the assumption that reloads happen
under service control and that processes survive and the execution
contetx is not reset. It's explicitly supported to change the main PID
of the service (for example via sd_notify("MAINPID=")) during reloads
even, hence this should cover things reasonably nice for you.
Lennart
--
Lennart Poettering, Berlin
> line parameter at run time with the latest SHA deployment.
You can use systemd credentials for that, but would have to tell
ostree to look in one for that. systemd credentials can be locked
against the local TPM, and hence be authenticated that way.
Lennart
--
Lennart Poettering, Berlin
fi.extra.d/waldo.addon.efi
i.e. the ….extra.d/ subdir is where to place things.
Also make sure your systemd-stub is new enough. i.e. at least v254,
better newer.
Lennart
--
Lennart Poettering, Berlin
you need to do:
https://github.com/systemd/systemd/blob/main/man/ukify.xml#L674
Lennart
--
Lennart Poettering, Berlin
y code
(i.e. no real PE stub, and no .linux section). They can be
SecureBoot signed like any other PE binary, which is how they are
authenticated. You can drop them as "side-car" next to your UKI and
their contents will be combined/override the relevant sections in
the main UKI. This is already available in released systemd
versions. See sd-stub man page for details.
Lennart
--
Lennart Poettering, Berlin
On Fr, 04.10.24 15:03, Fredrik Hugosson (h...@axis.com) wrote:
> On 2024-09-11 14:28, Lennart Poettering wrote:
> > On Mi, 11.09.24 11:43, Fredrik Hugosson (fredrik.hugos...@axis.com) wrote:
> >
> > > Hi!
> > >
> > > I'm trying to use the
&
r memory is never paged out,
then mlockal() or something similar is the way to go. But of course
you need ot know what you are doing, and verify that locking your code
into memory won't cause memory pressure on other processes where you'd
rather not have it.
Lennart
--
Lennart Poettering, Berlin
hing I'd suggest people to avoid, and if they do it
anyway, then at least only for a short time (i.e. terminate once boot
is complete or so)
Lennart
--
Lennart Poettering, Berlin
gt; IIRC normally none of the initramfs services are expected to survive the
> transition.
Yes, that's the recommendation.
Lennart
--
Lennart Poettering, Berlin
e system to boot faster, then
you should figure out whre the bottleneck currently is.
Lennart
--
Lennart Poettering, Berlin
ou want encrypted configuration (i.e. an
encrypted root) which I am pretty sure is quite desirable, because
that means a copy of the pcrlock data must be propagated into the
initrd, if pcrlock on rootfs is desired.
Lennart
--
Lennart Poettering, Berlin
tsFor=" for .mount services or x-systemd.requires= in fstab?
Not currently, no. I think it would be OK to add though.
(But really, just get this in via the boot loader path, i.e. st-stub)
Lennart
--
Lennart Poettering, Berlin
. There's a fundamental
misunderstanding here how loaded systems need to be managed.
And if you then combine this with non-persistant journald, you are
artificially amplifying the problem you artificially created for
yourself, because you intentionally moved even more stuff that would
normally be backed by disk into unreclaimable memory.
Lennart
--
Lennart Poettering, Berlin
is really broken.
Frankly: there seems to multiple msiconfigs in place:
1. apparmor policy seems bogus to allow mounting but not remounting of /run/
2. if you want to manage resources of your container, let it do the
container manager, not the container, systemd will be happy.
3. you turned off swap?
4. you turned off persistent logging?
Lennart
--
Lennart Poettering, Berlin
this transaction. i.e. "systemd-analyze
log-level debug" and then reproduce the issue. and provide the
logs. This will then show the transactions generated and what is being
waited for.
Lennart
--
Lennart Poettering, Berlin
device mapper, do we need to also install LVM2 to make
> device mapping work? In that case do we need the whole LVM2 or only
> some subset? I have tried various combinations of these rules on my
> product but nothing seems to solve the issue.
No, you do not need LVM for LUKS. You do need libdevmapper (i.e. DM
userspace) for it though, because libcryptsetup needs that.
This is typically an integration issue with your distro. Please ping
them.
Lennart
--
Lennart Poettering, Berlin
imeoutSec=5min
JobTimeoutAction=reboot-force
And then there is the hw watchdog you can use via RuntimeWatchdogSec=
in /etc/systemd/system.conf, which can catch some more failures.
If you do all three you should have quite OK coverage.
Lennart
--
Lennart Poettering, Berlin
act immediately on that however, but with a
10s delay, as you rmight notice, to optimize for cases where people
quickly log out/log back in via ssh in scripts or suchlike).
This is supposed to be a security feature to some degree: not allowing
users to consume unbounded resources on a system without actually
being logged in.
If you actually want to allow this, then enable lingering, it's
precisely the usecase it is intended for.
Lennart
--
Lennart Poettering, Berlin
nit is not marked
> as failed
>
>
> What exactly does 'the remaining commands' mean? Other commands from
> subsequent ExecCondition= statements, or any subsequent ExecStartPre= lines?
> Or ExecStart= commands, too?
All of them.
Lennart
--
Lennart Poettering, Berlin
now any concept of connections. Instead each FIFO
is just a single ring buffer and any writer to it will end up writing
into the same ring buffer.
Lennart
--
Lennart Poettering, Berlin
e bi-weekly timers based on
calendar time.
See:
https://github.com/systemd/systemd/issues/6024
Someone even started working on this, but the work stalled:
https://github.com/systemd/systemd/pull/20711
Lennart
--
Lennart Poettering, Berlin
o. I think
neither of your suggestions here really bring much to the table in
that regard?
Btw, if you just want to start some timer every 5min then there's
little point in using calendar time. you could instead use monotonic
time, i.e. OnActiveSec=5min + OnUnitActiveSec=5min
Lennart
--
Lennart Poettering, Berlin
where we take the
current time, and then alter it in certain ways you specify. File a
github RFE issue about this.
Lennart
--
Lennart Poettering, Berlin
not getting?
(That said, there's a PR somewhere to add a set of symlinks which
allows referenceing additional partitions on the soon-to-be-root disk
via symlinks, but it hasn't been merged yet. With that you should be
able to do this, as long as you have something indicating the root
disk, i.e. ESP efi var or so)
Lennart
--
Lennart Poettering, Berlin
missing what you are looking for?
Lennart
--
Lennart Poettering, Berlin
d admins will quickly use "systemctl
> reboot -i" by default or make even an alias for this, which makes this
> idea/change void.
>
> Is this really wanted? Or is this behavior a bug and a normal user
> should be able to call systemctl reboot with run0/sudo without
>
On Do, 22.08.24 15:29, Gesh (g...@gesh.uni.cx) wrote:
> On Thu, Aug 22, 2024 at 02:01:02PM GMT, Lennart Poettering wrote:
> > On Do, 22.08.24 14:44, Gesh (g...@gesh.uni.cx) wrote:
> >
> > > On Thu, Aug 22, 2024 at 11:57:58AM GMT, Lennart Poettering wrote:
> > >
ny additional information would be helpful.
Always include relevant log output in reports like this. Always
include information about systemd version.
Otherwise, it's not an actionable report, sorry.
Lennart
--
Lennart Poettering, Berlin
, so I wonder will this be kept stable? And, does stdout and
> stderr have to be different connections?
They do not.
We can certainly make the protocol stable (or at least a subset of
it), i.e. prep a patch that adds it to the api guarantee document
linked elsewhere in the thread.
Lennart
install a key that shall be shared by a user into
the user keyring, not the session one.
Lennart
--
Lennart Poettering, Berlin
systemd-measure and ukify.py --measure will not work in
> yocto, at least without qemu and swtpm hacks. Am I right on this?
It should work fine in "offline" mode. It only talks to a TPM if you
invoke it with the "status" verb. But you wouldn't do that for signing.
Lennart
--
Lennart Poettering, Berlin
On Do, 22.08.24 14:44, Gesh (g...@gesh.uni.cx) wrote:
> On Thu, Aug 22, 2024 at 11:57:58AM GMT, Lennart Poettering wrote:
> > On Di, 13.08.24 01:28, Gesh (g...@gesh.uni.cx) wrote:
> >
> > > systemd.exec(5) reads:
> > > > In order to reference the path a
On Do, 22.08.24 14:44, Gesh (g...@gesh.uni.cx) wrote:
> On Thu, Aug 22, 2024 at 11:26:24AM GMT, Lennart Poettering wrote:
> > We only do env var expansion in ExecStart= and related line
> > types. Nothing else. (And I think it actually was a mistake there too.)
>
>
unit, the %d thing will be
resolved at that time, but $CREDENTIALS_DIRECTORY will not be.
Lennart
--
Lennart Poettering, Berlin
er, AFAIK, environment variables are supported in service units only,
> right?
We only do env var expansion in ExecStart= and related line
types. Nothing else. (And I think it actually was a mistake there too.)
Lennart
--
Lennart Poettering, Berlin
ntly and I'm not sure why.
You are probably racing against the usual rename logic via .link
devices if you rename via udev rules. You need to disable the policy
via a .link file.
Honestly, I'd really avoid mixing rename via udev rules and rename via
.link files. I'd stick to .link files for this, really.
Lennart
--
Lennart Poettering, Berlin
are just doing our
part in not making things worse for that.
Lennart
--
Lennart Poettering, Berlin
It just declares: "it's OK if the timer elapses this much
later", and not more. Which point in time systemd then picks to
actually trigger the timer is up to systemd, and it in fact currently
applies some boundaries to the time window, since delaying wakeups
indefinitely doesn't
d
>
> And changing the utest --ssh-authorized-keys= as root worked too.
>
> Did I miss something?
We currently do not allow to change that without privs. There's a PR
here to add what you are looking for:
https://github.com/systemd/systemd/pull/31153
Lennart
--
Lennart Poettering, Berlin
ar= multiple
times to define multiple trigger calendar times.
(If you really want multiple separate timer units, you can make them
actviate the same service btw, via the Unit= setting)
Lennart
--
Lennart Poettering, Berlin
On Mo, 08.07.24 15:57, Demi Marie Obenour (d...@invisiblethingslab.com) wrote:
> On Mon, Jul 08, 2024 at 01:16:56PM +0200, Lennart Poettering wrote:
> > On Do, 04.07.24 12:44, Demi Marie Obenour (d...@invisiblethingslab.com)
> > wrote:
> >
> > > > No, thes
-root and
> >> continue to run in
> >> the root file system, what are the potential consequences?
> >
> > You are running a processes from a different context, pinning files
> > from an emptied file system.
> >
> Is that OK if
> i. we keep all initrd files by initramfs without releasing them
> ii. keep all software version as the same between initrd and host
> iii. reopen some files like logs in case of OOM
>
> Otherwise, i am not sure if it is OK under some safty feature like SELinux,
> we will test them
> later.
Well, I can't tell you what is OK in your specific scenario, but I
personally find arrangements like that icky.
Lennart
--
Lennart Poettering, Berlin
PC, but the same applies as
above: it's a bit icky if you consume services provided by the OS, if
you are such a low-level daemon that must survive from initrd into
host.
In many ways: if you run like this you should consider yourself
conceptually closer to kernelspace than to userspace. And h
ming conection and its service
instance fail if the onwards connetion fails).
Lennart
--
Lennart Poettering, Berlin
t; the root file system, what are the potential consequences?
You are running a processes from a different context, pinning files
from an emptied files.
Generally, don't do this, unless you know exactly what you are
doing. There are usually uch better approaches.
Lennart
--
Lennart Poettering, Berlin
for help on this.
Lennart
--
Lennart Poettering, Berlin
ail" disables the ordering, it means "if this mount is there
or not doesnt really matter for anything else". Both at startup and at
shutdown, and all the time inbetween
Lennart
--
Lennart Poettering, Berlin
on the filesystem. Also, I
> was able to reboot the system by switching to a text console and
> pressing ctrl-alt-delete.
>
> Any idea what happened here? I'm not sure if this is a systemd bug, or
> if I missed something in my packaging script (ebuild).
See this discussion:
https://github.com/systemd/systemd/pull/33279
Lennart
--
Lennart Poettering, Berlin
eavy.
>
> What would be the correct way (less heavy) to get logs from journald into
> rsyslog on EL8?
That sounds like a question for the rsyslog community. This here is a
systemd mailing list.
Lennart
--
Lennart Poettering, Berlin
hat can be acquired from a specific DNS
server that gives us information about the query. But if there are multiple
DNS servers that give us info, then we make a choice and only return
one reply.
> Furthermore, does systemd provide the configuration to switch this behavior
> ?
There's is
On Mo, 01.07.24 12:39, Lennart Poettering (lenn...@poettering.net) wrote:
> > Hmm, so we typically don't sync on systemd-logind for user
> > stuff/sessions if we can avoid that, since the root user is a user
> > that shall be allowed logging in too, and typically much e
On Mo, 01.07.24 12:36, Lennart Poettering (lenn...@poettering.net) wrote:
> On So, 30.06.24 22:48, Vladimir Kudrya (vladimir-...@yandex.ru) wrote:
>
> > Hello everyone!
> >
> > I'm noticing an issue on my system (Debian sid) on shutdown. Wlroots
> > compos
t said, given that user@.service is pretty much a logind concept, I
guess we should have at least that dep in place.
Can you please file an issue (or even better a PR), that adds the dep on
logind to user@.service)? That'd be great!
Thank you,
Lennart
--
Lennart Poettering, Berlin
this right now.
Lennart
--
Lennart Poettering, Berlin
; should be silenced but I do understand that it could be interpreted as
> the service will still start if errors were found opening the file.
Yes, this is a bug I guess. Can you please file an issue on github, so
that we keep track of this, and don't forget to fix this?
Even better: send a PR that fixes this.
Lennart
--
Lennart Poettering, Berlin
On Fr, 14.06.24 10:06, Mikhail Morfikov (mmorfi...@gmail.com) wrote:
> > --
> > Lennart Poettering, Berlin
>
> I don't need any warranty, I need a way to make this work.
Yeah, but this is the wrong forum to ask for help then. What you are
doing is strictly against how
anaged processes
and moves them elsewhere, it's simply not supported. Sorry, you voided
your warranty.
Lennart
--
Lennart Poettering, Berlin
this all means, but I have the suspicion you
actually want a generator, i.e. a plugin to systemd that adds some
deps depending on external configuration files.
i.e. implement this stuff:
https://www.freedesktop.org/software/systemd/man/latest/systemd.generator.html
Lennart
--
Lennart Poettering, Berlin
0
>
> systemd configuration:
>
> [Match]
> Name=eth0
> KernelCommandLine=!nfsroot
>
> [Network]
> DHCP=ipv4
> LinkLocalAddressing=ipv4
>
> [DHCP]
> ClientIdentifier=mac
> RouteMetric=10
It should suffice adding the following to your .network file:
[Route]
Destination=255.255.255.255/32
Lennart
--
Lennart Poettering, Berlin
e that services can add the followng to their deps:
Wants=modprobe@foobar.service
After=modprobe@foobar.service
To ensure the kmod "foobar" is definitely loaded before the service
begins execution.
Lennart
--
Lennart Poettering, Berlin
efine
various services inside the container, then you can properly
synchronize on them collectively to finish start-up by waiting for
systemd-nspawn@.service to start up. (if you add --notify=ready=yes
that is).
Lennart
--
Lennart Poettering, Berlin
1 - 100 of 1054 matches
Mail list logo
