[systemd-devel] How to completely clear journal?
Hello, I'm using systemd on a small embedded board. As I have to run journalctl anyway, my plan is to try to use it to collect logs, so I can transmit them to a server once a day. My plan is to do the following settings: Storage=volatile RuntimeMaxUse=2M I only have 64MB and I don't want to waste too much of it for syslog. I also don't want journald to log to the flash memory. Then, once a day, I want to read the current log via "journalctl", pipe it through gzip and then send it to one of my servers. As soon as this succeeded, I don't want to have the logs any longer on the embedded machine. So long story short: How to tell journald to just forget all previously logged stuff? Can I safely delete anything below /run/log/journal? Will this really clear the log (journalctl no longer returns anything after that)? Thank you very much in advance. Greetings, Manuel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Haskell support for socket activation
David Fisher has kindly informed me that high-level socket activation support is now available for Haskell developers! http://hackage.haskell.org/package/socket-activation -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 208
And, of particular importance to some high-density users: unit ordering reworked around a hashmap that scales much better with large numbers of Unix socket and mount units. Initial testing shows daemon-reload times dropping from 8+ seconds to under 2 with thousands of mount+automount unit pairs. Further work on this is still ongoing. Thanks Lennart! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd should not call KDSKBMODE on a VT with X
> This has been in place for a while, commited in February, does this > leave anything open? > > http://cgit.freedesktop.org/systemd/systemd/commit/?id=a25d4d0e3ccf0e9bf0b37e5791275fd6ca5eb4ae Looks good to me. Cheers -Art -- Arthur Taylor a...@ified.ca tayl...@csc.uvic.ca ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [ANNOUNCE] systemd 208
Heya, Mostly clean-ups and fixes, but with David's logind Wayland magic we actually have a major addition, too. http://www.freedesktop.org/software/systemd/systemd-208.tar.xz CHANGES WITH 208: * logind has gained support for facilitating privileged input and drm device access for unprivileged clients. This work is useful to allow Wayland display servers (and similar programs, such as kmscon) to run under the user's ID and access input and drm devices which are normally protected. When this is used (and the kernel is new enough) logind will "mute" IO on the file descriptors passed to Wayland as long as it is in the background and "unmute" it if it returns into the foreground. This allows secure session switching without allowing background sessions to eavesdrop on input and display data. This also introduces session switching support if VT support is turned off in the kernel, and on seats that are not seat0. * A new kernel command line option luks.options= is understood now which allows specifiying LUKS options for usage for LUKS encrypted partitions specified with luks.uuid=. * tmpfiles.d(5) snippets may now use specifier expansion in path names. More specifically %m, %b, %H, %v, are now replaced by the local machine id, boot id, hostname, and kernel version number. * A new tmpfiles.d(5) command "m" has been introduced which may be used to change the owner/group/access mode of a file or directory if it exists, but do nothing if it doesn't. * This release removes high-level support for the MemorySoftLimit= cgroup setting. The underlying kernel cgroup attribute memory.soft_limit= is currently badly designed and likely to be removed from the kernel API in its current form, hence we shouldn't expose it for now. * The memory.use_hierarchy cgroup attribute is now enabled for all cgroups systemd creates in the memory cgroup hierarchy. This option is likely to be come the built-in default in the kernel anyway, and the non-hierarchial mode never made much sense in the intrinsically hierarchial cgroup system. * A new field _SYSTEMD_SLICE= is logged along with all journal messages containing the slice a message was generated from. This is useful to allow easy per-customer filtering of logs among other things. * systemd-journald will no longer adjust the group of journal files it creates to the "systemd-journal" group. Instead we rely on the journal directory to be owned by the "systemd-journal" group, and its setgid bit set, so that the kernel file system layer will automatically enforce that journal files inherit this group assignment. The reason for this change is that we cannot allow NSS look-ups from journald which would be necessary to resolve "systemd-journal" to a numeric GID, because this might create deadlocks if NSS involves synchronous queries to other daemons (such as nscd, or sssd) which in turn are logging clients of journald and might block on it, which would then dead lock. A tmpfiles.d(5) snippet included in systemd will make sure the setgid bit and group are properly set on the journal directory if it exists on every boot. However, we recommend adjusting it manually after upgrades too (or from RPM scriptlets), so that the change is not delayed until next reboot. * Backlight and random seed files in /var/lib/ have moved into the /var/lib/systemd/ directory, in order to centralize all systemd generated files in one directory. * Boot time performance measurements (as displayed by "systemd-analyze" for example) will now read ACPI 5.0 FPDT performance information if that's available to determine how much time BIOS and boot loader initialization required. With a sufficiently new BIOS you hence no longer need to boot with Gummiboot to get access to such information. Contributions from: Andrey Borzenkov, Chen Jie, Colin Walters, Cristian Rodríguez, Dave Reisner, David Herrmann, David Mackey, David Strauss, Eelco Dolstra, Evan Callicoat, Gao feng, Harald Hoyer, Jimmie Tauriainen, Kay Sievers, Lennart Poettering, Lukas Nykryn, Mantas Mikulėnas, Martin Pitt, Michael Scherer, Michał Górny, Mike Gilbert, Patrick McCarty, Sebastian Ott, Tom Gundersen, Zbigniew Jędrzejewski-Szmek -- Berlin, 2013-10-02 Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing
Re: [systemd-devel] [PATCH 2/2] Run with a custom SMACK domain (label).
On Tue, 01.10.13 16:11, Auke Kok (auke-jan.h@intel.com) wrote:
> index 1434dea..d7b8dce 100644
> --- a/src/core/smack-setup.c
> +++ b/src/core/smack-setup.c
> @@ -36,6 +36,7 @@
> #include "macro.h"
> #include "smack-setup.h"
> #include "util.h"
> +#include "fileio.h"
> #include "log.h"
> #include "label.h"
>
> @@ -138,6 +139,12 @@ int smack_setup(void) {
> return 0;
> }
>
> +#ifdef SMACK_RUN_LABEL
> +if (write_string_file("/proc/self/attr/current", SMACK_RUN_LABEL))
> +log_warning("Failed to set SMACK label \"%s\" on self: %s",
> +SMACK_RUN_LABEL, strerror(abs(r)));
> +#endif
Looks got in principle, but error handling is borked. You need to assign
r first before you print it. Also, write_string_file returns negative
errno, so you should just strerror(-r) instead of strerror(abs(r)).
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] Mount /run, /dev/shm usable to tasks when using SMACK.
On Tue, 01.10.13 16:11, Auke Kok (auke-jan.h@intel.com) wrote:
> Once system itself is running in a security domain for SMACK,
> it will fail to start countless tasks due to missing privileges
> for mounted and created directory structures. For /run and shm
> specifically, we grant all tasks access.
Hmm, I am not convinced this patch is really desirable. So far we tried
to make sure that a systemd that is compiled with selinux/smack/ima
support works on kernels that lack it and vice versa. However, if I am
not mistaken this patch will break this, as you set MNT_FATAL for the
mounts but unconditionally add smackfsroot=* to the mount options --
which if I am not mistaken will cause the mount to fail on kernels that
lack SMACK, right?
Something that might work is simply dropping the MNT_FATAL from the
HAVE_SMACK lines. That way, it will be attempted to mount things with
the specified parameters, and if that fails it will be retried
immediately with the following line that lacks the smackfsdef= param?
The mounting code is smart enough to detect if /run is mounted and will
not actually try to mount things twice if something is found to be
mounted there already...
> ---
> src/core/mount-setup.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
> index 4359f59..310afbd 100644
> --- a/src/core/mount-setup.c
> +++ b/src/core/mount-setup.c
> @@ -79,10 +79,18 @@ static const MountPoint mount_table[] = {
>NULL, MNT_NONE },
> { "smackfs","/sys/fs/smackfs", "smackfs",
> "smackfsdef=*", MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_STRICTATIME,
>NULL, MNT_NONE },
> +#ifdef HAVE_SMACK
> +{ "tmpfs", "/dev/shm", "tmpfs",
> "mode=1777,smackfsroot=*", MS_NOSUID|MS_NODEV|MS_STRICTATIME,
> + NULL, MNT_FATAL|MNT_IN_CONTAINER },
> +#endif
> { "tmpfs", "/dev/shm", "tmpfs",
> "mode=1777", MS_NOSUID|MS_NODEV|MS_STRICTATIME,
>NULL, MNT_FATAL|MNT_IN_CONTAINER },
> { "devpts", "/dev/pts", "devpts",
> "mode=620,gid=" STRINGIFY(TTY_GID), MS_NOSUID|MS_NOEXEC,
>NULL, MNT_IN_CONTAINER },
> +#ifdef HAVE_SMACK
> +{ "tmpfs", "/run", "tmpfs",
> "mode=755,smackfsroot=*", MS_NOSUID|MS_NODEV|MS_STRICTATIME,
> + NULL, MNT_FATAL|MNT_IN_CONTAINER },
> +#endif
> { "tmpfs", "/run", "tmpfs",
> "mode=755", MS_NOSUID|MS_NODEV|MS_STRICTATIME,
>NULL, MNT_FATAL|MNT_IN_CONTAINER },
> { "tmpfs", "/sys/fs/cgroup","tmpfs",
> "mode=755", MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_STRICTATIME,
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] Run with a custom SMACK domain (label).
Allows the systemd --system process to change its current
SMACK label to a predefined custom label (usually "system")
at boot time.
This is needed to have a few system-generated folders and
sockets automatically be created with the right SMACK
label. Without that, processes either cannot communicate with
systemd or systemd fails to perform some actions.
---
configure.ac | 6 ++
src/core/smack-setup.c | 7 +++
2 files changed, 13 insertions(+)
diff --git a/configure.ac b/configure.ac
index 4c7fa23..a1695b9 100644
--- a/configure.ac
+++ b/configure.ac
@@ -524,6 +524,12 @@ else
fi
fi
+AC_ARG_WITH(smack-run-label,
+AS_HELP_STRING([--with-smack-run-label=STRING],
+[run systemd --system with a specific SMACK label]),
+[AC_DEFINE_UNQUOTED(SMACK_RUN_LABEL, ["$withval"], [Run with a smack
label])],
+[])
+
if test "x${have_smack}" = xyes ; then
AC_DEFINE(HAVE_SMACK, 1, [Define if SMACK is available])
fi
diff --git a/src/core/smack-setup.c b/src/core/smack-setup.c
index 1434dea..d7b8dce 100644
--- a/src/core/smack-setup.c
+++ b/src/core/smack-setup.c
@@ -36,6 +36,7 @@
#include "macro.h"
#include "smack-setup.h"
#include "util.h"
+#include "fileio.h"
#include "log.h"
#include "label.h"
@@ -138,6 +139,12 @@ int smack_setup(void) {
return 0;
}
+#ifdef SMACK_RUN_LABEL
+if (write_string_file("/proc/self/attr/current", SMACK_RUN_LABEL))
+log_warning("Failed to set SMACK label \"%s\" on self: %s",
+SMACK_RUN_LABEL, strerror(abs(r)));
+#endif
+
r = write_rules("/sys/fs/smackfs/cipso2", CIPSO_CONFIG);
switch(r) {
case -ENOENT:
--
1.8.1.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] Mount /run, /dev/shm usable to tasks when using SMACK.
Once system itself is running in a security domain for SMACK,
it will fail to start countless tasks due to missing privileges
for mounted and created directory structures. For /run and shm
specifically, we grant all tasks access.
---
src/core/mount-setup.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/core/mount-setup.c b/src/core/mount-setup.c
index 4359f59..310afbd 100644
--- a/src/core/mount-setup.c
+++ b/src/core/mount-setup.c
@@ -79,10 +79,18 @@ static const MountPoint mount_table[] = {
NULL, MNT_NONE },
{ "smackfs","/sys/fs/smackfs", "smackfs",
"smackfsdef=*", MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_STRICTATIME,
NULL, MNT_NONE },
+#ifdef HAVE_SMACK
+{ "tmpfs", "/dev/shm", "tmpfs",
"mode=1777,smackfsroot=*", MS_NOSUID|MS_NODEV|MS_STRICTATIME,
+ NULL, MNT_FATAL|MNT_IN_CONTAINER },
+#endif
{ "tmpfs", "/dev/shm", "tmpfs",
"mode=1777", MS_NOSUID|MS_NODEV|MS_STRICTATIME,
NULL, MNT_FATAL|MNT_IN_CONTAINER },
{ "devpts", "/dev/pts", "devpts",
"mode=620,gid=" STRINGIFY(TTY_GID), MS_NOSUID|MS_NOEXEC,
NULL, MNT_IN_CONTAINER },
+#ifdef HAVE_SMACK
+{ "tmpfs", "/run", "tmpfs",
"mode=755,smackfsroot=*", MS_NOSUID|MS_NODEV|MS_STRICTATIME,
+ NULL, MNT_FATAL|MNT_IN_CONTAINER },
+#endif
{ "tmpfs", "/run", "tmpfs", "mode=755",
MS_NOSUID|MS_NODEV|MS_STRICTATIME,
NULL, MNT_FATAL|MNT_IN_CONTAINER },
{ "tmpfs", "/sys/fs/cgroup","tmpfs", "mode=755",
MS_NOSUID|MS_NOEXEC|MS_NODEV|MS_STRICTATIME,
--
1.8.1.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: Journalctl performance
On Tue, Oct 1, 2013 at 6:13 AM, Colin Guthrie wrote: > Ouch 5s for a status is nasty. We regularly see this on our production systems. Yes, it's unfortunate. -- David Strauss | da...@davidstrauss.net | +1 512 577 5827 [mobile] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Small tool to spawn programs in graphical sessions from non-graphical ones
On Sat, Aug 31, 2013 at 2:09 AM, Manuel Amador (Rudd-O) wrote: > Based on systemd's related sibling loginctl, I managed to accomplish the > holy grail of the 90's: get Amarok to play music on my desktop sessiom from > a crontab (motivated by the missus' desire to have an alarm in the home > theater that requires her to walk downstairs, to adapt to her polyphasic > sleep): > > https://github.com/Rudd-O/run-in-gui > > Pull requests to, well, there. Flames to my personal email. I'm sure it's > buggy as fuck since it's been working only for the last half an hour or so, > but we pulled it off together in the space of 2 hours. Not criticizing your approach here, but, I think one could implement systemd --user sessions and timer units to dbus-send "play" messages to amarok. Together with creating a service for amarok that would keep it running, one could do this in 2-3 units. Glad we have achieved your 90's holy grail though :^) Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Small tool to spawn programs in graphical sessions from non-graphical ones
D-BUS. XAUTHORITY. Other session variables (including KIO / GPG password manager / et cetera). You get the use of none of these things in your cron-started programs... unless you use my program. Some programs even flat out refuse to start, actually. Thus, why I wrote my program. On 08/31/2013 05:28 AM, killermoehre wrote: Am 31.08.2013 11:09, schrieb Manuel Amador (Rudd-O): Based on systemd's related sibling loginctl, I managed to accomplish the holy grail of the 90's: get Amarok to play music on my desktop sessiom from a crontab (motivated by the missus' desire to have an alarm in the home theater that requires her to walk downstairs, to adapt to her polyphasic sleep): https://github.com/Rudd-O/run-in-gui Pull requests to, well, there. Flames to my personal email. I'm sure it's buggy as fuck since it's been working only for the last half an hour or so, but we pulled it off together in the space of 2 hours. Enjoy! Doesn't Amarok starts if you prefix it with the right DISPLAY variable? Like »DISPLAY=:0 amarok«. This should work from cron, too. Regards ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] kernel-install: add compat with 'installkernel'
On Tue, Oct 1, 2013 at 5:45 PM, Harald Hoyer wrote: > On 09/26/2013 12:38 AM, Tom Gundersen wrote: >> If 'kernel-install' is called as 'installkernel' it will be compatible with >> the >> syntax used by the kernel's build system. >> >> This means it can be called by doing 'make install' in a kernel build >> directory, if the correct symlink has been installed (which we don't do by >> default yet). >> --- >> src/kernel-install/kernel-install | 12 +--- >> 1 file changed, 9 insertions(+), 3 deletions(-) >> >> diff --git a/src/kernel-install/kernel-install >> b/src/kernel-install/kernel-install >> index fb2ee57..3f112c4 100644 >> --- a/src/kernel-install/kernel-install >> +++ b/src/kernel-install/kernel-install >> @@ -54,9 +54,15 @@ dropindirs_sort() >> >> export LC_COLLATE=C >> >> -COMMAND="$1" >> -KERNEL_VERSION="$2" >> -KERNEL_IMAGE="$3" >> +if [[ `basename $0` == 'installkernel' ]]; then >> +COMMAND='add' >> +KERNEL_VERSION="$1" >> +KERNEL_IMAGE="$2" >> +else >> +COMMAND="$1" >> +KERNEL_VERSION="$2" >> +KERNEL_IMAGE="$3" >> +fi >> >> if [[ -f /etc/machine-id ]]; then >> read MACHINE_ID < /etc/machine-id >> > > committed and modified slightly :) Thanks! -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patches to use -.mount without /etc/fstab
On Tue, 01.10.13 16:09, Karel Zak (k...@redhat.com) wrote: > > Why does it even print that warning? It's annoying and I don't see its > > purpose. Unless you run fsck with the -A option, it doesn't even need > > the fstab file. > > OK, fixed (will be in util-linux v2.24-rc2). Thanks a lot for this fix! With the new GPT auto-discovery stuff the abiity to boot without /etc/fstab is actually really useful, since we really don't need it anymore then. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] kernel-install: add compat with 'installkernel'
On 09/26/2013 12:38 AM, Tom Gundersen wrote: > If 'kernel-install' is called as 'installkernel' it will be compatible with > the > syntax used by the kernel's build system. > > This means it can be called by doing 'make install' in a kernel build > directory, if the correct symlink has been installed (which we don't do by > default yet). > --- > src/kernel-install/kernel-install | 12 +--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/src/kernel-install/kernel-install > b/src/kernel-install/kernel-install > index fb2ee57..3f112c4 100644 > --- a/src/kernel-install/kernel-install > +++ b/src/kernel-install/kernel-install > @@ -54,9 +54,15 @@ dropindirs_sort() > > export LC_COLLATE=C > > -COMMAND="$1" > -KERNEL_VERSION="$2" > -KERNEL_IMAGE="$3" > +if [[ `basename $0` == 'installkernel' ]]; then > +COMMAND='add' > +KERNEL_VERSION="$1" > +KERNEL_IMAGE="$2" > +else > +COMMAND="$1" > +KERNEL_VERSION="$2" > +KERNEL_IMAGE="$3" > +fi > > if [[ -f /etc/machine-id ]]; then > read MACHINE_ID < /etc/machine-id > committed and modified slightly :) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patches to use -.mount without /etc/fstab
Am 24.09.2013 21:53, schrieb Kelly Anderson: > If I'm not mistaken, the intent way back in the early stages of systemd was > to > eliminate /etc/fstab and use .mount files exclusively. Since it was never > fully implemented I took the prerogative to make it work on my systems. > I've been using the setup for quite some time and it works without problem. As Lennart said, it doesn't seem to be a goal. However, you can make a system work without just fine without fstab (I run such a system). > 1. if /etc/fstab is missing, systemd must remount / based on the options > in /etc/systemd/system/-.mount. Why does / need to be remounted? Simply mount / with the correct options from initrd. If you don't need initrd, a simple oneshot service with ExecStart=mount -o remount,rw / should suffice, or, as Lennart said, a reload of the -.mount unit. > 2. If /etc/fstab is missing, systemd must create a valid fstab (in this case > /run/fstab) so that fsck runs properly. fsck prints a warning if fstab is missing. It's annoying, so I created an empty /etc/fstab on my system. 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] Patches to use -.mount without /etc/fstab
On Tue, Oct 01, 2013 at 03:40:00PM +0200, Thomas Bächler wrote: > Am 01.10.2013 15:26, schrieb Karel Zak: > >>> 2. If /etc/fstab is missing, systemd must create a valid fstab (in this > >>> case > >>> /run/fstab) so that fsck runs properly. > >> > >> Not following on this one really... If fsck fails if it doesn't find any > >> fstab, then this is really something to fix in util-linux I am sure. It > > > > I didn't tests it, but according to code fsck prints warning only and > > continue as usually. > > Why does it even print that warning? It's annoying and I don't see its > purpose. Unless you run fsck with the -A option, it doesn't even need > the fstab file. OK, fixed (will be in util-linux v2.24-rc2). Karel -- Karel Zak http://karelzak.blogspot.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patches to use -.mount without /etc/fstab
Am 01.10.2013 15:26, schrieb Karel Zak: >>> 2. If /etc/fstab is missing, systemd must create a valid fstab (in this >>> case >>> /run/fstab) so that fsck runs properly. >> >> Not following on this one really... If fsck fails if it doesn't find any >> fstab, then this is really something to fix in util-linux I am sure. It > > I didn't tests it, but according to code fsck prints warning only and > continue as usually. Why does it even print that warning? It's annoying and I don't see its purpose. Unless you run fsck with the -A option, it doesn't even need the fstab file. I actually got rid of /etc/fstab (for fun) and only recreated an empty one to get rid of the warning. 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] Patches to use -.mount without /etc/fstab
On Tue, Oct 01, 2013 at 04:15:16AM +0200, Lennart Poettering wrote: > On Tue, 24.09.13 13:53, Kelly Anderson (ke...@xilka.com) wrote: > > > Hello, > > > > If I'm not mistaken, the intent way back in the early stages of systemd was > > to > > eliminate /etc/fstab and use .mount files exclusively. Since it was never > > fully implemented I took the prerogative to make it work on my systems. > > I've been using the setup for quite some time and it works without > > problem. > > So, I am not really convinced that we really want to get rid of /etc/fstab... +1 ;-) > > 2. If /etc/fstab is missing, systemd must create a valid fstab (in this > > case > > /run/fstab) so that fsck runs properly. > > Not following on this one really... If fsck fails if it doesn't find any > fstab, then this is really something to fix in util-linux I am sure. It I didn't tests it, but according to code fsck prints warning only and continue as usually. Karel -- Karel Zak http://karelzak.blogspot.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: Journalctl performance
'Twas brillig, and Jan Engelhardt at 01/10/13 12:42 did gyre and gimble: > > On Tuesday 2013-10-01 13:08, Colin Guthrie wrote: >> 'Twas brillig, and Lennart Poettering at 01/10/13 03:03 did gyre and gimble: >>> On Mon, 30.09.13 12:48, Jason St. John (jstj...@purdue.edu) wrote: >>> I've been seeing similar performance issues with the journal for several recent versions of systemd (at least from v204 through v207 on Arch Linux). I have journal logs from 2012-10-20 through today that contain 1,268,128 lines. I just ran "journalctl" with "less" as the pager, pressed "G", and it took 5.5 minutes to get all the way to the bottom. journalctl used lots of CPU throughout and regularly went to 99% CPU utilization. This is on a 3.5 year old laptop with a Core i5 M 430 and a 5,400 RPM hard drive. >>> >>> If this only happens with some journalctl versions, any change you could >>> git bisect this and fiugre out what made journalctl so slow? >> >> >> Well as noted in my original mail, I've been getting similarly bad >> performance between 195 and 207 and thus I'm not convinced this is a >> regression as such. Seems more likely just a general problem that has >> always been present but is only showing up now when sufficient amounts >> of journal log data has been generated. >> >> Perhaps some performance tests are needed to generate synthetic large >> journals? > > The log entries do not need to be hugely diverse or meaningful. I > have, for example, strongswan-ipsec (charon(8)) running which, even > just with a single peer, emits enough messages that you get lots > of real-world journals real fast. > > # ls -Slrt syst* > -rw-r- 1 122454016 Aug 28 09:41 > system@41aff803e2cf449d8a249f38b11d7fb7-0001-0004e4a12c34df3c.journal > -rw-r- 1 120889344 Sep 1 18:45 > system@41aff803e2cf449d8a249f38b11d7fb7-00025bf2-0004e4fd1ec466a4.journal > -rw-r- 1 123904000 Sep 6 23:37 > system@41aff803e2cf449d8a249f38b11d7fb7-0004a761-0004e5552dc059d4.journal > -rw-r- 1 122720256 Sep 11 23:04 > system@41aff803e2cf449d8a249f38b11d7fb7-00071eec-0004e5bdd9651a15.journal > -rw-r- 1 122212352 Sep 16 21:43 > system@41aff803e2cf449d8a249f38b11d7fb7-00098e6f-0004e621f85869be.journal > -rw-r- 1 91037696 Sep 17 12:34 > system@41aff803e2cf449d8a249f38b11d7fb7-000bef28-0004e6856b148e93.journal > -rw-r- 1 91955200 Sep 18 00:56 > system@41aff803e2cf449d8a249f38b11d7fb7-000d7244-0004e691ddc43d8c.journal > -rw-r- 1 91705344 Sep 18 15:23 > system@41aff803e2cf449d8a249f38b11d7fb7-000ef87b-0004e69c3cc69ce8.journal > -rw-r- 1 120033280 Sep 23 06:50 > system@41aff803e2cf449d8a249f38b11d7fb7-001083d7-0004e6a85723b5a8.journal > -rw-r- 1 123625472 Sep 28 07:19 > system@41aff803e2cf449d8a249f38b11d7fb7-0012c56d-0004e705c201cc5a.journal > -rw-r- 1 95404032 Oct 1 13:38 system.journal > > 13:41 ares07:~ # time systemctl status doesnotexist.service > doesnotexist.service > Loaded: error (Reason: No such file or directory) > Active: inactive (dead) > > > real0m5.769s > user0m0.000s > sys 0m0.028s > > The program is disk-bound for me, as running status another time > can/will get satisfied immediately from the file cache. Ouch 5s for a status is nasty. I guess there would be an optimisation whereby the journal data can be skipped for a non-existant service, but that just moves the problem as a status on a real operation would likely take almost as long (tho' if it finds the needed number of logs searching backwards I guess it can escape early from the lookup, so a real world case *should* be somewhat faster generally). Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix timeout when stopping Type=notify service
On 10/01/13 05:08, Lennart Poettering wrote:
> On Fri, 20.09.13 22:53, Olivier Brunel (j...@jjacky.com) wrote:
>
>> Since 41efeaec a call to service_unwatch_main_pid() is done from
>> service_set_main_pid(), which is called upon receiving message MAINPID=
>>
>> This had the side effect of not watching pid anymore, and would result in a
>> useless timeout when stopping the service, as the unit wouldn't be identified
>> from the pid, so not marked stopped which would result in systemd thinking
>> this
>> was a timeout.
>
> I commited a different fix now in
> 7400b9d2e99938d17b281d7df43680eade18666e, but it's untested. Could you
> check if this makes things work?
Yes, fixes the issue.
Thanks,
-j
>
>> ---
>> I'm not exactly familiar with systemd's internals, so this might not be the
>> correct way to fix this, please correct me if it isn't.
>>
>> src/core/service.c | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/src/core/service.c b/src/core/service.c
>> index 246a86e..1dccdff 100644
>> --- a/src/core/service.c
>> +++ b/src/core/service.c
>> @@ -3388,9 +3388,17 @@ static void service_notify_message(Unit *u, pid_t
>> pid, char **tags) {
>> log_warning_unit(u->id,
>> "Failed to parse notification
>> message %s", e);
>> else {
>> +int r;
>> +
>> log_debug_unit(u->id,
>> "%s: got %s", u->id, e);
>> service_set_main_pid(s, pid);
>> +r = unit_watch_pid(u, pid);
>> +if (r < 0)
>> +/* FIXME: we need to do something here */
>> +log_warning_unit(u->id,
>> + "Failed to watch PID %lu
>> from service %s",
>> + (unsigned long) pid,
>> u->id);
>> }
>> }
>>
>
>
> Lennart
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: Journalctl performance
On Tuesday 2013-10-01 13:08, Colin Guthrie wrote: >'Twas brillig, and Lennart Poettering at 01/10/13 03:03 did gyre and gimble: >> On Mon, 30.09.13 12:48, Jason St. John (jstj...@purdue.edu) wrote: >> >>> I've been seeing similar performance issues with the journal for >>> several recent versions of systemd (at least from v204 through v207 on >>> Arch Linux). I have journal logs from 2012-10-20 through today that >>> contain 1,268,128 lines. I just ran "journalctl" with "less" as the >>> pager, pressed "G", and it took 5.5 minutes to get all the way to the >>> bottom. journalctl used lots of CPU throughout and regularly went to >>> 99% CPU utilization. >>> >>> This is on a 3.5 year old laptop with a Core i5 M 430 and a 5,400 RPM >>> hard drive. >> >> If this only happens with some journalctl versions, any change you could >> git bisect this and fiugre out what made journalctl so slow? > > >Well as noted in my original mail, I've been getting similarly bad >performance between 195 and 207 and thus I'm not convinced this is a >regression as such. Seems more likely just a general problem that has >always been present but is only showing up now when sufficient amounts >of journal log data has been generated. > >Perhaps some performance tests are needed to generate synthetic large >journals? The log entries do not need to be hugely diverse or meaningful. I have, for example, strongswan-ipsec (charon(8)) running which, even just with a single peer, emits enough messages that you get lots of real-world journals real fast. # ls -Slrt syst* -rw-r- 1 122454016 Aug 28 09:41 system@41aff803e2cf449d8a249f38b11d7fb7-0001-0004e4a12c34df3c.journal -rw-r- 1 120889344 Sep 1 18:45 system@41aff803e2cf449d8a249f38b11d7fb7-00025bf2-0004e4fd1ec466a4.journal -rw-r- 1 123904000 Sep 6 23:37 system@41aff803e2cf449d8a249f38b11d7fb7-0004a761-0004e5552dc059d4.journal -rw-r- 1 122720256 Sep 11 23:04 system@41aff803e2cf449d8a249f38b11d7fb7-00071eec-0004e5bdd9651a15.journal -rw-r- 1 122212352 Sep 16 21:43 system@41aff803e2cf449d8a249f38b11d7fb7-00098e6f-0004e621f85869be.journal -rw-r- 1 91037696 Sep 17 12:34 system@41aff803e2cf449d8a249f38b11d7fb7-000bef28-0004e6856b148e93.journal -rw-r- 1 91955200 Sep 18 00:56 system@41aff803e2cf449d8a249f38b11d7fb7-000d7244-0004e691ddc43d8c.journal -rw-r- 1 91705344 Sep 18 15:23 system@41aff803e2cf449d8a249f38b11d7fb7-000ef87b-0004e69c3cc69ce8.journal -rw-r- 1 120033280 Sep 23 06:50 system@41aff803e2cf449d8a249f38b11d7fb7-001083d7-0004e6a85723b5a8.journal -rw-r- 1 123625472 Sep 28 07:19 system@41aff803e2cf449d8a249f38b11d7fb7-0012c56d-0004e705c201cc5a.journal -rw-r- 1 95404032 Oct 1 13:38 system.journal 13:41 ares07:~ # time systemctl status doesnotexist.service doesnotexist.service Loaded: error (Reason: No such file or directory) Active: inactive (dead) real0m5.769s user0m0.000s sys 0m0.028s The program is disk-bound for me, as running status another time can/will get satisfied immediately from the file cache. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] units/u...@.service.in
On Tue, 01.10.13 12:08, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > On Mon, Sep 30, 2013 at 07:17:54PM -0700, Lennart Poettering wrote: > > units: Add SHELL environment variable > ... > > diff --git a/units/u...@.service.in b/units/u...@.service.in > > index 3f8b59d..3718a57 100644 > > --- a/units/u...@.service.in > > +++ b/units/u...@.service.in > > @@ -13,6 +13,7 @@ After=systemd-user-sessions.service > > User=%I > > PAMName=systemd-user > > Type=notify > > +Environment=SHELL=%s > > ExecStart=-@rootlibexecdir@/systemd --user > > > > Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/dbus/user_bus_socket > > Slice=user-%i.slice > > Hm, shouldn't we treat $SHELL like $HOME and $USER, and set it "for > the units which have User= set, which includes user systemd instances" > (quoting systemd.exec(5) here)? This would be more consistent. Oh, indeed, that sounds like a good idea! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] fstab-generator: Generate explicit dependencies on systemd-fsck@.service instead of using FsckPassNo
Am 01.10.2013 12:30, schrieb Zbigniew Jędrzejewski-Szmek: >> Now, according to the fstab(5) manpage, the root fs should have passno 1 >> and everything else should have passno 2. We could ensure the same >> behaviour by having After=systemd-root-fsck.service in >> systemd-fsck@.service. > Serializing fscks like that makes only limited sense if you're doing > it from the initrd. But if the fsck is run from the ro root, then yes, > I guess you want to make sure that the fs that holds the fsck binaries > is OK before continuing. That's why systemd-root-fsck.service should be ordered before all systemd-fsck@.service units. This only affects the non-initrd case. In the initrd case, systemd-root-fsck should not be run anyway and the ordering I suggested has no effect. > Manual ordering is a bit of a corner case, but like Jan Engelhart wrote... >> On an iSCSI server, export /dev/sdf1 and /dev/sdf2 as separate LUNs. >> The iSCSI client will import them as /dev/sda and /dev/sdb. That is a >> case where, if you can, you would specify FsckPassNo because the >> automatic detection likely stops at host boundaries. > ...there might be use cases. Even if we drop support for ordering by > fsck-no field in /etc/fstab, do we have a new way of configuring this > through /etc/fstab? (Something like > x-systemd.comment=After=systemd-fsck-var.service ?) > Or is this really too much of an edge case? I don't think that the current > fsck-no-related code is harmful in any way or a maintenance burden, so > if it is dropped, it would be nice to cover all bases. If we are to keep the strict fs_passno as documented in fstab(5), I suggest we go with Lennart's suggestion: > d) Pimp up fstab-generator to write only .d dropins that add the >necessary deps between the fsck instances, but nothing else. I find the whole concept of the FsckPassNo option disturbing (including its documentation). It introduces an additional directive for something that can be solved with the existing ones, with the comment that it should only be used for certain types of services, or not at all. An option that shouldn't be used in newly written units shouldn't be used in generated ones either. 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] Fwd: Journalctl performance
'Twas brillig, and Lennart Poettering at 01/10/13 03:03 did gyre and gimble: > On Mon, 30.09.13 12:48, Jason St. John (jstj...@purdue.edu) wrote: > >> I've been seeing similar performance issues with the journal for >> several recent versions of systemd (at least from v204 through v207 on >> Arch Linux). I have journal logs from 2012-10-20 through today that >> contain 1,268,128 lines. I just ran "journalctl" with "less" as the >> pager, pressed "G", and it took 5.5 minutes to get all the way to the >> bottom. journalctl used lots of CPU throughout and regularly went to >> 99% CPU utilization. >> >> This is on a 3.5 year old laptop with a Core i5 M 430 and a 5,400 RPM >> hard drive. > > If this only happens with some journalctl versions, any change you could > git bisect this and fiugre out what made journalctl so slow? Well as noted in my original mail, I've been getting similarly bad performance between 195 and 207 and thus I'm not convinced this is a regression as such. Seems more likely just a general problem that has always been present but is only showing up now when sufficient amounts of journal log data has been generated. Perhaps some performance tests are needed to generate synthetic large journals? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: When parsing the root= cmdline option, set FsckPassNo to 1
Am 01.10.2013 12:15, schrieb Colin Guthrie: > 'Twas brillig, and Thomas Bächler at 01/10/13 10:18 did gyre and gimble: >> Am 01.10.2013 02:58, schrieb Lennart Poettering: >>> Now, if we have the initrd, then I figure root-fsck.service doesn't make >>> much sense, but there's something missing I think: if we use >>> fsck@.service for the root device, how do we then communicate to the >>> root-fsck.service on the host that the file system has already been >>> checked? How is that supposed to work? >> >> This is how I imagine things should work: >> >> 1) initrd fsck's the device used for /sysroot. >> 2) initrd mounts /sysroot as rw > > Why is it the initrd's job to do the rw mount? It should likely mount as > ro pretty much always no? It's up to the booted system to remount rw if > so desired (i.e. in the fstab). Why should I mount the file system ro only to mount it rw a few milliseconds later? The only reason that was ever done is that file system checks are usually impossible on rw file systems. Since we avoid those anyway with initrd setups, there is no reason left. I can pass the file system with root=, the option with rootflags= and optionally the fs type with rootfstype=. This way, I don't even need to configure my root file system in fstab (and I've started omitting it entirely from my fstabs since the line had no effect anyway). >> 3) initrd fsck's and mounts /usr and friends >> 4) switch-root >> 5) the main system only fsck's and mounts whatever isn't mounted yet. > > This is generally OK, but we have to differentiate between initrd boots > and non-initrd boots too - as Lennart said, root-fsck is only really > sensible if and only if no initrd is used. Yes, I think that's what we should go for: systemd-root-fsck is only for initrd-less systems. > I think everyone agrees that systemd-root-fsck is not needed if you have > an initrd. If that is so, I am happy. > It's only meant for initrd-less boots. Perhaps, the initrd > should just drop a masking symlink in /run/systemd/system for that > service to ensure it's not run? I like that. > Likewise the initrd could do the masking > for the remount service too such that someone booting without an initrd > could still get it? Maybe - I personally mask the service on all my systems (it noticably slowed down a non-SSD boot on an old machine). I don't think it should be needed on a properly configured system with initrd. Even on a non-initrd system, all it should change is the rw/ro flag, the rest can be configured properly right from the start. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] fstab-generator: Generate explicit dependencies on systemd-fsck@.service instead of using FsckPassNo
On Tue, Oct 01, 2013 at 10:57:17AM +0200, Thomas Bächler wrote: > Am 01.10.2013 05:10, schrieb Lennart Poettering: > b) is tempting. Given fsck's improved internal ordering handling, is > there actually a usecase for ordering the fsck's? I can't think of any > off the top of my head... > >>> > >>> I struggle coming up with one. I mean, the only I could think of is "oh > >>> my, it always used to work that way, and it is documented that way, you > >>> break UNIX!", which isn't even a usecase, but just confusion. > > Those were exactly my thoughts. And since systemd never had a problem > with breaking tradition if it was a good idea, I thought we could simply > go ahead. > > Now, according to the fstab(5) manpage, the root fs should have passno 1 > and everything else should have passno 2. We could ensure the same > behaviour by having After=systemd-root-fsck.service in > systemd-fsck@.service. Serializing fscks like that makes only limited sense if you're doing it from the initrd. But if the fsck is run from the ro root, then yes, I guess you want to make sure that the fs that holds the fsck binaries is OK before continuing. I think that since you're defining completly new behaviour, it would be nice to implement this smartly, to avoid constraining parallelization artificially. > If file system checks actually need to be manually ordered in a certain > manner (which I would consider an edge case), systemd provides a much > saner interface than a "pass number", namely Before= and After= ordering > on the fsck services using .d files. I'm not sure if it is saner. It is more verbose and complicated, and most people like to configure their fsck's through /etc/fstab, since it is more convinient than .d directories. Manual ordering is a bit of a corner case, but like Jan Engelhart wrote... > On an iSCSI server, export /dev/sdf1 and /dev/sdf2 as separate LUNs. > The iSCSI client will import them as /dev/sda and /dev/sdb. That is a > case where, if you can, you would specify FsckPassNo because the > automatic detection likely stops at host boundaries. ...there might be use cases. Even if we drop support for ordering by fsck-no field in /etc/fstab, do we have a new way of configuring this through /etc/fstab? (Something like x-systemd.comment=After=systemd-fsck-var.service ?) Or is this really too much of an edge case? I don't think that the current fsck-no-related code is harmful in any way or a maintenance burden, so if it is dropped, it would be nice to cover all bases. > >> Things like that should probably just be automatically determined by > >> the machine, and not requiring a human to invent weird passes to do > >> the job. A boolean sounds fine to me. > > As Kay mentioned, /sbin/fsck is rather powerful these days. +1, as long as we don't break more complicated setups. > > OK, sounds good to me. Anyone wants to cook up a patch that removes > > FsckPassNo= from the core and makes sure the fstab generator only takes > > the "passno" field in fstab as boolean to enable fsck or not? > > My patch 1/3 already treats passno as a boolean - if passno > 0, we > enable fsck, otherwise we don't. (passno < 0 is treated the same as > passno == 0 by the current FsckPassNo code, so I kept that.) > > I can cook up a patch that removes FsckPassNo= - I omitted it here since > I was unsure whether people have it in unit files they wrote manually. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: When parsing the root= cmdline option, set FsckPassNo to 1
'Twas brillig, and Thomas Bächler at 01/10/13 10:18 did gyre and gimble: > Am 01.10.2013 02:58, schrieb Lennart Poettering: >> Now, if we have the initrd, then I figure root-fsck.service doesn't make >> much sense, but there's something missing I think: if we use >> fsck@.service for the root device, how do we then communicate to the >> root-fsck.service on the host that the file system has already been >> checked? How is that supposed to work? > > This is how I imagine things should work: > > 1) initrd fsck's the device used for /sysroot. > 2) initrd mounts /sysroot as rw Why is it the initrd's job to do the rw mount? It should likely mount as ro pretty much always no? It's up to the booted system to remount rw if so desired (i.e. in the fstab). Of course the initrd could check the /sysroot/etc/fstab for this info (it may need to look at this for the /usr mount anyway), but something still makes me think it's up to the system to do the remount rw if needed. I get your point below about not needing remount-fs.service tho', so would be interested in Harald's opinon too :) > 3) initrd fsck's and mounts /usr and friends > 4) switch-root > 5) the main system only fsck's and mounts whatever isn't mounted yet. This is generally OK, but we have to differentiate between initrd boots and non-initrd boots too - as Lennart said, root-fsck is only really sensible if and only if no initrd is used. > This is what we now have as default in new Arch installations (including > / being mounted rw in initrd). What we don't have by default yet is > initrd being handled by systemd. In the systemd case, step 1) was > missing and the root device was never fsck'ed, thus the patch. > > The beauty of this setup is that systemd implicitly does everything > right, there is no need to serialize any fsck state between initrd and > main system. > > In the setup I am aiming for as a default, neither > systemd-root-fsck.service nor systemd-remount-fs.service are needed and > both can go away (in fact, I always mask the latter, since that saves me > a few milliseconds). I think everyone agrees that systemd-root-fsck is not needed if you have an initrd. It's only meant for initrd-less boots. Perhaps, the initrd should just drop a masking symlink in /run/systemd/system for that service to ensure it's not run? Likewise the initrd could do the masking for the remount service too such that someone booting without an initrd could still get it? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] units/u...@.service.in
On Mon, Sep 30, 2013 at 07:17:54PM -0700, Lennart Poettering wrote: > units: Add SHELL environment variable ... > diff --git a/units/u...@.service.in b/units/u...@.service.in > index 3f8b59d..3718a57 100644 > --- a/units/u...@.service.in > +++ b/units/u...@.service.in > @@ -13,6 +13,7 @@ After=systemd-user-sessions.service > User=%I > PAMName=systemd-user > Type=notify > +Environment=SHELL=%s > ExecStart=-@rootlibexecdir@/systemd --user > > Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/dbus/user_bus_socket > Slice=user-%i.slice Hm, shouldn't we treat $SHELL like $HOME and $USER, and set it "for the units which have User= set, which includes user systemd instances" (quoting systemd.exec(5) here)? This would be more consistent. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Renaming network interfaces: device or resource busy
'Twas brillig, and Lennart Poettering at 01/10/13 01:41 did gyre and gimble: > On Mon, 30.09.13 17:42, Thomas Bächler (tho...@archlinux.org) wrote: > >> Any application that listens on netlink for new network interfaces may >> start using the interface before udev has finished processing the uevent. >> >> IMO, this needs to be fixed in the kernel and udev, so that udev can >> have a chance to finish its uevent processing before the interface is >> announced via netlink. As far as I know, no work in that direction has >> been done. > > No, applications should not pick up network devices before udev > announced them. They should ignore netlink traffic before > that. NetworkManager actually gets that right... Yeah this is a slightly interesting case where our "stage1" can bring the network up. This system is pretty old and runs without udev or systemd right now (I do have plans to change it but there are only 24 hours in a day and most of them are already ear-marked!). Stage 1 can bring the network up to allow for a network install via a small (<20Mb) boot.iso. Once stage 1 is over, we download and switch to stage 2 which is when udev is started. I just need to fiddle around a bit to get the right way of taking down the network, starting udev, then bringing it back up again. It's not pretty but I'll figure something out. Long term, I'd rather stage 1 used systemd+udev but that's probably a task for another day. Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: When parsing the root= cmdline option, set FsckPassNo to 1
Am 01.10.2013 02:58, schrieb Lennart Poettering: > Now, if we have the initrd, then I figure root-fsck.service doesn't make > much sense, but there's something missing I think: if we use > fsck@.service for the root device, how do we then communicate to the > root-fsck.service on the host that the file system has already been > checked? How is that supposed to work? This is how I imagine things should work: 1) initrd fsck's the device used for /sysroot. 2) initrd mounts /sysroot as rw 3) initrd fsck's and mounts /usr and friends 4) switch-root 5) the main system only fsck's and mounts whatever isn't mounted yet. This is what we now have as default in new Arch installations (including / being mounted rw in initrd). What we don't have by default yet is initrd being handled by systemd. In the systemd case, step 1) was missing and the root device was never fsck'ed, thus the patch. The beauty of this setup is that systemd implicitly does everything right, there is no need to serialize any fsck state between initrd and main system. In the setup I am aiming for as a default, neither systemd-root-fsck.service nor systemd-remount-fs.service are needed and both can go away (in fact, I always mask the latter, since that saves me a few milliseconds). The only use case I see for both using fsck in initrd and having / mounted read-only during switch-root is a read-only root file system. In that light, I don't think there is anything to fix. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] fstab-generator: Generate explicit dependencies on systemd-fsck@.service instead of using FsckPassNo
Am 01.10.2013 05:10, schrieb Lennart Poettering: b) is tempting. Given fsck's improved internal ordering handling, is there actually a usecase for ordering the fsck's? I can't think of any off the top of my head... >>> >>> I struggle coming up with one. I mean, the only I could think of is "oh >>> my, it always used to work that way, and it is documented that way, you >>> break UNIX!", which isn't even a usecase, but just confusion. Those were exactly my thoughts. And since systemd never had a problem with breaking tradition if it was a good idea, I thought we could simply go ahead. Now, according to the fstab(5) manpage, the root fs should have passno 1 and everything else should have passno 2. We could ensure the same behaviour by having After=systemd-root-fsck.service in systemd-fsck@.service. If file system checks actually need to be manually ordered in a certain manner (which I would consider an edge case), systemd provides a much saner interface than a "pass number", namely Before= and After= ordering on the fsck services using .d files. >> Things like that should probably just be automatically determined by >> the machine, and not requiring a human to invent weird passes to do >> the job. A boolean sounds fine to me. As Kay mentioned, /sbin/fsck is rather powerful these days. > OK, sounds good to me. Anyone wants to cook up a patch that removes > FsckPassNo= from the core and makes sure the fstab generator only takes > the "passno" field in fstab as boolean to enable fsck or not? My patch 1/3 already treats passno as a boolean - if passno > 0, we enable fsck, otherwise we don't. (passno < 0 is treated the same as passno == 0 by the current FsckPassNo code, so I kept that.) I can cook up a patch that removes FsckPassNo= - I omitted it here since I was unsure whether people have it in unit files they wrote manually. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
