Re: [systemd-devel] [PATCH 0/1] systemd will fail to compile if libgcrypt is missing
On Sat, 02.11.13 02:11, Djalal Harouni (tix...@opendz.org) wrote: Hi list, I'm doing some systemd testing on clean machines. I'm building from git tree, and I've noticed that systemd autogen.sh will fail if the libgcrypt and its headers are missing, this will produce a buggy configure script. This is expected that way. If you build from git you need a few additional dependencies. The automatic dependency checks in configure.ac are only used for tarball builds, they are irrelevant for the git builds. Or in other words: if you build from git you need to know what you are doing, you need to install autoconf/automake/libtool and friends first, and a number of other dependencies, and these will not be automatically detected, and that's intended that way. There's not to fix here. 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] Power aware units
On 11/03/2013 02:36 PM, Bastien Nocera wrote: In addition to that, would it make sense for distributions to start porting their cron jobs to use systemd? in Fedora we already have started that migration process for relevant units ( not all packages that contain ron jobs should be/will be migrated ). I've just been waiting ( since July/August ) for the first step of that migration to be completed as in those packages that will not be migrated fix their dependency on crontabs. Ones those packagers apply the patches I sent them in that regard I will start the actual cron to timer units migration. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Power aware units
On Sun, 03.11.13 15:36, Bastien Nocera (had...@hadess.net) wrote: Heya, systemd already allows launching specific tasks based on a timer, and intervals, and I was wondering whether power awareness was something planned for launching and stopping units. MacOS X 10.9 has some additional metadata for units that allows launchd to stop and start particular tasks based on power levels: http://arstechnica.com/apple/2013/10/os-x-10-9/16/ So, hmm. So far our policy on Linux was mostly If something good for battery cases, then it is good for AC cases too, i.e. the dichotomy between services that may run on battery and that may not be run on on battery is not necessarily a good one. I am really wondering hence whether policies like this one really should exist at all? And to figure that out we probably should look closely at the usecases. So, what are the use cases? You listed: - backups - tmpfiles/cache ageing (including trash expulsion, thumbnail cleanup) - update-db And I figure other ones to add here are: - mandb cache cleanups - rotation of legacy log files (are there more usecases you can come up with?) All these are exclusively cronjobs, i.e. services triggered only by time, and nothing else. And all of these strike me as things where we really should run them on battery too, as not doing them at all will sooner or later have a negative effect on the stability and safety of the system. So, thinking about this I have the suspicion all that we really can do is modulate the timers a bit: i.e. if the system is on battery power simply lower the frequency how often we dispatch timer events. More specifically: what about adding a new option for .timer units maybe called BatterySlackSec= or so, where you can specify some extra time the execution of the job can be delayed for at maximum if the machine is on battery. If it is not on battery we'd ignore this value. If the machine changes from on battery to on ac we'd immediately execute all services which are already in their battery slack phase. This would then allow people to easily express things like Clean-up /tmp every day, but if I am on battery delay it for another day at max, and possibly exeucte it immediately if I replug power. Or something similar. So, would this make sense to you? Is there anything this logic wouldn't cover? (Oh, and also note that there actually already is ConditionACPower= which allows you to skip execution of certain services if AC is plugged in/is not plugged in. See systemd.unit(5) for details). We could implement this in 2 ways: - systemd itself speaks over D-Bus to UPower (using the new DisplayDevice to merge UPS and batteries) and stop/starts the units. I am a bit afraid of making systemd depend on external daemons for things like this. Making systemd a client to another service that is started by systemd, is always problematic, due to potential deadlocks and cyclic deps. We are currently working on getting rid of a dependency like this in regards to dbus-daemon where kdbus makes this all nice and clean for us, and I'd really prefer not to add another case like this... I don't even think this would be necessary really. The power source kernel device class is sufficiently simple for us to use directly, going via upower doesn't appear necessary (I mean, for this logic we don't need battery states of mice and suchlike, hence this shouldn't be a problem.) In addition to that, would it make sense for distributions to start porting their cron jobs to use systemd? It certainly would make sense, but my plan was to first add a couple of things to our timer logic implementation that is substantially better than classic cron so that we have strong case to make why people should adopt it. However, never found the time to work on this. 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] Need advice on daemon's architecture
On Sun, 03.11.13 10:40, Peter Lemenkov (lemen...@gmail.com) wrote: Hello All! I'm working on a system service which uses systemd intensively. Right now it's socket-activated, with main service of type simple. I recently added support for querying and publishing some internals via D-Bus, so it has a D-Bus name now. Does it add anything if I change type of a main service to dbus thus allowing systemd to know for sure if my service is fully initialized? Type=notify or Type=dbus are usually the best choices and is what I'd recommend. The former requires you to use sd_notify(), the latter requires you to make your service a bus service. Type=forking is the nastiest choice. Type=simple is an OK choice too, but doesn't pass as much state information to systemd as the other options. 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] Need advice on daemon's architecture
On Sun, 03.11.13 13:42, Hoyer, Marko (ADITG/SW2) (mho...@de.adit-jv.com) wrote: If you are using systemd intensively, then you may want to use Type=notify. With type=dbus, systemd will consider things ready when you take the name on the bus, but this might not actually be the last thing you do to initialise your daemon (although if this is the only interface for clients this is not a problem!). You still might want to use sd_notify() instead. This can also pass through some internal performance info to systemd which will show up on systemctl status output which is kinda nice. Col Isn't the classical Linux way an option too? Well, it is, but it is hard to get right and a lot of redundant code involved. - the daemon does its initialization with the calling thread - once it is done with the initialization, it forks off a process that goes on with the daemons work (the main loop probably) No, this is wrong. You really shouldn't do initialization in one process and then run the daemon from a forked off second one. A lot of (library) code is not happy with being initialized in one process and being used in another forked off one. For example, any code involving threads is generally allergic to this, since background threads cease to exist in the forked off child. This is nearly impossible to work around [1]. Or code involving file locks or even a lot of socket code doesn't like it either. In general you should not assume that any library can handle it, except for those cases where the library author explicitly tells you that it is safe. Actually, all systemd libraries (like libsystemd-journal or libsystem-bus) and a couple of my other libraries (like libcanberra) explicitly check for the PID changing and refuse operation in such cases, simply because the effects of fork()ing are so nasty. Or to be more explicit: if you initialize a sd_journal or sd_bus object in one process and then try to execute any operation on it in a forked off child process you will get -ECHILD returned which is how we indicate this misuage. So, what is the right way to do this? Fork off early, do the initialization in the child, and signal the parent that you are done via a pipe, so that the parent exits only after the child is done. This is explained in daemon(7). Or even better: don't bother at all, write your services without forking, and use Type=dbus or Type=notify instead. Lennart [1] Yeah, and don't tell me pthread_atfork() is the solution for this. It's not. It makes things even worse, since there's no defined execution order defined for it. If you claim pthread_atfork() was a solution and not a problem in itself, then you obviously have never used it, or only in trivial programs. -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Need advice on daemon's architecture
On 04/11/13 14:42, Lennart Poettering wrote: A lot of (library) code is not happy with being initialized in one process and being used in another forked off one. For what it's worth, fork(3posix) also notes this: * A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Consequently, to avoid errors, the child process may only execute async-signal-safe opera‐ tions until such time as one of the exec functions is called. See Linux signal(7) for a list of async-signal-safe operations: it's not as long a list as you might hope, and mostly contains syscalls. In particular, malloc() is not on the list, which rules out a lot of library code... S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] [RFC] Configurable Timeouts/Restarts default values
https://bugs.freedesktop.org/show_bug.cgi?id=71132
Patch adds DefaultTimeoutStartSec, DefaultTimeoutStopSec, DefaultRestartSec
configuration options to manager configuration file.
---
src/core/device.c| 2 +-
src/core/main.c | 9 +
src/core/manager.h | 3 +++
src/core/mount.c | 2 +-
src/core/scope.c | 2 +-
src/core/service.c | 6 +++---
src/core/socket.c| 2 +-
src/core/swap.c | 2 +-
src/core/system.conf | 3 +++
src/core/user.conf | 3 +++
10 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/src/core/device.c b/src/core/device.c
index 0595015..6fc4c95 100644
--- a/src/core/device.c
+++ b/src/core/device.c
@@ -70,7 +70,7 @@ static void device_init(Unit *u) {
* indefinitely for plugged in devices, something which cannot
* happen for the other units since their operations time out
* anyway. */
-UNIT(d)-job_timeout = DEFAULT_TIMEOUT_USEC;
+UNIT(d)-job_timeout = u-manager-default_timeout_start_usec;
UNIT(d)-ignore_on_isolate = true;
UNIT(d)-ignore_on_snapshot = true;
diff --git a/src/core/main.c b/src/core/main.c
index 5d30893..b21fb49 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -90,6 +90,9 @@ static bool arg_switched_root = false;
static char ***arg_join_controllers = NULL;
static ExecOutput arg_default_std_output = EXEC_OUTPUT_JOURNAL;
static ExecOutput arg_default_std_error = EXEC_OUTPUT_INHERIT;
+static usec_t arg_default_restart_usec = DEFAULT_RESTART_USEC;
+static usec_t arg_default_timeout_start_usec = DEFAULT_TIMEOUT_USEC;
+static usec_t arg_default_timeout_stop_usec = DEFAULT_TIMEOUT_USEC;
static usec_t arg_runtime_watchdog = 0;
static usec_t arg_shutdown_watchdog = 10 * USEC_PER_MINUTE;
static char **arg_default_environment = NULL;
@@ -636,6 +639,9 @@ static int parse_config_file(void) {
{ Manager, CPUAffinity,
config_parse_cpu_affinity2, 0, NULL},
{ Manager, DefaultStandardOutput, config_parse_output,
0, arg_default_std_output },
{ Manager, DefaultStandardError, config_parse_output,
0, arg_default_std_error },
+{ Manager, DefaultTimeoutStartSec, config_parse_sec,
0, arg_default_timeout_start_usec },
+{ Manager, DefaultTimeoutStopSec, config_parse_sec,
0, arg_default_timeout_stop_usec },
+{ Manager, DefaultRestartSec, config_parse_sec,
0, arg_default_restart_usec },
{ Manager, JoinControllers,
config_parse_join_controllers, 0, arg_join_controllers },
{ Manager, RuntimeWatchdogSec,config_parse_sec,
0, arg_runtime_watchdog},
{ Manager, ShutdownWatchdogSec, config_parse_sec,
0, arg_shutdown_watchdog },
@@ -1518,6 +1524,9 @@ int main(int argc, char *argv[]) {
m-confirm_spawn = arg_confirm_spawn;
m-default_std_output = arg_default_std_output;
m-default_std_error = arg_default_std_error;
+m-default_restart_usec = arg_default_restart_usec;
+m-default_timeout_start_usec = arg_default_timeout_start_usec;
+m-default_timeout_stop_usec = arg_default_timeout_stop_usec;
m-runtime_watchdog = arg_runtime_watchdog;
m-shutdown_watchdog = arg_shutdown_watchdog;
m-userspace_timestamp = userspace_timestamp;
diff --git a/src/core/manager.h b/src/core/manager.h
index ffcca48..c704d0e 100644
--- a/src/core/manager.h
+++ b/src/core/manager.h
@@ -230,6 +230,9 @@ struct Manager {
ExecOutput default_std_output, default_std_error;
+usec_t default_restart_usec, default_timeout_start_usec,
+default_timeout_stop_usec;
+
struct rlimit *rlimit[RLIMIT_NLIMITS];
/* non-zero if we are reloading or reexecuting, */
diff --git a/src/core/mount.c b/src/core/mount.c
index 88563b3..0c15b99 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -131,7 +131,7 @@ static void mount_init(Unit *u) {
assert(u);
assert(u-load_state == UNIT_STUB);
-m-timeout_usec = DEFAULT_TIMEOUT_USEC;
+m-timeout_usec = u-manager-default_timeout_start_usec;
m-directory_mode = 0755;
exec_context_init(m-exec_context);
diff --git a/src/core/scope.c b/src/core/scope.c
index 50e5dba..5d249ec 100644
--- a/src/core/scope.c
+++ b/src/core/scope.c
@@ -46,7 +46,7 @@ static void scope_init(Unit *u) {
assert(u);
assert(u-load_state == UNIT_STUB);
-s-timeout_stop_usec = DEFAULT_TIMEOUT_USEC;
+s-timeout_stop_usec = u-manager-default_timeout_start_usec;
watch_init(s-timer_watch);
diff --git a/src/core/service.c b/src/core/service.c
index ce75757..d11de79 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -124,9 +124,9 @@ static void service_init(Unit *u) {
assert(u);
assert(u-load_state == UNIT_STUB);
-
Re: [systemd-devel] Power aware units
On Mon, 2013-11-04 at 15:27 +0100, Lennart Poettering wrote: On Sun, 03.11.13 15:36, Bastien Nocera (had...@hadess.net) wrote: Heya, systemd already allows launching specific tasks based on a timer, and intervals, and I was wondering whether power awareness was something planned for launching and stopping units. MacOS X 10.9 has some additional metadata for units that allows launchd to stop and start particular tasks based on power levels: http://arstechnica.com/apple/2013/10/os-x-10-9/16/ So, hmm. So far our policy on Linux was mostly If something good for battery cases, then it is good for AC cases too, i.e. the dichotomy between services that may run on battery and that may not be run on on battery is not necessarily a good one. I am really wondering hence whether policies like this one really should exist at all? And to figure that out we probably should look closely at the usecases. So, what are the use cases? You listed: - backups - tmpfiles/cache ageing (including trash expulsion, thumbnail cleanup) - update-db And I figure other ones to add here are: - mandb cache cleanups - rotation of legacy log files (are there more usecases you can come up with?) All these are exclusively cronjobs, i.e. services triggered only by time, and nothing else. Those _were_ all cron jobs. I don't think that any of those should be cron jobs, especially the 4 AM update-db or man-db runs. Anacron is just patching over the fact that most machines aren't running at that time of day. Automatically installing application updates is another use case, or tracker indexing files. Basically, anything that runs in the background without direct user interaction. And all of these strike me as things where we really should run them on battery too, as not doing them at all will sooner or later have a negative effect on the stability and safety of the system. I don't think that update-db or man-db should be updated when on battery, and even less when on low battery. It also shouldn't wake up the hard disk, or be run when I have interactive tasks on-going (eg. it should run when the screen lock is on, not in the middle of streaming a film). So, thinking about this I have the suspicion all that we really can do is modulate the timers a bit: i.e. if the system is on battery power simply lower the frequency how often we dispatch timer events. More specifically: what about adding a new option for .timer units maybe called BatterySlackSec= or so, where you can specify some extra time the execution of the job can be delayed for at maximum if the machine is on battery. If it is not on battery we'd ignore this value. If the machine changes from on battery to on ac we'd immediately execute all services which are already in their battery slack phase. This would then allow people to easily express things like Clean-up /tmp every day, but if I am on battery delay it for another day at max, and possibly exeucte it immediately if I replug power. Or something similar. So, would this make sense to you? Is there anything this logic wouldn't cover? You want backups to run when on AC and the screen is locked (or even better, when the machine is supposed to be sleeping, with the lid closed for laptops). (Oh, and also note that there actually already is ConditionACPower= which allows you to skip execution of certain services if AC is plugged in/is not plugged in. See systemd.unit(5) for details). It doesn't include UPS status, it doesn't know when the hard disk is sleeping, it doesn't know when the screen lock is on. We could implement this in 2 ways: - systemd itself speaks over D-Bus to UPower (using the new DisplayDevice to merge UPS and batteries) and stop/starts the units. I am a bit afraid of making systemd depend on external daemons for things like this. Making systemd a client to another service that is started by systemd, is always problematic, due to potential deadlocks and cyclic deps. We are currently working on getting rid of a dependency like this in regards to dbus-daemon where kdbus makes this all nice and clean for us, and I'd really prefer not to add another case like this... I don't even think this would be necessary really. The power source kernel device class is sufficiently simple for us to use directly, going via upower doesn't appear necessary (I mean, for this logic we don't need battery states of mice and suchlike, hence this shouldn't be a problem.) It's not, because you're missing information about low batteries (eg. that's a policy in UPower, which I don't think you are or should be replicating in systemd), and about UPSes. In addition to that, would it make sense for distributions to start porting their cron jobs to use systemd? It certainly would make sense, but my plan was to first add a couple of things to our timer logic implementation that is substantially better than classic cron so that we have
Re: [systemd-devel] Power aware units
On Mon, 04.11.13 16:10, Bastien Nocera (had...@hadess.net) wrote: And I figure other ones to add here are: - mandb cache cleanups - rotation of legacy log files (are there more usecases you can come up with?) All these are exclusively cronjobs, i.e. services triggered only by time, and nothing else. Those _were_ all cron jobs. I don't think that any of those should be cron jobs, especially the 4 AM update-db or man-db runs. Anacron is just patching over the fact that most machines aren't running at that time of day. Well, but if not cronjob, what should they be? Automatically installing application updates is another use case, or tracker indexing files. Basically, anything that runs in the background without direct user interaction. And all of these strike me as things where we really should run them on battery too, as not doing them at all will sooner or later have a negative effect on the stability and safety of the system. I don't think that update-db or man-db should be updated when on battery, and even less when on low battery. Well, let's say you have a tablet or so which is never attached to AC, but where people simply replace the battery when it runs empty with a new charged one. You certainly wan't these cronjobs to eventually run. I mean, if you installed man-db/update-db you probably want them to work correctly, no? It also shouldn't wake up the hard disk, or be run when I have interactive tasks on-going (eg. it should run when the screen lock is on, not in the middle of streaming a film). Hmm, well, is the policy here that clear? I mean, if our kernel IO/CPU schedulers were any good then scheduling these things while you watch a movie should actually have no drawbacks, and even more be a good thing since the CPU is awake anyway and it's always good to do things when the CPU is awake anyway. We should be *very* careful in basically adding a second-level scheduler here that executes jobs when the CPU load is low, because we don't trust the first-level scheduler in the scheduler. A scheduler that watches another scheduler, and tries to detect when it is idle sounds like trouble. Major trouble. At this point I am quite sure we don't even make use of all the functionality the existing IO/CPU scheduler exposes, and hence there's really no reason to add a second-level scheduler on top. For example, do we actually set those cron jobs to SCHED_IDLE and IOPRIO_CLASS_IDLE? (And also possible on the other end, do we set the bits necessariy for video playback to something rt'ish?) So, would this make sense to you? Is there anything this logic wouldn't cover? You want backups to run when on AC and the screen is locked (or even better, when the machine is supposed to be sleeping, with the lid closed for laptops). But why exactly do you want this? Because our current IO/CPU scheduler setup causes these jobs to interfere too much with your foreground work? Or is there more to it? (Oh, and also note that there actually already is ConditionACPower= which allows you to skip execution of certain services if AC is plugged in/is not plugged in. See systemd.unit(5) for details). It doesn't include UPS status, it doesn't know when the hard disk is sleeping, it doesn't know when the screen lock is on. Hmm, so correct me if I am wrong: UPS stuff is only last-resort kind of stuff: i.e. when we run off UPS we are in the process of shutting down anyway, right? I mean, UPSes are not something that is used for continous operation, it's just the fallback in the case shit happens? Upower doesn't know when the disk is sleeping either, does it? I am not sure even the kernel knows this? It certainly would make sense, but my plan was to first add a couple of things to our timer logic implementation that is substantially better than classic cron so that we have strong case to make why people should adopt it. However, never found the time to work on this. Do you have a list of what's missing? The things I had on my list: - anacron-like persistency - adjust timers to coalesce them once in each second (similar to what sd-event is doing or glib) - timer jitter for cluster setups (related to the cluster thing above) - timer events that cause the system to resume - a list-timers command in systemctl (similar to list-sockets) - timer evets on DST changes or when the user alters the system time - syntax for specifying dates from the end of the month - modulate timer frequency based on battery state The first five or so I guess are the interesting ones. The benefit in adding usage classes (as Apple did), rather than tweaking each background task manually is that it makes it easier to change the policy for running those, and affect all the uses of that class. I have the suspicion that the Apple thing is too opaque for people to grok. And I also have the suspicion that in the end the number of services that need this is relatively limited
Re: [systemd-devel] [PATCH] [RFC] Configurable Timeouts/Restarts default values
On Mon, 04.11.13 17:03, Oleksii Shevchuk (alx...@gmail.com) wrote:
https://bugs.freedesktop.org/show_bug.cgi?id=71132
Patch adds DefaultTimeoutStartSec, DefaultTimeoutStopSec, DefaultRestartSec
configuration options to manager configuration file.
Looks good but please update man page too!
---
src/core/device.c| 2 +-
src/core/main.c | 9 +
src/core/manager.h | 3 +++
src/core/mount.c | 2 +-
src/core/scope.c | 2 +-
src/core/service.c | 6 +++---
src/core/socket.c| 2 +-
src/core/swap.c | 2 +-
src/core/system.conf | 3 +++
src/core/user.conf | 3 +++
10 files changed, 26 insertions(+), 8 deletions(-)
diff --git a/src/core/device.c b/src/core/device.c
index 0595015..6fc4c95 100644
--- a/src/core/device.c
+++ b/src/core/device.c
@@ -70,7 +70,7 @@ static void device_init(Unit *u) {
* indefinitely for plugged in devices, something which cannot
* happen for the other units since their operations time out
* anyway. */
-UNIT(d)-job_timeout = DEFAULT_TIMEOUT_USEC;
+UNIT(d)-job_timeout = u-manager-default_timeout_start_usec;
UNIT(d)-ignore_on_isolate = true;
UNIT(d)-ignore_on_snapshot = true;
diff --git a/src/core/main.c b/src/core/main.c
index 5d30893..b21fb49 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -90,6 +90,9 @@ static bool arg_switched_root = false;
static char ***arg_join_controllers = NULL;
static ExecOutput arg_default_std_output = EXEC_OUTPUT_JOURNAL;
static ExecOutput arg_default_std_error = EXEC_OUTPUT_INHERIT;
+static usec_t arg_default_restart_usec = DEFAULT_RESTART_USEC;
+static usec_t arg_default_timeout_start_usec = DEFAULT_TIMEOUT_USEC;
+static usec_t arg_default_timeout_stop_usec = DEFAULT_TIMEOUT_USEC;
static usec_t arg_runtime_watchdog = 0;
static usec_t arg_shutdown_watchdog = 10 * USEC_PER_MINUTE;
static char **arg_default_environment = NULL;
@@ -636,6 +639,9 @@ static int parse_config_file(void) {
{ Manager, CPUAffinity,
config_parse_cpu_affinity2, 0, NULL},
{ Manager, DefaultStandardOutput, config_parse_output,
0, arg_default_std_output },
{ Manager, DefaultStandardError, config_parse_output,
0, arg_default_std_error },
+{ Manager, DefaultTimeoutStartSec, config_parse_sec,
0, arg_default_timeout_start_usec },
+{ Manager, DefaultTimeoutStopSec, config_parse_sec,
0, arg_default_timeout_stop_usec },
+{ Manager, DefaultRestartSec, config_parse_sec,
0, arg_default_restart_usec },
{ Manager, JoinControllers,
config_parse_join_controllers, 0, arg_join_controllers },
{ Manager, RuntimeWatchdogSec,config_parse_sec,
0, arg_runtime_watchdog},
{ Manager, ShutdownWatchdogSec, config_parse_sec,
0, arg_shutdown_watchdog },
@@ -1518,6 +1524,9 @@ int main(int argc, char *argv[]) {
m-confirm_spawn = arg_confirm_spawn;
m-default_std_output = arg_default_std_output;
m-default_std_error = arg_default_std_error;
+m-default_restart_usec = arg_default_restart_usec;
+m-default_timeout_start_usec = arg_default_timeout_start_usec;
+m-default_timeout_stop_usec = arg_default_timeout_stop_usec;
m-runtime_watchdog = arg_runtime_watchdog;
m-shutdown_watchdog = arg_shutdown_watchdog;
m-userspace_timestamp = userspace_timestamp;
diff --git a/src/core/manager.h b/src/core/manager.h
index ffcca48..c704d0e 100644
--- a/src/core/manager.h
+++ b/src/core/manager.h
@@ -230,6 +230,9 @@ struct Manager {
ExecOutput default_std_output, default_std_error;
+usec_t default_restart_usec, default_timeout_start_usec,
+default_timeout_stop_usec;
+
struct rlimit *rlimit[RLIMIT_NLIMITS];
/* non-zero if we are reloading or reexecuting, */
diff --git a/src/core/mount.c b/src/core/mount.c
index 88563b3..0c15b99 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -131,7 +131,7 @@ static void mount_init(Unit *u) {
assert(u);
assert(u-load_state == UNIT_STUB);
-m-timeout_usec = DEFAULT_TIMEOUT_USEC;
+m-timeout_usec = u-manager-default_timeout_start_usec;
m-directory_mode = 0755;
exec_context_init(m-exec_context);
diff --git a/src/core/scope.c b/src/core/scope.c
index 50e5dba..5d249ec 100644
--- a/src/core/scope.c
+++ b/src/core/scope.c
@@ -46,7 +46,7 @@ static void scope_init(Unit *u) {
assert(u);
assert(u-load_state == UNIT_STUB);
-s-timeout_stop_usec = DEFAULT_TIMEOUT_USEC;
+s-timeout_stop_usec = u-manager-default_timeout_start_usec;
watch_init(s-timer_watch);
diff --git a/src/core/service.c
Re: [systemd-devel] Need advice on daemon's architecture
On Mon, 2013-11-04 at 14:57 +, Simon McVittie wrote: See Linux signal(7) for a list of async-signal-safe operations: it's not as long a list as you might hope, and mostly contains syscalls. In particular, malloc() is not on the list, which rules out a lot of library code... Given however that systemd is Linux/glibc-equivalent only, you can rely on malloc() working after fork() if you're writing a daemon which only runs on systemd systems. See: https://bugzilla.gnome.org/show_bug.cgi?id=659326#c24 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] nspawn does not correctly handle I/O redirection
A couple of weeks ago, I reported a bug that systemd-nspawn does not correctly handle I/O redirection[1]. I described in detail the several smaller bugs that lead up to both stdin and stdout redirection being broken, and uploaded a patch that fixes stdout redirection. That patch is attached here. Stdin redirection is more involved to fix. It has been several weeks, and no one has acknowledged the bug report, so I figured I would try another channel. Happy hacking, ~ Luke Shumaker [1]: https://bugs.freedesktop.org/show_bug.cgi?id=70290 systemd-stdout-fix.patch Description: Binary data ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux: fix selinux check for transient units
On Thu, 31.10.13 15:51, Vaclav Pavlin (vpav...@redhat.com) wrote:
From: Václav Pavlín vpav...@redhat.com
Sorry, I don't understand what this patch is doing. Please explain in a
commit message!
---
src/core/selinux-access.c | 59
++-
src/core/selinux-access.h | 15 +---
2 files changed, 70 insertions(+), 4 deletions(-)
diff --git a/src/core/selinux-access.c b/src/core/selinux-access.c
index 0a3ee18..5908a79 100644
--- a/src/core/selinux-access.c
+++ b/src/core/selinux-access.c
@@ -333,6 +333,50 @@ static int get_calling_context(
return 0;
}
+static int load_context(
+const char *path,
+const char *name,
+char **context) {
+
+int r = 0;
+char l[LINE_MAX];
+char *p;
+FILE *fd;
+
+fd = fopen(path, r);
Please always use re rather than r. Not that it would matter much
here, but Please always do.
+if (!fd)
+return -EEXIST;
+
+if (!fgets(l, sizeof(l), fd)) {
Hmm, isn't this a job for read_one_line_file()?
+if (feof(fd)) {
+r = -EINVAL;
+goto finish;
+}
+
+log_error(Failed to read context file '%s': %m, path);
+r = -errno;
+goto finish;
+}
+
+p = strtok (l, =);
strtok() is evil, as it keeps internal state, please don't use it. Also
one space too much...
+if (p streq(p, name)) {
+p = strtok (NULL, =);
+if (!p) {
+r = -EINVAL;
+goto finish;
+}
+
+*context = strdup(p);
Missing OOM check.
+} else
+r = -EINVAL;
+
+finish:
+if (fd)
+fclose(fd);
Please use _cleanup_close_ for cases like this.
+} else if (class == CLASS_TRANSIENT) {
+const char *context_path =
selinux_systemd_contexts_path();
Where is selinux_systemd_contexts_path() define? I cant find it in this
patch and neither in the sources? What am I missing?
+if (_u-source_path || _u-fragment_path) \
+_r = selinux_access_check(_c, _m, CLASS_SERVICE,
_u-source_path ?: _u-fragment_path, (permission), _error); \
+else\
+_r = selinux_access_check(_c, _m, CLASS_TRANSIENT,
_u-id, (permission), _error); \
You can recognize transient units via the transient bool on the Unit structure.
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] selinux: fix selinux check for transient units
On Mon, Nov 4, 2013 at 5:06 PM, Lennart Poettering
lenn...@poettering.net wrote:
Sorry, I don't understand what this patch is doing. Please explain in a
commit message!
The file format should also be documented in the code itself, if not
done by selinx, then we need to add the link to the doc.
---
src/core/selinux-access.c | 59
++-
src/core/selinux-access.h | 15 +---
2 files changed, 70 insertions(+), 4 deletions(-)
diff --git a/src/core/selinux-access.c b/src/core/selinux-access.c
index 0a3ee18..5908a79 100644
--- a/src/core/selinux-access.c
+++ b/src/core/selinux-access.c
@@ -333,6 +333,50 @@ static int get_calling_context(
return 0;
}
+static int load_context(
+const char *path,
+const char *name,
+char **context) {
+
+int r = 0;
+char l[LINE_MAX];
+char *p;
+FILE *fd;
+
+fd = fopen(path, r);
Please always use re rather than r. Not that it would matter much
here, but Please always do.
+if (!fd)
+return -EEXIST;
+
+if (!fgets(l, sizeof(l), fd)) {
Hmm, isn't this a job for read_one_line_file()?
+if (feof(fd)) {
+r = -EINVAL;
+goto finish;
+}
+
+log_error(Failed to read context file '%s': %m, path);
+r = -errno;
+goto finish;
+}
+
+p = strtok (l, =);
strtok() is evil, as it keeps internal state, please don't use it. Also
one space too much...
+if (p streq(p, name)) {
+p = strtok (NULL, =);
+if (!p) {
+r = -EINVAL;
+goto finish;
+}
+
+*context = strdup(p);
Missing OOM check.
+} else
+r = -EINVAL;
+
+finish:
+if (fd)
+fclose(fd);
Please use _cleanup_close_ for cases like this.
It should probably just use:
parse_env_file()
it does all that.
+} else if (class == CLASS_TRANSIENT) {
+const char *context_path =
selinux_systemd_contexts_path();
Where is selinux_systemd_contexts_path() define? I cant find it in this
patch and neither in the sources? What am I missing?
http://people.fedoraproject.org/~dwalsh/SELinux/Patches/0008-Add-selinux_systemd_contexts_path.patch
+if (_u-source_path || _u-fragment_path) \
+_r = selinux_access_check(_c, _m, CLASS_SERVICE,
_u-source_path ?: _u-fragment_path, (permission), _error); \
+else\
+_r = selinux_access_check(_c, _m, CLASS_TRANSIENT,
_u-id, (permission), _error); \
You can recognize transient units via the transient bool on the Unit
structure.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Need advice on daemon's architecture
-Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Monday, November 04, 2013 3:42 PM To: Hoyer, Marko (ADITG/SW2) Cc: Colin Guthrie; Peter Lemenkov; systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] Need advice on daemon's architecture On Sun, 03.11.13 13:42, Hoyer, Marko (ADITG/SW2) (mho...@de.adit-jv.com) wrote: If you are using systemd intensively, then you may want to use Type=notify. With type=dbus, systemd will consider things ready when you take the name on the bus, but this might not actually be the last thing you do to initialise your daemon (although if this is the only interface for clients this is not a problem!). You still might want to use sd_notify() instead. This can also pass through some internal performance info to systemd which will show up on systemctl status output which is kinda nice. Col Isn't the classical Linux way an option too? Well, it is, but it is hard to get right and a lot of redundant code involved. - the daemon does its initialization with the calling thread - once it is done with the initialization, it forks off a process that goes on with the daemons work (the main loop probably) No, this is wrong. You really shouldn't do initialization in one process and then run the daemon from a forked off second one. A lot of (library) code is not happy with being initialized in one process and being used in another forked off one. For example, any code involving threads is generally allergic to this, since background threads cease to exist in the forked off child. This is nearly impossible to work around [1]. Or code involving file locks or even a lot of socket code doesn't like it either. In general you should not assume that any library can handle it, except for those cases where the library author explicitly tells you that it is safe. Actually, all systemd libraries (like libsystemd-journal or libsystem-bus) and a couple of my other libraries (like libcanberra) explicitly check for the PID changing and refuse operation in such cases, simply because the effects of fork()ing are so nasty. Or to be more explicit: if you initialize a sd_journal or sd_bus object in one process and then try to execute any operation on it in a forked off child process you will get -ECHILD returned which is how we indicate this misuage. So, what is the right way to do this? Fork off early, do the initialization in the child, and signal the parent that you are done via a pipe, so that the parent exits only after the child is done. This is explained in daemon(7). Or even better: don't bother at all, write your services without forking, and use Type=dbus or Type=notify instead. Lennart [1] Yeah, and don't tell me pthread_atfork() is the solution for this. It's not. It makes things even worse, since there's no defined execution order defined for it. If you claim pthread_atfork() was a solution and not a problem in itself, then you obviously have never used it, or only in trivial programs. -- Lennart Poettering, Red Hat Thx for the comprehensive answer. My daemon is quite simple, threads are only used as kind of workers which are started from the daemon process out of the main loop. So I guess: no problem at this end. I'm additionally polling a udevd socket opened via libudev, which actually is initialized from the calling process by now. Additionally, I'm working on the connection to a control tool, which I plan to realize via sockets as well. So I plan to open a listener socket during the initialization. Maybe I'll actually switch to the sd_notify() way until someone appears who is not systemd and wants to use my daemon ... Best regards Marko Hoyer Software Group II (ADITG/SW2) Tel. +49 5121 49 6948 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] [RFCv2] Configurable Timeouts/Restarts default values
https://bugs.freedesktop.org/show_bug.cgi?id=71132 Patch adds DefaultTimeoutStartSec, DefaultTimeoutStopSec, DefaultRestartSec configuration options to manager configuration file. --- man/systemd-system.conf.xml | 12 man/systemd.mount.xml | 4 ++-- man/systemd.service.xml | 6 -- man/systemd.socket.xml | 4 ++-- man/systemd.swap.xml| 4 ++-- src/core/device.c | 2 +- src/core/main.c | 9 + src/core/manager.h | 3 +++ src/core/mount.c| 2 +- src/core/scope.c| 2 +- src/core/service.c | 6 +++--- src/core/socket.c | 2 +- src/core/swap.c | 2 +- src/core/system.conf| 3 +++ src/core/user.conf | 3 +++ 15 files changed, 48 insertions(+), 16 deletions(-) diff --git a/man/systemd-system.conf.xml b/man/systemd-system.conf.xml index e8cf8a9..f64fb91 100644 --- a/man/systemd-system.conf.xml +++ b/man/systemd-system.conf.xml @@ -95,6 +95,18 @@ /varlistentry varlistentry + termvarnameDefaultTimeoutStartSec=/varname/term + termvarnameDefaultTimeoutStopSec=/varname/term + termvarnameDefaultRestartSec=/varname/term + + listitempara +Configures the default time to wait for start, stop and restart. +For non service units varnameDefaultTimeoutStartSec=/varname +sets default for varnameTimeoutSec=/varname value. + /para/listitem +/varlistentry + +varlistentry termvarnameCPUAffinity=/varname/term listitemparaConfigures the initial diff --git a/man/systemd.mount.xml b/man/systemd.mount.xml index 217289a..bed2975 100644 --- a/man/systemd.mount.xml +++ b/man/systemd.mount.xml @@ -260,8 +260,8 @@ Takes a unit-less value in seconds, or a time span value such as 5min 20s. Pass 0 to disable the timeout -logic. Defaults to -90s./para/listitem +logic. Default value is setted up in manager configuration +file via termvarnameDefaultTimeoutStart=/varname/term./para/listitem /varlistentry /variablelist diff --git a/man/systemd.service.xml b/man/systemd.service.xml index b1e3af2..0cb3d9e 100644 --- a/man/systemd.service.xml +++ b/man/systemd.service.xml @@ -524,7 +524,8 @@ Takes a unit-less value in seconds, or a time span value such as 5min 20s. Pass 0 to disable the timeout -logic. Defaults to 90s, except when +logic. Defaults to varnameTimeoutStartSec=/varname in +manager configuration file, except when varnameType=oneshot/varname is used in which case the timeout is disabled by default. @@ -545,7 +546,8 @@ Takes a unit-less value in seconds, or a time span value such as 5min 20s. Pass 0 to disable the timeout -logic. Defaults to 90s. +logic. Defaults to varnameTimeoutStartSec=/varname in +manager configuration file. /para/listitem /varlistentry diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml index 8c88d9f..1c78562 100644 --- a/man/systemd.socket.xml +++ b/man/systemd.socket.xml @@ -679,8 +679,8 @@ Takes a unit-less value in seconds, or a time span value such as 5min 20s. Pass 0 to disable the timeout -logic. Defaults to -90s./para/listitem +logic. Defaults to varnameTimeoutStartSec=/varname in +manager configuration file./para/listitem /varlistentry varlistentry diff --git a/man/systemd.swap.xml b/man/systemd.swap.xml index 813ae6c..13f6c84 100644 --- a/man/systemd.swap.xml +++ b/man/systemd.swap.xml @@ -186,8 +186,8 @@ Takes a unit-less value in seconds, or a time span value such as 5min 20s. Pass 0
Re: [systemd-devel] Power aware units
On Monday 2013-11-04 16:52, Lennart Poettering wrote: Those _were_ all cron jobs. I don't think that any of those should be cron jobs, especially the 4 AM update-db or man-db runs. Anacron is just patching over the fact that most machines aren't running at that time of day. Well, but if not cronjob, what should they be? Some wishful thinking: daemons. locate would be a lot more useful if it was constantly adding new entries to its database -- perhaps fsnotify, or whatever became of efficiently watching directory changes recursively-- would be of use. mandb itself seems to be for keyword searches à la whatis/apropos, but not for plain man operation where you look up by page/filename, like man systemctl. It will (or should) know to just glob in /usr/share/man/ for systemctl.*. Hmm, so correct me if I am wrong: UPS stuff is only last-resort kind of stuff: i.e. when we run off UPS we are in the process of shutting down anyway, right? I mean, UPSes are not something that is used for continous operation, it's just the fallback in the case shit happens? Shutdowns are not triggered when power is lost first, but after perhaps 2–10 minutes (take your pick). Not all servers are terribly overloaded with VMs, enterprise databases and sysvinit scripts that take ages to shutdown. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] selinux: fix selinux check for transient units
On Mon, 04.11.13 17:06, Lennart Poettering (lenn...@poettering.net) wrote: On Thu, 31.10.13 15:51, Vaclav Pavlin (vpav...@redhat.com) wrote: From: Václav Pavlín vpav...@redhat.com Sorry, I don't understand what this patch is doing. Please explain in a commit message! Hmm, so, here's another idea. The transient units are created by a client process. We could easily determine the label of that client process. Wouldn't it a better approach to calculate the label of the transient units somehow from the client process' label? This way wouldn't need any additional systemd-specific infrastructure in libselinux. Dan, could that work? 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] selinux: fix selinux check for transient units
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/04/2013 02:05 PM, Lennart Poettering wrote:
On Mon, 04.11.13 17:06, Lennart Poettering (lenn...@poettering.net) wrote:
On Thu, 31.10.13 15:51, Vaclav Pavlin (vpav...@redhat.com) wrote:
From: Václav Pavlín vpav...@redhat.com
Sorry, I don't understand what this patch is doing. Please explain in a
commit message!
Hmm, so, here's another idea. The transient units are created by a client
process. We could easily determine the label of that client process.
Wouldn't it a better approach to calculate the label of the transient units
somehow from the client process' label? This way wouldn't need any
additional systemd-specific infrastructure in libselinux.
Dan, could that work?
Lennart
I suppose it would. The only label we have the the clients is the process
label.
What process types create these runtime objects and what do they request to do
with them?
Currently systemd asks for permissions on system class and service class, where
class system
{
ipc_info
syslog_read
syslog_mod
syslog_console
module_request
halt
reboot
status
undefined
enable
disable
reload
}
class service
{
start
stop
status
reload
kill
load
enable
disable
}
Do we have to add a rule like
allow sysadm_t networkmanager_t:service start;
Were networkmanager_t is a process type?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJ3/gsACgkQrlYvE4MpobPWbQCfWElx/pR6cOjQKM1Ad0cE/eU1
cAcAoJ1k49KbB143/NJH/DEfl0aRLhnn
=eao5
-END PGP SIGNATURE-
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Make X11 logind session unconditionally active
Hello! I'm still trying to make my friendship with logind. I have a headless server with Xvnc server running on it. Under the server a logind session is created by the DM. The session has Type=x11, but VTNr=0 since Xvnc does not bind itself to any VT. Hence the session is always Active=no (there is no VT I can switch to). So the question is: it is possible to mark a session as always active or something like that? Thanks, -- Ivan Shapovalov / intelfx / ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] systemctl: make LOAD column width dynamic
Otherwise 'not-found' overflows into the ACTIVE column.
---
src/systemctl/systemctl.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 9f5e273..04699be 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -287,11 +287,13 @@ static bool output_show_unit(const struct unit_info *u) {
}
static void output_units_list(const struct unit_info *unit_infos, unsigned c) {
-unsigned id_len, max_id_len, active_len, sub_len, job_len, desc_len,
n_shown = 0;
+unsigned id_len, max_id_len, load_len, active_len, sub_len, job_len,
desc_len;
+unsigned n_shown = 0;
const struct unit_info *u;
int job_count = 0;
max_id_len = sizeof(UNIT)-1;
+load_len = sizeof(LOAD)-1;
active_len = sizeof(ACTIVE)-1;
sub_len = sizeof(SUB)-1;
job_len = sizeof(JOB)-1;
@@ -302,6 +304,7 @@ static void output_units_list(const struct unit_info
*unit_infos, unsigned c) {
continue;
max_id_len = MAX(max_id_len, strlen(u-id));
+load_len = MAX(load_len, strlen(u-load_state));
active_len = MAX(active_len, strlen(u-active_state));
sub_len = MAX(sub_len, strlen(u-sub_state));
if (u-job_id != 0) {
@@ -344,7 +347,7 @@ static void output_units_list(const struct unit_info
*unit_infos, unsigned c) {
continue;
if (!n_shown !arg_no_legend) {
-printf(%-*s %-6s %-*s %-*s , id_len, UNIT, LOAD,
+printf(%-*s %-*s %-*s %-*s , id_len, UNIT,
load_len, LOAD,
active_len, ACTIVE, sub_len, SUB);
if (job_count)
printf(%-*s , job_len, JOB);
@@ -371,9 +374,9 @@ static void output_units_list(const struct unit_info
*unit_infos, unsigned c) {
e = arg_full ? NULL : ellipsize(u-id, id_len, 33);
-printf(%s%-*s%s %s%-6s%s %s%-*s %-*s%s %-*s,
+printf(%s%-*s%s %s%-*s%s %s%-*s %-*s%s %-*s,
on, id_len, e ? e : u-id, off,
- on_loaded, u-load_state, off_loaded,
+ on_loaded, load_len, u-load_state, off_loaded,
on_active, active_len, u-active_state,
sub_len, u-sub_state, off_active,
job_count ? job_len + 1 : 0, u-job_id ? u-job_type :
);
--
1.8.4.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/1] systemd will fail to compile if libgcrypt is missing
On Monday 2013-11-04 13:01, Lennart Poettering wrote:
On Sat, 02.11.13 02:11, Djalal Harouni (tix...@opendz.org) wrote:
I'm building from git tree, and I've noticed that systemd autogen.sh
will fail if the libgcrypt and its headers are missing.
This is expected that way. If you build from git you need a few
additional dependencies.[...] There's not to fix here.
Well, there is something of a solution—wrapping everything into
m4_ifdef:
m4_ifdef([AM_PATH_LIBGCRYPT], [
AC_ARG_ENABLE([gcrypt]..)
if test x${have_gcrypt} != xno; then
AM_PATH_LIBGCRYPT...
fi
])
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Linux kernel API
Hi, On 11/02/2013 12:15 AM, Greg KH wrote: On Sat, Nov 02, 2013 at 12:05:23AM +0100, ScotXW wrote: On 11/01/2013 06:51 PM, Greg KH wrote: On Fri, Nov 01, 2013 at 06:47:00PM +0100, ScotXW wrote: Hi, systemd is written exclusively for the Linux kernel because this offers advantages over the POSIX API. To illustrate the difference between Linux kernel API and POSIX API I created a diagram, see [1]. Linux doesn't implement all of the POSIX api in the kernel, other portions of it are in other userspace pieces. Would you please name a couple beside the libc? Why, this is your research, not mine :) This is //not// a recherche, I was looking for some fast answer from the off the top of ones head. Besides the scheme, there is now an article [1]. Please do note, that I did distinguish between the User-kernel API and the in-kernel API, so don't even start. Regards, Scot [1] https://en.wikipedia.org/wiki/Linux_kernel_API ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Linux kernel API
On Mon, Nov 04, 2013 at 10:54:26PM +0100, ScotXW wrote: Hi, On 11/02/2013 12:15 AM, Greg KH wrote: On Sat, Nov 02, 2013 at 12:05:23AM +0100, ScotXW wrote: On 11/01/2013 06:51 PM, Greg KH wrote: On Fri, Nov 01, 2013 at 06:47:00PM +0100, ScotXW wrote: Hi, systemd is written exclusively for the Linux kernel because this offers advantages over the POSIX API. To illustrate the difference between Linux kernel API and POSIX API I created a diagram, see [1]. Linux doesn't implement all of the POSIX api in the kernel, other portions of it are in other userspace pieces. Would you please name a couple beside the libc? Why, this is your research, not mine :) This is //not// a recherche, I was looking for some fast answer from the off the top of ones head. Besides the scheme, there is now an article [1]. The diagram on that article is still wrong, sorry. The article is also wrong, POSIX is still being developed and maintained and extended, thanks to a large effort by lots of Linux developers doing the work. I still fail to understand how _any_ of this pertains to this mailing list... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Scheme: Linux startup process with systemd
Hi, I created this [1] scheme. Can you help fill in the blank? I know there is very extensive documentation about systemd, it is way too extensive for my purposes, the home user. Regards, ScotX [1] https://commons.wikimedia.org/wiki/File:Linux_startup_process_wip.svg ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Scheme: Linux startup process with systemd
On Monday 2013-11-04 23:48, ScotXW wrote: Hi, I created this [1] scheme. Can you help fill in the blank? I know there is very extensive documentation about systemd, it is way too extensive for my purposes, the home user. [1] https://commons.wikimedia.org/wiki/File:Linux_startup_process_wip.svg Seems rather strange to find GRUB and Linux in BIOS. And if you talk about Uboot and Redboot and whatever else, then marking the orange section as GRUB is sorta outta place. It's also wrong on so many accounts. -initramfs is not mounted, because it is not a filesystem. -kernel does not execute /usr/bin/systemd but /init from the initramfs, or in case none was used, /sbin/init. -/usr/lib/systemd/system is a directory, not an executable entity -you already have systemd, so having systemd again in user interfaces is sort of inside out ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Scheme: Linux startup process with systemd
On Mon, Nov 4, 2013 at 11:48 PM, ScotXW shcsott...@yahoo.com wrote: I created this [1] scheme. Can you help fill in the blank? I know there is very extensive documentation about systemd, it is way too extensive for my purposes, the home user. Most of this is just misleading, plain wrong or backwards. Systemd is not in-between the kernel and applications, especially not for the ones you listed. And what's the point of these made-up names usoundd, ubusd? Never heard of them, and they will probably never exist in the future. In its current state, this looks all too wrong and will probably create more confusion than it will help people to understand things. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Linux kernel API
On Mon, Nov 4, 2013 at 2:10 PM, Greg KH gre...@linuxfoundation.org wrote: On Mon, Nov 04, 2013 at 10:54:26PM +0100, ScotXW wrote: Hi, On 11/02/2013 12:15 AM, Greg KH wrote: On Sat, Nov 02, 2013 at 12:05:23AM +0100, ScotXW wrote: On 11/01/2013 06:51 PM, Greg KH wrote: On Fri, Nov 01, 2013 at 06:47:00PM +0100, ScotXW wrote: systemd is written exclusively for the Linux kernel because this offers advantages over the POSIX API. To illustrate the difference between Linux kernel API and POSIX API I created a diagram, see [1]. Linux doesn't implement all of the POSIX api in the kernel, other portions of it are in other userspace pieces. Would you please name a couple beside the libc? Why, this is your research, not mine :) This is //not// a recherche, I was looking for some fast answer from the off the top of ones head. Besides the scheme, there is now an article [1]. I still fail to understand how _any_ of this pertains to this mailing list... Thanks Greg. Scot, I find your messages not appropriate for this list. Please remember that the list is named systemd-devel for a reason. Your requests are clearly not in the interest, or promote the development of systemd (if they are, you failed terribly at making a case that that is the case... and please do not attempt to do so further). So please don't post this kind of stuff to this list. There are far better places to post these requests. Sorry, Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Scheme: Linux startup process with systemd
On 11/04/2013 11:55 PM, Jan Engelhardt wrote: On Monday 2013-11-04 23:48, ScotXW wrote: Hi, I created this [1] scheme. Can you help fill in the blank? I know there is very extensive documentation about systemd, it is way too extensive for my purposes, the home user. [1] https://commons.wikimedia.org/wiki/File:Linux_startup_process_wip.svg Seems rather strange to find GRUB and Linux in BIOS. And if you talk about Uboot and Redboot and whatever else, then marking the orange section as GRUB is sorta outta place. Linux kernel and GNU GRUB can be payloads to coreboot. That is why they are on that level in their own color. However, the y-axis is the time from the connection to power. Does it make more sense now? The distinction of GNU GRUB is shurely important in a scheme about the start up process. It is the bootstraploader. It's also wrong on so many accounts. -initramfs is not mounted, because it is not a filesystem. AFAIK ramfs = ram file system, so I assumed it is being mounted. How else to epress it? Was initrd mounted, is that at least correct? Will tmpfs be mounted? -kernel does not execute /usr/bin/systemd but /init from the initramfs, or in case none was used, /sbin/init. Hö? You lost me. -/usr/lib/systemd/system is a directory, not an executable entity So system processes the declarative files in /../? -you already have systemd, so having systemd again in user interfaces is sort of inside out Yeah, there is alink missing between them, because systemd gets startet and then remains available as a daemon. Regards, ScotX ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Scheme: Linux startup process with systemd
Hi, On 11/05/2013 12:01 AM, Kay Sievers wrote: Most of this is just misleading, plain wrong or backwards. Systemd is not in-between the kernel and applications, especially not for the ones you listed. Yes it is, during the startup process! Y-axes represents the time, i.e. the start of systemd predates the start of the other programs. And what's the point of these made-up names usoundd, ubusd? Never heard of them, and they will probably never exist in the future. Just some consistent naming: [1] ;-) In its current state, this looks all too wrong and will probably create more confusion than it will help people to understand things. Well, I will keep working on it anyway, this is your chance at making it correct. Ok, no more unetworkd, usound, etc. There are numbers from 1 to 8, any more precise stuff to make this correct and useful to the Linux beginner? If someones know, what to mention, that someone should be on this list, right? Regards, ScotX [1] http://lists.freedesktop.org/archives/dbus/2010-April/012545.html ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Scheme: Linux startup process with systemd
On Tue, Nov 05, 2013 at 12:19:27AM +0100, ScotXW wrote: Hi, On 11/05/2013 12:01 AM, Kay Sievers wrote: Most of this is just misleading, plain wrong or backwards. Systemd is not in-between the kernel and applications, especially not for the ones you listed. Yes it is, during the startup process! Y-axes represents the time, i.e. the start of systemd predates the start of the other programs. And what's the point of these made-up names usoundd, ubusd? Never heard of them, and they will probably never exist in the future. Just some consistent naming: [1] ;-) In its current state, this looks all too wrong and will probably create more confusion than it will help people to understand things. Well, I will keep working on it anyway, this is your chance at making it correct. Ok, no more unetworkd, usound, etc. Why do we have to do anything here? You are trying to document something that has been documented numerous times before, for no valid reason why it needs to be documented in this manner in the first place. Please step back and try to describe what your goals are here. You say that the extensive systemd documentation somehow is too much for you, why is that? What is missing that would help you? What problem are you trying to solve? There are numbers from 1 to 8, any more precise stuff to make this correct and useful to the Linux beginner? If someones know, what to mention, that someone should be on this list, right? There is no need for any Linux beginner to care about systemd or the startup process. If they really do, they aren't a beginner anymore... greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Scheme: Linux startup process with systemd
On Tuesday 2013-11-05 00:19, ScotXW wrote: On 11/05/2013 12:01 AM, Kay Sievers wrote: Most of this is just misleading, plain wrong or backwards. Systemd is not in-between the kernel and applications, especially not for the ones you listed. [Yes is it] Y-axes represents the time How screwed up is that. If (and only if) you have a time-based function graph, common sense is putting time on the horizontal x axis, and value of function on the vertical y one. But your graphic is not showing progress, it is - what seems to be - showing a *timeless* diagram - like http://en.wikipedia.org/wiki/File:Netfilter-components.svg - of how things are stacked. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Scheme: Linux startup process with systemd
On Tuesday 2013-11-05 00:28, ScotXW wrote: Seems rather strange to find GRUB and Linux in BIOS. And if you talk about Uboot and Redboot and whatever else, then marking the orange section as GRUB is sorta outta place. Linux kernel and GNU GRUB can be payloads to coreboot. That may be so, but you have a separate bootloader layer already. However, the y-axis is the time from the connection to power. Does it make more sense now? No, it makes even less. Time is on x, if at all. What you have there is a timeless diagram, just like http://en.wikipedia.org/wiki/File:Netfilter-components.svg . It's also wrong on so many accounts. -initramfs is not mounted, because it is not a filesystem. AFAIK ramfs = ram file system, so I assumed it is being mounted. If you want to be exact, yes. ramfs is mounted, implicitly. And it's empty by default. But any standard reader would assume initramfs to mean initramfs image. And that's what is not mounted but extracted. Unless it's an initrd, in which case there is something (with contents) to mount. -kernel does not execute /usr/bin/systemd but /init from the initramfs, or in case none was used, /sbin/init. Hö? You lost me. init/main.c: if (!run_init_process(/sbin/init) || ... init/main.c: ramdisk_execute_command = /init; There is no mention of systemd in the linux kernel source *at all*. -/usr/lib/systemd/system is a directory, not an executable entity So system processes the declarative files in /../? For brevity, units in /../ -you already have systemd, so having systemd again in user interfaces is sort of inside out Yeah, there is alink missing between them, because systemd gets startet and then remains available as a daemon. Then you should write systemctl. The way it looks now is as if you are referring to the systemd --user instances (which are pretty much unimportant as of now) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] tree-wide conversion from libdbus to libsystemd-bus
On Fri, Nov 1, 2013 at 4:50 PM, Kay Sievers k...@vrfy.org wrote: [update] Simon, Zbigniew, Marc-Antoine you still work/plan to work on the stuff listed below? Please let us know. Thanks, Kay - loginctl Peeters Simon: I'll take ... (probably loginctl afterwards) - pam_systemd Zbigniew: I'll do pam_systemd - systemctl Marc-Antoine Perennou: I've goy it nearly half finished by now, should be done by next week end. - systemd Lennart: I am going to work on systemd itself. - test-inhibit.c ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Make X11 logind session unconditionally active
On Tue, 05.11.13 00:51, Ivan Shapovalov (intelfx...@gmail.com) wrote: Hello! I'm still trying to make my friendship with logind. I have a headless server with Xvnc server running on it. Under the server a logind session is created by the DM. The session has Type=x11, but VTNr=0 since Xvnc does not bind itself to any VT. Hence the session is always Active=no (there is no VT I can switch to). Nah, that's not how this really should work. Basically, there are sessions which are assigned to seats and sessions which aren't. Seats in this case means local, physical seats. Sessions without seats are unconditionally active. Only sessions with seats can be inactive. Since an xvnc session is not a local one it should not have a seat, and hecnce should alway be active. So the question is: it is possible to mark a session as always active or something like that? Well, that should be the case implicitly if the session is properly registered. What does loginctl show-session print for this session? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
