[systemd-devel] systemd-logind fails to start
210 /usr/bin/crond -n |-397 /bin/bash /home/robin/bin/check-connected --check-connected-detached `-543 sleep 60 I'm wondering how I can find out what's wrong. Is there some timer that my ancient sheevaplug lacks. The above shows I have no permanent hardware clock on this machine so perhaps that's the issue. Some of my filesystems seem to have very ancient dates etc etc. -- Robin Becker ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] arch linux container filesystems
On 20/06/2014 12:48, Lennart Poettering wrote: well, findmnt is neither red hat stuff, it's used all over the distributions. And you shouldn't accept that df can't deal with mount points that reference out-of-namespace sources. File a bug against coreutils, they really should make sure they properly handle the Linux mount logic in that area. Lennart as a matter of fact, my manual page for findmnt lists Karel Zak k...@redhat.com as the sole author if findmnt; that others have adopted it doesn't make it not redhat stuff. You are probably right that this should be fixed in df and (presumably all the other tools that don't work properly in systemd-nspawn containers), but as a general principle I believe if you break it, you own it applies here. As a novice user of these containers, I suspect this kind of error must have been seen before by the systemd developers, so someone among the systemd contributors probably has prior discovery rights to this bug as well. In any case, some might argue that a container (lightweight or not) should be virtually indistinguishable from the original system which would mean such a bug could not happen. -- Robin Becker ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] arch linux container filesystems
I asked about this at the arch linux forum, but got no response. I run an up to date arch linux X64 system with systemd-213-9. I built a simple container using the wiki article https://wiki.archlinux.org/index.php/Systemd-nspawn after systemd-nspawn -bD ~/MyContainer and root login I see this in my df output root@MyContainer ~]# df df: '/run/user/1000': No such file or directory df: '/run/user/1000/gvfs': No such file or directory df: '/proc/kmsg (deleted)': No such file or directory df: '/proc/sys/kernel/random/boot_id (deleted)': No such file or directory Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 147418744 85779872 54127364 62% / dev 14139004 1413896 1% /dev tmpfs14139000 1413900 0% /dev/shm tmpfs14139000 1413900 0% /sys/fs/cgroup run 1413900 44 1413856 1% /run tmpfs14139000 1413900 0% /tmp tmpfs14139004 1413896 1% /dev tmpfs14139000 1413900 0% /dev/shm tmpfs1413900 44 1413856 1% /run tmpfs14139000 1413900 0% /sys/fs/cgroup tmpfs14139000 1413900 0% /tmp tmpfs 2827840282784 0% /run/user/0 [root@MyContainer ~]# Is this what is expected? Not sure why my user id (1000) is being used. I can imagine containers might not have /proc/kmsg /proc/sys/kernel/random/boot_id; is that an error in df? Why do I have all the file system duplicates? -- Robin Becker ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] arch linux container filesystems
On 16/06/2014 14:00, Dave Reisner wrote: On Mon, Jun 16, 2014 at 01:01:31PM +0100, Robin Becker wrote: Why do I have all the file system duplicates? You don't -- df doesn't understand namespaces. You should use a tool which reads from /proc/self/mountinfo instead of /etc/mtab, e.g. findmnt. If you want df-like output from findmnt, use 'findmnt -vD'. OK thanks; pity we have to abandon old tools and learn a lot of red hat stuff. Price of progress I guess. -- Robin Becker ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] diverting HandlePowerKey
On 16/08/2012 18:36, Lennart Poettering wrote: .. Invoke the PowerOff() call on the org.freedesktop.login1.Manager interface of the /org/freedesktop/login1 object on the org.freedesktop.login1 service. Which is basically what systemctl poweroff does. thanks for this. I think my route to doing everything via openbox is a bit stymied as I cannot seem to get the lid switch to generate a keypress, even showkey says nothing going on. -- Robin Becker ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] diverting HandlePowerKey
Hi, I liked the idea of systemd when I first saw it, but after doing a few conversions I have some small issues. I run arch linux with slim openbox and that seems to be fully supported so far as I can tell. However, on my netbooks I like to use the power button to launch oblogout which brings up a bunch of buttons that allow me to logout/suspend/restart/halt etc etc. I can of course continue to use acpid to handle the power button, but that seems opposed to the spirit of systemd. Is there a way to divert HandlePowerKey to a script of my choosing? I could imagine that an option starting with a / character could be used to distinguish such a command from one of the standard logind.conf values, but that's obviously not implemented. Even if it was does systemd allow me to configure oblogout properly ie check for the conditions no-session, tty-session, any-session? Shell scripts might be a bit slower at boot, but they allow for possibilities that were not thought of at design time. Of course I would also like to treat the lid switch in a different way to what systemd proposes, surely it's obvious that some might like to hibernate or power off rather than suspend if the lid is closed? -- Robin Becker ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] diverting HandlePowerKey
On 16/08/2012 12:47, Mantas Mikulėnas wrote: On Thu, Aug 16, 2012 at 2:23 PM, Robin Becker ro...@reportlab.com wrote: It'd be a bit better if the button/lid events were handled by a program running inside the Openbox session (the events can be read from /run/acpid.socket). I'm not exactly sure here, but aren't the standard power events in systemd handled by a daemon running outside openbox? I thought that the handler kinds eg no-session, tty-session, any-session were supposed to allow some control over whether I can switch off the machine with other users logged on etc etc. Perhaps with cgroups those sorts of capabilities can be passed on to another program. Openbox is actually running as a user process so it has no greater rights than the user; that makes the use of a more capable daemon a bit more reasonable. -- Robin Becker ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] diverting HandlePowerKey
... Openbox is actually running as a user process so it has no greater rights than the user; that makes the use of a more capable daemon a bit more reasonable. No, if your action just runs `oblogout` (and possibly `systemctl suspend`), then the capabilities of a normal user are sufficient. Mantas, I think you are right that openbox can call oblogout, but my existing oblogout is trying to call shutdown, halt, hibernate etc etc and aren't those the things that HandlePowerKey is supposed to protect? I suppose there are dbus messages that can be used with consolekit, but that's just the more capable daemon again. Currently my oblogout is doing nasty things like sudo shutdown ie it gives itself super powers in a rather brutal way. -- Robin Becker ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
