he device times out before the "last
resort" timer starts it (and before the last devices appear).
Martin
--
Dr. Martin Wilck <mwi...@suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
of
systemd's service enablement logic).
Regards
Martin
--
Dr. Martin Wilck <mwi...@suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
systemd-devel mailing list
systemd-d
work, even if it's called right
after PID 1 is started. I'm pretty certain that that wasn't the case
for me. My client was running from an udev rule and thus not
unprivileged. That should be considered a bug, then?
My tests were done with systemd 228 a while ago.
Martin
--
Dr. Martin Wilck <m
or the automount unit to be ordered before
> (and,
> if not noauto, be pulled in by) local-fs.target, even for network
> filesystems?
Please don't. We don't need additional failure points for local-
fs.target.
Martin
--
Dr. Martin Wilck <mwi...@suse.com>, Tel. +49 (0)911 74053 2
r
onboard LAN, but the PCI device number (sic!) is wrong.
--
Dr. Martin Wilck <mwi...@suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
systemd-devel mai
ceTimeoutStartSec= setting might be OK to add...
Wouldn't this be, at least in part, be covered by using the newly
introduced "JobRunningTimeoutSec" for devices?
https://github.com/systemd/systemd/commit/db7076bf78bd8e466ae927b6d3ddf
64190c8d299
https://github.com/systemd/systemd/pull/5164
Martin
--
Dr.
em PCI slot numbers to
bus-device-function tuples. Obviously, the physical slot a controller
is connected to is less likely to change than the bus-device-function
number, so exposing it might make a lot of sense.
All of this requires support on the BIOS/Firmware side - without that,
none of the "p
On Sat, 2018-09-08 at 19:55 +0200, Michael Hirmke wrote:
> Hi *,
>
> [...]
> > > - The partition has to be mounted on boot.
> > > - It has to be unmounted before the nightly copy job, so that an
> > > fsck
> > > can be performed.
> > > - After that it has to be mounted read only, so that during
On Mon, 2018-09-10 at 09:55 +0200, Michael Hirmke wrote:
>
> > >
> > > > (I would just use `umount /var/backup`, however.)
> > >
> > > Can't do that as long as the mount unit is under systemd control.
> > > A few seconds later systemd remounts it on its own.
> > >
> > "noauto" mount option?
>
On Thu, 2019-02-07 at 14:39 +, Sven Wiltink wrote:
> Hey all,
>
> We've been running into the issue where lblk -O outputs the wwn
> instead of the serial for scsi devices. After some debugging I've
> come to the conclusing that /lib/udev/scsi_id is the underlying
> cause. It outputs the wwn
On Thu, 2019-02-07 at 19:13 +0100, suscrici...@gmail.com wrote:
> El Thu, 7 Feb 2019 11:18:40 +0100
>
> There's been a reply in Arch Linux forums and at least I can apply
> some
> contingency measures. If it happens again I will provide more info
> following your advice.
The log shows clearly
On Thu, 2019-01-31 at 14:46 +0100, Ziemowit Podwysocki wrote:
>
> ACTION=="remove", SUBSYSTEM=="usb", DRIVER=="usb",
> ATTRS{idVendor}=="1244", ATTRS{idProduct}=="206d", RUN+="/bin/touch
> /home/user/udev/%k"
>
> This one suppose to create file named after "KERNEL" param of the
> device.
On Mon, 2019-02-04 at 13:19 +0100, Lennart Poettering wrote:
>
> reading sysfs attrs is problematics from "remove" rules, as the sysfs
> device is likely to have vanished by then, as rules are executed
> asynchronously to the events they are run for.
>
> udev will import the udev db from the
We are facing problems during udev coldplug on certain very big systems
(read: > 1000 CPUs, several TiB RAM). Basically, the systems get
totally unresponsive immediately after coldplug starts, and remain so
for minutes, causing uevents to time out. Attempts to track it down
have shown that access
On Tue, 2019-05-28 at 11:43 +0200, Josef Moellers wrote:
> Hi,
>
> We just had an issue with a partner who tried to filter out the
> "open"
> system call:
>
> . This may, in general, not be a very clever idea because how is one
> to
> load a shared library to start with, but this example has
Hi
I'm experimenting with systemd's root storage daemon concept
(https://systemd.io/ROOT_STORAGE_DAEMONS/).
I'm starting my daemon from a service unit in the initrd, and
I set argv[0][0] to '@', as suggested in the text.
So far so good, the daemon isn't killed.
But a lot more is necessary to
On Mon, 2021-01-25 at 18:33 +0100, Lennart Poettering wrote:
> On Sa, 23.01.21 02:44, Martin Wilck (mwi...@suse.com) wrote:
>
> > Hi
> >
> > I'm experimenting with systemd's root storage daemon concept
> > (https://systemd.io/ROOT_STORAGE_DAEMONS/).
> >
>
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"):
[Unit]
Description=NVMe Event Monitor for Automatical Subsystem Connection
Documentation=man:nvme-monitor(1)
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 daemon" in some distant future).
>
> Hmm, wa? naahh.. udev is about dicovery it should not be required to
> maintain
On Tue, 2021-01-26 at 11:33 +0100, Lennart Poettering wrote:
>
> >
> > [Unit]
> > Description=NVMe Event Monitor for Automatical Subsystem Connection
> > Documentation=man:nvme-monitor(1)
> > DefaultDependencies=false
> > Conflicts=shutdown.target
> > Requires=systemd-udevd-kernel.socket
> >
s to react to the notification immediately, e.g. by
blocking IO to the device,
3) userspace tooling such as udev or multipathd need to figure out how
to how to deal with the situation cleanly, and eventually unblock it.
Wrt 1), we can only hope that it's the case. But 2) and 3) need work,
afaics.
know
that WWID changes can happen with certain storage arrays. See
https://listman.redhat.com/archives/dm-devel/2021-February/msg00116.html
and follow-ups, for example.
Regards,
Martin
--
Dr. Martin Wilck , Tel. +49 (0)911 74053 2107
SUSE Software Solutions Germany GmbH
HRB 36809, AG Nür
the
device. Thus if a user changes LUN assignments on a storage system,
it can happen that a direct INQUIRY returns a different WWID as in
sysfs, which is fatal. If we plan to rely more on sysfs for device
identification in the future, the problem gets worse.
I wonder if there's a chance that future ke
impractical for user space.
> But taking a step back: Other than "it's not what userland currently
> does", what specifically is the problem with designator_prio()? We've
> picked the priority list once and for all. If we promise never to
> change
> it, what is the issue?
If the pri
On Tue, 2021-04-27 at 16:41 -0400, Ewan D. Milne wrote:
> On Tue, 2021-04-27 at 20:33 +0000, Martin Wilck wrote:
> > On Tue, 2021-04-27 at 16:14 -0400, Ewan D. Milne wrote:
> > >
> > > There's no way to do that, in principle. Because there could be
> > > other
en trigger aborted commands
> or UA's as well which will be picked up by the kernel/respected
> drivers.
Thanks a lot. I'm not quite certain which of these paragraphs would
apply to the situation I had in mind (administrator remapping an
existing LUN on a storage array to a different volume). That s
On Tue, 2021-04-27 at 16:14 -0400, Ewan D. Milne wrote:
> On Mon, 2021-04-26 at 13:16 +0000, Martin Wilck wrote:
> > On Mon, 2021-04-26 at 13:14 +0200, Ulrich Windl wrote:
> > > > >
> > > >
> > > > While we're at it, I'd lik
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 environment to fully continue to exist,
I don't. I just need /sys and /dev (and perhaps /proc and
ttps://github.com/systemd/systemd/blob/main/src/udev/scsi_id/scsi_serial.c
There's a "fallback" logic in multipath-tools in case udev doesn't
provide a WWID:
https://github.com/opensvc/multipath-tools/blob/a41a61e8482def33e3ca8c9e3639ad2c37611551/libmultipath/discovery.c#L1040
--
Dr. Mar
an important
user space consumer of WWIDs (multipathd), I doubt that this would
improve matters for us. We'd be happy if the kernel could just pick the
"best" designator for us. But I understand that the kernel can't
guarantee a good choice (user space can't either).
What is your idea how
On Tue, 2021-11-30 at 14:11 +0100, Mohamed Ali Fodha wrote:
> Thanks, but I think using setuid has a security risk for attackers,
> so I understand there is no so much granularity to manage
> unprivileged access to systemd in case the polkit is not used.
You could use setcap to set CAP_SYS_ADMIN
On Wed, 2021-12-01 at 10:24 +0100, Ulrich Windl wrote:
> > >
>
> And I wonder what's wrong with allowing the shutdown command for the
> user in
> sudoers.
> (sudo $(which shutdown) -r now)
Sure. I thought sudo might not be installed on that embedded system,
either. If it is, I'd prefer it over
On Wed, 2022-01-05 at 08:39 +0100, Harald Dunkel wrote:
> On 2022-01-04 16:14:16, Andrei Borzenkov wrote:
> >
> > You have two interfaces which export the same onboard interface
> > index.
> > There is not much udev can do here; the only option is to disable
> > onboard interface name policy. The
On Fri, 2023-01-06 at 19:32 -0500, Gabriel L. Somlo wrote:
>
> I *can* run any tests y'all might suggest to further debug the state
> of the system. But at this point I really do believe there is (or
> should be :) a way to extend the timeout during initial boot to force
> the system to wait for
34 matches
Mail list logo
