> amplification.
Somehow I think you are missing what I am asking for: some data that
actually shows your optimization is 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 t
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
we write
them.
It would be great 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
ation: we could defrag only if we notice the fragmentation 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 apparentl
can 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
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*
> > > dev
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
art of 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
nd such). 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
_
ything it doesn'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
___
s that it didn't get a
socket passed 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
to be 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
│ └─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
/var?
Is 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
--
Lenn
ec failed!
> 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
ct/udisks/pull/838#issuecomment-768372627
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 fro
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
be written 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
I works just fine.
Right, sorry. POLLPRI 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
also 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&
;s little 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.
andle the two
> options (root and non-root) cleanly with unit files.
option 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
ossible 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
d to, when 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-dev
s://fedoraproject.org/wiki/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
_
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
tem 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 sys
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
improvement. 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
___
that. 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
ic (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
ther 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.
et second.target
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
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
d?
This requires libiptc 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.fre
yboard is connected 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
___
the admin is going 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
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
_
; Is this a good udev rule or even valid 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 devi
pagate this back 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
f that'd would 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
syste
s things a lot 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 yo
e 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, Be
InvocationID
The 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
that the
> FILE_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
hed; active 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
this on github?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
o it 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, in what way?
There's no 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
--
Lenna
ts to keep 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
Looks like a bug in 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
--
Lenna
; line. 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
ve
one, so that we can translate users 1:1 without loss.
Or in other words: this part is still work in progress...
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
e -b
> Is this the correct command? This seems to be not documented.
We have nothing better right now. i figure we should add "pstorectl"
or so, matching "coredumpctl" and "journalctl".
Please file an RFE issue on github
Maybe we
need to extend BindREadOnlyPaths= so that it takes a bunch of files as
bind mount sources and uses the first one that exists or so. It
wouldn#t be perfect though, given that this would handle only cases
where resolved is not installed, not the ones where it is installed
but disabled.
Ca
I couldn't be bothered to
revert to that. I have the suspicion Docker is generally considered
legacy software at this point, and the reimplementations (podman, …)
are probably the better replacements to focus on.
Lennart
--
Lennart Poettering, Berlin
___
be issue #3700?)
I think some people noticed this so far, but noone actually cared
enough to do anything about it. I guess few people were actually
missing it.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesk
s with. If the kernel already
exposes this, we can certainly expose this as dbus property too. Plese
file an RFE issue on github about that if so.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
are using.
Are you using this in --user or --system mode? (Note that a bunch of
sandboxing settings are only available for --system).
Have you checked the logs? In particular after enabling debug logging
(systemd-analyze log-level debug).
Lennart
--
Lennart Poettering, Berlin
unit into
multi-user.target. This then means that the service will be started at
boot, but before it can actually be activated, the tap0 device has to
show up. Key here is that the Wants= pulls the .device unit into the
job queue, and thus can be waited on.
Lennart
-
something fnmatch(3) nor glob(3) support,
hence tmpfiles.d/ doesn't either.
I this is something worth supporting it probably needs support in
glibc first. I'd rather not like to deviate from glibc behaviour here.
Lennart
--
Lennart Poettering, Berlin
__
loops we use that
allows to address certain forms of starvation. It's not used for
journald yet. Please file a bug on github about this if current
journald versions still show this behaviour for you, and we can look
in making use of this to make the sync stuff eventually complete even
if journ
ynamic updates"? What do you mean by that? DNS updates?
If you mean DNS updates, we do not support that currently, and noone
is working on that.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
t file to
make the kernel log all system calls that are done by a service.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
that.
Yes, I fully agree. This is messy and generally not portable. If you
care about portability maybe go the RLIMIT_NOFILE way, which is of
course terrible inefficient, but that's the price you have to pay for
portability I guess.
Anyway, I don't think mentioning /dev/fd/ is generall
ve everyone use either ed25519 or PKCS#7 for this.
Looking forward to your patches ;-)
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
is what I
am asking for here: if anyone actually cares about gnutls/gcrypt
support and what the reasons for them are.
I want something stronger than "I like" and "I dislike". I want to
hear technical, or legal reasons. Not "taste".
Lennart
--
Lennart Poettering
ed. So far we were
counting on this to resolve the licensing situation around crypto
libraries. Due to the Debian change I figure we can speed up things
now, though.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
system
about udev rules
> processing performance.
Replied there now.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
be really curious if a iouring based reader could outperform the
mmap based ones. I have the suspicion that yes, since paging in stuff
is slow, and doesn't really allow for reordering.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel m
: Failed to start The Apache HTTP Server.
Maybe there's more info the apache logs?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
okking the usecase. Please elaborate what you are trying to
do.
"systemctl daemon-reexec"'s usecase is pretty simple so far: update
systemd from one version to the next, and thus make sure to run the
new version of the code.
"systemctl switch-root"'s usecase is pret
criteria or is
> it based on experience?
We had to pick something. And 16M should be more than enough, but
generally available. So far noone complained, we got no bug reports
that it is too much or too little.
Lennart
--
Lennart Poettering, Berlin
__
s this is documented in detail.
Please contact the kubernetes folks and ask them to follow the
documented interfaces.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
ols location of
> configuration files? For all I can tell such variable does not exist.
Whch configuration files precisely?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
s is how systemd exposes its state. If you don't want to use that,
you won't get the state information.
Sorry,
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
b vs /usr/lib). Not really user friendly and not
> possible to do with simple command.
Fetching files from /lib or /usr/lib? What precisely do you mean?
For such build-time params we expose systemd.pc as pkg-config file,
which has various paths as variables.
Lenn
shutdown
> that we've had since the sysvinit? And also when isolating I suppose.
Are you running systemd? If so, please get rid of "killproc". It will
interfere with systemd's service management.
Lennart
--
Lennart Poettering, Berlin
__
not
sure how this would related to iwd.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
nd systemd decides
> not to restart it. iirc, there was a list of pids that would NOT be
> killed at that stage... it appears that the pid for ssh.service isn't
> getting placed in that list. How did that work again?
What is "killprocs"?
Is something killing services
d just disable lingering for the users in question
> > before running the dnf upgrade command? Not ideal but it's a workaround
> > as you asked!
>
>
> Yep I guessed that would be the only thing to do.
>
> How do I get a list of all users with linger enabled?
Look
they generalize parts of
the stack in include files, but they all do it differently, hence we
can't really carry that upstream.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
log-level debug" to turn on debug
logging in PID 1 any time.
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
e-linger").
So what sessions are those? Or do you have lingering enabled?
Do you maybe have cronjobs for the user installed?
Lennart
--
Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
On Do, 29.10.20 17:55, Marcin Kocur (marcin2...@gmail.com) wrote:
> W dniu 26.10.2020 o 11:19, Lennart Poettering pisze:
> > > Is this intended? Should I report bug to systemd or sane? The scanner is
> > > connected to my PC all the time.
> > sane.
> >
> >
'm not sure about even that.
That is the correct way: check for the one "negative" action type
(i.e. "remove"), and run your rules on all the other action types,
i.e. on all "positive" action types. (Where "p
even without the
kernel bind/unbind mess the sane rules already were broken)
Also see the NEWS note on the upcoming systemd version 247:
https://github.com/systemd/systemd/blob/master/NEWS#L5
> Is this intended? Should I report bug to systemd or sane? The scanner is
> con
701 - 800 of 9693 matches
Mail list logo
