Re: [systemd-devel] Udev rules hardware database
On Fri, 2014-11-07 at 08:26 +0100, Martin Pitt wrote:
Patrick Häcker [2014-11-05 16:55 +0100]:
I you want to have permanent power saving activated for your devices, the
recommended way is to use udev (e.g.
https://wiki.archlinux.org/index.php/Power_saving#USB_autosuspend). Some
[...]
- Is there already something like this?
By coincidence I recently noticed something interesting in sysfs: My
USB devices seem to have an attribute supports_autosuspend. These
They are from the kernel and tell you that the drivers for the devices
support autosuspend. It says nothing about the device itself.
are all 1 except for my USB webcam [1] where it is 0. This sounds very
promising indeed! So apparently the kernel now already grew either a
heuristics or some black/whitelists?
Nothing of this sort. It is a pure driver thing and only the negative
is to be taken at face value.
At least the current state how Linux (3.16.0) and udev (215) configure
autosuspend seems a bit weird:
- Some of my USB devices have power/autosuspend == 2: internal
laptop webcam, USB webcam ([1] again), USB Keyboard, USB mouse.
2 is the kernel's default for the general case.
All others have 0. There is no udev rule or other thing on my
system to set those, so unless it's udev or systemd itself I guess
it's from the kernel.
Drivers in the kernel can change it with
pm_runtime_set_autosuspend_delay()
- Most of my USB devices have power/level==auto (i. e. suspend
enabled), only some of them are on (i. e. suspend disabled).
Curiously those which are on are three of above devices where
autosuspend==2: USB webcam, USB Keyboard, USB mouse.
Again drivers can enable it with usb_enable_autosuspend()
This can not be done for HID devices, because for most mice
remote wakeup isn't usable in the generic case.
- The only udev rule which I'm aware of that does autosuspend is
42-usb-hid-pm.rules:
ACTION==add, SUBSYSTEM==usb, ATTR{bInterfaceClass}==03,
ATTRS{removable}==fixed, TEST==../power/control,
ATTR{../power/control}=auto
So it does not seem to be the case that we don't currently enable
autosuspend at all, but it's currently highly inconsistant and
confusing.
It is inconsistent. That is at least partially to the inability to find
general rules.
Regards
Oliver
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Udev rules hardware database
On Fri, 2014-11-07 at 12:55 +0100, Lennart Poettering wrote: On Fri, 07.11.14 09:23, Oliver Neukum (oneu...@suse.de) wrote: It is inconsistent. That is at least partially to the inability to find general rules. So what would you recommend we do? Experiment with turning auto-suspend on by default and then start building a blacklist if we get reports that things stop working? No. I suggest giving administrators (users) a really easy way to enable autosuspend and gather the results. That isn't good. We've tried for years to come up with something better. And that blacklist should that live in hwdb in userspace or be maintained as quirks list in the kernel, compiled in? user space Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Udev rules hardware database
On Sun, 2014-11-09 at 22:39 +0100, Patrick Häcker wrote: I really don't know. Some other operating system relies on a whitelist due to all of the horrible devices out there that can't handle suspend (keyboards and mice are notorious for being bad.) Thanks for your input. Do you know in which kernel version the above mentioned bug got fixed? I just checked two mice, a keyboard and a bunch of internal devices with a 3.17 kernel. Only one of the mice works completely reliable with activated power saving as input device – no problems with the internal devices. The funny thing is: That mouse is built from the same company as some other operating system – dog feeding does make sense. The problem with mice is the usual inability to trigger a remote wakeup when the mouse is moved. They only do a remote wakeup when a button is pressed. (The behavior is within spec. The USB HID spec is deficient.) I took two lessons from that 1. It makes no sense to use the same approach for all USB devices. Some classes need a blacklist others do need a whitelist. 2. The kernel is not really the ideal place to decide when to activate power management. Most mice are built for an operating model which has more grades then Linux usually uses. We see our system either as fully operational or suspended. Those mice are built for reducing power consumption when a system becomes unused and the screen is blanked or the screensaver comes up. You might want to ask one of the distro people to see if they have ever turned it on by default and what happened if they tried that. Unfortunately, I do not know anyone from a distribution who is in charge for that area. Do you? A short Google search didn't bring up any distribution which did that, but my search was probably incomplete. Unlikely. You end up with systems that are practically unusable in the worst and commonest case. But if my results mentioned above should be remotely representative, that might be disastrous, because for an average user it might be close to impossible to deactivate power savings without working input devices. Exactly. Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cdrom_id: unmount media on --eject-media if media mounted
On Thu, 2015-01-15 at 15:47 +0100, Robert Milasan wrote: ... which leads me to the question: why don't we just call the actual eject program? Just to avoid that dependency? Yes, we could do this, I didn't think of it :) I can confirm this to work and it is better than duplicating ejecting and needing to keep doing the same fixes in two places. But that doesn't answer the basic question. What is this policy of effectively never locking the door doing in udev? Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
On Thu, 2015-01-15 at 11:38 +0100, Martin Pitt wrote: Oliver Neukum [2015-01-15 11:31 +0100]: No, the events are generated. And it is processed. There is just no unmounting. That sounds like a bug/missing feature in cdrom_id --eject-media then. You could try and replace it with /usr/bin/eject, which does the unmounting of all partitions first, fail on busy, and does the eject at last? That does work. But what is the motivation of in effect disabling door locking? We don't -- we specifically leave it locked so that we get the eject button pressed events. (See my other response for some details). Well, yes, but why is policy that should be left to the GUI placed into udev? Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
On Thu, 2015-01-15 at 09:03 +0100, Martin Pitt wrote: - udev rules (60-cdrom_id.rules) picks that up and calls eject /dev/srX on the device; the eject program takes care to unmount everything before physical ejection. Note that the kernel will *not* generate DISK_EJECT_REQUEST uevents if the tray is not locked. Your case sounds exactly like that? No, the events are generated. And it is processed. There is just no unmounting. But what is the motivation of in effect disabling door locking? Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev: 60-persistent-storage.rules attempts blkid on removable devices with no medium present
On Mon, 2015-02-16 at 14:52 -0800, Hans Scholze wrote:
Hi,
I'm not sure if this is considered a problem but I noticed some
spurious error messages during boot. The source appears to be:
1. a USB media card reader is plugged in at boot
2. the device node exists regardless of whether a card is present
(expected)
3. line 70 of 60-persistent-storage.rules (KERNEL!=sr*,
IMPORT{builtin}=blkid) attempts blkid on the device with no card
present
4. the open() call in builtin_blkid() in udev-builtin-blkid.c fails
resulting in an error: /dev/sdd: No medium found message printed to
stderr
That seems to be the error. You cannot guarantee that blkid will never
see this error if the drive has removable media. It should have an
option for silently failing in these cases.
Regards
Oliver
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
On Mon, 2015-01-12 at 04:46 -0800, Greg KH wrote: Let me rephrase. Is this desirable? Probably not. But with some hardware, as you have seen, you need to run some type of userspace daemon to poll the device to handle media removal issues when the hardware itself does not report media removal. Well, we have been polling in kernel space since 3.13 It doesn't tell us whether the hardware button should eject the medium in the first place. Some hardware doesn't allow you to lock the door, so this question comes down to what to do if you try to lock it but it does not happen. No, for currently udev doesn't care. And the choice is pretty clear anyway. We are not going to refuse to use the device, are we? So we'll use it anyway. The question is, do we lock if we can? We need to be able to handle surprise removal. That doesn't mean we should in effect never lock the door if we can do so. I think we support locking the door, if userspace asks to, right? Yes and and that is not the problem. To do what? The kernel on its own and udev on their own behave differently. What is the correct way? The kernel on its own does not dictate this type of policy, it's up to userspace to determine if you want to lock the door when you mount I am afraid I am forced to strongly disagree with your statement. The kernel does have a default policy. It locks the door upon open() (which is implied in mount()) If you press the button during such a lock, an event is passed to user space. The question is why udev contains a rule that overrides the kernel and in user space implements an effective policy of no door locking. something, and to poll the device to detect media removal if the device is broken and does not report such things. That is why systems use udisks today, to handle all of these issues. Why not just use it? Could you elaborate on how to use udisks if udev has a rule that unconditionally ejects media if the button is pressed? And what is wrong with the kernel's default? Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] cdrom_id and 60-cdrom_id.rules behavior
On Mon, 2015-01-12 at 04:15 -0800, Greg KH wrote: On Mon, Jan 12, 2015 at 09:39:30AM +0100, Robert Milasan wrote: Hello, a while back, around 2011, in cdrom_id was added --eject-media, --lock-media and --unlock-media for not much explanation. Now, recently some people noticed that this might actually be a problem. Reference: http://bugzilla.opensuse.org/show_bug.cgi?id=909418 Here is a scenario: 1. add a CD/DVD into the driver 2. mount the driver: mount /dev/sr0 /mnt/my_cd (ensure you don't use the Gnome/KDE auto-mounting or reproduce this in a server setup) 3. eject the media (using the hardware button) and add a new one media (different disk) 4. ls /mnt/my_cd (it will be an empty output or the previous media) Is this expected? Yes, because you didn't unmount the media and tell the kernel that the filesystem is now gone. You are correct, but not really helpful :) Let me rephrase. Is this desirable? It doesn't tell us whether the hardware button should eject the medium in the first place. Also, I remember a while back (long time ago) that once you added a media into the driver and it was properly mounted, you couldn't eject the media until you unmounted the media. It depends on the hardware, some devices support this, others don't. If the device does not support locking the door, the question is moot. We need to be able to handle surprise removal. That doesn't mean we should in effect never lock the door if we can do so. NOTE: This works somewhat OK in the desktop setup, probably due to udisks (using Gnome/KDE), but in the console not really. Then use udisks :) To do what? The kernel on its own and udev on their own behave differently. What is the correct way? Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing
On Sun, 2016-09-25 at 23:57 +0200, Reindl Harald wrote: > > Am 25.09.2016 um 23:52 schrieb Sergei Franco: > > I am looking at correct way to disable the "feature" of emergency mode > > when systemd encounters missing block device entires in fstab. > > > > For example: > > > > the following entry is in /etc/fstab: > > UUID=d4a23034-8cbe-44b3-92a5-3d38e1816eff /data xfs > > defaults0 0 > > > > If the drive (d4a23034-8cbe-44b3-92a5-3d38e1816eff) has been detached > > and machine rebooted it stops booting with Emergency mode, even though > > the /data is not crucial for boot > > RTFM - when you don't say "nofail" it's ecpected to be crucial > > your entry says it's crucial That in turn raises the question why the default should be different than what is used in earlier systems. Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] WebUSB
Am Mittwoch, den 11.01.2017, 16:01 +0100 schrieb Lars Knudsen: > If it can be invoked via DBus - what is the harm to only do the scan > for the greylisted (in this case webusb) modems when the user > actually wants to search for a modem (like a printer) - and leave the > poor devices alone otherwise? In headless systems, it will not be > the same problem as they will most probably be custom made anyway. Why have a list at all? Would you want the kernel to do an unrequested probe of a device (function) with WebUSB descriptors at all? It seems to me that the finest granularity you might need is by device class, e.g. probing HID devices, so you don't block the keyboard. Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] WebUSB
On Tue, 2017-01-10 at 19:55 +0100, Lars Knudsen wrote > And we're quite happy to keep blacklisting specific VID/PID > combos we > know are not modems. Another possible solution is to greylist > devices > that happen to have webusb descriptors, such that they won't > get auto- > probed, but could be probed on-demand via D-Bus. But I'd > rather that > happen via udev rules than MM trying to walk USB device > attributes and > parsing webusb descriptors. > > If greylisting prevents auto-probing, I think it would be very > valuable for devices with a WebUSB header because those will in most > cases (as I see them used) be industrial things (like my current > medical company employer) or IoT devices. And waiting ~16 seconds for > a fallback to USB Serial where WebUSB is not available (or for other > reasons not chosen), can be a real pain. > > > I agree that a solid udev rule would be a good way forward (I'll look > into greylisting and see if I can come up with something that covers) > and maybe this could also be the place to do the user space access (or > not - I'll try to come back with something. I am afraid this would not work. Or rather it would work once. But as soon as the driver is already loaded, it will bind and we have a beautiful race condition, which the kernel will almost certainly win. > And if we happen to look at a storage device we may see an unclean removal if you kick the kernel off a device. I am afraid if you really want to go to triggered probing, you need a sysctl for that. Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Github systemd issue 6237
Am Montag, den 10.07.2017, 12:57 +0200 schrieb Reindl Harald: > > Am 10.07.2017 um 12:55 schrieb Lennart Poettering: > > > > > > The "nobody" user has special semantics on Linux: it's where things > > are mapped to that can't be mapped otherwise. It's used by user > > namspacing, by NFS and others. It's really not a good idea, to permit > > random services to create and access files under that ID > > and run it as root is a better idea? > seriously? This is moot. If you specify a user that is considered wrong for whatever reason the service must fail. Whether we disagree about who decide what is a valid user name also does not matter. You cannot substitute users for any reason. Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Github systemd issue 6237
Am Mittwoch, den 05.07.2017, 20:10 +1000 schrieb Michael Chapman: > I'm pretty sure you'll find that it does. Specifically, it will fail when > the child process for the command being executed attempts to map the > username to a UID. > > The issue being discussed here is that systemd considers "0day" to be > _syntactically_ invalid for a username. See the valid_user_group_name() > function in basic/user-util.c. What a valid username is, is defined in POSIX. If systemd wants to support only a subset of those, fair enough, but then it must totally fail anything that uses such a name. Falling back to another user is not acceptable. It being root is especially bad. Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 回复： 回复： [systemd-de vel] systemctl can't execute stop actually,whenservice is started by other way
Am Donnerstag, den 29.06.2017, 11:45 +0200 schrieb Reindl Harald: > > Am 29.06.2017 um 10:05 schrieb Oliver Neukum: > > > > Am Mittwoch, den 28.06.2017, 13:29 +0200 schrieb Lennart Poettering: > > > > > > Well, it's a service manager. As such it keeps track of services, > > > knows when they are started and when they aren't. Why would it stop > > > services that aren't started? > > > > Because you command it to do so. > > The check systemd does adds no value. There is a reason to not start > > something that is running. The reverse does not apply > > this is nonsense - how in the world should systemmd know what to stop > when it has no clue about the involved processes because it did not > start the service and hence has no tracking at all > So try and fail. That is still no excuse for ruling out that you can stop a service you have not started. That is pure politics. Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] 回复： 回复： [systemd-de vel] systemctl can't execute stop actually,whenservice is started by other way
Am Mittwoch, den 28.06.2017, 13:29 +0200 schrieb Lennart Poettering: > Well, it's a service manager. As such it keeps track of services, > knows when they are started and when they aren't. Why would it stop > services that aren't started? Because you command it to do so. The check systemd does adds no value. There is a reason to not start something that is running. The reverse does not apply. Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: enable suspend to idle
Am Donnerstag, den 01.03.2018, 15:17 +0100 schrieb Lennart Poettering:
> On Do, 01.03.18 14:40, Thomas Blume (thomas.bl...@suse.com) wrote:
> > As a proof of concept, I have created below udev rule and helper script,
> > which
> > works on my testmachine.
> > Obviously, like that it isn't portable to other distros, but I'd like to get
> > comments whether this is the way to go.
> > If I get positive feedback, I'll try a portable approach using a binary
> > helper.
> >
> > udev rule:
> >
> > -->
> > ACTION=="add", ATTR{power/wakeup}=="disabled",
> > IMPORT{program}="/usr/lib/udev/get-wakeup-devices.sh %p"
> > ENV{RESUME_FROM_IDLE}=="1", ATTR{power/wakeup}="enabled"
>
> Not following here. This doesn't appear like something where userspace
> should be involved. We generally avoid udev rules whose only job is to
> "shortcut" kernel events back into the kernel. Why doesn't the kernel
> set this up properly anyway on its own?
The kernel must not set policy on what is a source of wake ups. Setting
this up so that we do not get a regression in functionality compared
to old style S3 (whose policy is in firmware) falls to user space,
more specifically udev.
Regards
Oliver
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: enable suspend to idle
On Fri, 2018-03-02 at 10:18 +0100, Lennart Poettering wrote: > But why wouldn't that be a kernel option? I mean, so far the goal was > to encode "reasonable defaults" in the kernel itself, so that > userspace is only used when those "reasonable defaults" do not apply > onto one local case. > > Really, already for compatibility reasons the kernel should just carry > the "reasonable defaults", so that it's not necessary to match it up > with a udev version that carries the right policy for it. Well, no. The kernel must carry conservative defaults that do no harm in any case. Setting defaults sensible for the class of systems systemd runs on is the job of udev. For now we are running with defaults taken from firmware, which can be expected to be tailored to the system it comes with. Falling back to conservative defaults would mean a regression in functionality. Regards Oliver ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
