[systemd-devel] systemd.mount questions
I am attempting to learn how to use systemd. I read the man page on systemd.mount ( http://www.freedesktop.org/software/systemd/man/systemd.mount.html ) and I have two questions 1: say you want to mount proc, sys, run, dev, devpts, tmpfs do you need multiple systemd.mount files (1 for each) or can one file do and if so how so? 2. I did not see an option for passing the --no-mtab (-n ) option when calling mount. ( http://linux.die.net/man/8/mount ) So when using systemd.mount how is the --no-mtab option inserted? thanks in advance sincerely luxInteg ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd.mount questions
'Twas brillig, and lux-integ at 29/07/13 12:39 did gyre and gimble: > I am attempting to learn how to use systemd. I read the man page on > systemd.mount > > ( http://www.freedesktop.org/software/systemd/man/systemd.mount.html ) > > and I have two questions > > 1: say you want to mount proc, sys, run, dev, devpts, tmpfs > do you need multiple systemd.mount files (1 for each) or can one file do > and > if so how so? I assume you just mean tmp and not tmpfs at the end there? All of those file systems are handled internally as "API" filesystems inside systemd. You do not need fstab entries or .mount units for the above - they should all "Just Work"(tm) But to answer the question theoretically: you would need one unit per mount point. If you want to keep things in one file, just keep them in fstab as before. > 2. I did not see an option for passing the --no-mtab (-n ) option when > calling mount. > ( http://linux.die.net/man/8/mount ) > > So when using systemd.mount how is the --no-mtab option inserted? systemd doesn't support a /etc/mtab which is a statically managed file. It basically requires that /etc/mtab is a symlink to /proc/mounts which is dynamically updated from the kernel. So there is no option for this because there is no need. All the best Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd.mount questions
On Mon, Jul 29, 2013 at 12:39:40PM +0100, lux-integ wrote: > I am attempting to learn how to use systemd. I read the man page on > systemd.mount > > ( http://www.freedesktop.org/software/systemd/man/systemd.mount.html ) > > and I have two questions > > 1: say you want to mount proc, sys, run, dev, devpts, tmpfs > do you need multiple systemd.mount files (1 for each) or can one file do > and > if so how so? 1 mount unit = 1 mounted filesystem But, why? These things are already mounted for you. If you really need to override options, you can still use /etc/fstab > 2. I did not see an option for passing the --no-mtab (-n ) option when > calling mount. > ( http://linux.die.net/man/8/mount ) > > So when using systemd.mount how is the --no-mtab option inserted? You couldn't possibly make use of this option, even if you were able to pass it. systemd requires that /etc/mtab is a symlink to /proc/self/mounts: http://cgit.freedesktop.org/systemd/systemd/tree/src/core/main.c#n1136 d ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd.mount questions
On Mon, Jul 29, 2013 at 1:39 PM, lux-integ wrote: > I am attempting to learn how to use systemd. I read the man page on > systemd.mount > > ( http://www.freedesktop.org/software/systemd/man/systemd.mount.html ) > > and I have two questions > > 1: say you want to mount proc, sys, run, dev, devpts, tmpfs > do you need multiple systemd.mount files (1 for each) or can one file do and > if so how so? Systemd mounts these unconditionally, none of them need to be specified. An fstab entry will remount them to apply custom options, but they are always mounted. > 2. I did not see an option for passing the --no-mtab (-n ) option when > calling mount. > ( http://linux.die.net/man/8/mount ) > > So when using systemd.mount how is the --no-mtab option inserted? mtab as a regular file is not supported at all. Systemd requires mtab to be a symlink to /proc. Tthere is no need to pass that option on systemd systems. Kay ___ 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 Thu, Jul 25, 2013 at 02:00:06PM -0500, William Giokas wrote: > Moved zsh shell completion to shell-completion/zsh/_systemd for > automake's sake. Also allow users to specify where the files should go > with:: Makes sense, imho. Should we go one step further and split _systemd like the bash completions were split? This would have at least the advantage that people packaging a subset of systemd could package a subset of completion scripts. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Create a new logind session from a systemd --user unit
Hi,
> 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
>
> <...>
>
> The unit fails with message
>
> systemd[21209]: Failed at step GROUP spawning
> /home/abdo/.config/systemd/scripts/awesome.sh: Operation not permitted
Ok, more to the point.
I think initgroups in core/execute.c always needs privileges. It is always
called when User=blah is set on a service file and always fails on systemd user
instances for unprivileged users. This prevents from using PAM within a systemd
user instance, for example.
I attach a patch that makes a call to initgroups only when we ask for a
different user than the one for the running instance (when the group access list
may be different). I'm not certain whether this would break something else,
though...
Also, there is dbus policy preventing from accessing the CreateSession method
in logind1.Manager from unprivileged users. Is this intentional?
Thanks,
Abdó Roig.
>From ebf7783534d3aa3e56c20dba7450fd2169f3521f Mon Sep 17 00:00:00 2001
From: Abdo Roig-Maranges
Date: Mon, 29 Jul 2013 11:40:02 +0200
Subject: [PATCH] core: call initgroups only when uid changes
initgroups always requires the CAP_SETGID capability, and fails on
unprivileged systemd instances.
---
src/core/execute.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/core/execute.c b/src/core/execute.c
index 43b571e..e539673 100644
--- a/src/core/execute.c
+++ b/src/core/execute.c
@@ -576,7 +576,7 @@ static int ask_for_confirmation(char *response, char **argv) {
return r;
}
-static int enforce_groups(const ExecContext *context, const char *username, gid_t gid) {
+static int enforce_groups(const ExecContext *context, const char *username, uid_t uid, gid_t gid) {
bool keep_groups = false;
int r;
@@ -594,8 +594,8 @@ static int enforce_groups(const ExecContext *context, const char *username, gid_
return r;
}
-/* First step, initialize groups from /etc/groups */
-if (username && gid != 0) {
+/* First step, initialize groups from /etc/groups if different uid */
+if (username && gid != 0 && uid != getuid()) {
if (initgroups(username, gid) < 0)
return -errno;
@@ -1300,7 +1300,7 @@ int exec_spawn(ExecCommand *command,
#endif
if (apply_permissions) {
-err = enforce_groups(context, username, gid);
+err = enforce_groups(context, username, uid, gid);
if (err < 0) {
r = EXIT_GROUP;
goto fail_child;
--
1.8.3.4
___
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 Mon, Jul 29, 2013 at 04:07:31PM +0200, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Jul 25, 2013 at 02:00:06PM -0500, William Giokas wrote: > > Moved zsh shell completion to shell-completion/zsh/_systemd for > > automake's sake. Also allow users to specify where the files should go > > with:: > Makes sense, imho. Should we go one step further and split _systemd > like the bash completions were split? This would have at least the > advantage that people packaging a subset of systemd could package > a subset of completion scripts. Sorry, replied off list first. Originally this was there just to have the make install put zsh completion files in the right place. I would be open to doing this, however there are quite a few shared functions between commands, and as I have been told, there isn't really a good way to source or store the shared functions. I'm still going to try, but I make no promises. Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpxLMAg4adI5.pgp Description: PGP signature ___ 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 Mon, Jul 29, 2013 at 12:23:54PM -0500, William Giokas wrote: > On Mon, Jul 29, 2013 at 04:07:31PM +0200, Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Jul 25, 2013 at 02:00:06PM -0500, William Giokas wrote: > > > Moved zsh shell completion to shell-completion/zsh/_systemd for > > > automake's sake. Also allow users to specify where the files should go > > > with:: > > Makes sense, imho. Should we go one step further and split _systemd > > like the bash completions were split? This would have at least the > > advantage that people packaging a subset of systemd could package > > a subset of completion scripts. > > Sorry, replied off list first. > > Originally this was there just to have the make install put zsh > completion files in the right place. I would be open to doing this, > however there are quite a few shared functions between commands, and as > I have been told, there isn't really a good way to source or store the > shared functions. I'm still going to try, but I make no promises. I take back what I just said. All that really stands out is the -H completion, and that is just a few lines that I don't feel bad about having in all of the files. Currently I have 13 different files:: _hostnamectl _journalctl _localectl _loginctl _machinectl _systemctl _systemd _systemd-analyze _systemd-coredumpctl _systemd-inhibit _systemd-nspawn _timedatectl _udevadm with _systemd being the kind of 'fallback' option, containing the systemd commands that are less complex, and don't require as much in the way of functions (most simply use 'flag:desc:(a b c)' or some such). Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpANqVtnodp6.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [GIT PULL] Split out zsh completion into multiple files
All, This patch set splits out the zsh completion into 13 distinct files that are installed separately, similar to the bash completion system. There is also a final commit that changes the journalctl completion to work with the new use of -b/--boot. This also replaces all of the previous unmerged patches I have sent in since the 24th or so. You can pull from the git:// url specified, or browse the commits here: http://git.kaictl.net/wgiokas/systemd.git/ The following changes since commit 4c4ae27d4d314d0dc1c42cd6bfc7b9ae31660885: update TODO (2013-07-29 18:43:57 +0200) are available in the git repository at: git://git.kaictl.net/pub/wgiokas/systemd.git zshcomp for you to fetch changes up to 8f23e6b43ca9bb1b053419a5b8189cdfc7f5e080: shell-comp: Fix journalctl's --boot (2013-07-29 14:40:27 -0500) William Giokas (15): shell-completion: fix zsh completion installation shell-comp: Split out zsh _systemctl shell-comp: Split out zsh _loginctl shell-comp: Split out zsh _hostnamectl shell-comp: Split out zsh _journalctl shell-comp: Split out zsh _localectl shell-comp: Split out zsh _coredumpctl shell-comp: Split out zsh _timedatectl shell-comp: Split out zsh _udevadm shell-comp: Split out zsh _systemd-nspawn shell-comp: Split out zsh _systemd-inhibit shell-comp: Split out zsh _systemd-analyze shell-comp: Split out zsh _machinectl shell-comp: Remove unused functions shell-comp: Fix journalctl's --boot Makefile.am | 31 +- configure.ac|6 + shell-completion/systemd-zsh-completion.zsh | 1102 --- shell-completion/zsh/_hostnamectl | 38 + shell-completion/zsh/_journalctl| 92 +++ shell-completion/zsh/_localectl | 89 +++ shell-completion/zsh/_loginctl | 112 +++ shell-completion/zsh/_machinectl| 47 ++ shell-completion/zsh/_systemctl | 340 + shell-completion/zsh/_systemd | 107 +++ shell-completion/zsh/_systemd-analyze | 26 + shell-completion/zsh/_systemd-coredumpctl | 34 + shell-completion/zsh/_systemd-inhibit | 27 + shell-completion/zsh/_systemd-nspawn| 24 + shell-completion/zsh/_timedatectl | 71 ++ shell-completion/zsh/_udevadm | 141 16 files changed, 1184 insertions(+), 1103 deletions(-) delete mode 100644 shell-completion/systemd-zsh-completion.zsh create mode 100644 shell-completion/zsh/_hostnamectl create mode 100644 shell-completion/zsh/_journalctl create mode 100644 shell-completion/zsh/_localectl create mode 100644 shell-completion/zsh/_loginctl create mode 100644 shell-completion/zsh/_machinectl create mode 100644 shell-completion/zsh/_systemctl create mode 100644 shell-completion/zsh/_systemd create mode 100644 shell-completion/zsh/_systemd-analyze create mode 100644 shell-completion/zsh/_systemd-coredumpctl create mode 100644 shell-completion/zsh/_systemd-inhibit create mode 100644 shell-completion/zsh/_systemd-nspawn create mode 100644 shell-completion/zsh/_timedatectl create mode 100644 shell-completion/zsh/_udevadm -- Thanks, William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpltWQjBb7fb.pgp Description: PGP signature ___ 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 Mon, Jul 29, 2013 at 04:07:31PM +0200, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Jul 25, 2013 at 02:00:06PM -0500, William Giokas wrote: > > Moved zsh shell completion to shell-completion/zsh/_systemd for > > automake's sake. Also allow users to specify where the files should go > > with:: > Makes sense, imho. Should we go one step further and split _systemd > like the bash completions were split? This would have at least the > advantage that people packaging a subset of systemd could package > a subset of completion scripts. Please refer to the git pull request I sent in: http://lists.freedesktop.org/archives/systemd-devel/2013-July/012387.html -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpUbx2qKr1PC.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [GIT PULL v2] Split out zsh completion into multiple files
On Mon, Jul 29, 2013 at 02:53:17PM -0500, William Giokas wrote: > All, > > This patch set splits out the zsh completion into 13 distinct files that > are installed separately, similar to the bash completion system. There > is also a final commit that changes the journalctl completion to work > with the new use of -b/--boot. This also replaces all of the previous > unmerged patches I have sent in since the 24th or so. You can pull from > the git:// url specified, or browse the commits here: > > http://git.kaictl.net/wgiokas/systemd.git/ Just some small edits to the first commit. The following changes since commit 4c4ae27d4d314d0dc1c42cd6bfc7b9ae31660885: update TODO (2013-07-29 18:43:57 +0200) are available in the git repository at: git://git.kaictl.net/pub/wgiokas/systemd.git zshcomp for you to fetch changes up to d773c778c50e02d0a9af6ff5e2ebb49c55aef1f6: shell-comp: Fix journalctl's --boot (2013-07-29 15:01:07 -0500) William Giokas (15): shell-completion: fix zsh completion installation shell-comp: Split out zsh _systemctl shell-comp: Split out zsh _loginctl shell-comp: Split out zsh _hostnamectl shell-comp: Split out zsh _journalctl shell-comp: Split out zsh _localectl shell-comp: Split out zsh _coredumpctl shell-comp: Split out zsh _timedatectl shell-comp: Split out zsh _udevadm shell-comp: Split out zsh _systemd-nspawn shell-comp: Split out zsh _systemd-inhibit shell-comp: Split out zsh _systemd-analyze shell-comp: Split out zsh _machinectl shell-comp: Remove unused functions shell-comp: Fix journalctl's --boot Makefile.am | 32 +- configure.ac|6 + shell-completion/systemd-zsh-completion.zsh | 1102 --- shell-completion/zsh/_hostnamectl | 38 + shell-completion/zsh/_journalctl| 92 +++ shell-completion/zsh/_localectl | 89 +++ shell-completion/zsh/_loginctl | 112 +++ shell-completion/zsh/_machinectl| 47 ++ shell-completion/zsh/_systemctl | 340 + shell-completion/zsh/_systemd | 107 +++ shell-completion/zsh/_systemd-analyze | 26 + shell-completion/zsh/_systemd-coredumpctl | 34 + shell-completion/zsh/_systemd-inhibit | 27 + shell-completion/zsh/_systemd-nspawn| 24 + shell-completion/zsh/_timedatectl | 71 ++ shell-completion/zsh/_udevadm | 141 16 files changed, 1183 insertions(+), 1105 deletions(-) delete mode 100644 shell-completion/systemd-zsh-completion.zsh create mode 100644 shell-completion/zsh/_hostnamectl create mode 100644 shell-completion/zsh/_journalctl create mode 100644 shell-completion/zsh/_localectl create mode 100644 shell-completion/zsh/_loginctl create mode 100644 shell-completion/zsh/_machinectl create mode 100644 shell-completion/zsh/_systemctl create mode 100644 shell-completion/zsh/_systemd create mode 100644 shell-completion/zsh/_systemd-analyze create mode 100644 shell-completion/zsh/_systemd-coredumpctl create mode 100644 shell-completion/zsh/_systemd-inhibit create mode 100644 shell-completion/zsh/_systemd-nspawn create mode 100644 shell-completion/zsh/_timedatectl create mode 100644 shell-completion/zsh/_udevadm -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgp22psKSBKYv.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [GIT PULL] Split out zsh completion into multiple files
2013/7/29 William Giokas <1007...@gmail.com>: > This patch set splits out the zsh completion into 13 distinct files that > are installed separately, similar to the bash completion system. There One of the main reasons why the bash completion was split into separate files named after the individual binary, is that bash-completion will load the completions on demand this way. What's the benefit of splitting the zsh completion? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [GIT PULL] Split out zsh completion into multiple files
On Tue, Jul 30, 2013 at 12:05:00AM +0200, Michael Biebl wrote: > 2013/7/29 William Giokas <1007...@gmail.com>: > > This patch set splits out the zsh completion into 13 distinct files that > > are installed separately, similar to the bash completion system. There > > One of the main reasons why the bash completion was split into > separate files named after the individual binary, is that > bash-completion will load the completions on demand this way. > > What's the benefit of splitting the zsh completion? The bash completion was also split so that not all of the completions were installed if they weren't needed. If you configure systemd without xyz binary, the _xyz completion will not install, for the most part. Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpVj6RMTZk2Y.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Create a new logind session from a systemd --user unit
On Sat, 27.07.13 21:47, Abdó Roig-Maranges (abdo.r...@gmail.com) wrote: > > 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. This is not supported by logind. You cannot allocate sessions from other sessions, only from the system daemon. This is because we try to keep the various session definitions in sync, for example the audit session which is nowadays "sealed" off by the kernel. Either use a display manager or simply "update" your existing session's tty to graphical temporarily, rather then placing things on a new tty. (Note that the Fedora startx script does this implicitly this way) Note that "systemd --user" is WIP (which is why you find very little documentation about it from us, except the most basic reference in the man pages). It was never supposed to be run from login sessions (it's not called "systemd --session" but "systemd --user" for a reason) except for debugging purposes. Recent systemd versions make this a bit harder than before since for security reasons normal user sessions do not get write access to their cgroup tree anymore, only user@.service gets. Now, user@.service is not complete yet. To be fully useful we need some support from X11, so that it can connect to the X11 display via $XDG_RUNTIME_DIR/display, rather than relying on $DISPLAY. Also, D-Bus needs to look for the bus socket in $XDG_RUNTIME_DIR too. We are working on this bit by bit. If you want this to go faster, then please work with us, and write patches for libX11 and D-Bus. If you need an quick solution immediately I suggest you simply chown the sessions cgroup tree to your own user. That's a hack, and requires privileges, but is what I do for testing purposes. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Create a new logind session from a systemd --user unit
On Mon, 29.07.13 18:19, Abdó Roig-Maranges (abdo.r...@gmail.com) wrote: > Also, there is dbus policy preventing from accessing the CreateSession method > in logind1.Manager from unprivileged users. Is this intentional? Yes it is. CreateSession()/ReleaseSession() are only used by pam_systemd, by nobody else, and that's documented here: http://www.freedesktop.org/wiki/Software/systemd/logind/ Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Create a new logind session from a systemd --user unit
On Mon, 29.07.13 18:19, Abdó Roig-Maranges (abdo.r...@gmail.com) wrote: > I think initgroups in core/execute.c always needs privileges. It is always > called when User=blah is set on a service file and always fails on systemd > user > instances for unprivileged users. This prevents from using PAM within a > systemd > user instance, for example. Not following here. initgroups() is called before dropping prvis, so it should always work. Can you elaborate? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Create a new logind session from a systemd --user unit
On Tue, 30.07.13 01:02, Lennart Poettering (lenn...@poettering.net) wrote: > Either use a display manager or simply "update" your existing session's > tty to graphical temporarily, rather then placing things on a new > tty. (Note that the Fedora startx script does this implicitly this way) To elaborate a bit on this: this is also necessary since sessions can only be assigned to a single TTY. However, you need the proper tty-to-session assignment since otherwise logind+udev's device ACL management won't work and your X session will then lack access to audio devices, drm, or video4linux and similar... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Feature request] A way to native import /proc/cmdline within unit
On Thu, 25.07.13 19:35, Gerardo Exequiel Pozzi (vmlinuz...@yahoo.com.ar) wrote: > On 07/25/2013 05:06 PM, Lennart Poettering wrote: > > On Sat, 20.07.13 16:37, Gerardo Exequiel Pozzi (vmlinuz...@yahoo.com.ar) > > wrote: > > > >> Hello > >> > >> I am maintainer of Archiso project (The Arch Linux live ISO creator). > >> > >> I like a feature for systemd within unit files, mainly for importing > >> /proc/cmdline in initramfs stage, or in a generic form for any other > >> file with a similar format. Something like ImportOneLineFile=, like > >> current EnvironmentFile=. > >> > >> In this way, we can use/pass parameters to Exec*= directives if needed. > > > > So you awant to import kernel cmdline arguments into your environment? > > Yes, in a particular unit. > > > Note that you can do that already with the systemd.setenv= kernel > > command line option. What else do you need? > > > > Yes. But doing in this way: > > * Makes each variable passed, global to all units. > * For each parameter that I need to process I need to prefix them. > > So for example > archisobasedir=arch archisolabel=ARCH_201307 checksum=y > becomes: > systemd.setenv=archisobasedir=arch > systemd.setenv=archisolabel=ARCH_201307 systemd.setenv=checksum=y > > And if booting via PXE, think about automatic cmdline appended by > "ip=..." PXELINUX/IPAPPEND... > > The other solution that I have is using a service+script for > parsing/dumping cmdline in a file, then import with EnvironmentFile= but > does not look good. Other way maybe is using a generator, but they run > too early and I need to wait for some things happens before generating > units in a dynamic way. Hmm, but how do you process those variables further? In a shell script anyway? That sounds as if it would be appropriate to also parse /proc/cmdline from there? Why would it be better to do this in systemd rather than in the shell script itself? (or similar: better than in the Pythons script itself, Perl script, C program ...) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [Feature request] A way to native import /proc/cmdline within unit
On 07/29/2013 08:12 PM, Lennart Poettering wrote: > On Thu, 25.07.13 19:35, Gerardo Exequiel Pozzi (vmlinuz...@yahoo.com.ar) > wrote: > >> On 07/25/2013 05:06 PM, Lennart Poettering wrote: >>> On Sat, 20.07.13 16:37, Gerardo Exequiel Pozzi (vmlinuz...@yahoo.com.ar) >>> wrote: >>> Hello I am maintainer of Archiso project (The Arch Linux live ISO creator). I like a feature for systemd within unit files, mainly for importing /proc/cmdline in initramfs stage, or in a generic form for any other file with a similar format. Something like ImportOneLineFile=, like current EnvironmentFile=. In this way, we can use/pass parameters to Exec*= directives if needed. >>> >>> So you awant to import kernel cmdline arguments into your environment? >> >> Yes, in a particular unit. >> >>> Note that you can do that already with the systemd.setenv= kernel >>> command line option. What else do you need? >>> >> >> Yes. But doing in this way: >> >> * Makes each variable passed, global to all units. >> * For each parameter that I need to process I need to prefix them. >> >> So for example >> archisobasedir=arch archisolabel=ARCH_201307 checksum=y >> becomes: >> systemd.setenv=archisobasedir=arch >> systemd.setenv=archisolabel=ARCH_201307 systemd.setenv=checksum=y >> >> And if booting via PXE, think about automatic cmdline appended by >> "ip=..." PXELINUX/IPAPPEND... >> >> The other solution that I have is using a service+script for >> parsing/dumping cmdline in a file, then import with EnvironmentFile= but >> does not look good. Other way maybe is using a generator, but they run >> too early and I need to wait for some things happens before generating >> units in a dynamic way. > > Hmm, but how do you process those variables further? In a shell script > anyway? That sounds as if it would be appropriate to also parse > /proc/cmdline from there? Why would it be better to do this in systemd > rather than in the shell script itself? > > (or similar: better than in the Pythons script itself, Perl script, C > program ...) > > Lennart > In inside systemd unit, I want to avoid shell script if possible, using units only, doing things in a "systemd way". Anyway for complex tasks where systemd does not fit, scripting seems to be necessary. ExecStart=/usr/bin/program --param=$CMDLINE__ARG_VALUE ... I think is better because systemd already parse /proc/cmdline, and I guess that implementing this is easy, but maybe I am wrong. Thanks for your feedback. -- Gerardo Exequiel Pozzi \cos^2\alpha + \sin^2\alpha = 1 signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build: do not link everything with -lrt (and therefore -pthread)
On Sun, Jul 28, 2013 at 11:48 PM, Jan Engelhardt wrote: > On Monday 2013-07-22 05:57, Shawn Landden wrote: >>diff --git a/Makefile.am b/Makefile.am >>index 3ece887..f96866c 100644 >>--- a/Makefile.am >>+++ b/Makefile.am >>@@ -1832,6 +1832,7 @@ libsystemd_daemon_internal_la_SOURCES = \ >> $(libsystemd_daemon_la_SOURCES) >> >> libsystemd_daemon_la_CFLAGS = \ >>+ $(RT_LIBS) \ >> $(AM_CFLAGS) \ >> -fvisibility=hidden \ >> -DSD_EXPORT_SYMBOLS > > libs don't belong into CFLAGS. They ought to go into _la_LIBADD. Moved it to libsystemd_daemon_la_LIBADD and applied it. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Create a new logind session from a systemd --user unitt
Hi, Thanks a lot for your explanations! > Either use a display manager or simply "update" your existing session's > tty to graphical temporarily, rather then placing things on a new > tty. (Note that the Fedora startx script does this implicitly this way) I figured I could use a systemd unit as a sort of very thin display manager to create a second session for my own user. I'll try using the same tty, without extra sessions, then. > We are working on this bit by bit. If you want this to go faster, then > please work with us, and write patches for libX11 and D-Bus. Well, this is just for my home PC... I tried managing user daemons, X, etc. via systemd --user some time ago, and loved it! I'm just trying to do it in a way that will not break much as the thing evolves. >> I think initgroups in core/execute.c always needs privileges. It is always >> called when User=blah is set on a service file and always fails on systemd >> user >> instances for unprivileged users. This prevents from using PAM within a >> systemd >> user instance, for example. > > Not following here. initgroups() is called before dropping prvis, so it > should always work. Can you elaborate? I was referring to the systemd --user instance running as user abdo via the user@.service unit. Then when I started a systemd --user unit containing User=abdo PAMName=login I got the GROUP error I reported. In this case the initgroups() is called as my unprivileged user abdo because it is the user for which the systemd --user process is running. Did I miss something? I didn't look at it very carefully, just guessed the problem and tested a solultion that happened to work. I understand I shouldn't do the PAM stuff from a systemd --user unit, but the problem with group privs I encountered in systemd --user instances may still be an issue. Abdó Roig. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] I wanna construct server-client model with systemd option.
Hello. I'm Tony. I have aimed to construct server-client model. In order to build that mode, I supposed that there was X_server and A_client. I tried to do several time to operate that model properly, but I have failed to do that operation. In my view, I need to edit my service option which have been used for execution , but I'm not accustomed to using service option and confused a few option related with execution like "Type="and "Execstart=". I would suppose the procedure to successfully do that. 1. X_server should start first. 2. After X_server finished the start-up process, but it keeps it's activated state, A_client start and connect to X_server. What should I do something to build a procedure like above and what should I use options to operate that scheme properly? Consequently, I wonder what kind of thing will be used to make that procedure. Thanks. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] I wanna construct server-client model with systemd option.
On Mon, Jul 29, 2013 at 5:48 PM, Tony Seo wrote: > I have aimed to construct server-client model. > > In order to build that mode, I supposed that there was X_server and > A_client. > > I tried to do several time to operate that model properly, but I have failed > to do that operation. > > In my view, I need to edit my service option which have been used for > execution , but I'm not accustomed to using service option and confused a > few option related with execution like "Type="and "Execstart=". All of the options involving startup types and dependencies are explained in the manual pages. You can view them online here: http://www.freedesktop.org/software/systemd/man/systemd.service.html If you need more help, or are troubleshooting, please post your unit files here and a description of what you intend for these to do, and we can look at solving your problems. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] .automount from user?
Hello. I'm curious, and perhaps maybe lazy: is there any way to do automount units from a user systemd instance? I suppose I could write some silly script that collects automount files out of the user units directories and validates and accepts them, but it would be stellar if systemd had some plan for bestowing my users their ability to use their fuse group membership in a cool rad automounting way. Peace love chicken grease- rektide. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
