systemd 183 and /lib/udev/devices/

systemd 183 and /lib/udev/devices/

[Allin Cottrell]

I see in the NEWS file:

"udev: /lib/udev/devices/ are not read anymore; 
systemd-tmpfiles should be used to create dead device nodes as 
workarounds for broken subsystems."

What sort of "broken subsystems" are we talking about here? 
I'm currently running systemd 44 and udev 182 (without init 
scripts) and I have "pts" and "shm" under /lib/udev/devices/. 
There's no reference to /dev/pts or /dev/shm in fstab, but at 
run time /dev/pts is populated and there's a tmpfs mounted on 
/dev/shm. How can I tell whether I need the systemd-tmpfiles 
workaround? Thanks.

Allin Cottrell

Re: systemd 183 and /lib/udev/devices/

[Tom Gundersen]

On Sun, May 27, 2012 at 4:46 PM, Allin Cottrell <cottrell@wfu.edu> wrote:
> There's no reference to /dev/pts or /dev/shm
> in fstab, but at run time /dev/pts is populated and there's a tmpfs mounted
> on /dev/shm. How can I tell whether I need the systemd-tmpfiles workaround?

The mountpoints are created by systemd[0], so no need to do anything
to make this work.

[0]: <http://cgit.freedesktop.org/systemd/systemd/tree/src/core/mount-setup.c#n61>

Re: systemd 183 and /lib/udev/devices/

[Allin Cottrell]

On Sun, 27 May 2012, Tom Gundersen wrote:

> On Sun, May 27, 2012 at 4:46 PM, Allin Cottrell <cottrell@wfu.edu> wrote:
>> There's no reference to /dev/pts or /dev/shm
>> in fstab, but at run time /dev/pts is populated and there's a tmpfs mounted
>> on /dev/shm. How can I tell whether I need the systemd-tmpfiles workaround?
>
> The mountpoints are created by systemd[0], so no need to do anything
> to make this work.
>
> [0]: <http://cgit.freedesktop.org/systemd/systemd/tree/src/core/mount-setup.c#n61>

Thanks, that's nice. One more question: in switching to make 
/var/lock a symlink to /run/lock, how does/should /run/lock get 
created? Is that also automagic via systemd? (I didn't find a 
reference to "lock" in mount-setup.c.)

Allin Cottrell

Re: systemd 183 and /lib/udev/devices/

[Tom Gundersen]

On Sun, May 27, 2012 at 6:17 PM, Allin Cottrell <cottrell@wfu.edu> wrote:
> One more question: in switching to make /var/lock a
> symlink to /run/lock, how does/should /run/lock get created? Is that also
> automagic via systemd? (I didn't find a reference to "lock" in
> mount-setup.c.)

This is done by systemd-tmpfiles [0].

Cheers,

Tom

[0]: <http://cgit.freedesktop.org/systemd/systemd/tree/tmpfiles.d/legacy.conf>

Re: systemd 183 and /lib/udev/devices/

[Bryan Kadzban]

[-- Attachment #1: Type: text/plain, Size: 576 bytes --]

Tom Gundersen wrote:
> On Sun, May 27, 2012 at 4:46 PM, Allin Cottrell <cottrell@wfu.edu>
> wrote:
>> There's no reference to /dev/pts or /dev/shm in fstab, but at run
>> time /dev/pts is populated and there's a tmpfs mounted on /dev/shm.
>> How can I tell whether I need the systemd-tmpfiles workaround?
> 
> The mountpoints are created by systemd[0], so no need to do anything 
> to make this work.

So... machines without systemd are screwed, unless they resurrect the
bootscripts that copied these nodes, from way back before udevd started
to do it itself?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 261 bytes --]

Re: systemd 183 and /lib/udev/devices/

[Paul Bender]

On 5/27/2012 10:39 AM, Bryan Kadzban wrote:
> Tom Gundersen wrote:
>> On Sun, May 27, 2012 at 4:46 PM, Allin Cottrell<cottrell@wfu.edu>
>> wrote:
>>> There's no reference to /dev/pts or /dev/shm in fstab, but at run
>>> time /dev/pts is populated and there's a tmpfs mounted on /dev/shm.
>>> How can I tell whether I need the systemd-tmpfiles workaround?
>>
>> The mountpoints are created by systemd[0], so no need to do anything
>> to make this work.
>
> So... machines without systemd are screwed, unless they resurrect the
> bootscripts that copied these nodes, from way back before udevd started
> to do it itself?

Yes.

Whenever someone decides to violate the separation of utilities that 
make Unix like distributions so powerful, the end user is harmed. This 
is what the people behind systemd has chosen to do, yet falsely claim 
otherwise (after all, if you cannot use udev without building the rest 
of systemd, they are not separate).

Given its current direction, I suspect that systemd will suffer the some 
fate as Hal. That is, it will become something that the community 
rejects because it attempted to absorb everything. Unfortunately, end 
users suffer in the mean time.

The sooner we fork udev, the better.

Re: systemd 183 and /lib/udev/devices/

[Greg KH]

On Sun, May 27, 2012 at 11:20:43AM -0700, Paul Bender wrote:
> On 5/27/2012 10:39 AM, Bryan Kadzban wrote:
> >Tom Gundersen wrote:
> >>On Sun, May 27, 2012 at 4:46 PM, Allin Cottrell<cottrell@wfu.edu>
> >>wrote:
> >>>There's no reference to /dev/pts or /dev/shm in fstab, but at run
> >>>time /dev/pts is populated and there's a tmpfs mounted on /dev/shm.
> >>>How can I tell whether I need the systemd-tmpfiles workaround?
> >>
> >>The mountpoints are created by systemd[0], so no need to do anything
> >>to make this work.
> >
> >So... machines without systemd are screwed, unless they resurrect the
> >bootscripts that copied these nodes, from way back before udevd started
> >to do it itself?
> 
> Yes.
> 
> Whenever someone decides to violate the separation of utilities that
> make Unix like distributions so powerful, the end user is harmed.
> This is what the people behind systemd has chosen to do, yet falsely
> claim otherwise (after all, if you cannot use udev without building
> the rest of systemd, they are not separate).

There is a long history of needing more tools on the system to build a
program, than to use them, see all of the different build system ways of
specifying just this very thing.

> Given its current direction, I suspect that systemd will suffer the
> some fate as Hal. That is, it will become something that the
> community rejects because it attempted to absorb everything.
> Unfortunately, end users suffer in the mean time.

The "community" didn't reject hal, the developers realized they got it
wrong.

> The sooner we fork udev, the better.

Feel free to, no one is stopping you.  Also, some people seem to like
mdev for some reason, perhaps you should try that out instead.

Best of luck,

greg k-h

Re: systemd 183 and /lib/udev/devices/

[Kay Sievers]

On Sun, May 27, 2012 at 4:46 PM, Allin Cottrell <cottrell@wfu.edu> wrote:
> I see in the NEWS file:
>
> "udev: /lib/udev/devices/ are not read anymore; systemd-tmpfiles should be
> used to create dead device nodes as workarounds for broken subsystems."
>
> What sort of "broken subsystems" are we talking about here?

The only one still known is the parport driver, where cups might rely
on module-autoloading by accessing of /dev/lp0.

There are around 3 users in the world which need that. :)

> I'm currently
> running systemd 44 and udev 182 (without init scripts) and I have "pts" and
> "shm" under /lib/udev/devices/. There's no reference to /dev/pts or /dev/shm
> in fstab, but at run time /dev/pts is populated and there's a tmpfs mounted
> on /dev/shm. How can I tell whether I need the systemd-tmpfiles workaround?

How can you run udev without an init script? It's usually 2-3 steps to
bring it up. What mounts devpts and the /dev/shm tmpfs? The same thing
that calls mount should just also do the mkdir before the mount.

We decided against putting device nodes anywhere else than /dev, so
the functionality was removed. If you want the whole
/lib/udev/devices/ functionality back, one line like "cp -ax
/lib/udev/devices/* /dev" should do it.

In the future, tools are expected to use tmpfiles to create things
like the /dev/lp0 stuff. The tmpfiles are used to properly set up
directories, files, file content with the proper permissions in
volatile filesystems like /dev, /run (/var/run), /tmp, /sys. It can
also be used to create device nodes.

Kay

Re: systemd 183 and /lib/udev/devices/

[Allin Cottrell]

On Sun, 27 May 2012, Kay Sievers wrote:

> On Sun, May 27, 2012 at 4:46 PM, Allin Cottrell <cottrell@wfu.edu> wrote:
>> I see in the NEWS file:
>>
>> "udev: /lib/udev/devices/ are not read anymore; systemd-tmpfiles should be
>> used to create dead device nodes as workarounds for broken subsystems."
>>
>> What sort of "broken subsystems" are we talking about here?
>
> The only one still known is the parport driver, where cups might rely
> on module-autoloading by accessing of /dev/lp0.
>
> There are around 3 users in the world which need that. :)

Fine, I'm not one of them.

>> I'm currently running systemd 44 and udev 182 (without init 
>> scripts) and I have "pts" and "shm" under /lib/udev/devices/. 
>> [...]
>
> How can you run udev without an init script?

I mean with a scriptless systemd setup.

Allin Cottrell

Re: systemd 183 and /lib/udev/devices/

[Robby Workman]

On Sun, 27 May 2012 11:20:43 -0700
Paul Bender <pebender@san.rr.com> wrote:

> The sooner we fork udev, the better.


Well, I'm not pleased with the direction it's gone either, but I
am also aware that a fork to maintain udev is a lot of work that
will mostly be monotonous, boring, and time consuming.  I don't
want to do it, and I doubt anyone else does either, especially
since it *is* possible to build standalone udev from the systemd
sources.  

This is currently untested and should be considered a work in 
progress, but it might serve as a useful starting point for
someone:

http://connie.slackware.com/~rworkman/standalone-udev-from-systemd/

-RW