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
disk as before,
simply to make things simple so that people can optionally do both:
store the verification key offline *and* in TPM, and if the TPM is
lost they can still use the verification key they stored elsewhere)
Lennart
--
Lennart Poettering, Berlin
__
_users(), since that spawns off a child process which then
> goes and writes to /proc/$parent_pid/, but I guess children can ptrace
> their parents? At least it seemed to work when I just tested it.
On traditional Linux any ptracable means "uid matches". With yama lsm
parents can ptrce t
mething I don't like. Semantically it's only
marginally better than just creating a new file from scratch.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
o not
> defragment unless it's SCSI/SATA/SAS and it reports it's rotational.
btrfs itelf has a knob declaring whether something is ssd or not ssd,
configurable via the mount option. Of course, one would bind any
higher level logic to that same thing, and thus make it btrfs' own
problem, or the
ut a
really low-level system thing, hence you might get warnings about
this.
You can of course mask sys-fs-fuse-connections.mount too.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
worth it.
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
timized for access times, not for minimal iops.
I'd be totally open to revisit this all, and take iops more into
account, but again, we'd need a bit of profiling that compares access
times, iops, and stuff with and without this, on rotating and ssd.
Lennart
--
Lennart
that other mail could have a special value besides yes/no
of "ssd" or so, where we'd use btrfs own understanding if it's backed
by ssd or rotating media, as controlled with the ssd/nossd mount
option. (though ideally we'd have a better way to query it that to
parse out the mount
On Fr, 05.02.21 17:44, Chris Murphy (li...@colorremedies.com) wrote:
> On Fri, Feb 5, 2021 at 3:55 PM Lennart Poettering
> wrote:
> >
> > On Fr, 05.02.21 20:58, Maksim Fomin (ma...@fomin.one) wrote:
> >
> > > > You know, we issue the btrfs ioctl, under the
ia. Apparently noone
who cares about this apparently wants to do such research though, and
hence I remain deeply unimpressed. Let's not try to do such
optimizations without any data that actually shows it betters things.
Lennart
--
Lennart Poettering, Berlin
___
On Fr, 05.02.21 16:16, Phillip Susi (ph...@thesusis.net) wrote:
>
> Lennart Poettering writes:
>
> > Nope. We always interleave stuff. We currently open all journal files
> > in parallel. The system one and the per-user ones, the current ones
> > and the archived ones.
t a new file before the old one is full?
Various reasons: user asked for rotation or vacuuming. because
abnormal shutdown. becase time change (we want individual files to be
montonically ordered), …
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Fr, 05.02.21 16:06, Dave Howorth (syst...@howorth.org.uk) wrote:
> On Fri, 5 Feb 2021 16:23:02 +0100
> Lennart Poettering wrote:
> > I don't think that makes much sense: we rotate and start new files for
> > a multitude of reasons, such as size overrun, time jumps, abn
On Fr, 05.02.21 10:24, Phillip Susi (ph...@thesusis.net) wrote:
>
> Lennart Poettering writes:
>
> > You are focussing only on the one-time iops generated during archival,
> > and are ignoring the extra latency during access that fragmented files
> > cost. Show me tha
On Do, 04.02.21 12:51, Chris Murphy (li...@colorremedies.com) wrote:
> On Thu, Feb 4, 2021 at 6:49 AM Lennart Poettering
> wrote:
>
> > You want to optimize write pattersn I understand, i.e. minimize
> > iops. Hence start with profiling iops, i.e. what defrag actually cost
On Mi, 03.02.21 23:11, Chris Murphy (li...@colorremedies.com) wrote:
> On Wed, Feb 3, 2021 at 9:46 AM Lennart Poettering
> wrote:
> >
> > Performance is terrible if cow is used on journal files while we write
> > them.
>
> I've done it for a year on NVMe. The
s worth it: i.e. that leaving the
files fragment doesn't hurt access to the journal badly, and that the
number of iops is substantially lowered at the same time.
The thing is that we tend to have few active files and many archived
files, and since we interleave stuff our acces
On Mi, 03.02.21 22:32, Chris Murphy (li...@colorremedies.com) wrote:
> On Thu, Jan 28, 2021 at 7:18 AM Lennart Poettering
> wrote:
> >
> > On Mi, 27.01.21 17:19, Chris Murphy (li...@colorremedies.com) wrote:
> >
> > > Is it possible for a udev rule to have a tim
eat if we could turn datacow back on once the files are
archived, and then take benefit of compression/checksumming and
stuff. not sure if there's any sane API for that in btrfs besides
rewriting the whole file, though. Anyone knows?
Just dropping FS_NOCOW_FL on the existing file doesn#t work iirc, it
can
entation is
really too high.
But quite frankly, this sounds polishing things after the horse
already left the stable: if you want to optimize iops, then don't use
btrfs. If you bought into btrfs, then apparently you are OK with the
extra iops it generates, hence al
certainly still optimize stuff (i.e. "systemctl daemon-reload" is
expensive), but things to my knowledge having a few K of units should
be totally Ok. (But then again I don't run things like that myself, my
knowledge is purely based on feedback, or the recent lack thereof)
Lennart
--
Lennart
On Di, 02.02.21 11:46, Alan Perry (al...@snowmoose.com) wrote:
>
> On 2/2/21 1:55 AM, Lennart Poettering wrote:
> > On Mo, 01.02.21 16:36, Alan Perry (al...@snowmoose.com) wrote:
> > > Hi, Per the udev rules, the blkid builtin is run on mmcblk*boot*
> > >
On Di, 02.02.21 22:50, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> 02.02.2021 17:59, Lennart Poettering пишет:
> >
> > Note that Requires= in almost all cases should be combined with an
> > order dep of After= onto the same unit.
>
> Years ago I asked for exampl
f the
usual workflow.
Note that Requires= in almost all cases should be combined with an
order dep of After= onto the same unit. If the unit above doesn't do
that it's almost certainly broken.
Lennart
--
Lennart Poettering, Berlin
___
). It will not show you anything that is from the
unit file that is masked. Which is kinda the point of masking: hiding
away the original unit file, and making sure systemd (or systemctl
cat) won't use them for anything.
Lennart
--
Lennart Poettering, Berlin
___
oesn't find anything, so not much bad
happened?
If this matters to you, and it's really clear that there is unlikely
anything blkid-recognizable on it, then by all means, please send a
PR!
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel ma
d in that it needs — just creates the socket itself as a
fallback...
It's generally a good idea for services to have Requires= + After= on
the sockets that actviate it, to make sure that the sockets are always
started before the service itself, and the situation you are seeing
can
known
> up-front, before the first install, but be somehow tied to the machine's
> hardware. So that's what we did.
Write it from the initrd.
You can also set it via a kernel command line option. There was also
the idea of initializing it from an env var passed t
│ └─854319 (sd-pam)
> └─syncthing.service
>
> exists and gets auto started by "systemd" without any asking really.
> This is really very bad, no?
> What am I missing here?
systemd at the very least will spawn your per-user dbus daemon, which
is needs to be avail
it possible you are playing some weird games with your machine ID
or boot ID?
journalctl by default only shows messages matching either the current machine ID
or the current boot ID. (the latter since the initrd will have a
different machine ID than the host)
Lennart
--
Lennart Poette
Rebooting.
> [ 1670.211839] kvm: exiting hardware virtualization
> [ 1671.457978] reboot: Restarting system
> [ 1671.461965] reboot: machine restart
> ~~~
The logs above suggest dracut does kexec in your case, not systemd?
Lennart
--
Lennart Poe
68372627
systemd/udev has no clue about btrfs superblocks. It only talks to
libblkid, and to the kernel. It doesn't parase anything on its own. If
you want this property to be attached to the udev device, please
request this from the libblkid maintainer, since we basically impo
On Do, 28.01.21 10:08, Martin Wilck (mwi...@suse.com) wrote:
> Hi Lennart,
>
> thanks again.
>
> On Wed, 2021-01-27 at 23:56 +0100, Lennart Poettering wrote:
> > On Mi, 27.01.21 21:51, Martin Wilck (mwi...@suse.com) wrote:
> >
> > if you want the initrd envir
correctly to /var but journalctl appears to read from
> /run.
journalctl reads from both dirs, always. What makes you think it reads
from the wrong dir only?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
syste
OLLPRI is the right API. inotify is used by cgroupfs
for similar notifications, and I mixed that up. for
/proc/self/mountinfo POLLPRI is the right choice.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Di, 26.01.21 13:30, Martin Wilck (mwi...@suse.com) wrote:
> On Tue, 2021-01-26 at 11:30 +0100, Lennart Poettering wrote:
> >
> > > Imagine two parallel instances of systemd-udevd (IMO there are
> > > reasons
> > > to handle it like a "root storage dae
fork our stuff, or just use our
stuff, it's Free Software after all.
Either way, please contact the maintainers of your distro and
"elogind" for help in general, this is the wrong forum for such
questions.
Lennart
--
Lennart Poettering, Berlin
___
On Di, 26.01.21 01:19, Martin Wilck (mwi...@suse.com) wrote:
> On Mon, 2021-01-25 at 18:33 +0100, Lennart Poettering wrote:
> >
> > Consider using IgnoreOnIsolate=.
> >
>
> I fail to make this work. Installed this to the initrd (note the
> ExecStop "command&
le one can do
> > about that.
>
> Why would it be so bad? I would actually prefer a single instance for
> most subsystems. But maybe I'm missing something.
Well, because you can't update things on-the-fly then, you cannot
reexec since everything is backed by initrd. You cannot restart
one: have two unit files? i.e. two instances of the subsystem,
one managing the root storage, and one the rest.
option two: if you cannot have multiple instances of your subsystem,
then the only option is to make the initrd version manage
everything. But of course, that sucks, but there's little
t; Is it possible to somehow remove the "sleep 1"?
>
> For details see:
> https://github.com/eriksjolund/user-systemd-service-actions-workflow
https://github.com/systemd/systemd/pull/17967
Lennart
--
Lennart Poettering, Berlin
___
s
hen our
builds kinda required it). If this is important to you I'd suggest
open a feature about it, any ping @mrc0mmand about it (he's our CI
go-to guy).
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
i/LTOByDefault
(I think Suse is even further ahead on this)
So, it's up to you where you want to take things, but I sense the
future is "yes to LTO" and not "no to LTO".
Lennart
--
Lennart Poettering, Berlin
___
systemd-dev
reference clock. This is a much stronger
option, but means the boot process will be delayed based on network
availability.
Coincidentally we documented this recently in more detail, see git
commit b149d230ea23c14bac2dfe79c47e58782623200f which also will be in
the nex
system service, if this is a
> > kiosk system, maybe you can use it instead.
>
> Thank you for the reply. There are security risks running pulseaudio
> in system mode[1].
Well, but what you are doing is worse, you reverse the layers of the
stack...
If you want a system s
sr/bin/killall --user kodi --exact --wait kodi-gbm
> Restart=on-abort
> StandardInput=tty
> StandardOutput=journal
>
> [Install]
> Alias=display-manager.service
This is not a supported setup. System services should not be clients
to per-user services. The opposite
ne-id
Most likely something has that file open still.
Maybe turn on debug logging ("systemd-analyze log-level debug") and
check logs on next boot, and check what the precise error was.
Lennart
--
Lennart Poettering, Berlin
___
systemd-deve
nt. Everyhing can. But
humm, the docs don't need "fixing", they aren't broken. They suggest
exactly what to do.
Happy to review/merge a patch that improves things, but I think the
brokeness you two imply is just not there.
Lennart
--
Lennart Poettering, Berlin
___
Hence contact your downstream distro about this
instead, they can help you.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
istic (or may be it is but then it is always "wrong" for
> > your purpose :) ), so in your case job for Second runs too late, when
> > Third is already started and there is no pending job to fail.
>
> Ah. Thanks for the explanation. Adding
>
a
unit is in the job queue or it isn't, the distinction between jobs and
units is very technical, and if you ask me not too relevant for
readers.
Hence, I don't agree with your criticism. Insisting on the existance
of the job concept to explain ordering deps doesn't help.
Lennart
--
Lennar
t
Add "After=first.target second.target" here as well. Ordering and
requirement deps are orthogonal in systemd. See documentation.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
ted? i.e. the activation of service 1 and 2 need to happen first
and they are the trigger for service 3, but besides that noone ever
asks for service 3?
If so, it appears to me a Wants= dep from services 1 and 2 on 3 would
make sense, plus a Requisite= dep in the other direction.
Lennart
--
Lennart Poettering
t; issues.
Have you read the docs about ExecStop=?
Note that ExecStop= is only run once the service managed to complete
initializatio at least once, i.e. ExecStart= complete fully so that
the service is up.
Maybe turn on debug logging (with "systemd-analyze log-level debug")
to get a clos
way, I'd recommend you to try it out and see if it fixes your
CI problems? That's the only way you can now for sure...
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
can't restart libvirtd-tls.socket when libvirtd.service is
> running: I first have to stop libvirtd.service.
This really depends on how the libvirt object put together its unit
files, and cannot be answered out of thin air.
Not sure what "configured TLS later" is even suppo
development headers to be installed during
build.
Also note that your kernel needs to enable iptables (not nftables) for
this to work.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://list
cted to the AT keyboard
controller, and yours is connected to a serial port, right? So the
udev rules should be fixed to match against the former only.
Anyway, please file a PR/issue on github about this, and continue the
discussion there.
Lennart
--
Lennart Poettering, Berlin
__
oing to customize it anyway then maybe /etc/fstab should
> be that config file? Instead of gpt-generator, why not make udev create a
> "/dev/disk/by-purpose/efi" symlink and use that as the fstab device...
> Would that technically work?
That is in fact a great
ier boot. It's what the systemd-udev-trigger.service unit is
> > doing.
> >
> > Triggering means all udev rules are run again.
> >
> > Lennart
> >
> > --
> > Lennart Poettering, Berlin
> >
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
this be configured?
No, it cannot.
But you can use $EXIT_CODE, $EXIT_STATUS and $SERVICE_RESULT env vars
in ExecStop= that tell you what happened. Thus you can write a script
wrapping your stop command that determines what to do.
Further details on these env vars are on systemd.
tically at boot, in order to
"coldplug" devices that have been found by the kernel already during
earlier boot. It's what the systemd-udev-trigger.service unit is
doing.
Triggering means all udev rules are run again.
Lennart
--
Lennart Poettering, Berlin
__
alid or is using `..` something that
> shouldn't be possible?
No, that's OK, we do that from time to time too. Of course, I'd avoid
it unless there's no better way to match the device. i.e. if you can
recognize a device by its own properties it's typically much better
than rec
k to us if this
is still a problem in current versions.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
work for you. (or even better, hack it up,
provide a patch).
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Fr, 27.11.20 23:18, Gena Makhomed (g...@csdoc.com) wrote:
> How to fix or workaround this problem with default route?
Have you looked at networkd's logs?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-de
worse btw, since the write pattern we employ
that are very unfriendly to CoW file systems (i.e. we do random
writes; CoW file systems can't really handle anything that aren't
linear writes). In upstream defaults we thus turn off cow for these
files, not sure if your distro undoes that tho
used, others are not. It
could certainly use some love to make it round again though.
It's too good to remove I'd say. I'd rather see the thing fixed (work
on that would be minor I guess), and a test added so that it doesn't
regress again.
Lennart
--
Lennart Poettering, Berlin
invocation is randomly generated whenever a new start cycle begins.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Di, 10.11.20 12:47, Arian Van Putten (ar...@wire.com) wrote:
> I think what you might want is `Type=exec` instead of `Type=simple` in your
> unit file. It was recently added to systemd.
Recently? That was in 2018! 2 Years ago!
Lennart
--
Lennart Poettering,
tc/fstab i#d recommend:
1. in your initrd fsck the root fs first
2. then mount it in the initrd, and mount it writable right away
3. remove /etc/fstab
4. systemd-remount-fs will notice that the file is absent, and not do
anything. (You could even mask the service if you like)
Lennart
--
Lennar
ILE_SIZE_INCREASE define in journal-file be runtime configurable,
> and/or clamped by the existing size limits.
Yeah, making this value configurable certainly makes sense. Please
file an RFE issue on github.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
tive files will stay around. This
means that, in effect, there might still be more journal files
around in total than this limit after a vacuuming operation is
complete. This setting defaults to 100.
Lennart
--
Lennart Poettering, Berlin
__
of it there?
(We probably should convert that text into markdown anyway, and
maintain it as part of the git repo).
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
on github?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
probably might not matter too much there to fix the
action guards. It would still be much prettier, more correct if they'd
use ACTION=="remove" though.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
o nice way. Depends on the subsystem.
You could start by going through the udev rules files of your
distros. 95% of the rules files that use a guard different from
ACTION!="remove" are possibly broken, or at least ugly (and not future
proof).
Lennart
--
Lennart Poettering, Berlin
_
a ref?
Please provide a minimal example where the issue is supposed to show.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
your OS? /var should be writable at the point the
rfkill service is started. i.e. it comes with an ordering dep on
After=systemd-remount-fs.service and a line
RequiresMountsFor=/var/lib/systemd/rfkill which make sure /var/ must
be mounted and writable by then.
Lennart
--
Lennart Poettering, Berli
e. If that's not the case
for you, this would probably be a bug. Please file an issue on github
about this then.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
s0
>
> WLANInterfaceType="mesh-point"
>
> It doesn't want to match even though wlp6s0 is currently connected to my
> mesh.
Give this looks like a bug, please file an issue on github about this please.
Lennart
--
Lennart Poettering, Berlin
_
601 - 700 of 8651 matches
Mail list logo