Re: [systemd-devel] Regarding the
'Twas brillig, and abhishek sharma at 30/09/13 05:16 did gyre and gimble: Is there any service in the existing standard distribution, where I can get hands on these parameters ExecStartPre, ExecStart, ExecStartPost, ExecReload, ExecStop, ExecStop, ExecMainCode, signal result and ExecMainStatus under Service Unit Objects.? I'm not aware of standard services that use all of these because they exist to cover various edge cases that are quite frequently unneeded in a typical setup. Unfortunately not all the services implements these parameters, I searched many but could not find. I am currently using fedora 19 and want to get hands on these things to have better understanding. Your best opertunity to understand these is to create some dummy units of your own and play around with them. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Make upstart compatibility optional
On Sun, Sep 29, 2013 at 11:18:52PM -0300, Cristian Rodríguez wrote:
El 29/09/13 15:11, Lennart Poettering escribió:
On Fri, 27.09.13 23:04, Kay Sievers (k...@vrfy.org) wrote:
On Fri, Sep 27, 2013 at 9:24 PM, Cristian Rodríguez
crrodrig...@opensuse.org wrote:
Distributions such as openSUSE and probably others never included
upstart, in that case there is no need to include this code.
This introduces --disable-upstartcompat, however upstart compat is still
enabled by default.
I think we should just remove it, and leave it to people who actually
need it to patch it back in, I doubt there are any left, really.
I agree. We can't test this anyway anymore. I'd be happy to merge a
patch that removes any Upstart compat support.
Lennart
OK, here we go...patch attached..
What about removing the TELINIT define in configure.ac and the
associated machinery in systemctl.c? You'd need to fabricate a new error
message for when systemd isn't running and systemctl is called as the
name init.
I also notice there's a comment in src/shared/utmp-wtmp.c that mentions
upstart, but it's actually incorrect: sysvinit uses PREVLEVEL as well.
d
--
If debugging is the process of removing bugs, then programming must be
the process of putting them in. - Edsger Dijkstra
From c6040aaa4914123774295336a51f0630f7903586 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cristian=20Rodr=C3=ADguez?= crrodrig...@opensuse.org
Date: Sun, 29 Sep 2013 23:17:42 -0300
Subject: [PATCH] remove legacy upstart compatibility
---
src/systemctl/systemctl.c | 93
---
1 file changed, 93 deletions(-)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index eede616..bb7ada9 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -5678,94 +5678,6 @@ _pure_ static int action_to_runlevel(void) {
return table[arg_action];
}
-static int talk_upstart(void) {
-_cleanup_dbus_message_unref_ DBusMessage *m = NULL, *reply = NULL;
-_cleanup_dbus_error_free_ DBusError error;
-int previous, rl, r;
-char
-env1_buf[] = RUNLEVEL=X,
-env2_buf[] = PREVLEVEL=X;
-char *env1 = env1_buf, *env2 = env2_buf;
-const char *emit = runlevel;
-dbus_bool_t b_false = FALSE;
-DBusMessageIter iter, sub;
-DBusConnection *bus;
-
-dbus_error_init(error);
-
-if (!(rl = action_to_runlevel()))
-return 0;
-
-if (utmp_get_runlevel(previous, NULL) 0)
-previous = 'N';
-
-if (!(bus =
dbus_connection_open_private(unix:abstract=/com/ubuntu/upstart, error))) {
-if (dbus_error_has_name(error, DBUS_ERROR_NO_SERVER)) {
-r = 0;
-goto finish;
-}
-
-log_error(Failed to connect to Upstart bus: %s,
bus_error_message(error));
-r = -EIO;
-goto finish;
-}
-
-if ((r = bus_check_peercred(bus)) 0) {
-log_error(Failed to verify owner of bus.);
-goto finish;
-}
-
-if (!(m = dbus_message_new_method_call(
- com.ubuntu.Upstart,
- /com/ubuntu/Upstart,
- com.ubuntu.Upstart0_6,
- EmitEvent))) {
-
-log_error(Could not allocate message.);
-r = -ENOMEM;
-goto finish;
-}
-
-dbus_message_iter_init_append(m, iter);
-
-env1_buf[sizeof(env1_buf)-2] = rl;
-env2_buf[sizeof(env2_buf)-2] = previous;
-
-if (!dbus_message_iter_append_basic(iter, DBUS_TYPE_STRING, emit)
||
-!dbus_message_iter_open_container(iter, DBUS_TYPE_ARRAY, s,
sub) ||
-!dbus_message_iter_append_basic(sub, DBUS_TYPE_STRING, env1) ||
-!dbus_message_iter_append_basic(sub, DBUS_TYPE_STRING, env2) ||
-!dbus_message_iter_close_container(iter, sub) ||
-!dbus_message_iter_append_basic(iter, DBUS_TYPE_BOOLEAN,
b_false)) {
-log_error(Could not append arguments to message.);
-r = -ENOMEM;
-goto finish;
-}
-
-if (!(reply = dbus_connection_send_with_reply_and_block(bus, m, -1,
error))) {
-
-if (bus_error_is_no_service(error)) {
-r = -EADDRNOTAVAIL;
-goto finish;
-}
-
-log_error(Failed to issue method call: %s,
bus_error_message(error));
-r = -EIO;
-goto finish;
-}
-
-r = 1;
-
-finish:
-if (bus) {
-dbus_connection_flush(bus);
-dbus_connection_close(bus);
-
[systemd-devel] What is the best way to run a shell script through 'ExecStart'
Greetings all, I have been trying to convert a LSB initscript of a package into corresponding systemd service file. Most init scripts are simple and translating them into systemd unit files is non-trivial. In this case it is a relatively long script involving some loops. 1) Should I write a script file separately and then call it through 'ExecStart'? or 2) It would be good (and do-able) idea to fit whole script inside ExecStart=/bin/sh -c script? (If yes, I would prefer it as it will free me from hassle of maintaining two files) If 2) seems appropriate, can anyone please share something which involves using of loop inside systemd service file? Thanks, Shakeel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What is the best way to run a shell script through 'ExecStart'
Hi Muhammad, On Mon, Sep 30, 2013 at 3:25 PM, Muhammad Shakeel muhammad_shak...@mentor.com wrote: I have been trying to convert a LSB initscript of a package into corresponding systemd service fyile. Most init scripts are simple and translating them into systemd unit files is non-trivial. In this case it is a relatively long script involving some loops. 1) Should I write a script file separately and then call it through 'ExecStart'? or 2) It would be good (and do-able) idea to fit whole script inside ExecStart=/bin/sh -c script? (If yes, I would prefer it as it will free me from hassle of maintaining two files) If you need something non-trivial (such as loops or a script over more than a couple of lines), then I suggest keeping it in a separate file. Systemd service files intentionally do not support loops (or other control structures). HTH, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd remounts root fs read-only, doesn't detect lxc-libvirt
Am 29.09.2013 22:06, schrieb Florian Klink: Am 29.09.2013 21:59, schrieb Lennart Poettering: On Sat, 28.09.13 16:35, Florian Klink (flo...@flokli.de) wrote: Hi, I setup some freshly-bootstrapped Arch Linux containers using systemd 204 (so only systemd inside, no old init systems) They are started using libvirt-lxc. The root of the container filesystem is a mountpoint (in my case, aufs filesystem, to save some space and use base images, but this is also reproducible with a loop ext filesystem mounted on the root location). /dev/loop0 /var/lib/libvirt/filesystems/test/root ext4 rw,relatime,data=ordered 0 0 According to src/core/umount.c, the remount,ro of / should not occur when systemd is started inside a container environment. However, after starting up, then shutting down the container, the filesystem is mounted ro. /dev/loop0 /var/lib/libvirt/filesystems/test/root ext4 ro,relatime,data=ordered 0 0 So probably systemd is not detecting here correctly that it's running inside the container, although lxc-libvirt as env for pid 1 seems to be supported inside detect_container(). So something is apparently wrong here. Is there any way to find out why it is remounting ro? Maybe you have listed it as such in the fstab of the container? Does systemd-detect-virt in the container detect libvirt-lxc correcty? Lennart yes, it says libvirt-lxc. fstab inside the container is empty. Florian I did the bootstrap of the container fs again, now systemd-207-5 is installed. With this, the problem magically disappears, container fs stays mounted rw. But still thanks for your help! Florian ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What is the best way to run a shell script through 'ExecStart'
Am 30.09.2013 15:31, schrieb Tom Gundersen:
On Mon, Sep 30, 2013 at 3:25 PM, Muhammad Shakeel
muhammad_shak...@mentor.com wrote:
I have been trying to convert a LSB initscript of a package into
corresponding systemd service fyile. Most init scripts are simple and
translating them into systemd unit files is non-trivial. In this case it is
a relatively long script involving some loops.
1) Should I write a script file separately and then call it through
'ExecStart'?
or
2) It would be good (and do-able) idea to fit whole script inside
ExecStart=/bin/sh -c script? (If yes, I would prefer it as it will free
me from hassle of maintaining two files)
If you need something non-trivial (such as loops or a script over more
than a couple of lines), then I suggest keeping it in a separate file.
Systemd service files intentionally do not support loops (or other
control structures)
i tend to use PHP for most things because re-use of internal libraries
and a simple endless loop with type=simple does it's job
#!/usr/bin/php
while(1 == 1)
{
}
___
cat /etc/systemd/system/monitor-dbmail-imapd.service
[Unit]
Description=monitor dbmail-imapd
After=dbmail-imapd.service
[Service]
Type=simple
ExecStart=/usr/local/bin/check-dbmail-service.php 143 dbmail-imapd
Restart=always
RestartSec=1
TimeoutSec=1
Nice=19
IOSchedulingClass=3
User=dbmail
Group=dbmail
PrivateTmp=true
NoNewPrivileges=yes
CapabilityBoundingSet=CAP_KILL
ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr
ReadOnlyDirectories=/proc
ReadOnlyDirectories=/sys
InaccessibleDirectories=/boot
InaccessibleDirectories=/home
InaccessibleDirectories=/var/lib/rpm
InaccessibleDirectories=/var/lib/yum
InaccessibleDirectories=/var/spool
[Install]
WantedBy=multi-user.target
___
cat /usr/local/bin/check-dbmail-service.php
#!/usr/bin/php
?php
/** make sure we are running as shell-script */
if(PHP_SAPI != 'cli')
{
exit('FORBIDDEN');
}
/** verify that port and binary-name are given */
if(empty($_SERVER['argv'][1]) || empty($_SERVER['argv'][2]))
{
exit('USAGE: check-dbmail-service port process-name' . \n);
}
/** service loop */
while(1 == 1)
{
if(!check_service())
{
sleep(5);
if(!check_service())
{
passthru('/usr/bin/killall -s SIGTERM ' .
escapeshellarg($_SERVER['argv'][2]));
usleep(75);
passthru('/usr/bin/killall -s SIGKILL ' .
escapeshellarg($_SERVER['argv'][2]));
}
}
sleep(30);
}
/**
* check if service is available and responds
*
* @access public
* @return boolean
*/
function check_service()
{
$errno = 0;
$errstr = '';
$fp = @fsockopen('tcp://127.0.0.1', $_SERVER['argv'][1], $errno, $errstr, 5);
if($fp)
{
$response = @fgets($fp, 128);
@fclose($fp);
if(!empty($response))
{
return true;
}
else
{
return false;
}
}
else
{
return false;
}
}
?
signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Renaming network interfaces: device or resource busy
Hi, Just trying to debug the problem mentioned in the subject. I'm wanting to use the new device names in stage 2 of our installer (some closing config routines write the interface name into some conf files etc), but when udev rules kick in, the device is already up and in use... is there any way to work out what is using it and preventing the rename? I would guess fuser or netstat but not quite sure what to look for. Simply running netstat only shows unix sockets, no tcp/udp ones... Any help appreciated. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Renaming network interfaces: device or resource busy
Am 30.09.2013 17:14, schrieb Colin Guthrie: Hi, Just trying to debug the problem mentioned in the subject. I'm wanting to use the new device names in stage 2 of our installer (some closing config routines write the interface name into some conf files etc), but when udev rules kick in, the device is already up and in use... is there any way to work out what is using it and preventing the rename? I would guess fuser or netstat but not quite sure what to look for. Simply running netstat only shows unix sockets, no tcp/udp ones... Any help appreciated. Any application that listens on netlink for new network interfaces may start using the interface before udev has finished processing the uevent. IMO, this needs to be fixed in the kernel and udev, so that udev can have a chance to finish its uevent processing before the interface is announced via netlink. As far as I know, no work in that direction has been done. We had such a problem when running dhcpcd without an interface argument: Depending on whether udev or dhcpcd was faster, interface renaming would succeed or fail. We are now working around this issue ([1]), but I don't particularly like that solution. [1] https://projects.archlinux.org/archiso.git/commit/?id=7d14796716939fbabb9daba6b6f5294016d63cd4 signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Renaming network interfaces: device or resource busy
'Twas brillig, and Thomas Bächler at 30/09/13 16:42 did gyre and gimble: Am 30.09.2013 17:14, schrieb Colin Guthrie: Hi, Just trying to debug the problem mentioned in the subject. I'm wanting to use the new device names in stage 2 of our installer (some closing config routines write the interface name into some conf files etc), but when udev rules kick in, the device is already up and in use... is there any way to work out what is using it and preventing the rename? I would guess fuser or netstat but not quite sure what to look for. Simply running netstat only shows unix sockets, no tcp/udp ones... Any help appreciated. Any application that listens on netlink for new network interfaces may start using the interface before udev has finished processing the uevent. IMO, this needs to be fixed in the kernel and udev, so that udev can have a chance to finish its uevent processing before the interface is announced via netlink. As far as I know, no work in that direction has been done. We had such a problem when running dhcpcd without an interface argument: Depending on whether udev or dhcpcd was faster, interface renaming would succeed or fail. We are now working around this issue ([1]), but I don't particularly like that solution. So by the time udev kicks in dhcp has been an gone but the interface is up. It seems doing a ifconfig eth0 down, udevadm trigger, ifconfig enp0s3 up, and redoing the routes and everything works OK with the new name. Seems I need to either convert our stage1 to udev and get the renaming done earlier or do some kind of network routine around when udev starts to do the above manual steps... ugg! Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [HEADS-UP] systemd hackfest at FOSDEM 2014/Brussels or devconf.cz 2014/Brno?
Heya! We are looking into organizing another systemd Hackfest early next year, either co-located with FOSDEM 2014 in Brussels (Feb. 1+2) or with devconf.cz 2014 in Brno (Feb 7-9). Now, we have the suspcicion that more people might be willing to attend if we host it at FOSDEM, but it would be easier to organize it in Brno. Hence, we'd like to have some more clarity on this. Please let me know (quickly!) if you'd be interested to attend if it happens in Brussels but wouldn't attend in Brno (or vice versa!). Thank you! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Randomly on shutdown, stop timeout for user at .service (repeated report, different user)
It appears that history repeats itself. Once (July 2013) a similar issue was reported here, by different user: http://lists.freedesktop.org/archives/systemd-devel/2013-July/012283.html I'm also using Arch Linux, systemd-207, linux-3.11.2. On shutdown and reboot, user@0.service occasionally freezes my system until it times out and gets killed. Steps to reproduce: 1) Boot 2) Login 3) Execute either systemctl reboot or reboot or shutdown -h now or whatever. I've went through the steps here, to get a proper shutdown log: http://freedesktop.org/wiki/Software/systemd/Debugging/#shutdowncompleteseventually And, the shutdown log can be found here: http://pastebin.com/wbr04AQw The actual lines related to issue: #2223 [ 74.387130] systemd[1]: Got D-Bus request: org.freedesktop.DBus.Local.Disconnected() on /org/freedesktop/DBus/Local #2224 [ 163.814925] systemd[1]: user@0.service stopping timed out. Killing. #2225 [ 163.815447] systemd[1]: user@0.service changed stop-sigterm - stop-sigkill #2226 [ 163.816063] systemd[1]: Received SIGCHLD from PID 326 (systemd). #2227 [ 163.816093] systemd[1]: Got SIGCHLD for process 326 (systemd) #2228 [ 163.816153] systemd[1]: Child 326 died (code=killed, status=9/KILL) #2229 [ 163.816158] systemd[1]: Child 326 belongs to user@0.service #2230 [ 163.816171] systemd[1]: user@0.service: main process exited, code=killed, status=9/KILL #2231 [ 163.816183] systemd[1]: user@0.service changed stop-sigkill - failed I currently haven't found out a pattern for this. I have attempted to quit some processes before initiating the shutdown/reboot, but the result is random. About 95% of shutdowns/reboots it will be a long one. 3% it will be noticeably longer than the quickest one, but shorter than the above one. Remaining 2%, the shutdown will be very quick. It also happens if I get to log in console screen and Ctrl + Alt + Del, like, I perform an ASAP shutdown after boot. In case anything more is needed, please ask. -- Toms Seisums - (+371) 26431391 May the force be with you, always! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [HEADSUP] cgroup rework documentation
Heya! We had been missing useful documentation on the new cgroup APIs that are supposed to replace the direct cgroupfs access of old. I closed that gap now: http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ It's terse but should be fairly comprehensive. Light on examples unfortunately, but hey, we at least link to useful source code... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Randomly on shutdown, stop timeout for user at .service (repeated report, different user)
В Mon, 30 Sep 2013 18:55:14 +0300 Toms Seisums toms.seis...@gmail.com пишет: It appears that history repeats itself. Once (July 2013) a similar issue was reported here, by different user: http://lists.freedesktop.org/archives/systemd-devel/2013-July/012283.html I'm also using Arch Linux, systemd-207, linux-3.11.2. On shutdown and reboot, user@0.service occasionally freezes my system until it times out and gets killed. Steps to reproduce: 1) Boot 2) Login 3) Execute either systemctl reboot or reboot or shutdown -h now or whatever. I've went through the steps here, to get a proper shutdown log: http://freedesktop.org/wiki/Software/systemd/Debugging/#shutdowncompleteseventually And, the shutdown log can be found here: http://pastebin.com/wbr04AQw The actual lines related to issue: #2223 [ 74.387130] systemd[1]: Got D-Bus request: org.freedesktop.DBus.Local.Disconnected() on /org/freedesktop/DBus/Local #2224 [ 163.814925] systemd[1]: user@0.service stopping timed out. Killing. Full log would be interesting. As far as I can tell, SIGRTMIN+24 used to terminate user instance is either lost or ignored. But I could never reproduce it while using any form of debugging. https://bugzilla.novell.com/show_bug.cgi?id=841544 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Fwd: Journalctl performance
On Wed, Sep 25, 2013 at 8:44 AM, Frederic Crozat fcro...@suse.com wrote: Le mercredi 25 septembre 2013 à 12:10 +0100, Colin Guthrie a écrit : Hi, On a relatively average journal it can take a long time to page through all the data collected. With data stored from 5th August to 25th September and running journalctl and pressing G to jump to the end in less, and it takes several minutes before the end of the messages are reached with journalctl taking 100% CPU for most of that time. This is on a slightly older systemd (approximately similar to the 195 version used in Suse - i.e. a shitton of backported patches!) but even on my regular-use laptop (with SSD) and logs dating back to Jun 18th it takes ~1m 30s to do the same. This is ultimately with something approximating 2.5m lines of output to be paged through (systemd debugging is on!) With this kind of performance, it's kinda a hard sell, although I'm not really sure if I should *expect* any better performance and I appreciate that listing specific date ranges or particular services can reduce the amont of data returned and thus speed things up dramitcally. So I guess my question is is it basically unrealistic to expect better performance from a simple just output everything operation like this? Sadly this is exactly the type of operation a typical user who is used to syslog would do with journalctl and thus don't see the beneifts. Any thoughts on this? HDD (systemd 195+patches): [root@marley ~]# du -sh /var/log/journal/ 1.5G /var/log/journal/ [root@marley ~]# date; journalctl | wc -l; date Wed 25 Sep 11:39:00 BST 2013 1957295 Wed 25 Sep 11:42:16 BST 2013 SSD (systemd 207): [root@jimmy ~]# du -sh /var/log/journal/ 2.0G /var/log/journal/ [root@jimmy ~]# date; journalctl | wc -l; date Wed 25 Sep 11:40:18 BST 2013 2391076 Wed 25 Sep 11:42:10 BST 2013 And just for some plain text comparisions on the older, HDD machine: [root@marley ~]# date; journalctl /home/journal; date Wed 25 Sep 11:50:41 BST 2013 Wed 25 Sep 11:53:59 BST 2013 [root@marley ~]# wc -l /home/journal 1957527 /home/journal [root@marley ~]# date; cat /home/journal /dev/null; date Wed 25 Sep 11:54:49 BST 2013 Wed 25 Sep 11:54:50 BST 2013 [root@marley ~]# date; cat /home/journal | gzip /home/journal.gz; date Wed 25 Sep 11:55:23 BST 2013 Wed 25 Sep 11:55:28 BST 2013 [root@marley ~]# date; zcat /home/journal.gz /dev/null; date Wed 25 Sep 11:55:50 BST 2013 Wed 25 Sep 11:55:51 BST 2013 [root@marley ~]# date; cat /home/journal | xz /home/journal.xz; date Wed 25 Sep 11:56:15 BST 2013 Wed 25 Sep 11:58:12 BST 2013 [root@marley ~]# date; xzcat /home/journal.xz /dev/null; date Wed 25 Sep 12:01:25 BST 2013 Wed 25 Sep 12:01:27 BST 2013 [root@marley ~]# ls -lh /home/journal* -rw-r--r-- 1 root root 244M Sep 25 11:53 /home/journal -rw-r--r-- 1 root root 17M Sep 25 11:55 /home/journal.gz -rw-r--r-- 1 root root 9.8M Sep 25 11:58 /home/journal.xz So, 2 seconds to page through 9.8M of compressed data directly with log files, or ~2 minutes, 30 seconds to page through 1.5GB of journal based logs to produce the same result (and I know the files here will be hot in terms of cache etc which gives them a slightly unfair advantage, but this would factor into real world usage too) Now, of course I do know that in the journalctl case, there is both more to look at, perhaps some old journals that are ultimately analysed at but never used because they are corrupt or something, and a whole bunch of other data that is not synthesizable to the journalctl syslog-style output, but forgetting features and looking at raw numbers and, as I said above, it's a hard sell on the surface! Is there something wrong here? Are my numbers unrealistic? Is this pointing at a larger problem with my setup/usage? I'm seeing similar bad numbers on openSUSE, but I recently noticed an owner difference between some journal files (since journal files moved from adm to systemd-journal group) and I'm wondering if it wasn't breaking cleanup / rotation of old journal entries (I haven't investigated much :( -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel I've been seeing similar performance issues with the journal for several recent versions of systemd (at least from v204 through v207 on Arch Linux). I have journal logs from 2012-10-20 through today that contain 1,268,128 lines. I just ran journalctl with less as the pager, pressed G, and it took 5.5 minutes to get all the way to the bottom. journalctl used lots of CPU throughout and regularly went to 99% CPU utilization. This is on a 3.5 year old laptop with a Core i5 M 430 and a 5,400 RPM hard drive. Jason ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org
Re: [systemd-devel] [HEADS-UP] systemd hackfest at FOSDEM 2014/Brussels or devconf.cz 2014/Brno?
On Mon, Sep 30, 2013 at 05:52:32PM +0200, Lennart Poettering wrote: We are looking into organizing another systemd Hackfest early next year, either co-located with FOSDEM 2014 in Brussels (Feb. 1+2) or with devconf.cz 2014 in Brno (Feb 7-9). Now, we have the suspcicion that more people might be willing to attend if we host it at FOSDEM, but it would be easier to organize it in Brno. Hence, we'd like to have some more clarity on this. Please let me know (quickly!) if you'd be interested to attend if it happens in Brussels but wouldn't attend in Brno (or vice versa!). We would prefer FOSDEM. rsc -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] systemd hackfest at FOSDEM 2014/Brussels or devconf.cz 2014/Brno?
On Monday 2013-09-30 17:52, Lennart Poettering wrote: We are looking into organizing another systemd Hackfest early next year, either co-located with FOSDEM 2014 in Brussels (Feb. 1+2) or with devconf.cz 2014 in Brno (Feb 7-9). Now, we have the suspcicion that more people might be willing to attend if we host it at FOSDEM, but it would be easier to organize it in Brno. if it so turned out that the hackfest does not strike my nerve, I could still go to FOSDEM in a blink. But devconf.cz, I would not know what to expect (in terms of talks - the 2013 schedule has already been nuked it seems). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] systemd hackfest at FOSDEM 2014/Brussels or devconf.cz 2014/Brno?
I would strongly prefer Brussels for travel reasons. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADS-UP] systemd hackfest at FOSDEM 2014/Brussels or devconf.cz 2014/Brno?
2013/9/30 Lennart Poettering lenn...@poettering.net: We are looking into organizing another systemd Hackfest early next year, either co-located with FOSDEM 2014 in Brussels (Feb. 1+2) or with devconf.cz 2014 in Brno (Feb 7-9). Now, we have the suspcicion that more people might be willing to attend if we host it at FOSDEM, but it would be easier to organize it in Brno. Hence, we'd like to have some more clarity on this. Please let me know (quickly!) if you'd be interested to attend if it happens in Brussels but wouldn't attend in Brno (or vice versa!). I will most likely be in Brussels for FOSDEM in any case, and I don't think I will be able to travel again just one week later. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Renaming network interfaces: device or resource busy
On Mon, 30.09.13 16:14, Colin Guthrie (gm...@colin.guthr.ie) wrote: Hi, Just trying to debug the problem mentioned in the subject. I'm wanting to use the new device names in stage 2 of our installer (some closing config routines write the interface name into some conf files etc), but when udev rules kick in, the device is already up and in use... is there any way to work out what is using it and preventing the rename? Hmm, what software do you use that configures the network interfaces? Software really needs to be fixed to ignore devices that have not been reported as initialized by udev. They are welcome to watch netlink but never exclusively, they must ignore netlink traffic for devices that have not been configured with udev yet. The renaming of the iface is blocked by by the iface being up, that's all. If you figure out which software is responsible for upping the iface, you know your culprit. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Renaming network interfaces: device or resource busy
On Mon, 30.09.13 17:42, Thomas Bächler (tho...@archlinux.org) wrote: Any application that listens on netlink for new network interfaces may start using the interface before udev has finished processing the uevent. IMO, this needs to be fixed in the kernel and udev, so that udev can have a chance to finish its uevent processing before the interface is announced via netlink. As far as I know, no work in that direction has been done. No, applications should not pick up network devices before udev announced them. They should ignore netlink traffic before that. NetworkManager actually gets that right... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] smack-setup: fix path to Smack/CIPSO mappings
The correct path to the dir with CIPSO mappings is /etc/smack/cipso.d/; /etc/smack/cipso is a file that can include these mappings as well, though it is no longer supported in upstream libsmack. --- src/core/smack-setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/core/smack-setup.c b/src/core/smack-setup.c index d67a84a..1434dea 100644 --- a/src/core/smack-setup.c +++ b/src/core/smack-setup.c @@ -40,7 +40,7 @@ #include label.h #define SMACK_CONFIG /etc/smack/accesses.d/ -#define CIPSO_CONFIG /etc/smack/cipso/ +#define CIPSO_CONFIG /etc/smack/cipso.d/ #ifdef HAVE_SMACK -- 1.8.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Randomly on shutdown, stop timeout for user at .service (repeated report, different user)
On Mon, 30.09.13 18:55, Toms Seisums (toms.seis...@gmail.com) wrote: It appears that history repeats itself. Once (July 2013) a similar issue was reported here, by different user: http://lists.freedesktop.org/archives/systemd-devel/2013-July/012283.html I'm also using Arch Linux, systemd-207, linux-3.11.2. On shutdown and reboot, user@0.service occasionally freezes my system until it times out and gets killed. Steps to reproduce: 1) Boot 2) Login 3) Execute either systemctl reboot or reboot or shutdown -h now or whatever. I've went through the steps here, to get a proper shutdown log: http://freedesktop.org/wiki/Software/systemd/Debugging/#shutdowncompleteseventually And, the shutdown log can be found here: http://pastebin.com/wbr04AQw The actual lines related to issue: #2223 [ 74.387130] systemd[1]: Got D-Bus request: org.freedesktop.DBus.Local.Disconnected() on /org/freedesktop/DBus/Local #2224 [ 163.814925] systemd[1]: user@0.service stopping timed out. Killing. #2225 [ 163.815447] systemd[1]: user@0.service changed stop-sigterm - stop-sigkill #2226 [ 163.816063] systemd[1]: Received SIGCHLD from PID 326 (systemd). #2227 [ 163.816093] systemd[1]: Got SIGCHLD for process 326 (systemd) #2228 [ 163.816153] systemd[1]: Child 326 died (code=killed, status=9/KILL) #2229 [ 163.816158] systemd[1]: Child 326 belongs to user@0.service #2230 [ 163.816171] systemd[1]: user@0.service: main process exited, code=killed, status=9/KILL #2231 [ 163.816183] systemd[1]: user@0.service changed stop-sigkill - failed I currently haven't found out a pattern for this. I have attempted to quit some processes before initiating the shutdown/reboot, but the result is random. About 95% of shutdowns/reboots it will be a long one. 3% it will be noticeably longer than the quickest one, but shorter than the above one. Remaining 2%, the shutdown will be very quick. Hmm, this is the systemd user instance for root which fails to shut down. Can you reproduce this if you start/stop user@0.service quickly in a loop? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] smack-setup: fix path to Smack/CIPSO mappings
On Mon, 30.09.13 17:43, Patrick McCarty (patrick.mcca...@linux.intel.com) wrote: The correct path to the dir with CIPSO mappings is /etc/smack/cipso.d/; /etc/smack/cipso is a file that can include these mappings as well, though it is no longer supported in upstream libsmack. Thanks! Applied! --- src/core/smack-setup.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/core/smack-setup.c b/src/core/smack-setup.c index d67a84a..1434dea 100644 --- a/src/core/smack-setup.c +++ b/src/core/smack-setup.c @@ -40,7 +40,7 @@ #include label.h #define SMACK_CONFIG /etc/smack/accesses.d/ -#define CIPSO_CONFIG /etc/smack/cipso/ +#define CIPSO_CONFIG /etc/smack/cipso.d/ #ifdef HAVE_SMACK Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: When parsing the root= cmdline option, set FsckPassNo to 1
On Mon, 30.09.13 00:32, Thomas Bächler (tho...@archlinux.org) wrote:
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index 9efccb9..6cecb4e 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -449,7 +449,7 @@ static int parse_new_root_from_proc_cmdline(void) {
}
log_debug(Found entry what=%s where=/sysroot type=%s, what, type);
-r = add_mount(what, /sysroot, type, opts, 0, noauto, nofail, false,
+r = add_mount(what, /sysroot, type, opts, 1, noauto, nofail, false,
SPECIAL_INITRD_ROOT_FS_TARGET, /proc/cmdline);
Hmm, Harald, how is this supposed to work?
Originally the intention was that root-fsck.service would run fsck for
the root device, anf fsck@.service would be used for the rest. The
difference is mostly one about ordering, i.e. root-fsck.service is the
only one that is fine with the fs being already mounted.
Now, if we have the initrd, then I figure root-fsck.service doesn't make
much sense, but there's something missing I think: if we use
fsck@.service for the root device, how do we then communicate to the
root-fsck.service on the host that the file system has already been
checked? How is that supposed to work?
Harald? What is the idea here?
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] fstab-generator: Generate explicit dependencies on systemd-fsck@.service instead of using FsckPassNo
On Mon, 30.09.13 01:34, Thomas Bächler (tho...@archlinux.org) wrote:
I'd love to get rid of FsckPassNo=, but I fear that's not that
easy... After all it's not just a boolean, it actually influences the
ordering of the fsck. There traditionally were two documented phases
which you could use to serialize multiple fsck on the same HDD
but different partitions, but parallelize it on different HDDs. Now,
fsck since a while can determine all that automatically these days. But
still by using FsckPassNo= you get ordering deps automatically added.
a) leave everything as is and FsckPassNo= does odering deps
b) declare that manual passno configuration is stupid beyond treating it
as simple boolean. In thatc ase we should drop all references of
passno in the sources. Of course people might complain that we break
compat with UNIX, but well...
c) Pimp up fstab-generator to write complete unit files for
fsck@.service that include the right dependencies. Meh.
d) Pimp up fstab-generator to write only .d dropins that add the
necessary deps between the fsck instances, but nothing else.
I think c) and a) suck. b) sounds like the best option to me. d) sounds
workable too.
If we go for b) then I figure people might complain that fstab(5) is not
longer compatible with what systemd does?
Opinions?
---
src/fstab-generator/fstab-generator.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index 6cecb4e..83aba7d 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -209,17 +209,26 @@ static int add_mount(
Before=%s\n,
post);
+if (passno 0) {
+_cleanup_free_ char *fsck = NULL;
+fsck = unit_name_from_path_instance(systemd-fsck, what,
.service);
+fprintf(f,
+Requires=%s\n
+After=%s\n,
+fsck,
+fsck);
+}
+
+
fprintf(f,
\n
[Mount]\n
What=%s\n
Where=%s\n
-Type=%s\n
-FsckPassNo=%i\n,
+Type=%s\n,
what,
where,
-type,
-passno);
+type);
if (!isempty(opts)
!streq(opts, defaults))
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] WiFi device starting a service
On Sat, 28.09.13 00:22, Paul D. DeRocco (pdero...@ix.netcom.com) wrote:
I'm working with a Gumstix, and I want to run an ifup command when the
WiFi device becomes available. I'm not sure why, but it always seems to
become available after the boot process is complete, so I can't use a
regular service unit tied to something like multi-user.target. So I'm
trying to have a udev rule launch a service instead. My first guess is
this:
/etc/udev/rules.d/wlan0-ifup.rules:
SUBSYSTEM==net, KERNEL==wlan0, \
ENV{SYSTEMD_WANTS}+=wlan0-ifup.service
/etc/systemd/system/wlan0-ifup.service:
[Unit]
Description=Bring wlan0 up
DefaultDependencies=false
[Service]
ExecStart=/sbin/ifup wlan0
Matching to wlan sounds like a poor choice, as on modern systems that's
not how interfaces are named. Also, even on old systems there's no
guarantee that wlan is how things are named.
Naturally, the service never runs, so it doesn't work. After logging in, I
can manually start the service, and the WiFi connects, so the problem has
to be in my udev rule. I ask here, because this seems more
systemd-specific than udev-specific.
There's also a rule in 99-systemd.rules:
SUBSYSTEM==net, KERNEL!=lo, TAG+=systemd, \
ENV{SYSTEMD_ALIAS}+=/sys/subsystem/net/devices/$name
I suspect that there's a way to hook something to that, but I can't figure
out how.
So what's the right way to do this? Is there a man page specifically for
this situation?
Something like this should work:
SUBSYSTEM==net, DEVTYPE==wlan, ENV{SYSTEMD_WANTS}+=ifup@$name.service
or so. This will instantiate one instance of ifup@.service per wlan
interface found. (Note however that the DEVTYPE match only works for
clean network drivers which do not implement their own wlan stack, and
which advertise themselves properly).
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Make upstart compatibility optional
On Sun, 29.09.13 23:18, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:
El 29/09/13 15:11, Lennart Poettering escribió:
On Fri, 27.09.13 23:04, Kay Sievers (k...@vrfy.org) wrote:
On Fri, Sep 27, 2013 at 9:24 PM, Cristian Rodríguez
crrodrig...@opensuse.org wrote:
Distributions such as openSUSE and probably others never included
upstart, in that case there is no need to include this code.
This introduces --disable-upstartcompat, however upstart compat is still
enabled by default.
I think we should just remove it, and leave it to people who actually
need it to patch it back in, I doubt there are any left, really.
I agree. We can't test this anyway anymore. I'd be happy to merge a
patch that removes any Upstart compat support.
Lennart
OK, here we go...patch attached..
THanks!
Applied!
From c6040aaa4914123774295336a51f0630f7903586 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cristian=20Rodr=C3=ADguez?= crrodrig...@opensuse.org
Date: Sun, 29 Sep 2013 23:17:42 -0300
Subject: [PATCH] remove legacy upstart compatibility
---
src/systemctl/systemctl.c | 93
---
1 file changed, 93 deletions(-)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index eede616..bb7ada9 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -5678,94 +5678,6 @@ _pure_ static int action_to_runlevel(void) {
return table[arg_action];
}
-static int talk_upstart(void) {
-_cleanup_dbus_message_unref_ DBusMessage *m = NULL, *reply = NULL;
-_cleanup_dbus_error_free_ DBusError error;
-int previous, rl, r;
-char
-env1_buf[] = RUNLEVEL=X,
-env2_buf[] = PREVLEVEL=X;
-char *env1 = env1_buf, *env2 = env2_buf;
-const char *emit = runlevel;
-dbus_bool_t b_false = FALSE;
-DBusMessageIter iter, sub;
-DBusConnection *bus;
-
-dbus_error_init(error);
-
-if (!(rl = action_to_runlevel()))
-return 0;
-
-if (utmp_get_runlevel(previous, NULL) 0)
-previous = 'N';
-
-if (!(bus =
dbus_connection_open_private(unix:abstract=/com/ubuntu/upstart, error))) {
-if (dbus_error_has_name(error, DBUS_ERROR_NO_SERVER)) {
-r = 0;
-goto finish;
-}
-
-log_error(Failed to connect to Upstart bus: %s,
bus_error_message(error));
-r = -EIO;
-goto finish;
-}
-
-if ((r = bus_check_peercred(bus)) 0) {
-log_error(Failed to verify owner of bus.);
-goto finish;
-}
-
-if (!(m = dbus_message_new_method_call(
- com.ubuntu.Upstart,
- /com/ubuntu/Upstart,
- com.ubuntu.Upstart0_6,
- EmitEvent))) {
-
-log_error(Could not allocate message.);
-r = -ENOMEM;
-goto finish;
-}
-
-dbus_message_iter_init_append(m, iter);
-
-env1_buf[sizeof(env1_buf)-2] = rl;
-env2_buf[sizeof(env2_buf)-2] = previous;
-
-if (!dbus_message_iter_append_basic(iter, DBUS_TYPE_STRING, emit)
||
-!dbus_message_iter_open_container(iter, DBUS_TYPE_ARRAY, s,
sub) ||
-!dbus_message_iter_append_basic(sub, DBUS_TYPE_STRING, env1) ||
-!dbus_message_iter_append_basic(sub, DBUS_TYPE_STRING, env2) ||
-!dbus_message_iter_close_container(iter, sub) ||
-!dbus_message_iter_append_basic(iter, DBUS_TYPE_BOOLEAN,
b_false)) {
-log_error(Could not append arguments to message.);
-r = -ENOMEM;
-goto finish;
-}
-
-if (!(reply = dbus_connection_send_with_reply_and_block(bus, m, -1,
error))) {
-
-if (bus_error_is_no_service(error)) {
-r = -EADDRNOTAVAIL;
-goto finish;
-}
-
-log_error(Failed to issue method call: %s,
bus_error_message(error));
-r = -EIO;
-goto finish;
-}
-
-r = 1;
-
-finish:
-if (bus) {
-dbus_connection_flush(bus);
-dbus_connection_close(bus);
-dbus_connection_unref(bus);
-}
-
-return r;
-}
-
static int talk_initctl(void) {
struct init_request request = {};
int r;
@@ -6037,11 +5949,6 @@ static int start_with_fallback(DBusConnection *bus) {
goto done;
}
-/* Hmm, talking to systemd via D-Bus didn't work. Then
- * let's try to talk to Upstart via D-Bus. */
-if (talk_upstart() 0)
-goto
Re: [systemd-devel] [PATCH] Make upstart compatibility optional
On Mon, 30.09.13 08:44, Dave Reisner (d...@falconindy.com) wrote: I agree. We can't test this anyway anymore. I'd be happy to merge a patch that removes any Upstart compat support. Lennart OK, here we go...patch attached.. What about removing the TELINIT define in configure.ac and the associated machinery in systemctl.c? You'd need to fabricate a new error message for when systemd isn't running and systemctl is called as the name init. For now I have change the path, but left this in, so that Debian can still pass on init invocations to sysvinit telinit. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd should not call KDSKBMODE on a VT with X
On Fri, 27.09.13 11:43, Arthur Taylor (a...@ified.ca) wrote: This is an old thread from February. Sorry I can't reply to the original email. Apparently I failed to notice this question. My bad. Hello systemd developers TL;DR: On a VT which X is running, messing with KDSKBMODE on underneath X at best has no affect and at worst breaks keyboard input badly. In the short term, systemd should stop calling this ioctl because it has no benefit and makes no sense. It sounds to me we indeed want to set K_UNICODE only if K_OFF (or something else like it) is currently not set. However, before we change this, there's one thing that makes me wonder: what does X11 do on shutdown? Does it put the kbd back to K_UNICODE? Or back to K_XLATE? Lennart Provided the behaviour hasn't been changed in the last six months, Xorg remembers the VT KBMODE on start, set it to whatever it needs (sometimes more than once :-/ ) and restores it to the value it was on start upon exit. (Of course if X crashes hard it isn't restored, and that is why SysRq+R was invented.) This has been in place for a while, commited in February, does this leave anything open? http://cgit.freedesktop.org/systemd/systemd/commit/?id=a25d4d0e3ccf0e9bf0b37e5791275fd6ca5eb4ae Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Start and stop requests for a service
On Fri, 27.09.13 11:37, Umut Tezduyar (u...@tezduyar.com) wrote: Hi, I have noticed that ExecStop is not being run on following service with following requests: [Service] Type=oneshot RemainAfterExit=yes ExecStart=/bin/sh -c sleep 20 /usr/bin/systemd-cat echo ExecStart.. ExecStop=/bin/sh -c /usr/bin/systemd-cat echo ExecStop.. $ systemctl start hello.service $ systemctl stop hello.service I have couple discussions: 1) When a oneshot service is being in activating state, why doesn't stop request wait for the service to become active? I would expect systemd to queue stop request as long as service is in activating state. I think this kind of behavior is fine for Type=simple but not for Type=oneshot. KillMode=none is the only way to provide atomicity. Well, the thinking was that people would be annoyed if systemctl start hangs and they C-c it, and then do systemctl stop this hangs too... In the case of Type=oneshot I think people would be particularly annoyed if it wouldn't act immediately, after all Type=oneshot is the kind of service where *all* interesting bits only happen during activating state... Not following regarding the atomicity? 2) If I have an ExecStop directive, I would expect it to run no matter what. My solution is moving ExecStop to ExecStopPost. The idea was that ExecStop= is the clean way down, and ExecStopPost= the last resort thing to clean things up... My use case: I have a service which sets up ip filters on ExecStart and removes the filters on ExecStop. Setting up ip filters is done by a script. I have ended up finding my target in an inacceptable state due to start stop request coming right after each other. Hmm, so, but using ExecStopPost= should fix the issue for you, no? I think I don't fully get the problem, can you elaborate? There are three options basically, what to do if we get a stop request while we are starting something: a) wait until start finished, then immediately stop. -- I think this would be a bad idea, as pointed out above b) immediately go to ExecStop= if there is. -- I think this would be a bad idea, since ExecStop='s job is to do a clean shutdown, and something that has not started up fully is unlikely to shutdown cleanly. c) immediately go to SIGTERM/ExecStopPost=. Which seems to be the most reliable choice and is what is currently implemented. Can you may a good case why a) or b) would actually be the better choice? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Fwd: Journalctl performance
On Mon, 30.09.13 12:48, Jason St. John (jstj...@purdue.edu) wrote: I've been seeing similar performance issues with the journal for several recent versions of systemd (at least from v204 through v207 on Arch Linux). I have journal logs from 2012-10-20 through today that contain 1,268,128 lines. I just ran journalctl with less as the pager, pressed G, and it took 5.5 minutes to get all the way to the bottom. journalctl used lots of CPU throughout and regularly went to 99% CPU utilization. This is on a 3.5 year old laptop with a Core i5 M 430 and a 5,400 RPM hard drive. If this only happens with some journalctl versions, any change you could git bisect this and fiugre out what made journalctl so slow? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to add a dependency to a systemd.mount that is activated by /bin/mount?
On Wed, 25.09.13 01:11, Tim Landscheidt (t...@tim-landscheidt.de) wrote: On mount /mnt/test, however, systemctl status mnt-test.mount mount-wrapper shows the latter service being inactive (dead), while the former is active (mounted). How can I (or can I not?) set up a dependency that is hon- oured when /bin/mount is called as well? The status of the mount unit shows that mount /mnt/test seems to be trans- lated to ExecMount=/bin/mount /dev/$DEVICE /mnt/test -t auto -o noauto,user, so apparently systemd gets notified. This cannot work really and is not supported. /bin/mount more or less just invokes the mount() syscall internally. The kernel then does its thing and doesn't give systemd any time to do anything before that. And that's good that way, because we never want the kernel to wait for userspace... Or to say this with different words: in a way systemd is simply a scheduler for /bin/mount invocations by means of the .mount units. A corollary of that is that it is systemd which defers to /bin/mount for the actual mounting and not /bin/mount that deferes to systemd. If they'd defer to each other nothing would do anything or we'd have a cyclic dep/deadlock... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Patches to use -.mount without /etc/fstab
On Tue, 24.09.13 13:53, Kelly Anderson (ke...@xilka.com) wrote:
Hello,
If I'm not mistaken, the intent way back in the early stages of systemd was
to
eliminate /etc/fstab and use .mount files exclusively. Since it was never
fully implemented I took the prerogative to make it work on my systems.
I've been using the setup for quite some time and it works without
problem.
So, I am not really convinced that we really want to get rid of /etc/fstab...
1. if /etc/fstab is missing, systemd must remount / based on the options
in /etc/systemd/system/-.mount.
This could be done by scheduling a reload job for -.mount. systemctl
reload -- -.mount should have the desired effect.
2. If /etc/fstab is missing, systemd must create a valid fstab (in this case
/run/fstab) so that fsck runs properly.
Not following on this one really... If fsck fails if it doesn't find any
fstab, then this is really something to fix in util-linux I am sure. It
should treat a non-existant fstab the same way as an empty one.
The attached patches address those issues.
+if ( ! f ) {
+f = fopen(/etc/systemd/system/-.mount, r);
This doesn't really work, as the unit file might at many other
places. Also, we really shouldn't process unit files anywhere except PID
1, and definitely not duplicate the code for it...
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add SHELL environment variable
On Mon, 23.09.13 21:01, Evan Callicoat (a...@propter.net) wrote: Thanks! Applied! With the advent of systemd --user sessions, it's become very interesting to spawn X as a user unit, as well as accompanying processes that may have previously been in a .xinitrc/.xsession, or even just to replace a collection of XDG/GDM/KDM/etc session files with independent systemd --user units. The simplest case here would be to login on a tty, with the traditional /usr/sbin/login login manager. However, systemd --user (spawned by user@.service) is at the top level of the slice for the user, and does not inherit any environment variables from the login process. Given the number of common applications which rely on SHELL being set in the environment, it seems like the cleanest way to provide this variable is to set it to %s in the user@.service. Ideally in the long-term, applications which rely on SHELL being set should be fixed to just grab it from getpwnam() or similar, but until that becomes more common, I propose this simple change to make user sessions a little bit nicer out of the box. --- units/u...@.service.in | 1 + 1 file changed, 1 insertion(+) diff --git a/units/u...@.service.in b/units/u...@.service.in index 3f8b59d..3718a57 100644 --- a/units/u...@.service.in +++ b/units/u...@.service.in @@ -13,6 +13,7 @@ After=systemd-user-sessions.service User=%I PAMName=systemd-user Type=notify +Environment=SHELL=%s ExecStart=-@rootlibexecdir@/systemd --user Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/dbus/user_bus_socket Slice=user-%i.slice ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] fstab-generator: Generate explicit dependencies on systemd-fsck@.service instead of using FsckPassNo
On Tue, Oct 1, 2013 at 3:07 AM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 30.09.13 01:34, Thomas Bächler (tho...@archlinux.org) wrote: I'd love to get rid of FsckPassNo=, but I fear that's not that easy... After all it's not just a boolean, it actually influences the ordering of the fsck. There traditionally were two documented phases which you could use to serialize multiple fsck on the same HDD but different partitions, but parallelize it on different HDDs. Now, fsck since a while can determine all that automatically these days. But still by using FsckPassNo= you get ordering deps automatically added. a) leave everything as is and FsckPassNo= does odering deps b) declare that manual passno configuration is stupid beyond treating it as simple boolean. In thatc ase we should drop all references of passno in the sources. Of course people might complain that we break compat with UNIX, but well... c) Pimp up fstab-generator to write complete unit files for fsck@.service that include the right dependencies. Meh. d) Pimp up fstab-generator to write only .d dropins that add the necessary deps between the fsck instances, but nothing else. I think c) and a) suck. b) sounds like the best option to me. d) sounds workable too. If we go for b) then I figure people might complain that fstab(5) is not longer compatible with what systemd does? b) is tempting. Given fsck's improved internal ordering handling, is there actually a usecase for ordering the fsck's? I can't think of any off the top of my head... -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] iscsid / systemd / dracut integration effort
On Mon, 23.09.13 10:33, The Lee-Man (leeman.dun...@gmail.com) wrote: After=network.target NetworkManager-wait-online.service tgtd.service targetcli.service Please use network-online.target here instead of NetworkManager-wait-online.service. Please see the discussion of this unit on: http://www.freedesktop.org/software/systemd/man/systemd.special.html That said, this service makes local block devices available over the network, right, and it doesn't want to connect to anything on the network, or does it? If so, I really don't see the need for pulling in network-online.target/NetworkManager-wait-online.service here at all. iscsi.service: == After=network.target NetworkManager-wait-online.service iscsid.service This one on the other hand actually wants network connectivity around, right, since it tries to connect to other hosts? For this one using network-online.target sounds appropriate. ConditionPathExists=/etc/iscsi/initiatorname.iscsi [Service] Type=oneshot ExecStart=/sbin/iscsiadm -m node --loginall=automatic ExecStop=/bin/sync Wut?? Is this really necessary? If this is really necessary (which I doubt, appears to be snake oil to me...), then why doesn't iscsiadm do this internally? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] fstab-generator: Generate explicit dependencies on systemd-fsck@.service instead of using FsckPassNo
On Tue, Oct 1, 2013 at 4:29 AM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 01.10.13 04:19, Tom Gundersen (t...@jklm.no) wrote: I'd love to get rid of FsckPassNo=, but I fear that's not that easy... After all it's not just a boolean, it actually influences the ordering of the fsck. There traditionally were two documented phases which you could use to serialize multiple fsck on the same HDD but different partitions, but parallelize it on different HDDs. Now, fsck since a while can determine all that automatically these days. But still by using FsckPassNo= you get ordering deps automatically added. a) leave everything as is and FsckPassNo= does odering deps b) declare that manual passno configuration is stupid beyond treating it as simple boolean. In thatc ase we should drop all references of passno in the sources. Of course people might complain that we break compat with UNIX, but well... c) Pimp up fstab-generator to write complete unit files for fsck@.service that include the right dependencies. Meh. d) Pimp up fstab-generator to write only .d dropins that add the necessary deps between the fsck instances, but nothing else. I think c) and a) suck. b) sounds like the best option to me. d) sounds workable too. If we go for b) then I figure people might complain that fstab(5) is not longer compatible with what systemd does? b) is tempting. Given fsck's improved internal ordering handling, is there actually a usecase for ordering the fsck's? I can't think of any off the top of my head... I struggle coming up with one. I mean, the only I could think of is oh my, it always used to work that way, and it is documented that way, you break UNIX!, which isn't even a usecase, but just confusion. I have the suspicion that if we remove support for it, and don't tell anyone nobody might actually notice. So maybe we should just go ahead and change it to become a boolean only, and not tell anyone, and that's it? Opinions? Things like that should probably just be automatically determined by the machine, and not requiring a human to invent weird passes to do the job. A boolean sounds fine to me. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Some thoughts about loop_read/loop_write in util.c
On Fri, 13.09.13 08:38, cee1 (fykc...@gmail.com) wrote: 2013/9/12 Lennart Poettering lenn...@poettering.net: On Thu, 12.09.13 09:43, cee1 (fykc...@gmail.com) wrote: What about the following patch? It simply do read/write again if poll returns, and let read/write report error if something is wrong. I guess that patch makes sense, but could you change it to not just comment but delete the old lines? Also, could you add a comment there: /* We knowingly ignore the revents value here, and expect that any error/EOF is reported via read()/write() */ OK, see the attachment. Ah! No need to resend after all, found your original mail. Applied! Thanks! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix timeout when stopping Type=notify service
On Fri, 20.09.13 22:53, Olivier Brunel (j...@jjacky.com) wrote:
Since 41efeaec a call to service_unwatch_main_pid() is done from
service_set_main_pid(), which is called upon receiving message MAINPID=
This had the side effect of not watching pid anymore, and would result in a
useless timeout when stopping the service, as the unit wouldn't be identified
from the pid, so not marked stopped which would result in systemd thinking
this
was a timeout.
I commited a different fix now in
7400b9d2e99938d17b281d7df43680eade18666e, but it's untested. Could you
check if this makes things work?
---
I'm not exactly familiar with systemd's internals, so this might not be the
correct way to fix this, please correct me if it isn't.
src/core/service.c | 8
1 file changed, 8 insertions(+)
diff --git a/src/core/service.c b/src/core/service.c
index 246a86e..1dccdff 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -3388,9 +3388,17 @@ static void service_notify_message(Unit *u, pid_t pid,
char **tags) {
log_warning_unit(u-id,
Failed to parse notification
message %s, e);
else {
+int r;
+
log_debug_unit(u-id,
%s: got %s, u-id, e);
service_set_main_pid(s, pid);
+r = unit_watch_pid(u, pid);
+if (r 0)
+/* FIXME: we need to do something here */
+log_warning_unit(u-id,
+ Failed to watch PID %lu
from service %s,
+ (unsigned long) pid, u-id);
}
}
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] fstab-generator: Generate explicit dependencies on systemd-fsck@.service instead of using FsckPassNo
On Tue, 01.10.13 04:42, Kay Sievers (k...@vrfy.org) wrote: On Tue, Oct 1, 2013 at 4:29 AM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 01.10.13 04:19, Tom Gundersen (t...@jklm.no) wrote: I'd love to get rid of FsckPassNo=, but I fear that's not that easy... After all it's not just a boolean, it actually influences the ordering of the fsck. There traditionally were two documented phases which you could use to serialize multiple fsck on the same HDD but different partitions, but parallelize it on different HDDs. Now, fsck since a while can determine all that automatically these days. But still by using FsckPassNo= you get ordering deps automatically added. a) leave everything as is and FsckPassNo= does odering deps b) declare that manual passno configuration is stupid beyond treating it as simple boolean. In thatc ase we should drop all references of passno in the sources. Of course people might complain that we break compat with UNIX, but well... c) Pimp up fstab-generator to write complete unit files for fsck@.service that include the right dependencies. Meh. d) Pimp up fstab-generator to write only .d dropins that add the necessary deps between the fsck instances, but nothing else. I think c) and a) suck. b) sounds like the best option to me. d) sounds workable too. If we go for b) then I figure people might complain that fstab(5) is not longer compatible with what systemd does? b) is tempting. Given fsck's improved internal ordering handling, is there actually a usecase for ordering the fsck's? I can't think of any off the top of my head... I struggle coming up with one. I mean, the only I could think of is oh my, it always used to work that way, and it is documented that way, you break UNIX!, which isn't even a usecase, but just confusion. I have the suspicion that if we remove support for it, and don't tell anyone nobody might actually notice. So maybe we should just go ahead and change it to become a boolean only, and not tell anyone, and that's it? Opinions? Things like that should probably just be automatically determined by the machine, and not requiring a human to invent weird passes to do the job. A boolean sounds fine to me. OK, sounds good to me. Anyone wants to cook up a patch that removes FsckPassNo= from the core and makes sure the fstab generator only takes the passno field in fstab as boolean to enable fsck or not? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
