Re: [systemd-devel] udev "uaccess" tag does not support "hotplug" for some devices

[Tom Yan]

Woo it's a win of almighty grawity again! \o/

My rules works perfectly fine with the 70- prefix just as the shipped
70-uaccess.rules. Should have thought about it. Any pointer for
details about the "consumed" here btw?

On 19 August 2015 at 20:43, Mantas Mikulėnas  wrote:
> On Wed, Aug 19, 2015 at 3:18 PM, Robert Milasan  wrote:
>> On Wed, 19 Aug 2015 17:45:28 +0800
>> "Tom Yan"  wrote:
>>
>>> Hi all!
>>>
>>> So I added the following rules:
>>> [tom@localhost ~]$ grep . /etc/udev/rules.d/*
>>> /etc/udev/rules.d/uas.rules:DRIVERS=="uas", TAG+="uaccess"
>>> /etc/udev/rules.d/usb-storage.rules:DRIVERS=="usb-storage",
>>> TAG+="uaccess"
>>
>> Can you try:
>>
>> ACTION=="add|change", SUBSYSTEMS=="usb",
>> ENV{ID_USB_DRIVER}=="usb-storage", TAG+="uaccess"
>>
>> in usb-storage.rules ?
>>
>> You might wanna rename the rule to something like 90-usb-storage.rules,
>> but thats besides the point.
>
> Hmm, in fact, the "uaccess" tag is consumed by:
>
> 73-seat-late.rules:15:TAG=="uaccess", ENV{MAJOR}!="", RUN{builtin}+="uaccess"
>
> So the ordering might be very relevant.
>
> --
> Mantas Mikulėnas 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Unmount NBD swap on shutdown

[Alkis Georgopoulos]

Hi, systemd runs swapoff on shutdown, but unfortunately another step is 
needed for NBD swap:

# nbd-client -d /dev/nbd1

This notifies the server that the client is shutting down, and thus the 
nbd-server process is terminated, the swap file is erased etc.


In order to work around that issue, I'm trying to create a systemd 
service that

1) Runs on shutdown:
WantedBy=shutdown.target
2) Runs before `swapoff` and before the network gets down:
After=swap.target network.target
3) And at that time, it calls a script that calls swapoff itself, and 
then nbd-client -d:

ExecStart=/path/to/my-nbd-disconnect-script

It's not called at all though when I'm running `poweroff`. What am I 
doing wrong?
How can I invoke `nbd-client -d` on shutdown, but before the swap gets 
off and while the network is still up?


Thank you,
Alkis Georgopoulos
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd --user and the role of DBUS API

[Mantas Mikulėnas]

On Wed, Aug 19, 2015 at 7:13 PM, Simon McVittie <
simon.mcvit...@collabora.co.uk> wrote:

> On 19/08/15 14:12, Mantas Mikulėnas wrote:
>
> > The user bus address is
>
> ... tried by default in libdbus 1.9, GLib 2.45, and sd-bus; so you don't
> need to set DBUS_SESSION_BUS_ADDRESS at all, unless you need
> compatibility with older versions, or reimplementations like dbus-sharp.
>

(Aside: This reminds me of last year's attempt to make $DISPLAY default to
/run/user/*/X11-display … Back then, the last argument was that "old
programs require $DISPLAY anyway, so having a default value is pointless".)

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd --user and the role of DBUS API

[Mantas Mikulėnas]

On Wed, Aug 19, 2015 at 7:48 PM, Michał Zegan 
wrote:

> I may not understand something, but how does it work when I have things
> like at-spi2-registryd running on my session? I cannot start one local and
> one remote gui session, for example? Of course I mean the user bus.
>

I don't know how at-spi works in general. But AFAIK it launches its own
separate bus anyway (I see dbus-daemon
--config-file=/etc/at-spi2/accessibility.conf), so it could continue doing
that.

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd --user and the role of DBUS API

[Michał Zegan]

I may not understand something, but how does it work when I have things 
like at-spi2-registryd running on my session? I cannot start one local 
and one remote gui session, for example? Of course I mean the user bus.


W dniu 19.08.2015 o 18:13, Simon McVittie pisze:

On 19/08/15 14:12, Mantas Mikulėnas wrote:

sd-bus has better performance and native
kdbus support (and a better API than e.g. dbus-glib), but if you're
writing programs in GTK or Qt or EFL, then you'll still want GDBus or
QtDBus or Eldbus.

To clarify, *everything* has a better API than dbus-glib. libdbus, the
low-level reference implementation that is described as painful by its
own documentation, is better than dbus-glib. Please don't use dbus-glib.

If you don't care about portability beyond Linux, sd-bus is essentially
a better libdbus; if you do care about portability beyond Linux, sd-bus
is unsuitable.


The current devel branch (1.9.20) of dbus-daemon installs the
--user units dbus.socket and dbus.service necessary for this.

It only does that if you configure with --enable-user-session. It is
currently opt-in, because it changes the semantics of how the OS is put
together, and some people seem to feel very strongly about the
historical per-login-session buses. I might swap the user bus from
opt-in to opt-out in 1.11 or 1.13 or something. On Debian and its
derivatives, installing the dbus-user-session package has the same
effect as --enable-user-session (and I'd encourage other general-purpose
distributions to use similar packaging).

dbus 1.9.20 is about to become dbus 1.10.0 with only trivial changes, so
a stable branch with optional user-bus support is (finally) around the
corner.


The user bus address is

... tried by default in libdbus 1.9, GLib 2.45, and sd-bus; so you don't
need to set DBUS_SESSION_BUS_ADDRESS at all, unless you need
compatibility with older versions, or reimplementations like dbus-sharp.


(Technically the same can be done with dbus 1.8.x as well, but AFAIK the
developers do not approve.)

We don't add features in stable-branches, particularly features that
change semantics, so libdbus 1.8.x does not have the necessary code
changes to make the right things for a user-bus happen by default. You
can backport them, at your own risk; or you can just parachute in the
dbus.socket and dbus.service files and not make the code changes, but
then setting DBUS_SESSION_BUS_ADDRESS appropriately is your responsibility.



___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd --user and the role of DBUS API

[Simon McVittie]

On 19/08/15 14:12, Mantas Mikulėnas wrote:
> sd-bus has better performance and native
> kdbus support (and a better API than e.g. dbus-glib), but if you're
> writing programs in GTK or Qt or EFL, then you'll still want GDBus or
> QtDBus or Eldbus.

To clarify, *everything* has a better API than dbus-glib. libdbus, the
low-level reference implementation that is described as painful by its
own documentation, is better than dbus-glib. Please don't use dbus-glib.

If you don't care about portability beyond Linux, sd-bus is essentially
a better libdbus; if you do care about portability beyond Linux, sd-bus
is unsuitable.

> The current devel branch (1.9.20) of dbus-daemon installs the
> --user units dbus.socket and dbus.service necessary for this.

It only does that if you configure with --enable-user-session. It is
currently opt-in, because it changes the semantics of how the OS is put
together, and some people seem to feel very strongly about the
historical per-login-session buses. I might swap the user bus from
opt-in to opt-out in 1.11 or 1.13 or something. On Debian and its
derivatives, installing the dbus-user-session package has the same
effect as --enable-user-session (and I'd encourage other general-purpose
distributions to use similar packaging).

dbus 1.9.20 is about to become dbus 1.10.0 with only trivial changes, so
a stable branch with optional user-bus support is (finally) around the
corner.

> The user bus address is

... tried by default in libdbus 1.9, GLib 2.45, and sd-bus; so you don't
need to set DBUS_SESSION_BUS_ADDRESS at all, unless you need
compatibility with older versions, or reimplementations like dbus-sharp.

> (Technically the same can be done with dbus 1.8.x as well, but AFAIK the
> developers do not approve.)

We don't add features in stable-branches, particularly features that
change semantics, so libdbus 1.8.x does not have the necessary code
changes to make the right things for a user-bus happen by default. You
can backport them, at your own risk; or you can just parachute in the
dbus.socket and dbus.service files and not make the code changes, but
then setting DBUS_SESSION_BUS_ADDRESS appropriately is your responsibility.

-- 
Simon McVittie
Collabora Ltd. 

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd --user and the role of DBUS API

[Ian Geiser]

On 08/19/2015 11:32 AM, Mantas Mikulėnas wrote:

On Wed, Aug 19, 2015 at 4:47 PM, Ian Geiser mailto:igei...@devonit.com>> wrote:


...snip...



Not quite; …/systemd/private is not even a bus – it's a direct
peer-to-peer connection to systemd, providing just that one service. (It
is therefore independent of which dbus-daemon version you're running.)

So you need to connect to it in a slightly different way
(e.g. "g_dbus_connection_new_for_address()").

Also keep in mind that this socket is for internal systemd use only
(hence its name), and can be removed from systemd /at any time /in some
future release. For your own projects it's better to set up the actual
user bus.


Oh okay, yeah that makes sense now. So I will leave that alone then and




Yes, that would work. (Though e.g. if you use polkit it should be the
very latest version as well.)


Okay, I am looking at that now. Thanks a TON!


[Also that's some /weird/ quoting style of yours]
I have no clue what outlook "tried" to do. it's a bit "speshul" :D  back 
to a sensible mail client now...

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd --user and the role of DBUS API

[Mantas Mikulėnas]

On Wed, Aug 19, 2015 at 4:47 PM, Ian Geiser  wrote:

> On Wed, Aug 19, 2015 at 2:55 PM, Ian Geiser  wrote:
> > Greetings, I am struggling with search queries here so I need to ask
> this outright.  "what is the role of dbus going forward?"  Is dbus the
> preferred way going forward?  Or should things really be using sd-bus.h
> instead?
>
>
>
> D-Bus is not going away, only its internals are being replaced. Existing
> clients will continue working.
>
>
>
> kdbus replaces the "dbus-daemon" router and the Unix socket transport with
> a direct kernel API, but all existing programs can still connect to it via
> systemd-bus-proxy (at least until they get native kdbus support).
>
>
>
> sd-bus.h is only a library for writing DBus clients & servers. Here the
> choice is still up to you – sd-bus has better performance and native kdbus
> support (and a better API than e.g. dbus-glib), but if you're writing
> programs in GTK or Qt or EFL, then you'll still want GDBus or QtDBus or
> Eldbus.
>
>
>
> *[igeiser] *Awesome, thanks for the clarification
>
>
>
> (I've heard GDBus already has native kdbus support in development, too.)
>
>
> > I manage an embedded product that leverages system heavily at the system
> level, but I want to expand this into the user session. The main focus is
> to use "scopes" for classification and control of specific application's
> process groups.  The rub here is that while system-run can do this if I try
> to do this via dbus the org.freedesktop.systemd1 is missing from the user
> session no matter what or where I set my DBUS_SESSION_BUS_ADDRESS.  I am
> using systemd  224.
>
> Right, systemd will not be accessible on a session bus, since it runs
> *outside* the session.
>
>
>
> So instead you'll find it on the *user* bus, which is available by
> default on kdbus systems, but can be configured with dbus-daemon as well.
> The current devel branch (1.9.20) of dbus-daemon installs the --user units
> dbus.socket and dbus.service necessary for this. The user bus address is
> "kernel:path=/dev/kdbus/$UID-user/bus;unix:runtime=yes" (if I got the
> syntax right?), or
> "kernel:path=/dev/kdbus/$UID-user/bus;unix:path=/run/user/$UID/bus".
>
> *[igeiser] *Can I access it using the path directly in 1.8.x using
> ”unix:path=/run/user/$UID/system/private”? Or is that what the 1.9.20
> allows to happen?
>

Not quite; …/systemd/private is not even a bus – it's a direct peer-to-peer
connection to systemd, providing just that one service. (It is therefore
independent of which dbus-daemon version you're running.)

So you need to connect to it in a slightly different way
(e.g. "g_dbus_connection_new_for_address()").

Also keep in mind that this socket is for internal systemd use only (hence
its name), and can be removed from systemd *at any time *in some future
release. For your own projects it's better to set up the actual user bus.


> (Technically the same can be done with dbus 1.8.x as well, but AFAIK the
> developers do not approve.)
>
>
>
> *[igeiser] *Is this the method various “user units” howtos add a
> dbus.socket and dbus.service into the user directory?  I will research the
> dbus repo for their details.  This is happy lab fun time so I am play with
> hacks if they don’t lead me away from the official solution.
>

Yes, that would work. (Though e.g. if you use polkit it should be the very
latest version as well.)

[Also that's some *weird* quoting style of yours]

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Pretty sure that libudev does not provide a facility

[Anne Mulhern]

for traversing sysfs directory via slaves or holders subdirectories.

lsblk calls the holders direction "inverse".

python-pyudev does not provide such a facility, (but it unofficially 
discontinued development
in 2013). And lsblk does not seem to use libudev facilities directly for this
traversal. So, I think I'm probably right.

Can someone confirm my supposition (or even better, contradict it)?

Thanks!

- mulhern
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd --user and the role of DBUS API

[Ian Geiser]

On Wed, Aug 19, 2015 at 2:55 PM, Ian Geiser 
mailto:igei...@devonit.com>> wrote:
> Greetings, I am struggling with search queries here so I need to ask this 
> outright.  "what is the role of dbus going forward?"  Is dbus the preferred 
> way going forward?  Or should things really be using sd-bus.h instead?

D-Bus is not going away, only its internals are being replaced. Existing 
clients will continue working.

kdbus replaces the "dbus-daemon" router and the Unix socket transport with a 
direct kernel API, but all existing programs can still connect to it via 
systemd-bus-proxy (at least until they get native kdbus support).

sd-bus.h is only a library for writing DBus clients & servers. Here the choice 
is still up to you – sd-bus has better performance and native kdbus support 
(and a better API than e.g. dbus-glib), but if you're writing programs in GTK 
or Qt or EFL, then you'll still want GDBus or QtDBus or Eldbus.

[igeiser] Awesome, thanks for the clarification

(I've heard GDBus already has native kdbus support in development, too.)

> I manage an embedded product that leverages system heavily at the system 
> level, but I want to expand this into the user session. The main focus is to 
> use "scopes" for classification and control of specific application's process 
> groups.  The rub here is that while system-run can do this if I try to do 
> this via dbus the org.freedesktop.systemd1 is missing from the user session 
> no matter what or where I set my DBUS_SESSION_BUS_ADDRESS.  I am using 
> systemd  224.

Right, systemd will not be accessible on a session bus, since it runs outside 
the session.

So instead you'll find it on the user bus, which is available by default on 
kdbus systems, but can be configured with dbus-daemon as well. The current 
devel branch (1.9.20) of dbus-daemon installs the --user units dbus.socket and 
dbus.service necessary for this. The user bus address is 
"kernel:path=/dev/kdbus/$UID-user/bus;unix:runtime=yes" (if I got the syntax 
right?), or "kernel:path=/dev/kdbus/$UID-user/bus;unix:path=/run/user/$UID/bus".
[igeiser] Can I access it using the path directly in 1.8.x using 
”unix:path=/run/user/$UID/system/private”? Or is that what the 1.9.20 allows to 
happen?
(Technically the same can be done with dbus 1.8.x as well, but AFAIK the 
developers do not approve.)

[igeiser] Is this the method various “user units” howtos add a dbus.socket and 
dbus.service into the user directory?  I will research the dbus repo for their 
details.  This is happy lab fun time so I am play with hacks if they don’t lead 
me away from the official solution.

--
Mantas Mikulėnas mailto:graw...@gmail.com>>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Systemd --user and the role of DBUS API

[Mantas Mikulėnas]

On Wed, Aug 19, 2015 at 2:55 PM, Ian Geiser  wrote:
> Greetings, I am struggling with search queries here so I need to ask this
outright.  "what is the role of dbus going forward?"  Is dbus the preferred
way going forward?  Or should things really be using sd-bus.h instead?

D-Bus is not going away, only its internals are being replaced. Existing
clients will continue working.

kdbus replaces the "dbus-daemon" router and the Unix socket transport with
a direct kernel API, but all existing programs can still connect to it via
systemd-bus-proxy (at least until they get native kdbus support).

sd-bus.h is only a library for writing DBus clients & servers. Here the
choice is still up to you – sd-bus has better performance and native kdbus
support (and a better API than e.g. dbus-glib), but if you're writing
programs in GTK or Qt or EFL, then you'll still want GDBus or QtDBus or
Eldbus.

(I've heard GDBus already has native kdbus support in development, too.)

> I manage an embedded product that leverages system heavily at the system
level, but I want to expand this into the user session. The main focus is
to use "scopes" for classification and control of specific application's
process groups.  The rub here is that while system-run can do this if I try
to do this via dbus the org.freedesktop.systemd1 is missing from the user
session no matter what or where I set my DBUS_SESSION_BUS_ADDRESS.  I am
using systemd  224.

Right, systemd will not be accessible on a session bus, since it runs
*outside* the session.

So instead you'll find it on the *user* bus, which is available by default
on kdbus systems, but can be configured with dbus-daemon as well. The
current devel branch (1.9.20) of dbus-daemon installs the --user units
dbus.socket and dbus.service necessary for this. The user bus address is
"kernel:path=/dev/kdbus/$UID-user/bus;unix:runtime=yes" (if I got the
syntax right?), or
"kernel:path=/dev/kdbus/$UID-user/bus;unix:path=/run/user/$UID/bus".

(Technically the same can be done with dbus 1.8.x as well, but AFAIK the
developers do not approve.)

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev "uaccess" tag does not support "hotplug" for some devices

[Mantas Mikulėnas]

On Wed, Aug 19, 2015 at 3:18 PM, Robert Milasan  wrote:
> On Wed, 19 Aug 2015 17:45:28 +0800
> "Tom Yan"  wrote:
>
>> Hi all!
>>
>> So I added the following rules:
>> [tom@localhost ~]$ grep . /etc/udev/rules.d/*
>> /etc/udev/rules.d/uas.rules:DRIVERS=="uas", TAG+="uaccess"
>> /etc/udev/rules.d/usb-storage.rules:DRIVERS=="usb-storage",
>> TAG+="uaccess"
>
> Can you try:
>
> ACTION=="add|change", SUBSYSTEMS=="usb",
> ENV{ID_USB_DRIVER}=="usb-storage", TAG+="uaccess"
>
> in usb-storage.rules ?
>
> You might wanna rename the rule to something like 90-usb-storage.rules,
> but thats besides the point.

Hmm, in fact, the "uaccess" tag is consumed by:

73-seat-late.rules:15:TAG=="uaccess", ENV{MAJOR}!="", RUN{builtin}+="uaccess"

So the ordering might be very relevant.

-- 
Mantas Mikulėnas 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev "uaccess" tag does not support "hotplug" for some devices

[Robert Milasan]

On Wed, 19 Aug 2015 17:45:28 +0800
"Tom Yan"  wrote:

> Hi all!
> 
> So I added the following rules:
> [tom@localhost ~]$ grep . /etc/udev/rules.d/*
> /etc/udev/rules.d/uas.rules:DRIVERS=="uas", TAG+="uaccess"
> /etc/udev/rules.d/usb-storage.rules:DRIVERS=="usb-storage",
> TAG+="uaccess"

Can you try:

ACTION=="add|change", SUBSYSTEMS=="usb",
ENV{ID_USB_DRIVER}=="usb-storage", TAG+="uaccess"

in usb-storage.rules ?

You might wanna rename the rule to something like 90-usb-storage.rules,
but thats besides the point.

-- 
Robert Milasan

L3 Support Engineer
SUSE Linux (http://www.suse.com)
email: rmila...@suse.com
GPG fingerprint: B6FE F4A8 0FA3 3040 3402  6FE7 2F64 167C 1909 6D1A
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev "uaccess" tag does not support "hotplug" for some devices

[Robert Milasan]

On Wed, 19 Aug 2015 17:45:28 +0800
"Tom Yan"  wrote:

> Hi all!
> 
> So I added the following rules:
> [tom@localhost ~]$ grep . /etc/udev/rules.d/*
> /etc/udev/rules.d/uas.rules:DRIVERS=="uas", TAG+="uaccess"
> /etc/udev/rules.d/usb-storage.rules:DRIVERS=="usb-storage",
> TAG+="uaccess"
> 

I think using DRIVERS is incorrect, but as I dont have all info.

> The rules basically works, but it doesn't support "hotplug", that is,
> I have to re-login for newly plugged devices to get the ACLs, and I
> have to do that as well if I replugged the device after I logged in.
> 
> However, it doesn't seem to be a universal limitation, because it does
> support "hotplug" for my SATA optical drive. I enabled hotplug of that
> SATA port in BIOS, unplugged the SATA cable, made sure "cdrom"
> (symlink) and "sr0" are no longer in /dev, then plugged it in again,
> the ACLs remains. I also tried to boot without the optical drive
> connected, and plugged in after login, it also works fine.

Because the rule is different, not implemented the same way as you did.

> 
> So could it be a bug of udev or logind, or something wrong with
> certain kernel drivers?
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
Robert Milasan

L3 Support Engineer
SUSE Linux (http://www.suse.com)
email: rmila...@suse.com
GPG fingerprint: B6FE F4A8 0FA3 3040 3402  6FE7 2F64 167C 1909 6D1A
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Systemd --user and the role of DBUS API

[Ian Geiser]

Greetings, I am struggling with search queries here so I need to ask this 
outright.  "what is the role of dbus going forward?"  Is dbus the preferred way 
going forward?  Or should things really be using sd-bus.h instead?

I manage an embedded product that leverages system heavily at the system level, 
but I want to expand this into the user session. The main focus is to use 
"scopes" for classification and control of specific application's process 
groups.  The rub here is that while system-run can do this if I try to do this 
via dbus the org.freedesktop.systemd1 is missing from the user session no 
matter what or where I set my DBUS_SESSION_BUS_ADDRESS.  I am using systemd  
224.

Thanks!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] REMINDER! systemd.conf 2015 Call for Papers ends soon!

[Lennart Poettering]

Heya!

We'd like to remind you that the systemd.conf 2015 Call for
Presentations ends on August 31st! Please submit your presentation
proposals before that data on our website!

We are specifically interested in submissions from projects and
vendors building today's and tomorrow's products, services and devices
with systemd. We'd like to learn about the problems you encounter and
the benefits you see! Hence, if you work for a company using systemd,
please submit a presentation!

We are also specifically interested in submissions from downstream
distribution maintainers of systemd! If you develop or maintain
systemd packages in a distribution, please submit a presentation
reporting about the state, future and the problems of systemd
packaging so that we can improve downstream collaboration!

And of course, all talks regarding systemd usage in containers, in the
cloud, on servers, on the desktop, in mobile and in embedded are
highly welcome! Talks about systemd networking and kdbus IPC are very
welcome too!

Please submit your presentations until August 31st!

For further details and links see:

http://0pointer.net/blog/systemdconf-2015-call-for-papers.html

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] udev "uaccess" tag does not support "hotplug" for some devices

[Tom Yan]

Hi all!

So I added the following rules:
[tom@localhost ~]$ grep . /etc/udev/rules.d/*
/etc/udev/rules.d/uas.rules:DRIVERS=="uas", TAG+="uaccess"
/etc/udev/rules.d/usb-storage.rules:DRIVERS=="usb-storage", TAG+="uaccess"

The rules basically works, but it doesn't support "hotplug", that is,
I have to re-login for newly plugged devices to get the ACLs, and I
have to do that as well if I replugged the device after I logged in.

However, it doesn't seem to be a universal limitation, because it does
support "hotplug" for my SATA optical drive. I enabled hotplug of that
SATA port in BIOS, unplugged the SATA cable, made sure "cdrom"
(symlink) and "sr0" are no longer in /dev, then plugged it in again,
the ACLs remains. I also tried to boot without the optical drive
connected, and plugged in after login, it also works fine.

So could it be a bug of udev or logind, or something wrong with
certain kernel drivers?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel