Re: [systemd-devel] [udev] Giving exclusive rights over a sound card to a user
Brilliant, worked like a charm : $ ls -l /dev/snd/ total 0 drwxr-xr-x 2 rootroot 60 11 janv. 00:52 by-id drwxr-xr-x 2 rootroot 100 11 janv. 00:52 by-path crw-rw+ 1 rootaudio 116, 2 11 janv. 00:52 controlC0 crw-rw+ 1 rootaudio 116, 7 11 janv. 00:52 controlC1 crw-rw 1 navaati audio 116, 12 11 janv. 00:52 controlC2 crw-rw+ 1 rootaudio 116, 6 11 janv. 00:52 hwC0D0 crw-rw+ 1 rootaudio 116, 11 11 janv. 00:52 hwC1D0 crw-rw+ 1 rootaudio 116, 3 11 janv. 00:55 pcmC0D3p crw-rw+ 1 rootaudio 116, 4 11 janv. 00:55 pcmC0D7p crw-rw+ 1 rootaudio 116, 5 11 janv. 00:55 pcmC0D8p crw-rw+ 1 rootaudio 116, 9 11 janv. 00:55 pcmC1D0c crw-rw+ 1 rootaudio 116, 8 11 janv. 00:55 pcmC1D0p crw-rw+ 1 rootaudio 116, 10 11 janv. 00:52 pcmC1D2c crw-rw 1 navaati audio 116, 13 11 janv. 00:55 pcmC2D0p === SUCCESS ! crw-rw+ 1 rootaudio 116, 1 11 janv. 00:52 seq crw-rw+ 1 rootaudio 116, 33 11 janv. 00:52 timer And pulseaudio gets it right, I get exactly the desired behaviour. Thanks a lot ! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd --user broken
Hi. All these big changes from systemd 205 seem good and yummy, but how do this relates to the systemd --user sessions ? I used to launch all my desktop components (WM, panel, applets, pulseaudio...) using systemd user units, systemd --user itself being launched by my display manager, but now it crashes at launch saying Failed to create root cgroup hierarchy: Permission denied and Failed to allocate manager object: Permission denied. Is this a bug, or should a totally new paradigm be used for user sessions ? I find it surprising that apparently no one has yelled at this yet, but I couldn't find any interesting thread about this issue. I hope it's not me being bad at googling. Regards, Léo Gillot-Lamure. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] EFI boot generator failing to detect I'm actually booting on EFI
Hi. I run an EFI system with gentoo, gummiboot and systemd 202 (and no initramfs). I'm expecting my ESP to be mounted on /boot thanks to the systemd-efi-boot-generator, however it is not. By stracting it for the open syscall, I can see that the last call is this one, before EXIT_SUCCESSing : open(/sys/firmware/efi/efivars/LoaderDevicePartUUID-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f, O_RDONLY|O_NOCTTY|O_CLOEXEC) = -1 ENOENT (No such file or directory) Thus the failing call is efi_get_loader_device_part_uuid at line 58 of efi-boot-generator.c not finding the LoaderDevicePartUUID variable. Is my firmware buggy ? Could the generator be modified to work anyway ? Thanks. Léo Gillot-Lamure. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] EFI boot generator failing to detect I'm actually booting on EFI
My module is built in the kernel (actually modules support is disabled on my kernel), and the /sys/firmware/efi/ is here and properly usable (for example efibootmgr works). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] EFI boot generator failing to detect I'm actually booting on EFI
Yup, I have both. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Fwd: EFI boot generator failing to detect I'm actually booting on EFI
Aaaah, crap, that was it : too old gummiboot, I think I was using version 7 or 10... Now (I've stolen a binary from f19 package because I couldn't build it) it works and I've even got firmware time information in systemd-analyze (a 30s spent in firmware…). Thanks for the help and the good job ! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Start and stop actions of device units
Hi. Would it be possible to bind something to the start and stop actions of a device unit ? I've got a device (a hard drive) that I can programmatically plug/unplug using commands such as echo '0 0 0' /sys/class/scsi_host/host1/ scan and echo 1 /sys/devices/pci:00/:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/delete. The goal is reducing noise. It would be nice to bind these commands in the device unit itself so that other units needing it can start it by themselves, etc. Thanks, Léo Gillot-Lamure. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] $PWD=/ in systemd --user
Hi. I'm running a user session using systemd --user and my PWD in the session (visible, for example, when launching a xterm) is / instead of $HOME as one would expect. That's a bit annoying. I tried to wrap systemd --user in a script doing cd $HOME before exec'ing it, but it doesn't change anything. Have you guys using the user session noticed the same thing ? Regards, Léo Gillot-Lamure. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd based gnome-session
Hi. I've read the unit files you provide and I'm wondering about a possible race condition related to dbus activation. For example let's see the unit gconf.service: [Unit] Description=settings daemon for gnome [Service] Type=dbus BusName=org.gnome.GConf ExecStart=/usr/libexec/gconfd-2 [Install] WantedBy=gnome.target Alias=dbus-org.gnome.GConf.service Why this line Alias= ? Creating this alias is only useful if you add a line SystemdService=dbus-org.gnome.GConf.service to the file /usr/share/dbus-1/services/org.gnome.GConf.service (this is a major pain in the current dbus and systemd architecture…). Moreover, even if you did, I thought that bus activation in the user session was not implemented ? (I'd be very happy to be proved wrong here :). Now, in such a situation, this is how a race condition can appear: Let's say that gnome-settings-daemon makes use of the well known name org.gnome.GConf on the bus (it's probably the case). Usually, gconf.service will be launched, will take the name on the bus, then gnome-settings-daemon.service will be launched, will talk to this name, gconf will answer and everything is fine. However gconf.service and gnome-settings-daemon.service are actually launched *in parallel*. Let's imagine than for any reason gconf.service takes a looong time before taking the well-know name on the bus. During this time gnome-settings-daemon launches and try to talk to org.gnome.GConf. Since no one owns this name (remember, gconf.service is a snail today), the dbus daemon will launch gconf according to the file /usr/share/dbus-1/services/org.gnome.GConf.service. This causes the first problem : the gconf daemon will be part of the dbus.service cgroup, which is bad. Then a second problem appears : gconf.service finally awakes from its nap and try to take the name on the bus. Ooops : it's already taken by the daemon launched by dbus-daemon… Thus gconf.service will fail. Race condition, not good. The exact same kind of stuff appears with pulseaudio (launched by gnome-settings-daemon aswell) and virtually any bus-activated user service that you'd like to be a service managed by systemd instead of dbus-daemon. Regards, Léo Gillot-Lamure. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] GDM service file (was: systemd unit files for Debian based systems)
Simple suggestion : GDM takes a name on the bus, so you can reliably know when the service has finished to start. The service file used in Gentoo adds a line BusName=org.gnome.DisplayManager in the [Service] section to achieve that. signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Systemd socket activation of DBus in the user session
Hello. I'm trying to get systemd work as the user session supervisor, thus i want it to launch the dbus daemon for the session. Systemd seems to require that dbus is socket activated (service units of Type=dbus have a Require dep on dbus.socket, not on dbus.service), so i created the relevant .socket and .service unit files. Taking inspiration from the unit files at the system level, i put /usr/bin/dbus-daemon --session --address=systemd: --nofork --systemd-activation as the ExecStart command line for the daemon. The session boots up, the dbus daemon is launched by the socket activation, the gnome panel is properly launched (trough a unit file) and registers to the bus, messages on the bus are correctly passed, everything seems fine. Except the bus-activation of services. For example launching gnome-terminal doesn't work because it tries to launch something (can't remember what, maybe it was gconf, or some gvfs stuff) using the bus and it fails. The result is exactly the same when not using the --systemd-activation flag. This message http://lists.freedesktop.org/archives/systemd-devel/2012-May/005301.html says that it's a dbus bug, because the daemon launches bus-activated processes with DBUS_SESSION_BUS_ADDRESS==systemd:,guid=hash which is broken. Thus arise two questions : - Auke, considering this problem how did you manage to get the session-wide DBus work in your Meego systemd --user experiment ? - Dear DBus folks, could this bug be fixed ? Maybe there are already patches around fixing it ? I could not see any mention of it on the mailing list. Thanks, Léo Gillot-Lamure. signature.asc Description: This is a digitally signed message part ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
