[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
Re: [systemd-devel] systemd --user broken
On Sat, Jul 27, 2013 at 4:50 PM, Léo Gillot-Lamure leo.gil...@navaati.net wrote: 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. systemd --user is now always started as a service by PID1, triggered by logind. $ tree -d /sys/fs/cgroup/systemd/user.slice/ /sys/fs/cgroup/systemd/user.slice/ `-- user-2702.slice |-- session-1.scope `-- user@2702.service You need to chown() the cgroup subtree yourself if you start your own systemd --user. It all needs still some work how things should work in the end, we are not quite there to offer a fully working default setup of systemd --user. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd --user broken
It all needs still some work how things should work in the end Unfortunately, with shared session daemon there is no way to have display session managed by systemd -- too many problems should be solved. Mainly with attaching services to active seat/session (for polkit), environment propagation and so on.. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd --user broken
On Sat, Jul 27, 2013 at 6:24 PM, Oleksii Shevchuk alx...@gmail.com wrote: It all needs still some work how things should work in the end Unfortunately, with shared session daemon It is, and always was, designed as a --user daemon, just like the name suggests, not as a session daemon. With the upcoming kdbus work, systemd --user will be the creator and owner of the user's bus, and there can and should only be one per user and no per session. there is no way to have display session managed by systemd Apps/services are per user, right, not per session. The session runs in the session cgroup, it is kind of managed by PID1 now. There are just pieces missing, it's not a no way thing. too many problems should be solved. No doubt, there is a lot of stuff open to solve and which needs quite some work. Mainly with attaching services to active seat/session (for polkit), environment propagation and so on.. Right, it's nothing that works out of the box today, but we will get there. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] man: systemd.unit: fix volatile path
The volatile path was '/run/systemd/systemd' when it should be '/run/systemd/system'. Fix. --- man/systemd.unit.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml index f6a0791..2f65ec6 100644 --- a/man/systemd.unit.xml +++ b/man/systemd.unit.xml @@ -285,7 +285,7 @@ entryLocal configuration/entry /row row - entryfilename/run/systemd/systemd/filename/entry +entryfilename/run/systemd/system/filename/entry entryVolatile units/entry /row row -- 1.7.12.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: systemd.unit: fix volatile path
Attaching the patch since I don't have a mail client at the moment that can keep itself from breaking patches. On Sat, Jul 27, 2013 at 9:55 AM, Brandon Philips bran...@ifup.co wrote: The volatile path was '/run/systemd/systemd' when it should be '/run/systemd/system'. Fix. --- man/systemd.unit.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml index f6a0791..2f65ec6 100644 --- a/man/systemd.unit.xml +++ b/man/systemd.unit.xml @@ -285,7 +285,7 @@ entryLocal configuration/entry /row row - entryfilename/run/systemd/systemd/filename/entry + entryfilename/run/systemd/system/filename/entry entryVolatile units/entry /row row -- 1.7.12.4 0001-man-systemd.unit-fix-volatile-path.patch Description: Binary data ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd --user broken
It is, and always was, designed as a --user daemon, just like the name suggests, not as a session daemon. With the upcoming kdbus work, systemd --user will be the creator and owner of the user's bus, and there can and should only be one per user and no per session. I understand this. But.. That's sad, when really good user expierence throwed away. Have no idea what to do with per-user daemon, that is unattached to any session. Apps/services are per user, right, not per session. Currently most apps are per-session, or at least heavily linked with it (connected to keychain manager, i/o console etc) Right, it's nothing that works out of the box today, but we will get there. Is there any place where I can get info about expected end point of that process? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd --user broken
On Sat, Jul 27, 2013 at 7:30 PM, Oleksii Shevchuk alx...@gmail.com wrote: It is, and always was, designed as a --user daemon, just like the name suggests, not as a session daemon. With the upcoming kdbus work, systemd --user will be the creator and owner of the user's bus, and there can and should only be one per user and no per session. I understand this. But.. That's sad, when really good user expierence throwed away. Have no idea what to do with per-user daemon, that is unattached to any session. It might currently work better, because things have worked that way in the past and are therefore more easily to be used without modifications. But that doesn't mean that we want to model after that or that is the best way to do it. At this moment in time, it should be reasonable straight-forward to get the current setup work like it did before the slice stuff. Apps/services are per user, right, not per session. Currently most apps are per-session, or at least heavily linked with it (connected to keychain manager, i/o console etc) Keychains probably belong into the kernel keychain, and not in userspac at alle, not in a session and not in the user daemon's context. For most other things: there are actually very few things that should use the environment as a data store and to pass around config/policy/runtime information; it's just a too broken and static model that should no be used in this century. Right, it's nothing that works out of the box today, but we will get there. Is there any place where I can get info about expected end point of that process? No, it's just ideas that happened between talking about it, only at the moment we actually implement it, we will find out. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: systemd.unit: fix volatile path
On Sat, Jul 27, 2013 at 6:58 PM, Brandon Philips bran...@ifup.co wrote: Attaching the patch since I don't have a mail client at the moment that can keep itself from breaking patches. No problem, attachments are totally fine on this list. Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd --user broken
For most other things: there are actually very few things that should use the environment as a data store and to pass around config/policy/runtime information; it's just a too broken and static model that should no be used in this century. Probably yes. But who and when will reimplement all the stuff? Ok, active session detection can be easily changed within systemd/logind (probably) to active user detection, but what about DISPLAY= (the problem of selecting default console for new instances)? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd --user broken
On Sat, Jul 27, 2013 at 8:03 PM, Oleksii Shevchuk alx...@gmail.com wrote: For most other things: there are actually very few things that should use the environment as a data store and to pass around config/policy/runtime information; it's just a too broken and static model that should no be used in this century. Probably yes. But who and when will reimplement all the stuff? Its should be rather trivial changes, nothing in the sense of like re-implementations. Ok, active session detection can be easily changed within systemd/logind (probably) to active user detection, but what about DISPLAY= (the problem of selecting default console for new instances)? It's a symlink, which X should read: $ ls -l $XDG_RUNTIME_DIR/X11-display lrwxrwxrwx 1 root root 17 Jul 27 15:39 /run/user/2702/X11-display - /tmp/.X11-unix/X0 We will very unlikely support multiple graphical logins of the same user at the same time, in any default setup. Custom setups or setups which declare that as supported will need to add their own logic to make that possible. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Create a new logind session from a systemd --user unit
Hello, I'm happily using systemd 204 user instance to handle my desktop (xorg, awesome wm, mpd, etc.) in Arch. I started experimenting with systemd 206 trying to adapt my setup to the changes in cgroups, slices, and all that. In 206, systemd user session is started automatically by pam_systemd when I login to a tty. Then, I want to manually launch my window manager, in a new logind session for my user, on a different tty. I tried adding User and PAMName to my window manager unit awesome.service: [Unit] Description=Awesome window manager After=xorg@0.service Requisite=xorg@0.service Requires=dbus.socket [Service] User=abdo PAMName=login TTYPath=/dev/tty7 Type=simple SyslogIdentifier=awesome Environment=DISPLAY=:0 ExecStart=/home/abdo/.config/systemd/scripts/awesome.sh start KillSignal=SIGINT TimeoutSec=15 However, as soon as I start the service with systemctl --user start awesome.service The unit fails with message systemd[21209]: Failed at step GROUP spawning /home/abdo/.config/systemd/scripts/awesome.sh: Operation not permitted Running the same service from the system systemd instance (with an already running user-owned xorg), works as expected, creating a new session. I think it fails setting the group for the process, it does not even get to the PAM stuff. The user abdo is the same for which the systemd user instance is running, of course. Is this a bug in systemd or it's me missing something? Thanks! Abdó. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] /home Fails to Mount During Boot
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 for root's password and after receiving a shell prompt, the command mount /home completes without error and after exiting the shell the boot-up proceeds normally. This is sort of new behavior. I saw it once or twice during the last few months, but now, after updating to kernel 3.10.3-300.fc19.x86_64, it happens on each boot. How can I debug this problem? systemd-204-9.fc19.x86_64 kernel-3.10.3-300.fc19.x86_64 /etc/fstab: /dev/sda4 /home btrfs noatime 0 0 The /home file system is a raid1 btrfs across two identical drive partitions, sda4 and sdb4. Log: Jul 27 17:33:42 vfr systemd[1]: Mounted /boot. Jul 27 17:33:42 vfr kernel: EXT4-fs (md0): mounted filesystem with ordered data mode. Opts: (null) Jul 27 17:33:42 vfr kernel: SELinux: initialized (dev md0, type ext4), uses xattr Jul 27 17:35:08 vfr systemd[1]: Job dev-sda4.device/start timed out. Jul 27 17:35:08 vfr systemd[1]: Timed out waiting for device dev-sda4.device. Jul 27 17:35:08 vfr systemd[1]: Dependency failed for /home. Jul 27 17:35:08 vfr systemd[1]: Dependency failed for Local File Systems. Jul 27 17:35:08 vfr systemd[1]: Dependency failed for Mark the need to relabel after reboot. Jul 27 17:35:08 vfr systemd[1]: Dependency failed for Relabel all filesystems, if necessary. Jul 27 17:35:08 vfr systemd[1]: Triggering OnFailure= dependencies of local-fs.target. Jul 27 17:35:08 vfr systemd[1]: Stopped Daily Cleanup of Temporary Directories. Jul 27 17:35:08 vfr systemd[1]: Stopped IPv4 firewall with iptables. Jul 27 17:35:08 vfr systemd[1]: Stopped ABRT Xorg log watcher. Jul 27 17:35:08 vfr systemd[1]: Stopped CUPS Printer Service Spool. Jul 27 17:35:08 vfr alsactl[427]: alsactl 1.0.27.2 daemon started Jul 27 17:35:09 vfr systemd-journal[278]: Allowing system journal files to grow to 100.0M. Jul 27 17:35:08 vfr systemd[1]: Started Trigger Flushing of Journal to Persistent Storage. Jul 27 17:35:08 vfr systemd[1]: Started Tell Plymouth To Write Out Runtime Data. Jul 27 17:35:08 vfr systemd[1]: Started Recreate Volatile Files and Directories. Jul 27 17:35:08 vfr systemd[1]: Started Security Auditing Service. Jul 27 17:35:08 vfr systemd[1]: Starting Update UTMP about System Runlevel Changes... Jul 27 17:35:08 vfr systemd[1]: Started Update UTMP about System Runlevel Changes. Jul 27 17:35:08 vfr systemd[1]: Startup finished in 1.311s (kernel) + 1.778s (initrd) + 1min 32.142s (userspace) = 1min 35.231s. Jul 27 17:35:08 vfr auditd[428]: Started dispatcher: /sbin/audispd pid: 438 Jul 27 17:35:08 vfr audispd[438]: priority_boost_parser called with: 4 Jul 27 17:35:08 vfr audispd[438]: max_restarts_parser called with: 10 Jul 27 17:35:08 vfr audispd[438]: audispd initialized with q_depth=120 and 1 active plugins Jul 27 17:35:08 vfr auditd[428]: Init complete, auditd 2.3.1 listening for events (startup state enable) Jul 27 17:35:08 vfr sedispatch[443]: Connection Error (Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory): AVC Will be dropped Jul 27 17:35:08 vfr sedispatch[443]: Connection Error (Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory): AVC Will be dropped Jul 27 17:35:13 vfr auditctl[429]: No rules Jul 27 17:35:13 vfr auditctl[429]: AUDIT_STATUS: enabled=0 flag=1 pid=0 rate_limit=0 backlog_limit=320 lost=0 backlog=0 Jul 27 17:35:13 vfr kernel: [127B blob data] Jul 27 17:35:38 vfr systemd[1]: Starting Stop Read-Ahead Data Collection... Jul 27 17:35:38 vfr systemd[1]: Started Stop Read-Ahead Data Collection. Jul 27 17:40:15 vfr kernel: device fsid 6c3aeff6-9a50-4481-a175-7b98980eb638 devid 1 transid 674749 /dev/sda4 Jul 27 17:40:15 vfr kernel: btrfs: disk space caching is enabled Jul 27 17:40:16 vfr kernel: SELinux: initialized (dev sdb4, type btrfs), uses xattr -- Garry T. Williams ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shell-completion: fix zsh completion installation
On 7-26-13 00:41:11 Michael Biebl wrote: 2013/7/25 William Giokas 1007...@gmail.com: Moved zsh shell completion to shell-completion/zsh/_systemd for automake's sake. Also allow users to specify where the files should go with:: ./configure --with-zshcompletiondir=/path/to/some/where and by default going to `$datadir/zsh/site-functions` I was told [1], the directory for 3rd party packages would be /usr/share/zsh/vendor-completions. But I'm not a zsh user, so I'm just paroting what I read there. If it's any help, I am a zsh user and Fedora 19 has this file installed on my system: /usr/share/zsh/5.0.2/functions/_systemd My /usr/share/zsh/site-functions directory is empty. -- Garry T. Williams ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /home Fails to Mount During Boot
On Sun, Jul 28, 2013 at 12:13 AM, Garry T. Williams gtwilli...@gmail.com 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 for root's password and after receiving a shell prompt, the command mount /home completes without error and after exiting the shell the boot-up proceeds normally. This is sort of new behavior. I saw it once or twice during the last few months, but now, after updating to kernel 3.10.3-300.fc19.x86_64, it happens on each boot. How can I debug this problem? systemd-204-9.fc19.x86_64 kernel-3.10.3-300.fc19.x86_64 /etc/fstab: /dev/sda4 /home btrfs noatime 0 0 The /home file system is a raid1 btrfs across two identical drive partitions, sda4 and sdb4. I believe you want to use UUID, rather than the name of one of your devices (see lsblk -f). -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /home Fails to Mount During Boot
El 27/07/13 19:14, Tom Gundersen escribió: I believe you want to use UUID, rather than the name of one of your devices (see lsblk -f). It also fails to umount here with v206, however I am using UUID instead of device names. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /home Fails to Mount During Boot
On 7-28-13 01:14:55 Tom Gundersen wrote: On Sun, Jul 28, 2013 at 12:13 AM, Garry T. Williams gtwilli...@gmail.com wrote: /etc/fstab: /dev/sda4 /home btrfs noatime 0 0 The /home file system is a raid1 btrfs across two identical drive partitions, sda4 and sdb4. I believe you want to use UUID, rather than the name of one of your devices (see lsblk -f). Thanks. That seems to have done it. (It has been intermittent until this kernel.) I've had that entry in fstab for a long time -- probably two years. That's about when I first tried btrfs on /home. Is the use of /dev/sd* in the fstab racey in some way? -- Garry T. Williams ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] shell-completion: fix zsh completion installation
On Sat, Jul 27, 2013 at 5:30 PM, Garry T. Williams gtwilli...@gmail.comwrote: On 7-26-13 00:41:11 Michael Biebl wrote: 2013/7/25 William Giokas 1007...@gmail.com: Moved zsh shell completion to shell-completion/zsh/_systemd for automake's sake. Also allow users to specify where the files should go with:: ./configure --with-zshcompletiondir=/path/to/some/where and by default going to `$datadir/zsh/site-functions` I was told [1], the directory for 3rd party packages would be /usr/share/zsh/vendor-completions. But I'm not a zsh user, so I'm just paroting what I read there. If it's any help, I am a zsh user and Fedora 19 has this file installed on my system: /usr/share/zsh/5.0.2/functions/_systemd My /usr/share/zsh/site-functions directory is empty. -- Garry T. Williams ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel That version is the old systemd completion that is still in the last zsh release, from before I moved it to the systemd repository and added a most of the other commands and options -- Daniel Wallace ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /home Fails to Mount During Boot
On Sun, Jul 28, 2013 at 1:34 AM, Garry T. Williams gtwilli...@gmail.com wrote: On 7-28-13 01:14:55 Tom Gundersen wrote: On Sun, Jul 28, 2013 at 12:13 AM, Garry T. Williams gtwilli...@gmail.com wrote: /etc/fstab: /dev/sda4 /home btrfs noatime 0 0 The /home file system is a raid1 btrfs across two identical drive partitions, sda4 and sdb4. I believe you want to use UUID, rather than the name of one of your devices (see lsblk -f). Thanks. That seems to have done it. (It has been intermittent until this kernel.) I've had that entry in fstab for a long time -- probably two years. That's about when I first tried btrfs on /home. Is the use of /dev/sd* in the fstab racey in some way? Btrfs multi-device volumes need all be known to the kernel before mount can succeed. Which one of the device is given to mount does not matter, they all result in the same volume to be mounted. If you reference one of the volumes directly in fstab, the other needed volume needs to be already known to the kernel or it will fail. So yes, it is racy, it depends on discovery order. Using the volume's UUID will make systemd check if the volume is ready for mount, and only after all devices are known to the kernel, the kernel will signify ready and we attempt to mount. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /home Fails to Mount During Boot
On Sun, Jul 28, 2013 at 3:28 AM, Kay Sievers k...@vrfy.org wrote: Is the use of /dev/sd* in the fstab racey in some way? Btrfs multi-device volumes need all be known to the kernel before mount can succeed. Which one of the device is given to mount does not matter, they all result in the same volume to be mounted. If you reference one of the volumes directly in fstab, the other needed volume needs to be already known to the kernel or it will fail. So yes, it is racy, it depends on discovery order. The above should both read *devices* not *volumes*. Using the volume's UUID will make systemd check if the volume is ready for mount, and only after all devices are known to the kernel, the kernel will signify ready and we attempt to mount. The checking will make the device known to the kernel's btrfs code. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
