Re: [systemd-devel] Allow stop jobs to be killed during shutdown
2014-01-27 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: On Sat, Jan 25, 2014 at 06:16:38PM +0100, Reindl Harald wrote: Am 25.01.2014 18:09, schrieb Marcos Mello: Koen Kooi koen at dominion.thruhere.net writes: [snip] To make matters worse, the cylon eye isn't displayed when you boot with 'quiet' in your kernel command line. quiet systemd.show_status=1 shows the gracious Cylon eye so that should be default and extended by a visible counter manually to add boot-params are useless for the normal user the advaned one is not using quiet at all I now pushed a change to git to display time since a job was started and the job timeout in the ephemeral status. It turns out that in the recent rewrite, the timeout logic was borked, so the ephemeral status was not displayed properly. It should now be displayed more reliably. Thanks! Still, nothing is displayed with 'quiet'. This is a separate change to make I guess. That would be awesome. I assume this would cover a stuck boot as well? This is often mentioned complaint, see e.g. the recent discussion https://lists.debian.org/debian-boot/2014/01/msg00251.html https://lists.debian.org/debian-boot/2014/01/msg00253.html https://lists.debian.org/debian-boot/2014/01/msg00255.html -- 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] How can this be done with systemd
'Twas brillig, and Roelof Wobben at 25/01/14 17:44 did gyre and gimble: From: rwob...@hotmail.com To: zbys...@in.waw.pl CC: systemd-devel@lists.freedesktop.org Subject: RE: [systemd-devel] How can this be done with systemd Date: Sat, 25 Jan 2014 15:12:27 + Date: Sat, 25 Jan 2014 16:05:29 +0100 From: zbys...@in.waw.pl To: rwob...@hotmail.com CC: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] How can this be done with systemd On Sat, Jan 25, 2014 at 09:29:18AM +, Roelof Wobben wrote: Hello, I try to port systemd to a live distro. The biggest problem is that they work with modules. So before the start up can be processed all the modules needs to be packed out and copied to memory. systemd-modules-load.service(8) will load the modules, but of course won't unpack them. You'll have to do it yourself. Probably adding a separate .service with DefaultDependencies=no, Before=systemd-modules-load.service, and installed as wanted by systemd-modules-load.service which unpacks the modules is the way to do it. Zbyszek I look at systemd-modules-load.service(8) but that is for kernel modules. The modules I talk about are a sort of container which contains software like kernel.xzm which contains all the directories and files of the kernel in use. Anyone a out-of-the-box idea how to solve this ? If you're dealing with things like UnionFS and AusFS and such like, then I'd recommend actually doing all this *before* systemd. For our live CDs, we use a dracut module to do the unionfs setup and then when things are transitioned over systemd can work happily. http://svnweb.mageia.org/packages/cauldron/dracut/current/SOURCES/0513-mgalive-A-module-to-mount-Mageia-Live-media.patch?view=markup (note there is also upstream dracut support for live-media too. I didn't write the above module and I've not really had time to try and consolidate it with the usptream support). Col 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] Cannot see the whole picture
'Twas brillig, and Roelof Wobben at 26/01/14 09:16 did gyre and gimble: Second part I m struggeling with is how I can take care that this is one of the first part of the booting. And this part must be alone and cannot be in parralel with other parts because they all depend on this step. Can someone help me to see the whole picture ? Replied on your other thread, but doing so here for the sake of completeness. You will likely want to set everything up within the initrd and then transition over to the real PID1 after all your modules and unions etc. are configured. If you're not already doing so, I'd strongly recommend using dracut to build your initrd. We (in Mageia) use a custom dracut module to do our setup. It's quite simple. Upstream dracut does also have modules for live media but I've not yet had time to consolidate our version with the upstream one (it's on an ever expanding TODO list). Long term goal is certainly to not require any specific downstream patches to dracut. Our module is here. It shows us doing the initial moutn of the filesystem (which is squashfs) and using overlayfs in combination with tmpfs to make it writable. This sounds similar to what you are trying to achieve. http://svnweb.mageia.org/packages/cauldron/dracut/current/SOURCES/0513-mgalive-A-module-to-mount-Mageia-Live-media.patch?view=markup Hope it helps 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] Malicious tests?
'Twas brillig, and Tom Horsley at 27/01/14 00:44 did gyre and gimble: 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... I've documented that problem in earlier comments on that bug as to why systemctl disable does this. See: https://bugzilla.redhat.com/show_bug.cgi?id=1043212#c19 It's due to chkconfig shelling out to systemctl daemon-reload but also systemctl doing it and thus causing two reloads in very quick succession, which triggers the serialisation race (it also re-runs Type=oneshot services which seems wrong to me, but need to clarify) I've documented the problem quite thoroughly both here and on that bug and implemented several workarounds, but the underlying problem is definitely a serious one and one I'll be discussing it with Lennart and Zbigniew (aka haranguing them!) on Thursday/Friday. I can reproduce the problem very easily on my system, so that's half the battle. Sadly simple containers with little real world units seem to avoid the problems. But I'm sure there will be some kind of fix for this over the next week or so. 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] Allow stop jobs to be killed during shutdown
'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
ExecStop=/bin/kill -WINCH ${MAINPID}
# We want systemd to give httpd some time to finish gracefully, but still want
# it to kill httpd after TimeoutStopSec if something went wrong during the
# graceful stop. Normally, Systemd sends SIGTERM signal right after the
# ExecStop, which would kill httpd. We are sending useless SIGCONT here to
give
# httpd time to finish.
KillSignal=SIGCONT
It's probably not nice to do that, but it should give the necessary
time to let things clean up properly...
A proper fix is probably highly desirable tho'!
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] Malicious tests?
Sadly simple containers with little real world units seem to avoid the problems. But I'm sure there will be some kind of fix for this over the next week or so. But my example doesn't have any units at all :-). I issue two disable commands in a row for units that don't even exist. I have no idea why it would feel the need to do a daemon-reload when I disable a non-existent unit. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Malicious tests?
Am 27.01.2014 12:30, schrieb Tom Horsley: Sadly simple containers with little real world units seem to avoid the problems. But I'm sure there will be some kind of fix for this over the next week or so. But my example doesn't have any units at all :-). I issue two disable commands in a row for units that don't even exist. I have no idea why it would feel the need to do a daemon-reload when I disable a non-existent unit there is a deeper problem a simple reload should not lead to reach any target which is already reached for hours, so reload does way more as expected [root@rh:~]$ /var/log/messages; systemctl daemon-reload; sleep 3; systemctl daemon-reload; cat /var/log/messages Jan 27 12:36:35 rh systemd[1]: Mounted Configuration File System. Jan 27 12:36:35 rh systemd[1]: Reached target Sound Card. Jan 27 12:36:35 rh systemd[1]: Found device /sys/devices/virtual/block/md0. Jan 27 12:36:35 rh systemd[1]: Found device /dev/md0. Jan 27 12:36:35 rh systemd[1]: Found device /dev/disk/by-id/md-name-localhost.localdomain:0. Jan 27 12:36:35 rh systemd[1]: Found device /dev/disk/by-id/md-uuid-1d691642:baed26df:1d197496:4fb00ff8. Jan 27 12:36:35 rh systemd[1]: Found device /dev/disk/by-label/boot. Jan 27 12:36:35 rh systemd[1]: Found device /sys/devices/virtual/block/md2. Jan 27 12:36:35 rh systemd[1]: Found device /dev/md2. Jan 27 12:36:35 rh systemd[1]: Found device /dev/disk/by-id/md-name-localhost.localdomain:2. Jan 27 12:36:35 rh systemd[1]: Found device /dev/disk/by-id/md-uuid-ea253255:cb915401:f32794ad:ce0fe396. Jan 27 12:36:35 rh systemd[1]: Found device /dev/disk/by-label/data. Jan 27 12:36:38 rh systemd[1]: Mounted Configuration File System. Jan 27 12:36:38 rh systemd[1]: Reached target Sound Card. Jan 27 12:36:38 rh systemd[1]: Found device /sys/devices/virtual/block/md0. Jan 27 12:36:38 rh systemd[1]: Found device /dev/md0. Jan 27 12:36:38 rh systemd[1]: Found device /dev/disk/by-id/md-name-localhost.localdomain:0. Jan 27 12:36:38 rh systemd[1]: Found device /dev/disk/by-id/md-uuid-1d691642:baed26df:1d197496:4fb00ff8. 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] What do I need to do to force systemd to create folders in the cgroups tree?
For my application I have three slices. Two of these are working,
onelan.slice and onelan-screen.slice, but onelan-player.slice is
not causing the cgroup folders to come into existence.
I put a dependency on workaround-systemd-cgroup-limitations-onelan-player-
slice.service to cause onelan-player.slice to be created. That slice will
be used later to hold processes create via the dbus start transient interface.
But when that services run I see the following cgroups:
# find /sys/fs/cgroup -name '*.slice' -print
/sys/fs/cgroup/memory/onelan.slice
/sys/fs/cgroup/cpuacct/onelan.slice
/sys/fs/cgroup/cpuacct/onelan.slice/onelan-screen.slice
/sys/fs/cgroup/cpuacct/onelan.slice/onelan-player.slice
/sys/fs/cgroup/cpu/onelan.slice
/sys/fs/cgroup/cpu/onelan.slice/onelan-screen.slice
/sys/fs/cgroup/cpu/onelan.slice/onelan-player.slice
/sys/fs/cgroup/systemd/user.slice
/sys/fs/cgroup/systemd/onelan.slice
/sys/fs/cgroup/systemd/onelan.slice/onelan-screen.slice
/sys/fs/cgroup/systemd/onelan.slice/onelan-player.slice
/sys/fs/cgroup/systemd/system.slice
/sys/fs/cgroup/systemd/system.slice/system-lvm2\x2dpvscan.slice
/sys/fs/cgroup/systemd/system.slice/system-systemd\x2dfsck.slice
/sys/fs/cgroup/systemd/system.slice/system-systemd\x2dbacklight.slice
/sys/fs/cgroup/systemd/system.slice/system-getty.slice
I expect to have /sys/fs/cgroup/memory/onelan.slice/onelan-player.slice
but it does not exist.
What do I need to do to force it to be created?
Here is the content of involved unit files and status from systemd.
# cat /etc/systemd/system/workaround-systemd-cgroup-limitations-onelan-player-
slice.service
[Unit]
Description=workaround systemd cgroup limitations service
After=workaround-systemd-cgroup-limitations-onelan-slice.service
Requires=workaround-systemd-cgroup-limitations-onelan-slice.service
[Service]
Slice=onelan-player.slice
Type=oneshot
StandardOutput=syslog
ExecStart=/usr/local/onelan/systemd/workaround-systemd-cgroup-limitations
onelan-player.slice
RemainAfterExit=yes
# cat /usr/local/onelan/systemd/workaround-systemd-cgroup-limitations
#!/bin/bash
#
# Copyright 2014 (c) ONELAN Ltd. www.onelan.co.uk
# All rights reserved.
#
#
# workaround-systemd-cgroup-limitations
#
# As of systemd 208 it is not possible to setup all
# the cgroup attributes that we need.
#
# As soon as systemd aquires a method of doing the
# additional cgroup setup this module and its .service
# can be deleted.
#
set -e
function set_attr {
VALUE=$1
CGATTR=$2
echo Info: Set ${VALUE} into ${CGATTR}
echo ${VALUE} ${CGATTR}
}
case $1 in
onelan.slice)
find /sys/fs/cgroup -name '*.slice' -print /root/onelan.slice.log
CGROUP=/sys/fs/cgroup/cpu/onelan.slice
set_attr 10 ${CGROUP}/cpu.rt_period_us
set_attr 9 ${CGROUP}/cpu.rt_runtime_us
;;
onelan-player.slice)
find /sys/fs/cgroup -name '*.slice' -print /root/onelan-player.slice.log
CGROUP=/sys/fs/cgroup/memory/onelan.slice/onelan-players.slice
LINE=$( grep '#SwapMemoryLimit' /etc/onelan/ntb/systemd-player-memory-
limits.include )
LIMIT=${LINE#*=}
set_attr ${LIMIT} ${CGROUP}/memory.memsw.limit_in_bytes
;;
*)
exit 1
;;
esac
# cat /etc/systemd/system/onelan-players.slice
[Unit]
Description=ONELAN Players Slice
DefaultDependencies=no
Before=slices.target
Wants=onelan.slice
After=onelan.slice
[Slice]
CPUAccounting=true
MemoryAccounting=true
.include /etc/onelan/ntb/systemd-player-memory-limits.include
# cat /etc/onelan/ntb/systemd-player-memory-limits.include
[Slice]
MemoryLimit=3217719296
#SwapMemoryLimit=5365202944
# systemctl status onelan-player.slice
onelan-player.slice
Loaded: loaded
Active: active since Mon 2014-01-27 10:43:20 GMT; 24min ago
Barry
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Update Ant USB Sticks in hwdb
--- hwdb/20-usb-vendor-model.hwdb | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/hwdb/20-usb-vendor-model.hwdb b/hwdb/20-usb-vendor-model.hwdb index 60dbcd2..e048745 100644 --- a/hwdb/20-usb-vendor-model.hwdb +++ b/hwdb/20-usb-vendor-model.hwdb @@ -38217,13 +38217,16 @@ usb:v0FCFp1003* ID_MODEL_FROM_DATABASE=ANT Development Board usb:v0FCFp1004* - ID_MODEL_FROM_DATABASE=ANT2USB + ID_MODEL_FROM_DATABASE=ANTUSB1 Stick usb:v0FCFp1006* ID_MODEL_FROM_DATABASE=ANT Development Board usb:v0FCFp1008* - ID_MODEL_FROM_DATABASE=Mini stick Suunto + ID_MODEL_FROM_DATABASE=ANTUSB2 Stick + +usb:v0FCFp1009* + ID_MODEL_FROM_DATABASE=ANTUSB-m Stick usb:v0FD0* ID_VENDOR_FROM_DATABASE=Tulip Computers B.V. -- 1.8.3.2 ___ 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
[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.
So systemdPID1 would trigger the ExecStop (triggering the user session
shutdown) and then not do the normal round of killing due to the
KillSignal, wait for a timeout (which is quite long) and only then do a
SIGKILL (which is brutal but you'd hope the user session would have done
all it's work by then and killed as much as is humanly possible (spawned
off root processes stuck in the user's cgroup not withstanding...).
But perhaps I'm still missing something and this won't work :(
And of course as mentioned originally it would be nice to provide better
semantics to control this.
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] Allow stop jobs to be killed during shutdown
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? -t ___ 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 Mon, Jan 27, 2014 at 1:13 PM, Andrey Borzenkov arvidj...@gmail.com wrote: В 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= ... I think we could avoid all this be just not using async signals at all unless something is broken and we need to go on a killing-spree. -t ___ 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
Am 27.01.2014 05:18, schrieb David Anderson:
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*
FWIW, you can copy /usr/lib/udev/rules.d/80-net-name-slot.rules to
/etc/udev/rules.d/ and comment out line 10:
# NAME==, ENV{ID_NET_NAME_ONBOARD}!=, NAME=$env{ID_NET_NAME_ONBOARD}
signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Update Ant USB Sticks in hwdb
Hi Gustav, We are pulling this information from http://www.linux-usb.org/usb.ids, so it would be best if you could submit your update upstream: http://www.linux-usb.org/usb-ids.html. Cheers, Tom On Mon, Jan 27, 2014 at 1:04 PM, Gustav Tiger gus...@tiger.name wrote: --- hwdb/20-usb-vendor-model.hwdb | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/hwdb/20-usb-vendor-model.hwdb b/hwdb/20-usb-vendor-model.hwdb index 60dbcd2..e048745 100644 --- a/hwdb/20-usb-vendor-model.hwdb +++ b/hwdb/20-usb-vendor-model.hwdb @@ -38217,13 +38217,16 @@ usb:v0FCFp1003* ID_MODEL_FROM_DATABASE=ANT Development Board usb:v0FCFp1004* - ID_MODEL_FROM_DATABASE=ANT2USB + ID_MODEL_FROM_DATABASE=ANTUSB1 Stick usb:v0FCFp1006* ID_MODEL_FROM_DATABASE=ANT Development Board usb:v0FCFp1008* - ID_MODEL_FROM_DATABASE=Mini stick Suunto + ID_MODEL_FROM_DATABASE=ANTUSB2 Stick + +usb:v0FCFp1009* + ID_MODEL_FROM_DATABASE=ANTUSB-m Stick usb:v0FD0* ID_VENDOR_FROM_DATABASE=Tulip Computers B.V. -- 1.8.3.2 ___ 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
В 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] udev failing to assign consistent biosdevnames to my ethernet interfaces
On Mon, Jan 27, 2014 at 6:39 AM, David Anderson d...@natulte.net wrote: You have two devices of type Ethernet with the same Instance values. Regardless, should udev be capable of handling this gracefully? 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.). Udev should not operate in the firmware namespace, and just allocate the eno1 name here. It's the firmware that owns these names, not userspace. 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. Devices are independent and should not depend on each other, we cannot really depend on the state of another, otherwise unrelated, device. In any case, I ended up writing my own rules that correctly set up eno1/eno2 based on the port #s on the board. Slightly annoying, but short of bugging Intel for a firmware update, not much else to do. Yeah, that's the only real option for now. The only thing we could do is falling back to the default PCI geography name on error; but even then, it would not be predictable which of the devices with the conflicting firmware names will win at bootup. Kay ___ 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
On Mon, Jan 27, 2014 at 1:25 PM, Thomas Bächler tho...@archlinux.org wrote:
Am 27.01.2014 05:18, schrieb David Anderson:
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*
FWIW, you can copy /usr/lib/udev/rules.d/80-net-name-slot.rules to
/etc/udev/rules.d/ and comment out line 10:
# NAME==, ENV{ID_NET_NAME_ONBOARD}!=, NAME=$env{ID_NET_NAME_ONBOARD}
This is probably the best thing to do (at least until we can figure
out something better), it will name your nics according to
ID_NET_NAME_PATH instead, which is not as pretty, but won't suffer
from the same issue.
-t
___
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 Mon, 27.01.14 09:03, Michael Biebl (mbi...@gmail.com) wrote: so that should be default and extended by a visible counter manually to add boot-params are useless for the normal user the advaned one is not using quiet at all I now pushed a change to git to display time since a job was started and the job timeout in the ephemeral status. It turns out that in the recent rewrite, the timeout logic was borked, so the ephemeral status was not displayed properly. It should now be displayed more reliably. Thanks! Still, nothing is displayed with 'quiet'. This is a separate change to make I guess. That would be awesome. I assume this would cover a stuck boot as well? This is often mentioned complaint, see e.g. the recent discussion https://lists.debian.org/debian-boot/2014/01/msg00251.html https://lists.debian.org/debian-boot/2014/01/msg00253.html https://lists.debian.org/debian-boot/2014/01/msg00255.html So, there has been this todo list item for a while to support a mode where a failing service at boot would result in boot status output to be turned on. Still not sure iof such a logic would be a good upstream default, but certainly a good default for more technically-minded distros such as Debian. 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. When that point is reached we'c continue the entire rest of the boot with status output enabled. And we wouldn't just turn the logging on, we'd also explain why we turned it on in one introductory message: Turning on boot-time status output because of service failure:, or Turning on boot-time status output because of nearing job timeout: or something like that. I'd be happy to see a patch like that merged. Lennart -- Lennart Poettering, Red Hat ___ 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 Mon, Jan 27, 2014 at 1:32 PM, Lennart Poettering lenn...@poettering.net wrote: So, there has been this todo list item for a while to support a mode where a failing service at boot would result in boot status output to be turned on. Still not sure iof such a logic would be a good upstream default, but certainly a good default for more technically-minded distros such as Debian. 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? 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? And we wouldn't just turn the logging on, we'd also explain why we turned it on in one introductory message: Turning on boot-time status output because of service failure:, or Turning on boot-time status output because of nearing job timeout: or something like that. -t ___ 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
'Twas brillig, and Andrey Borzenkov at 27/01/14 12:25 did gyre and gimble:
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!
Done a bit of testing with this hack today.
Doesn't seem to cause any problems, and while I didn't have a reliable
reproducer, I have done lots of reboots on my VM and I'd expect at least
one of them to have stalled by now.
So I might push this one in too.
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] [RFC PATCH 1/2] Replace mkostemp+unlink with open(O_TMPFILE)
On Sun, Jan 26, 2014 at 3:21 AM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
This will only work on Linux = 3.11, and probably not on all
filesystems. Fallback code is provided.
---
Hi,
because on bug https://bugzilla.gnome.org/show_bug.cgi?id=722889, I
was looking into async signal safety of the journal logging functions.
All that do any formatting are unsafe, but sd_journal_sendv *almost*
is. Currently it calls mkostemp and writev, but only in the fallback
path. So for the purpose of simple logging without multi-megabyte
messages it already is safe. But it would be nice to turn this into an
explicit guarantee. When O_TMPFILE is not available, it is hard to
make it generally safe, so I thought it would nice to provide a mode
where it simply fails when safety cannot be guaranteed. Because
sd_j_sendv does not take any flags, this is done by changing the
length parameter to mean that negative means signal-safe. So on
newer kernels, everything should just work and the function should be
async-signal-safe when a negative parameter is used. On old kernels,
it would cleanly fail for large messages. I think this is a worthy goal,
and being able to call structured logging from signal handlers should
lead to better diagnostics in the long run.
Comments? It would be great if somebody could look over sd_j_sendv to
verify my assumptions that everything in it is signal safe apart from
the stuff mentioned above.
Zbyszek
src/core/manager.c | 17 +++--
src/journal/journal-send.c | 20 +++-
src/journal/journal-verify.c | 12 +++-
src/shared/util.c| 22 ++
src/shared/util.h| 2 ++
5 files changed, 37 insertions(+), 36 deletions(-)
diff --git a/src/core/manager.c b/src/core/manager.c
index 95fc7e6..7156c38 100644
--- a/src/core/manager.c
+++ b/src/core/manager.c
@@ -1985,28 +1985,17 @@ void manager_dispatch_bus_name_owner_changed(
}
int manager_open_serialization(Manager *m, FILE **_f) {
-_cleanup_free_ char *path = NULL;
+const char *path;
int fd = -1;
FILE *f;
assert(_f);
-if (m-running_as == SYSTEMD_SYSTEM)
-asprintf(path, /run/systemd/dump-PID_FMT-XX,
getpid());
-else
-asprintf(path, /tmp/systemd-dump-PID_FMT-XX,
getpid());
-
-if (!path)
-return -ENOMEM;
-
-RUN_WITH_UMASK(0077) {
-fd = mkostemp(path, O_RDWR|O_CLOEXEC);
-}
-
+path = m-running_as == SYSTEMD_SYSTEM ? /run/systemd : /tmp;
+fd = open_tmpfile(path, O_RDWR|O_CLOEXEC);
if (fd 0)
return -errno;
-unlink(path);
log_debug(Serializing state to %s, path);
f = fdopen(fd, w+);
diff --git a/src/journal/journal-send.c b/src/journal/journal-send.c
index 281e154..ca9199f 100644
--- a/src/journal/journal-send.c
+++ b/src/journal/journal-send.c
@@ -216,10 +216,6 @@ _public_ int sd_journal_sendv(const struct iovec *iov,
int n) {
uint8_t buf[CMSG_SPACE(sizeof(int))];
} control;
struct cmsghdr *cmsg;
-/* We use /dev/shm instead of /tmp here, since we want this to
- * be a tmpfs, and one that is available from early boot on
- * and where unprivileged users can create files. */
-char path[] = /dev/shm/journal.XX;
bool have_syslog_identifier = false;
assert_return(iov, -EINVAL);
@@ -309,16 +305,14 @@ _public_ int sd_journal_sendv(const struct iovec *iov,
int n) {
/* Message doesn't fit... Let's dump the data in a temporary
* file and just pass a file descriptor of it to the other
- * side */
-
-buffer_fd = mkostemp(path, O_CLOEXEC|O_RDWR);
+ * side.
+ *
+ * We use /dev/shm instead of /tmp here, since we want this to
+ * be a tmpfs, and one that is available from early boot on
+ * and where unprivileged users can create files. */
+buffer_fd = open_tmpfile(/dev/shm, O_RDWR | O_CLOEXEC);
if (buffer_fd 0)
-return -errno;
-
-if (unlink(path) 0) {
-close_nointr_nofail(buffer_fd);
-return -errno;
-}
+return buffer_fd;
n = writev(buffer_fd, w, j);
if (n 0) {
diff --git a/src/journal/journal-verify.c b/src/journal/journal-verify.c
index f2422ff..9434cc9 100644
--- a/src/journal/journal-verify.c
+++ b/src/journal/journal-verify.c
@@ -785,9 +785,6 @@ int journal_file_verify(
uint64_t n_weird = 0, n_objects = 0, n_entries = 0, n_data = 0,
n_fields = 0, n_data_hash_tables = 0, n_field_hash_tables = 0, n_entry_arrays
= 0, n_tags = 0;
usec_t last_usec = 0;
int data_fd = -1, entry_fd = -1, entry_array_fd = -1;
-char data_path[] =
Re: [systemd-devel] Malicious tests?
On Sun, 26.01.14 19:44, Tom Horsley (horsley1...@gmail.com) wrote: 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 systemctl disable implies a systemctl daemon-reload and there appears to be a bug in that currently. Nope, we don't hjave a fuzzing test suit so far. But of course, we'd be happy to add support something for this, maybe based on the ChomeOS dbus fuzzer? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] merging libsd-id128 and libsd-login with libsystemd
On Sun, 26.01.14 00:16, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Thu, Jan 16, 2014 at 04:41:48PM +0100, Lennart Poettering wrote: So I am pretty sure libsystemd-id128, libsystemd-login, libsystemd-journal should just end up in a single libsystemd.so together with the event loop, the bus, the asyncns stuff and more. All this functinality requires each other, and should nto pull in its own copy of src/shared/*.c each time. I now pushed a series of patches which merge libsystemd-id128 and libsystemd-login into libsystemd. I also changed the linker to gold by default, becuase bfd had a bug [1]. It has since been fixed, but not released yet, and anyway gold is minimally faster. When running distcheck, which uses -flto, a bug [2] in gold was uncovered. I worked around it by disabling lto for the compat libsystemd-login. I doesn't matter much anyway for this lib. All in all, this doesn't give a good feeling... I wouldn't be surprised if other issues pop up. I guess it's better to do this now and potentially revert than right before release. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=16467 [2] https://sourceware.org/bugzilla/show_bug.cgi?id=16504 libsystemd-journal is more complicated. It uses libsystemd-label, which in turn uses libselinux. Doing a straighforward merge would mean that everything is linked with libselinux. I think that the idea of splitting the reporting side of sd-journal and moving it to libsystemd, while keeping the rest separate, might be a good idea. Comments? Hmm, any idea what precisely the label calls are we make in libsystemd-journal? Given that this is a client-side library it appears surprising that it needs to check the selinux database for something. Maybe we can change this to just not use the label-version of the respective calls? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH 1/2] Replace mkostemp+unlink with open(O_TMPFILE)
On Sun, 26.01.14 00:21, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: This will only work on Linux = 3.11, and probably not on all filesystems. Fallback code is provided. --- Hi, because on bug https://bugzilla.gnome.org/show_bug.cgi?id=722889, I was looking into async signal safety of the journal logging functions. All that do any formatting are unsafe, but sd_journal_sendv *almost* is. Currently it calls mkostemp and writev, but only in the fallback path. So for the purpose of simple logging without multi-megabyte messages it already is safe. But it would be nice to turn this into an explicit guarantee. When O_TMPFILE is not available, it is hard to Yupp, it's certainly a good idea to make our logging functions safe for execution in any context. What I don't understands though is why mkostemp() would not be safe here? +#ifdef O_TMPFILE +fd = open(path, flags | O_TMPFILE, S_IRUSR | S_IWUSR); +if (fd = 0) +return fd; +#endif Hmm, O_TMPFILE sounds like something to define in missing.h and then unconditionally use... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] syscallfilter: port to libseccomp
On Sat, 25.01.14 18:06, Ronny Chevalier (chevalier.ro...@gmail.com) wrote: Doesn't libseccomp provide a way to enumerate the contents of the defined filter again? I'd really prefer if we could find a way that specifiying a filter of read write and of write read would actually result in the same string exposed via the bus. Unfortunately no, this is why I strdup the string from the .service, but yes I see why this is not really a good idea... Maybe by adding each syscall, after being validated by the libseccomp API, in an array and sorting them ? And if the first element is the ~ then it's a blacklist ? Yeah, so I would be fine with parsing the string and resolving the syscalls with seccomp_syscall_resolve_name(), then adding the returned integer to an array, then sort the array and regenerate a string out if it again with seccomp_syscall_resolve_num(), possibly prefixing it with ~... That way, we'd expose a string, but a normalized and somewhat portable one. Lennart -- Lennart Poettering, Red Hat ___ 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 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. Lennart -- Lennart Poettering, Red Hat ___ 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 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... Lennart -- Lennart Poettering, Red Hat ___ 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
On Mon, Jan 27, 2014 at 03:51:34PM +0100, Lennart Poettering wrote: On Sun, 26.01.14 17:23, Tom Gundersen (t...@jklm.no) wrote: 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? Well, it would, but I am really sure KillMode=mixed would be the better approach... 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). Yeah, I fully agree. We need a timeout here that is mandated by the system, and cannot be overridden, so that the user cannot find a way to circumvent kill requests by the admin. However, it certainly makes sense to make it a bit higher than the systemd user instance's own timeouts. A bit higher is probably not enough, since a user instance might need to shutdown a few things in order, and more than one might have to time out. It'd probably make sense to decrease the timeouts in --user instances to something substantially smaller than in --system, and than make the timeout for user@.service a multiple of that. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH 2/2] journal: add async-signal-safe mode for sd_journald_sendv
On Sun, 26.01.14 00:21, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
+static int writev_safe(int fd, const struct iovec *w, int j, bool
async_signal_safe) {
+if (!async_signal_safe)
+return writev(fd, w, j);
+
+for (int i = 0; i j; i++) {
+size_t written = 0;
+
+while (written w[i].iov_len) {
+ssize_t r;
+
+r = write(fd, w[i].iov_base + written, w[i].iov_len
- written);
+if (r 0 errno != -EINTR)
+return -errno;
+
+written += r;
+}
+}
+
+return 0;
+}
I don't follow here. What's the rationale for using write() here?
Doesn't the libc include pretty much the same manual loop internally
anyway as a fallback?
Are you sure that writzev() is not async signal safe? Maybe this is just
a documentation oversight?
Lennart
--
Lennart Poettering, Red Hat
___
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] [RFC PATCH 1/2] Replace mkostemp+unlink with open(O_TMPFILE)
El 27/01/14 10:52, Lucas De Marchi escribió: This unlink() doesn't make much sense with O_TMPFILE. Yup, the name can't be seen in the filesystem and it goes away on close() or program termination. it is more like tmpfile(3) than mkstemp(3) ___ 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 Sat, 25.01.14 16:41, Dominique Michel (dominique.mic...@vtxnet.ch) wrote: So there is a 5s timeout before displaying that, but all it does is tell you how many jobs are waiting and not how long it's going to wait for them. If the user sits and watches that animation for 20s they'll likely think ahh well this is stuck and yank the cord, not knowing that things will be done cleanly if they just wait another 10s. I fully agree. At my work, 20s are already a lot of time when it is time to go. If we displayed a timeout clock here too, users would be more willing to wait. It would also be nice to show which process systemd is waiting for, together with something like Press Ctrl+C to abort and continue Most important is the possibility to abort the wait and continue, because I am sure some peoples I know will just think What is this f. s. and yank the cord anyway. I like the theory of this, but I am not sure how to implement this nicely, since it is usually not clear what precisely the unit is that isn't showing up... Also, it's security sensitive I think, so it cannot be enabled by default I think... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH 1/2] Replace mkostemp+unlink with open(O_TMPFILE)
On Mon, Jan 27, 2014 at 03:14:28PM +0100, Lennart Poettering wrote: On Sun, 26.01.14 00:21, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: This will only work on Linux = 3.11, and probably not on all filesystems. Fallback code is provided. --- Hi, because on bug https://bugzilla.gnome.org/show_bug.cgi?id=722889, I was looking into async signal safety of the journal logging functions. All that do any formatting are unsafe, but sd_journal_sendv *almost* is. Currently it calls mkostemp and writev, but only in the fallback path. So for the purpose of simple logging without multi-megabyte messages it already is safe. But it would be nice to turn this into an explicit guarantee. When O_TMPFILE is not available, it is hard to Yupp, it's certainly a good idea to make our logging functions safe for execution in any context. What I don't understands though is why mkostemp() would not be safe here? mkostemp is not on the list of safe functions. I looked at the implementation, and it actually has a static variable, so it really cannot be called. +#ifdef O_TMPFILE +fd = open(path, flags | O_TMPFILE, S_IRUSR | S_IWUSR); +if (fd = 0) +return fd; +#endif Hmm, O_TMPFILE sounds like something to define in missing.h and then unconditionally use... It has different values on different archs... Possible to replicate, but ugly. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH 1/2] Replace mkostemp+unlink with open(O_TMPFILE)
On Mon, Jan 27, 2014 at 5:35 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Jan 27, 2014 at 03:14:28PM +0100, Lennart Poettering wrote: Yupp, it's certainly a good idea to make our logging functions safe for execution in any context. What I don't understands though is why mkostemp() would not be safe here? mkostemp is not on the list of safe functions. I looked at the implementation, and it actually has a static variable, so it really cannot be called. But does this matter here? The static var is still mixed with random. It seems it will work just fine, at least with the next iteration? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH 1/2] Replace mkostemp+unlink with open(O_TMPFILE)
On Mon, Jan 27, 2014 at 5:37 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Mon, Jan 27, 2014 at 11:52:48AM -0200, Lucas De Marchi wrote:
On Sun, Jan 26, 2014 at 3:21 AM, Zbigniew Jędrzejewski-Szmek
+int open_tmpfile(const char *path, int flags) {
+int fd;
+char *p;
+
+#ifdef O_TMPFILE
+fd = open(path, flags | O_TMPFILE, S_IRUSR | S_IWUSR);
+if (fd = 0)
+return fd;
+#endif
+p = strappenda(path, /systemd-tmp-XX);
+
+RUN_WITH_UMASK(0077) {
+fd = mkostemp(p, O_RDWR|O_CLOEXEC);
+}
+
+if (fd 0)
+return -errno;
+
+unlink(path);
This unlink() doesn't make much sense with O_TMPFILE.
unlink is only reached if open(O_TMPFILE) failed and fd comes
from mkostemp.
Can we expect open(O_TMPFILE) to fail on kernels which do not support it?
I guess they will just silently ignore it? Then we never unlink?
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] making a python daemon both systemd and el5 compatible
I'm working on a small daemon[1] that doesn't do a whole lot, but we need it to work on RHEL5+. Going out of the gate I want to ensure it also works with systemd, since i want it to be usable on fedora and el7. This stackoverflow[2] has a method, but then mentions some compatibility problems with the library it recommends that seem like it will not make it to friendly back to el5. In the interm I was going to try leveraging cherrypy's bits (PIDFile and Daemonize), but they aren't backwards compatible to EL5, so we have to fix that. I tried to find some place where this was mentioned or recommended but my google-fu failed me. Do you have any recommendations or a existing python daemon that you could point me at that has similar needs? thank you very much greg swift [1] https://github.com/rackerlabs/plight [2] http://stackoverflow.com/questions/13069634/python-daemon-and-systemd-service ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] making a python daemon both systemd and el5 compatible
'Twas brillig, and Greg Swift at 27/01/14 17:20 did gyre and gimble: I'm working on a small daemon[1] that doesn't do a whole lot, but we need it to work on RHEL5+. Going out of the gate I want to ensure it also works with systemd, since i want it to be usable on fedora and el7. This stackoverflow[2] has a method, but then mentions some compatibility problems with the library it recommends that seem like it will not make it to friendly back to el5. In the interm I was going to try leveraging cherrypy's bits (PIDFile and Daemonize), but they aren't backwards compatible to EL5, so we have to fix that. I tried to find some place where this was mentioned or recommended but my google-fu failed me. Do you have any recommendations or a existing python daemon that you could point me at that has similar needs? thank you very much I had to do this recently for something which I run on CentOS5: http://colin.guthr.ie/git/misc/on-the-pull/commit/?id=9654725a625520bbb57864b1f1cd515948e1106d It's kinda ugly, but it works. I added the --pid-file option to the arguments and a --user option (which needs --pid-file to be passed). My argument passing code is definitely ugly but I'm pretty lazy and also fairly crap at knowing all the right knobs to twiddle in python (and perl) to best leverage their APIs. Hopefully this is useful. Patches welcome :p 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] [RFC PATCH 1/2] Replace mkostemp+unlink with open(O_TMPFILE)
On Mon, Jan 27, 2014 at 05:54:58PM +0100, Kay Sievers wrote: On Mon, Jan 27, 2014 at 5:35 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Jan 27, 2014 at 03:14:28PM +0100, Lennart Poettering wrote: Yupp, it's certainly a good idea to make our logging functions safe for execution in any context. What I don't understands though is why mkostemp() would not be safe here? mkostemp is not on the list of safe functions. I looked at the implementation, and it actually has a static variable, so it really cannot be called. But does this matter here? The static var is still mixed with random. It seems it will work just fine, at least with the next iteration? I guess it's a question whether we want to rely on a specific implementation, or on the promises made by standards/documentation. mkostemp might call the random number generator, which might modify some global state, etc, which could be visible from outside of the signal handler. It just feels risky to make promises about this. writev should probably be safe... OTOH, it's trivial to reimplement. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH 1/2] Replace mkostemp+unlink with open(O_TMPFILE)
On Mon, Jan 27, 2014 at 06:40:39PM +0100, Zbigniew Jędrzejewski-Szmek wrote: On Mon, Jan 27, 2014 at 05:54:58PM +0100, Kay Sievers wrote: On Mon, Jan 27, 2014 at 5:35 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Jan 27, 2014 at 03:14:28PM +0100, Lennart Poettering wrote: Yupp, it's certainly a good idea to make our logging functions safe for execution in any context. What I don't understands though is why mkostemp() would not be safe here? mkostemp is not on the list of safe functions. I looked at the implementation, and it actually has a static variable, so it really cannot be called. But does this matter here? The static var is still mixed with random. It seems it will work just fine, at least with the next iteration? I guess it's a question whether we want to rely on a specific implementation, or on the promises made by standards/documentation. mkostemp might call the random number generator, which might modify some global state, etc, which could be visible from outside of the signal handler. It just feels risky to make promises about this. Yeah, it's hard to tell because of all the ifdefs, but it might call gettimeofday, which rules it out. writev should probably be safe... OTOH, it's trivial to reimplement. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH 1/2] Replace mkostemp+unlink with open(O_TMPFILE)
On Mon, Jan 27, 2014 at 6:40 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Jan 27, 2014 at 05:54:58PM +0100, Kay Sievers wrote: On Mon, Jan 27, 2014 at 5:35 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Jan 27, 2014 at 03:14:28PM +0100, Lennart Poettering wrote: Yupp, it's certainly a good idea to make our logging functions safe for execution in any context. What I don't understands though is why mkostemp() would not be safe here? mkostemp is not on the list of safe functions. I looked at the implementation, and it actually has a static variable, so it really cannot be called. But does this matter here? The static var is still mixed with random. It seems it will work just fine, at least with the next iteration? I guess it's a question whether we want to rely on a specific implementation, or on the promises made by standards/documentation. I think the status-quo of glibc is good enough for us to define our expectations. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH 1/2] Replace mkostemp+unlink with open(O_TMPFILE)
On Mon, 27.01.14 18:40, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Mon, Jan 27, 2014 at 05:54:58PM +0100, Kay Sievers wrote: On Mon, Jan 27, 2014 at 5:35 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Jan 27, 2014 at 03:14:28PM +0100, Lennart Poettering wrote: Yupp, it's certainly a good idea to make our logging functions safe for execution in any context. What I don't understands though is why mkostemp() would not be safe here? mkostemp is not on the list of safe functions. I looked at the implementation, and it actually has a static variable, so it really cannot be called. But does this matter here? The static var is still mixed with random. It seems it will work just fine, at least with the next iteration? I guess it's a question whether we want to rely on a specific implementation, or on the promises made by standards/documentation. mkostemp might call the random number generator, which might modify some global state, etc, which could be visible from outside of the signal handler. It just feels risky to make promises about this. Maybe we should just implement our own version of mkostemp() for this, which uses /dev/urandom instead of the RNG. ANd that always use that, even in the non async-signal-safe case... This is not time-critical and a fall-back anyway, so I don't see an issue here. I just really don't like exposing two codepaths to the user. I want one version that works for everybody, because people are highly like to misuse this otherwise. Logging is so basic that people shouldn't be able to fuck it up... That said, I am pretty happy to just assume glibc behaviour here as sane behaviour and ignore other implementations. It is relatively safe to assume that the glibc guys are aware of the async-signal safety problems and won't make this worse... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH 1/2] Replace mkostemp+unlink with open(O_TMPFILE)
On Mon, Jan 27, 2014 at 6:27 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Jan 27, 2014 at 05:57:56PM +0100, Kay Sievers wrote: Can we expect open(O_TMPFILE) to fail on kernels which do not support it? I guess they will just silently ignore it? Then we never unlink? No, it is supposed to fail properly if it doesn't work. The flags were changed to be incompatible with old kernels. We should probably have a unit test for that. I have a small utility I was using for tests, I'll dig it up. Oh, any idea how this works? I couldn't see any kernel code that checks for currently unused flags and fails. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH 1/2] Replace mkostemp+unlink with open(O_TMPFILE)
On Mon, 27.01.14 19:09, Lennart Poettering (lenn...@poettering.net) wrote: I just really don't like exposing two codepaths to the user. I want one version that works for everybody, because people are highly like to misuse this otherwise. Logging is so basic that people shouldn't be able to fuck it up... To clarify this: I neither like having two codepaths essentially doing the same here, and one tested and the other one barely... Nor do I like even given the caller control about this. I mean, we can make sure for our own code that we handle async signal safety properly, but it appears like a difficult request to make to other people... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH 1/2] Replace mkostemp+unlink with open(O_TMPFILE)
On Mon, Jan 27, 2014 at 07:15:23PM +0100, Kay Sievers wrote: On Mon, Jan 27, 2014 at 6:27 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Jan 27, 2014 at 05:57:56PM +0100, Kay Sievers wrote: Can we expect open(O_TMPFILE) to fail on kernels which do not support it? I guess they will just silently ignore it? Then we never unlink? No, it is supposed to fail properly if it doesn't work. The flags were changed to be incompatible with old kernels. We should probably have a unit test for that. I have a small utility I was using for tests, I'll dig it up. Oh, any idea how this works? I couldn't see any kernel code that checks for currently unused flags and fails. open(/tmp, O_TMPFILE|O_RDWR, S_IRUSR | S_IWUSR) returns -1, errno=EISDIR on Linux 3.9. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH 1/2] Replace mkostemp+unlink with open(O_TMPFILE)
On Mon, Jan 27, 2014 at 7:50 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Jan 27, 2014 at 07:15:23PM +0100, Kay Sievers wrote: On Mon, Jan 27, 2014 at 6:27 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Mon, Jan 27, 2014 at 05:57:56PM +0100, Kay Sievers wrote: Can we expect open(O_TMPFILE) to fail on kernels which do not support it? I guess they will just silently ignore it? Then we never unlink? No, it is supposed to fail properly if it doesn't work. The flags were changed to be incompatible with old kernels. We should probably have a unit test for that. I have a small utility I was using for tests, I'll dig it up. Oh, any idea how this works? I couldn't see any kernel code that checks for currently unused flags and fails. open(/tmp, O_TMPFILE|O_RDWR, S_IRUSR | S_IWUSR) returns -1, errno=EISDIR on Linux 3.9. Yeah, but what happens for a /tmp/does-not-exist request? :) Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH 1/2] Replace mkostemp+unlink with open(O_TMPFILE)
On Mon, Jan 27, 2014 at 07:53:51PM +0100, Kay Sievers wrote:
On Mon, Jan 27, 2014 at 7:50 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Mon, Jan 27, 2014 at 07:15:23PM +0100, Kay Sievers wrote:
On Mon, Jan 27, 2014 at 6:27 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
On Mon, Jan 27, 2014 at 05:57:56PM +0100, Kay Sievers wrote:
Can we expect open(O_TMPFILE) to fail on kernels which do not support
it?
I guess they will just silently ignore it? Then we never unlink?
No, it is supposed to fail properly if it doesn't work. The flags were
changed to be incompatible with old kernels. We should probably have a
unit test for that. I have a small utility I was using for tests, I'll
dig it up.
Oh, any idea how this works? I couldn't see any kernel code that
checks for currently unused flags and fails.
open(/tmp, O_TMPFILE|O_RDWR, S_IRUSR | S_IWUSR)
returns -1, errno=EISDIR on Linux 3.9.
Yeah, but what happens for a /tmp/does-not-exist request? :)
It returns -1/ENOENT (all versions).
For /tmp/exists -1/ENOTDIR (all versions).
See for yourself :) :
#define _GNU_SOURCE
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include unistd.h
#include stdio.h
int main(int argc, char** argv) {
int fd = open(argv[1], O_TMPFILE|O_RDWR, S_IRUSR | S_IWUSR);
printf(fd=%d %m\n, fd);
sleep(1000);
return 0;
}
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH 1/2] Replace mkostemp+unlink with open(O_TMPFILE)
On Mon, 2014-01-27 at 19:53 +0100, Kay Sievers wrote: Can we expect open(O_TMPFILE) to fail on kernels which do not support it? Yeah, but what happens for a /tmp/does-not-exist request? :) #define O_TMPFILE (__O_TMPFILE | O_DIRECTORY) the O_DIRECTORY part should make it fail. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] making a python daemon both systemd and el5 compatible
- Original Message - From: Greg Swift gregsw...@gmail.com To: systemd-devel@lists.freedesktop.org Sent: Tuesday, January 28, 2014 3:20:46 AM Subject: [systemd-devel] making a python daemon both systemd and el5 compatible I'm working on a small daemon[1] that doesn't do a whole lot, but we need it to work on RHEL5+. Going out of the gate I want to ensure it also works with systemd, since i want it to be usable on fedora and el7. This stackoverflow[2] has a method, but then mentions some compatibility problems with the library it recommends that seem like it will not make it to friendly back to el5. In the interm I was going to try leveraging cherrypy's bits (PIDFile and Daemonize), but they aren't backwards compatible to EL5, so we have to fix that. I tried to find some place where this was mentioned or recommended but my google-fu failed me. Do you have any recommendations or a existing python daemon that you could point me at that has similar needs? The Beaker project's daemons (beakerd, beaker-proxy, beaker-watchdog and beaker-provision) adopts a policy that if it is on a distro which doesn't have systemd, it uses the SysV init files and vice-versa. The spec file here [1] should give you some idea about what we are doing. Specifically, w.r.t python-daemon, on the SO thread you mention, I had replied with my experience here [2] and I wrote further on this here [3]. Specifically, this may be helpful for you: In the [Service] section, the Type is set to Forking. This is because, beakerd uses python-daemon which forks itself (detaches itself) during the daemonization. However, you must ensure that when creating a DaemonContext() object, you should specify detach_process=True. This is because, if python-daemon detects that it is running under a init manager, it doesn’t detach itself unless the keyword is explicitly set to True, as above (you can see the code in daemon.py). Hence, although not setting the above keyword would work under SysV Init, it doesn’t work under systemd (with Type=Forking), since the daemon doesn’t fork at all and systemd expects it to fork (and finally kills it). The PIDFile specifies where the process ID is dumped by beakerd and is setup while creating the DaemonContext object as follows and ExecStart specifies the location to the binary that is to be started. [1] http://git.beaker-project.org/cgit/beaker/plain/beaker.spec?h=develop [2] http://stackoverflow.com/a/17848250 [3] http://echorand.me/2013/08/02/notes-on-writing-systemd-unit-files-for-beakers-daemon-processes/ Hope those give you some ideas and point you towards the right direction. Best, Amit. -- Amit Saha http://echorand.me ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH 1/2] Replace mkostemp+unlink with open(O_TMPFILE)
On Mon, Jan 27, 2014 at 07:11:49PM +0100, Lennart Poettering wrote: On Mon, 27.01.14 19:09, Lennart Poettering (lenn...@poettering.net) wrote: I just really don't like exposing two codepaths to the user. I want one version that works for everybody, because people are highly like to misuse this otherwise. Logging is so basic that people shouldn't be able to fuck it up... To clarify this: I neither like having two codepaths essentially doing the same here, and one tested and the other one barely... Nor do I like even given the caller control about this. I mean, we can make sure for our own code that we handle async signal safety properly, but it appears like a difficult request to make to other people... Yeah. The idea of two codepaths was crazy. I've now committed a version which reimplements mkostemp and provides the guarantee always. Zbyszek ___ 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:48:38PM +0400, Andrey Borzenkov wrote: 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 Done. After a job has been running for more than 5s, or a failure occurs, cylon eye will be shown. Also status will be printed until bootup or shutdown is completed. systemd 208 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ) Detected virtualization 'systemd-nspawn'. [FAILED] Failed to start bad.service. See 'systemctl status bad.service' for details. Starting Permit User Sessions... [ OK ] Started Cleanup of Temporary Directories. [ OK ] Started Permit User Sessions. Starting Console Getty... [ OK ] Started Console Getty. [ OK ] Reached target Login Prompts. [ OK ] Reached target Multi-User System. [ OK ] Reached target Graphical Interface. Fedora release 21 (Rawhide) Kernel 3.13.0-0.rc5.git0.2.fc21.x86_64 on an x86_64 (console) fedora-21 login: root ___ 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
2014-01-28 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl: Done. After a job has been running for more than 5s, or a failure occurs, cylon eye will be shown. Also status will be printed until bootup or shutdown is completed. You are awesome, thanks man! ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
