Re: [systemd-devel] [RFC] the chopping block
On 02/13/2016 01:01 PM, Lennart Poettering wrote: > On Sat, 13.02.16 00:10, Christian Seiler (christ...@iwakd.de) wrote: > >> On 02/12/2016 10:34 PM, Lennart Poettering wrote: >>> On Fri, 12.02.16 17:49, Simon McVittie (simon.mcvit...@collabora.co.uk) >>> wrote: >>> >>>> On 11/02/16 17:06, Lennart Poettering wrote: >>>>> 5) Here's the controversial one I think: support for booting up >>>>>without /var. We have kludges at quite a few places because we >>>>>cannot access /var early during boot. >>>> >>>> I don't think /var is really the same thing as /usr: for a start, it has >>>> to be read/write, whereas /usr and / can be read-only for at least the >>>> early stages of boot. >>>> >>>> On stateless systems with a read-only / and /etc, requiring /var to be >>>> mounted from the initramfs would mean that the mechanism for setting up >>>> /var (NFS or tmpfs or whatever) would have to move into the >>>> initramfs. >>> >>> Since initrds tend to cover root-on-nfs, root-on-iscsi and so on >>> anyway, that sounds like no change in behaviour really.. >> >> Well, kind-of. The root-on-nfs and root-on-iscsi are dumbed-down >> versions of what's possible once a system is booted. > > Well, to my understanding dracut and stuff makes pretty much all > storage tech that is available during the normal system also available > in the initrd, with the same software, to make sure testing stays > managable. Ok, so I just checked. So the very last version of dracut (released 3 months ago) supports starting iscsid in the initramfs, older versions do not - and only if systemd is installed in the initramfs image. If there's no systemd in the initramfs or an older version is used, dracut uses the iscsistart binary as I explained. So support for this is very, very new. NFS (latest dracut git master): idmapping for NFSv4 is supported to some extent, but there are a lot of assumptions going in: it assumes that nsswitch is used for idmapping (which is probably the most common case on clients, but it need not be the only possibility), it tries to install all nsswitch modules found in /etc/nsswitch.conf, but doesn't know anything about their configuration. What's not supported at all: NFS with Kerberos support. I should note note that NFS w/ Kerberos doesn't work out of the box for /var on a running system either, because you still need to fetch a Kerberos ticket for all the system users that access /var, but it's relatively easy to set something like that up, because you just need to write a simple systemd service for that and run it at boot - which most admins will be able to do - modifying the initramfs is a lot more complicated (especially because the documentation is sparse and the criticism of many people that initramfs are black magic is there for a reason). So basically: it's probably going to work in many cases as long as you don't want a Kerberized setup, but not everything will work out of the box, even if you don't use Kerberos. NBD: dracut (current git master) currently doesn't even support /usr on nbd if / isn't on it (and even then only if on the same device). And then there are still other setups that I had mentioned. DRBD with cluster filesystem: not supported in initramfs. sshfs: doesn't work in initramfs. FUSE filesystems in general: I only know that some people have experimented with zfs-fuse for the rootfs, and it was very fiddly at best from what I remember. And while most people who want to use ZFS on Linux nowadays use the kernel module (where binaries can't be distributed for legal reasons), other FUSE filesystems still have the same issue. The problem is that storage is complicated. You need to special-case each different storage type and add specific code to make that work in the initramfs. If you look at the dracut source code, every different storage solution is special-cased. You need to make sure that the programs required for that storage work in an initramfs environment and can either terminated before switch_root and then restarted in the running system, or alternatively support being kept around during switch_root. You need to have glue code that copies the right files into the initramfs. For rootfs there are certain limitations that have been widely accepted, but if you now start to say that lots of common mount points, especially some parts of /var, to be required to be mounted in the initramfs, you'll make life a lot more complicated for a lot of people. A _lot_ of different projects will have to make sure that their software now works in an initramfs context, even if it was never intended to be used for the root filesystem. That's a lot of work for other people, especially since coordination between different projects
Re: [systemd-devel] [RFC] the chopping block
On 02/13/2016 01:44 PM, Reindl Harald wrote: > [root@mail-gw:~]$ cat /etc/fstab | grep log > UUID=a8fc620d-8046-47a3-8b63-102c525ce5e8 /var/log ext4 defaults, noexec > 0 1 To be fair to Lennart: your specific use case, if /var/log is just a separate partition, will work perfectly fine even with Lennart's change, because mounting a partition on a local storage device using the UUID is already supported by initramfs implementations (see the /usr case). My objection to the change is about more complicated storage setups, where one would need to put in a lot of work to be rid of limitations we all have accepted for / and /usr. Regards, Christian signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] the chopping block
On 02/12/2016 10:34 PM, Lennart Poettering wrote: > On Fri, 12.02.16 17:49, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: > >> On 11/02/16 17:06, Lennart Poettering wrote: >>> 5) Here's the controversial one I think: support for booting up >>>without /var. We have kludges at quite a few places because we >>>cannot access /var early during boot. >> >> I don't think /var is really the same thing as /usr: for a start, it has >> to be read/write, whereas /usr and / can be read-only for at least the >> early stages of boot. >> >> On stateless systems with a read-only / and /etc, requiring /var to be >> mounted from the initramfs would mean that the mechanism for setting up >> /var (NFS or tmpfs or whatever) would have to move into the >> initramfs. > > Since initrds tend to cover root-on-nfs, root-on-iscsi and so on > anyway, that sounds like no change in behaviour really.. Well, kind-of. The root-on-nfs and root-on-iscsi are dumbed-down versions of what's possible once a system is booted. iSCSI: currently the rootfs works fine, because for the rootfs one can easily tell the initramfs implementation explicitly that it's on iSCSI. If your rootfs is on network storage, you have to do so anyway, so that's not an issue. But there's no way to determine *just* from looking at /etc/fstab that a given file system is on iSCSI (or nbd for that matter), because those just look like regular SCSI block devices (which don't exist yet if the initramfs hasn't logged in to the iSCSI session). This is already somewhat problematic for /usr, but since I've never seen a setup where people put /usr on iSCSI but / not, so this was never a huge issue in that regard. On the other hand, what I have seen in practice are systems with /var/log on iSCSI. Also, if you look at how iSCSI login in initramfs works currently, it's basically just running a binary called 'iscsistart' that tells the kernel to log in to a specific session where the rootfs is on, the real daemon isn't started yet. So only a specific session that is configured separately (!) from all the other configured sessions is logged into in the initramfs - and the daemon that reads the proper configuration is only started after the system has booted. So in order to support generic filesystems on iSCSI in initramfs, one would need to start the full daemon already in the initramfs, plus the full configuration database must be available in the initramfs (which can change with just some admin commands, after which the admin would need to remember to regenerate the initramfs image), and the daemon would need to be modified to support that. NFS: nfsroot is supported only for NFSv2/3 and (depending on the initramfs implementation) in NFSv4 with sec=sys without idmapping. If you need NFSv4 with idmapping or want to actually have a secure NFS mount (e.g. encrypted + authenticated via Kerberos), that currently doesn't work at all from the initramfs. idmapping requires that request-key works within the initramfs and properly calls the nfsidmap binary, which will in turn usually require the full NSS stack of the system to be available. For Kerberos you need rpc.svcgssd to be running, as well as have a program like k5start running to get a ticket for the root user, otherwise the file system is inaccessible on a kernel level. (And Kerberos also requires idmapping btw.) Also, in contrast to e.g. iSCSI, where you could probably get away with killing the daemon before switching to the rootfs, and then restarting the daemon, both the idmapping binaries and the rpc.svcgssd have to remain available, (the former as an upcall from the kernel, the latter as a running daemon), otherwise the kernel won't be able to properly handle the filesystem. And NFS and iSCSI are just two things I have quite a bit of experience with. You could also imagine that people put /var/log on sshfs, or any other FUSE filesystem for that matter, which as of now works, but will break if you introduce the change, because the vast majority of FUSE filesystems (if any at all) support running from initramfs. Or you could have /var/log as a bind mount of a directory within an OCFS2 filesystem on a multi-master DRBD. It's not that difficult to set up on a normal system, but good luck getting that to work from an initramfs. Of course, it's not impossible to make all these setups work. But it would require changes to a lot of other software that's currently used, which are probably going to be relatively painful and it's going to be a lot of work for a lot of other people. The maintenance burden in systemd for buffering things in /run before /var, /var/log, etc. are available is minuscule compared to that amount of pain this change would cause other people. Which in turn means what would more likely happen is that this would not be implemented in many cases and then once the version of systemd with this requirement hits distributions, this would break users' systems without them being
Re: [systemd-devel] grant users access to certain services only
On 21.08.2015 12:04, Jóhann B. Guðmundsson wrote: Should not the solution for this be tied to the user and group field mentioned in the unit so for example the postgresql type service unit contains... User=postgres Group=postgres Which would mean that the posgres user could start,stop,restart,reload the postgresql.service as well as any user that has been added to the postgres group? For postgres it would probably solve this problem (as long as it's configurable), the question is whether you'd maybe rather want something a bit more generic for the future. I would suggest a setting like UnitControl=alice bob group:foobar that would enable alice, bob and everybody in group foobar to control that specific unit. (The name for the setting is debatable.) That would be quite simple but still very flexible and generic. The only problem I see is that for this to be useful, you'd need to be able to resolve the names, and you don't want to do that in pid 1. Question is whether PolicyKit (not pid 1) can do that check for systemd with systemd just passing along the whitelist somehow. (Don't know too much about PolicyKit yet to answer that question myself, unfortunately.) The same problem also applies to the solution of tying it to User=/Group=, however. Just my 2c. Christian 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] Getting EOF on FD#1 stdout (a service using socat)
Am 2015-07-27 12:31, schrieb John Lane: I have a problem with what I thought would be a simple service unit: # /etc/systemd/system/socat.service [Service] ExecStart=/usr/bin/socat UDP-RECV:4321 STDOUT The expected outcome is that /usr/bin/socat UDP-RECV:4321 STDOUT is started with its standard output connected to the journal. However, the service terminates immediately without error. I've looked into it and notice that socat is getting an EOF on FD#1, its standard output, and it then terminates: N starting data transfer loop with FDs [5,5] and [1,1] N socket 2 (fd 1) is at EOF I close(5) N exiting with status 0 The command-line given in ExecStart works as expected if given on a command-line. systemd opens sockets that connect the stdout/stderr of a service to journald, but those sockets are unidirectional. This means that one cannot read from those file descriptors. But socat by default uses a bidirectional mode, and because it gets EOF when trying to read STDOUT, it will immediately terminate. Use the -u option to make socat work unidirectionally, then it should work: ExecStart=/usr/bin/socat -u UDP-RECV:4321 STDOUT (See the man page of socat for further details.) If you try it on the command line, the terminal you are using can in fact be opened for writing, so it will not get an EOF there (but you can use Ctrl+D when calling it manually to simulate that condition). Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] configure.ac: strip off trailing slashed from $rootprefix
On 05/30/2015 12:42 PM, Daniel Mack wrote:
On 05/30/2015 12:31 PM, Christian Seiler wrote:
Speaking of: using 'echo' for shell scripting is problematic, because
while bash, busybox's sh, mksh, pdksh and zsh don't interpret escape
sequences (\n, \0oo, ...) by default when using echo and invoked as
/bin/sh, dash and ash do. (Note that e.g. dash ist default on Debian,
so it's not like this is something theoretical.) Also, when invoked as
their proper name (not as /bin/sh), only bash and busybox's shell do
not interpret escape sequences by default with echo. (In short: it's a
mess.)
It's a mess indeed. Now we only need a POSIX compliant way to strip
_all_ trailing dashes from a string, then we can get rid of that one
occurrence of 'sed' in configure.ac :)
Define once:
# (local variables in functions are a bashism, don't use them, but
# name global variable in such a way that it won't clash with
# anything else)
strip_trailing_slashes()
{
_strip_trailing_slashes_value=$1
while [[ ${_strip_trailing_slashes_value} !=
${_strip_trailing_slashes_value%/} ]] ; do
_strip_trailing_slashes_value=${_strip_trailing_slashes_value%/}
done
printf '%s\n' ${_strip_trailing_slashes_value}
}
Later:
VAR=$(strip_trailing_slashes $VAR)
(Or, alternatively, repeat the loop each time, you're using M4
anyway, so you could AC_DEFUN the whole thing.)
It's up to you to decide what you find more appealing.
Christian
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] configure.ac: strip off trailing slashed from $rootprefix
On 05/30/2015 10:28 AM, Daniel Mack wrote:
On 05/30/2015 08:50 AM, Mike Gilbert wrote:
On Fri, May 29, 2015 at 8:05 PM, Daniel Mack dan...@zonque.org wrote:
Make sure the variable set via --with-rootprefix= does not contain a
trailing slash, so man pages can use entities like rootprefix;/lib
without ending up having double slashes.
---
configure.ac | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/configure.ac b/configure.ac
index 92654a6..55b73de 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1396,7 +1396,8 @@ AC_ARG_WITH([zshcompletiondir],
AC_ARG_WITH([rootprefix],
AS_HELP_STRING([--with-rootprefix=DIR], [rootfs directory prefix
for config files and kernel modules]),
-[], [with_rootprefix=${ac_default_prefix}])
+[with_rootprefix=`echo ${withval} | sed -e s,/*$,,`],
+[with_rootprefix=${ac_default_prefix}])
Why do you pipe it through sed when a simple shell parameter expansion would
do?
with_rootprefix=${withval%/}
Isn't that's a bash'ism which we try to avoid at other places? FWIW, we
use sed to strip off trailing dashes from $host for EFI_ARCH. Also, that
one only replaces one trailing slash, not all of them.
No, it's not a bashism, it's indeed POSIX. See:
http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_06_02
For example:
V=aXbXc
printf '%s\n' ${V#*X}
printf '%s\n' ${V##*X}
printf '%s\n' ${V%X*}
printf '%s\n' ${V%%X*}
When using either one of bash, dash, ash, busybox's shell, mksh, pdksh
and zsh as /bin/sh, it all produces the same output:
bXc
c
aXb
a
The following are bashisms, however:
- ${variable/pattern/subst}
- ${!variable_variable}
Speaking of: using 'echo' for shell scripting is problematic, because
while bash, busybox's sh, mksh, pdksh and zsh don't interpret escape
sequences (\n, \0oo, ...) by default when using echo and invoked as
/bin/sh, dash and ash do. (Note that e.g. dash ist default on Debian,
so it's not like this is something theoretical.) Also, when invoked as
their proper name (not as /bin/sh), only bash and busybox's shell do
not interpret escape sequences by default with echo. (In short: it's a
mess.)
POSIX itself is ambivalent:
http://pubs.opengroup.org/onlinepubs/009695399/utilities/echo.html
| or if any of the operands contain a backslash ( '\' ) character, the
| results are implementation-defined.
But it does recommend the behavior that ash and dash currently show
and NOT bash's behavior:
| The following character sequences shall be recognized on
| XSI-conformant systems within any of the arguments:
| [ list of escape sequences ]
The only portable way (not only to other UNIX systems, but also to
Linux systems with other shells) of printing things without
interpreting escape sequences is to use printf:
printf '%s\n' $variable
This is the same as ALL POSIX-compliant shells.
See also:
http://unix.stackexchange.com/questions/65803/why-is-printf-better-than-echo
Christian
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] ExecStart vs ExecStartPre
On 05/26/2015 11:12 PM, Steven Noonan wrote: Hi there, I'm wondering what the functional difference is between doing: ExecStartPre=/bin/foo ExecStart=/bin/bar and ExecStart=/bin/foo ExecStart=/bin/bar From my read of the systemd.service man page, they appear to have the same behavior in the common use case. Three differences come directly to mind: - If you have unit of type that is NOT oneshot (simple, forking, etc.), you can have only a single ExecStart= line, not multiple ones. The main service process must be started in ExecStart= and not ExecStartPre=. - Even in Type=oneshot units you must have at least one ExecStart= line (but can in any case have an arbitrary amount of ExecStartPre= lines, even zero). - If you set PermissionsStartOnly= or RootDirectoryStartOnly=, then certain settings will be applied to ExecStart= but not to ExecStartPre= (see manpage for details). (There are probably more.) Generally speaking, I follow the following guidelines when writing units: - Type=oneshot: I typically use only ExecStart= and only use ExecStartPre= if I have to use *StartOnly=true (see above). - other types: ExecStart= to start the service proper, ExecStartPre= for preparatory things (like generating a default config if none is already present or something along those lines) But it really depends on your use case and as always YMMV. Hope that helps! Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] DefaultDependencies of [Unit]
Am 2015-04-28 11:33, schrieb Lennart Poettering: On Tue, 28.04.15 16:19, 樊超 (fcvi...@gmail.com) wrote: I want to let my service run when shutdown,and it needn't close by systemd,so can i set the DefaultDependencies of [Unit] to no? I don't understand the meaning of DefaultDependencies. It's [Unit] like this: After=network.target network-online.target remote-fs.target And I want to know if it matters when start the pc if I set DefaultDependencies of [Unit] to no Sure it matters. If DefaultDependencies=yes you get ordered after basic.target and are shut down before shutdown.target is reached. If you set DefaultDependencies=no you are started really really early on (unless you explicitly order yourself after basic.target). That means you'd have to make sure your service is written in a way it can handle being run that early and doesn't assume directories like /var are already mounted, or specific other services already running. Similar, during shutdown if you continue to access /var this late you will keep the mount for it busy, and accessing other services might fail earlier than expected. On the other hand, nothing prevents somebody from adding back select dependencies by hand, i.e. if only Conflicts=shutdown.target is what is to be avoided, then using DefaultDependencies=no but also After=basic.target will make sure the service isn't started too early (but kept until systemd's final process killing spree). Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Another attempt: Making dependencies properly overridable
On 04/23/2015 08:36 PM, Lennart Poettering wrote: I mean, so far the deps we set are combined from: unit file (1) + dropins(2) + .wants/ + .requires/ symlinks (3) + automatic deps (4) + deps configured in other units (5) I'd allow unsetting deps configured in (1) from (1), (2) and (3). I'd allow unsetting deps configured in (2) from (2) and (3). I'd allow unsetting deps made in (3) from (3). I would not allow unsetting deps made in (1,2,3) with (4) or (5), or vice versa. That makes sense, I'll incorporate that. Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Another attempt: Making dependencies properly overridable
On 04/23/2015 08:38 PM, Lennart Poettering wrote: On Sun, 19.04.15 09:29, Andrei Borzenkov (arvidj...@gmail.com) wrote: Unless I'm mistaken, the only real change is that Wants= will clear list, just like it does it for ExecStart=. This should be rather straightforward to implement I guess. Actually it's not that easy. You need to collect the deps created from unit configuration into a set of hashmaps of their own, and then add a final commit step that merges those into the real deps. And if we want to do this without needless copies and allocations this is actually not easy at all. Yes, I know, because I'm currently working on a patch for this. ;-) I'll probably send a first version in a couple of days. Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] is there a plan for NIC teaming support ?
Am 2015-03-12 15:29, schrieb Dax Kelson: Could you please explain (or link to description of) what teamd can do that bonding cannot? Table, info, benchmarks here: http://rhelblog.redhat.com/2014/06/23/team-driver/ [2] On a side note, out of curiosity: does teamd support ARP monitoring if the interface is added to a bridge? The bonding driver doesn't and this is something that always bothered me. Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why don't remote file systems wait for network-online.target?
Am 2015-03-10 12:40, schrieb Martin Pitt: we got a report [1] that NFS fstab mounts (sometimes) aren't being mounted at boot as the network is still down: | mount[866]: mount.nfs: Network is unreachable | systemd[1]: mnt-server.mount mount process exited, code=exited status=32 | systemd[1]: Failed to mount /mnt/server. | systemd[1]: Dependency failed for Remote File Systems. | systemd[1]: Job remote-fs.target/start failed with result 'dependency'. | systemd[1]: Unit mnt-server.mount entered failed state. At the moment, neither network-fs-pre.target has no dependencies at all, and the fstab-generator-created .mount units only have Before=remote-fs.target and no other dependencies. I can't reproduce that under Debian Jessie with systemd-215. Individual NFS mounts (mnt-server.mount in your case) are ordered like this here: After=systemd-journald.socket remote-fs-pre.target network.target network-online.target system.slice -.mount Wants=network-online.target system.slice This is part of mount unit's DefaultDependencies, see: http://cgit.freedesktop.org/systemd/systemd/tree/src/core/mount.c#n366 (mount_is_network checks for fstype or _netdev; and nfs is in the list of filesystems considered network.) Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sysv-generator: doesn't handle /etc/insserv/overrides or /etc/chkconfig.d
Am 2015-02-16 13:59, schrieb Lennart Poettering: You couldn't override init scripts that way - if you wanted to do that, you'd have to replace them completely. But if you just want to alter (or even specify for the first time for certain third-party scripts) dependency information but keep getting updates for the init script from the software vendor, this was really, really useful. Since I never heard anyone asking for this, I doubt it was really that useful in real life... Understanding that you don't want to accept this kind of patch, I do want to disagree here vehemently. On sysvinit systems I've used that a LOT of times to modify init scripts, both from the distribution and from third parties. Scripts from the distribution mainly to add some dependencies due to local configuration, but third-party scripts because those had either completely broken LSB headers or even non-existent ones. So at least from my experience, this feature was _immensely_ useful. And if you search for insserv/overrides in your favorite search engine, you'll find that there are enough hits there to see that I'm not the only one. (Now obviously, you don't want to support it, so I'll move on, but I did want to disagree with the assertion that it wasn't useful.) Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Another attempt: Making dependencies properly overridable
Am 2015-02-16 14:16, schrieb Lennart Poettering: On Mon, 16.02.15 14:13, Michael Biebl (mbi...@gmail.com) wrote: Not quite. While you can use drop-in snippets to amend orderings/depends, it's (unfortunately) not possible to override Wants=,Before= etc. There have been discussions to allow masking deps via /dev/null symlinks in .wants/ and .requires/ dirs... I think that'd be a better solution... [...] Agreed, systemctl edit is much nicer. Unfortunately, as said above, drop-ins can *not* be used to override all aspects of a native unit file. So it's not (yet) a complete replacement for insserv overrides. If it would be possible to unset Wants= or After=, just like other service properties, then things would be different. As mentioned, I'd be happy to take patches to make precisely that work! Last time I talked about this here, there was a lot of confusion, so I didn't pursue it further. But I would really like to get this to work, but before I start with a patch, I'd like to explain what I'd like to do before working on it, to see if it works for you. The semantics I'd like to see would be the following: - anything in /etc named exactly the same as in /usr/lib overrides the latter, just as is already the case with units and drop-ins = allow masking of .wants/ and .requires/ with symlinks to /dev/null (I think you were in favor of that) - additionally, postpone processing of dependencies in unit files until the entire unit (and all drop-ins) have been read in For example, even without a drop-in: a.service: [Unit] Wants=b.service Wants= Wants=c.service After that, Wants should be set to c.service. Note that this should NOT affect dependencies set in other ways, i.e. via .wants/ directories or by dependencies of other services, this should JUST alter what was specified in the unit itself. A more complex example to illustrate the latter: /usr/lib/.../a.service: [Unit] Wants=b.service After=c.service /usr/lib/.../a.service.wants/d.service - /usr/lib/.../d.service /usr/lib/.../a.service.wants/e.service - /usr/lib/.../e.service /usr/lib/.../f.service [Unit] Before=a.service /etc/.../a.service.d/dont-depend-on-b.conf: [Unit] Wants= /etc/.../a.service.d/not-after-c.conf: [Unit] After= /etc/.../a.service.wants/e.service - /dev/null In the end, the dependnecies should be: Wants=d.service - b.service gets removed via drop-in - e.service gets removed because it's masked - but d.service stays, because it was never defined in the unit file, so a drop-in doesn't override it, only the mask does After=f.service - c.service gets removed via drop-in - f.service is not declared in the original unit file but rather in f.service as a Before= dependency, so you'd have to override that to make this go into effect The general principle would be: you can drop stuff at the same place it's defined. If it's defined as After= in a unit, override it in a drop-in for that unit, if it's defined as Before= in another unit, override it in a drop-in for the other unit, and if it's defined in the filesystem via .wants/ or .requires/, you can override it by masking it in the filesystem. Only in the end will all remaining dependencies be combined to make up the entire list of dependencies for that service. Would you be agreeable to these semantics? If so, I'll hack up a patch. Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sysv-generator: doesn't handle /etc/insserv/overrides or /etc/chkconfig.d
Hi,
Would you accept a patch that makes the sysv-generator consider these
local overrides? (I have a test patch just for insserv/overrides
that's diffstat +14 -8; for chkconfig.d it would be a bit more longer,
because you can override individual settings there (and not just all
of them at once), but shouldn't be too complicated.
We currently have support for calling out to chkconfig, but zero
support for calling out to update-rcd or insserv. It would be weird
supporting some facilities they provide without supporting the tools
themsevles...
This is also the first time I hear about chkconfig.d, which is kinda
interesting, given that the transition on Fedora is already years
past... We never got any request for it to be supported
explicitly. Which makes me wonder if it really makes sense to support
this now.
So, I am pretty conservative about this. That said I am note entirely
sure what precisely the patch you propose would entail. What precisely
would it do? Just look for init scripts in some other place in
addition to /etc/rc.d?
So this would definitely NOT call out to anything at all, this is just
about the possibility to override headers (LSB or chkconfig ones) in
init scripts.
Basically, you have the following semantics
- insserv (SuSE/Debian), when it processes /etc/init.d/$NAME, it also
looks for /etc/insserv/overrides/$NAME. If the latter exists, it
reads the LSB headers (but ONLY the LSB headers) from that file and
completely ignores the LSB headers in /etc/init.d/$NAME (i.e. that
file is not parsed at all). But the script called is still the
original /etc/init.d/$NAME.
- chkconfig (Fedora, RHEL, ...), when it processes /etc/init.d/$NAME,
it also looks for /etc/chkconfig.d/$NAME. If the latter exists,
every header set in that file overrides the corresponding header in
the original init script (but the original init script is still
read).
You couldn't override init scripts that way - if you wanted to do that,
you'd have to replace them completely. But if you just want to alter
(or even specify for the first time for certain third-party scripts)
dependency information but keep getting updates for the init script
from the software vendor, this was really, really useful.
A patch that would incorporate both would be something along the lines
of:
- add sysv_override_path to LookupPaths and sysv_override_type
override_type would be either SYSV_OVERRIDE_UPDATING (chkconfig.d
semantics) or SYSV_OVERRIDE_REPLACING (insserv semantics)
- add override_path to struct SysvStub and fill it in
enumerate_sysv() with
lp-sysv_override_path + / + scriptname
- load_sysv(SysvStub *s) - load_sysv(SysvStub *s, const char *path)
+ use that path instead of s-path in there
- in main, replace q = load_sysv(service) with something like
if (!file_exists(service-override_path) || lp-sysv_override_type ==
SYSV_OVERRIDE_UPDATING) {
q = load_sysv(service, service-path);
if (q 0)
continue;
}
if (file_exists(service-override_path)) {
q = load_sysv(service, service-override_path);
if (q 0)
continue;
}
- continue to use s-path for ExecStart etc.
I don't think that would be terribly complicated, but I haven't written
and tested it yet, since I first wanted to know whether you'd consider
this at all.
Note that on servers running Debian I've used /etc/insserv/overrides
countless times over the past years, so maybe chkconfig.d wasn't
something that was widely popularized, but insserv/overrides definitely
was.
Christian
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] sysv-generator: doesn't handle /etc/insserv/overrides or /etc/chkconfig.d
resending, didn't go to list the first time (sorry for the duplicate) Am 16.02.2015 um 12:00 schrieb Jóhann B. Guðmundsson: In the simplest case, the init script is trivial and you just create a simple native service and are better off anyway. But most of the time, init scripts where you want to override headers are provided by third parties, and do a lot of involved things, and as an administrator you don't want to port the old init script yourself, you just want to call the original one and be done with it. (And even worse, some third-party init scripts don't even come with LSB headers, even in 2015.) That's a matter of perception we prefer migrating the legacy sysv initscript on these parts to take advantage of administrator features systemd provides. Sure, in an ideal world. But as I said in my initial mail, if you have crappy scripts provided by third-parties, this is not always an option. And I don't think init scripts are going to fully disappear in the next 10 years, it's not realistic - especially if you look at a lot of third-party scripts, where the authors appear to have had no clue about what they were doing. Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] sysv-generator: doesn't handle /etc/insserv/overrides or /etc/chkconfig.d
Hi, I just noticed that sysv-generator doesn't handle /etc/insserv/overrides (e.g. older SuSE, Debian) or /etc/chkconfig.d (e.g. RHEL = 6, Centos, old Fedora), it just ignores it, thus not retaining administrator overrides to init script headers. Now obviously, one can create a native unit file that overrides the sysv service, but that is not always so nice. In the simplest case, the init script is trivial and you just create a simple native service and are better off anyway. But most of the time, init scripts where you want to override headers are provided by third parties, and do a lot of involved things, and as an administrator you don't want to port the old init script yourself, you just want to call the original one and be done with it. (And even worse, some third-party init scripts don't even come with LSB headers, even in 2015.) Obviously, one can always just copy and modify the generated service file from /run/systemd/generator.late, so it's not like there is no technical solution to this issue, but I think this is one the ugliest ways for the administrator to achieve this, because the settings you want to override are in one format (LSB headers), the format you have to use to override them is a completely different one (service file). Also, if you want to compare the two, you have to manually keep a copy of the service file around as a reference, since sysv-generator doesn't generate units where there's a native one around (which is good in general, but hurts here), otherwise you can't easily just look at both files and view the changes. Would you accept a patch that makes the sysv-generator consider these local overrides? (I have a test patch just for insserv/overrides that's diffstat +14 -8; for chkconfig.d it would be a bit more longer, because you can override individual settings there (and not just all of them at once), but shouldn't be too complicated. Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Container, private network and socket activation
Am 03.02.2015 um 22:06 schrieb Lennart Poettering: Socket activation is somethings daemons need to support explicitly. Many do these days, but I don't think Apache is one of them. FYI: all released versions (i.e. up to 2.4.x) of Apache httpd don't support it yet, but the current development version does - at least if you compile it with the corresponding options (no module needs to be loaded for that, it's in the core). There's a proposal to backport that and sd_notify integration[1] to the stable 2.4.x branch, but nothing's happened so far: http://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/STATUS?revision=1656674view=markup#l138 [1] Although Fedora apparently already includes sd_notify integration for quite a while now, but no socket activation... Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 1/2] systemd.unit(5): add examples for common tasks
Am 27.01.2015 um 19:12 schrieb Lennart Poettering: On Tue, 27.01.15 17:45, Christian Seiler (christ...@iwakd.de) wrote: Add examples for (a) making units enableable and (b) overriding vendor settings to the man page. I am not a native english speaker, but I am not sure there's a word like enableable in the english language. Maybe rephrase this as allowing units to be enabled? Drat. I've read that in technical contexts often enough, and for safety I typed it into google. There were enough results there to make me think 'oh, ok, it's a real word'. A quick look in a dictionary disagrees with that assessment. Oh well. (Although the urban dictionary does have that word, but my guess is you won't accept that as a canonical source for the English language. ;-)) I'll change it. +linking to the actual unit will be created. It +tells systemd to pull in the unit when starting +filenamemulti-user.target/filename. The +converse commandsystemctl disable/command +will remove that symlink again./para +/example converse? shouldn't it be reverse or inverse? Hmm, converse was the first word that popped into my head, but inverse is probably better, yes. +programlisting[Unit] +Description=Some HTTP server +After=network.target remote-fs.target sqldb.service Given the fact that network.target is so vaguely defined, and not even necessary in most cases, I'd really suggest removing this bit fromt the After= line. Ok. +[Service] +Type=notify +ExecStart=/usr/sbin/some-fancy-httpd-server +TimeoutStartSec=5 I think the default timeout should be fine. THere's usually no good reason to change it. I know, but I wanted to have something that was easily understandable at first glance that was already set in the original unit that would then be overridden. I'll use Nice= instead, that's more likely to be used. +paraThe first possibility is to copy the unit +file to + filename/etc/systemd/system/httpd.service/filename +and change the chosen settings:/para + +programlisting[Unit] +Description=Some HTTP server +After=network.target remote-fs.target sqldb.service emphasismemcached.service/emphasis +Requires=sqldb.service emphasismemcached.service/emphasis +ConditionPathExists=emphasis/srv/www/emphasis I wonder if the example should better use AssertionXYZ rather than ConditionXYZ for this? A right, that's new, I'll use that instead. Will send second patch after your response to my question. Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] logind: chown+chmod /run/user/$UID if mount(tmpfs) fails with EPERM
Am 27.01.2015 um 19:02 schrieb Lennart Poettering: Merged this one too, made some changes first howver. I reworked this to use our chmod_and_chown() helper, and removed the bit that checks whether the mount point actually was a mount point after umount2(). I really prefer if we can just check the return value of the syscall and decide on that. Looks much nicer, yes. Please check if this all works for you now! Yes, works for me, directory gets created, chown/chmod is applied, XDG_RUNTIME_DIR is set and loginctl shows the session. Thanks! Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v3] systemd.unit(5): add examples for common tasks
Am 27.01.2015 um 19:32 schrieb Lennart Poettering: On Tue, 27.01.15 19:26, Christian Seiler (christ...@iwakd.de) wrote: Will send second patch after your response to my question. Uh, which question are you precisely referring to? Forget it, I answered that question myself and forgot to edit out the last sentence of my mail. ;-) I've attached git format-patch's output for the revised manpage. Christian From 4d251d71bfa5eb19a7d14392d34357e0e3e859cc Mon Sep 17 00:00:00 2001 From: Christian Seiler christ...@iwakd.de Date: Sat, 24 Jan 2015 14:04:03 +0100 Subject: [PATCH] systemd.unit(5): add examples for common tasks Add examples for (a) how to allow units to be enabled and (b) overriding vendor settings to the man page. --- man/systemd.unit.xml | 165 +++ 1 file changed, 165 insertions(+) diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml index e820b33..9704d6f 100644 --- a/man/systemd.unit.xml +++ b/man/systemd.unit.xml @@ -1574,6 +1574,171 @@ /refsect1 refsect1 +titleExamples/title + +example +titleAllowing units to be enabled/title + +paraThe following snippet (highlighted) +allows a unit (e.g. +filenamefoo.service/filename) to be +enabled via +commandsystemctl enable/command:/para + +programlisting[Unit] +Description=Foo + +[Service] +ExecStart=/usr/sbin/foo-daemon + +emphasis[Install]/emphasis +emphasisWantedBy=multi-user.target/emphasis/programlisting + +paraAfter running +commandsystemctl enable/command, a symlink +filename/etc/systemd/system/multi-user.target.wants/foo.service/filename +linking to the actual unit will be created. It +tells systemd to pull in the unit when starting +filenamemulti-user.target/filename. The +inverse commandsystemctl disable/command +will remove that symlink again./para +/example + +example +titleOverriding vendor settings/title + +paraThere are two methods of overriding +vendor settings in unit files: copying the unit +file from +filename/usr/lib/systemd/system/filename +to filename/etc/systemd/system/filename and +modifying the chosen settings. Alternatively, +one can create a directory named +filenamereplaceableunit/replaceable.d//filename +within +filename/etc/systemd/system/filename and +place a drop-in file +filenamereplaceablename/replaceable.conf/filename +there that only changes the specific settings +one is interested in. Note that multiple such +drop-in files are read if present./para + +paraThe advantage of the first method is +that one easily overrides the complete unit, +the vendor unit is not parsed at all anymore. +It has the disadvantage that improvements to +the unit file by the vendor are not +automatically incorporated on updates./para + +paraThe advantage of the second method is +that one only overrides the settings one +specifically wants, where updates to the unit +by the vendor automatically apply. This has the +disadvantage that some future updates by the +vendor might be incompatible with the local +changes./para + +paraNote that for drop-in files, if one wants +to remove entries from a setting that is parsed +as a list (and is not a dependency), such as +varnameConditionPathExists=/varname (or +e.g. varnameExecStart=/varname in service +units), one needs to first clear the list +before re-adding all entries except the one +that is to be removed. See below for an +example./para + +paraThis also applies for user instances of +systemd, but with different locations for the +unit files. See the section on unit load paths +for further details./para
Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness
On a general note: the stuff I mentioned that I did to modify the
container was just taken from the lxc-debian template that comes with
LXC 1.0, and I didn't have time to look at it thoroughly to see what's
actually needed there. The stuff I mentioned was more along the lines of
'what I did to get where I was if somebody wanted to reproduce it'
instead of 'I recommend doing that'.
Am 27.01.2015 um 03:08 schrieb Lennart Poettering:
- explicitly enable getty@tty{1,2,3,4}.service
Why?
Ah, it's nice to see we all live in our own bubbles. :-)
LXC predates systemd by about 2 years. (And at the very beginning,
systemd didn't support containers out of the box, so it predates
systemd's container support by even more.) And at that time, doing that
was a way to sysvinit containers with no or minimal modification to
/etc/inittab. So instead of saying that LXC breaks systemd's
assumptions, you could also say systemd breaks LXC's assumptions. As I
said: bubbles. ;-)
Now I'm not going to argue with you that the method of doing
$container_ttys= isn't vastly superior to what was there previously,
because it is. So I don't disagree with the long-term solution at all.
But LXC 1.0 just doesn't support this yet, so the question is what to do
in the mean time. If I do what I described:
- logind can't open /dev/tty0, so all VT management in there is
disabled anyway
- within systemd: vt_disallocate can't open /dev/tty0, so it just
returns an error, but that error code is never checked in
core/execute.c, so it just behaves as if the directive never had
been there
- getty@.service statically enabled just runs agetty, so really only
$TERM is wrong
- but that was wrong already with sysvinit containers, and I never had
any major issues because of that
So yeah, it's not pretty, it shouldn't stay in the long run, I
completely agree with your reasoning why you don't like it, but
currently it does seem to 'work'.
That being the case, thinking about it, I actually don't use this
feature myself (with kernels = 3.12 or so, lxc-attach works quite well,
so I never actually had the need to use a console to log in to a
container, for normal purposes I use SSH anyway), so maybe I'm just
going to deactivate the whole thing in my local config anyway.
Speaking of, isn't there a bug in container-getty@.service?[*] It uses
ConditionPathExists=/dev/pts/%I, starts agetty on pts/%I but sets
TTYPath=/dev/%I instead of /dev/pts/%I... And having the utmp specifier
be just a number (%I) instead of pts/%I is also probably weird.
[*]
http://cgit.freedesktop.org/systemd/systemd/tree/units/container-ge...@.service.m4.in
- mask systemd-udevd.service (haven't tested if that's actually needed,
the lxc-debian template also does this however)
There's no point in doing that. udev uses
ConditionPathIsReadWrite=/sys anyway, and is automatically skipped
hence when /sys is read-only.
Ah, good point, so it is in fact not needed. No idea why that's in there
then. Perhaps from a historic attempt when systemd didn't have that
Condition in there?
- touch /etc/fstab if you debootstrap it directly
You can just remove it. You don't need it in containers (and not even
on most hosts, unless you actually need to refer to external
partitions that cannot be auto-configured.
Ah, indeed, just tried it. Interesting, why did I write that? No idea...
I am tempted to just
change nspawn to mount a private tmpfs into /run/user, too, as it
already mounts /run anyway.
That would solve /run-quota issues for CAP_SYS_ADMIN-less containers,
but is unnecessary (although harmless) for those that do have it.
I decided against doing this after all. [...] Hence, we either do
something (possibly skipping it it on missing perms) or, we don't do
it at all, [...]
Fair enough[#], but did you receive my patches for the part about
skipping on missing perms?
http://lists.freedesktop.org/archives/systemd-devel/2015-January/027343.html
http://lists.freedesktop.org/archives/systemd-devel/2015-January/027344.html
[#] One could probably always do --tmpfs=/run/lock:options with nspawn
anyway, if one wants to explicitly do this.
Christian
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v3] systemd.service(5): add some simple examples
Am 27.01.2015 um 21:45 schrieb Lennart Poettering: On Tue, 27.01.15 17:45, Christian Seiler (christ...@iwakd.de) wrote: +paraNote that systemd assumes here that the +program will continue running in the foreground +as long as it's active. If the program I think foreground vs. background here is probably something to avoid. These are services after all, and hence kinda background in all cases. I am not sure how to explain this better though... Maybe clarify that the program does not fork on its own, and that the process systemd starts stays running until the very end of the daemon, or so. Yes, you are completely right. I've kept the use of 'background' at some places, but specifically avoided foreground, since that is really, really misleading. I've also rephrased the paragraph in question. I hope that's better. +paraNote that systemd will consider the unit +to be in the state 'starting' until the program +has terminated, so ordered dependencies will +wait for the program to finish before starting +themselves. The unit will revert to the +'inactive' state after the execution is +done. That means another request to start the +unit will perform the action again./para It might be worth also mentioning here that the the unit this way will never actually be active. It will go directly from activating to inactive, which might be surprising! Thanks for the pointer, done! Now I also mentioned something about multiple ExecStart= for oneshot units, which might be useful there. +paraSimilarly to the oneshot services, there +are sometimes units that need to execute a +program to set up something and then execute +another to shut it down, but no process remains +active while they are considered +'started'. Network configuration can sometimes +fall into this category./para Another reason to use RemainAfterExit= are services that shall not execute again and again when they are pulled in, but only the first time... Mentioned that, thanks! varnameRemainAfterExit=/varnameoptiondbus/option Typo. Should be Type=, not RemainAfterExit= *hehe* fixed. +example +titleDeferred (idle) services/title Hmm, I wonder if we maybe should remove this part. Idle services are kinda exotic, and I figure people might be tempted to misuse them. I think this might be something to document at the description of Type=, but not push people towards using this beyond that. When I started writing this, I didn't just want to copy the getty service (people can look that up anyway), so I decided to come up with something else. However, once I wrote that unit, I realized that this could have easily just been a Type=oneshot, RemainAfterExit=yes, After=multi-user.target unit and have the same effect, and be a lot more consistent with the rest of the way of doing things... Type=idle is basically really just for gettys or something extremely similar (like other interactive apps on VTs) that also get automatically restarted. Since these examples are supposed to provide a starting point for people on how to write services, I've removed the section completely, and I think this kind of special internal thing should remain in the reference documentation. v3 attached, I also fixed one or two other minor typos I noticed. Christian From ff44c16a173b36695e4844b36fbd10ac977bf4a3 Mon Sep 17 00:00:00 2001 From: Christian Seiler christ...@iwakd.de Date: Tue, 27 Jan 2015 17:38:02 +0100 Subject: [PATCH] systemd.service(5): add some simple examples Add a couple of exampels, at least one for each service type that include some explanations and pointers to various relevant options. --- man/systemd.service.xml | 296 1 file changed, 296 insertions(+) diff --git a/man/systemd.service.xml b/man/systemd.service.xml index 4c890df..f33e8df 100644 --- a/man/systemd.service.xml +++ b/man/systemd.service.xml @@ -1358,6 +1358,302 @@ ExecStart=/bin/echo $ONE $TWO $THREE/programlisting /refsect1 refsect1 +titleExamples/title + +example +titleSimple service/title + +paraThe following unit file creates a service +that will execute +filename/usr/sbin/foo-daemon/filename. +Since no varnameType=/varname is specified, +the default +varnameType=/varnameoptionsimple/option
Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness
Am 27.01.2015 um 14:46 schrieb Lennart Poettering: Note that $container_ttys= is actually just a frontend for dynamically instantiating console-getty@.service instances for the specified ptys. You can just enable them statically too. No, I can't, because you only support PTY numbers in that interface and I can't predict which ones will get assigned. Oh, I see now, I can use ../ in the statically enabled, and that actually works. If I now combine that with LXC's feature to add a subdir to the ttys, I can do the following: - tell LXC to create /dev/lxc/ttyN instead - statically enable container-getty@..-lxc-ttyN.service - just tried it: works Thanks! Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Examples in man pages
Just a heads-up: while reading the Unwants thread I noticed that dependencies are the only types of lists in unit files that can't be reset, so my example in there actually doesn't work, so please don't commit my patch just now. I'm writing more examples and will resubmit anyway. Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unwants
Am 27.01.2015 um 15:45 schrieb Zbigniew Jędrzejewski-Szmek: On Tue, Jan 27, 2015 at 01:36:41PM +0100, Lennart Poettering wrote: Dependencies are always additive and coalescing currently. We don't track which configuration file or automatic logic created which dependency, and hence it is not really possible right now do reset the list of dependencies: we wouldn't know what to reset and what not. Note that in many cases dependencies can be created from both sides, and if A wants some dependency on B, and B also wants it from A, then we coalesce it one. If now some configuration in A wants to reset its setting, what do we do with the request from B? Yes, I think attempting any kind of dependency removal *from loaded units* would be very complicated, and would require major surgery to current unit engine. And things would become conceptually more complicated, which we certainly don't need. But masking of .wants/ links is something different I think. It is a *localized* modification to a single configuration file. We currently allow overridding of almost all configuration (units files, files in .d directories, recently even generators), but .wants and .requires are an exception. I think we should allow this. Apart from current use case, it would things more consistent for the user. Additionally, not considering .wants/ but drop-ins: currently, all[*] lists except dependencies can be overridden in drop-ins by resetting them first. So if I write ConditionPathExists=/foo in the unit file, and then ConditionPathExists= ConditionPathExists=/bar in a snippet, that will work as expected. Not so for dependencies. The problem here is I think a bit in the parsing logic: when parsing a unit file, dependencies are immediately added to the unit in question. If you were to first collect them as a set and then only after all drop-ins / etc. of a unit file are parsed you would add them to the unit's dependencies, this would immediately solve the problem. Also note that if b.service as Before=a.service, I would NOT expect and empty After= in a.service to override that, it would be weird. This is another good reason to first collect stuff locally (and only do overrides on that level) before adding the global state at the end of parsing. Or to put it this way: if you take the following things: - the unit file itself - all drop-ins - all .requires.d/ - all .wants.d/ you could combine them (according to precedence rules) to a single large unit file and only then process that. This is at least what I think is a good way to model this, and that's how I modeled it in my head as a user before I looked at the code, when I realized that that's not the case. If you make the code work in a way that respects that model, I think that a lot of things about overrides become much more consistent. Just my 2 cents. Christian [*] Probably, I haven't checked. ;-) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v2 2/2] systemd.service(5): add some simple examples
Add a couple of exampels, at least one for each service type that include some explanations and pointers to various relevant options. --- man/systemd.service.xml | 332 1 file changed, 332 insertions(+) diff --git a/man/systemd.service.xml b/man/systemd.service.xml index 4c890df..5ccbba0 100644 --- a/man/systemd.service.xml +++ b/man/systemd.service.xml @@ -1358,6 +1358,338 @@ ExecStart=/bin/echo $ONE $TWO $THREE/programlisting /refsect1 refsect1 +titleExamples/title + +example +titleSimple service/title + +paraThe following unit file creates a service +that will execute +filename/usr/sbin/foo-daemon/filename. +Since no varnameType=/varname is specified, +the default +varnameType=/varnameoptionsimple/option +will be assumed. systemd will assume the unit +to be started immediately after the program has +begun executing./para + +programlisting[Unit] +Description=Foo + +[Service] +ExecStart=/usr/sbin/foo-daemon + +[Install] +WantedBy=multi-user.target/programlisting + +paraNote that systemd assumes here that the +program will continue running in the foreground +as long as it's active. If the program +backgrounds/daemonizes/forks itself, please use +varnameType=/varnameoptionforking/option +instead./para + +paraSince no varnameExecStop=/varname was +specified, systemd will send SIGTERM to all +processes started from this service, and after +a timeout also SIGKILL. This behavior can be +modified, see + citerefentryrefentrytitlesystemd.kill/refentrytitlemanvolnum5/manvolnum/citerefentry +for details./para + +paraNote that this unit type does not include +any type of notification when a service has +completed initialization. For this, you should +use other unit types, such as +varnameType=/varnameoptionnotify/option +if the service understands systemd's +notification protocol, +varnameType=/varnameoptionforking/option +if the service can background itself or +varnameType=/varnameoptiondbus/option +if the unit acquires a DBus name once +initialization is complete. See below./para +/example + +example +titleOneshot service/title + +paraSometimes units should just execute an +action without keeping active processes, such +as a filesystem check or a cleanup action on +boot. For this, +varnameType=/varnameoptiononeshot/option +exists. Units of this type will wait until the +process specified terminates and then fall back +to being inactive. The following unit will +perform a clenaup action:/para + +programlisting[Unit] +Description=Cleanup old Foo data + +[Service] +Type=oneshot +ExecStart=/usr/sbin/foo-cleanup + +[Install] +WantedBy=multi-user.target/programlisting + +paraNote that systemd will consider the unit +to be in the state 'starting' until the program +has terminated, so ordered dependencies will +wait for the program to finish before starting +themselves. The unit will revert to the +'inactive' state after the execution is +done. That means another request to start the +unit will perform the action again./para +/example + +example +titleStoppable oneshot service/title + +paraSimilarly to the oneshot services, there +are sometimes units that need to execute a +program to set up something and then execute +another to shut it down, but no process remains +active while they are considered +'started'. Network configuration can sometimes +fall into this
[systemd-devel] [PATCH v2 1/2] systemd.unit(5): add examples for common tasks
Add examples for (a) making units enableable and (b) overriding vendor settings to the man page. --- man/systemd.unit.xml | 164 +++ 1 file changed, 164 insertions(+) diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml index e820b33..8714f70 100644 --- a/man/systemd.unit.xml +++ b/man/systemd.unit.xml @@ -1574,6 +1574,170 @@ /refsect1 refsect1 +titleExamples/title + +example +titleMaking a unit enableable/title + +paraThe following snippet (highlighted) makes +a unit (e.g. filenamefoo.service/filename) +enableable via +commandsystemctl enable/command:/para + +programlisting[Unit] +Description=Foo + +[Service] +ExecStart=/usr/sbin/foo-daemon + +emphasis[Install]/emphasis +emphasisWantedBy=multi-user.target/emphasis/programlisting + +paraAfter running +commandsystemctl enable/command, a symlink + filename/etc/systemd/system/multi-user.target.wants/foo.service/filename +linking to the actual unit will be created. It +tells systemd to pull in the unit when starting +filenamemulti-user.target/filename. The +converse commandsystemctl disable/command +will remove that symlink again./para +/example + +example +titleOverriding vendor settings/title + +paraThere are two methods of overriding +vendor settings in unit files: copying the unit +file from +filename/usr/lib/systemd/system/filename +to filename/etc/systemd/system/filename and +modifying the chosen settings. Alternatively, +one can create a directory named +filenamereplaceableunit/replaceable.d//filename +within +filename/etc/systemd/system/filename and +place a drop-in file + filenamereplaceablename/replaceable.conf/filename +there that only changes the specific settings +one is interested in. Note that multiple such +drop-in files are read if present./para + +paraThe advantage of the first method is +that one easily overrides the complete unit, +the vendor unit is not parsed at all anymore. +It has the disadvantage that improvements to +the unit file by the vendor are not +automatically incorporated on updates./para + +paraThe advantage of the second method is +that one only overrides the settings one +specifically wants, where updates to the unit +by the vendor automatically apply. This has the +disadvantage that some future updates by the +vendor might be incompatible with the local +changes./para + +paraNote that for drop-in files, if one wants +to remove entries from a setting that is parsed +as a list (and is not a dependency), such as +varnameConditionPathExists=/varname (or +e.g. varnameExecStart=/varname in service +units), one needs to first clear the list +before re-adding all entries except the one +that is to be removed. See below for an +example./para + +paraThis also applies for user instances of +systemd, but with different locations for the +unit files. See the section on unit load paths +for further details./para + +paraSuppose there is a vendor-supplied unit + filename/usr/lib/systemd/system/httpd.service/filename +with the following contents:/para + +programlisting[Unit] +Description=Some HTTP server +After=network.target remote-fs.target sqldb.service +Requires=sqldb.service +ConditionPathExists=/srv/webserver + +[Service] +Type=notify +ExecStart=/usr/sbin/some-fancy-httpd-server +TimeoutStartSec=5 + +[Install] +WantedBy=multi-user.target/programlisting + +paraNow one wants to change some settings as +an administrator: firstly, in the
Re: [systemd-devel] Examples in man pages
Am 24.01.2015 um 15:18 schrieb Zbigniew Jędrzejewski-Szmek: On Sat, Jan 24, 2015 at 02:13:00PM +0100, Christian Seiler wrote: +example +titleMaking a unit enableable/title + +paraThe following snippet makes a unit +(e.g. filenamefoo.service/filename) +enableable via +commandsystemctl enable/command:/para + +programlisting[Install] +WantedBy=multi-user.target/programlisting + +paraAfter running +commandsystemctl enable/command, a symlink + filename/etc/systemd/system/multi-user.target.wants/foo.service/filename +linking to the actual unit will be created. It +tells systemd to pull in the unit when starting +filenamemulti-user.target/filename. The +converse commandsystemctl disable/command +will remove that symlink again./para The description is good. I wonder if it might better to inlcude a complete unit here and discuss all lines, instead of just a snippet. I wanted to keep it as minimal an example as possible, but maybe something absolutely trivial such as: [Unit] Description=Foo [Service] ExecStart=/usr/sbin/foo-daemon [Install] WantedBy=multi-user.target with the last section highlighted (emphasis)? I don't want to make it too complicated. [ example about overriding vendor defaults ] This part looks nice too. Thanks! I'll then go on and write a couple more examples for different typical use cases. Here's what I'd want to cover: - systemd.service(5) - Type=simple - RemainAfterExit= discussion - Type=oneshot - RemainAfterExit= discussion - Type=forking - PIDFile=, GuessMainPID= - Type=dbus - Type=notify - also include snippet for required code in daemon and link to sd_notify(3) - Type=idle: getty example - systemd.target(5) - use remote-fs.target to discuss how synchronization points via targets work (but also note how DefaultDependencies= makes that one special) - example of service group with PartOf= - systemd.socket(5) - inetd style activation Accept=yes - systemd style activation Accept=no - also include snippet for required code in daemon and link to sd_listen_fds()/... - systemd.timer(5) - just a trivial example w/ a oneshot service - systemd.path(5) - dynamically activate service based on presence of configuration (and explain difference to ConditionPatchExists=) - systemd.mount(5), systemd.automount(5) and systemd.swap(5) - an example that is equivalent to a given entry in /etc/fstab and then explain how additional systemd options such as Condition...= can be used to go beyond what is possible in /etc/fstab I'll probably skip systemd.device(5), because I can't think of a good example for manually using those units. Did I forget anything? Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness
Am 23.01.2015 um 18:57 schrieb Lennart Poettering:
Am 2015-01-23 08:29, schrieb Mantas Mikulėnas:
IIRC, the reason for tmpfs on /run/user/* was lack of tmpfs quotas...
if thats still a problem, maybe there could be one tmpfs at /run/user,
still preventing users from touching root-only /run?
Yes, that's a good idea. Initially when posting this thread I thought
that there just had to be a trade-off between dropping CAP_SYS_ADMIN
(and making it more difficult to escape the container), and a user
inside the container DOSing the container by filling up /run.
But with your idea, I can at least separate /run/user from /run
itself
Hmm, which container manager are you using?
LXC 1.0.6 (which comes with Debian Jessie). I use the following
configuration for containers w/o CAP_SYS_ADMIN (note: I'm not claiming
this is secure (non-userns-containers may never be), and also this is
still work in progress and I'm only posting this as a proof of concept
and so that other people can reproduce it):
/etc/lxc/lxc.conf:
lxc.cgroup.use = @all
/etc/lxc/jessie-container.conf:
# This is still work in progress, I can probably get rid of some of
# those FSs, I'm not really comfortable with e.g. debugfs there.
# But if I remove them, I'll probably have to mask the units unless I
# want error messages on every container startup, and I would really
# like to keep the delta low... Still thinking about that.
lxc.mount.auto = proc sys cgroup:mixed
lxc.mount.entry = tmpfs dev/shm tmpfs rw,nosuid,nodev,create=dir 0 0
lxc.mount.entry = tmpfs run tmpfs rw,nosuid,nodev,mode=755,create=dir 0 0
lxc.mount.entry = tmpfs run/lock tmpfs
rw,nosuid,nodev,noexec,relatime,size=5120k,create=dir 0 0
lxc.mount.entry = debugfs sys/kernel/debug debugfs rw,relatime 0 0
lxc.mount.entry = mqueue dev/mqueue mqueue rw,relatime,create=dir 0 0
lxc.mount.entry = hugetlbfs dev/hugepages hugetlbfs
rw,relatime,create=dir 0 0
# here I'll probably add the /run/user entry
lxc.tty = 4
lxc.pts = 1024
lxc.cap.drop = sys_admin sys_module mac_admin mac_override net_admin
sys_time syslog
lxc.cgroup.devices.deny = a
lxc.cgroup.devices.allow = c *:* m
lxc.cgroup.devices.allow = b *:* m
lxc.cgroup.devices.allow = c 1:3 rwm #/dev/null
lxc.cgroup.devices.allow = c 1:5 rwm #/dev/zero
lxc.cgroup.devices.allow = c 1:7 rwm #/dev/full
lxc.cgroup.devices.allow = c 5:0 rwm #/dev/tty
lxc.cgroup.devices.allow = c 1:8 rwm #/dev/random
lxc.cgroup.devices.allow = c 1:9 rwm #/dev/urandom
lxc.cgroup.devices.allow = c 1:9 rwm #/dev/urandom
lxc.cgroup.devices.allow = c 5:2 rwm #/dev/pts/ptmx
lxc.cgroup.devices.allow = c 136:* rwm #/ev/pts/*
lxc.cgroup.devices.allow = c 254:0 rm #/dev/rtc{,0}
lxc.cgroup.devices.allow = c 10:228 rm #/dev/hpet
# this is just the Debian default, I didn't change anything
# there (so far):
lxc.seccomp = /usr/share/lxc/config/common.seccomp
lxc.autodev = 1
lxc.kmsg = 0
lxc.haltsignal = SIGRTMIN+14
/var/lib/lxc/$container/config:
lxc.include = /etc/lxc/jessie-container.conf
lxc.utsname = something
lxc.rootfs = /path/to/something
lxc.arch= amd64
# network:
lxc.network.type = veth
# (and other directives that specify IP etc.)
Also inside the container the following changes w.r.t. vanilla Jessie:
- explicitly enable getty@tty{1,2,3,4}.service
- no ConditrionPathExists=/dev/tty0 for getty@.service
- mask systemd-udevd.service (haven't tested if that's actually needed,
the lxc-debian template also does this however)
- touch /etc/fstab if you debootstrap it directly
- I hope I didn't forget anything
Didn't try other Distros inside the containers yet (or LXC w/ systemd on
other distros for that matter).
Also, on the host, I DON'T have cgmanager or similar installed.
I am tempted to just
change nspawn to mount a private tmpfs into /run/user, too, as it
already mounts /run anyway.
That would solve /run-quota issues for CAP_SYS_ADMIN-less containers,
but is unnecessary (although harmless) for those that do have it.
(the same way mode=1777 /run/lock is a separate tmpfs already)
by just a simple static mount entry for the container.
Hmm, /run/lock is a sepatate tmpfs? /run/lock is a pretty useless,
legacy thing. Which distro is this?
Debian Jessie. But a box with Fedora 19 here also has it (although not
mode=1777 but mode=0755) and in both Debian Jessie and Fedora 19 there
is some stuff in there. Although on Fedora it's not a separate tmpfs.
(Note that in Debian you can also configure it to be on the same tmpfs
as /run, but since on Debian it has mode 1777, there's a good reason NOT
to do that.)
Christian
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] service.d/.conf files and multi-valued options
Am 2015-01-23 14:27, schrieb Lennart Poettering: Yes, it does, although only in the general systemd.unit(5), not in the specific options, so maybe it's not that easy to find. Actually, it kinda says it in the specific options. From the explanation of ExecStart=: ...If the empty string is assigned to this option, the list of commands to start is reset, prior assignments of this option will have no effect... Oh, I didn't see that while skimming the man page. Still, I think a tutorial manpage as I described (different ways to override distro configuration) would be a good idea. Would you accept a patch for something like that? If so, what should the man page be called? And at the explanation of ExecStartPre= says the syntax is identical to ExecStart=. So I think we are covered here. No, sure, I don't think ExecStartPre= needs additional information, I just didn't see the sentence in ExecStart=, sorry about that. Btw. it would also be nice to have a possibility to just remove a specific entry from a list, not to reset it completely. Probably less for things like Exec*=, but more for After=/Before=/... For example, if there's a unit with After=b.service c.service und as an admin I want to not order it after c.service, I will have to first reset the list (empty After=) and then add all the current other units it orders after again. If an update then makes the unit also be ordered after d.service to fix some other bug, the local setting will override the After=d.service too... Maybe something like 'After-=c.service'? Although that would probably break traditional ini parsers trying to process unit files... I'd be very careful with coming up with more and more syntaxes like this. People have also requested +=, to append things to existing lines. I agree that I also don't like that syntax, but: I think for simplicity's sake the right approach to remove parts of a unit file is to copy it from /usr to /etc, and then modify it there. .d/ is not the answer to everything. I am aware of course that copying the files from /usr to /etc will also disconnect you from new unit files added by package updates, but I guess you cannot have a cake and eat it too... But if I want to add something to After=/Before=/..., I can easily do that with a drop-in just containing After=foo.service. And that's indeed very useful, I've used that a couple of times. So for symmetry reasons, I think the converse would also be quite useful (although I haven't needed it that often). I don't have a good idea for the syntax just now, but would you be opposed to at least adding 'design a syntax for this' to the TODO list? Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] service.d/.conf files and multi-valued options
Am 2015-01-23 12:21, schrieb Matthias Urlichs: Igor Bukanov: It is not clear from the systemd.unit manual page what happens when foo.service.d/bar.conf sets an option like Service/ExecStartPre that can be specified multiple times. From experimenting I see that *.conf files supply additional values to the option and to overwrite or remove already given values for the option one have to copy the whole file into /etc and edit it there. Is it so? Doesn't the manpage state that an empty entry clears the list? Yes, it does, although only in the general systemd.unit(5), not in the specific options, so maybe it's not that easy to find. I think it would be nice to have some kind of man page that is a tutorial as to what are the best practices to override distro service files with your own site-specific configuration, which also includes a couple of simple examples that cover the most common cases. Btw. it would also be nice to have a possibility to just remove a specific entry from a list, not to reset it completely. Probably less for things like Exec*=, but more for After=/Before=/... For example, if there's a unit with After=b.service c.service und as an admin I want to not order it after c.service, I will have to first reset the list (empty After=) and then add all the current other units it orders after again. If an update then makes the unit also be ordered after d.service to fix some other bug, the local setting will override the After=d.service too... Maybe something like 'After-=c.service'? Although that would probably break traditional ini parsers trying to process unit files... Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] logind: remove per-user runtime dir again if setup fails
If setup of per-user runtime dir fails, clean up afterwards by removing
the directory before returning from the function, so we don't leave the
directory behind.
If this is not done, the second time the user logs in logind would
assume that the directory is already set up, even though it isn't.
---
src/login/logind-user.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/login/logind-user.c b/src/login/logind-user.c
index 49c373b..d7930ad 100644
--- a/src/login/logind-user.c
+++ b/src/login/logind-user.c
@@ -336,6 +336,9 @@ static int user_mkdir_runtime_path(User *u) {
r = mount(tmpfs, p, tmpfs, MS_NODEV|MS_NOSUID, t);
if (r 0) {
+/* try to clean up, but ignore errors */
+r = -errno;
+rmdir(p);
log_error_errno(r, Failed to mount per-user tmpfs
directory %s: %m, p);
goto fail;
}
--
2.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] logind: chown+chmod /run/user/$UID if mount(tmpfs) fails with EPERM
In containers without CAP_SYS_ADMIN, it is not possible to mount tmpfs
(or any filesystem for that matter) on top of /run/user/$UID.
Previously, logind just failed in such a situation.
Now, logind will resort to chown+chmod of the directory instead. This
allows logind still to work in those environments, although without the
guarantees it provides (i.e. users not being able to DOS /run or other
users' /run/user/$UID space) when CAP_SYS_ADMIN is available.
---
src/login/logind-user.c | 31 ---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/src/login/logind-user.c b/src/login/logind-user.c
index d7930ad..3f7e3ce 100644
--- a/src/login/logind-user.c
+++ b/src/login/logind-user.c
@@ -335,12 +335,28 @@ static int user_mkdir_runtime_path(User *u) {
}
r = mount(tmpfs, p, tmpfs, MS_NODEV|MS_NOSUID, t);
-if (r 0) {
+if (r 0 errno != EPERM) {
/* try to clean up, but ignore errors */
r = -errno;
rmdir(p);
log_error_errno(r, Failed to mount per-user tmpfs
directory %s: %m, p);
goto fail;
+} else if (r 0 errno == EPERM) {
+/* we probably don't have CAP_SYS_ADMIN and are in a
+ * container, so just try to chown()/chmod() the
+ * directory. */
+log_debug(Failed to mount per-user tmpfs directory
%s, just setting permissions., p);
+
+r = chown(p, u-uid, u-gid);
+if (r = 0)
+r = chmod(p, 0700);
+
+if (r 0) {
+r = -errno;
+rmdir(p);
+log_error_errno(r, Failed to change
permissions of per-user tmpfs directory %s: %m, p);
+goto fail;
+}
}
}
@@ -513,8 +529,17 @@ static int user_remove_runtime_path(User *u) {
if (r 0)
log_error_errno(r, Failed to remove runtime directory %s:
%m, u-runtime_path);
-if (umount2(u-runtime_path, MNT_DETACH) 0)
-log_error_errno(errno, Failed to unmount user runtime
directory %s: %m, u-runtime_path);
+r = umount2(u-runtime_path, MNT_DETACH);
+if (r 0) {
+r = -errno;
+/* only log an error if the directory was a mount point,
+ * otherwise it could just be that we weren't able to
+ * mount it because we don't have CAP_SYS_AMDIN. */
+if (path_is_mount_point(u-runtime_path, false) 0)
+log_error_errno(r, Failed to unmount user runtime
directory %s: %m, u-runtime_path);
+else
+log_debug_errno(r, Failed to unmount user runtime
directory %s: %m, u-runtime_path);
+}
r = rm_rf(u-runtime_path, false, true, false);
if (r 0)
--
2.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] logind vs CAP_SYS_ADMIN-lessness
Am 2015-01-23 08:29, schrieb Mantas Mikulėnas: IIRC, the reason for tmpfs on /run/user/* was lack of tmpfs quotas... if thats still a problem, maybe there could be one tmpfs at /run/user, still preventing users from touching root-only /run? Yes, that's a good idea. Initially when posting this thread I thought that there just had to be a trade-off between dropping CAP_SYS_ADMIN (and making it more difficult to escape the container), and a user inside the container DOSing the container by filling up /run. But with your idea, I can at least separate /run/user from /run itself (the same way mode=1777 /run/lock is a separate tmpfs already) by just a simple static mount entry for the container. Thanks for bringing this up! Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] logind vs CAP_SYS_ADMIN-lessness
I've been playing around with systemd on Debian Jessie in CAP_SYS_ADMIN-less and I came upon the following issue[1]: Without CAP_SYS_ADMIN, logind is unable to mount a per-user tmpfs to /run/user/$UID. Relevant journal messages: systemd-logind[48]: Failed to mount per-user tmpfs directory /run/user/600: Operation not permitted sshd[1357]: pam_systemd(sshd:session): Failed to create session: Access denied The user is still allowed to log in, but there are some unwanted side effects: - ls -l /run/user total 0 drwx-- 2 root root 40 Jan 22 15:00 0 drwx-- 2 root root 40 Jan 22 14:46 600 Therefore, /run/user/$UID is effectively useless because the permissions are wrong (logind aborts after mkdir but before mount). Also: lack of cleanup on this error could be considered a second (more minor) problem. - XDG_RUNTIME_DIR not set (pam_systemd aborts beforehand) - user not registered in logind (loginctl doesn't show user) - user not put in cgroup (logind aborts before that logic happens), they stay in the getty@tty*.service / ssh.service cgroup. - probably some more stuff related to this Obviously, without CAP_SYS_ADMIN you can never mount not even a tmpfs to /run/user/$UID, so it's clear why it doesn't work. For now, this is mostly a cosmetic issue for me, because I don't really need logind functionality in such containers, so it's not a huge problem for me. Nevertheless, I think it would be great if this could also be fixed, because you never know what other applications people might come up with. The solution would probably be to just add a code path to chown the directory instead of mounting a tmpfs on top of it. That doesn't separate users from root inside the container quite as much, but in containers without CAP_SYS_ADMIN, I think that's a trade-off that's worth making. What do you think? Regards, Christian [1] Note that the only other issue I stumbled upon has now been fixed, so in general I would say that systemd already works really well in containers without CAP_SYS_ADMIN if you know how to set them up properly. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Shutdown problems
Am 2014-11-07 04:07, schrieb Nikolaus Rath: $ cat /lib/systemd/system-shutdown/debug.sh #!/bin/sh exec /shutdown.log exec 21 mount -o remount,rw / Well, you need to mount / rewrite *before* redirecting output into a file. Try putting the 'mount -o remount,rw /' line to the top of the script and try again. Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3] systemctl: add edit verb
Am 2014-10-22 10:36, schrieb Lennart Poettering: We can do this for the pager because there is no arguments to give, here we have a list of paths. THinking about this: are all those editors actually fine with editing multiple files at once? is nano? I know for certain that nano, vim, emacs, joe, kwrite and gedit support multiple files on the command line (and switching between them). Therefore, I don't think that will be an issue. The biggest problem I see with this is more the fact that you don't immediately recognize that multiple files are open (and not just in nano, some other editors suffer from the same problem). But calling it mutliple times in sequence is even worse, since then you can't even switch between files and suspend (Ctrl-Z) will probably do some really weird stuff. What about the following? - if there is only one file: call the editor just with the one file - if there is more than one file: create a temporary file in /tmp (that will be deleted afterwards) that contains a list of all files that are opened by the editor + some explanation text (like git/svn/... commit message hints) and put that in front of the list of files that are to be edited. Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Apply ProtectSystem to non-merged /usr directories
Am 2014-10-20 17:05, schrieb Lennart Poettering:
I am sorry, but this is nothing we want to support. Monopolizing the
OS in /usr is what makes ProtectSystem= work. If you split things up
into many dirs then you will simply not get the same level of
protection. We will not try to list every possible dirs that the OS
might be split up to in systemd.
Why wouldn't you get the same level of protection, even if it is split
up? I mean, we are talking about /bin, /sbin, /lib and possibly some
pseudo-multiarch-variants for /lib - it's not like there are any other
directories, the /usr-merge is about moving /bin, /sbin and /lib to
/usr/$dir. I don't see that split-/usr with these additional
directories
protected would be inherently more insecure.
Note that your patch is likely to break systems that have the dirs
you
list as symlinks (which all systems that have /usr merged have).
But on those systems, systemd is going to be compiled without
HAVE_SPLIT_USR, right?
Also note that it hardcodes x86_64 peculiarities in an
arch-independent way, which looks pretty wrong too.
That is definitely a good point. Also note that /lib32 is not included
in the patch...
We are fine with supporting HAVE_SPLIT_USR work to the level where
things generally work, but given that ProtectSystem= is only an extra
layer of protection where nothing breaks if it doesn't fully protect
systems that haven't done the usr-merge I think applying this patch
is not useful.
But computer security often works as defence in depth. Of course
ProtectSystem is an additional security measure, and protecting /usr
alone is obviously still better than protecting nothing at all, but if
it is not much work to provide a slightly higher level of protection -
why not?
That all said, to add something constructive to this: If I put my
administrator hat on, I think I can come up with something that might
make all parties happy:
To start with, ProtectSystem does not include /opt. Now I don't suggest
adding that to the list: distributions by default do not install
anything there, therefore a vanilla installation of a reasonable
distribution will not be affected by this. And there might be software
which requires system services to be able to write to /opt (for
example,
think of some proprietary software that creates logfiles underneath
/opt
that you want to rotate, but want the logrotate-job to use
ProtectSystem, since it's run as root), so it's probably a good default
not to include it.
However, as an administrator, if I know what software is installed
underneath /opt, and that there is no need for services to write to it,
I might actually want to include it. Of course, I could add drop-ins
for
all services that use ProtectSystem to also have
ReadOnlyDirectories=/InaccessibleDirectories=, but that would mean as
an
administrator I have to track these services - and if an update
suddenly
changes service files to use ProtectSystem= for increased protection,
I'd likely miss that and not be able to add these directives.
Additionally, not all custom installations follow the FHS and put
everything in /opt. I've seen computing clusters where software was
installed centrally and mounted per NFS to some other top-level
directory that is not /opt and /usr.
Therefore, may I suggest to make this configurable in
/etc/systemd/system.conf:
- have an option such as ProtectSystemDirectories= that is a list
like the other *Directories= options for units
- set the default to /usr, -/boot (like currently)
- distributions can customize that to fit their needs (depending on
/lib{32,64}, split- or no-split-/usr, etc.)
- administrators may themselves add /opt and other directories if
needed
- still hard-code /etc for ProtectSystem=full
If you're willing to accept a patch for this, I'd provide one.
Christian
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Apply ProtectSystem to non-merged /usr directories
Am 2014-10-21 14:28, schrieb Lennart Poettering: We explicitly make no assumptions on /opt because nobody knows right now what it is supposed to be... Sure, I wasn't disputing that point. Same for /usr, /bin, /sbin, and the other stuff Martin#s patch added: we cannot make assumptions about it, it might be (and is in real life) set up in different ways, and we don't want to be in that game. That's why I didn't suggest that you (as upstream) should be in that game, but that distributions and administrators should be able to do so themselves. Therefore, may I suggest to make this configurable in /etc/systemd/system.conf: [...] If you're willing to accept a patch for this, I'd provide one. I really disagree that this would be a good idea. We should give clear guidelines how things should be set up here to take full benefit of the functionality. Because this is about an agreement between the OS people and the upstream developers of packages to run on the OS. We want to make sure they can make the assumptions everywhere, which are not configurable and behave differently everywhere. For example, I really want that let's say apache sets ProtectSystem= and can be sure it will just not break things on our OSes. And because of that its impact should be only on the safe subset, and it should be the same on all installations, and not be subject to configuration. Debian's systemd package currently includes a variant of Martin's patch that does include additional directories. So your point that ProtectSystem= does the same thing on every distro is already not true. Of course, if you make it configurable, people can shoot themselves in the foot. But you already have a ton of global options in system.conf that can break a lot of software if people do stupid stuff with it: - set a global CapabilityBoundingSet= that's very restrictive - either the system doesn't boot at all because some essential stuff is completely missing - or it boots but some services don't work because they rely on certain things - set SystemCallArchitectures=native when non-native software is installed - set DefaultEnvironment=LD_TRACE_LOADED_OBJECTS=1 or the such - set DefaultTimeoutStartSec=1 to break any unit that takes longer than 1 second to start but doesn't set an own timeout because it assumes the default timeout is sane - DefaultLimitCPU=1 - ... Also, to go to your apache example: it's not clear that ProtectSystem= just making /usr readonly doesn't break things: I have seen DocumentRoots beneath /usr in the wild (/usr/local/www or the such), with people running dynamic webapps that had to write into that tree. If you then upgrade from a package version that did not include ProtectSystem= (perhaps because it only included a SysV init script) to a package version that does include ProtectSystem=, things will break. I actually agree with your sentiment of having an agreement between upstream developers and the core OS - I just think I would like to interpret the matter a little differently: To me, ProtectSystem= is supposed to be a protection of all the files a) installed on a system (not created by the user) and b) not subject to modification by typical services. (i.e. not a cache / status file / ...) For distros with /usr-move, this falls back to /usr and /boot (and /etc if =full). For other distros, there may be a few additional directories. And on a custom installation, it may include additional directories, such as /opt. If I am an upstream developer and ship a unit file with ProtectSystem=full, my expectations are that normal operation on directories that are supposed to contain data that is not put there at installation (such as /var, /tmp, /home, /srv, /run, ...) remain accessible, but that systemd will provide an extra layer of security around the rest of the installed system. As an upstream developer, I don't know where the distro the user is using decided to install stuff, whether it's in /usr or directly in /bin or wherever. And I don't really care about that and I don't WANT to care about that. If I really only want /usr to be read-only, I could just add ReadOnlyDirectories=/usr to the unit file and be done with it. But I don't want to care about distro details as an upstream developer, I want the setting to just work[tm] and do the right thing[tm]. The fact that it is a generically named option makes me actually expect an abstraction of distro differences. On the other hand, if I put my administrator hat on, as I said in the last mail, I will know what directories may be present additionally that could also fall under that umbrella. And if something breaks because I put in a stupid setting, that's my bad. By all means, put a big fat warning in the docs that this setting is dangerous to fiddle around with. I do see a good bit of orthogonality here: - Upstream developers can clearly expect that /usr-_type_ (!) stuff is protected
[systemd-devel] [PATCH] cryptsetup: Support key-slot option
Debian recently introduced the option key-slot to /etc/crypttab to
specify the LUKS key slot to be used for decrypting the device. On
systems where a keyfile is used and the key is not in the first slot,
this can speed up the boot process quite a bit, since cryptsetup does
not need to try all of the slots sequentially. (Unsuccessfully testing
a key slot typically takes up to about 1 second.)
This patch makes systemd aware of this option.
Debian bug that introduced the feature:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704470
---
man/crypttab.xml| 14 ++
src/cryptsetup/cryptsetup.c | 13 +++--
2 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/man/crypttab.xml b/man/crypttab.xml
index 90d8ce9..5f386e5 100644
--- a/man/crypttab.xml
+++ b/man/crypttab.xml
@@ -164,6 +164,20 @@
/varlistentry
varlistentry
+termvarnamekey-slot=/varname/term
+
+listitemparaSpecifies the key slot to
+compare the passphrase or key against.
+If the key slot does not match the given
+passphrase or key, but another would, the
+setup of the device will fail regardless.
+This implies varnameluks/varname. See
+
citerefentryrefentrytitlecryptsetup/refentrytitlemanvolnum8/manvolnum/citerefentry
+for possible values. The default is to try
+all key slots in sequential
order./para/listitem
+/varlistentry
+
+varlistentry
termvarnameluks/varname/term
listitemparaForce LUKS mode. When this mode
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index 0a15b50..033c0cd 100644
--- a/src/cryptsetup/cryptsetup.c
+++ b/src/cryptsetup/cryptsetup.c
@@ -39,6 +39,7 @@
static const char *opt_type = NULL; /* CRYPT_LUKS1, CRYPT_TCRYPT or
CRYPT_PLAIN */
static char *opt_cipher = NULL;
static unsigned opt_key_size = 0;
+static int opt_key_slot = CRYPT_ANY_SLOT;
static unsigned opt_keyfile_size = 0;
static unsigned opt_keyfile_offset = 0;
static char *opt_hash = NULL;
@@ -87,6 +88,14 @@ static int parse_one_option(const char *option) {
return 0;
}
+} else if (startswith(option, key-slot=)) {
+
+opt_type = CRYPT_LUKS1;
+if (safe_atoi(option+9, opt_key_slot) 0) {
+log_error(key-slot= parse failure, ignoring.);
+return 0;
+}
+
} else if (startswith(option, tcrypt-keyfile=)) {
opt_type = CRYPT_TCRYPT;
@@ -425,7 +434,7 @@ static int attach_luks_or_plain(struct crypt_device *cd,
crypt_get_device_name(cd));
if (key_file) {
-r = crypt_activate_by_keyfile_offset(cd, name, CRYPT_ANY_SLOT,
+r = crypt_activate_by_keyfile_offset(cd, name, opt_key_slot,
key_file,
opt_keyfile_size,
opt_keyfile_offset,
flags);
if (r 0) {
@@ -439,7 +448,7 @@ static int attach_luks_or_plain(struct crypt_device *cd,
if (pass_volume_key)
r = crypt_activate_by_volume_key(cd, name, *p,
opt_key_size, flags);
else
-r = crypt_activate_by_passphrase(cd, name,
CRYPT_ANY_SLOT, *p, strlen(*p), flags);
+r = crypt_activate_by_passphrase(cd, name,
opt_key_slot, *p, strlen(*p), flags);
if (r = 0)
break;
--
1.8.3.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Have timers fire after boot is complete
Hello, one of the most-requested features that is not present in systemd currently is a true rc.local-type functionality that runs after all other services. I haven't read all past discussions, but from what I've gathered the main objection from the systemd developers is that having a catch-all After=* dependency would not be the sane thing to do. That said, the frequency of people requesting this feature indicates that there are valid use cases for this kind of functionality. To give a few examples: - remove /etc/nologin after everything is started (some administrators may want this as a policy, while other's don't) - send an email to the admin btw. computer XYZ just finished rebooting and here are the log entries generated from the boot process - in linux HA you may want to defer the node rejoining the cluster to the point when you know that the server has correctly booted and none of the core services failed in the process I'm sure there are quite a few more. Current solutions are type=idle units (which don't really work for many of the above use cases, since type=idle is essentially type=simple) or setting SysVStartPriority to 99 (as done in Fedora), but that only orders relative to sysv services, not to native services - and in a setup where most if not all services are native, this will not have the desired effect. In order to implement this feature in systemd, I've gone another direction: Instead of having a service for which some ordering constraints are ensured, why not have a timer? There is already OnBootSec=, which is relative to the time when the kernel was activated, so the idea was to have another timer base for this specific purpose. The patch I'm going to send as a reply to this email will implement OnTransactionFinishedSec=. When a timer is started and contains such an entry, it will tell the manager to ping it as soon as the transaction is complete. The manager then proceeds to activate all other units in the transaction and as soon as it reaches manager_check_finished and no jobs are left in the run_queue, and after it closes the idle pipe to trigger the type=idle jobs, it pings the timers again. The timers will then remember the finish time of the current transaction and use that as a base for all OnTransactionFinishedSec= entries. This also has some nice semantics if you want to run something not immediately after boot but e.g. 5 minutes later. If you think, well, boot time is ~30s, I just put in OnBootSec=330s, this will usually give the expected results. However, if for some reason you first boot into rescue.target, then do some stuff for 10 minutes and then run systemctl isolate default.target, the timer will fire immediately while the system is still in the process of booting, which may not be what you want. On the other hand, OnTransactionFinishedSec= will only start counting once you reach the transaction that started the timer, which usually would be the boot transaction (if timer is in default.target) but could also be the isolate transaction in the above scenario. Anyway, I hope I've provided a rationale why this can be a useful feature to have in systemd. The patch will follow in a reply to this mail. Regards, Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Have timers fire after boot is complete
Am 27.09.2012 12:07, schrieb Jóhann B. Guðmundsson: On 09/27/2012 08:33 AM, Christian Seiler wrote: one of the most-requested features that is not present in systemd currently is a true rc.local-type functionality that runs after all other services. Any particular reason why those user just dont create type oneshot unit then order it as they see fit with after and or before? Let's say I have a couple of servers lying around, each with different services installed. Now I want to distribute a single unit file that is always run at the end sending me an email that the system has rebooted and sending me all log messages generated in the boot process so I can see if everything went correctly. Obviously, I can add lots and lots of different units to After= of that service, but as soon as some other service is added to the list, I have to adjust it. Also, the After= dependency isn't really correct here: Such a script doesn't specifically depend on e.g. After=apache.service (it doesn't really care about that) but rather something that should run at a certain time, thus the idea of using a timer for this feature. Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Have timers fire after boot is complete
I haven't read all past discussions, but from what I've gathered the main objection from the systemd developers is that having a catch-all After=* dependency would not be the sane thing to do. Can you just use a Type=idle unit? From man systemd.service: Behavior of idle is very similar to simple, however actual execution of a the service binary is delayed until all jobs are dispatched. This may be used to avoid interleaving of output of shell services with the status output on the console. The problem here is that a Type=idle service is basically a type=simple service and you might want to have Type=forking or Type=oneshot services which you want to start. Also, my patch is more generic - it allows an arbitrary time to pass before actually running the event. My patch basically implements Type=idle for timers. This isn't necessarily guaranteed to be last but I think it would generally be the case... unless I've misunderstood it. Sure, there's no guarantee that it is the last, since all are executed in parallel - just like Type=idle services. Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Have timers fire after boot is complete
If you want to run a script in the very end of everything you simply order it after the default target as in [Unit] Description=My custom script After=default.target [Service] Type=oneshot ExecStart=/path/to/my/custom/script [Install] WantedBy=default.target Hmmm, I remember vaguely that this didn't produce the desired results for some people and that there's a reason why Fedora's rc-local.service only uses the SysVPriority=99 hack and not After=default.target. But perhaps I'm wrong, I'll look into that. Christian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
