Re: [systemd-devel] [PATCH 00/10] Device Management for systemd-logind

On Sun, Aug 25, 2013 at 8:46 PM, David Herrmann wrote: > logind itselfs takes care of revoking device access for inactive sessions > (synchronized with session-switches!). It also tries to resume every device > when a session is activated. But session-devices must not be used to watch > session st

Re: [systemd-devel] [PATCH 10/10] logind: implement generic multi-session

Hi David, On Sun, Aug 25, 2013 at 8:46 PM, David Herrmann wrote: > One important note is that delayed session-switching is meant for > backwards compatibility. New compositors or other sessions should really > try to deal correctly with forced session switches! They only need to > handle EACCES/E

Re: [systemd-devel] [RFC v2] mount: improve DefaultDependencies and use in generator

On Sat, Aug 24, 2013 at 3:56 AM, Colin Walters wrote: > On Fri, 2013-08-23 at 15:09 +0800, Tom Gundersen wrote: >> This moves reduces redundancy between systemd core and the fstab-generator, >> by >> improving and relying on the DefaultDependencies logic. > > It

Re: [systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root

On 24 Aug 2013 03:51, "Colin Walters" wrote: > > First, thanks for working on this, most of these patches look sane to > me. > > On Fri, 2013-08-23 at 15:09 +0800, Tom Gundersen wrote: > > > +if (path_equal(m->where, "/")

[systemd-devel] [PATCH 7/7] swap: handle nofail/noauto in core

--- src/core/swap.c | 15 + src/fstab-generator/fstab-generator.c | 59 ++- 2 files changed, 18 insertions(+), 56 deletions(-) diff --git a/src/core/swap.c b/src/core/swap.c index f0e19ad..57d15eb 100644 --- a/src/core/swap.c +++ b/src

[systemd-devel] [PATCH 6/7] mount: filesystems mounted in the initrd should not conflict with umount.target in the real root

These mounts should be kept around and unmounted in the shutdown ramfs. Currently, we will still attempt to umount these in the final kill spree, but we should consider avoiding that too. --- src/core/mount.c | 26 +- 1 file changed, 21 insertions(+), 5 deletions(-) diff

[systemd-devel] [PATCH 4/7] swap: backing device should unconditionally want swap unit

There is no need to restrict this to only the 'nofail' case. In the '!nofail' case the unit is already wanted by swap.target, so this is not a functional change. --- src/core/swap.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/core/swap.c b/src/core/swap.c index 82550

[systemd-devel] [PATCH 5/7] mount: move device links handling from generator

This makes mount units work like swap units: when the backing device appears the mount unit will be started. v2: the device should want the mount unconditionally, not only for DefaultDependencies=yes --- src/core/mount.c | 12 ++- src/fstab-generator/fstab-generator.

[systemd-devel] [PATCH 3/7] fstab-generator: use DefaultDependencies=yes

This removes some redundancy between the generator and the core mount handling. --- TODO | 2 -- src/fstab-generator/fstab-generator.c | 52 --- 2 files changed, 6 insertions(+), 48 deletions(-) diff --git a/TODO b/TODO index 3800c

[systemd-devel] [PATCH 2/7] mount: don't pull in network.target, just order after it

--- src/core/mount.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/core/mount.c b/src/core/mount.c index c7d29b0..7838e60 100644 --- a/src/core/mount.c +++ b/src/core/mount.c @@ -476,7 +476,7 @@ static int mount_add_default_dependencies(Mount *m) { } i

[systemd-devel] [PATCH 1/7] filesystem targets: disable default dependencies

This means we can use default dependencies on mount units without having to get them automatically ordered before the filesystem targets. Reported-by: Thomas Baechler --- units/initrd-fs.target | 2 ++ units/initrd-root-fs.target | 2 ++ units/local-fs.target | 2 ++ units/remote-fs.

[systemd-devel] [RFC v2] mount: improve DefaultDependencies and use in generator

This moves reduces redundancy between systemd core and the fstab-generator, by improving and relying on the DefaultDependencies logic. Functional changes: * Mount units will no longer Want network.target, only order themselves After it. * Both monut and swap units will now be WantedBy their

Re: [systemd-devel] [RFC] mount: improve DefaultDependencies and use in generator

On Wed, Aug 21, 2013 at 7:53 PM, Tom Gundersen wrote: > I'd like to move some of the default dependency logic from the fstab generator > to core. This should remove some redundancy and also improve consistency > between mount units and fstab entries. > > The first patch si

Re: [systemd-devel] [RFC] mount: improve DefaultDependencies and use in generator

On Wed, Aug 21, 2013 at 10:06 PM, Thomas Bächler wrote: > Am 21.08.2013 13:53, schrieb Tom Gundersen: >> I'd like to move some of the default dependency logic from the fstab >> generator >> to core. This should remove some redundancy and also improve consistency >&g

Re: [systemd-devel] [PATCH 2/3] mount: move device links handling from generator

On Wed, Aug 21, 2013 at 8:50 PM, Harald Hoyer wrote: > On 08/21/2013 01:53 PM, Tom Gundersen wrote: >> -if (!isbind && >> -!path_equal(where, "/")) { >> - >> -r = device_name(what, &a

[systemd-devel] [PATCH 3/3] mount: x-initrd.mount should not conflict with umount.target

These mounts were mounted in the initrd and should be unmounted there as well. Currently, we will still attempt to umount these in the final kill spree, but we should consider avoiding that too. --- src/core/mount.c | 26 +- 1 file changed, 21 insertions(+), 5 deletions(-)

[systemd-devel] [PATCH 2/3] mount: move device links handling from generator

Now, when default dependencies are enabled for a mount unit it will be WantedBy the respective devices. --- src/core/mount.c | 13 +++- src/fstab-generator/fstab-generator.c | 40 +++ 2 files changed, 15 insertions(+), 38 deletions(-)

[systemd-devel] [PATCH 1/3] fstab-generator: use DefaultDependencies=yes

This removes some redundancy between the generator and the core mount handling. --- TODO | 2 -- src/fstab-generator/fstab-generator.c | 52 --- 2 files changed, 6 insertions(+), 48 deletions(-) diff --git a/TODO b/TODO index 9bc14

[systemd-devel] [RFC] mount: improve DefaultDependencies and use in generator

Hi guys, I'd like to move some of the default dependency logic from the fstab generator to core. This should remove some redundancy and also improve consistency between mount units and fstab entries. The first patch simply enables default dependencies in the generator, and removes some things tha

[systemd-devel] [PATCH] units: disable kmod-static-nodes.service in containers

Hi Zbyszek, Regarding : Would it make sense to use ConditionCapability=CAP_MKNOD instead? This would match what is done in systemd-tmpfiles-setup-dev.service. The effect is currently the same (I thin

Re: [systemd-devel] prevent unmount of single partitions on shutdown

On Wed, Aug 21, 2013 at 5:56 PM, Colin Guthrie wrote: > 'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 21/08/13 04:38 did > gyre and gimble: >> On Wed, Aug 21, 2013 at 05:21:59AM +0200, Stephan Raue wrote: >>> Hi, >>> >>> i try to port systemd on a own embedded OS which is stored in a >>> squas

[systemd-devel] [PATCH] cryptsetup-generator: allow specifying options in /proc/cmdline

The main usecase for this is to make it possible to use cryptsetup in the initrd without it having to include a host-specific /etc/crypttab. Cc: Harald Hoyer Tested-by: Thomas Bächler --- Hi guys, This allows us to use systemd in the initrd for encrypted root in Arch. I didn't look much into h

Re: [systemd-devel] [RFC] Integrating an early-boot service in a blocking way?

Hi Michael, On 16 Aug 2013 05:01, "Michael Stapelberg" wrote: > > Hi, > > the debian-live people have approached me and want to experiment with > systemd. One of the things they need to have is running a service called > live-config.service, but the issue is that it needs to run in early > boot,

Re: [systemd-devel] Please pass 'fsck.mode=force' on the kernel command line rather than creating /forcefsck on the root file system

On 16 Aug 2013 05:05, "Reindl Harald" wrote: > > Please pass 'fsck.mode=force' on the kernel command line rather than creating /forcefsck on the root file system > > please drop this deprectaion, it is disturbing and useless > > if you want a forced fsck for *whatever* reason you do *not* want > t

Re: [systemd-devel] [PATCH] udev: fail firmware loading immediately if no search path is defined

Hi Maarten, On 7 Aug 2013 09:52, "Maarten Lankhorst" wrote: > So what is wrong with my 'fail in udev immediately if not configured' idea? In that case it > doesn't matter whether CONFIG_FW_LOADER_USER_HELPER is set or not. Well that would break the case for anyone who actually wants to use a non

Re: [systemd-devel] [PATCH] fstab-generator: respect noauto/nofail when adding sysroot mount

On Fri, Aug 9, 2013 at 5:41 AM, WANG Chao wrote: >> > Signed-off-by: WANG Chao >> >> For the future, no need to do s-o-b in systemd. I dropped the line >> before applying. > > Thanks. Any story here? Just that we should avoid giving the wrong impression. See e.g.

Re: [systemd-devel] fstab-generator: why nofail=true removes "Before=$post" in .mount

On Thu, Aug 8, 2013 at 7:35 AM, WANG Chao wrote: > In add_mount(), if nofail=true, "Before=$post" won't be added to > xxx.mount: > > [..] > if (post && !noauto && !nofail && !automount) > fprintf(f, > "Before=%s\n", > post); > > why doing this? The way thin

Re: [systemd-devel] [PATCH] fstab-generator: respect noauto/nofail when adding sysroot mount

On Thu, Aug 8, 2013 at 9:18 AM, WANG Chao wrote: > Currently we don't respect noauto/nofail root mount options (from > rootflags kernel cmdline). We should map these two flags to the > corresponding boolean variable noauto and nofail when calling > add_mount(). Thanks for the patch. We need some

Re: [systemd-devel] [PATCH 2/3] install: don't allow to enable/disable templates

On 8 Aug 2013 17:57, "Thomas Bächler" wrote: > > Am 08.08.2013 15:19, schrieb Michal Sekletar: > > Calling enable on template units doesn't make sense since it is possible > > to enable instances directly and users are not forced to use Alias= > > trickery anymore. > > Actually, it would make sens

Re: [systemd-devel] FUSE mount cannot be started on boot

On 8 Aug 2013 17:10, "Jan Engelhardt" wrote: > > > On Thursday 2013-08-08 16:26, Tom Gundersen wrote: > >On Thu, Aug 8, 2013 at 2:00 PM, Jan Engelhardt wrote: > >> > >> With systemd 195, an /etc/fstab line like > >> > >>

Re: [systemd-devel] FUSE mount cannot be started on boot

On Thu, Aug 8, 2013 at 2:00 PM, Jan Engelhardt wrote: > > With systemd 195, an /etc/fstab line like > > /srv/www /home/www fuse.bindfs auto,group=foo,perms=g+rw 0 0 > > can fail to start if /dev/fuse does not exist yet. This sounds strange. /dev/fuse should be created by udev (in 195, an

Re: [systemd-devel] [PATCH 2/3] install: don't allow to enable/disable templates

Hi Michal, On Thu, Aug 8, 2013 at 3:19 PM, Michal Sekletar wrote: > Calling enable on template units doesn't make sense since it is possible > to enable instances directly and users are not forced to use Alias= > trickery anymore. It actually might make sense to still call enable on a template u

Re: [systemd-devel] Impact when not loading ipv6 and autofs kernel module ...

On Wed, Aug 7, 2013 at 1:24 PM, Hoyer, Marko (ADITG/SW2) wrote: > 2. What impact do I have to expect in case the kernel does not provide > ipv6 functionality? I think the main problem is in case you were to somehow insmod the ipv6 module after boot, in which case it probably won't be set up

Re: [systemd-devel] Fwd: best way to handle service restarts after hibernate/suspend?

On Wed, Aug 7, 2013 at 10:12 AM, Mathijs Kwik wrote: > I have a few things that need to get run after waking up my laptop > (things like hdparm to set device power options/spindown time). > I created oneshot, remainafterexit services for those and made them > wanted by multi-user.target.This works

Re: [systemd-devel] [PATCH] Change CONFIG_FW_LOADER_USER_HELPER to default n and don't select it

On 7 Aug 2013 02:26, "Andy Lutomirski" wrote: > > On Tue, Aug 6, 2013 at 5:24 PM, Tom Gundersen wrote: > > > > On 6 Aug 2013 18:32, "Bryan Kadzban" wrote: > >> > >> On Tue, Aug 06, 2013 at 11:17:17AM +0200, Tom Gundersen wrote: >

Re: [systemd-devel] [PATCH] Change CONFIG_FW_LOADER_USER_HELPER to default n and don't select it

On 6 Aug 2013 18:32, "Bryan Kadzban" wrote: > > On Tue, Aug 06, 2013 at 11:17:17AM +0200, Tom Gundersen wrote: > > On Tue, Aug 6, 2013 at 11:11 AM, Tom Gundersen wrote: > > > On Tue, Aug 6, 2013 at 10:20 AM, Maarten Lankhorst > > > wrote: > >

Re: [systemd-devel] [PATCH] Change CONFIG_FW_LOADER_USER_HELPER to default n and don't select it

On Tue, Aug 6, 2013 at 11:11 AM, Tom Gundersen wrote: > On Tue, Aug 6, 2013 at 10:20 AM, Maarten Lankhorst > wrote: >> Op 05-08-13 18:29, Andy Lutomirski schreef: >>> The systemd commit below can delay firmware loading by multiple >>> minutes if CONFIG_FW_LOADER_US

Re: [systemd-devel] [PATCH] Change CONFIG_FW_LOADER_USER_HELPER to default n and don't select it

hange would break new kernels as well >> as old kernels. >> >> Since the kernel apparently can't count on reasonable userspace >> support, turn this thing off by default. >> >> commit a3bd8447be4ea2ce230eb8ae0e815c04d85fa15a >> Author: Tom Gundersen >

Re: [systemd-devel] guidance on how to get systemd to function

On Fri, Aug 2, 2013 at 12:01 PM, lux-integ wrote: > Would you care to elaborate what PID1 is please? I suggest you read up on systemd to answer this and many other standard questions. The link posted by Reindl is a good start, but I suggest also reading all the links under "Manuals and Documenta

Re: [systemd-devel] guidance on how to get systemd to function

On Fri, Aug 2, 2013 at 11:03 AM, lux-integ wrote: > Firstly I read somewhere that I need to add > > init=/usr/lib/systemd/systemd to /boot/grub/grub.cfg > to get systemd to work. This is the only definite piece of advice I have been > able to garner from my search on the internet. That sounds

Re: [systemd-devel] macros in systemd unit files question

On Thu, Aug 1, 2013 at 4:25 PM, lux-integ wrote: > On Thursday 01 August 2013 12:58:46 Tom Gundersen wrote: >> 'm not following. Do you mean that systemd is already doing what you >> need, > > > not sure as I am just learning > > > ...but suppose > I

Re: [systemd-devel] macros in systemd unit files question

On Thu, Aug 1, 2013 at 1:45 PM, lux-integ wrote: > On Thursday 01 August 2013 12:15:21 Colin Guthrie wrote: >> The rootfs mount is called -.mount (i.e. a leading -) > many thanks for this >> To be honest with you tho', unless you are tailoring your system for a >> very specific case > > yes this i

Re: [systemd-devel] macros in systemd unit files question

On Wed, Jul 31, 2013 at 4:03 PM, lux-integ wrote: > #-- > IF mountpoint exists > /bin/echo "obladee" > /bin/mount /dev/something $mountpoint > ELSE > /bin/echo "obladaa" > /bin/mount /dev/something somewherelse > ENDiF > #-- > > does this file need to be s

Re: [systemd-devel] macros in systemd unit files question

On Wed, Jul 31, 2013 at 3:05 PM, lux-integ wrote: > On Wednesday 31 July 2013 13:26:18 Tom Gundersen wrote: >> If you really need a proper programming >> language, then you'd be better off using a script and pointing >> ExecStart to that. > > example please? Make

Re: [systemd-devel] macros in systemd unit files question

Hi, On Wed, Jul 31, 2013 at 2:14 PM, lux-integ wrote: > > I am trying to learn systemD. I scaned through some of the man pages. I am > here asking if systemD unit file synthesis can be made to support macros; > for example of the following type:- > > #-- > IF mountpoint exists >

Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount

On Tue, Jul 30, 2013 at 8:41 PM, Vivek Goyal wrote: > On Tue, Jul 30, 2013 at 07:34:01PM +0100, Colin Guthrie wrote: >> 'Twas brillig, and Vivek Goyal at 30/07/13 15:26 did gyre and gimble: >> FYI, I don't see any CC's on the original mail as displayed on GMane via >> NNTP... > > I am CCed in orig

Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount

On Tue, Jul 30, 2013 at 4:13 PM, Harald Hoyer wrote: > On 07/30/2013 03:46 PM, Zbigniew Jędrzejewski-Szmek wrote: >> Maybe rootfsflags=nofail could do be used as this flag? > > rootfsflags=nofail sounds ok, if it is not used for booting the initial > system. Yeah, you are right, this looks like

Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount

On Tue, Jul 30, 2013 at 2:27 PM, WANG Chao wrote: > On 07/30/13 at 02:05pm, Tom Gundersen wrote: >> On Tue, Jul 30, 2013 at 1:53 PM, WANG Chao wrote: >> > - It's not before initrd-root-fs.target. > In case of kdump, 2nd kernel initrd is used to mount non-root local/re

Re: [systemd-devel] [PATCH] fstab-generator: introduce rd.weak_sysroot to bypass failures in sysroot.mount

On Tue, Jul 30, 2013 at 1:53 PM, WANG Chao wrote: > If specified kernel command line rd.weak_sysroot, fstab-generate will > generate a weaker version of sysroot.mount: > - It's not required by initrd-root-fs.target. > - It's not before initrd-root-fs.target. > > So that failure in the weaker sys

Re: [systemd-devel] /home Fails to Mount During Boot

On Sun, Jul 28, 2013 at 12:13 AM, Garry T. Williams wrote: > Recently, my /home file system fails to mount during boot. The > relevant message is: > > systemd[1]: Job dev-sda4.device/start timed out. > systemd[1]: Timed out waiting for device dev-sda4.device. > > I'm dropped to a prompt f

Re: [systemd-devel] [PATCH] build: allow specifying a custom pam session name

On Fri, Jul 26, 2013 at 12:28 AM, Marc-Antoine Perennou wrote: > for distribution now wanting to use "systemd-shared" Could you explain a bit more why this needs to be configurable? What's the usecase? Cheers, Tom ___ systemd-devel mailing list system

Re: [systemd-devel] [PATCH] tmpfiles: don't apply --create to /dev twice during boot

On Wed, Jul 24, 2013 at 4:09 PM, Lennart Poettering wrote: > On Wed, 24.07.13 15:49, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > >> >> On Wed, Jul 24, 2013 at 03:32:55PM +0200, Tom Gundersen wrote: >> > Instead allow negation in the prefix filtering, to re

[systemd-devel] [PATCHv2] tmpfiles: don't apply --create to /dev twice during boot

We used to call systemd-tmpfiles --prefix=/dev --create --remove systemd-udevd systemd-tmpfiles --create --remove which caused a bug: The first call would create dead device nodes, udev would change permissions on these nodes, before the second call to tmpfiles would reset the permissions

Re: [systemd-devel] [PATCH] tmpfiles: don't apply --create to /dev twice during boot

On Wed, Jul 24, 2013 at 3:49 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Jul 24, 2013 at 03:32:55PM +0200, Tom Gundersen wrote: >> Instead allow negation in the prefix filtering, to restrict the >> second call to apply to everything but /dev: >> >> systemd-tmpfi

[systemd-devel] [PATCH] tmpfiles: don't apply --create to /dev twice during boot

We used to call systemd-tmpfiles --prefix=/dev --create --remove systemd-udevd systemd-tmpfiles --create --remove which caused a bug: The first call would create dead device nodes, udev would change permissions on these nodes, before the second call to tmpfiles would reset the permissions

Re: [systemd-devel] removal of RD_TIMESTAMP support in initrd

On Tue, Jul 23, 2013 at 12:44 AM, Lennart Poettering wrote: > I do understand that you are currently not running systemd in the initrd > [1], so for you for now this is indeed a loss of functionality. I am > sorry for that, but please understand this as gentle push to maybe use > systemd in the in

Re: [systemd-devel] Excluding .hwdb files

On 22 Jul 2013 18:19, "Michael Biebl" wrote: > > 2013/7/22 Kay Sievers : > > On Mon, Jul 22, 2013 at 3:32 PM, Umut Tezduyar wrote: > >> For an embedded system that is not using hwdb.bin, we are shipping > >> roughly 4 mb .hwdb files under /usr/lib/udev/hwdb.d. Is it > >> distributions responsibil

Re: [systemd-devel] [PATCH][usbutils] lsusb: port to hwdb

On Sun, Jul 21, 2013 at 3:34 AM, Greg KH wrote: > Can this mean I can drop the usb.ids file from the usbutils package? I > can't remember where hwdb is generated from, does it rely on the usb.ids > file for the initial creation? hwdb does not use the usb.ids from the usbutils package. However,

[systemd-devel] [PATCH][usbutils] lsusb: port to hwdb

644 --- a/names.c +++ b/names.c @@ -3,6 +3,7 @@ * names.c -- USB name database manipulation routines * * Copyright (C) 1999, 2000 Thomas Sailer (sai...@ife.ee.ethz.ch) + * Copyright (C) 2013 Tom Gundersen (t...@jklm.no) * * This program is free software; you can redistribute

[systemd-devel] [PATCH][pciutils] libpci: pci_id_lookup - add udev/hwdb support

Small correction to the subject, it should have said: [PATCH][pciutils] libpci: pci_id_lookup - add udev/hwdb support On Sat, Jul 20, 2013 at 10:44 PM, Tom Gundersen wrote: > This lets you select hwdb support at compile time. > > hwdb is an efficient hardware database shipped wi

Re: [systemd-devel] [PATCH][pciutils] lspci: pci_id_lookup - add udev/hwdb support

On Sat, Jul 20, 2013 at 10:54 PM, Michael Biebl wrote: > 2013/7/20 Tom Gundersen : >> Ideally Linux distros using systemd would like to not ship pci.ids, but use >> hwdb as the only source >> of this information, which this patch allows. > > I don't think you stri

[systemd-devel] [PATCH][pciutils] lspci: pci_id_lookup - add udev/hwdb support

This lets you select hwdb support at compile time. hwdb is an efficient hardware database shipped with recent versions of systemd/udev. It contains among other sources pci.ids so querying hwdb rather than reading pci.ids directly should give the same result. Ideally Linux distros using systemd

Re: [systemd-devel] /etc/systemd/system/darkice.service

On Thu, Jul 18, 2013 at 2:27 PM, Lennart Poettering wrote: > On Thu, 18.07.13 18:01, Kai Hendry (hen...@iki.fi) wrote: >> [root@pihsg ~]# systemctl status darkice.service >> darkice.service - DarkIce audio forwarder >>Loaded: loaded (/etc/systemd/system/darkice.service; enabled) >>Active:

Re: [systemd-devel] hwdb for gphoto2

On Wed, Jul 17, 2013 at 11:54 AM, Kay Sievers wrote: > On Wed, Jul 17, 2013 at 11:31 AM, Tom Gundersen wrote: >> Hi guys, >> >> Here is an attempt at converting libgphoto2 to hwdb. Seems to work for my >> phone. >> >> hwdb file: <https://dev.archli

[systemd-devel] hwdb for gphoto2

Hi guys, Here is an attempt at converting libgphoto2 to hwdb. Seems to work for my phone. hwdb file: patch: Comments welcome. Cheers, Tom ___

Re: [systemd-devel] hwdb for sane

On Wed, Jul 17, 2013 at 9:36 AM, Tom Gundersen wrote: > On Wed, Jul 17, 2013 at 1:57 AM, Tom Gundersen wrote: >> Hi guys, >> >> I had a stab at converting sane to using hwdb rather than a huge udev >> rules file. >> >> For now only the usb entries have bee

Re: [systemd-devel] hwdb for sane

On Wed, Jul 17, 2013 at 1:57 AM, Tom Gundersen wrote: > Hi guys, > > I had a stab at converting sane to using hwdb rather than a huge udev > rules file. > > For now only the usb entries have been converted, I didn't look at how > to deal with scsi. > > hwdb

[systemd-devel] hwdb for sane

Hi guys, I had a stab at converting sane to using hwdb rather than a huge udev rules file. For now only the usb entries have been converted, I didn't look at how to deal with scsi. hwdb file: udev rules:

Re: [systemd-devel] [PATCHv3 2/2] logind: apply ACL's to "dead" device nodes

On Tue, Jul 16, 2013 at 8:39 PM, Lennart Poettering wrote: > On Tue, 16.07.13 19:38, Tom Gundersen (t...@jklm.no) wrote: > >> -udev_enumerate_unref(e); >> +/* udev exports "dead" device nodes to allow module on-demand >> loading, >>

[systemd-devel] [PATCHv3 2/2] logind: apply ACL's to "dead" device nodes

Based on a patch by Kay Sievers. When a dead device nodes is tagged with "uaccess" using the static_node mechanism, it's ACL's are managed by logind in the same way as "live" device nodes. This allows in particular /dev/snd/{seq,timer} to cause modules to be loaded on-demand when accessed by a n

[systemd-devel] [PATCHv3 1/2] udev: export tags of "dead" device nodes to /run/udev/static_node-tags/

Based on a patch by Kay Sievers. A tag is exported at boot as a symlinks to the device node in the folder /run/udev/static_node-tags//, if the device node exists. These tags are cleaned up by udevadm info --cleanup-db, but are otherwise never removed. --- man/udev.xml | 10 --

Re: [systemd-devel] [PATCHv2 1/2] udev: export tags of "dead" device nodes to /run/udev/static_node-tags/

On Sun, Jul 14, 2013 at 2:51 PM, Dave Reisner wrote: >> @@ -152,9 +153,9 @@ enum token_type { >> TK_A_OWNER_ID, /* uid_t */ >> TK_A_GROUP_ID, /* gid_t */ >> TK_A_MODE_ID, /* mode_t */ >> +TK_A_TAG,

Re: [systemd-devel] runtime directories for services vs. tmpfiles

On Tue, Jul 16, 2013 at 6:34 PM, Zbigniew Jędrzejewski-Szmek wrote: > Hm, can we take a step back for a moment? It seems that the rpm macros > are a fairly complicated solution, and they also don't carry over into > debian or arch. User mode sessions also will not work with rpm macros. For what i

Re: [systemd-devel] runtime directories for services vs. tmpfiles

Hi Michael, On Tue, Jul 16, 2013 at 3:24 AM, Michael Biebl wrote: > an interesting issue was raised as part of reviewing a patch for > iodione [1], a system service which needs a runtime directory. We > thought this might need further dicussion, so reposting the issue to > systemd-devel: > > For

Re: [systemd-devel] kmod-static-nodes.service doesn't care about udev?

On Fri, Jul 12, 2013 at 7:57 PM, Zbigniew Jędrzejewski-Szmek wrote: > I see another problem: in a container, this unit fails with: > # /usr/bin/kmod static-nodes --format=tmpfiles > --output=/run/tmpfiles.d/kmod.conf > Error: could not open /lib/modules/3.9.6-301.fc19.x86_64/modules.devname - No

Re: [systemd-devel] Manpage updates

On Mon, Jul 15, 2013 at 12:28 PM, Colin Guthrie wrote: > I think some threading/mail client mixup on David's part has resulted in > him not seeing all that was posted Most probably due to GMail (or something similar) ignoring In-Reply-To, and instead grouping messages by Subject. -t

[systemd-devel] [PATCHv2 2/2] logind: apply ACL's to "dead" device nodes

Based on a patch by Kay Sievers. When a dead device nodes is tagged with "uaccess" using the static_node mechanism, it's ACL's are managed by logind in the same way as "live" device nodes. This allows in particular /dev/snd/{seq,timer} to cause modules to be loaded on-demand when accessed by a n

[systemd-devel] [PATCHv2 1/2] udev: export tags of "dead" device nodes to /run/udev/static_node-tags/

Based on a patch by Kay Sievers. A tag is exported at boot as a symlinks to the device node in the folder /run/udev/static_node-tags//, if the device node exists. These tags are cleaned up by udevadm info --cleanup-db, but are otherwise never removed. --- v2: use directories of symlinks, rather

Re: [systemd-devel] kmod-static-nodes.service doesn't care about udev?

On Fri, Jul 12, 2013 at 8:42 PM, Lennart Poettering wrote: > On Fri, 12.07.13 20:37, Tom Gundersen (t...@jklm.no) wrote: > >> >> On Fri, Jul 12, 2013 at 7:57 PM, Zbigniew Jędrzejewski-Szmek >> wrote: >> > I see another problem: in a container, this unit fails

Re: [systemd-devel] kmod-static-nodes.service doesn't care about udev?

On Fri, Jul 12, 2013 at 7:57 PM, Zbigniew Jędrzejewski-Szmek wrote: > I see another problem: in a container, this unit fails with: > # /usr/bin/kmod static-nodes --format=tmpfiles > --output=/run/tmpfiles.d/kmod.conf > Error: could not open /lib/modules/3.9.6-301.fc19.x86_64/modules.devname - No

Re: [systemd-devel] kmod-static-nodes.service doesn't care about udev?

On Fri, Jul 12, 2013 at 8:16 PM, Lennart Poettering wrote: > Oh, humm, does the unit file really belong in systemd? Sounds like > something that should be in kmod, no? I don't have a strong opinion about where the unit should live. As far as I remember Lucas requested I put it in systemd, but I f

Re: [systemd-devel] kmod-static-nodes.service doesn't care about udev?

On Fri, Jul 12, 2013 at 7:08 PM, Lennart Poettering wrote: > On Fri, 12.07.13 09:28, Oleksii Shevchuk (alx...@gmail.com) wrote: > >> Latest innovation with kmod-static-nodes.service introduce next issues with >> >> 1. default distro paths >> 2. interacting with rest configuration >> >> So, what is

Re: [systemd-devel] kmod-static-nodes.service doesn't care about udev?

On 12 Jul 2013 08:28, "Oleksii Shevchuk" wrote: > > Latest innovation with kmod-static-nodes.service introduce next issues with > > 1. default distro paths > 2. interacting with rest configuration > > So, what is the problem. > > kmod-static-nodes.service.in: > > ExecStartPre=/usr/bin/mkdir -p /ru

Re: [systemd-devel] [PATCH] static-nodes: move creation of static nodes from udevd to tmpfiles

On Mon, Jul 8, 2013 at 9:09 AM, Umut Tezduyar wrote: > Hi. I thought they serve for the same purpose. One generates device > node information, other one creates the devices. I have no objection > either but I thought we have documentation etc ready for > systemd-static-nodes.service. I pushed thi

[systemd-devel] [PATCH] manage ACL's on "dead" device nodes

Hi guys, I resurrected an old patch by Kay to allow logind to manage ACL's on static device nodes, in an attempt to fix https://bugs.archlinux.org/task/29048. I made some changes, so any bugs are on me ;-) Comments? Cheers, Tom 0001-tag-dead-device-nodes.patch Description: Binary data 0002

Re: [systemd-devel] [PATCH] static-nodes: move creation of static nodes from udevd to tmpfiles

Hi Umut, On Sun, Jul 7, 2013 at 8:11 PM, Umut Tezduyar wrote: > Just a suggestion, can kmod-static-nodes.service be merged to > systemd-static-nodes.service and have 2 ExecStartPre= as: > > ExecStartPre=/usr/bin/mkdir -p /run/tmpfiles.d > ExecStartPre=/usr/bin/kmod static-nodes --format=tmpfiles

[systemd-devel] [PATCH] static-nodes: move creation of static nodes from udevd to tmpfiles

Hi guys, Any objections to pushing this patch (attached as I'm having problems with sendmail): As of kmod v14 (currently in Fedora Rawhide and Arch Linux [core]), it is possible to export the static node information from /lib/modules/`uname -r`/modules.devname in tmpfiles.d(5) format.

Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc

On Fri, Jul 5, 2013 at 10:04 PM, Michael Biebl wrote: > My very first idea was [1], to use /lib/udev for the cache file as > long as /etc/udev/hwdb.d was empty. > And as soon as files are added to /etc/udev/hwdb.d, the cache file is > generated in /etc/udev and udev will first try to read the cach

Re: [systemd-devel] Text input on startup (tty-force) disabling after a few seconds

Didn't cryptsetup recently get TC support? Could you use that (i.e. /etc/crypttab? On Jun 19, 2013 6:01 PM, "Peeters Simon" wrote: > > 2013/6/19 Natanji : > > Hi everyone, > > I'm somewhat new to systemd and have a problem. I would like to run a > > custom script with systemd on startup that will

Re: [systemd-devel] Problems with SWAP in 204

On Wed, Jun 19, 2013 at 12:16 AM, Henrik /KaarPoSoft wrote: > When booting, I get a few errors related to swap; in particular: > Failed to reread /proc/swaps: File exists > swapon: /dev/sda3: swapon failed: Device or resource busy The output of "systemctl --full --all --type=swap" might be useful

Re: [systemd-devel] [PATCH] udev: Make builtin firmware to find in subdirectories

On Mon, Jun 17, 2013 at 9:57 PM, Greg KH wrote: > In fact, we should really just delete the firmware logic from udev > entirely now that the kernel doesn't even call it anymore, right? This fimware logic is not compiled by default, but for people with old kernels it can be enabled with a configur

Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc

On Mon, Jun 17, 2013 at 7:43 PM, Michael Biebl wrote: > I guess we can all agree that the cache file in /etc is not really nice and > that > /etc/ld.so.cache already exists, doesn't really make that better. > A 5+ MB blob is really annoying, especially if you use tools like etckeeper. > Putting t

Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc

Hi Martin, On Fri, Jun 14, 2013 at 2:15 PM, Martin Pitt wrote: > I tought about using /var/cache/ first as well, but /var might be on a > different partition. Hence I was using /lib/udev (i. e. udevlibdir) as > this guaranteed to be on the same partition as all the other udev > helpers. Yeah, I

Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc

On Fri, Jun 14, 2013 at 2:03 PM, Łukasz Stelmach wrote: > It was <2013-06-14 pią 13:30>, when Jan Janssen wrote: >> On 06/14/2013 01:08 PM, Tom Gundersen wrote: >>> That said, I don't think libdir is appropriate as this data is not >>> under the control of t

Re: [systemd-devel] [PATCH] udev hwdb: Store binary database in libdir, not in /etc

On Fri, Jun 14, 2013 at 12:26 PM, Martin Pitt wrote: > right now, udev stores its binary hwdb cache in /etc/udev/, which is > ugly IMHO. This is neither user-editable nor configuration of any > kind. It's just a cache file, and does not need to appear in backup, > VCSes of /etc and the like. > > C

Re: [systemd-devel] x-initrd.mount + shutdown umount logic question

On Thu, Jun 13, 2013 at 11:13 PM, Colin Guthrie wrote: > If a mount has the x-initrd.mount option shouldn't it be excluded from > the umount loop during shutdown? Makes sense. Also see the patch "[PATCH] mount: Don't add conflicts with umount.target for certain mounts" just posted by Ross Lagerwa

Re: [systemd-devel] systemd-shutdown static linking

On Tue, Jun 11, 2013 at 10:59 AM, Thomas Bächler wrote: > I think this code is only called when there is no -.mount unit, which > results from a missing entry for / in fstab. It is entirely possible > that Ross didn't add / to his fstab by accident or on purpose. I just want to point out: This is

Re: [systemd-devel] systemd-shutdown static linking (was: Please proof-read: ...)

On Tue, Jun 11, 2013 at 10:07 AM, Umut Tezduyar wrote: > Those 2 lines were added on 89b1d5e0e49d3b3501e5f3aadcad712290bcd9bf and the > commit log explains why we needed them. "/" can be treated as special case > and excluded. If so, I guess also /usr and anything marked x-initrd.mount should be

Re: [systemd-devel] Build option to disable systemd-tmpfiles services

On Mon, Jun 3, 2013 at 4:15 PM, Colin Guthrie wrote: > 'Twas brillig, and Umut Tezduyar at 02/06/13 10:09 did gyre and gimble: >> How do you attach patches to the email thread? I have tried following >> command and it still poped up in a different thread: >> >> git send-email >> --in-reply-to=cag-

Re: [systemd-devel] Build option to disable systemd-tmpfiles services

On Mon, Jun 3, 2013 at 3:24 PM, Kay Sievers wrote: > Mind trying to move the stuff into one (or at least fewer) section > instead of adding a ton of ifdefs for the same conditional? > > Thanks, > Kay Done. -t ___ systemd-devel mailing list systemd-deve

<    5   6   7   8   9   10   11   12   13   >