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 /
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 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 o
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 c
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 volum
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
> > >
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 like to mention
m, we 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, A
2) the kernel needs 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)
tributes in sysfs only change after rescanning 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 ge
having separate sysfs attributes for
designators of different types, that's 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 priori
lified any time soon. Speaking for 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
this, doesn't look at the SCSI name attribute at all:
https://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/a41a61e8482def
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
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
> > Afte
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 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 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/).
> &
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 m
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 reve
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 t
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 tha
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 of
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 last
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. This
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 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
1 entry for
onboard LAN, but the PCI device number (sic!) is wrong.
--
Dr. Martin Wilck , 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-devel
for mapping system 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,
gt; DefaultDeviceTimeoutStartSec= 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
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 , Tel. +49 (0)911 74053 2107
SUSE Linux
hould* actually 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.
Marti
o obtain
the information from systemd ("will multipathd.service be started later
in the boot process?").
> If you're working with your own internal services, there might be
> other ways of checking this.
What do you mean?
Regards,
Martin
--
Dr. Martin Wilck , Tel. +49 (0)911 74053 2
mentation of
systemd's service enablement logic).
Regards
Martin
--
Dr. Martin Wilck , 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
system
ere the device times out before the "last
resort" timer starts it (and before the last devices appear).
Martin
--
Dr. Martin Wilck , Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
35 matches
Mail list logo
