Re: [systemd-devel] [PATCH] core: get rid the start job when transitioning to deactivating
Dne 18.7.2013 20:02, Lennart Poettering napsal(a):
On Thu, 18.07.13 17:04, Michal Sekletar (msekl...@redhat.com) wrote:
When dependency unit is configured with StopWhenUnneeded=yes and
activation of main unit fails, e.g. start timeout occurs, then
dependencies are never stopped. This happens because start job for
the main unit is still around.
---
src/core/unit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/unit.c b/src/core/unit.c
index 0e9329f..d5c89a4 100644
--- a/src/core/unit.c
+++ b/src/core/unit.c
@@ -1461,7 +1461,7 @@ void unit_notify(Unit *u, UnitActiveState os,
UnitActiveState ns, bool reload_su
else if (u-job-state == JOB_RUNNING ns !=
UNIT_ACTIVATING) {
unexpected = true;
-if (UNIT_IS_INACTIVE_OR_FAILED(ns))
+if (UNIT_IS_INACTIVE_OR_FAILED(ns) ||
UNIT_IS_INACTIVE_OR_DEACTIVATING(ns))
job_finish_and_invalidate(u-job, ns
== UNIT_FAILED ? JOB_FAILED : JOB_DONE, true);
}
Hmm, so UNIT_IS_INACTIVE_OR_DEACTIVATING() actually tests for a superset
of UNIT_IS_INACTIVE_OR_FAILED(), so oring them is unnecessary.
I am not entirely grokking the patch though. So far the idea was that if
a unit is being deactviated while a start job is queued that we then
simply wait until the deactivation is complete and then execute the
start job. This would break with your patch though...
Hmm, can you eleraborate on the actual problem you are trying to solve=
I don't get it so far ;-)
Thanks,
Lennart
Dne 18.7.2013 20:02, Lennart Poettering napsal(a):
On Thu, 18.07.13 17:04, Michal Sekletar (msekl...@redhat.com) wrote:
When dependency unit is configured with StopWhenUnneeded=yes and
activation of main unit fails, e.g. start timeout occurs, then
dependencies are never stopped. This happens because start job for
the main unit is still around.
---
src/core/unit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/unit.c b/src/core/unit.c
index 0e9329f..d5c89a4 100644
--- a/src/core/unit.c
+++ b/src/core/unit.c
@@ -1461,7 +1461,7 @@ void unit_notify(Unit *u, UnitActiveState os,
UnitActiveState ns, bool reload_su
else if (u-job-state == JOB_RUNNING ns !=
UNIT_ACTIVATING) {
unexpected = true;
-if (UNIT_IS_INACTIVE_OR_FAILED(ns))
+if (UNIT_IS_INACTIVE_OR_FAILED(ns) ||
UNIT_IS_INACTIVE_OR_DEACTIVATING(ns))
job_finish_and_invalidate(u-job, ns
== UNIT_FAILED ? JOB_FAILED : JOB_DONE, true);
}
Hmm, so UNIT_IS_INACTIVE_OR_DEACTIVATING() actually tests for a superset
of UNIT_IS_INACTIVE_OR_FAILED(), so oring them is unnecessary.
I am not entirely grokking the patch though. So far the idea was that if
a unit is being deactviated while a start job is queued that we then
simply wait until the deactivation is complete and then execute the
start job. This would break with your patch though...
Hmm, can you eleraborate on the actual problem you are trying to solve=
I don't get it so far ;-)
Thanks,
Lennart
Hi,
when service has StopWhenUnneeded=yes and it is requested by forking
service, which fails during initialization, the first unit is not stopped.
Reproducer:
-bash-4.2# more /etc/systemd/system/test*
::
/etc/systemd/system/test.service
::
[Unit]
Description=aaa
Requires=testb.service
[Service]
Type=forking
ExecStart=/bin/sleep 50
TimeoutStartSec=3
::
/etc/systemd/system/testb.service
::
[Unit]
Description=aaa
StopWhenUnneeded=yes
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/echo hej
ExecStop=/bin/echo hou
-bash-4.2# systemctl status testb test
testb.service - aaa
Loaded: loaded (/etc/systemd/system/testb.service; static)
Active: inactive (dead)
test.service - aaa
Loaded: loaded (/etc/systemd/system/test.service; static)
Active: inactive (dead)
-bash-4.2# systemctl start test
Job for test.service failed. See 'systemctl status test.service' and
'journalctl -xn' for details.
-bash-4.2# systemctl status testb test
testb.service - aaa
Loaded: loaded (/etc/systemd/system/testb.service; static)
Active: active (exited) since Thu 2013-07-18 15:34:34 CEST; 7s ago
Process: 45 ExecStart=/bin/echo hej (code=exited, status=0/SUCCESS)
Jul 18 15:34:34 mycontainer systemd[1]: Starting aaa...
Jul 18 15:34:34 mycontainer systemd[1]: Started aaa.
test.service - aaa
Loaded: loaded (/etc/systemd/system/test.service; static)
Active: failed (Result: timeout) since Thu 2013-07-18 15:34:37 CEST;
4s ago
Process: 46 ExecStart=/bin/sleep 50 (code=killed, signal=TERM)
Jul 18 15:34:34 mycontainer systemd[1]: Starting aaa...
Jul 18 15:34:37 mycontainer systemd[1]: test.service
[systemd-devel] [PATCH] systemctl: warn about use of deprecated options
---
I should have thought about it in previous commit, sorry for that!
---
src/systemctl/systemctl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index c9f9981..f09ccca 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -5012,6 +5012,7 @@ static int systemctl_parse_argv(int argc, char *argv[]) {
* in --types= too for compatibility
* with old versions */
if (unit_load_state_from_string(optarg) = 0) {
+log_warning(Using --type for load
states is depreciated, please use --state instead.);
if (strv_push(arg_states, type) 0)
return log_oom();
type = NULL;
@@ -5128,6 +5129,7 @@ static int systemctl_parse_argv(int argc, char *argv[]) {
break;
case ARG_FAILED:
+log_warning(Use of --failed is deprecated, please use
--state=failed instead.);
if (strv_extend(arg_states, failed) 0)
return log_oom();
--
1.8.3.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCHv2] systemctl: warn about use of deprecated options
---
I should have thought about it in previous commit, sorry for that!
since v1:
* fixed typo
---
src/systemctl/systemctl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index c9f9981..f09ccca 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -5012,6 +5012,7 @@ static int systemctl_parse_argv(int argc, char *argv[]) {
* in --types= too for compatibility
* with old versions */
if (unit_load_state_from_string(optarg) = 0) {
+log_warning(Using --type for load
states is deprecated, please use --state instead.);
if (strv_push(arg_states, type) 0)
return log_oom();
type = NULL;
@@ -5128,6 +5129,7 @@ static int systemctl_parse_argv(int argc, char *argv[]) {
break;
case ARG_FAILED:
+log_warning(Use of --failed is deprecated, please use
--state=failed instead.);
if (strv_extend(arg_states, failed) 0)
return log_oom();
--
1.8.3.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv2] systemctl: warn about use of deprecated options
On Fri, Jul 19, 2013 at 11:21:04AM +0200, Maciej Wereski wrote:
if (unit_load_state_from_string(optarg) =
0) {
+log_warning(Using --type for load
states is deprecated, please use --state instead.);
No, there's nothing wrong with using --type. This warning
would just be noise, breaking scripts.
Zbyszek
--
they are not broken. they are refucktored
-- alxchk
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: Fix exmaple to use the new --boot syntax
On Fri, Jul 19, 2013 at 01:54:51PM +0200, Jan Janssen wrote: --- man/journalctl.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied. Zbyszek -- they are not broken. they are refucktored -- alxchk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] tmpfiles: Fix memory leak in parse_line()
---
src/tmpfiles/tmpfiles.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 555347a..4a1ce36 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -119,6 +119,14 @@ static const char conf_file_dirs[] =
#define MAX_DEPTH 256
+static void item_free(Item *);
+static inline void item_freep(Item **i) {
+if (*i)
+item_free(*i);
+}
+
+#define _cleanup_item_free_ _cleanup_(item_freep)
+
static bool needs_glob(ItemType t) {
return t == IGNORE_PATH || t == IGNORE_DIRECTORY_PATH || t ==
REMOVE_PATH || t == RECURSIVE_REMOVE_PATH || t == RELABEL_PATH || t ==
RECURSIVE_RELABEL_PATH;
}
@@ -1013,7 +1021,7 @@ static bool item_equal(Item *a, Item *b) {
}
static int parse_line(const char *fname, unsigned line, const char *buffer) {
-_cleanup_free_ Item *i = NULL;
+_cleanup_item_free_ Item *i = NULL;
Item *existing;
_cleanup_free_ char
*mode = NULL, *user = NULL, *group = NULL, *age = NULL;
--
1.8.3.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: Fix memory leak in parse_line()
On Fri, Jul 19, 2013 at 03:43:12PM +0200, Maciej Wereski wrote: --- src/tmpfiles/tmpfiles.c | 10 +- 1 file changed, 9 insertions(+), 1 deletion(-) Applied, but moved the cleanup function definition down to avoid forward declaration. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] runtime directories for services vs. tmpfiles
Le mardi 16 juillet 2013 à 17:59 +0100, Colin Guthrie a écrit : 'Twas brillig, and Kay Sievers at 16/07/13 17:24 did gyre and gimble: On Tue, Jul 16, 2013 at 6:01 PM, Lennart Poettering lenn...@poettering.net wrote: Hmm, I'd like such an automatism, but I'd really prefer if we could come up with some scheme to automatically determine all tmpfiles snippets in the package and apply them all automatically. But I am not sure how that could be done with current RPM. In fact, I'd actually like to do the same for the %systemd_post macros, and suchlike, where people tend to be pretty bad at always listing all unit files correctly. Actually rereading this bit above, I can see the desire for automated snippets, but are there not some cases where you would want to avoid calling %systemd_post macros for some shipped units? e.g. they may only be used internally by others (Requires=, Also= and similar). I think such automation might not be good. (just look at the NFS units which I think we've finally cleaned up a bit in Mageia - enough to actually work at least). Hmm, an rpmlint check for stuff like this maybe is the first step? At least people who care and look at that would fix their stuff? Misc was looking at doing most of that. Not sure what you mean about naming tho'... do you just mean the folder name (etc vs usr) or just not picking very nice unit names? For the folder, I put rpmlint checks in Mageia a while ago to ban units, tmpfiles and udev rules from shipping in /etc. And another to do with non-ghost files in /run or /var/run. I had it in my head that I'd spoken to Misc about this at the time I wrote them but now I have a paranoid fear that maybe I didn't... They are simple enough anyway, so if they are not upstream and have instead been reimplemented then it's no great loss, but apologies if forgot to ping you at the time Misc (and I've seen you twice in person since then too!!) Patches here. Can't check if it's upstream yet as rpmlint.zarb.org is down for now... We are now on sf.net. And someone already contacted me to get the patches, I said i was ok on the principle, but from the code point of view, it could have been refactored ( but I didn't do it yet ); IE having a structure like : ['regexp','name-of-exception','message'], have it exposed in the configuration and have a generic module using this, so every distribution could add them. IIRC, Suse do have this kind of patchs, but I didn't merged them yet. -- Michael Scherer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] console-getty.service: conflict with vconsole-setup
Lennart Poettering wrote: /dev/tty0 always points to the foreground VC tty. Are you saying UML provides /dev/tty0 but not /dev/tty1, /dev/tty2, ...? I am pretty sure that UML should be fixed to provide neither or both, evertyhing else is broken. Thanks for all the information. With some help from Al, I finally figured out what's happening: 0. um Linux does not do VT102 emulation. This is a known limitation. 1. In its default configuration, it connects the guest's /dev/console to the host's fd:0,fd:1. 2. In its default configuration (I just sent a patch changing this), it connects the guest's /dev/tty[1-16] to a /dev/pts/N on the the host (allocated dynamically). Then, to get a prompt on the guest, the user can do `screen /dev/pts/N` or `minicom /dev/pts/N` on the host. 3. It provides con#= and ssl#= kernel parameters to override how all the console and serial devices on the guest should be connected to the host. So, I can provide a patch for getty-generator to detect um Linux and switch to getty on /dev/console, but vconsole-setup will still fail; what should we do about that? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] console-getty.service: conflict with vconsole-setup
On Fri, Jul 19, 2013 at 11:50:53PM +0530, Ramkumar Ramachandra wrote: [intertesting analysis removed] So, I can provide a patch for getty-generator to detect um Linux and switch to getty on /dev/console, but vconsole-setup will still fail; what should we do about that? Make systemd-vconsole-setup.service conditional on ConditionVirtualization=!uml? I don't think any of that setup is needed in that case. Zbyszek -- they are not broken. they are refucktored -- alxchk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] vconsole-setup: setup negative conditional on uml
User-Mode Linux does not do VT102 emulation, and $ vconsole-setup /dev/tty0 will always fail on it. In order to prevent vconsole-setup.service from always failing, disable it when uml is detected. Cc: Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl Cc: Lennart Poettering lenn...@poettering.net Signed-off-by: Ramkumar Ramachandra artag...@gmail.com --- units/systemd-vconsole-setup.service.in | 1 + 1 file changed, 1 insertion(+) diff --git a/units/systemd-vconsole-setup.service.in b/units/systemd-vconsole-setup.service.in index 18faa63..3dc3153 100644 --- a/units/systemd-vconsole-setup.service.in +++ b/units/systemd-vconsole-setup.service.in @@ -13,6 +13,7 @@ Conflicts=shutdown.target After=systemd-readahead-collect.service systemd-readahead-replay.service Before=sysinit.target shutdown.target ConditionPathExists=/dev/tty0 +ConditionVirtualization=!uml [Service] Type=oneshot -- 1.8.3.3.797.gb72c616.dirty ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] make: Automake is complaining about .PRECIOUS being redefined
On Thu, Jul 18, 2013 at 09:18:55AM +0200, Holger Hans Peter Freyther wrote: From: Holger Hans Peter Freyther hol...@moiji-mobile.com Yesterday I added test-suite.log as dependency to the .PRECIOUS target. Automake is warning about this target being redefined and from what I see there is no way I can stop the warning but I can add the %MAKEFILE% as dependency. automake warning: Makefile.am:35: warning: user target '.PRECIOUS' defined here ... /usr/share/automake-1.13/am/configure.am: ... overrides Automake target '.PRECIOUS' defined here Applied for now. But that looks like a plain automake bug. It should know that targets starting with a dot are not real targets. Could you file a bug report with automake, so this gets fixed properly? Zbyszek --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index e598585..c9b0715 100644 --- a/Makefile.am +++ b/Makefile.am @@ -32,7 +32,7 @@ SUBDIRS = . po .SECONDARY: # Keep the test-suite.log -.PRECIOUS: $(TEST_SUITE_LOG) +.PRECIOUS: $(TEST_SUITE_LOG) %MAKEFILE% LIBUDEV_CURRENT=4 LIBUDEV_REVISION=6 -- 1.8.3.2 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- they are not broken. they are refucktored -- alxchk ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [IDEA] systemd as basis for HA clusters
Hi all, I was wondering how much systemd could add to current high availability cluster setups. Today systemd is used on HA clusters as just an init replacement. However, there are systemd features that might come in handy and improve the overall performance and even reliability of such clusters: * watchdog functionality as in http://0pointer.de/blog/projects/watchdog.html is the most evident feature; * tcp-based dbus communication could be used to exchange information between cluster members; Also, I believe systemd functionality could be extended so it would take into consideration other nodes' systemd instances in order to make sure each service is always alive somewhere -- call it floating units if you will. :-) Does this idea even make sense? Is it too one systemd to rule them all? -- Pablo Hess ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 0/2] Finishing touches for User-Mode Linux
Hi, These are the finishing touches required to make User-Mode Linux work out-of-the-box. Sorry it took so long: I had to build with abs and test it for good. Thanks again, for all the help. Ramkumar Ramachandra (2): getty-generator: run console shell for uml vconsole-setup: setup negative conditional on uml src/getty-generator/getty-generator.c | 3 ++- units/systemd-vconsole-setup.service.in | 1 + 2 files changed, 3 insertions(+), 1 deletion(-) -- 1.8.3.3.797.gb72c616.dirty ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] getty-generator: run console shell for uml
In its default configuration, um Linux connects its /dev/console to the
host's fd:0,fd:1. Other tty devices (/dev/tty*) are accessible on
various host devices that the user must connect to explicitly. By
running getty on /dev/console by default,
$ ./linux ubd0=arch-rootfs
will display a prompt immediately on the same terminal, along with the
boot messages. This is much more user-friendly, than making the user
explicitly connect to the right device using
$ screen /dev/pts/8
to get a login prompt.
Cc: Thomas Bächler tho...@archlinux.org
Cc: Lennart Poettering lenn...@poettering.net
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
src/getty-generator/getty-generator.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/getty-generator/getty-generator.c
b/src/getty-generator/getty-generator.c
index 4b7a60a..9c7ed1a 100644
--- a/src/getty-generator/getty-generator.c
+++ b/src/getty-generator/getty-generator.c
@@ -96,6 +96,7 @@ int main(int argc, char *argv[]) {
int r = EXIT_SUCCESS;
char *active;
const char *j;
+const char *id = NULL;
if (argc 1 argc != 4) {
log_error(This program takes three or no arguments.);
@@ -111,7 +112,7 @@ int main(int argc, char *argv[]) {
umask(0022);
-if (detect_container(NULL) 0) {
+if (detect_container(NULL) 0 || (detect_vm(id) 0 !strcmp(id,
uml))) {
log_debug(Automatically adding console shell.);
if (add_symlink(console-getty.service,
console-getty.service) 0)
--
1.8.3.3.797.gb72c616.dirty
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] removal of RD_TIMESTAMP support in initrd
Hi, With systemd 206 near release, I'd like to understand if commit c72aadd1851096ea is going to stand. This commit removes support for reading RD_TIMESTAMP in the initramfs, and thus makes systemd mandatory for measuring initramfs runtime. If this is the intended future, please help me to understand the rationale behind removing 25 lines of code for a useful feature -- one which has extremely low overhead and is self contained code-wise. I strongly object to the way this was done and would appreciate a more official explanation. Cheers, Dave ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] question about SecureBits / NoNewPrivileges
Hi i try to secure the Apache-Webserver (mpm-prefork) as much as possible am i right that with the following settings in the systemd-unit after the child-process is forked with the apache user and the capabilities are reduced as below even a potential root exploit would have no success? SecureBits=noroot fails i guess because it even disallows the parent-process to run as root after start SecureBits=noroot-locked NoNewPrivileges=yes CapabilityBoundingSet=CAP_CHOWN CAP_SETGID CAP_SETUID CAP_DAC_OVERRIDE CAP_KILL CAP_NET_BIND_SERVICE CAP_IPC_LOCK _ [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/httpd.service [Unit] Description=Apache Webserver After=network.service [Service] Type=simple EnvironmentFile=-/etc/sysconfig/httpd ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND ExecReload=/usr/sbin/httpd $OPTIONS -k graceful ExecStop=/usr/sbin/httpd $OPTIONS -k graceful-stop KillSignal=SIGCONT TimeoutStopSec=2 Restart=always RestartSec=1 UMask=006 PrivateTmp=yes SecureBits=noroot-locked NoNewPrivileges=yes CapabilityBoundingSet=CAP_CHOWN CAP_SETGID CAP_SETUID CAP_DAC_OVERRIDE CAP_KILL CAP_NET_BIND_SERVICE CAP_IPC_LOCK InaccessibleDirectories=/boot InaccessibleDirectories=/home InaccessibleDirectories=/root InaccessibleDirectories=/var/lib/rpm InaccessibleDirectories=/var/spool [Install] WantedBy=multi-user.target signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
