Re: [systemd-devel] Offline systemd unit file installer
В Fri, 8 Aug 2014 19:57:12 + Paassen, Hiram van hiram.van.paas...@mastervolt.com пишет: Hey, Is there a off-line variant for systemctl enable/disable? We use buildroot to generate/cross-compile a file-system and make extensive use of systemd. Right now we use installer scripts to create the symlinks needed to enable a unit. This means changes in unit files also need changes in the corresponding install scripts. Is there a tool or something in the systemd source that can parse unit files and install the required symlinks in the appointed directory? Something that can run on the host system? systemctl --root=/path/to/root enable ... What would be the best way to do such a thing if there is no tool? Best regards, Hiram Power Products, LLC Email Notice This message is intended only for the use of the Addressee and may contain information that is PRIVILEGED and/or CONFIDENTIAL. This email is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this email is not an intended recipient, you have received this email in error and any review, dissemination, distribution or copying is strictly prohibited. If you have received this email in error, please notify the sender immediately by return mail and permanently delete the copy you received. Thank you. ___ 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] Mount unit using device symlink
В Mon, 04 Aug 2014 15:43:46 -0400 Patrick Hemmer syst...@stormcloud9.net пишет: I'm trying to mount a device using one of its symlinks, but systemd errors with Timed out waiting for device dev-block-ec2-ephemeral0.device The unit looks like: [Unit] After=ephemeral0-format.service [Mount] What=/dev/block/ec2/ephemeral0 Where=/mnt/ephemeral0 /dev/block/ec2/ephemeral0 is a symlink set up by udev: # udevadm info -q symlink -n /dev/xvdb block/ec2/ephemeral0 disk/by-uuid/d57e2dd9-0062-448c-a914-0b6df045dafb # ls -l /dev/block/ec2/ephemeral0 lrwxrwxrwx 1 root root 10 Aug 4 16:59 /dev/block/ec2/ephemeral0 - ../../xvdb systemd automatically creates a unit for the /sys path, but not the symlink: # systemctl list-units | grep 'xvdb\|ephemeral0' sys-devices-vbd\x2d2064-block-xvdb.device loaded active plugged /sys/devices/vbd-2064/block/xvdb Check with systemctl list-units --all --full. Any ideas how to get this mount unit working with a symlink? -Patrick ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] ldconfig: dont run it if ldconfig is not installed
On Wed, Jul 30, 2014 at 11:02 AM, Umut Tezduyar Lindskog umut.tezdu...@axis.com wrote: --- units/ldconfig.service |1 + 1 file changed, 1 insertion(+) diff --git a/units/ldconfig.service b/units/ldconfig.service index 43c145b..09a2b74 100644 --- a/units/ldconfig.service +++ b/units/ldconfig.service @@ -13,6 +13,7 @@ Conflicts=shutdown.target After=systemd-readahead-collect.service systemd-readahead-replay.service systemd-remount-fs.service Before=sysinit.target shutdown.target systemd-update-done.service ConditionNeedsUpdate=/etc +ConditionFileIsExecutable=/sbin/ldconfig Is it really possible on Linux? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] always check asprintf return code
В Fri, 25 Jul 2014 15:38:31 +0200 Karel Zak k...@redhat.com пишет: There is a small number of the places in sources where we don't check asprintf() return code and assume that after error the function returns NULL pointer via the first argument. That's wrong, after error the content of pointer is undefined. --- src/core/unit-printf.c | 8 +--- src/cryptsetup/cryptsetup.c | 11 --- src/journal/coredump.c | 5 ++--- src/journal/journalctl.c| 16 +++- src/run/run.c | 16 src/shared/install.c| 15 +-- src/systemctl/systemctl.c | 14 -- src/tty-ask-password-agent/tty-ask-password-agent.c | 5 +++-- 8 files changed, 54 insertions(+), 36 deletions(-) diff --git a/src/core/unit-printf.c b/src/core/unit-printf.c index 5bd30f0..8ac2081 100644 --- a/src/core/unit-printf.c +++ b/src/core/unit-printf.c @@ -208,7 +208,9 @@ static int specifier_user_name(char specifier, void *data, void *userdata, char @@ -230,8 +232,8 @@ static int specifier_user_name(char specifier, void *data, void *userdata, char if (specifier == 'u') printed = strdup(username); -else -asprintf(printed, UID_FMT, uid); +else (asprintf(printed, UID_FMT, uid) 0) Missing if? +return -ENOMEM; } if (!printed) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] readahead: use BTRFS_IOC_DEFRAG_RANGE
В Mon, 21 Jul 2014 18:15:37 +0300
Timofey Titovets nefelim...@gmail.com пишет:
Zbyszek, i research problem and i found what in btrfs.h
struct btrfs_ioctl_defrag_range_args not defined
This acceptable if i add it in missing.h like:
/* btrfs_ioctl_defrag_range_args now 21.07.2014
* not defined in btrfs.h and duplicated from kernel/fs/btrfs/ctree.h
*/
#ifdef HAVE_LINUX_BTRFS_H
struct btrfs_ioctl_defrag_range_args {
uint64_t start; /* start byte = 0 */
uint64_t len; /* whole file uint64_t-1 */
uint64_t flags; /* start_io 2 */
uint32_t extent_thresh; /* 0 */
uint32_t compress_type;
uint32_t unused[4];
};
#endif
I think it should really be discussed on btrfs list. It must be
properly exported to user space if user space is going to use it.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2] readahead: use BTRFS_IOC_DEFRAG_RANGE
В Mon, 21 Jul 2014 16:51:22 +0300 Timofey Titovets nefelim...@gmail.com пишет: Zbyszek, thanks for comment, i will work on fixing what you say and resend patch. Just completed TODO: * readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG This is still not an explanation. What is the difference between the two? I can't explain it, because no i add this todo in TODO list (recursively todo%) I could not find any previous discussion on systemd list. TODO was added by Lennart. - - readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG ioctl, with START_IO But as i understand start_io option force write data, without buffering in memory, to the disk. may be it have a sacral sense, i ask for comments in btrfs list for explaration and add explanation to the v3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] core: do not add default dependencies to /usr mount unit
В Tue, 22 Jul 2014 00:39:13 +0200
Jon Severinsson j...@severinsson.net пишет:
This makes no difference if /usr was mounted in the initrd,
and brings the behaviour of legacy systems closer to those
with a propper initrd.
This should be documented in systemd.special(7) then.
But what exact problem does it solve?
---
src/core/mount.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/core/mount.c b/src/core/mount.c
index 102bbef..39a9aaf 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -380,7 +380,8 @@ static int mount_add_default_dependencies(Mount *m) {
if (!p)
return 0;
-if (path_equal(m-where, /))
+if (path_equal(m-where, /) ||
+path_equal(m-where, /usr))
return 0;
if (mount_is_network(p)) {
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] readahead: use BTRFS_IOC_DEFRAG_RANGE
В Sun, 20 Jul 2014 22:27:20 +0300 Timofey Titovets nefelim...@gmail.com пишет: Just completed TODO: * readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG It would be helpful to give explanation why for future reference. +/* TODO: Fix: wan't compile it it struct in ifndef HAVE_LINUX_BTRFS_H */ Could you please check spelling here? I do not understand it, sorry. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] need help implementing a special behaviour
В Tue, 08 Jul 2014 14:37:19 +0200 Steffen Sledz sl...@dresearch-fe.de пишет: On 08.07.2014 14:22, Lennart Poettering wrote: On Tue, 08.07.14 14:11, Steffen Sledz (sl...@dresearch-fe.de) wrote: There is one more open question. We did not found a *clear* definition (e.g. a state diagram) of all the states a unit can have. Yeah, I tried to avoid documenting this in too much detail, since we wanted to have the freedom to still alter the state machine if we need to. e.g. What is the criteria for a service to change from *activating* to *active/started*? That depends on the service Type= you have chosen, and whether you have ExecStartPre= and/or ExecStartPost= commands for your service. Active is entered basically after everything needed to start up a service is executed plus the service has reported back that it is up. Everything needed means ExecStartPre= and ExecStartPost= having been executed. And the reporting back refers to the notification logic you chose with Type=. See systemd.service(5) for more information about that. Hope that makes some sense? Also this manpage is not fully clear. E.g. if we have to *simple* services A and B with an After= between them. What is the criteria that A changes from *activating* to *active* and B can start? If there are ExecStartPost - once they finish execution. If there are not - once program from ExecStart is launched (actually, once it is forked - I do not see how systemd can wait until it is actually execed). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] need help implementing a special behaviour
В Tue, 8 Jul 2014 14:22:01 +0200 Lennart Poettering lenn...@poettering.net пишет: There is one more open question. We did not found a *clear* definition (e.g. a state diagram) of all the states a unit can have. Yeah, I tried to avoid documenting this in too much detail, since we wanted to have the freedom to still alter the state machine if we need to. But it is better to change documentation then than not having any documentation at all. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 215
В Thu, 3 Jul 2014 22:59:57 +0200 Lennart Poettering lenn...@poettering.net пишет: * A new command systemctl is-system-running has been added that allows checking the overall state of the system, for example whether it is fully up and running. Is it more reliable than simply waiting for idle? At which point systemd considers system fully up? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-fsck-root semantics
В Wed, 2 Jul 2014 12:33:01 -0600 Chris Murphy li...@colorremedies.com пишет: On Jul 2, 2014, at 5:39 AM, Daniel Drake dr...@endlessm.com wrote: Hi, I'm trying to understand dracut/systemd fsck behaviour, in the context of an ext4 filesystem root mounted read-only from dracut, remaining read-only even when the system is fully booted (kiosk-style). I see that systemd's fstab-generator rightly creates a mount unit for /sysroot from the initramfs, and causes e2fsck to be run on it from inside the dracut initramfs, before it is mounted. So far so good. It's not wrong, but it seems unnecessary to fsck an ro file system. How is it becoming inconsistent if it's read only? How do you know it was not mounted rw last time? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: do not check btrfs and xfs
В Sat, 28 Jun 2014 19:49:07 +0200
Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет:
fsck.btrfs and fsck.xfs are documented to return immediately, so there is
little sense in running them. Avoids some user confusion and a few lines
in the logs.
https://bugzilla.redhat.com/show_bug.cgi?id=1098799
This sounds far too specific for a generic tool. If I read this bug
report correctly, the primary complain was that systemd tries to
install fsck service even though fstab says skip fsck. This appears to
be the actual bug; I do not see how it can happen as fsck service
should be skipped for passno==0.
---
man/systemd-f...@.service.xml | 15 ---
src/fstab-generator/fstab-generator.c | 23 ++-
2 files changed, 30 insertions(+), 8 deletions(-)
diff --git a/man/systemd-f...@.service.xml b/man/systemd-f...@.service.xml
index ee66f3712d..1e9975f426 100644
--- a/man/systemd-f...@.service.xml
+++ b/man/systemd-f...@.service.xml
@@ -69,14 +69,15 @@
all other file systems and for the root file system in
the initramfs./para
-paraThose services are started at boot if
-optionpassno/option in
+paraThose services are started at boot for the root
+file system or when optionpassno/option in
filename/etc/fstab/filename for the file system is
-set to a value greater than zero. The file system
-check for root is performed before the other file
-systems. Other file systems may be checked in
-parallel, except when they are one the same rotating
-disk./para
+set to a value greater than zero, except for file
+system types like btrfs and xfs which are checked by
+the kernel. The check for root is performed before the
+other file systems. Other file systems may be checked
+in parallel, except when they are one the same
+rotating disk./para
parafilenamesystemd-fsck/filename does not know
any details about specific filesystems, and simply
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index 1256a1ce53..4dad82d425 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -165,6 +165,14 @@ static bool mount_in_initrd(struct mntent *me) {
streq(me-mnt_dir, /usr);
}
+static bool mount_skip_fsck(const char *fstype) {
+static const char table[] =
+btrfs\0
+xfs\0;
+
+return fstype nulstr_contains(table, fstype);
+}
+
static int add_mount(
const char *what,
const char *where,
@@ -377,6 +385,7 @@ static int parse_fstab(bool initrd) {
else {
bool noauto, nofail, automount;
const char *post;
+int check;
noauto = !!hasmntopt(me, noauto);
nofail = !!hasmntopt(me, nofail);
@@ -393,6 +402,13 @@ static int parse_fstab(bool initrd) {
else
post = SPECIAL_LOCAL_FS_TARGET;
+check = me-mnt_passno;
+if (check mount_skip_fsck(me-mnt_type)) {
+log_warning(No need to check %s, type %s.
Ignoring fstab passno.,
+what, me-mnt_type);
+check = 0;
+}
+
k = add_mount(what,
where,
me-mnt_type,
@@ -415,6 +431,7 @@ static int parse_fstab(bool initrd) {
static int add_root_mount(void) {
_cleanup_free_ char *what = NULL;
const char *opts;
+int check;
if (isempty(arg_root_what)) {
log_debug(Could not find a root= entry on the kernel
commandline.);
@@ -436,12 +453,16 @@ static int add_root_mount(void) {
else
opts = arg_root_options;
+check = mount_skip_fsck(arg_root_fstype);
+if (!check)
+log_debug(Skipping fsck for root.);
+
log_debug(Found entry what=%s where=/sysroot type=%s, what,
strna(arg_root_fstype));
return add_mount(what,
/sysroot,
arg_root_fstype,
opts,
- 1,
+ check,
false,
false,
false,
___
systemd-devel mailing list
Re: [systemd-devel] Restart of Target should restart all services that are wanted by that target and have StopWhenUnneeded=true
On Fri, Jun 27, 2014 at 9:56 AM, Michael Seiwald michael.seiw...@ith-icoserve.com wrote: Hi, I have a target unit that acts as a collection unit for several service units. The service units all have a WantedBy directive pointing to the target unit as well as StopWhenUnneeded set to true. When I stop the target the service units stop as well which ist the expected behaviour. When I restart the target the services are unaffected. Is this the wanted behaviour or a bug? Is there a better way to achieve this? Yes, this is expected. You probably want to make service units PartOf target unit. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] no fsck at boot
В Tue, 24 Jun 2014 11:03:06 -0600 Chris Murphy li...@colorremedies.com пишет: On Jun 24, 2014, at 2:12 AM, Colin Guthrie gm...@colin.guthr.ie wrote: Well, the initramfs should mount the rootfs readonly, and then it can read it's /etc/fstab (and the /forcefsck file) and determine if any further action should be taken before doing any kind of pivotroot type stuff to transition to the host OS. This should all be handled by your initramfs really. Not sure what systemd bits do that in a systemd+dracut combo tho', as not fiddled with it for a while! These are selective extractions, but are in order. I see no evidence the initramfs attempts to mount root. The first mount that happens is initiated by systemd. systemd can also be used in initrd^Wamfs. It has the whole set of units specifically for use in initrd. May be it is your case? [1.156856] rawhide.localdomain systemd[1]: Failed to load configuration for systemd-fsck-root.service: No such file or directory [1.158494] rawhide.localdomain systemd[1]: Installed new job sysroot.mount/start as 30 [1.158510] rawhide.localdomain systemd[1]: Installed new job systemd-fsck@dev-disk-by\x2duuid-d372e5d1\x2d386f\x2d460c\x2db036\x2d611469e0155e.service/start as 32 [1.591769] rawhide.localdomain systemd[1]: About to execute: /bin/mount /dev/disk/by-uuid/d372e5d1-386f-460c-b036-611469e0155e /sysroot -t auto -o subvol=root,ro [1.591940] rawhide.localdomain systemd[1]: Forked /bin/mount as 165 [1.592109] rawhide.localdomain systemd[1]: sysroot.mount changed dead - mounting [1.592299] rawhide.localdomain systemd[165]: Executing: /bin/mount /dev/disk/by-uuid/d372e5d1-386f-460c-b036-611469e0155e /sysroot -t auto -o subvol=root,ro If I use rd.break on kernel command line, the fsck job was initiated well before /sysroot was mounted ro. Chris Murphy ___ 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] localization of console
On Thu, Jun 19, 2014 at 1:49 PM, Alexey Shabalin a.shaba...@gmail.com wrote: Oh, sorry. I have not problems with encryption passphrase. I can not see my font after getty@.service, after login. Are you using graphical plymouth (or may be another boot splash screen)? Yes, plymouth. It sounds similar to https://bugzilla.novell.com/show_bug.cgi?id=780516 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] localization of console
В Thu, 19 Jun 2014 02:04:53 +0400 Alexey Shabalin a.shaba...@gmail.com пишет: 2014-06-19 0:06 GMT+04:00 Jason St. John jstj...@purdue.edu: On Wed, Jun 18, 2014 at 12:19 PM, Alexey Shabalin a.shaba...@gmail.com wrote: Hello. I do not understand how the should work localization of console. - systemd-vconsole-setup.service for an early boot (for enter password in cryptsetup? but people do not used non-latin letters for password) - getty@.service contains TTYReset=yes (or https://bugzilla.redhat.com/show_bug.cgi?id=972635 but i use kernel-3.14.6), and all previous font and kbd settings reseted I see package workaround-cyrillic-console in Russian Fedora: https://github.com/RussianFedora/workaround-cyrillic-console contain unit setup-cyrfont@.service: After=getty@%i.service BindsTo=getty@%i.service Requires=getty@%i.service IgnoreOnIsolate=yes [Service] ExecStart=/usr/bin/setfont -C /dev/%i latarcyrheb-sun16 Type=oneshot For ALTLinux i was add systemd-vconsole-setup@.service unit: After=getty@%i.service BindsTo=getty@%i.service Requires=getty@%i.service IgnoreOnIsolate=yes [Service] Type=oneshot ExecStart=/lib/systemd/systemd-vconsole-setup /dev/%i May be exist better way for localization? What Linux distribution are you using? On my Arch Linux systems, I configured the font and keymap (keyboard layout) in /etc/vconsole.conf, and for the initial RAM disk, I put the consolefont and keymap hooks before the encrypt hook in /etc/mkinitcpio.conf. This lets me use an alternate keyboard layout for entering the encryption passphrase. I think something similar to this is what you are looking for, but adapted to whichever Linux distribution you are using. Oh, sorry. I have not problems with encryption passphrase. I can not see my font after getty@.service, after login. Are you using graphical plymouth (or may be another boot splash screen)? I think because TTYReset=yes in getty@.service, and it reset my font settings. My question is how to see my font in console. PS: i am use ALTLinux, but think some problem in fedora too. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd not initializing
On Mon, Jun 16, 2014 at 3:27 PM, Mantas Mikulėnas graw...@gmail.com wrote: On Jun 16, 2014 2:12 PM, Jay D Bhatt jay.bh...@igate.com wrote: Hi Andrey, I also think getty is missing. There was no sbin/getty, it was agetty, so I created soft link to make sbin/getty. Hmm, I thought getty@.service actually invokes agetty directly, no? Secondly, cat /sys/class/tty/console/active was not possible as there was no folders structure inside /sys/. Which likely explains why systemd did not auto-start getty on console. No tty/console stuff, or absolutely empty? An empty /sys might mean that systemd failed to mount sysfs. (I should re-read the earlier logs you posted.) It's again a kernel option, CONFIG_SYSFS if I remember correctly. I wonder how well udev and systemd even work without sysfs. I didn't got your below question I see ssh service - are you able to ssh into it? How do I do ssh into it? Please guide. By using `ssh root@ip-address`, with the IP address of the device. (Of course that only works if the device has networking configured as well, so not always useful...) Other interesting thing I found was systemd rules were not set for ttymxc* . I set the rules for it, since I am using console=ttymxc3. Hmm, I think systemd automatically starts a getty on the console device too, no? Sure, by looking in /sys ... If ttymxc* is common, maybe it would be useful to send a patch for including it along with systemd's default rules... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd not initializing
On Mon, Jun 16, 2014 at 3:12 PM, Jay D Bhatt jay.bh...@igate.com wrote: Hi Andrey, I also think getty is missing. There was no sbin/getty, it was agetty, so I created soft link to make sbin/getty. systemd already calls agetty, it si just that service is named getty@tty.service. Secondly, cat /sys/class/tty/console/active was not possible as there was no folders structure inside /sys/. I didn't got your below question I see ssh service - are you able to ssh into it? How do I do ssh into it? Please guide. Other interesting thing I found was systemd rules were not set for ttymxc* . Not sure which rules do you mean? I set the rules for it, since I am using console=ttymxc3. So, now I am again building new rpm of system and generating image and checking out about hanging problem. Do you have device node /dev/ttymxc3? If yes, you could try to explicitly enable getty service on it ln -s /usr/lib/systemd/system/getty@.service /etc/systemd/system/default.target.wants/getty@ttymxc3.service This /should/ give you login on console. (Yu ay need to create /etc/systemd/system/default.target.wants directory) Hmm ... but if you do not have sysfs, systemd may not notice that device is now available ... at least coldplugging of devices will definitely *not* work, and console driver is built in, so no getty service still. You need to sort out sysfs issue first. What ls -lR /sys shows? If you find anything missing, let me know? Mantas already commented on other parts. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Slow startup of systemd-journal on BTRFS
On Mon, Jun 16, 2014 at 2:14 PM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 16.06.14 10:17, Russell Coker (russ...@coker.com.au) wrote: I am not really following though why this trips up btrfs though. I am not sure I understand why this breaks btrfs COW behaviour. I mean, fallocate() isn't necessarily supposed to write anything really, it's mostly about allocating disk space in advance. I would claim that journald's usage of it is very much within the entire reason why it exists... I don't believe that fallocate() makes any difference to fragmentation on BTRFS. Blocks will be allocated when writes occur so regardless of an fallocate() call the usage pattern in systemd-journald will cause fragmentation. journald's write pattern looks something like this: append something to the end, make sure it is written, then update a few offsets stored at the beginning of the file to point to the newly appended data. This is of course not easy to handle for COW file systems. But then again, it's probably not too different from access patterns of other database or database-like engines... ... which traditionally experienced severe sequential read performance degradation in this case. As I understand this is exactly what happens - readahead attempts to preload files which gives us heavy random read access. The only real remedy was to defragment files. It should work relatively well for journal where files are mostly write once at the expense of additional read/write activity. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 09/11] Avoid conflict between su shell and agetty on the same console
В Fri, 13 Jun 2014 16:41:08 +0200 Werner Fink wer...@suse.de пишет: Otherwise this leads to a poweroff at boot time. I'm not sure what conflict you mean here. Could you provide bug reference? --- units/console-shell.service.m4.in |3 --- 1 file changed, 3 deletions(-) diff --git units/console-shell.service.m4.in units/console-shell.service.m4.in index 3f4904a..295dc8d 100644 --- units/console-shell.service.m4.in +++ units/console-shell.service.m4.in @@ -26,6 +26,3 @@ StandardError=inherit KillMode=process IgnoreSIGPIPE=no SendSIGHUP=yes - -[Install] -WantedBy=getty.target ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 05/11] After emergency service had been started any incoming traffic on syslog.socket
В Fri, 13 Jun 2014 16:41:04 +0200 Werner Fink wer...@suse.de пишет: From: arvidj...@gmail.com will terminate emergency.service due to implicit dependencies on basic.target and therefore sysinit.target which in turn conflict with emergency.target. I always considered it as a stopgap not suitable for upstream. But I still do not know what can be done to fix it. It still looks rather wrong that any arbitrary service can displace the whole run-level. May be we need counterpart for RefuseManualStart so that some targets can only be displaced manually, not as result of implicit dependency. --- units/emergency.service.in |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git units/emergency.service.in units/emergency.service.in index 94c090f..59f7cda 100644 --- units/emergency.service.in +++ units/emergency.service.in @@ -9,7 +9,7 @@ Description=Emergency Shell Documentation=man:sulogin(8) DefaultDependencies=no -Conflicts=shutdown.target +Conflicts=shutdown.target syslog.socket Before=shutdown.target [Service] ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd not initializing
В Fri, 13 Jun 2014 09:18:57 + Jay D Bhatt jay.bh...@igate.com пишет: Sorry, Forgot to send log. I got the previous log by command use `journalctl --boot -1` Please find the log attached. This time the system stopped prior to previous run. This time it stopped at : [ OK ] Started D-Bus System Message Bus. Starting Authorization Manager... What I miss in both your logs is any mention of anything related to getty on any line (serial or whatever). I.e. from normal boot on commodity PC: июн 13 13:21:25 opensuse.site systemd[1]: Starting Getty on tty1... июн 13 13:21:25 opensuse.site systemd[1]: Started Getty on tty1. So your system does not hang - it boots completely, but does not start getty so you cannot login. I see ssh service - are you able to ssh into it? What does cat /sys/class/tty/console/active show on your system? In any case, you can always add service to hardcode getty on console if autodetection fails for you (to enable debugging); do you know how console device is called? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/4] core: fix invalid free() in killall()
В Fri, 13 Jun 2014 18:48:19 +0200
Andreas Henriksson andr...@fatal.se пишет:
static int killall() in ./src/core/killall.c tries to get s
initialized by calling get_process_comm(...) which calls
read_one_line_file(...) which if it fails will mean it is left
uninitialized.
It is then used in argument to strna(s) call where it is
dereferenced(!), in addition to nothing else initializing it before
the scope it is in finishes.
Signed-off-by: Andreas Henriksson andr...@fatal.se
---
src/core/killall.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/killall.c b/src/core/killall.c
index 57ed41c..eab48f7 100644
--- a/src/core/killall.c
+++ b/src/core/killall.c
@@ -168,7 +168,7 @@ static int killall(int sig, Set *pids, bool send_sighup) {
continue;
if (sig == SIGKILL) {
-_cleanup_free_ char *s;
+_cleanup_free_ char *s = NULL;
get_process_comm(pid, s);
Do you mean this may fail to assign value to s? Then it needs more
fixes.
log_notice(Sending SIGKILL to PID PID_FMT (%s).,
pid, strna(s));
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
В Sun, 8 Jun 2014 01:42:18 +0200 Michael Biebl mbi...@gmail.com пишет: 2014-06-08 1:07 GMT+02:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: On Sun, Jun 08, 2014 at 12:55:55AM +0200, Michael Biebl wrote: Could you elaborate why Before=network.target is too late? Because then network setup races with e.g. iptables setup. Depending on the timing, a window in which the network has been set up, but the firewall is not yet in place. If the iptables setup has Before=network.target, why is that not sufficient? Because network.target itself does not do anything at all. You have some other service which does actual job of setting up networking. This other service is ordered before network.target. Ordering something else before network.target will simply run them concurrently. In case of iptables this leaves you with window where interfaces are up but iptables is not yet setup. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
В Fri, 06 Jun 2014 12:53:01 + Rusty Bird rustyb...@openmailbox.org пишет: https://bugs.freedesktop.org/show_bug.cgi?id=79600 --- Makefile.am | 1 + man/systemd.special.xml | 1 + units/network-pre.target | 11 +++ units/network.target | 2 ++ units/systemd-networkd.service.in | 3 ++- 5 files changed, 17 insertions(+), 1 deletion(-) create mode 100644 units/network-pre.target diff --git a/Makefile.am b/Makefile.am index a2a01d0..79adc34 100644 --- a/Makefile.am +++ b/Makefile.am @@ -413,6 +413,7 @@ dist_systemunit_DATA = \ units/remote-fs.target \ units/remote-fs-pre.target \ units/network.target \ + units/network-pre.target \ units/network-online.target \ units/nss-lookup.target \ units/nss-user-lookup.target \ diff --git a/man/systemd.special.xml b/man/systemd.special.xml index 8c2..7515cf8 100644 --- a/man/systemd.special.xml +++ b/man/systemd.special.xml @@ -71,6 +71,7 @@ filenamelocal-fs-pre.target/filename, filenamemulti-user.target/filename, filenamenetwork.target/filename, +filenamenetwork-pre.target/filename, filenamenetwork-online.target/filename, filenamenss-lookup.target/filename, filenamenss-user-lookup.target/filename, That's rather terse documentation :) diff --git a/units/network-pre.target b/units/network-pre.target new file mode 100644 index 000..0c4a0ca --- /dev/null +++ b/units/network-pre.target @@ -0,0 +1,11 @@ +# This file is part of systemd. +# +# systemd is free software; you can redistribute it and/or modify it +# under the terms of the GNU Lesser General Public License as published by +# the Free Software Foundation; either version 2.1 of the License, or +# (at your option) any later version. + +[Unit] +Description=Network (Pre) +Documentation=man:systemd.special(7) +RefuseManualStart=yes diff --git a/units/network.target b/units/network.target index 65fc64b..6966035 100644 --- a/units/network.target +++ b/units/network.target @@ -9,3 +9,5 @@ Description=Network Documentation=man:systemd.special(7) Documentation=http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget +Requires=network-pre.target +After=network-pre.target diff --git a/units/systemd-networkd.service.in b/units/systemd-networkd.service.in index 373ac4e..8e4d213 100644 --- a/units/systemd-networkd.service.in +++ b/units/systemd-networkd.service.in @@ -9,8 +9,9 @@ Description=Network Service Documentation=man:systemd-networkd.service(8) DefaultDependencies=no -After=dbus.service +After=dbus.service network-pre.target Before=network.target +Requires=network-pre.target Wants=network.target ConditionCapability=CAP_NET_ADMIN signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFC] Move handling of sysv initscripts to a generator
В Thu, 29 May 2014 16:11:25 +0200 Thomas H.P. Andersen pho...@gmail.com пишет: What about the SysVStartPriority= option set in native .service's? Is there any non-trivial use case for it? The only usage I have seen was in rc.local emulation and right now none of services installed here defines it. The generator does not know about non-generated units with such a value set so it cannot take them into account when converting start priority to before/after. Should the manager itself try to reorder all units with a sysv priority later? This rather defeats the idea of removing SYSV awareness from systemd core. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFC] Move handling of sysv initscripts to a generator
В Thu, 29 May 2014 16:11:25 +0200 Thomas H.P. Andersen pho...@gmail.com пишет: On Wed, May 28, 2014 at 3:38 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Wed, May 28, 2014 at 01:12:23AM +0200, Thomas H.P. Andersen wrote: From: Thomas Hindoe Paaboel Andersen pho...@gmail.com Reuses logic from service.c and the rc-local generator. Note that this drops reading of chkconfig entirely. How likely is this to cause regressions in existing distributions? It also drops reading runlevels from the LSB headers. The runlevels were only used to check for runlevels outside of the normal 1-5 range and then add special dependencies and settings. Special runlevels were dropped in the past so it seemed to be unused code. Also note that this code behaves differently to the old if an initcsript and native unit exist with the same name. Before the initscript would be ignored but now a .service file is created in /run which will override the native unit. This is a total no-no. This would immediately break existing setups, becuase since forever this has been documented and advertised as a compatibility mechanism. The old code dealing with initscripts are left in for now as the generator will run first and the old code will then ignore the initscripts since unit files exist for them. I will add another patch to rip the old code out later. It would be nice to have this counterpart too, since then it would be easier to tell how much complexity and existing code we are removing. I think that there's general agreement to the idea of moving sysv support to a generator, the question is only if we can do it without significant breakage. I cleaned up the code for yours and Peeters comments. Units generated from initscripts no longer take precedence over native units. Ripping out the old code was harder than I thought though. The Service struct contains a few sysv-specific fields that were filled directly when the initscripts were parsed. Only one of them can be set from a .service file. If we want to keep them all then we need to add options for them in the .service file. IMO all but one are irrelevant with the generator. The relevant one left is is_sysv. It is used to prevent the sysv unit from garbage collection and to refuse socket activation for sysv services. The remaining fields (sysv_has_lsb, sysv_enabled, sysv_start_priority_from_rcnd, sysv_start_priority, sysv_runlevels) are now only used in service_dump and I cannot see any code in systemd making use of the dumped values. Would it be acceptable to just drop the fields only used in service_dump? Is it okay to add a SysV=true/false option to .service? Could it make use of SourcePath to avoid adding special case variable? What about the SysVStartPriority= option set in native .service's? The generator does not know about non-generated units with such a value set so it cannot take them into account when converting start priority to before/after. Should the manager itself try to reorder all units with a sysv priority later? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unable to override systemd-udevd.service
В Thu, 24 Apr 2014 12:07:37 +0200 David Gstir da...@sigma-star.at пишет: [Resend to mailing list, because my client somehow swallowed half the Cc fields - sorry about that.] Hi! I encountered the same issue, running version 195-13.45.1 from opensuse in a container: On 23.04.2014, at 19:26, Andrey Borzenkov (by way of Andrey Borzenkov arvidj...@gmail.com) arvidj...@gmail.com wrote: В Wed, 23 Apr 2014 06:43:04 +0200 Lennart Poettering lenn...@poettering.net пишет: On Sun, 30.03.14 19:23, Andrey Borzenkov (arvidj...@gmail.com) wrote: linux-qbc6:~ # systemctl show systemd-udevd.service -p FragmentPath FragmentPath=/usr/lib/systemd/system/systemd-udevd.service linux-qbc6:~ # cp /usr/lib/systemd/system/systemd-udevd.service /etc/systemd/system linux-qbc6:~ # systemctl daemon-reload linux-qbc6:~ # cp /usr/lib/systemd/system/systemd-udevd.service /etc/systemd/system linux-qbc6:~ # systemctl show systemd-udevd.service -p FragmentPath FragmentPath=/usr/lib/systemd/system/systemd-udevd.service linux-qbc6:~ # exit From non-exhaustive testing it appears to be the only unit showing this property. Enabling systemd debug does not add any useful information (no output about unit discovery). Any way to debug it? The version is systemd-208-19.1.x86_64 from openSUSE. Hmm, that's weird. Is /etc on some weird mount point or so? Not really. Just plain disk in QEMU VM. 17 21 0:5 / /dev rw,relatime shared:2 - devtmpfs devtmpfs rw,size=380164k,nr_inodes=95041,mode=755 18 17 0:15 / /dev/shm rw,relatime shared:3 - tmpfs tmpfs rw 19 21 0:16 / /run rw,nosuid,nodev,relatime shared:6 - tmpfs tmpfs rw,mode=755 20 17 0:11 / /dev/pts rw,relatime shared:4 - devpts devpts rw,gid=5,mode=620,ptmxmode=000 21 1 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 rw,data=ordered ... etc Similar situation here. It might be interesting to run strace -o log -e open -p 1 and then trigger a reload, and then look at the generate log file log. It should show you where systemd is looking for the udev service file, and might contain a hint, why it skips the file in /etc? Actually, it does not :) 1 open(/usr/lib/systemd/system/systemd-udevd.service, O_RDONLY|O_NOCTTY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC) = 17 1 open(/usr/lib/systemd/system/systemd-udevd-kernel.socket, O_RDONLY|O_NOCTTY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC) = 17 1 open(/usr/lib/systemd/system/systemd-udevd-control.socket, O_RDONLY|O_NOCTTY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC) = 17 1 open(/etc/systemd/system/systemd-udevd.service, O_RDONLY|O_NOCTTY|O_LARGEFILE|O_CLOEXEC) = 18 1 openat(AT_FDCWD, /etc/systemd/system/systemd-udevd.service.d, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 1 openat(AT_FDCWD, /run/systemd/system/systemd-udevd.service.d, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 1 openat(AT_FDCWD, /run/systemd/generator/systemd-udevd.service.d, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 1 openat(AT_FDCWD, /usr/local/lib/systemd/system/systemd-udevd.service.d, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 1 openat(AT_FDCWD, /usr/lib/systemd/system/systemd-udevd.service.d, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 1 openat(AT_FDCWD, /lib/systemd/system/systemd-udevd.service.d, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) Systemd does not even try to open the override in /etc here either. However, I noticed an error with /usr/lib/systemd/system/udev.service: snip open(/usr/lib/systemd/system/udev.service, O_RDONLY|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC) = -1 ELOOP (Too many levels of symbolic links) open(/usr/lib/systemd/system/systemd-udevd.service, O_RDONLY|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC) = 15 snip Interestingly, removing /usr/lib/systemd/system/udev.service (which is just a symlink to systemd-udevd.service) makes the override work: snip open(/etc/systemd/system/systemd-udevd.service, O_RDONLY|O_NOCTTY|O_NOFOLLOW|O_CLOEXEC) = 15 snip Could it be that this symlink somehow causes systemd to ignore the override? Andrey, do you have similar behavior with /usr/lib/systemd/system/udev.service? Yes, I have the same link and the same ELOOP behavior ... and yes, removing link makes it work. Looks like systemd bug at the end ... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent timers delay Type=idle units
В Wed, 23 Apr 2014 05:57:39 +0200 Lennart Poettering lenn...@poettering.net пишет: Ah, OK, I think I got it now: You have services that are to be started by timers that take a long time to complete. THe timers have been configured to be persistent. If the system comes up and the timestamp files suggest that the timers need to be triggered immediately this is done, adding the service execution time to the bootup time. This is normally not a problem except when there's some other bootup service that uses Type=idle which will then be affected by these long running services... Did I get this right? Hmm, this sounds nasty. I wodner what we can do about it... Provide boot completed indication? systemd already provides starting and running states. Which logically implies that bootup is finished when starting is replaced by running. Add new timer condition which fires at this point? This will stop misusing Idle for poor man's replacement of proper boot completed event. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Unable to override systemd-udevd.service
В Wed, 23 Apr 2014 06:43:04 +0200 Lennart Poettering lenn...@poettering.net пишет: On Sun, 30.03.14 19:23, Andrey Borzenkov (arvidj...@gmail.com) wrote: linux-qbc6:~ # systemctl show systemd-udevd.service -p FragmentPath FragmentPath=/usr/lib/systemd/system/systemd-udevd.service linux-qbc6:~ # cp /usr/lib/systemd/system/systemd-udevd.service /etc/systemd/system linux-qbc6:~ # systemctl daemon-reload linux-qbc6:~ # cp /usr/lib/systemd/system/systemd-udevd.service /etc/systemd/system linux-qbc6:~ # systemctl show systemd-udevd.service -p FragmentPath FragmentPath=/usr/lib/systemd/system/systemd-udevd.service linux-qbc6:~ # exit From non-exhaustive testing it appears to be the only unit showing this property. Enabling systemd debug does not add any useful information (no output about unit discovery). Any way to debug it? The version is systemd-208-19.1.x86_64 from openSUSE. Hmm, that's weird. Is /etc on some weird mount point or so? Not really. Just plain disk in QEMU VM. 17 21 0:5 / /dev rw,relatime shared:2 - devtmpfs devtmpfs rw,size=380164k,nr_inodes=95041,mode=755 18 17 0:15 / /dev/shm rw,relatime shared:3 - tmpfs tmpfs rw 19 21 0:16 / /run rw,nosuid,nodev,relatime shared:6 - tmpfs tmpfs rw,mode=755 20 17 0:11 / /dev/pts rw,relatime shared:4 - devpts devpts rw,gid=5,mode=620,ptmxmode=000 21 1 8:2 / / rw,relatime shared:1 - ext4 /dev/sda2 rw,data=ordered ... etc It might be interesting to run strace -o log -e open -p 1 and then trigger a reload, and then look at the generate log file log. It should show you where systemd is looking for the udev service file, and might contain a hint, why it skips the file in /etc? Actually, it does not :) 1 open(/usr/lib/systemd/system/systemd-udevd.service, O_RDONLY|O_NOCTTY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC) = 17 1 open(/usr/lib/systemd/system/systemd-udevd-kernel.socket, O_RDONLY|O_NOCTTY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC) = 17 1 open(/usr/lib/systemd/system/systemd-udevd-control.socket, O_RDONLY|O_NOCTTY|O_LARGEFILE|O_NOFOLLOW|O_CLOEXEC) = 17 1 open(/etc/systemd/system/systemd-udevd.service, O_RDONLY|O_NOCTTY|O_LARGEFILE|O_CLOEXEC) = 18 1 openat(AT_FDCWD, /etc/systemd/system/systemd-udevd.service.d, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 1 openat(AT_FDCWD, /run/systemd/system/systemd-udevd.service.d, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 1 openat(AT_FDCWD, /run/systemd/generator/systemd-udevd.service.d, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 1 openat(AT_FDCWD, /usr/local/lib/systemd/system/systemd-udevd.service.d, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 1 openat(AT_FDCWD, /usr/lib/systemd/system/systemd-udevd.service.d, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) 1 openat(AT_FDCWD, /lib/systemd/system/systemd-udevd.service.d, O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) But this is really the only system exhibiting this behavior ... another VM with the same openSUSE version does not. This particular system ignores /etc/systemd/system/systemd-udev.service even after reboot. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Persistent timers delay Type=idle units
В Wed, 23 Apr 2014 20:30:35 +0200 Lennart Poettering lenn...@poettering.net пишет: On Wed, 23.04.14 13:15, Leonid Isaev (lis...@umail.iu.edu) wrote: Hmm, this sounds nasty. I wodner what we can do about it... Maybe we should add a new setting PersistentExtraSec= to timer units or so which allows delaying these kind of timers by an extra margin. Would this work for you? Yes, I think so. Actually, that's what Thomas proposed on arch-general... Hmm, thinking about this: the problem is actually not restricted to persistent timers, any timer that has OnBootSec=10ms or so is also affected by this, should the boot take longer than 10ms... Another option might be to change what Type=idle means: instead of making it wait until the job queue is empty it might be better to simply make it wait until the default job is finished (with other words, until graphical.target is reached). I think it was discussed in the past and it was exact reason Idle was introduced - because default.target is not accurate representation of finished startup sequence. Is it technically possible to track jobs that resulted from dependency closure of default.target? I.e. all units pulled in (directly or indirectly) by default target? This would probably be more accurate approximation of at the end of startup and automatically fix problem discussed here. It would also provide more or less useful startup finished synchronization point. That way it doesn't matter what services are added in by timers... Somehow this appears like the better solution to me. This probably also means changing the manager state machine, and splitting its starting state into two: one state for the time until the default target is not yet reached, and a second state for the time until the job queue is actually empty. I added this to the TODO list now. I'd be happy to take a patch for this though! Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] gummiboot can't be installed on ESP which is soft RAID1 metadata=0.9 partition
В Mon, 14 Apr 2014 18:22:50 +0200 Francis Moreau francis.m...@gmail.com пишет: On 04/14/2014 06:16 PM, Lennart Poettering wrote: On Mon, 14.04.14 18:01, Francis Moreau (francis.m...@gmail.com) wrote: Hello, gummiboot install fails when ESP is MD RAID1 device using metadata 0.9 or 1.0. I don't think using such RAID for ESP would lead to issue. Is there any reason gummiboot doesn't want to be installed on such partition ? The installer will make sure that the ESP is on GPT and carries the right type UUID. We do that for safety reasons, since that's the requirement made by UEFI, and how the bootloader is found. You cannot place the ESP on sw RAID, since the firmware might want to write to the ESP (most won't do that, but could, and the tianocore implemenation you use in qemu certainly does). Does UEFI allow firmware to write to ESP ? Yes, it does. ESP is really not special in this respect. If so that would indeed prevent ESP to be on soft RAID. Thanks ___ 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] fstab-generator: local-fs.target waits for nofail mounts
В Thu, 10 Apr 2014 09:46:56 -0400 Vivek Goyal vgo...@redhat.com пишет: On Thu, Apr 10, 2014 at 06:38:59AM +0400, Andrey Borzenkov wrote: [..] So with nofail opion for rootfs we should have following situation. - sysroot.mount Before=initrd-root-fs.target - initrd-root-fs.target Requires=sysroot.mount OnFailure=emergency.target - initrd.target Wants=initrd-root-fs.target OnFailure=emergency.target - dracut-pre-pivot.service After=initrd.target sysroot.mount Now let us say sysroot.mount failed activation because root device did not show up. We waited for certain time interval, then time out. Now what will happen to initrd-root-fs.target and initrd.target states. Assuming initrd-root-fs.target Requires sysroot.mounts it enters Failed state and systemd effectively executes analog of systemctl start emergency.target. What happens after that is defined entirely by what emergency.target pulls in. initrd.target in your example does not depend on sysroot.mount in any way so unless there are further indirect dependencies it actually should be reached at this point. initrd.target Wants initrd-root-fs.target which inturn depends on sysroot.mount. Wants does not imply any sort of mandatory dependency. Unit A wants unit B means that when systemd gets request to start A it will additionally attempt to start B. Whether it will actually be able to start B is irrelevant. systemd automatically generates a Requires=sysroot.mount in initrd-root-fs.target. So if sysroot.mount fails, that should start emergency.target as initrd-root-fs.target will fail. As initrd.target has Wants=initrd-root-fs.target, and initrd-root-fs.target activation has failed. So does that mean that initrd.target will reach the failed state too and we will try to launch emergency.target. No, unless it has some other mandatory dependency (Requires, BindsTo). As already explained, Wants does not imply any sort of dependency between unit states; it is simply convenient shortcut to start multiple units at once. After start job is submitted, units run independently on each other. What will happen to dracut-pre-pivot.service. It is supposed to run after intird.target has reached. Now initrd.target has failed activation. Will dracut-pre-pivot.service be activated? Yes. Again, After does not imply any mandatory dependency. A After B only says that when two units are started together, A should wait until B startup is complete. If B fails to start, its startup obviously is complete :) so systemd will just continue. One thing I'm not sure about - what are started together actually means. I.e. common sense suggests that systemctl start A B causes them both be started together. But what if I do systemctl start A and later systemctl start B while job for A is still running and B has After=A. Will it wait for A startup to complete? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: local-fs.target waits for nofail mounts
В Wed, 9 Apr 2014 13:49:47 -0400 Vivek Goyal vgo...@redhat.com пишет: On Wed, Apr 09, 2014 at 05:36:13PM +0800, WANG Chao wrote: On 04/08/14 at 06:02pm, Vivek Goyal wrote: On Tue, Apr 08, 2014 at 02:14:33AM +0200, Zbigniew Jędrzejewski-Szmek wrote: [..] Defining a new target which by default waits for all the local fs target sounds interesting. Again, I have the question, what will happen to local-fs-all.target if some device does not show up and say one of the mounts specified in /etc/fstab fails. It result is different for Requires= and for Wants=. Iff there's a chain of Requires= from the failing unit (.device in this case) to the target unit it will fail. Otherwise, it'll just be delayed. If, as I suggested above local-fs-all.target would have Requires= on the .mount units, then your unit could still have Wants=/After=local-fs-all.target, and it'll be started even if some mounts fail. Thanks now I understand the difference between Requires= and Wants= better. What we want is. - Wait for all devices to show up as specified in /etc/fstab. Run fsck on devices. Mount devices to mount points specified. - If everything is successful, things are fine and local-fs-all.target will be reached. - If some device does not show up, or if fsck fails or mount fails, still local-fs-all.target should reach so that kdump module can detect that failure happened and can take alternative action. Alternatively, you can specify a soft depenendency on local-fs-all.target by using Wants=local-fs-all.target. I think this is preferable, because we want local-fs-all.target to be as similar as possible to local-fs.target, which has Requires= on the mount points. With this caveat, this should all be satisfied with my proposal. Agreed. We could define Wants=local-fs-all.target and that would make sure that our unit will be started even if local-fs-all.target fails. You can use OnFailure= to define unit(s) started when local-fs-all.target fails. But it sounds like you are not really interested in *all* filesystems, but in specific fileststems defined in kdump configuration. Kdump scripts registers with dracut as pre-pivot hook. And I believe that in initramfs environments /etc/fstab does not contain all filesystems. It prmarily contains root and any file system specified on dracut command line using --mount option during initramfs generation. So my understanding that given the fact that /etc/fstab is minimal in initramfs, we should be fine waiting for all the fs specified. Given the fact that we run under dracut pre-pivot hook callback, I think dracut-pre-pivot.service wil have to create a dependency to run after local-fs-all.target is reached. Hm, maybe. It would be good to get some input from Harald here. This is pretty specialized, so maybe it'd be better to have a separate unit positioned before or after or parallel to dracut-pre-pivot.service. I am just thinking loud now. Taking a step back and going back to figure out why did we introduce nofail to begin with. If I go through kexec-tools logs, it says nofail was introduced otherwise we never reach initrd.target. I am wondering why that's the case. Current initrd.target seems to have following. [Unit] Description=Initrd Target Requires=basic.target Conflicts=rescue.service rescue.target After=basic.target rescue.service rescue.target AllowIsolate=yes OnFailure=emergency.target OnFailureIsolate=yes ConditionPathExists=/etc/initrd-release dracut doesn't use this initrd.target. It uses the stock one from systemd: [Unit] Description=Initrd Default Target Documentation=man:systemd.special(7) OnFailure=emergency.target OnFailureIsolate=yes ConditionPathExists=/etc/initrd-release Requires=basic.target Wants=initrd-root-fs.target initrd-fs.target initrd-parse-etc.service After=initrd-root-fs.target initrd-fs.target basic.target rescue.service rescue.target AllowIsolate=yes In sysroot.mount context, if we don't use nofail in case of root disk failure, we will never reach initrd-root-fs.target and hence we never reach initrd.target and dracut-pre-povit.service never get a chance to start. Ok, I want to understand what is never reach a target means. So with nofail opion for rootfs we should have following situation. - sysroot.mount Before=initrd-root-fs.target - initrd-root-fs.target Requires=sysroot.mount OnFailure=emergency.target - initrd.target Wants=initrd-root-fs.target OnFailure=emergency.target -
Re: [systemd-devel] [PATCH] fstab-generator: local-fs.target waits for nofail mounts
В Mon, 7 Apr 2014 13:40:17 -0400 Vivek Goyal vgo...@redhat.com пишет: Defining a new target which by default waits for all the local fs target sounds interesting. Again, I have the question, what will happen to local-fs-all.target if some device does not show up and say one of the mounts specified in /etc/fstab fails. What we want is. - Wait for all devices to show up as specified in /etc/fstab. Run fsck on devices. Mount devices to mount points specified. - If everything is successful, things are fine and local-fs-all.target will be reached. - If some device does not show up, or if fsck fails or mount fails, still local-fs-all.target should reach so that kdump module can detect that failure happened and can take alternative action. You can use OnFailure= to define unit(s) started when local-fs-all.target fails. But it sounds like you are not really interested in *all* filesystems, but in specific fileststems defined in kdump configuration. For example, Asssume a user wants to save vmcore to nfs destination. Now for whatever reason, nfs target could not be mounted. In that case kdump will still like to get control and alternatively save dump to local root fs. Without knowing details it sounds like RequiresMountsFor is more appropriate (and can be set by generator based on actual kdump configuration). If systemd just hangs because nfs mounting failed and local-fs-all.target was never reached, then we can't take backup action. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd and After=network.target
On Wed, Apr 2, 2014 at 3:22 PM, Matthew Monaco m...@0x01b.net wrote: On 04/02/2014 03:41 AM, Ivan Shapovalov wrote: Hello all, I've noticed that systemd-networkd.service (ordered Before=network.target) finishes its startup before the connection is established/failed. Because of this, some networking daemons ordered After=network.target (like openvpn) are prone to failures when they attempt to connect at startup. Is this intended, or is this a bug, or have I overlooked some piece of configuration? Thanks, -- Ivan Shapovalov / intelfx / For OpenVPN specifically, I *think* this is a bug (which I've poked at a little). OpenVPN should be able to handle the networking coming and going as it's running, but for some reason it can't resolve the remote address if it wasn't able to at first start, even though it attempts to resolve it at each connection attempt. It could also be glibc issue. glibc caches /etc/resolv.conf, so if it is updated when interface comes up glibc is unaware of it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requiring hardware device and escaping device names
On Tue, Apr 1, 2014 at 6:45 AM, Kai Hendry hen...@webconverger.com wrote: On 31 March 2014 09:54, Kai Hendry hen...@webconverger.com wrote: Not sure what to try next? If I start it manually `sudo systemctl start shkd@-dev-input-event0.service`, it starts working again. Is http://www.freedesktop.org/software/systemd/man/systemd.service.html#TimeoutSec= the right way to proceed? Not sure. RestartSec=5 did the trick! Not sure why systemd gives up trying to restart a process, despite Restart=always http://ix.io/bog Using Bind on device name would be more logical. In this case systemd would stop service when deviced disappeared and restart when it appears again. This avoids permanent restart loop when device is not present. Still don't understand where [hendry@alarmpi ~]$ systemctl status shkd@sys-devices-platform-bcm2708_usb-usb1-1\x2d1-1\x2d1.2-1\x2d1.2.2-1\x2d1.2.2:1.0-input-input1.service shkd@sys-devices-platform-bcm2708_usb-usb1-1x2d1-1x2d1.2-1x2d1.2.2-1x2d1.2.2:1.0-input-input1.service - Simple HotKey Daemon Loaded: loaded (/etc/systemd/system/shkd@.service; disabled) Active: inactive (dead) Comes from. From systemctl status. As soon as unit is mentioned anywhere the stub for it is internally created by systemd (it resolves actual unit on-disk definition lazily). So your own command creates it :) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Unable to override systemd-udevd.service
linux-qbc6:~ # systemctl show systemd-udevd.service -p FragmentPath FragmentPath=/usr/lib/systemd/system/systemd-udevd.service linux-qbc6:~ # cp /usr/lib/systemd/system/systemd-udevd.service /etc/systemd/system linux-qbc6:~ # systemctl daemon-reload linux-qbc6:~ # cp /usr/lib/systemd/system/systemd-udevd.service /etc/systemd/system linux-qbc6:~ # systemctl show systemd-udevd.service -p FragmentPath FragmentPath=/usr/lib/systemd/system/systemd-udevd.service linux-qbc6:~ # exit From non-exhaustive testing it appears to be the only unit showing this property. Enabling systemd debug does not add any useful information (no output about unit discovery). Any way to debug it? The version is systemd-208-19.1.x86_64 from openSUSE. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Requiring hardware device and escaping device names
В Sun, 30 Mar 2014 23:48:11 +0800
Kai Hendry hen...@webconverger.com пишет:
On 26 March 2014 22:55, Jóhann B. Guðmundsson johan...@gmail.com wrote:
SUBSYSTEM==input, ENV{ID_INPUT_KEYBOARD}==?*, ENV{.INPUT_CLASS}=kbd,
TAG+=systemd, ENV{SYSTEMD_WANTS}+=shkd@%p.service
...
Trying to teach myself how to fish here. How did you know it would
match this particular device?
$ udevadm monitor
udevadm monitor --env would be more useful, it also shows device
attributes after event is processed.
...
Anyway, it doesn't seem to work.
[hendry@alarmpi ~]$ systemctl | grep shk
shkd@-devices-platform-bcm2708_usb-usb1-1-1-1-1.2-1-1.2.2-1-1.2.2:1.0-input-input0-event0.service
loaded failed failed Simple
HotKey Daemon
That's right. You really want %N ($devnode), not %p in the rule. %p
refers to path in /sys, while your daemon apparently needs real device
path in /dev.
To filter those paths that generate device nodes you could check for
DEVNAME or NAME not being empty. If you need more specific match, you
need to check attributes for your device.
SUBSYSTEM==input, ENV{ID_INPUT_KEYBOARD}==?*, ENV{DEVNAME}==?*, \
TAG+=systemd, ENV{SYSTEMD_WANTS}+=shkd@%N.service
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] writing a systemd unit for nbd devices
On Fri, Mar 21, 2014 at 4:05 PM, Wouter Verhelst wou...@debian.org wrote: First, let me explain how NBD works. The client side of the NBD protocol is implemented partially in user space, and partially in kernel space. The user space part handles connecting and the initial protocol negotiation; but once that has been done, nbd-client calls the NBD_DO_IT ioctl() on an open /dev/nbdX file, which hands the socket file descriptor to the kernel and which does not return until the device is disconnected (with nbd-client -d, or because the link to the server died). As such, the nbd-client process needs to continue running while the device is connected. In addition, nbd-client needs to fork() and open() the /dev/nbdX device to support partitioned NBD devices (due to a deadlock issue, that can't be done from the initial NBD_DO_IT ioctl handling, so it is done in the first open() instead). But the parent nbd-client remains around, right? For supporting root-on-NBD in conjunction with systemd, I've already added a -systemd-mark option to nbd-client so it will make argv[0][0] read as '@' (I think that method is slightly ugly, but that's a discussion for another time). In Debian, I've already supported root-on-NBD for quite a while with an initramfs script and some code in the init script of nbd-client which adds the PID for the root NBD device to the list of PIDs that shouldn't be killed; I understand that dracut (and hence Fedora as well) have similar support (though I'm not sure how well it all works). For non-root NBD devices, however, the situation would be slightly more complex. This is supported in Debian by the package's init script; AFAIK, though, no other distribution has support for that in its init scripts (or upstart/systemd configuration, yada yada). Currently, in Debian, the situation is that there is a configuration file, /etc/nbd-client, which is sourced in the init script, and which contains bash arrays with configuration. The init script then loops over those bash arrays and runs the appropriate nbd-client command to connect the device. Any actual mounting (etc) of the device, then, is left to other init scripts. It expects that filesystems on NBD devices have the _netdev option in its fstab entry listed, so that it will be mounted by the mountnfs rather than mountall init script. As can be expected, this took several iterations to get right in all corner cases. It seems to be working fine now, however. When converting this to systemd unit files, from skimming over the documentation, I guess I'll need something along the lines of the following: - I will need to create dev-nbd@.device unit files. These unit files would connect the device when needed. How do you determine when it is needed? From your description I'd suggest as first step generator that mostly does the same as already done by iitscript - create generator that reads /etc/nbd-client and creates service (not device) file for every NBD device. It could be a link to common template, or separate unit - it does not really matter. - this service will simply start nbd-client as you describe above. Those services will be of Type=simple; and they probably should be After=network.target and definitely Before=remote-fs-pre.target for _netdev to work. - It may be a good idea to move the configuration from a sourced shell script snipped to something else. I do want to retain some backwards compatibility, but it's okay if that's just a program interpreting the shell script snippet and outputting something more modern. Generator allows you to retain existing configuration. And at the very beginning generator can be just a shell script (especially if it does not need to do more than just ln -s). But I suspect you will need at least pass information about NBD server and I presume it may be different for each device, right? I do foresee some problems, though, and I'd like to see if these are indeed problems or whether I just need to read more documentation. I haven't found an easy answer in the documentation that I've read, but then maybe I haven't been looking very well. NBD device nodes are a bit special in that due to the way NBD devices are connected, the device must exist at all times, even before it is connected; I suspect (though have not actually tried) that systemd will only try to start a .device unit file if the device node itself is not there yet. For NBD, the difference between a connected device and a not-connected one can be spotted in the apparent size of the block device (the BLKGETSIZE64 ioctl will return 0 for a not-connected device) and in the presence (or lack thereof) of a file /sys/block/nbdX/pid (if it exists, it contains the PID of the nbd-client process handling the connection; if it does not, the device is not connected), not by the presence (or lack thereof) of the device node itself. This is not the case for partitions of NBD devices,
Re: [systemd-devel] [PATCH] timedated: add --timezone option to set the default timezone
В Wed, 19 Mar 2014 19:55:35 +0100 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет: On Thu, Mar 20, 2014 at 12:39:12AM +0900, juho son wrote: Hi, I omitted explain about. /etc have many system's configuration files. localtime is one of them. Normally /etc is on readable and writable location. So you've made the directory for configuration read-only, but you want to change the configuration, so you're creating a second configuration directory to store the new values there. This doesn't make sense to me, and is not going to work unless glibc is also modifed, since any program will try to read that file. My company offers solution based on tailored shared SLES image which is mostly read-only with some links into small write-only area. This worked fine for the past 10+ years. So it is something that is used in real world. And yes, /etc/localtime is a link as well. (Not to mention the fact that /opt has a rather different purpose, but let's say that this is a secondary issue). We are using /var (which is read-write and private for each host using image), but that does not really matter. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Passing variables from udev to unit
В Fri, 14 Mar 2014 08:53:45 +1000
Peter Hutterer peter.hutte...@who-t.net пишет:
Hey,
I have a service file wacom-inputattach@.service that is started from a udev
rule:
SUBSYSTEM==tty|pnp, KERNEL==ttyS[0-9]*, ATTRS{id}==WACf*,
TAG+=systemd, ENV{SYSTEMD_WANTS}+=wacom-inputattach@%k.service
and the service file then runs:
ExecStart=/usr/bin/inputattach -w8001 /dev/%I
That works fine, but now I need to pass a second parameter into the service
file. Ideally I want to run something like:
ExecStart=/usr/bin/inputattach --baud $BAUD -w8001 /dev/%I
I can set the baud rate based on ATTRS{id} in the udev rule, I just don't
know if there is a way to pass this to the service file. Is there a way to
do this or do I need to write a wrapper?
One possibility would be to generate
/run/systemd/system/wacom-inputattach@%k.service.d/baud.conf that
contains
[Service]
BAUD=9600
But this requires systemd reload and may generate burst of reload
requests if there are multiple devices. May be wrapper is simpler.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Help regarding service dependency
В Thu, 13 Mar 2014 21:25:34 -0400 (EDT) Amit Saha as...@redhat.com пишет: Hello, We have service1 which starts in default.target, and we want it to start After service2 (systemd-readahead-done) which starts after the default.target is reached. So, I think what would happen in this case is the After=service2 for service1 is ignored and it is started before service2 since the default.target must be reached. There is no ordering dependencies between default.target and individual units; default.target is simply a way to define what is started using Wants. So it should work. For more specific info, here is a snippet of the .timer file for service2: [Unit] Description=Stop Read-Ahead Data Collection 10s After Completed Startup Documentation=man:systemd-readahead-replay.service(8) DefaultDependencies=no Conflicts=shutdown.target After=default.target Before=shutdown.target ConditionVirtualization=no [Timer] OnActiveSec=30s A colleague suggested creating a new target for service1 which the system boots into and has a After=default.target, systemd-readahead-done.service. You seem to assume default.target is magic - it is not. If you boot into another target, it becomes default target in this case. Even if not exactly how I mention, this idea holds promise. Also, is there any other suggested solution involving fiddling with the unit dependencies but not the system boot target? No fiddling is required. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: improve wording of systemctl's --after/--before
В Wed, 12 Mar 2014 23:07:32 -0400 Jason St. John jstj...@purdue.edu пишет: Commit 4a77ca7 was an attempt at fixing the wording of --after and --before, but the new wording was unclear. Split the combined --after/--before section into a separate section for each, explicitly state what each option does, and add information about how these lists are generated. Reported-by: Andrey Borzenkov arvidj...@gmail.com Reported-by: Lennart Poettering lenn...@poettering.net --- Patch that resulted in commit 4a77ca7 was posted here: http://lists.freedesktop.org/archives/systemd-devel/2014-February/017277.html Lennart's response: http://lists.freedesktop.org/archives/systemd-devel/2014-March/017778.html I put a Reported-by line for Andrey because he was the one that originally brought this to the ML's attention, and I added one for Lennart because his note about the whole section needing rewording is what directed my attention to this. If Reported-by lines are not to be used, feel free to strip them when applying. man/systemctl.xml | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/man/systemctl.xml b/man/systemctl.xml index ee6ab8f..a24b7c1 100644 --- a/man/systemctl.xml +++ b/man/systemctl.xml @@ -145,12 +145,23 @@ along with systemd; If not, see http://www.gnu.org/licenses/. varlistentry termoption--after/option/term + +listitem + paraWith commandlist-dependencies/command, show the + units that are ordered before the specified unit. In other Hmm ... so now it is absolutely unclear why it is called after in the first place. Because it describes what happens before? :) May be, something like In other words, specified unit is ordered after all of listed units. + words, list the units that are in the varnameAfter=/varname + directive of the specified unit./para No, the second sentence is wrong. Other unit may have Before=specified unit or it may be implicit dependencies. +/listitem + /varlistentry + + varlistentry termoption--before/option/term listitem - paraShow after (before) which units the specified unit is started - with commandlist-dependencies/command. - /para + paraWith commandlist-dependencies/command, show the + units that are ordered after the specified unit. In other + words, list the units that are in the varnameBefore=/varname + directive of the specified unit./para /listitem /varlistentry Ditto. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] Discoverable Partitions Spec
В Fri, 7 Mar 2014 20:37:12 +0100 Lennart Poettering lenn...@poettering.net пишет: On Fri, 07.03.14 20:47, Mantas Mikulėnas (graw...@gmail.com) wrote: On Fri, Mar 7, 2014 at 8:26 PM, Lennart Poettering lenn...@poettering.net wrote: Heya! Since yesterday systemd in git can now discover root, /home, /srv and swap partitions automatically based on GPT type GUIDs, thus making /etc/fstab unnecessary for simple setups. I have now put together something like a spec describing the logic behind that, and what it is good for: http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/ It would be good if in the long run OS installers could adopt this and use the right partition type GUIDs automatically, to make this discovery work. For now however, you need to manually change the GPT type GUIDs of your installation if you want to make use of this scheme. That might not work very well if one tried to dual-boot two systemd distros… Hmm? there are all kinds of provisions in the spec to make sure this works correctly. For example, we won't do this all for /usr and /var and /etc since we cannot allow incorrect mixing and matching between parallel installations. However, for /home and /srv that is much less of a problem, and sharing should be *good* in that case. And for the root disk we declare explicitly that installers may only drop the root= param from the kernel cmdline if the OS is installed as first root partition on the disk. Otherwise it *must* specify it to make sure the right partition is found at boot. Putting this altogether this should work fine for multi-boot cases. That said, the benefit of not requiring an /etc/fstab is primarily one for simpler appliance style disk images where only one OS is installed, not for the super generic full distro cases that want to support every possible storage setup. For example, I wouldn't expect anaconda to ever drop the root= param from the kernel cmdline of its installations. I mean, given that anaconda wants to support booting LVM on LUKS on RAID and iscsi on bonded vlans and whatever else, there's no auto-discovery like this possible anyway, and hence they can just keep the root= in there for everybody... So what is the benefit of creating specification and tools that nobody will use? If distributions will have to support explicit filesystem configuration anyway, what is the benefit for them to add *additional* support for automatic configuration? Especially if this automatic configuration is incomplete and has to be augmented with explicit configuration anyway. FAQ #1 talks about /usr and /etc, but /etc is almost always in the root partition, isn't it? Well, sure it is, and so is /var... But it certainly makes sense to have a seperate /etc in some cases. For example, in virtualized environments it might make sense to share a single fixed read-only /usr between a large number of containers that each have a private /etc and /var. I mean, this is the FAQ section, I am not saying whether splitting these things makes sense or no sense at all, I am just saying that auto-discovery makes no sense for these cases... Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] systemctl: fix description of --after/--before
It was backward - --after fetches After property, so units shown really come *before* unit given as argument. Same for --before. --- man/systemctl.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/man/systemctl.xml b/man/systemctl.xml index 355cd11..fef9578 100644 --- a/man/systemctl.xml +++ b/man/systemctl.xml @@ -148,8 +148,8 @@ along with systemd; If not, see http://www.gnu.org/licenses/. termoption--before/option/term listitem - paraShow which units are started after or before - with commandlist-dependencies/command, respectively. + paraShow after (before) which units the specified unit is started + with commandlist-dependencies/command. /para /listitem /varlistentry -- tg: (74fae42..) u/systemctl-list-deps-man (depends on: master) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /run needs to be mounted? ugh.
В Tue, 11 Feb 2014 17:20:15 +0100 Jason A. Donenfeld ja...@zx2c4.com пишет: On Tue, Feb 11, 2014 at 5:15 PM, Dave Reisner d...@falconindy.com wrote: I don't think there's any change needed here. The interface states: The initrd should mount /run as a tmpfs. And sure enough, this isn't a requirement, but there's many valid reasons to do this. Ahh, okay. I suppose what I'm wondering is what the advantages are to mounting /run (if the remaining interfaces in the list aren't used)? It looks like mounting /run occurs pretty soon in core/main.c. Could it be that the only advantages of mounting /run early on are for using the more advanced systemd initrd interfaces, such as giving control back during shutdown? Or are there benefits in doing this even for the most minimal of initrd? /run is used to pass state between initrd and system for such components as udev or mdadm. I do not know how your initramfs implementation works and whether it is using udev, but if you support root on MD, you likely will need /run. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] /run needs to be mounted? ugh.
В Tue, 11 Feb 2014 17:25:29 +0100 Lennart Poettering lenn...@poettering.net пишет: An initrd without /run is mostly pointless, no? Either you have storage daemons and hence need /run around, or you don't have storage daemons, in which case you can just boot without involving any initrd? You still need something to resolve LABEL, UUID, /dev/disk/by-* or any other fancy root names. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to prevent sleep during running oneshot units
В Wed, 12 Feb 2014 02:12:15 +0100 Kai Krakow hurikha...@gmail.com пишет: See systemd-inhibit(1). Yeah, I've read that of course. Maybe I didn't get the complete picture but from the man page it's supposed to work by running systemd-inhibit on the command line. This in turn means, I'd need to place ExecStartPre and ExecPostStop hooks in the unit file. No, you need to wrap your command with it. I.e. instead of ExecStart=/path/to/backup-command ... you use ExecStart=/usr/bin/systemd-inhibit /path/to/backup-command ... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] pager: remove --no-init setting from LESS options
On Tue, Feb 11, 2014 at 9:15 AM, Mantas Mikulėnas graw...@gmail.com wrote: On Feb 11, 2014 7:02 AM, Jason A. Donenfeld ja...@zx2c4.com wrote: I use konsole. It has a nice feature that when the scrollbars have been disabled -- like in the case of a full-console app like vim or less -- it makes the mouse wheel send up and down key strokes, so that scrolling happens. It's really nice. I open up less, and then I can scroll through it using the mouse wheel. This doesn't work with systemd's pager, however, because systemd passes --no-init to less. This patch removes this X flag. On the one hand, scrolling like that is convenient, in gnome-terminal as well – on the other hand, removing -X causes `less` open the alt screen mode even for really short outputs, which can become annoying quickly… Should not it simply respect existing LESS value? Or, for that matter, SYSTEMD_LESS if someone thinks of a good reason to have different settings? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Use normal English elide in place of ellipsize
В Tue, 4 Feb 2014 15:31:58 + Barry Scott barry.sc...@onelan.co.uk пишет: Change the messages output and also all internal function names and variables to match. As a non-native English speaker I must admit ellipsize was more understandable. I am not sure I would understand elide if it was not used in this context. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Allow stop jobs to be killed during shutdown
В Wed, 5 Feb 2014 00:10:51 +0100 Lennart Poettering lenn...@poettering.net пишет: On Wed, 29.01.14 19:29, Andrey Borzenkov (arvidj...@gmail.com) wrote: Thanks for tracking this done, this really sounds like you nailed the problem. Now, how to fix it? Hmm, so, I would claim this is a shortcoming of KillMode=control-group, which is the default for everything. There has been an item on the TODO list to maybe introduce a KillMode=mixed setting, which would send SIGTERM only to the main process, and the SIGKILL later on to all processes. I am pretty sure that this would solve the issue at hand quite nicely here, because the systemd user instance would get a nice chance to clean up its own act, before the systemd system instance would make tabula rasa... I still favor alternative approach - let systemd wait for main PID to exit after ExecStop instead. This is functionally equivalent to the above with slight advantages I am really not convinced that ExecStop= should be allowed to be asynchronous. (Which is what you suggest we do, right?) Yes. In fact, it's already problem enough that we pretend we allow ExecReload= to be asynchronous like that... It's a question of allowing bad code through... I do not suggest send it a singnal and pray for it. You send a signal (or whatever) and wait for MAINPID to exit. MAINPID is *the* service for systemd. Service exists while it runs; service is stopped when it exits. I do not understand what is bad about it, sorry. Either people let us shutdown a service, or they do it themselves, but allowing a crappy (asynchronous) shutdown routine sounds wrong to me... It is synchronous for systemd - it waits until MAINPID exits. Not every service has natural synchronous stop implementation - actually, I suspect that most of them do not and simply use busy loop waiting for the same MAINPID. But we already have PID 1 whose job is to wait for other processes to exist and it does its job rather well. Why not rely on it? At the hackfest in BRU I have now implemented KillMode=mixed, which should fixed the issue mostly... Could you test, please? Sure it works, but it does exactly the same - it implements asynchronous service stop without having benefits of reaping leftover processes early. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] reboot splash screen
В Fri, 31 Jan 2014 18:11:10 -0500 Cliff Brake cliff.br...@gmail.com пишет: Hi, I'm trying to get systemd to display a splash screen on powerdown. I've tried using something similar to these recipes: http://cgit.freedesktop.org/plymouth/tree/systemd-units But, for some reason my service is not being activated (included below): root@q7imx6:~# more /lib/systemd/system/reboot-splash.service [Unit] Description=Test unit Before=systemd-reboot.service DefaultDependencies=no [Service] Environment=DISPLAY=:0 ExecStart=/usr/bin/lcd-test-qt /usr/share/pixmaps/poweroff-splash.png If your program need X, it is very unlikely to work as a service. Did you test if manually starting it does anything? KillMode=none SendSIGKILL=no [Install] WantedBy=reboot.target (I've been testing with reboot command). Did you enable it? [Install] section only tells which links should be created by systemctl enable, it does not cause unit to be pulled in. Additionally, shutdown seems to be hanging at: [ OK ] Reached target Shutdown. Running systemd v206 Does systemd-reboot.service run at the start of a reboot? No, it runs at the very end of reboot sequence. Appreciate any ideas on the best way to do this. The goal is to get the splash screen to display as quickly as possible after reboot command is issued. This is counterpart of how do I start service after everything else is started on bootup. As it stands now, there is no easy way to do it (and plymouth splash screen appears also far too late during reboot). To make splash screen appear before anything else on shutdown you literally need something that is ordered after everything else on startup. This probably involves new special unit boot-final.target which is ordered After every other unit. This gives defined point in time where both late boot and early shutdown services can run. I may end up patching systemd to simply start the splash program if I can't figure out how to make it happen in a service. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Allow stop jobs to be killed during shutdown
В Mon, 27 Jan 2014 15:48:50 +0100
Lennart Poettering lenn...@poettering.net пишет:
On Sun, 26.01.14 12:09, Andrey Borzenkov (arvidj...@gmail.com) wrote:
Any advices on how to do that?
I have both the issue (reproducible on each shutdown) and will to debug.
Well, enable the debug shell, and then from there try to figure out why
things are stuck. i.e. whether it is systemd --user that really never
exits. Or whether it actually exits but PID 1 doesn't notice it. And
then if you figured out which of the two cases, you'd have to figure out
why that is...
I finally managed to reproduce it with user instance running with debug
level (before *any* attempt to add debugging, strace, whatever resulted
in problem disappearing).
It seems that /bin/kill -RTMIN+24 is being killed itself. I wonder - is
it possible that it is the same SIGTERM that is used by PID 1 to stop
user@0service?
Ah, bummer! Yikes!
Thanks for tracking this done, this really sounds like you nailed the
problem. Now, how to fix it?
Hmm, so, I would claim this is a shortcoming of
KillMode=control-group, which is the default for everything. There has
been an item on the TODO list to maybe introduce a KillMode=mixed
setting, which would send SIGTERM only to the main process, and the
SIGKILL later on to all processes. I am pretty sure that this would
solve the issue at hand quite nicely here, because the systemd user
instance would get a nice chance to clean up its own act, before the
systemd system instance would make tabula rasa...
I still favor alternative approach - let systemd wait for main PID
to exit after ExecStop instead. This is functionally equivalent to the
above with slight advantages
- it will probably decrease number of timeouts because systemd will go
on killing spree as soon as main PID exits, not after final timeout.
- it is more generic as it allows any available method to trigger
service stop, not just a signal.
Comments are welcome :)
From: Andrey Borzenkov arvidj...@gmail.com
Subject: [PATCH] add WaitForMainPIDOnStop option
WaitForMainPIDOnStop=true will wait for exit of main PID in addition to
command set as ExecStop.
Use it in user@.service to allow user systemd to complete exit transaction
before starting final kill.
---
man/systemd.service.xml | 13 +
src/core/dbus-service.c | 1 +
src/core/load-fragment-gperf.gperf.m4 | 1 +
src/core/service.c| 15 +--
src/core/service.h| 1 +
units/u...@.service.in| 2 ++
6 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index d316ab5..c121c95 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -1016,6 +1016,19 @@ ExecStart=/bin/echo $ONE $TWO ${TWO}
optionnone/option./para/listitem
/varlistentry
+varlistentry
+
termvarnameWaitForMainPIDOnStop=/varname/term
+
+listitemparaTakes a boolean value
+that specifies whether systemd should
+additionally wait for the main PID of a service
+to exit after executing ExecStop command.
+Default is to wait for completion of ExecStop
+command only. Defaults to
+optionno/option./para
+/listitem
+/varlistentry
+
/variablelist
paraCheck
diff --git a/src/core/dbus-service.c b/src/core/dbus-service.c
index 3db9339..35a3c2f 100644
--- a/src/core/dbus-service.c
+++ b/src/core/dbus-service.c
@@ -54,6 +54,7 @@ const sd_bus_vtable bus_service_vtable[] = {
SD_BUS_PROPERTY(RootDirectoryStartOnly, b, bus_property_get_bool,
offsetof(Service, root_directory_start_only), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(RemainAfterExit, b, bus_property_get_bool,
offsetof(Service, remain_after_exit), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(GuessMainPID, b, bus_property_get_bool,
offsetof(Service, guess_main_pid), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY(WaitForMainPIDOnStop, b, bus_property_get_bool,
offsetof(Service, stop_waits_for_main_pid), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY(MainPID, u, bus_property_get_pid,
offsetof(Service, main_pid), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
SD_BUS_PROPERTY(ControlPID, u, bus_property_get_pid,
offsetof(Service, control_pid), SD_BUS_VTABLE_PROPERTY_EMITS_CHANGE),
SD_BUS_PROPERTY(BusName, s, NULL, offsetof(Service, bus_name),
SD_BUS_VTABLE_PROPERTY_CONST),
diff --git a/src/core/load-fragment-gperf.gperf.m4
b/src/core/load-fragment-gperf.gperf.m4
index
Re: [systemd-devel] [PATCH] Drop Before=paths/sockets/timers.target from DefaultDependencies.
В Wed, 29 Jan 2014 10:16:06 +0100 Thomas Bächler tho...@archlinux.org пишет: Am 29.01.2014 03:49, schrieb Andrey Borzenkov: Zbyszek's argument for the patch, however, is that following the recommended WantedBy= behavior already applies the same Before= dependency, Where is *this* documented? Unless I misunderstand what you say. The documentation (and code) regarding the sometimes unexpected behaviour of DefaultDependencies is scattered in a few places - this cost me some time when I first learned how to systemd. From systemd.unit(5): If true, (the default), a few default dependencies will implicitly be created for the unit. The actual dependencies created depend on the unit type. Now, it is true that when you look at systemd.service(5) and friends, there is no mention of this implicit Before= dependency mentioned above. Even when you look at the code, you won't find it directly. Eventually, you'll find this bit in systemd.target(5): Unless DefaultDependencies= is set to false, target units will implicitly complement all configured dependencies of type Wants=, Requires=, RequiresOverridable= with dependencies of type After= if the units in question also have DefaultDependencies=true Ah! of course. Thank you. Somehow amount of documentation in systemd may also become a disadvantage :) So, in order to understand DefaultDependencies, you need to read the related bits in systemd.unit(5), systemd.service(5), systemd.timer(5), systemd.socket(5), systemd.path(5), systemd.slice(5), systemd.swap(5) and systemd.target(5). The manpages systemd.mount(5) and systemd.automount(5) seem to lack any information about default dependencies. In theory you need just two of them - for two units in question, for which you try to understand why they have these specific relations. This is really annoying to learn - I'd suggest collecting all this information in one place - IMO, it belongs either into systemd.unit(5) or into its own manpage. Actually I think having default dependency for a unit type in the man page for this unit type is logical. May be some magic to auto-generate cross-reference man page would be nice. Maintaining this manually is too error prone. signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Drop Before=paths/sockets/timers.target from DefaultDependencies.
В Tue, 28 Jan 2014 13:15:38 -0800 David Timothy Strauss da...@davidstrauss.net пишет: Alternatively, we should update the man pages to reflect what the DefaultDependencies= option affects. Zbyszek's argument for the patch, however, is that following the recommended WantedBy= behavior already applies the same Before= dependency, Where is *this* documented? Unless I misunderstand what you say. and anyone doing otherwise ought not to be subjected to a possibly circular Before= dependency. ___ 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] Add unit to arbitrary target.
On Wed, Jan 29, 2014 at 9:23 AM, dE de.tec...@gmail.com wrote:
On enabling a unit, by default systemd will put it in a target which has
been specified in by the unit itself.
Is there any way by which I can make the unit start in any custom target?
Manual linking or using systemctl?
Just use manual links. Create directory
/etc/systemd/{system,user}/foo.target.wants and link to your unit
there. The name is better be the same as original unit name with
exception of templates (I do not think it is enforced right now but it
may be in the future).
Or if you know in advance which units should be started by your
target, just list them in Wants= directive in your target unit.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Allow stop jobs to be killed during shutdown
В Mon, 27 Jan 2014 07:43:55 +0100 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет: Looks like we need a setting like SendKillSignalTo=main-pid|all|control-pid. Quoting from this thread I don't think we want any processes to survive the exit of user@.service, So why would we need this setting? Final kill should go to all remaining processes; what is scenario where it would *not*? So may be we simply need to make final kill independent of KillMode. I'm fine with having separate setting for SIGTERM and SIGKILL, just do not see use case for the latter. Having KillMode=process and ensuring that final kill really attempts to kill everything would be enough to fix this problem. Except in this case KillMode probably has to be renamed to something else, like SendTermSignalTo= ... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev failing to assign consistent biosdevnames to my ethernet interfaces
В Mon, 27 Jan 2014 05:39:58 + David Anderson d...@natulte.net пишет: On Mon, Jan 27, 2014 at 5:18 AM, Andrey Borzenkov arvidj...@gmail.comwrote: В Mon, 27 Jan 2014 04:18:20 + David Anderson d...@natulte.net пишет: This is a continuation of a discussion I had on #systemd. I have a server that has two onboard ethernet chipsets, and a fresh Arch linux install (systemd/udevd v208). On this system, consistent interface naming fails, and I end up with eno1 and eth1 after bootup. The full boot log is at http://pastebin.com/raw.php?i=KR1YqHYp , but the apparently relevant part is: Jan 26 19:10:38 ironman kernel: e1000e :00:19.0 eth0: Intel(R) PRO/1000 Network Connection ... Jan 26 19:10:38 ironman kernel: e1000e :02:00.0 eth1: Intel(R) PRO/1000 Network Connection ... *Jan 26 19:10:38 ironman systemd-udevd[153]: error changing net interface name eth1 to eno1: File exists* Jan 26 19:10:38 ironman systemd[1]: Found device 82574L Gigabit Network Connection. *Jan 26 19:10:38 ironman systemd-udevd[149]: renamed network interface eth0 to eno1* From that, it appears that udevd is trying to rename both interfaces to eno1. As you can see from the boot log, the two chipsets are on separate PCI buses (bus 0, dev 0x19, and bus 2, dev 0). Looking in /sys , neither device has an acpi_index attribute, and both have an index attribute equal to 1. I'm by far not an expert on this data, but index=1 naively sounds right, since they're both the only ethernet device on their bus. According to The Source ( http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n131 ), lack of acpi_index means that index is used instead, and we end up with two devices mapping to eno1. Further debugging information: full `dmidecode` output ( http://pastebin.com/raw.php?i=MLXkYF2s ), and some shell spelunking in /sys ( http://pastebin.com/raw.php?i=TbSvDMSB ). At this point, I need more expert help. Is this a udev bug where it produces incorrect output in the presence of multiple PCI buses? Is it a firmware bug where my motherboard provides incorrect data to udev? Looks like it. According to specs Device Type Instance is a unique value (within a given onboard device type) Can you link me to the relevant spec? I suspect that Intel interpreted this as unique value within a bus instead of unique machine-wide, but I'm interested in the context surrounding that statement. http://www.dmtf.org/sites/default/files/standards/documents/DSP0134_2.8.0.pdf 7.42 Onboard Devices Extended Information (Type 41) If it is indeed a firmware bug, there's nothing obvious for udev to do. A suggestion on IRC was to disambiguate by bus/device ID in such cases (lowest bus:device gets eno1, next gets eno2, etc.). I don't know if this is desirable, or even if udev can do this since it would require a second pass over the affected devices with a global view of all such devices. This means interface names will be dependent on scan order (the first one wins) which rather defeats the idea of automatically generated persistent names. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Allow stop jobs to be killed during shutdown
В Mon, 27 Jan 2014 12:15:54 +
Colin Guthrie gm...@colin.guthr.ie пишет:
[Mailing list CC'ed again]
'Twas brillig, and Andrey Borzenkov at 27/01/14 11:58 did gyre and gimble:
В Mon, 27 Jan 2014 11:27:31 +
Colin Guthrie gm...@colin.guthr.ie пишет:
'Twas brillig, and Andrey Borzenkov at 26/01/14 17:16 did gyre and gimble:
I guess what we want is to first send SIGTERM only to the systemd
--user process, and only after a timeout start sending SIGTERM to all
the processes in the control group? I.e., wouldn't a ExecStop entry in
user@.service give us the required timeout?
Does not work. systemd sends SIGTERM as soon as ExecStop finished.
Could you not use the same hack that apache httpd needs?
http://pkgs.fedoraproject.org/cgit/httpd.git/tree/httpd.service#n28
No.
systemd user instance needs SIGTERM to start shutdown procedure.
systemd system instance does not allow SIGTERM to be sent to the
$MAINPID only. Sending SIGTERM to all processes at the very beginning
is wrong.
Hmm, I thought the bit I quoted which said:
ExecStop=/bin/kill -WINCH ${MAINPID}
could be used to tell the user session to start it's shudown procedure,
but rather than -WINCH as in the httpd case, we'd just send SIGTERM here
instead.
Ah, well. So systemd will not allow to say KillMode=none but happily
accepts dummy signal which does nothing. How consistent :)
This could be considered as workaround for a released distro where
user@.service does not do anything useful anyway. Right. Thank you for
an idea!
But perhaps I'm still missing something and this won't work :(
No, I expect it to work. Just losing final graceful stop step, but
this should have been handled by systemd user instance already in the
first place.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Allow stop jobs to be killed during shutdown
В Mon, 27 Jan 2014 13:15:55 +0100 Tom Gundersen t...@jklm.no пишет: On Mon, Jan 27, 2014 at 7:43 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Sun, Jan 26, 2014 at 09:16:13PM +0400, Andrey Borzenkov wrote: В Sun, 26 Jan 2014 17:23:54 +0100 Tom Gundersen t...@jklm.no пишет: Unfortunately, setting KillMode=process is not allowed: Jan 26 17:12:30 linux-1a7f systemd[1]: user@0.service has PAM enabled. Kill mode must be set to 'control-group'. Refusing. Probably user@.service should be exempt from this rule. It is supposed to handle all services started by it itself, it *is* service manager after all? I don't think we want any processes to survive the exit of user@.service, so KillMode=process feels wrong. However, isn't the problem that we are going into the kill control-group mode too soon, before user@.serivce has had a chance of cleaning itself up gracefully? Yes. I rebuilt systemd without this restriction, set KillMode=process for user@.service and this fixed things here. So there are two problems associated with user instance. 1. Using KillMode=control-group is wrong. Each service managed by user instance has own requirements how it is stopped. Just sending everything SIGTERM without even trying service ExecStop first is obviously incorrect. I guess what we want is to first send SIGTERM only to the systemd --user process, and only after a timeout start sending SIGTERM to all the processes in the control group? I.e., wouldn't a ExecStop entry in user@.service give us the required timeout? Does not work. systemd sends SIGTERM as soon as ExecStop finished. Looks like we need a setting like SendKillSignalTo=main-pid|all|control-pid. Or something like that. Also the TimeoutStopSec on user@.service should be probably increased to 10 min or so. I believe someone already mentioned this problem. In general, we cannot assume that ExecStop is synchronous. It may just signal main process to exit. systemd should wait until $MAINPID exits (or timeout) before continuing further processing. ExecStop is required to be synchronous, i.e. the service should be stopped when it returns. /bin/kill is not going to work here. Good point, I had missed that (I assumed there was a timeout). So something like a synchronous systemctl --user stop should do it, no? Yes, except systemd --user is defined only for a *current* user. Extending it to systemd --user=UID would be a solution (it must be numerical UID as nothing more is available in user@.service). I played with su, but it does not work with UID - it want user name, ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Allow stop jobs to be killed during shutdown
В Mon, 27 Jan 2014 15:29:15 +0100 Lennart Poettering lenn...@poettering.net пишет: On Mon, 27.01.14 13:42, Tom Gundersen (t...@jklm.no) wrote: So maybe something like this: In addition to the boolean values for systemd.show_status= on the kernel cmdline (or ShowStatus= in system.conf), we'd add a third value called auto. If that is set we'd boot up without any status output, until either at least one service failed, or at least one job reaches its timeout half-way. For people like me who has an attention span of about five seconds, half-way to the timeout is still a really long time to just sit there. Maybe just use the same timeout as the eye-of-cylon thingie? Yeah, maybe. Figuring out good timeouts its probably something one should do when actually playing around with it and checking how things feel if this is implemented... When that point is reached we'c continue the entire rest of the boot with status output enabled. Hm, maybe only do this if something actually failed/reached the timeout, and not if we just show the eye-of-cylon for a while and then continue normally? Hmm, possibly, yeah, but we probably should explain that too... i.e. Turning off boot-time status output again, since timeout is resolved or so... But maybe this ultimately gets too confusing... Note that this all is just an issue on non-Plymouth systems. If you use Plymouth then things are much nicer anyway, since the output is always generated, just not visible on screen until the user hits Esc. Yes, but you still want to virtually press ESC to attract user attention to a problem ... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Allow stop jobs to be killed during shutdown
В Fri, 24 Jan 2014 18:46:06 +0100 Lennart Poettering lenn...@poettering.net пишет: On Fri, 24.01.14 21:10, Ivan Shapovalov (intelfx...@gmail.com) wrote: However, something like that can never be the default, we need to give services the chance to shut down cleanly and in the right order then bugs like https://bugzilla.redhat.com/show_bug.cgi?id=1023820 I have so far never encountered this issue, but I fear this is a bug where somebody who can reproduce this needs to sit down and debug a bit... Lennart Any advices on how to do that? I have both the issue (reproducible on each shutdown) and will to debug. Well, enable the debug shell, and then from there try to figure out why things are stuck. i.e. whether it is systemd --user that really never exits. Or whether it actually exits but PID 1 doesn't notice it. And then if you figured out which of the two cases, you'd have to figure out why that is... I finally managed to reproduce it with user instance running with debug level (before *any* attempt to add debugging, strace, whatever resulted in problem disappearing). It seems that /bin/kill -RTMIN+24 is being killed itself. I wonder - is it possible that it is the same SIGTERM that is used by PID 1 to stop user@0service? Jan 26 11:53:58 linux-1a7f systemd[1942]: Received SIGTERM from PID 1 (systemd). Jan 26 11:53:58 linux-1a7f systemd[1942]: Activating special unit exit.target Jan 26 11:53:58 linux-1a7f systemd[1942]: Trying to enqueue job exit.target/start/replace Jan 26 11:53:58 linux-1a7f systemd[1942]: Installed new job exit.target/start as 3 Jan 26 11:53:58 linux-1a7f systemd[1942]: Installed new job systemd-exit.service/start as 4 Jan 26 11:53:58 linux-1a7f systemd[1942]: Installed new job shutdown.target/start as 5 Jan 26 11:53:58 linux-1a7f systemd[1942]: Installed new job default.target/stop as 7 Jan 26 11:53:58 linux-1a7f systemd[1942]: Enqueued job exit.target/start as 3 Jan 26 11:53:58 linux-1a7f systemd[1942]: Stopping Default. Jan 26 11:53:58 linux-1a7f systemd[1942]: default.target changed active - dead Jan 26 11:53:58 linux-1a7f systemd[1942]: Job default.target/stop finished, result=done Jan 26 11:53:58 linux-1a7f systemd[1942]: Stopped target Default. Jan 26 11:53:58 linux-1a7f systemd[1942]: Starting Shutdown. Jan 26 11:53:58 linux-1a7f systemd[1942]: shutdown.target changed dead - active Jan 26 11:53:58 linux-1a7f systemd[1942]: Job shutdown.target/start finished, result=done Jan 26 11:53:59 linux-1a7f systemd[1942]: Reached target Shutdown. Jan 26 11:53:59 linux-1a7f systemd[1942]: Starting Exit the Session... Jan 26 11:53:59 linux-1a7f systemd[1942]: About to execute: /usr/bin/kill -s 58 $MANAGERPID Jan 26 11:53:59 linux-1a7f systemd[1942]: Forked /usr/bin/kill as 1951 Jan 26 11:53:59 linux-1a7f systemd[1942]: systemd-exit.service changed dead - start Jan 26 11:53:59 linux-1a7f systemd[1942]: Set up jobs progress timerfd. Jan 26 11:53:59 linux-1a7f systemd[1942]: Collecting default.target Jan 26 11:53:59 linux-1a7f systemd[1942]: Received SIGCHLD from PID 1943 ((sd-pam)). Jan 26 11:53:59 linux-1a7f systemd[1942]: Got SIGCHLD for process 1943 ((sd-pam)) Jan 26 11:53:59 linux-1a7f systemd[1942]: Child 1943 died (code=exited, status=0/SUCCESS) Jan 26 11:53:59 linux-1a7f systemd[1942]: Received SIGCHLD from PID 1951 ((kill)). Jan 26 11:53:59 linux-1a7f systemd[1942]: Got SIGCHLD for process 1951 ((kill)) Jan 26 11:53:59 linux-1a7f systemd[1942]: Child 1951 died (code=killed, status=15/TERM) Jan 26 11:53:59 linux-1a7f systemd[1942]: Child 1951 belongs to systemd-exit.service Jan 26 11:53:59 linux-1a7f systemd[1942]: systemd-exit.service: main process exited, code=killed, status=15/TERM Jan 26 11:53:59 linux-1a7f systemd[1942]: systemd-exit.service changed start - dead Jan 26 11:53:59 linux-1a7f systemd[1942]: Job systemd-exit.service/start finished, result=done Jan 26 11:53:59 linux-1a7f systemd[1942]: Started Exit the Session. Jan 26 11:53:59 linux-1a7f systemd[1942]: Closed jobs progress timerfd. Jan 26 11:53:59 linux-1a7f systemd[1942]: Starting Exit the Session. Jan 26 11:53:59 linux-1a7f systemd[1942]: exit.target changed dead - active Jan 26 11:53:59 linux-1a7f systemd[1942]: Job exit.target/start finished, result=done Jan 26 11:53:59 linux-1a7f systemd[1942]: Reached target Exit the Session. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Allow stop jobs to be killed during shutdown
В Sun, 26 Jan 2014 12:09:23 +0400 Andrey Borzenkov arvidj...@gmail.com пишет: В Fri, 24 Jan 2014 18:46:06 +0100 Lennart Poettering lenn...@poettering.net пишет: On Fri, 24.01.14 21:10, Ivan Shapovalov (intelfx...@gmail.com) wrote: However, something like that can never be the default, we need to give services the chance to shut down cleanly and in the right order then bugs like https://bugzilla.redhat.com/show_bug.cgi?id=1023820 I have so far never encountered this issue, but I fear this is a bug where somebody who can reproduce this needs to sit down and debug a bit... Lennart Any advices on how to do that? I have both the issue (reproducible on each shutdown) and will to debug. Well, enable the debug shell, and then from there try to figure out why things are stuck. i.e. whether it is systemd --user that really never exits. Or whether it actually exits but PID 1 doesn't notice it. And then if you figured out which of the two cases, you'd have to figure out why that is... I finally managed to reproduce it with user instance running with debug level (before *any* attempt to add debugging, strace, whatever resulted in problem disappearing). It seems that /bin/kill -RTMIN+24 is being killed itself. I wonder - is it possible that it is the same SIGTERM that is used by PID 1 to stop user@0service? I'm almost sure it is. cg_kill_recursive is in no way atomic, so it can easily hit new process that was spawned since service stop had been initiated. Unfortunately, setting KillMode=process is not allowed: Jan 26 17:12:30 linux-1a7f systemd[1]: user@0.service has PAM enabled. Kill mode must be set to 'control-group'. Refusing. Probably user@.service should be exempt from this rule. It is supposed to handle all services started by it itself, it *is* service manager after all? Jan 26 11:53:58 linux-1a7f systemd[1942]: Received SIGTERM from PID 1 (systemd). Jan 26 11:53:58 linux-1a7f systemd[1942]: Activating special unit exit.target Jan 26 11:53:58 linux-1a7f systemd[1942]: Trying to enqueue job exit.target/start/replace Jan 26 11:53:58 linux-1a7f systemd[1942]: Installed new job exit.target/start as 3 Jan 26 11:53:58 linux-1a7f systemd[1942]: Installed new job systemd-exit.service/start as 4 Jan 26 11:53:58 linux-1a7f systemd[1942]: Installed new job shutdown.target/start as 5 Jan 26 11:53:58 linux-1a7f systemd[1942]: Installed new job default.target/stop as 7 Jan 26 11:53:58 linux-1a7f systemd[1942]: Enqueued job exit.target/start as 3 Jan 26 11:53:58 linux-1a7f systemd[1942]: Stopping Default. Jan 26 11:53:58 linux-1a7f systemd[1942]: default.target changed active - dead Jan 26 11:53:58 linux-1a7f systemd[1942]: Job default.target/stop finished, result=done Jan 26 11:53:58 linux-1a7f systemd[1942]: Stopped target Default. Jan 26 11:53:58 linux-1a7f systemd[1942]: Starting Shutdown. Jan 26 11:53:58 linux-1a7f systemd[1942]: shutdown.target changed dead - active Jan 26 11:53:58 linux-1a7f systemd[1942]: Job shutdown.target/start finished, result=done Jan 26 11:53:59 linux-1a7f systemd[1942]: Reached target Shutdown. Jan 26 11:53:59 linux-1a7f systemd[1942]: Starting Exit the Session... Jan 26 11:53:59 linux-1a7f systemd[1942]: About to execute: /usr/bin/kill -s 58 $MANAGERPID Jan 26 11:53:59 linux-1a7f systemd[1942]: Forked /usr/bin/kill as 1951 Jan 26 11:53:59 linux-1a7f systemd[1942]: systemd-exit.service changed dead - start Jan 26 11:53:59 linux-1a7f systemd[1942]: Set up jobs progress timerfd. Jan 26 11:53:59 linux-1a7f systemd[1942]: Collecting default.target Jan 26 11:53:59 linux-1a7f systemd[1942]: Received SIGCHLD from PID 1943 ((sd-pam)). Jan 26 11:53:59 linux-1a7f systemd[1942]: Got SIGCHLD for process 1943 ((sd-pam)) Jan 26 11:53:59 linux-1a7f systemd[1942]: Child 1943 died (code=exited, status=0/SUCCESS) Jan 26 11:53:59 linux-1a7f systemd[1942]: Received SIGCHLD from PID 1951 ((kill)). Jan 26 11:53:59 linux-1a7f systemd[1942]: Got SIGCHLD for process 1951 ((kill)) Jan 26 11:53:59 linux-1a7f systemd[1942]: Child 1951 died (code=killed, status=15/TERM) Jan 26 11:53:59 linux-1a7f systemd[1942]: Child 1951 belongs to systemd-exit.service Jan 26 11:53:59 linux-1a7f systemd[1942]: systemd-exit.service: main process exited, code=killed, status=15/TERM Jan 26 11:53:59 linux-1a7f systemd[1942]: systemd-exit.service changed start - dead Jan 26 11:53:59 linux-1a7f systemd[1942]: Job systemd-exit.service/start finished, result=done Jan 26 11:53:59 linux-1a7f systemd[1942]: Started Exit the Session. Jan 26 11:53:59 linux-1a7f systemd[1942]: Closed jobs progress timerfd. Jan 26 11:53:59 linux-1a7f systemd[1942]: Starting Exit the Session. Jan 26 11:53:59 linux-1a7f systemd[1942]: exit.target changed dead - active Jan 26 11:53:59 linux-1a7f systemd[1942]: Job exit.target/start finished, result=done Jan 26 11:53:59 linux-1a7f
Re: [systemd-devel] Allow stop jobs to be killed during shutdown
В Sun, 26 Jan 2014 17:18:28 +0400 Andrey Borzenkov arvidj...@gmail.com пишет: В Sun, 26 Jan 2014 12:09:23 +0400 Andrey Borzenkov arvidj...@gmail.com пишет: В Fri, 24 Jan 2014 18:46:06 +0100 Lennart Poettering lenn...@poettering.net пишет: On Fri, 24.01.14 21:10, Ivan Shapovalov (intelfx...@gmail.com) wrote: However, something like that can never be the default, we need to give services the chance to shut down cleanly and in the right order then bugs like https://bugzilla.redhat.com/show_bug.cgi?id=1023820 I have so far never encountered this issue, but I fear this is a bug where somebody who can reproduce this needs to sit down and debug a bit... Lennart Any advices on how to do that? I have both the issue (reproducible on each shutdown) and will to debug. Well, enable the debug shell, and then from there try to figure out why things are stuck. i.e. whether it is systemd --user that really never exits. Or whether it actually exits but PID 1 doesn't notice it. And then if you figured out which of the two cases, you'd have to figure out why that is... I finally managed to reproduce it with user instance running with debug level (before *any* attempt to add debugging, strace, whatever resulted in problem disappearing). It seems that /bin/kill -RTMIN+24 is being killed itself. I wonder - is it possible that it is the same SIGTERM that is used by PID 1 to stop user@0service? I'm almost sure it is. cg_kill_recursive is in no way atomic, so it can easily hit new process that was spawned since service stop had been initiated. Unfortunately, setting KillMode=process is not allowed: Jan 26 17:12:30 linux-1a7f systemd[1]: user@0.service has PAM enabled. Kill mode must be set to 'control-group'. Refusing. Probably user@.service should be exempt from this rule. It is supposed to handle all services started by it itself, it *is* service manager after all? I rebuilt systemd without this restriction, set KillMode=process for user@.service and this fixed things here. So there are two problems associated with user instance. 1. Using KillMode=control-group is wrong. Each service managed by user instance has own requirements how it is stopped. Just sending everything SIGTERM without even trying service ExecStop first is obviously incorrect. 2. user@.service has single timeout, but it manages unknown in advance number of services each needing unknown timeout. While having some capping to total timeout looks sensible, only user itself may estimate the value. But service user@.system is system-level service which use cannot configure ... Jan 26 11:53:58 linux-1a7f systemd[1942]: Received SIGTERM from PID 1 (systemd). Jan 26 11:53:58 linux-1a7f systemd[1942]: Activating special unit exit.target Jan 26 11:53:58 linux-1a7f systemd[1942]: Trying to enqueue job exit.target/start/replace Jan 26 11:53:58 linux-1a7f systemd[1942]: Installed new job exit.target/start as 3 Jan 26 11:53:58 linux-1a7f systemd[1942]: Installed new job systemd-exit.service/start as 4 Jan 26 11:53:58 linux-1a7f systemd[1942]: Installed new job shutdown.target/start as 5 Jan 26 11:53:58 linux-1a7f systemd[1942]: Installed new job default.target/stop as 7 Jan 26 11:53:58 linux-1a7f systemd[1942]: Enqueued job exit.target/start as 3 Jan 26 11:53:58 linux-1a7f systemd[1942]: Stopping Default. Jan 26 11:53:58 linux-1a7f systemd[1942]: default.target changed active - dead Jan 26 11:53:58 linux-1a7f systemd[1942]: Job default.target/stop finished, result=done Jan 26 11:53:58 linux-1a7f systemd[1942]: Stopped target Default. Jan 26 11:53:58 linux-1a7f systemd[1942]: Starting Shutdown. Jan 26 11:53:58 linux-1a7f systemd[1942]: shutdown.target changed dead - active Jan 26 11:53:58 linux-1a7f systemd[1942]: Job shutdown.target/start finished, result=done Jan 26 11:53:59 linux-1a7f systemd[1942]: Reached target Shutdown. Jan 26 11:53:59 linux-1a7f systemd[1942]: Starting Exit the Session... Jan 26 11:53:59 linux-1a7f systemd[1942]: About to execute: /usr/bin/kill -s 58 $MANAGERPID Jan 26 11:53:59 linux-1a7f systemd[1942]: Forked /usr/bin/kill as 1951 Jan 26 11:53:59 linux-1a7f systemd[1942]: systemd-exit.service changed dead - start Jan 26 11:53:59 linux-1a7f systemd[1942]: Set up jobs progress timerfd. Jan 26 11:53:59 linux-1a7f systemd[1942]: Collecting default.target Jan 26 11:53:59 linux-1a7f systemd[1942]: Received SIGCHLD from PID 1943 ((sd-pam)). Jan 26 11:53:59 linux-1a7f systemd[1942]: Got SIGCHLD for process 1943 ((sd-pam)) Jan 26 11:53:59 linux-1a7f systemd[1942]: Child 1943 died (code=exited, status=0/SUCCESS) Jan 26 11:53:59 linux-1a7f systemd[1942]: Received SIGCHLD from PID 1951 ((kill)). Jan 26 11:53:59 linux-1a7f systemd[1942]: Got SIGCHLD for process 1951 ((kill)) Jan 26
Re: [systemd-devel] Allow stop jobs to be killed during shutdown
В Sun, 26 Jan 2014 17:23:54 +0100 Tom Gundersen t...@jklm.no пишет: Unfortunately, setting KillMode=process is not allowed: Jan 26 17:12:30 linux-1a7f systemd[1]: user@0.service has PAM enabled. Kill mode must be set to 'control-group'. Refusing. Probably user@.service should be exempt from this rule. It is supposed to handle all services started by it itself, it *is* service manager after all? I don't think we want any processes to survive the exit of user@.service, so KillMode=process feels wrong. However, isn't the problem that we are going into the kill control-group mode too soon, before user@.serivce has had a chance of cleaning itself up gracefully? Yes. I rebuilt systemd without this restriction, set KillMode=process for user@.service and this fixed things here. So there are two problems associated with user instance. 1. Using KillMode=control-group is wrong. Each service managed by user instance has own requirements how it is stopped. Just sending everything SIGTERM without even trying service ExecStop first is obviously incorrect. I guess what we want is to first send SIGTERM only to the systemd --user process, and only after a timeout start sending SIGTERM to all the processes in the control group? I.e., wouldn't a ExecStop entry in user@.service give us the required timeout? Does not work. systemd sends SIGTERM as soon as ExecStop finished. Jan 26 21:00:14 linux-1a7f systemd[1]: Stopping User Manager for 0... Jan 26 21:00:14 linux-1a7f systemd[1]: About to execute: /usr/bin/kill -15 $MAINPID Jan 26 21:00:14 linux-1a7f systemd[1]: Forked /usr/bin/kill as 1978 Jan 26 21:00:14 linux-1a7f systemd[1]: user@0.service changed running - stop Jan 26 21:00:14 linux-1a7f systemd[1978]: Executing: /usr/bin/kill -15 1886 Jan 26 21:00:14 linux-1a7f systemd[1886]: Received SIGTERM from PID 1978 (kill). Jan 26 21:00:14 linux-1a7f systemd[1886]: Activating special unit exit.target Jan 26 21:00:14 linux-1a7f systemd[1886]: Trying to enqueue job exit.target/start/replace Jan 26 21:00:14 linux-1a7f systemd[1886]: Installed new job exit.target/start as 9 Jan 26 21:00:14 linux-1a7f systemd[1886]: Installed new job systemd-exit.service/start as 10 Jan 26 21:00:14 linux-1a7f systemd[1886]: Installed new job shutdown.target/start as 11 Jan 26 21:00:14 linux-1a7f systemd[1886]: Installed new job -.slice/stop as 12 Jan 26 21:00:14 linux-1a7f systemd[1886]: Installed new job default.target/stop as 13 Jan 26 21:00:14 linux-1a7f systemd[1886]: Installed new job test.service/stop as 14 Jan 26 21:00:14 linux-1a7f systemd[1886]: Installed new job paths.target/stop as 15 Jan 26 21:00:14 linux-1a7f systemd[1886]: Installed new job timers.target/stop as 16 Jan 26 21:00:14 linux-1a7f systemd[1886]: Installed new job sockets.target/stop as 17 Jan 26 21:00:14 linux-1a7f systemd[1886]: Enqueued job exit.target/start as 9 Jan 26 21:00:14 linux-1a7f systemd[1886]: Stopping Test service with stop delay... Jan 26 21:00:14 linux-1a7f systemd[1886]: About to execute: /bin/sleep 10 Jan 26 21:00:14 linux-1a7f systemd[1886]: Forked /bin/sleep as 2001 Jan 26 21:00:14 linux-1a7f systemd[1886]: test.service changed exited - stop Jan 26 21:00:14 linux-1a7f systemd[2001]: Executing: /bin/sleep 10 Jan 26 21:00:14 linux-1a7f systemd[1886]: Stopping Default. ... Jan 26 21:00:14 linux-1a7f systemd[1]: Child 1978 died (code=exited, status=0/SUCCESS) Jan 26 21:00:14 linux-1a7f systemd[1]: Child 1978 belongs to user@0.service Jan 26 21:00:14 linux-1a7f systemd[1]: user@0.service: control process exited, code=exited status=0 Jan 26 21:00:14 linux-1a7f systemd[1]: user@0.service got final SIGCHLD for state stop Jan 26 21:00:14 linux-1a7f systemd[1]: user@0.service changed stop - stop-sigterm I believe someone already mentioned this problem. In general, we cannot assume that ExecStop is synchronous. It may just signal main process to exit. systemd should wait until $MAINPID exits (or timeout) before continuing further processing. 2. user@.service has single timeout, but it manages unknown in advance number of services each needing unknown timeout. While having some capping to total timeout looks sensible, only user itself may estimate the value. But service user@.system is system-level service which use cannot configure ... I think it really makes sense to have a system-wide timeout on these things (possibly a high one), we don't want the user to delay things without limit. The user already has the possibility of putting their own limits if they want to (but they must of course be shorter than the system-wide one). I mostly agree, except current 90 seconds look too small and this definitely requires better communication to user (like auto exit from quiet mode) so system does not appear to be hung. There is also practical issue - we have two levels - PID 1 instance and user instance (multiple users actually). Does it make sense to display each individual user
Re: [systemd-devel] Malicious tests?
В Sun, 26 Jan 2014 19:44:13 -0500 Tom Horsley horsley1...@gmail.com пишет: Does systemd have any tests for malicious behavior? People sending bazillions of dbus requests? People sending random nonsense dbus requests? I'm just asking because you gotta know someone is gonna do it if you don't do it first :-). I also find that merely sending two systemctl disable commands in quick succession totally borks my fedora 20 system, so there's your first malicious test that doesn't even need a new program or script written... See: https://bugzilla.redhat.com/show_bug.cgi?id=1043212#c45 It is not disable itself but rather implicit deamon-reload it does. This was reported here just recently by Colin. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev failing to assign consistent biosdevnames to my ethernet interfaces
В Mon, 27 Jan 2014 04:18:20 + David Anderson d...@natulte.net пишет: This is a continuation of a discussion I had on #systemd. I have a server that has two onboard ethernet chipsets, and a fresh Arch linux install (systemd/udevd v208). On this system, consistent interface naming fails, and I end up with eno1 and eth1 after bootup. The full boot log is at http://pastebin.com/raw.php?i=KR1YqHYp , but the apparently relevant part is: Jan 26 19:10:38 ironman kernel: e1000e :00:19.0 eth0: Intel(R) PRO/1000 Network Connection ... Jan 26 19:10:38 ironman kernel: e1000e :02:00.0 eth1: Intel(R) PRO/1000 Network Connection ... *Jan 26 19:10:38 ironman systemd-udevd[153]: error changing net interface name eth1 to eno1: File exists* Jan 26 19:10:38 ironman systemd[1]: Found device 82574L Gigabit Network Connection. *Jan 26 19:10:38 ironman systemd-udevd[149]: renamed network interface eth0 to eno1* From that, it appears that udevd is trying to rename both interfaces to eno1. As you can see from the boot log, the two chipsets are on separate PCI buses (bus 0, dev 0x19, and bus 2, dev 0). Looking in /sys , neither device has an acpi_index attribute, and both have an index attribute equal to 1. I'm by far not an expert on this data, but index=1 naively sounds right, since they're both the only ethernet device on their bus. According to The Source ( http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n131), lack of acpi_index means that index is used instead, and we end up with two devices mapping to eno1. Further debugging information: full `dmidecode` output ( http://pastebin.com/raw.php?i=MLXkYF2s ), and some shell spelunking in /sys ( http://pastebin.com/raw.php?i=TbSvDMSB ). At this point, I need more expert help. Is this a udev bug where it produces incorrect output in the presence of multiple PCI buses? Is it a firmware bug where my motherboard provides incorrect data to udev? Looks like it. According to specs Device Type Instance is a unique value (within a given onboard device type) You have two devices of type Ethernet with the same Instance values. Regardless, should udev be capable of handling this gracefully? You can always override udev names with your own. What do you suggest to do automatically? There is no way to find out which interface is really the first and which is the second. Should I report a bug? Do you need more information from my system? Thoughts on temporary workarounds so that I can continue configuring my system with consistent interfaces also welcome, but my major concern is whether udev is doing the right thing, and how to make it do the right thing if not. Cheers, - Dave ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Allow stop jobs to be killed during shutdown
В Fri, 24 Jan 2014 18:46:06 +0100 Lennart Poettering lenn...@poettering.net пишет: On Fri, 24.01.14 21:10, Ivan Shapovalov (intelfx...@gmail.com) wrote: However, something like that can never be the default, we need to give services the chance to shut down cleanly and in the right order then bugs like https://bugzilla.redhat.com/show_bug.cgi?id=1023820 I have so far never encountered this issue, but I fear this is a bug where somebody who can reproduce this needs to sit down and debug a bit... Lennart Any advices on how to do that? I have both the issue (reproducible on each shutdown) and will to debug. Well, enable the debug shell, and then from there try to figure out why things are stuck. i.e. whether it is systemd --user that really never exits. Or whether it actually exits but PID 1 doesn't notice it. And User systemd does not attempt to exit because it does not see signal (RTMIN+24). I'm ready to try to debug it further but simply do not know where - epoll handling by systemd is black magic to me. then if you figured out which of the two cases, you'd have to figure out why that is... Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Allow stop jobs to be killed during shutdown
В Fri, 24 Jan 2014 19:44:08 +0100 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет: On Fri, Jan 24, 2014 at 07:26:48PM +0100, Michael Biebl wrote: 2014/1/24 Lennart Poettering lenn...@poettering.net: On Fri, 24.01.14 18:18, Michael Biebl (mbi...@gmail.com) wrote: Making the shutdown more verbose in such a situation would imho be a good idea, showing a countdown or something like that with a note for which service systemd is currently waiting to be shutdown. I completely agree with Tom here: In situations where on shutdown (or boot for that matter) the system blocks for longer then 30-60 secs and no feedback at all most people will simply assume the system got stuck and do power-reset. Yupp, Michal had the same idea, that's why there is the eye-of-sauron animation in place... Ah, good to know. That's a start. I guess my systemd version (v204) is simply too old then? Is this animation shown irregardless of whether one has booted with quiet or not? With quiet the [OK] lines are not shown, so no, it only works without quiet. Is it possible to automatically switch to more verbose mode as soon as any problem is seen (like service timeout)? Does it require plymouth? It's text based. Zbyszek ___ 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] Allow stop jobs to be killed during shutdown
On Fri, Jan 24, 2014 at 11:09 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 24.01.2014 20:01, schrieb Andrey Borzenkov: В Fri, 24 Jan 2014 19:44:08 +0100 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет: On Fri, Jan 24, 2014 at 07:26:48PM +0100, Michael Biebl wrote: 2014/1/24 Lennart Poettering lenn...@poettering.net: On Fri, 24.01.14 18:18, Michael Biebl (mbi...@gmail.com) wrote: Making the shutdown more verbose in such a situation would imho be a good idea, showing a countdown or something like that with a note for which service systemd is currently waiting to be shutdown. I completely agree with Tom here: In situations where on shutdown (or boot for that matter) the system blocks for longer then 30-60 secs and no feedback at all most people will simply assume the system got stuck and do power-reset. Yupp, Michal had the same idea, that's why there is the eye-of-sauron animation in place... Ah, good to know. That's a start. I guess my systemd version (v204) is simply too old then? Is this animation shown irregardless of whether one has booted with quiet or not? With quiet the [OK] lines are not shown, so no, it only works without quiet. Is it possible to automatically switch to more verbose mode as soon as any problem is seen (like service timeout)? too late, May be I was not clear. There is some timeout after which running stars animation starts. Apparently it is hard-coded and not configurable. It would be useful if this timeout also triggered switch to verbose mode. after the timeout is reached it continues the users problem is the silent waiting *before* the timeout ___ 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] Is masking an error?
On Tue, Jan 21, 2014 at 1:01 PM, Thomas Bächler tho...@archlinux.org wrote: Am 21.01.2014 09:33, schrieb Holger Schurig: on my systemd v208 + many patches from the Fedora 21 source RPM i get TWO error messages in my journal when I login as root: 09:27:58 systemd-logind[118]: Failed to start unit user@0.service: Unit user@0.service failed to load: No such file or directory. 09:27:58 systemd-logind[118]: Failed to start user service: Unit user@0.service failed to load: No such file or directory. Since logind explicitly creates a start job for user@0.service, this is an error, since the service does not exist. systemd could certainly be intelligent enough to notice that template was deliberately masked by admin. That not exactly the same as service does not exist. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] understanding list-unit-files ...
В Wed, 15 Jan 2014 16:20:44 +0100 Holger Schurig holgerschu...@gmail.com пишет: There is one strange thing here: root@desktop:/etc# systemctl list-unit-files | grep multi multi-user.targetdisabled root@desktop:/etc# systemctl status multi-user.target multi-user.target - Multi-User System Loaded: loaded (/lib/systemd/system/multi-user.target; disabled) Active: active since Wed 2014-01-15 15:22:14 CET; 56min ago Docs: man:systemd.special(7) 15:22:14 systemd[1]: Starting Multi-User System. 15:22:14 systemd[1]: Reached target Multi-User System. root@desktop:/etc# So, why is list-unit-files saying that multi-user.target is disabled? It's not, it was even started automatically ... disabled here means only that links, listed in [Install] section, are not present. I agree that semantic of systemctl enable|disable is a bit misleading if you are new to systemd. I am not native English speaker so I cannot suggest alternative that would not convey so strong meaning while still being semantically correct. To really prevent systemd from starting service ever use mask, not disable. It can be started automatically by many different means, e.g. by being pulled in by any other unit, by adding it explicitly as systemd.unit to kernel command line or by simply adding 3 to kernel parameters. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl reboot/shutdown freezes client
В Wed, 15 Jan 2014 02:54:16 +0100 Reindl Harald h.rei...@thelounge.net пишет: can someone please have a look why starting with Fedora 20/RHEL7 and systemd-208 after typing systemctl reboot no longer waits until sshd is closing the client connection resulting in a completly frozen VT ignoring CTRL+C and waiting for KeepAlive timeout If you mean - you ssh into VM, then reboot VM and your client ssh hangs - you can use ~. to quit it. You should always be prepared for something like this - nobody can guarantee your server or network won't die in the middle of session. https://bugzilla.redhat.com/show_bug.cgi?id=1023788 systemd-208-11.fc20.x86_64 http://koji.fedoraproject.org/koji/buildinfo?buildID=491024 still the same problem signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is there any way to stop services in cgroup?
В Чт, 02/01/2014 в 17:43 +0200, Mantas Mikulėnas пишет: On Thu, Jan 2, 2014 at 4:02 PM, Tony Seo tonys...@gmail.com wrote: Hello. I wonder that systemd has a method to stop all services in specific cgroup. Actually, I have looked for a method to stop all services as the same time. I have searched many manual in systemd site. I couldn't find any method to stop all services which I want to stop. If you're trying to stop all instances of a service, systemd-git recently had wildcard support added, so `systemctl stop sshd@*.service` will now work. Otherwise, use a .target and BindsTo. PartOf is probably more appropriate here. But the practical problem is that both must be specified for each unit explicitly, which simply does not scale for future unknown services. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] network-online.target and manual mounts
systemd.special(7) suggests that network-online.target should be pulled in by consumer. Unfortunately, that means that when booting without active consumer (let's say no NFS mounts in fstab) network-online.target is not started at all. If NFS is mounted manually later, no synchronization point exists on shutdown, so network may be stopped before NFS is unmounted. This leads to prolonged timeout. Is there any mechanism to start it when NFS (or other network) mount appears? The very existence of network mount could be considered as indication that network *is* online? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] network-online.target and manual mounts
В Ср, 01/01/2014 в 15:00 -0500, Dave Reisner пишет: On Wed, Jan 01, 2014 at 11:43:15PM +0400, Andrey Borzenkov wrote: systemd.special(7) suggests that network-online.target should be pulled in by consumer. Unfortunately, that means that when booting without active consumer (let's say no NFS mounts in fstab) network-online.target is not started at all. If NFS is mounted manually later, no synchronization point exists on shutdown, so network may be stopped before NFS is unmounted. This leads to prolonged timeout. Is there any mechanism to start it when NFS (or other network) mount appears? The very existence of network mount could be considered as indication that network *is* online? I think tihs is a post-v208 change, but if you manually mount a network share manually after booting, network-online.target is pulled in as Wants= and After=. This should make for correct ordering on shutdown. # mount.cifs //10.0.2.1/pkgs pkg -o defaults,guest,rw # systemctl show -p After -p Wants $PWD/pkg Wants=network-online.target system.slice After=systemd-journald.socket remote-fs-pre.target network.target network-online.target system.slice -.mount Yes, units automatically created from existing mounts do get Wants, but as they are never activated via systemd, these Wants lines never gets executed. Check systemctl status network-online.target. d ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv2] install: Assume *.wants symlinks have the same name as their target for scalability.
В Вс, 29/12/2013 в 18:57 +0100, Zbigniew Jędrzejewski-Szmek пишет:
Hi,
I'd like to reopen this thread.
I have been looking at our bugs [1-10, there are others too] related to
enabling/disabling of units and following of symlinks. Currently this
is an unintuitive mess and some changes will have to be made.
I think that the general rules should be:
(/lib is short for /usr/lib, /usr/local/lib, etc.,
.wants is short for .wants or .requires)
1. when given a unit, it must be possible to read information about
this unit without reading all other units
2. all symlinks in /run and /etc are considered configuration and
will be removed by systemctl disable
3. symlinks within the configuration directories must have
(a) the same symlink and target name, or
(b) the symlink can be a instance and the target a template with
the same stem and type
(c) in /lib, the name can be different, but the type must match, and this
provides an alias
4. systemd must follow the same logic as systemctl and must enforce
the rules.
This means that:
If I read this correctly, the end effect is that every systemd unit file
must be found under standard systemd directories. Right?
1. when linking a unit with 'systemctl enable /path/to/file',
the unit must be linked both into /etc/systemd/system/ and
/etc/systemd/systemd/whatever.wants/. This is what systemctl enable
currently does, but we allowed only the second part done
manually. systemd would be changed to ignore all files in .wants/,
and it would be changed to ignore symlinks in .wants if the unit
cannot be loaded by name otherwise.
What is semantic of having symlink in .wants to different unit file that
would normally be found by systemd. I.e. having both /lib/foo.service
and /etc/foo.service will use /etc version; but what if there is symlink
that points into /lib?
2. symlinking to units to provide an alias is allowed only in /lib.
When systemctl disable is executed, all symlinks in /etc and /run will
be nuked, but /lib will be left alone. I think this is current behaviour.
3. .wants directories and .d directories will only be honored for
the main unit name. The problem that we have currently is that
if the alias unit is not pulled in by anything, this extra configuration
is ignored. But even 'systemctl status' loads the unit, and loads
this extra configuration. systemd would be changed to warn about this
and ignore those extra dirs.
4. support for aliases will be provided on a best-effort basis: If
the alias is done by symlinking in /lib, it is always known.
If the alias is provided by Alias= configuration directive, it
is only known if the unit was already loaded.
There's a bug that 'systemctl disable' removes too much stuff for
instance units. I can't find the report atm, but this is a bug that
should be fixed too.
Zbyszek
[1] https://bugs.freedesktop.org/show_bug.cgi?id=72611
systemctl is-enabled scales poorly with many units (this one)
[2] https://bugs.freedesktop.org/show_bug.cgi?id=63621
systemctl enable doesn't work for Alias names
[3] https://bugs.freedesktop.org/show_bug.cgi?id=72154
systemctl enable named.service yields error messages used for legacy
sysinit scripts
[4] https://bugzilla.redhat.com/show_bug.cgi?id=1014311
RFE: allow systemctl enable work on symlinked units
[5] https://bugzilla.redhat.com/show_bug.cgi?id=864298
systemctl is-enabled reports 'static' incorrectly (it appears)
[6] https://bugzilla.redhat.com/show_bug.cgi?id=955379
systemctl enable fails for user-defined service files in
/etc/systemd/system
[7] https://bugs.freedesktop.org/show_bug.cgi?id=65255
some units can be started when the file is just copied into .wants/
[8] https://bugs.freedesktop.org/show_bug.cgi?id=54560
systemd does not follow symlinks that point outside of
/etc/systemd/system or /usr/lib/systemd/system
[9] https://bugzilla.redhat.com/show_bug.cgi?id=1002806
runlevel command returns unknown
[10] https://bugzilla.redhat.com/show_bug.cgi?id=815835
/sbin/runlevel reports unknown where it shouldn't
On Fri, Dec 13, 2013 at 01:03:30PM -0800, da...@davidstrauss.net wrote:
From: David Strauss da...@davidstrauss.net
---
src/shared/install.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/shared/install.c b/src/shared/install.c
index 17e8a75..512e3df 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -419,10 +419,15 @@ static int find_symlinks_fd(
r = q;
} else if (de-d_type == DT_LNK) {
-_cleanup_free_ char *p = NULL, *dest = NULL;
+_cleanup_free_ char *p = NULL, *dest = NULL,
*no_inst = NULL;
bool found_path, found_dest, b = false;
Re: [systemd-devel] [PATCHv2] login: Don't stop a running user manager from garbage-collecting the user.
On Tue, Dec 24, 2013 at 1:14 PM, Ivan Shapovalov intelfx...@gmail.com wrote: It seems that this patch has been applied to Arch's systemd-208-3, but it did not fix the issue for me. I'm still getting the timeout: Dec 23 17:26:42 intelfx-laptop systemd[1]: user@1000.service stopping timed out. Killing. That's likely different problem. Timeout stopping user@.service was reported more than once. It seems that somehow user systemd instance does not get SIGTERM and so does not initiate service stop (at least that is as far as I could debug it). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev rules environment variable
В Wed, 18 Dec 2013 13:36:52 +0100 Robert Milasan rmila...@suse.com пишет: So basically it doesn't really work ?! It does not always work for net device as it looks like. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev rules environment variable
В Wed, 18 Dec 2013 02:52:01 +0100
Kay Sievers k...@vrfy.org пишет:
On Tue, Dec 17, 2013 at 8:14 PM, Andrey Borzenkov arvidj...@gmail.com wrote:
В Tue, 17 Dec 2013 19:59:47 +0100 Kay Sievers k...@vrfy.org пишет:
# modprobe dummy
dummy is not renamed.
UDEV [80256.274447] move /devices/pci:00/:00:03.0/net/ens3
(net)
ACTION=move
...
INTERFACE=ens3
SEQNUM=1452
...
TAGS=:systemd:
UDEV_LOG=7
Oops. test_device is lost.
Adding something like:
ACTION!=add|remove, IMPORT{db}=test_device
might make it work.
But it does not really scale. It needs to be done individually for every
single prperty. E.g. INTERFACE_OLD added by udev itself is lost as well.
And if even you did not remember this behavior what chances are that
others will?
For move event the only thing that changes is interface name. From
the udev pov not even path to database is changed (IFINDEX is the
same). So I think udev should import all existing properties by default
because this is really the same device with the same properties (as
opposed to change even where properties are not known in advance).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev rules environment variable
В Tue, 17 Dec 2013 14:05:56 +0100
Robert Milasan rmila...@suse.com пишет:
On Tue, 17 Dec 2013 13:54:34 +0100
Martin Pitt martin.p...@ubuntu.com wrote:
Robert Milasan [2013-12-17 12:44 +0100]:
I have this rule as a test, but doesn't do squat (meaning it doesnt
work) :)
ACTION==add, SUBSYSTEM==net, KERNEL==?*, ENV{test_device}=1
ACTION==remove, SUBSYSTEM==net, KERNEL==?*,
ENV{test_device}==1, RUN+=/bin/sh -c 'echo test_device
/tmp/test_device.log'
Drop the KERNEL== bits. Network devices don't have a /dev/... device
node in Linux, so KERNEL will never be set for those.
Martin
Even without the KERNEL== doesn't seem to work:
I'm testing this by first removing the network device (ex. rmmod
e1000), so I can have first an ADD event and then a REMOVE event, by
removing again the module, so:
rmmod e1000 (remove first)
modprobe e1000 (ADD event, set the test_device var to 1)
You miss MOVE event ... as was explained it does not import existing
environment by default ...
rmmod e1000 (REMOVE event, get the test_device value)
This doesn't seem to work, or at least it looks like that.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udev rules environment variable
В Tue, 17 Dec 2013 19:59:47 +0100
Kay Sievers k...@vrfy.org пишет:
Works just fine here as expected, it's probably something in your setup.
No, it *your* default interface renaming :)
Kay
# head -2 /etc/udev/rules.d/10-local.rules
ACTION==add, SUBSYSTEM==net, ENV{test_device}=1
ACTION==remove, SUBSYSTEM==net, ENV{test_device}==1,
RUN+=/bin/logger $env{test_device}
# udevadm monitor -p -u
# modprobe dummy
dummy is not renamed.
KERNEL[80247.266050] add /devices/pci:00/:00:03.0/net/eth0 (net)
ACTION=add
DEVPATH=/devices/pci:00/:00:03.0/net/eth0
IFINDEX=8
INTERFACE=eth0
SEQNUM=1448
SUBSYSTEM=net
KERNEL[80247.295702] move /devices/pci:00/:00:03.0/net/ens3 (net)
ACTION=move
DEVPATH=/devices/pci:00/:00:03.0/net/ens3
DEVPATH_OLD=/devices/pci:00/:00:03.0/net/eth0
IFINDEX=8
INTERFACE=ens3
SEQNUM=1452
SUBSYSTEM=net
UDEV [80256.247824] add /devices/pci:00/:00:03.0/net/ens3 (net)
ACTION=add
DEVPATH=/devices/pci:00/:00:03.0/net/ens3
ID_BUS=pci
...
INTERFACE=ens3
INTERFACE_OLD=eth0
SEQNUM=1448
...
test_device=1
UDEV [80256.274447] move /devices/pci:00/:00:03.0/net/ens3 (net)
ACTION=move
...
INTERFACE=ens3
SEQNUM=1452
...
TAGS=:systemd:
UDEV_LOG=7
Oops. test_device is lost.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is it possible to start other service units by a service unit which was killed?
В Tue, 17 Dec 2013 04:13:33 +0900 Tony Seo tonys...@gmail.com пишет: But I'm curious about fail from your answer, now. What is the fail signal in systemd? When process terminated unexpectedly with any exit status that does not mean normal exit. See SuccessExitStatus in man systemd.service. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is it possible to start other service units by a service unit which was killed
В Mon, 16 Dec 2013 02:26:02 +0900 Tony Seo tonys...@gmail.com пишет: Hello. I send this mail to know whether systemd have options to solve this problem without socket activation. what I have experienced situation is like: If I have A.service, B.service and C.service, I'd like to set [service] in A.service to make others started when A.service is exited(fail, exit .. are not important) For fail - see OnFailure (man systemd.unit). For clean exit I guess the only way is to call systemctl directly. Why would you want to do it in case of normal exit? May be there are other ways to achieve your goal? A.service-- [service] ExecStart=/bin/program Restart=always --?(I don't know that some options to start B.service and C.service) So, I have checked some options in [service] manual, but I have not detected some options to start other units when A.service was killed. I really want to know that systemd have methods or options to solve my problem without socket activation. Thanks ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: [Pkg-systemd-maintainers] Bug#732157: Want SIGSTOP-style daemon/service readiness notification
В Sun, 15 Dec 2013 23:23:54 +0100 Lennart Poettering lenn...@poettering.net пишет: This is really not how we should do it: the admin must be capable of tracing and pausing the boot process, and an init system should not make that impossible. What happens currently when service gets SIGSTOP? Does systemd ignore it? Will it reflect this information in service state? Actually, what state service *is* in this case (it obviously is not running but is not failed either ...)? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why doe I not see the logging with -u
В Sat, 14 Dec 2013 09:22:46 +0100 Cecil Westerhof cecil.wester...@snow.nl пишет: I made a first setup to make a service for the H2 database. I made the folowing service file: [Unit] Description=H2 Database [Service] Type=simple ExecStart=/usr/bin/java -cp /home/cecil/java/h2/bin/h2-1.3.174.jar org.h2.tools.Console -tool -tcp Restart=always User=cecil [Install] WantedBy=multi-user.target After starting and stopping I got with ‘journalctl -u h2’: ... Should I not see that with the first command, or am I overlooking something? Did you try journalctl -u h2.service? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why doe I not see the logging with -u
В Sat, 14 Dec 2013 10:19:45 +0100 Cecil Westerhof cecil.wester...@snow.nl пишет: On 12/14/2013 09:56 AM, Andrey Borzenkov wrote: I made a first setup to make a service for the H2 database. I made the folowing service file: [Unit] Description=H2 Database [Service] Type=simple ExecStart=/usr/bin/java -cp /home/cecil/java/h2/bin/h2-1.3.174.jar org.h2.tools.Console -tool -tcp Restart=always User=cecil [Install] WantedBy=multi-user.target After starting and stopping I got with ‘journalctl -u h2’: ... Should I not see that with the first command, or am I overlooking something? Did you try journalctl -u h2.service? I did not, but that should give the same result. I just tried it and it does give the same result. As user or as root? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] Initial libsystemd-asyncns commit
В Thu, 12 Dec 2013 14:09:42 +0100 Marcel Holtmann mar...@holtmann.org пишет: Hi Lennart, why do we have to spawn threads or do forks for DNS. This looks all pretty expensive. In ConnMan for example we just wrote our own async DNS using a mainloop. Works perfectly fine and is dirt cheap. Well, we don't fork threads/processes for each call but reuse them. What libasyncns does what your solution doesn't do is go via NSS. This means /etc/hosts, nss-myhostname, nss-ldap, nss-mdns and so on just work, while that all is lost when doing DNS natively. I am pretty sure we should not bypass NSS for this. actually NSS for DNS is pretty nasty stuff. I am pretty sure we should bypass it and create a proper implementation. Is anybody actually using NIS or LDAP for domain name resolution? Yes, there are solutions that are using LDAP for hostname resolution quite heavily - actually are based around LDAP without any local /etc/hosts. The problem with NSS is that it still does not fix the fundamental problem. It is sequential and blocking. You can spawn as many threads as you want and it will stay sequential. I fully agree with you that we need to consider /etc/hosts, the local hostname and also mDNS, but I get the feeling it would be more beneficial to just build that in. ConnMan ships a DNS proxy cache to actually be able to be smart and parallel. We did not bother with the details like /etc/hosts so far since our use cases always had an empty /etc/hosts with just localhost only anyway. However that is easy to fix. Spawning threads or forking is expensive (even if you reuse it) comparing to what you actually do here. You just want to resolve a host. It is especially expensive since you can not control on what is actually used. And there are clearly use cases where you have to ask a specific nameserver or set of nameservers. Regards Marcel ___ 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] install: Assume *.wants symlinks have the same name as their target for scalability.
В Wed, 11 Dec 2013 15:54:39 -0800 da...@davidstrauss.net пишет: From: David Strauss da...@davidstrauss.net --- src/shared/install.c | 5 + 1 file changed, 5 insertions(+) diff --git a/src/shared/install.c b/src/shared/install.c index 17e8a75..14c0f4b 100644 --- a/src/shared/install.c +++ b/src/shared/install.c @@ -423,6 +423,11 @@ static int find_symlinks_fd( bool found_path, found_dest, b = false; int q; +/* Skip symlinks with a different basename than + * the target unit */ +if (!streq(basename(de-d_name), name)) +continue; + This completely changes semantic of what it does. In this case no symlink is needed in the first place - just touch .../unit.wants/other.unit would be enough, as long as we assume units can only be located in standard config paths. /* Acquire symlink name */ p = path_make_absolute(de-d_name, path); if (!p) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] syslog makes impossible to enter emergency mode
В Wed, 11 Dec 2013 01:04:00 +0100 Lennart Poettering lenn...@poettering.net пишет: So, there has been a long standing TODO item regarding this: use RequisiteOverride=basic.target instead of Requires=basic.target for services by default. This would have the result that services can be started by the user without fulfilling basic.target, but causing it to fail if it is pulled in recursively. THis should fix your issue too, no? I expect, yes, it should. The change to make things work like this should be fairly easy in systemd, but so far I was always too lazy to test this in all detail to make sure it actually works (especially since the xyzOverridable stuff is little used and might not work entirely correct). Can I convince you to play around with this to see if this makes things work for you? Sure. Waiting for a patch :) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] udevadm settle takes too long to finish
В Mon, 9 Dec 2013 12:42:21 -0700 Chris Murphy li...@colorremedies.com пишет: On Dec 9, 2013, at 3:33 AM, Thomas Bächler tho...@archlinux.org wrote: Am 07.12.2013 22:29, schrieb Robert Milasan: From systemd-analyze dump: Wants: systemd-udevd.service WantedBy: lvm2-activation-early.service WantedBy: lvm2-activation.service Before: lvm2-activation-early.service Before: sysinit.target After: systemd-udev-trigger.service After: systemd-journald.socket References: systemd-udevd.service References: systemd-udev-trigger.service References: sysinit.target References: systemd-journald.socket ReferencedBy: lvm2-activation-early.service ReferencedBy: lvm2-activation.service What's the distribution you are using? Using udevadm settle for lvm is a waste of boot time and isn't even guaranteed to work (ask Lennart, Kay or Greg K-H for the full speech). It's a hackish workaround for LVM's inability to activate volumes automatically. I'm finding that plymouth-start.service uses ExecStartPost= to call udevadm settle twice. The actual culprit though is dmraid-activation.service which is enabled by default (why?) and Wants=systemd-udev-settle.service. dmraid.activation.service also has the #2 biggest blame hit: 4.551s dmraid-activation.service There is no such service on openSUSE, which OP has :) So why is this enabled by default when there's no dmraid at all, and never has been dmraid metadata on any attached device? The obvious question is - and how should system know it? Who is responsible for activating it again after you have added dmraid devices? Is it possible to trigger dmraid from some udev rule similar to what mdadm currently does? If I systemctl disable dmraid-activation.service both the dmraid-activation.service hit goes away, as does systemd-udev-settle.service. Chris Murphy ___ 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] How to use systemctl preset ?
В Mon, 9 Dec 2013 01:58:38 +0900 Tony Seo tonys...@gmail.com пишет: Hello. I have tried to use systemctl preset command. As you know that systemd.org already explained preset in manual page, So I read those things about preset and some example to use systemctl preset. http://www.freedesktop.org/software/systemd/man/systemd.preset.html But, when I try systemctl preset command, systemd print error like below. $systemctl preset Too few arguments.(error msg) It requires at least one unit name ... $ls 00-first.preset $systemctl preset 00-first.preset Failed to issue method call: Invalid argument(error msg) ... which must be unit name, not arbitrary file. I think I have been experiencing him who already sent a mail related with me. https://bugs.freedesktop.org/show_bug.cgi?id=64215 But I couldn't understand what Lennart said like below. * If you specify just test as parameter, then this would cause test.service to be reset to the preset default, but since test.service doesn't exist on your machine this fails.* i hope someone who shall explain how to apply systemctl preset to enable/disable many units at once. You need to list all units as arguments to systemctl preset. As I understand, that's intended more for packaging support where package can issue systemctl preset unit during installation to enable/disable unit according to local policy. So it is more remove policy knowledge from command than automate many units at once. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question about a udev rule
В Sun, 8 Dec 2013 19:14:17 +0100
Robert Milasan rmila...@suse.com пишет:
I've got this small rule which seems to not work at all:
ACTION!=add|change, GOTO=end_root_symlink
SUBSYSTEM!=block, GOTO=end_root_symlink
ENV{DEVTYPE}!=partition, GOTO=end_root_symlink
IMPORT{program}=/usr/bin/udevadm info --export --export-prefix=ROOT_
--device-id-of-file=/ ENV{MAJOR}!=0, ENV{MAJOR}==$env{ROOT_MAJOR},
^ is not comma missing here?
ENV{MINOR}==$env{ROOT_MINOR}, SYMLINK+=root
LABEL=end_root_symlink
Can anyone tell me what I'm doing wrong?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] script assigned via Unit's ExecStartPre= only partially executes, fails to complete ?
В Sun, 01 Dec 2013 00:10:36 -0800 jen...@promessage.com пишет: I cannot answer why iptables do not work, but general comment with the ExecStartPre= script, cat /usr/local/etc/openvpn/up.script #!/bin/sh /usr/local/sbin/openvpn --rmtun --dev tun1 /dev/null 21 There is no reason to lose valuable debugging information. All output is collected by systemd and is available via journal. Hiding it makes really no sense. /usr/sbin/iptables -I FORWARD -i eth0 -o tun1 -j ACCEPT iptables -L -v -n | grep tun 0 0 ACCEPT all -- eth0 tun10.0.0.0/0 0.0.0.0/0 journalctl shows the up.script launched, and the tun1 device is broight up, journalctl -xb | egrep -i up.script|tables Use journalctl -u openvpn.service, this will show *all* output associated with your unit start/stop. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] syslog makes impossible to enter emergency mode
В Tue, 26 Nov 2013 02:27:00 +0100
Lennart Poettering lenn...@poettering.net пишет:
On Tue, 26.11.13 01:00, Lennart Poettering (lenn...@poettering.net) wrote:
On Sun, 24.11.13 22:36, Andrey Borzenkov (arvidj...@gmail.com) wrote:
Interesting case (https://bugzilla.novell.com/show_bug.cgi?id=852021).
Systemd enters emergency due to failed mount. At the same time syslog
socket triggers syslog.service. Due to implicit Requires on
basic.target which Requires sysinit.target which conflicts with
emergency.{service,target} syslog.service tries to start basic.target
(it is not there yet ...) which apparently kills emergency shell.
This was probably introduced by
80cfe9e163b1c92f917e0a5e053b148fca790677.
I figure we should find something in the middle of
OnActivationIsolate=yes and OnActivationIsolate=no. i.e. make use of
the replace-irreversible job mode which will allow the emergency jobs
to be queued without being reversible by later requests until they are
finished or explicitly flushed out with systemctl cancel.
I figure I'll replace OnActivationIsolate=yes by OnActivationMode= which
takes the full range of job modes, and then turn OnActiveIsolate= into a
hidden compat switch
Done.
Lennart
Does not work. Quoting man page: creates jobs that cannot be reversed
UNLESS THEY FINISHED or are explicitly canceled. This is exactly what
happens here - emergency.target job is already finished, then syslog
kicks in and tries to starts basic.target = sysinit.target which kills
emergency service.
Nov 30 09:48:57 linux-cor4 systemd[1]: Dependency failed for Local File Systems.
Nov 30 09:48:57 linux-cor4 systemd[1]: Triggering OnFailure= dependencies of
local-fs.target.
Nov 30 09:48:57 linux-cor4 systemd[1]: Trying to enqueue job
emergency.target/start/replace-irreversibly
...
Nov 30 09:48:58 linux-cor4 systemd[1]: Job emergency.service/start finished,
result=done
Nov 30 09:48:58 linux-cor4 systemd[1]: Started Emergency Shell.
Nov 30 09:48:58 linux-cor4 systemd[1]: Starting Emergency Mode.
Nov 30 09:48:58 linux-cor4 systemd[1]: emergency.target changed dead - active
Nov 30 09:48:58 linux-cor4 systemd[1]: Job emergency.target/start finished,
result=done
Nov 30 09:48:58 linux-cor4 systemd[1]: Reached target Emergency Mode.
...
Nov 30 09:48:58 linux-cor4 systemd[1]: Incoming traffic on syslog.socket
Nov 30 09:48:58 linux-cor4 systemd[1]: Trying to enqueue job
rsyslog.service/start/replace
...
Nov 30 09:48:58 linux-cor4 systemd[1]: Installed new job emergency.service/stop
as 192
Nov 30 09:48:58 linux-cor4 systemd[1]: Installed new job emergency.target/stop
as 193
This is obvious race condition - some people reported success some -
not. I can reliably reproduce failure :)
And it does not look like using isolate would actually change anything
here ... we'd be in the same situation.
Short term solution is to make emergency.service conflict with
sysylog.socket, but this potentially can be triggered by any other
socket so it obviously does not scale.
So to repeat the question - should not *default* service dependency be
Requisite instead of Requires?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] syslog makes impossible to enter emergency mode
Interesting case (https://bugzilla.novell.com/show_bug.cgi?id=852021).
Systemd enters emergency due to failed mount. At the same time syslog
socket triggers syslog.service. Due to implicit Requires on
basic.target which Requires sysinit.target which conflicts with
emergency.{service,target} syslog.service tries to start basic.target
(it is not there yet ...) which apparently kills emergency shell.
I wonder if default service dependency should not be Requisite instead
of Requires. After all, if we are not past basic.target, there should
be really good reason for it and attempting to start it implicitly does
not look the right thing to do.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-bugs] Russian translation for systemd
В Thu, 14 Nov 2013 21:10:26 +0600 Alexander E. Patrakov patra...@gmail.com пишет: +#: ../src/hostname/org.freedesktop.hostname1.policy.in.h:4 +msgid +Authentication is required to set the statically configured local host name, +as well as the pretty host name. +msgstr +Для настройки статического имени локального узла, а также чудесного +имени вашей машины, требуется авторизация. I honestly do not like имя узла (node name) as translation for host name. Node has rather different semantic. And you should chose either node name or machine name but do not use them interchangeably. Host name is pretty much an idiom, not descriptive text. I would rather prefer имя системы (system name) in this case. I have never seen pretty translated as чудесный in such context (where the meaning is descriptive, meaningful). Could you please show some prior art? Whatever it is, it is not Miraculous :) In this context it means free form system description (comment). Russian equivalent would be Описание компьютера or Описание системы (system description), depending on how host name is translated to be consistent. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Need help with a systemd/mdadm interaction.
В Tue, 12 Nov 2013 21:17:19 +1100
NeilBrown ne...@suse.de пишет:
On Tue, 12 Nov 2013 18:16:24 +0900 Greg KH gre...@linuxfoundation.org wrote:
On Tue, Nov 12, 2013 at 07:54:42PM +1100, NeilBrown wrote:
On Tue, 12 Nov 2013 00:10:28 -0800 Greg KH gre...@linuxfoundation.org
wrote:
On Tue, Nov 12, 2013 at 11:31:45AM +1100, NeilBrown wrote:
Alternately, is there some all devices have been probed, nothing new
will
appear unless it is hot-plugged event. That would be equally useful
(and
probably mirrors what hardware-RAID cards do).
No, there's no way to ever know this in a hotplug world, sorry.
Especially with USB devices, they show up when they show up, there's no
oh look, the bus is all scanned now and all devices currently plugged
in are found type knowledge at all.
Then there are hotplug PCI systems where people slam in PCI cards
whenever they feel like it (remember, thunderbolt is PCI express...)
Sorry,
greg k-h
Surely something must be possible.
For USB, nope, there isn't, sorry.
Clearly a physical hot-plug event will cause more devices to appear, but
there must come a point at which no more (non-virtual) devices will appear
unless a physical event happens?
Not for USB, sorry.
The USB bus just announces devices when it finds them, there is no all
is quiet type signal or detection.
Same for PCI hotplug, devices can show up at any point in time, you
never know when, and you don't know when all devices are found.
sorry,
greg k-h
Hmmm... OK. USB doesn't bother me a lot, but PCI is important.
I guess I'll just have to settle for a timeout much like the current
device-discovery timeout that systemd has.
Still hoping someone can tell me how to plug into that though...
If information about array name or other identification is available in
udev rule (I see reference to device node only) what you can do is to
start timer with now+5second (pick your timeout) that simply fires off
mdadm -IRs for specific array. Something like
mdadm-last-resort@.timer
[Timer]
OnCalendar=+5s
mdadm-last-resort@.service
[Service]
Type=oneshot
ExecStart=/sbin/mdadm -IRs %n
udev rule
... SYSTEMD_WANTS=mdadm-last-resort@$ENV{SOMETHING_UNIQUE}.timer
signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
