Re: [systemd-devel] StartupFinished signal is not sent on 210
Hi, -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: den 4 mars 2014 22:00 To: Umut Tezduyar Cc: Umut Tezduyar Lindskog; systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] StartupFinished signal is not sent on 210 On Tue, 04.03.14 21:40, Umut Tezduyar (u...@tezduyar.com) wrote: To compare 208 and 210, I pretty much followed steps @ https://wiki.ubuntu.com/DebuggingDBus and by using $ dbus-monitor type=signal,sender='org.freedesktop.systemd1' --system You have to invoke Subscribe() first on the manager bus, to get something. We only send out the messages as long as at least one living client has issued this call. Don't you think this is something worth mentioning in the NEWS since we were able to retrieve signals without subscribing to them on 208. Excuse me if it is documented somewhere and I missed it. Subscribe() is actually around since day #1 of systemd. And it is documented here: http://www.freedesktop.org/wiki/Software/systemd/dbus/ Of course, I must admit it is less than ideal that with logind around you might be able to get away with never calling it... That certainly hides bugs... We don't have logind and we certainly weren't calling Subscribe(). Then I can't explain how come we were receiving the signal, can you? Could it be that one of systemd applications was subscribing and we were just lucky to get the signal? We changed a couple of times how systemd delivers those signals during the history, but clients which called Subscribed() should always just have worked. Note that 211 actually changes things back to be more like 209... The difference between 209 + 210 and 209+210 is the single subscriber case. With 209 + 210 we have the following rule: 1. when there's no subscriber we don't send out any signals 2. when there's one or more subscribers we broadcast signals to everybody In 209+210 we had this ruleset instead: 1. when there's no subscriber we don't send out any signals 2. when there's one subscriber send all signals as unicast to it 3. when there's two or more subscribers we broadcast signals to everybody I thought for a while that doing step #2 was smart, but then again, it's kinda stupid, since it second guesses the dbus filter logic too much, and the messages look different to the receiver depending on the number of other subscribers. So I dropped this again... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] core: add startup resource control option
Similar to CPUShares= and BlockIOWeight= respectively. However only
assign the specified weight during startup. Each control group
attribute is re-assigned as weight by CPUShares=weight and
BlockIOWeight=weight after startup. If not CPUShares= or
BlockIOWeight= be specified, then the attribute is re-assigned to each
default attribute value. (default cpu.shares=1024, blkio.weight=1000)
If only CPUShares=weight or BlockIOWeight=weight be specified, then
that implies StartupCPUShares=weight and StartupBlockIOWeight=weight.
---
src/core/cgroup.c | 25 --
src/core/cgroup.h |6 ++-
src/core/dbus-cgroup.c| 40
src/core/load-fragment-gperf.gperf.m4 |2 +
src/core/load-fragment.c | 83 +
src/core/load-fragment.h |2 +
6 files changed, 152 insertions(+), 6 deletions(-)
diff --git a/src/core/cgroup.c b/src/core/cgroup.c
index 1327486..dc28306 100644
--- a/src/core/cgroup.c
+++ b/src/core/cgroup.c
@@ -33,8 +33,12 @@ void cgroup_context_init(CGroupContext *c) {
* structure is preinitialized to 0 */
c-cpu_shares = 1024;
+c-startup_cpu_shares = 1024;
+c-use_startup_cpu_shares = false;
c-memory_limit = (uint64_t) -1;
c-blockio_weight = 1000;
+c-startup_blockio_weight = 1000;
+c-use_startup_blockio_weight = false;
}
void cgroup_context_free_device_allow(CGroupContext *c, CGroupDeviceAllow *a) {
@@ -92,14 +96,18 @@ void cgroup_context_dump(CGroupContext *c, FILE* f, const
char *prefix) {
%sBlockIOAccounting=%s\n
%sMemoryAccounting=%s\n
%sCPUShares=%lu\n
+%sStartupCPUShares=%lu\n
%sBlockIOWeight=%lu\n
+%sStartupBlockIOWeight=%lu\n
%sMemoryLimit=% PRIu64 \n
%sDevicePolicy=%s\n,
prefix, yes_no(c-cpu_accounting),
prefix, yes_no(c-blockio_accounting),
prefix, yes_no(c-memory_accounting),
prefix, c-cpu_shares,
+prefix, c-startup_cpu_shares,
prefix, c-blockio_weight,
+prefix, c-startup_blockio_weight,
prefix, c-memory_limit,
prefix, cgroup_device_policy_to_string(c-device_policy));
@@ -267,7 +275,7 @@ fail:
return -errno;
}
-void cgroup_context_apply(CGroupContext *c, CGroupControllerMask mask, const
char *path) {
+void cgroup_context_apply(Manager *m, CGroupContext *c, CGroupControllerMask
mask, const char *path) {
bool is_root;
int r;
@@ -284,7 +292,9 @@ void cgroup_context_apply(CGroupContext *c,
CGroupControllerMask mask, const cha
if ((mask CGROUP_CPU) !is_root) {
char buf[DECIMAL_STR_MAX(unsigned long) + 1];
-sprintf(buf, %lu\n, c-cpu_shares);
+sprintf(buf, %lu\n, manager_get_job(m,
m-default_unit_job_id)
+? c-startup_cpu_shares
+: c-cpu_shares);
r = cg_set_attribute(cpu, path, cpu.shares, buf);
if (r 0)
log_warning(Failed to set cpu.shares on %s: %s,
path, strerror(-r));
@@ -298,7 +308,9 @@ void cgroup_context_apply(CGroupContext *c,
CGroupControllerMask mask, const cha
CGroupBlockIODeviceBandwidth *b;
if (!is_root) {
-sprintf(buf, %lu\n, c-blockio_weight);
+sprintf(buf, %lu\n, manager_get_job(m,
m-default_unit_job_id)
+? c-startup_blockio_weight
+: c-blockio_weight);
r = cg_set_attribute(blkio, path, blkio.weight,
buf);
if (r 0)
log_warning(Failed to set blkio.weight on %s:
%s, path, strerror(-r));
@@ -407,11 +419,14 @@ CGroupControllerMask
cgroup_context_get_mask(CGroupContext *c) {
/* Figure out which controllers we need */
-if (c-cpu_accounting || c-cpu_shares != 1024)
+if (c-cpu_accounting ||
+c-cpu_shares != 1024 ||
+c-startup_cpu_shares != 1024)
mask |= CGROUP_CPUACCT | CGROUP_CPU;
if (c-blockio_accounting ||
c-blockio_weight != 1000 ||
+c-startup_blockio_weight != 1000 ||
c-blockio_device_weights ||
c-blockio_device_bandwidths)
mask |= CGROUP_BLKIO;
@@ -637,7 +652,7 @@ static int unit_realize_cgroup_now(Unit *u) {
return r;
/* Finally, apply the necessary attributes. */
-cgroup_context_apply(unit_get_cgroup_context(u), mask, u-cgroup_path);
+cgroup_context_apply(u-manager, unit_get_cgroup_context(u), mask,
u-cgroup_path);
return 0;
}
diff --git a/src/core/cgroup.h
Re: [systemd-devel] StartTransientService problems
On Wed 05 Mar 2014 04:47:13 Lennart Poettering wrote: On Tue, 25.02.14 17:59, Barry Scott (barry.sc...@onelan.co.uk) wrote: Which should make them available via the bus for transient units. If you need other props like this, just let me know and I'll add them too... I just tried to set LimitCORE and that was rejected. Can you add this and the other related LimitXXX items please? Done, in git. Thanks. I did not find detailed docs on how to call StartTransientUnit() I have been reading the systemd sources to figure out the signatures of the call and its parameters. Did I miss API documentation? I would like to test these changes but I have failed to update a F20 system to newer code drops. Do you plan to have a F20 build of the newer systemd at least for testing? I also updated systemd-run to take arbitrary settable properties with a new -p switch to set on the unit that is created. I used that as a testcase for LimitCORE and friends. But this enables a lot of other cool things: # systemd-run -p BlockIOWeight=10 updatedb Is an awesome way to run updatedb in the background without taking much resources, totally cgroup-enabled... Lennart Barry ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd][cgroup in container] problem with cgroup hierarchy in container
On 04.03.2014 21:10, Lennart Poettering wrote: OK, this looks wrong, the machine slice appears to have been used twice in the cgroup path. Can you try this with 210 in the container, and then run systemctl show and report the value of the ControlGroup property, please? If you boot this up with npsawn instead of libvirt-lxc, does t work then? I can reproduce similar behaviour on Fedora 21. I used Linux 3.14.0-0.rc5, systemd 210 on host and guest machine, libvirtd 1.2.2. The CGroup hierarchy for the libvirtd machine looks as follows: ├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 22 ├─machine.slice │ └─machine-lxc\x2dmycontainer.scope │ ├─4282 /libexec/libvirt_lxc --name mycontainer --console 18 --security=selinux --handshake 21 --background │ └─machine.slice │ └─machine-lxc\x2dmycontainer.scope │ ├─4283 /usr/lib/systemd/systemd │ ├─machine.slice │ │ └─machine-lxc\x2dmycontainer.scope │ │ └─user.slice │ │ └─user-0.slice │ │ └─user@0.service │ │ └─4361 /usr/lib/systemd/systemd --user │ ├─system.slice │ │ ├─systemd-logind.service │ │ │ └─4345 /usr/lib/systemd/systemd-logind │ │ ├─dbus.service │ │ │ └─4341 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation │ │ ├─sshd.service │ │ │ └─4347 /usr/sbin/sshd -D │ │ └─systemd-journald.service │ │ └─4319 /usr/lib/systemd/systemd-journald │ └─user.slice │ └─user-0.slice │ ├─session-15.scope │ │ ├─4349 login -- root │ │ └─4374 -bash │ └─user@0.service │ └─4367 (sd-pam) The same container running with systemd-nspawn use below hierarchy: ├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 22 ├─machine.slice │ └─machine-mycontainer.scope │ ├─4459 /usr/lib/systemd/systemd │ ├─system.slice │ │ ├─systemd-logind.service │ │ │ └─4517 /usr/lib/systemd/systemd-logind │ │ ├─dbus.service │ │ │ └─4509 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation │ │ ├─sshd.service │ │ │ └─4519 /usr/sbin/sshd -D │ │ └─systemd-journald.service │ │ └─4483 /usr/lib/systemd/systemd-journald │ └─user.slice │ └─user-0.slice │ ├─session-16.scope │ │ ├─4522 login -- root │ │ └─4560 -bash │ └─user@0.service │ ├─4547 /usr/lib/systemd/systemd --user │ └─4553 (sd-pam) I can't report the value of the ControlGroup property, I get this: # systemctl show Segmentation fault Libvirt only ever creates the first two levels as expected. When starting a guest it invokes a DBus API call to systemd-machined, which talks to systemd to create the cgroups: /sys/fs/cgroup/systemd/machine.slice /sys/fs/cgroup/systemd/machine.slice/machine-lxc\x2dmycontainer.scope The fact that the libvirt_lxc process itself ends up in the right place suggest that this isn't libvirt, but rather systemd is creating these extra levels. It seems to me that systemd create second level (machine.slice/machine-lxc\x2dmycontainer.scope) during /usr/lib/systemd/systemd execution, and the third level during /usr/lib/systemd/systemd --user execution. Regards -- Dariusz Michaluk Samsung RD Institute Poland Samsung Electronics d.micha...@samsung.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Reg: optimize boot process.
Hello Everyone, May any one let me know how to customize systemd to fast boot so that systemd initialization can be done in parallel on the multiple (like - four ) core to speed up boot process. Thanks in advance. Regards, Manmohan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] restore support for enslaving to bonding interface
Hi Mark, On Wed, Mar 5, 2014 at 1:41 AM, Mark Oteiza mvote...@udel.edu wrote: networkd: Restore logic for enslaving to a master bonding interface. Applied. Thanks! Bonding support seems to have been removed right after being added, between 52433f6 (22 Jan) and 54abf46 (25 Jan). http://cgit.freedesktop.org/systemd/systemd/log/src/network/networkd-link.c With this patch, networkd successfully configures the links. Currently, networkd will not dhcp on the bonding interface. Here is my configuration: Also thanks for the bug report. This should now be fixed in git. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Network unreachable in container
This really makes no sense to me at all, i don't grok a word of what you are writing here. The term host refers the system the containers run on, usually... Your remark here is relevant. After googling a little bit Linux container, many wiki/articles refer to the HOST as opposed to the CONTAINER. But you are right, as traditionally the term host in the computing language refers to the machine you are running on. Virtual machines, and now container become more and more popular, and in this way we maybe shall to think about a correct term, different from the generic host, to define the primary OS. When reading about container setup, I found myself many times unable to understand on which system configuration files shall be installed. And left with this question : what system I am running on ? This clarification could well help all wiki dealing with virtualization. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] StartupFinished signal is not sent on 210
On Wed, 05.03.14 09:07, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote: Of course, I must admit it is less than ideal that with logind around you might be able to get away with never calling it... That certainly hides bugs... We don't have logind and we certainly weren't calling Subscribe(). Then I can't explain how come we were receiving the signal, can you? Could it be that one of systemd applications was subscribing and we were just lucky to get the signal? machined and logind are the only ones in the systemd tree that call it currently. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC][PATCH 0/2] journald: add support for wall forwarding
Hi, I want journald to send emergency messages to logged-in users, and I think this is a general enough way to do it. These patches adds two new options for journald.conf: * ForwardToWall (default no) * MaxLevelWall (default emerg) When ForwardToWall is yes, journald forwards all log messages equal or below MaxLevelWall to utmp_wall(). A forwarded log message looks like this when it gets written to a users terminal: Broadcast message from systemd-journald@hostname (Wed 2014-03-05 13:00:00 CET): some-process[4711]: This is an emergency log message from some-process! Comments? If you think this the correct approach, please consider applying these patches :) Sebastian Thorarensen (2): utmp-wtmp: allow overriding username on wall journald: add support for wall forwarding Makefile.am|2 + man/journald.conf.xml | 40 +++-- src/journal/journald-gperf.gperf |2 + src/journal/journald-native.c |4 ++ src/journal/journald-server.c |7 +++ src/journal/journald-server.h |2 + src/journal/journald-stream.c |4 ++ src/journal/journald-syslog.c |4 ++ src/journal/journald-wall.c| 59 src/journal/journald-wall.h| 26 + src/journal/journald.conf |2 + src/shared/utmp-wtmp.c | 12 ++-- src/shared/utmp-wtmp.h |2 +- src/shutdownd/shutdownd.c |2 +- src/systemctl/systemctl.c |4 +- .../tty-ask-password-agent.c |2 +- 16 files changed, 148 insertions(+), 26 deletions(-) create mode 100644 src/journal/journald-wall.c create mode 100644 src/journal/journald-wall.h -- 1.7.10.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC][PATCH 1/2] utmp-wtmp: allow overriding username on wall
utmp_wall() now takes an optional argument 'username_override' which
allows the caller to override the username shown on wall messages.
journald will use this to inform users that its wall messages comes from
'systemd-journald'.
---
src/shared/utmp-wtmp.c | 12 +++-
src/shared/utmp-wtmp.h |2 +-
src/shutdownd/shutdownd.c |2 +-
src/systemctl/systemctl.c |4 ++--
src/tty-ask-password-agent/tty-ask-password-agent.c |2 +-
5 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/src/shared/utmp-wtmp.c b/src/shared/utmp-wtmp.c
index 32996fa..0200798 100644
--- a/src/shared/utmp-wtmp.c
+++ b/src/shared/utmp-wtmp.c
@@ -347,16 +347,18 @@ static int write_to_terminal(const char *tty, const char
*message) {
return 0;
}
-int utmp_wall(const char *message, bool (*match_tty)(const char *tty)) {
+int utmp_wall(const char *message, const char *username_override, bool
(*match_tty)(const char *tty)) {
_cleanup_free_ char *text = NULL, *hn = NULL, *un = NULL, *tty = NULL;
char date[FORMAT_TIMESTAMP_MAX];
struct utmpx *u;
int r;
-hn = gethostname_malloc();
-un = getlogname_malloc();
-if (!hn || !un)
+if (!(hn = gethostname_malloc()))
return -ENOMEM;
+if (!username_override) {
+if (!(un = getlogname_malloc()))
+return -ENOMEM;
+}
getttyname_harder(STDIN_FILENO, tty);
@@ -364,7 +366,7 @@ int utmp_wall(const char *message, bool (*match_tty)(const
char *tty)) {
\a\r\n
Broadcast message from %s@%s%s%s (%s):\r\n\r\n
%s\r\n\r\n,
- un, hn,
+ un ? un : username_override, hn,
tty ? on : , strempty(tty),
format_timestamp(date, sizeof(date), now(CLOCK_REALTIME)),
message) 0)
diff --git a/src/shared/utmp-wtmp.h b/src/shared/utmp-wtmp.h
index 5924023..f15bbf7 100644
--- a/src/shared/utmp-wtmp.h
+++ b/src/shared/utmp-wtmp.h
@@ -32,4 +32,4 @@ int utmp_put_runlevel(int runlevel, int previous);
int utmp_put_dead_process(const char *id, pid_t pid, int code, int status);
int utmp_put_init_process(const char *id, pid_t pid, pid_t sid, const char
*line);
-int utmp_wall(const char *message, bool (*match_tty)(const char *tty));
+int utmp_wall(const char *message, const char *username_override, bool
(*match_tty)(const char *tty));
diff --git a/src/shutdownd/shutdownd.c b/src/shutdownd/shutdownd.c
index 8d034e6..fafd9ce 100644
--- a/src/shutdownd/shutdownd.c
+++ b/src/shutdownd/shutdownd.c
@@ -143,7 +143,7 @@ static void warn_wall(usec_t n, struct sd_shutdown_command
*c) {
if (asprintf(l, %s%s%s%s!, c-wall_message, c-wall_message[0] ?
\n : ,
prefix, format_timestamp(date, sizeof(date), c-usec)) =
0)
-utmp_wall(l, NULL);
+utmp_wall(l, NULL, NULL);
else
log_error(Failed to allocate wall message);
}
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index f395265..0435d40 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -257,7 +257,7 @@ static void warn_wall(enum action a) {
}
if (*p) {
-utmp_wall(p, NULL);
+utmp_wall(p, NULL, NULL);
return;
}
}
@@ -265,7 +265,7 @@ static void warn_wall(enum action a) {
if (!table[a])
return;
-utmp_wall(table[a], NULL);
+utmp_wall(table[a], NULL, NULL);
}
static bool avoid_bus(void) {
diff --git a/src/tty-ask-password-agent/tty-ask-password-agent.c
b/src/tty-ask-password-agent/tty-ask-password-agent.c
index 7a90e65..fa4d660 100644
--- a/src/tty-ask-password-agent/tty-ask-password-agent.c
+++ b/src/tty-ask-password-agent/tty-ask-password-agent.c
@@ -538,7 +538,7 @@ static int show_passwords(void) {
free(p);
if (wall) {
-utmp_wall(wall, wall_tty_match);
+utmp_wall(wall, NULL, wall_tty_match);
free(wall);
}
}
--
1.7.10.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC][PATCH 2/2] journald: add support for wall forwarding
This will let journald forward logs as messages sent to all logged in users (like wall). Two options are added: * ForwardToWall (default no) * MaxLevelWall (default emerg) 'ForwardToWall' is overridable by kernel command line option 'systemd.journald.forward_to_wall'. This can be used to emulate the traditional syslogd behaviour of sending emergency messages to all logged in users. --- Makefile.am |2 ++ man/journald.conf.xml| 40 +++--- src/journal/journald-gperf.gperf |2 ++ src/journal/journald-native.c|4 +++ src/journal/journald-server.c|7 + src/journal/journald-server.h|2 ++ src/journal/journald-stream.c|4 +++ src/journal/journald-syslog.c|4 +++ src/journal/journald-wall.c | 59 ++ src/journal/journald-wall.h | 26 + src/journal/journald.conf|2 ++ 11 files changed, 136 insertions(+), 16 deletions(-) create mode 100644 src/journal/journald-wall.c create mode 100644 src/journal/journald-wall.h diff --git a/Makefile.am b/Makefile.am index f99cef7..02a2fbf 100644 --- a/Makefile.am +++ b/Makefile.am @@ -3227,6 +3227,8 @@ libsystemd_journal_core_la_SOURCES = \ src/journal/journald-server.h \ src/journal/journald-console.c \ src/journal/journald-console.h \ + src/journal/journald-wall.c \ + src/journal/journald-wall.h \ src/journal/journald-native.c \ src/journal/journald-native.h \ src/journal/journald-rate-limit.c \ diff --git a/man/journald.conf.xml b/man/journald.conf.xml index a814ec1..723d445 100644 --- a/man/journald.conf.xml +++ b/man/journald.conf.xml @@ -381,24 +381,28 @@ termvarnameForwardToSyslog=/varname/term termvarnameForwardToKMsg=/varname/term termvarnameForwardToConsole=/varname/term +termvarnameForwardToWall=/varname/term listitemparaControl whether log messages received by the journal daemon shall be forwarded to a traditional syslog daemon, to the -kernel log buffer (kmsg), or to the -system console. These options take -boolean arguments. If forwarding to -syslog is enabled but no syslog daemon -is running, the respective option has -no effect. By default, only forwarding -to syslog is enabled. These settings -may be overridden at boot time with -the kernel command line options +kernel log buffer (kmsg), to the +system console, or sent as wall +messages to all logged-in users. These +options take boolean arguments. If +forwarding to syslog is enabled but no +syslog daemon is running, the +respective option has no effect. By +default, only forwarding to syslog is +enabled. These settings may be +overridden at boot time with the +kernel command line options literalsystemd.journald.forward_to_syslog=/literal, - literalsystemd.journald.forward_to_kmsg=/literal + literalsystemd.journald.forward_to_kmsg=/literal, + literalsystemd.journald.forward_to_console=/literal and - literalsystemd.journald.forward_to_console=/literal. + literalsystemd.journald.forward_to_wall=/literal. When forwarding to the console, the TTY to log to can be changed with varnameTTYPath=/varname, @@ -410,12 +414,14 @@ termvarnameMaxLevelSyslog=/varname/term termvarnameMaxLevelKMsg=/varname/term termvarnameMaxLevelConsole=/varname/term +termvarnameMaxLevelWall=/varname/term listitemparaControls the maximum log level of messages that are stored -on disk, forwarded to syslog, kmsg or -the console (if
[systemd-devel] [PATCH 0/2] systemd serialization on switch-root
From: Harald Hoyer har...@redhat.com If systemctl switch-root is called with a specific INIT or /proc/cmdline contains init=, then systemd would not serialize itsself. Let systemctl check, if the new init is in the standard systemd installation path and if so, clear the INIT parameter, to let systemd serialize itsself. Harald Hoyer (2): util: add files_same() helper function systemctl: for switch-root check, if we switch to a systemd init src/shared/util.c | 20 +--- src/shared/util.h | 2 ++ src/systemctl/systemctl.c | 11 +++ 3 files changed, 26 insertions(+), 7 deletions(-) -- 1.8.5.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] util: add files_same() helper function
From: Harald Hoyer har...@redhat.com
files_same() returns
1, if the files are the same
0, if the files have different inode/dev numbers
errno, for any stat error
---
src/shared/util.c | 20 +---
src/shared/util.h | 2 ++
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/src/shared/util.c b/src/shared/util.c
index 8c7cfbd..b1341ad 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -3198,19 +3198,25 @@ bool on_tty(void) {
return cached_on_tty;
}
-int running_in_chroot(void) {
+int files_same(const char *filea, const char *fileb) {
struct stat a = {}, b = {};
-/* Only works as root */
-if (stat(/proc/1/root, a) 0)
+if (stat(filea, a) 0)
return -errno;
-if (stat(/, b) 0)
+if (stat(fileb, b) 0)
return -errno;
-return
-a.st_dev != b.st_dev ||
-a.st_ino != b.st_ino;
+return (a.st_dev == b.st_dev a.st_ino == b.st_ino);
+}
+
+int running_in_chroot(void) {
+int ret = files_same(/proc/1/root, /);
+
+if (ret 0)
+return ret;
+
+return (ret == 0);
}
static char *ascii_ellipsize_mem(const char *s, size_t old_length, size_t
new_length, unsigned percent) {
diff --git a/src/shared/util.h b/src/shared/util.h
index e430071..eab8cfd 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -451,6 +451,8 @@ static inline const char *ansi_highlight_off(void) {
return on_tty() ? ANSI_HIGHLIGHT_OFF : ;
}
+int files_same(const char *filea, const char *fileb);
+
int running_in_chroot(void);
char *ellipsize(const char *s, size_t length, unsigned percent);
--
1.8.5.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] systemctl: for switch-root check, if we switch to a systemd init
From: Harald Hoyer har...@redhat.com
If systemctl switch-root is called with a specific INIT or
/proc/cmdline contains init=, then systemd would not serialize
itsself.
Let systemctl check, if the new init is in the standard systemd
installation path and if so, clear the INIT parameter,
to let systemd serialize itsself.
---
src/systemctl/systemctl.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index f395265..18dbcc0 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -4283,6 +4283,7 @@ static int show_environment(sd_bus *bus, char **args) {
static int switch_root(sd_bus *bus, char **args) {
_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
_cleanup_free_ char *init = NULL;
+_cleanup_free_ char *root_systemd_path = NULL;
const char *root;
unsigned l;
int r;
@@ -4309,6 +4310,16 @@ static int switch_root(sd_bus *bus, char **args) {
if (!init)
return log_oom();
+root_systemd_path = strjoin(root, /, SYSTEMD_BINARY_PATH, NULL);
+if (!root_systemd_path)
+return log_oom();
+
+if (files_same(init, root_systemd_path) 0) {
+char *t = init;
+init = strdup();
+free(t);
+}
+
log_debug(switching root - root: %s; init: %s, root, init);
r = sd_bus_call_method(
--
1.8.5.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH 1/2] utmp-wtmp: allow overriding username on wall
Hi,
both patches look useful. Some comments below.
On Wed, Mar 05, 2014 at 01:46:01PM +0100, Sebastian Thorarensen wrote:
utmp_wall() now takes an optional argument 'username_override' which
allows the caller to override the username shown on wall messages.
journald will use this to inform users that its wall messages comes from
'systemd-journald'.
---
src/shared/utmp-wtmp.c | 12 +++-
src/shared/utmp-wtmp.h |2 +-
src/shutdownd/shutdownd.c |2 +-
src/systemctl/systemctl.c |4 ++--
src/tty-ask-password-agent/tty-ask-password-agent.c |2 +-
5 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/src/shared/utmp-wtmp.c b/src/shared/utmp-wtmp.c
index 32996fa..0200798 100644
--- a/src/shared/utmp-wtmp.c
+++ b/src/shared/utmp-wtmp.c
@@ -347,16 +347,18 @@ static int write_to_terminal(const char *tty, const
char *message) {
return 0;
}
-int utmp_wall(const char *message, bool (*match_tty)(const char *tty)) {
+int utmp_wall(const char *message, const char *username_override, bool
(*match_tty)(const char *tty)) {
_cleanup_free_ char *text = NULL, *hn = NULL, *un = NULL, *tty =
NULL;
char date[FORMAT_TIMESTAMP_MAX];
struct utmpx *u;
int r;
-hn = gethostname_malloc();
-un = getlogname_malloc();
-if (!hn || !un)
+if (!(hn = gethostname_malloc()))
return -ENOMEM;
+if (!username_override) {
+if (!(un = getlogname_malloc()))
+return -ENOMEM;
+}
Please keep the assignments out of the if conditionals. And maybe
call username_override just username?
getttyname_harder(STDIN_FILENO, tty);
@@ -364,7 +366,7 @@ int utmp_wall(const char *message, bool
(*match_tty)(const char *tty)) {
\a\r\n
Broadcast message from %s@%s%s%s (%s):\r\n\r\n
%s\r\n\r\n,
- un, hn,
+ un ? un : username_override, hn,
un ?: username_override,
tty ? on : , strempty(tty),
format_timestamp(date, sizeof(date),
now(CLOCK_REALTIME)),
message) 0)
diff --git a/src/shared/utmp-wtmp.h b/src/shared/utmp-wtmp.h
index 5924023..f15bbf7 100644
--- a/src/shared/utmp-wtmp.h
+++ b/src/shared/utmp-wtmp.h
@@ -32,4 +32,4 @@ int utmp_put_runlevel(int runlevel, int previous);
int utmp_put_dead_process(const char *id, pid_t pid, int code, int status);
int utmp_put_init_process(const char *id, pid_t pid, pid_t sid, const char
*line);
-int utmp_wall(const char *message, bool (*match_tty)(const char *tty));
+int utmp_wall(const char *message, const char *username_override, bool
(*match_tty)(const char *tty));
diff --git a/src/shutdownd/shutdownd.c b/src/shutdownd/shutdownd.c
index 8d034e6..fafd9ce 100644
--- a/src/shutdownd/shutdownd.c
+++ b/src/shutdownd/shutdownd.c
@@ -143,7 +143,7 @@ static void warn_wall(usec_t n, struct
sd_shutdown_command *c) {
if (asprintf(l, %s%s%s%s!, c-wall_message, c-wall_message[0] ?
\n : ,
prefix, format_timestamp(date, sizeof(date), c-usec))
= 0)
-utmp_wall(l, NULL);
+utmp_wall(l, NULL, NULL);
else
log_error(Failed to allocate wall message);
}
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index f395265..0435d40 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -257,7 +257,7 @@ static void warn_wall(enum action a) {
}
if (*p) {
-utmp_wall(p, NULL);
+utmp_wall(p, NULL, NULL);
return;
}
}
@@ -265,7 +265,7 @@ static void warn_wall(enum action a) {
if (!table[a])
return;
-utmp_wall(table[a], NULL);
+utmp_wall(table[a], NULL, NULL);
}
static bool avoid_bus(void) {
diff --git a/src/tty-ask-password-agent/tty-ask-password-agent.c
b/src/tty-ask-password-agent/tty-ask-password-agent.c
index 7a90e65..fa4d660 100644
--- a/src/tty-ask-password-agent/tty-ask-password-agent.c
+++ b/src/tty-ask-password-agent/tty-ask-password-agent.c
@@ -538,7 +538,7 @@ static int show_passwords(void) {
free(p);
if (wall) {
-utmp_wall(wall, wall_tty_match);
+utmp_wall(wall, NULL, wall_tty_match);
free(wall);
}
}
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] [V2] systemctl: for switch-root check, if we switch to a systemd init
From: Harald Hoyer har...@redhat.com
If systemctl switch-root is called with a specific INIT or
/proc/cmdline contains init=, then systemd would not serialize
itsself.
Let systemctl check, if the new init is in the standard systemd
installation path and if so, clear the INIT parameter,
to let systemd serialize itsself.
---
Version 2: now with new root prepended to init also.
src/systemctl/systemctl.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index f395265..cfdda43 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -4283,6 +4283,8 @@ static int show_environment(sd_bus *bus, char **args) {
static int switch_root(sd_bus *bus, char **args) {
_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
_cleanup_free_ char *init = NULL;
+_cleanup_free_ char *root_init_path = NULL;
+_cleanup_free_ char *root_systemd_path = NULL;
const char *root;
unsigned l;
int r;
@@ -4309,6 +4311,22 @@ static int switch_root(sd_bus *bus, char **args) {
if (!init)
return log_oom();
+if (init[0]) {
+root_systemd_path = strjoin(root, /, SYSTEMD_BINARY_PATH,
NULL);
+if (!root_systemd_path)
+return log_oom();
+
+root_init_path = strjoin(root, /, init, NULL);
+if (!root_init_path)
+return log_oom();
+
+if (files_same(root_init_path, root_systemd_path) 0) {
+char *t = init;
+init = strdup();
+free(t);
+}
+}
+
log_debug(switching root - root: %s; init: %s, root, init);
r = sd_bus_call_method(
--
1.8.5.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC][PATCH 2/2] journald: add support for wall forwarding
On Wed, Mar 05, 2014 at 01:45:51PM +0100, Sebastian Thorarensen wrote: This will let journald forward logs as messages sent to all logged in users (like wall). Two options are added: * ForwardToWall (default no) Is there a good reason not to set it to yes by default? * MaxLevelWall (default emerg) 'ForwardToWall' is overridable by kernel command line option 'systemd.journald.forward_to_wall'. This can be used to emulate the traditional syslogd behaviour of sending emergency messages to all logged in users. --- Makefile.am |2 ++ man/journald.conf.xml| 40 +++--- src/journal/journald-gperf.gperf |2 ++ src/journal/journald-native.c|4 +++ src/journal/journald-server.c|7 + src/journal/journald-server.h|2 ++ src/journal/journald-stream.c|4 +++ src/journal/journald-syslog.c|4 +++ src/journal/journald-wall.c | 59 ++ src/journal/journald-wall.h | 26 + src/journal/journald.conf|2 ++ 11 files changed, 136 insertions(+), 16 deletions(-) create mode 100644 src/journal/journald-wall.c create mode 100644 src/journal/journald-wall.h diff --git a/Makefile.am b/Makefile.am index f99cef7..02a2fbf 100644 --- a/Makefile.am +++ b/Makefile.am @@ -3227,6 +3227,8 @@ libsystemd_journal_core_la_SOURCES = \ src/journal/journald-server.h \ src/journal/journald-console.c \ src/journal/journald-console.h \ + src/journal/journald-wall.c \ + src/journal/journald-wall.h \ src/journal/journald-native.c \ src/journal/journald-native.h \ src/journal/journald-rate-limit.c \ diff --git a/man/journald.conf.xml b/man/journald.conf.xml index a814ec1..723d445 100644 --- a/man/journald.conf.xml +++ b/man/journald.conf.xml @@ -381,24 +381,28 @@ termvarnameForwardToSyslog=/varname/term termvarnameForwardToKMsg=/varname/term termvarnameForwardToConsole=/varname/term + termvarnameForwardToWall=/varname/term listitemparaControl whether log messages received by the journal daemon shall be forwarded to a traditional syslog daemon, to the -kernel log buffer (kmsg), or to the -system console. These options take -boolean arguments. If forwarding to -syslog is enabled but no syslog daemon -is running, the respective option has -no effect. By default, only forwarding -to syslog is enabled. These settings -may be overridden at boot time with -the kernel command line options +kernel log buffer (kmsg), to the +system console, or sent as wall +messages to all logged-in users. These +options take boolean arguments. If +forwarding to syslog is enabled but no +syslog daemon is running, the +respective option has no effect. By +default, only forwarding to syslog is +enabled. These settings may be +overridden at boot time with the +kernel command line options literalsystemd.journald.forward_to_syslog=/literal, - literalsystemd.journald.forward_to_kmsg=/literal + literalsystemd.journald.forward_to_kmsg=/literal, + literalsystemd.journald.forward_to_console=/literal and - literalsystemd.journald.forward_to_console=/literal. + literalsystemd.journald.forward_to_wall=/literal. When forwarding to the console, the TTY to log to can be changed with varnameTTYPath=/varname, @@ -410,12 +414,14 @@ termvarnameMaxLevelSyslog=/varname/term termvarnameMaxLevelKMsg=/varname/term termvarnameMaxLevelConsole=/varname/term +termvarnameMaxLevelWall=/varname/term
Re: [systemd-devel] [PATCH 2/2] systemctl: for switch-root check, if we switch to a systemd init
On Wed, Mar 05, 2014 at 02:37:47PM +0100, har...@redhat.com wrote:
From: Harald Hoyer har...@redhat.com
If systemctl switch-root is called with a specific INIT or
/proc/cmdline contains init=, then systemd would not serialize
itsself.
Let systemctl check, if the new init is in the standard systemd
installation path and if so, clear the INIT parameter,
to let systemd serialize itsself.
---
src/systemctl/systemctl.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index f395265..18dbcc0 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -4283,6 +4283,7 @@ static int show_environment(sd_bus *bus, char **args) {
static int switch_root(sd_bus *bus, char **args) {
_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
_cleanup_free_ char *init = NULL;
+_cleanup_free_ char *root_systemd_path = NULL;
const char *root;
unsigned l;
int r;
@@ -4309,6 +4310,16 @@ static int switch_root(sd_bus *bus, char **args) {
if (!init)
return log_oom();
+root_systemd_path = strjoin(root, /, SYSTEMD_BINARY_PATH, NULL);
+if (!root_systemd_path)
+return log_oom();
+
+if (files_same(init, root_systemd_path) 0) {
+char *t = init;
+init = strdup();
+free(t);
Maybe the old value should be kept on oom error?
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] systemctl: for switch-root check, if we switch to a systemd init
On 03/05/2014 02:55 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Mar 05, 2014 at 02:37:47PM +0100, har...@redhat.com wrote:
From: Harald Hoyer har...@redhat.com
If systemctl switch-root is called with a specific INIT or
/proc/cmdline contains init=, then systemd would not serialize
itsself.
Let systemctl check, if the new init is in the standard systemd
installation path and if so, clear the INIT parameter,
to let systemd serialize itsself.
---
src/systemctl/systemctl.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index f395265..18dbcc0 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -4283,6 +4283,7 @@ static int show_environment(sd_bus *bus, char **args) {
static int switch_root(sd_bus *bus, char **args) {
_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
_cleanup_free_ char *init = NULL;
+_cleanup_free_ char *root_systemd_path = NULL;
const char *root;
unsigned l;
int r;
@@ -4309,6 +4310,16 @@ static int switch_root(sd_bus *bus, char **args) {
if (!init)
return log_oom();
+root_systemd_path = strjoin(root, /, SYSTEMD_BINARY_PATH, NULL);
+if (!root_systemd_path)
+return log_oom();
+
+if (files_same(init, root_systemd_path) 0) {
+char *t = init;
+init = strdup();
+free(t);
Maybe the old value should be kept on oom error?
Zbyszek
Well, on oom, we most likely are screwed on sending the dbus message later on
anyway.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Subscribe from commandline
Hi Guys, Probably this question has been asked before and it might be a DBus list question rather than systemd but just asking anyway, so please pardon my ignorance. I am using dbus-send to get some properties out of systemd dbus messages when an application dies. The thing is that I need to send Subscribe first to systemd so that I can receive those messages. But if I use dbus-send from commandline it immediately exits and then there is no where to receive the death notification messages (since there are no active subscriptions). How are you guys testing this? Write any script that stays? Any example I can follow? Thanks.___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Subscribe from commandline
On Wed, 05.03.14 08:42, Usman (deser...@yahoo.com) wrote: Hi Guys, Probably this question has been asked before and it might be a DBus list question rather than systemd but just asking anyway, so please pardon my ignorance. I am using dbus-send to get some properties out of systemd dbus messages when an application dies. The thing is that I need to send Subscribe first to systemd so that I can receive those messages. But if I use dbus-send from commandline it immediately exits and then there is no where to receive the death notification messages (since there are no active subscriptions). How are you guys testing this? Write any script that stays? Any example I can follow? Subscribe() is for receiving signals about property changes and new/removed jobs/units. It is not necessary to call this if you just want to invoke a method call and want the response for that. dbus-send cannot listen for signals, it only does method invocations, hence Subscribe() does not apply to it at all... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-backlight and backlight level 0
systemd-backlight saves backlight levels on shutdown, and restores them on startup. However, on some systems, backlight level 0 actually turns the backlight *off*; this can potentially make the system unusable. Complicating matters, on most systems, nothing pays attention to the brightness adjustment keys in text mode. I'd suggest one or both of the following two changes, to avoid a painful failure mode: - systemd-backlight should avoid saving/restoring a backlight level of 0, and have a minimum backlight level. (Possibly overridable via configuration, for people who *really* want to restore backlight level 0.) - Something ought to listen to the brightness keys (and perhaps other hotkeys) in pure text mode. systemd seems like a good place for such a something to live. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-backlight and backlight level 0
Hi On Wed, Mar 5, 2014 at 6:46 PM, Josh Triplett j...@joshtriplett.org wrote: systemd-backlight saves backlight levels on shutdown, and restores them on startup. However, on some systems, backlight level 0 actually turns the backlight *off*; this can potentially make the system unusable. Complicating matters, on most systems, nothing pays attention to the brightness adjustment keys in text mode. I'd suggest one or both of the following two changes, to avoid a painful failure mode: - systemd-backlight should avoid saving/restoring a backlight level of 0, and have a minimum backlight level. (Possibly overridable via configuration, for people who *really* want to restore backlight level 0.) Never restoring val==0 seems fine to me. - Something ought to listen to the brightness keys (and perhaps other hotkeys) in pure text mode. systemd seems like a good place for such a something to live. We cannot do that. It requires keymap-handling (as brightness keys are handled on the keysym, not keycode level) and this is exclusive territory of the compositor (or other foreground session controllers). Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-backlight and backlight level 0
On Wed, 05.03.14 09:46, Josh Triplett (j...@joshtriplett.org) wrote: systemd-backlight saves backlight levels on shutdown, and restores them on startup. However, on some systems, backlight level 0 actually turns the backlight *off*; this can potentially make the system unusable. Complicating matters, on most systems, nothing pays attention to the brightness adjustment keys in text mode. I'd suggest one or both of the following two changes, to avoid a painful failure mode: - systemd-backlight should avoid saving/restoring a backlight level of 0, and have a minimum backlight level. (Possibly overridable via configuration, for people who *really* want to restore backlight level 0.) To deal with situations like this there's systemd.restore_state=0 on the kernel cmdline, see kernel-command-line(7). I could be convinced to fix brightness level 0 to 1 when restoring. But then again, I fear the next people will come then and say 1 is only marginally better than 0, i want the minimum to be 16!... Or even others saying Dude, I only got 3 brightness levels, and you took one away from me So I am not enthusiastic about the idea... - Something ought to listen to the brightness keys (and perhaps other hotkeys) in pure text mode. systemd seems like a good place for such a something to live. That's definitely a job for the DE I am sure, so that can it do an OSD and all the other stuff. We do power button handling in logind only because what it does is relatively important and really close to the system lifecycle... But brightness keys (or volume keys..) are not close at all. I am really sure that that's for the DEs to handle, not us. 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] [systemd][cgroup in container] problem with cgroup hierarchy in container
On Wed, 05.03.14 11:38, Dariusz Michaluk (d.micha...@samsung.com) wrote: I can't report the value of the ControlGroup property, I get this: # systemctl show Segmentation fault Oh, yuck! THis is weird. Can you get a gdb backtrac and/or valgrind run for this? Can't reproduce this here... What's the contents of /proc/1/cgroup in both cases (i.e. the nspawn and the libvrit-lxc case?) Libvirt only ever creates the first two levels as expected. When starting a guest it invokes a DBus API call to systemd-machined, which talks to systemd to create the cgroups: /sys/fs/cgroup/systemd/machine.slice /sys/fs/cgroup/systemd/machine.slice/machine-lxc\x2dmycontainer.scope The fact that the libvirt_lxc process itself ends up in the right place suggest that this isn't libvirt, but rather systemd is creating these extra levels. It seems to me that systemd create second level (machine.slice/machine-lxc\x2dmycontainer.scope) during /usr/lib/systemd/systemd execution, and the third level during /usr/lib/systemd/systemd --user execution. nspawn and libvirt-lxc mostly follow the same code paths and register via machined... So it's weird that different things happen. Somehow the systemd instance inside the container must be confused about the cgroup it is running in... 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 1/2] util: add files_same() helper function
On Wed, 05.03.14 14:37, har...@redhat.com (har...@redhat.com) wrote:
-return
-a.st_dev != b.st_dev ||
-a.st_ino != b.st_ino;
+return (a.st_dev == b.st_dev a.st_ino == b.st_ino);
No need for the extra ()...
+}
+
+int running_in_chroot(void) {
+int ret = files_same(/proc/1/root, /);
Please avoid calling functions in variable declarations. We try to avoid
that in our code, to keep variable declarations and code seperate
(initialization with a constant value is fine).
+
+if (ret 0)
+return ret;
+
+return (ret == 0);
No need for the extra ()
Otherwise looks good.
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] systemctl: for switch-root check, if we switch to a systemd init
On Wed, 05.03.14 14:37, har...@redhat.com (har...@redhat.com) wrote:
From: Harald Hoyer har...@redhat.com
If systemctl switch-root is called with a specific INIT or
/proc/cmdline contains init=, then systemd would not serialize
itsself.
Let systemctl check, if the new init is in the standard systemd
installation path and if so, clear the INIT parameter,
to let systemd serialize itsself.
---
src/systemctl/systemctl.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index f395265..18dbcc0 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -4283,6 +4283,7 @@ static int show_environment(sd_bus *bus, char **args) {
static int switch_root(sd_bus *bus, char **args) {
_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
_cleanup_free_ char *init = NULL;
+_cleanup_free_ char *root_systemd_path = NULL;
const char *root;
unsigned l;
int r;
@@ -4309,6 +4310,16 @@ static int switch_root(sd_bus *bus, char **args) {
if (!init)
return log_oom();
+root_systemd_path = strjoin(root, /, SYSTEMD_BINARY_PATH, NULL);
+if (!root_systemd_path)
+return log_oom();
We can simplify this and allocate it on the stack:
char *root_systemd_path;
root_systemd_path = strappaneda(root, / SYSTEMD_BINARY_PATH);
And then we don't have to do the OOM check anymore...
+
+if (files_same(init, root_systemd_path) 0) {
+char *t = init;
+init = strdup();
+free(t);
This is actually unnecessary, the sd-bus libraries will automatically
serialize when they encounter a NULL string. Actually, switch_root()
could be simplified a bit making use of this...
Just use:
free(init);
init = NULL;
or so...
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] core: add startup resource control option
When is startup considered over? I'd like if it meant before the WantedBy unit was started so this value still has use for arbitrary startup. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Reg: optimize boot process.
Manmohan Singh manmohan.mani2...@gmail.com schrieb: Hello Everyone, May any one let me know how to customize systemd to fast boot so that systemd initialization can be done in parallel on the multiple (like - four ) core to speed up boot process. Systemd already does this by design unintentionally. The prime goal of systemd wasn't speed but it's design naturally provides massive auto- parallelization and automatic resolving of dependencies. For that to work, however, you have to use units that natively use systemd's configuration syntax and socket activation where possible (so you can throw away dependency info), and not sysvinit wrappers with manual dependency info (which will serialize the boot process). You may want to boot it on a filesystem that scales well to parallel workload (i.e., reiserfs doesn't), maybe enable the readahead service and use a filesystem for which systemd handles defragmentation and/or relocation (like ext4 or btrfs). Most of the time, the problem with slow boot is not in systemd itself but in lvm activation, initramfs scripts, network scripts, etc. As a first pointer activate systemd's bootchart service and look at its output. Then come back with what you found. ;-) BTW: As an example, I found that initializing networking wrong will have a bad effect on display manager startup times. I switched to NetworkManager (from netctl) and the problem went away. I had a 30s delay in starting my xsession with lightdm, this delay is gone since I'm using NetworkManager. Now boot time until X startup (without loading the desktop) is down from 90s+ to around 25s. -- Replies to list only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-backlight and backlight level 0
On Wed, Mar 05, 2014 at 06:59:27PM +0100, David Herrmann wrote: On Wed, Mar 5, 2014 at 6:46 PM, Josh Triplett j...@joshtriplett.org wrote: systemd-backlight saves backlight levels on shutdown, and restores them on startup. However, on some systems, backlight level 0 actually turns the backlight *off*; this can potentially make the system unusable. Complicating matters, on most systems, nothing pays attention to the brightness adjustment keys in text mode. I'd suggest one or both of the following two changes, to avoid a painful failure mode: - systemd-backlight should avoid saving/restoring a backlight level of 0, and have a minimum backlight level. (Possibly overridable via configuration, for people who *really* want to restore backlight level 0.) Never restoring val==0 seems fine to me. Likewise. - Something ought to listen to the brightness keys (and perhaps other hotkeys) in pure text mode. systemd seems like a good place for such a something to live. We cannot do that. It requires keymap-handling (as brightness keys are handled on the keysym, not keycode level) and this is exclusive territory of the compositor (or other foreground session controllers). Perhaps this will get fixed when we switch from kernel VTs to a userspace-managed console, then. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-backlight and backlight level 0
On Wed, Mar 05, 2014 at 07:10:51PM +0100, Lennart Poettering wrote: On Wed, 05.03.14 09:46, Josh Triplett (j...@joshtriplett.org) wrote: systemd-backlight saves backlight levels on shutdown, and restores them on startup. However, on some systems, backlight level 0 actually turns the backlight *off*; this can potentially make the system unusable. Complicating matters, on most systems, nothing pays attention to the brightness adjustment keys in text mode. I'd suggest one or both of the following two changes, to avoid a painful failure mode: - systemd-backlight should avoid saving/restoring a backlight level of 0, and have a minimum backlight level. (Possibly overridable via configuration, for people who *really* want to restore backlight level 0.) To deal with situations like this there's systemd.restore_state=0 on the kernel cmdline, see kernel-command-line(7). Yeah, I've seen that one; however, having to reboot the system and change the kernel command line to unbreak it seems less ideal than having the system avoid broken states to begin with. I could be convinced to fix brightness level 0 to 1 when restoring. But then again, I fear the next people will come then and say 1 is only marginally better than 0, i want the minimum to be 16!... Or even others saying Dude, I only got 3 brightness levels, and you took one away from me So I am not enthusiastic about the idea... Given the choice between maximum flexibility and never making the system unusable, I'll take the latter. Not that hard to make it configurable, if that proves necessary. On restore, I'd suggest reading max_brightness, and if the stored value falls under a threshold of ceil(max_brightness/SOME_DIVISOR), restore it to that value instead. (Ideally there should be some way to ask the driver what level of brightness will produce a non-zero value in actual_brightness, but no such mechanism seems to exist.) Does that sound reasonable? - Something ought to listen to the brightness keys (and perhaps other hotkeys) in pure text mode. systemd seems like a good place for such a something to live. That's definitely a job for the DE I am sure, so that can it do an OSD and all the other stuff. We do power button handling in logind only because what it does is relatively important and really close to the system lifecycle... But brightness keys (or volume keys..) are not close at all. I am really sure that that's for the DEs to handle, not us. DEs don't handle the text consoles. However, it does sound like this will have to wait for kmscon or equivalent. - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] man: ipv4 link-local
--- TODO|1 - man/systemd.network.xml |9 + 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/TODO b/TODO index fd75eab..dbfe48e 100644 --- a/TODO +++ b/TODO @@ -670,7 +670,6 @@ Features: - add proper initrd support (in particular generate .network/.link files based on /proc/cmdline) - add reduced [Link] support to .network files - add IPv4LL tests (inspire by DHCP) - - add IPv4LL to man pages. Explain coexistance between DHCP - add Scope= parsing option for [Network] - change LL address generation and make it predictable like get_mac() (link-config.c) - have smooth transition from LL to routable address, without disconnecting clients. diff --git a/man/systemd.network.xml b/man/systemd.network.xml index fcf48c6..4118fc9 100644 --- a/man/systemd.network.xml +++ b/man/systemd.network.xml @@ -189,6 +189,15 @@ /listitem /varlistentry varlistentry +termvarnameIPv4LL=/varname/term +listitem +paraA boolean. When true, enables IPv4 link-local support. +If literalDHCP=/literal is also true, IPv4 link-local +address will be removed upon acquiring a DHCP lease. +/para +/listitem +/varlistentry +varlistentry termvarnameAddress=/varname/term listitem paraA static IPv4 or IPv6 address and its prefix length, -- 1.7.10.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd][cgroup in container] problem with cgroup hierarchy in container
I can reproduce similar behaviour on Fedora 21. I used Linux 3.14.0-0.rc5, systemd 210 on host and guest machine, libvirtd 1.2.2. See this yesterday thread Network unreachable in container and Lennart comment : What is Host ? What is guest ?? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: ipv4 link-local
Applied. Thanks! -t On Wed, Mar 5, 2014 at 8:51 PM, Umut Tezduyar Lindskog umut.tezdu...@axis.com wrote: --- TODO|1 - man/systemd.network.xml |9 + 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/TODO b/TODO index fd75eab..dbfe48e 100644 --- a/TODO +++ b/TODO @@ -670,7 +670,6 @@ Features: - add proper initrd support (in particular generate .network/.link files based on /proc/cmdline) - add reduced [Link] support to .network files - add IPv4LL tests (inspire by DHCP) - - add IPv4LL to man pages. Explain coexistance between DHCP - add Scope= parsing option for [Network] - change LL address generation and make it predictable like get_mac() (link-config.c) - have smooth transition from LL to routable address, without disconnecting clients. diff --git a/man/systemd.network.xml b/man/systemd.network.xml index fcf48c6..4118fc9 100644 --- a/man/systemd.network.xml +++ b/man/systemd.network.xml @@ -189,6 +189,15 @@ /listitem /varlistentry varlistentry + termvarnameIPv4LL=/varname/term +listitem +paraA boolean. When true, enables IPv4 link-local support. +If literalDHCP=/literal is also true, IPv4 link-local +address will be removed upon acquiring a DHCP lease. +/para +/listitem +/varlistentry +varlistentry termvarnameAddress=/varname/term listitem paraA static IPv4 or IPv6 address and its prefix length, -- 1.7.10.4 ___ 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] systemd-backlight and backlight level 0
Hi On Wed, Mar 5, 2014 at 8:31 PM, Josh Triplett j...@joshtriplett.org wrote: On Wed, Mar 05, 2014 at 07:10:51PM +0100, Lennart Poettering wrote: On Wed, 05.03.14 09:46, Josh Triplett (j...@joshtriplett.org) wrote: systemd-backlight saves backlight levels on shutdown, and restores them on startup. However, on some systems, backlight level 0 actually turns the backlight *off*; this can potentially make the system unusable. Complicating matters, on most systems, nothing pays attention to the brightness adjustment keys in text mode. I'd suggest one or both of the following two changes, to avoid a painful failure mode: - systemd-backlight should avoid saving/restoring a backlight level of 0, and have a minimum backlight level. (Possibly overridable via configuration, for people who *really* want to restore backlight level 0.) To deal with situations like this there's systemd.restore_state=0 on the kernel cmdline, see kernel-command-line(7). Yeah, I've seen that one; however, having to reboot the system and change the kernel command line to unbreak it seems less ideal than having the system avoid broken states to begin with. I'd expect this to be set on the recovery boot option. At I know some distros always provide two boot entries and to me this seems like the right place to set it. I could be convinced to fix brightness level 0 to 1 when restoring. But then again, I fear the next people will come then and say 1 is only marginally better than 0, i want the minimum to be 16!... Or even others saying Dude, I only got 3 brightness levels, and you took one away from me So I am not enthusiastic about the idea... Given the choice between maximum flexibility and never making the system unusable, I'll take the latter. Not that hard to make it configurable, if that proves necessary. On restore, I'd suggest reading max_brightness, and if the stored value falls under a threshold of ceil(max_brightness/SOME_DIVISOR), restore it to that value instead. (Ideally there should be some way to ask the driver what level of brightness will produce a non-zero value in actual_brightness, but no such mechanism seems to exist.) Does that sound reasonable? - Something ought to listen to the brightness keys (and perhaps other hotkeys) in pure text mode. systemd seems like a good place for such a something to live. That's definitely a job for the DE I am sure, so that can it do an OSD and all the other stuff. We do power button handling in logind only because what it does is relatively important and really close to the system lifecycle... But brightness keys (or volume keys..) are not close at all. I am really sure that that's for the DEs to handle, not us. DEs don't handle the text consoles. However, it does sound like this will have to wait for kmscon or equivalent. Yepp. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-backlight and backlight level 0
On Wed, Mar 05, 2014 at 10:21:17PM +0100, David Herrmann wrote: On Wed, Mar 5, 2014 at 8:31 PM, Josh Triplett j...@joshtriplett.org wrote: On Wed, Mar 05, 2014 at 07:10:51PM +0100, Lennart Poettering wrote: On Wed, 05.03.14 09:46, Josh Triplett (j...@joshtriplett.org) wrote: systemd-backlight saves backlight levels on shutdown, and restores them on startup. However, on some systems, backlight level 0 actually turns the backlight *off*; this can potentially make the system unusable. Complicating matters, on most systems, nothing pays attention to the brightness adjustment keys in text mode. I'd suggest one or both of the following two changes, to avoid a painful failure mode: - systemd-backlight should avoid saving/restoring a backlight level of 0, and have a minimum backlight level. (Possibly overridable via configuration, for people who *really* want to restore backlight level 0.) To deal with situations like this there's systemd.restore_state=0 on the kernel cmdline, see kernel-command-line(7). Yeah, I've seen that one; however, having to reboot the system and change the kernel command line to unbreak it seems less ideal than having the system avoid broken states to begin with. I'd expect this to be set on the recovery boot option. At I know some distros always provide two boot entries and to me this seems like the right place to set it. Not a bad idea, but rather than requiring the addition of an extra option (or potentially more than one, if other parts of systemd might want to be more conservative on recovery as well), how about having systemd-backlight treat single as systemd.restore_state=0? - Josh Triplett ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] systemd-run: extend bash completion
From: Thomas Hindoe Paaboel Andersen pho...@gmail.com
--system
-H --host
-M --machine
--service-type (options: simple forking oneshot dbus notify idle)
--uid
--gid
--nice
--setenv
-p --property (options read from bus_append_unit_property_assignment)
---
shell-completion/bash/systemd-run | 39 +--
1 file changed, 37 insertions(+), 2 deletions(-)
diff --git a/shell-completion/bash/systemd-run
b/shell-completion/bash/systemd-run
index ab55274..d4e4f98 100644
--- a/shell-completion/bash/systemd-run
+++ b/shell-completion/bash/systemd-run
@@ -25,9 +25,16 @@ __systemctl() {
__get_slice_units () { __systemctl $1 list-units --all -t slice \
| { while read -r a b c d; do echo $a; done; }; }
+__get_machines() {
+local a b
+machinectl list --no-legend --no-pager | { while read a b; do echo
$a; done; };
+}
+
_systemd_run() {
local cur=${COMP_WORDS[COMP_CWORD]} prev=${COMP_WORDS[COMP_CWORD-1]}
-local OPTS='-h --help --version --user --scope --unit --description
--slice -r --remain-after-exit --send-sighup'
+local OPTS='-h --help --version --user --system --scope --unit
--description --slice
+-r --remain-after-exit --send-sighup -H --host -M --machine
--service-type
+--uid --gid --nice --setenv -p --property'
local mode=--system
local i
@@ -40,7 +47,7 @@ _systemd_run() {
[[ ${COMP_WORDS[i]} == --user ]] mode=--user
-[[ $i -lt $COMP_CWORD ${COMP_WORDS[i]} ==
@(--unit|--description|--slice) ]] ((i++))
+[[ $i -lt $COMP_CWORD ${COMP_WORDS[i]} ==
@(--unit|--description|--slice|--service-type|-H|--host|-M|--machine|-p|--property)
]] ((i++))
done
case $prev in
@@ -54,6 +61,34 @@ _systemd_run() {
COMPREPLY=( $(compgen -W '$comps' -- $cur) )
return 0
;;
+--service-type)
+local comps='simple forking oneshot dbus notify idle'
+
+COMPREPLY=( $(compgen -W '$comps' -- $cur) )
+return 0
+;;
+-p|--property)
+local comps='CPUAccounting= MemoryAccounting= BlockIOAccounting=
SendSIGHUP=
+ SendSIGKILL= MemoryLimit= CPUShares= BlockIOWeight=
User= Group=
+ DevicePolicy= KillMode= DeviceAllow=
BlockIOReadBandwidth=
+ BlockIOWriteBandwidth= BlockIODeviceWeight= Nice=
Environment=
+ KillSignal='
+
+COMPREPLY=( $(compgen -W '$comps' -- $cur) )
+return 0
+;;
+-H|--host)
+local comps=$(compgen -A hostname)
+
+COMPREPLY=( $(compgen -W '$comps' -- $cur) )
+return 0
+;;
+-M|--machine)
+local comps=$( __get_machines )
+
+COMPREPLY=( $(compgen -W '$comps' -- $cur) )
+return 0
+;;
esac
COMPREPLY=( $(compgen -W '${OPTS[*]}' -- $cur) )
--
1.8.5.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Subscribe from commandline
Thanks Lennart. Is there a way I can do it from shell rather than writing C or Java code? I just want to quickly verify that the messages I get once Unit state changes. Any example? Thanks. On Wednesday, March 5, 2014 2:22 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 05.03.14 08:42, Usman (deser...@yahoo.com) wrote: Hi Guys, Probably this question has been asked before and it might be a DBus list question rather than systemd but just asking anyway, so please pardon my ignorance. I am using dbus-send to get some properties out of systemd dbus messages when an application dies. The thing is that I need to send Subscribe first to systemd so that I can receive those messages. But if I use dbus-send from commandline it immediately exits and then there is no where to receive the death notification messages (since there are no active subscriptions). How are you guys testing this? Write any script that stays? Any example I can follow? Subscribe() is for receiving signals about property changes and new/removed jobs/units. It is not necessary to call this if you just want to invoke a method call and want the response for that. dbus-send cannot listen for signals, it only does method invocations, hence Subscribe() does not apply to it at all... 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 2/2] journald: add support for wall forwarding
On Wed, 5 Mar 2014, Zbigniew Jędrzejewski-Szmek wrote: On Wed, Mar 05, 2014 at 01:45:51PM +0100, Sebastian Thorarensen wrote: This will let journald forward logs as messages sent to all logged in users (like wall). Two options are added: * ForwardToWall (default no) Is there a good reason not to set it to yes by default? I set it to no just to keep the old behaviour, but it propably makes more sense to have enabled as default. I will set the default to yes in the next patch version. -- Sebastian Thorarensen___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC][PATCH v2 0/2] journald: add support for wall forwarding
Thanks for the review. Here is an updated version of the patches. Changes since v1: * ForwardToWall is now enabled by default * Fixed errors in journald-wall.c (a colon was printed even when there was no identifier and pid) * Coding style fixes Sebastian Thorarensen (2): utmp-wtmp: allow overriding username on wall journald: add support for wall forwarding Makefile.am|2 + man/journald.conf.xml | 40 +++- src/journal/journald-gperf.gperf |2 + src/journal/journald-native.c |4 ++ src/journal/journald-server.c |8 +++ src/journal/journald-server.h |2 + src/journal/journald-stream.c |4 ++ src/journal/journald-syslog.c |4 ++ src/journal/journald-wall.c| 67 src/journal/journald-wall.h| 26 src/journal/journald.conf |2 + src/shared/utmp-wtmp.c | 12 ++-- src/shared/utmp-wtmp.h |2 +- src/shutdownd/shutdownd.c |2 +- src/systemctl/systemctl.c |4 +- .../tty-ask-password-agent.c |2 +- 16 files changed, 158 insertions(+), 25 deletions(-) create mode 100644 src/journal/journald-wall.c create mode 100644 src/journal/journald-wall.h -- 1.7.10.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC][PATCH v2 1/2] utmp-wtmp: allow overriding username on wall
utmp_wall() now takes an optional argument 'username_override' which
allows the caller to override the username shown on wall messages.
journald will use this to inform users that its wall messages comes from
'systemd-journald'.
---
src/shared/utmp-wtmp.c | 12
src/shared/utmp-wtmp.h |2 +-
src/shutdownd/shutdownd.c |2 +-
src/systemctl/systemctl.c |4 ++--
src/tty-ask-password-agent/tty-ask-password-agent.c |2 +-
5 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/src/shared/utmp-wtmp.c b/src/shared/utmp-wtmp.c
index 32996fa..30a0c03 100644
--- a/src/shared/utmp-wtmp.c
+++ b/src/shared/utmp-wtmp.c
@@ -347,16 +347,20 @@ static int write_to_terminal(const char *tty, const char
*message) {
return 0;
}
-int utmp_wall(const char *message, bool (*match_tty)(const char *tty)) {
+int utmp_wall(const char *message, const char *username, bool
(*match_tty)(const char *tty)) {
_cleanup_free_ char *text = NULL, *hn = NULL, *un = NULL, *tty = NULL;
char date[FORMAT_TIMESTAMP_MAX];
struct utmpx *u;
int r;
hn = gethostname_malloc();
-un = getlogname_malloc();
-if (!hn || !un)
+if (!hn)
return -ENOMEM;
+if (!username) {
+un = getlogname_malloc();
+if (!un)
+return -ENOMEM;
+}
getttyname_harder(STDIN_FILENO, tty);
@@ -364,7 +368,7 @@ int utmp_wall(const char *message, bool (*match_tty)(const
char *tty)) {
\a\r\n
Broadcast message from %s@%s%s%s (%s):\r\n\r\n
%s\r\n\r\n,
- un, hn,
+ un ?: username, hn,
tty ? on : , strempty(tty),
format_timestamp(date, sizeof(date), now(CLOCK_REALTIME)),
message) 0)
diff --git a/src/shared/utmp-wtmp.h b/src/shared/utmp-wtmp.h
index 5924023..040a16e 100644
--- a/src/shared/utmp-wtmp.h
+++ b/src/shared/utmp-wtmp.h
@@ -32,4 +32,4 @@ int utmp_put_runlevel(int runlevel, int previous);
int utmp_put_dead_process(const char *id, pid_t pid, int code, int status);
int utmp_put_init_process(const char *id, pid_t pid, pid_t sid, const char
*line);
-int utmp_wall(const char *message, bool (*match_tty)(const char *tty));
+int utmp_wall(const char *message, const char *username, bool
(*match_tty)(const char *tty));
diff --git a/src/shutdownd/shutdownd.c b/src/shutdownd/shutdownd.c
index 8d034e6..fafd9ce 100644
--- a/src/shutdownd/shutdownd.c
+++ b/src/shutdownd/shutdownd.c
@@ -143,7 +143,7 @@ static void warn_wall(usec_t n, struct sd_shutdown_command
*c) {
if (asprintf(l, %s%s%s%s!, c-wall_message, c-wall_message[0] ?
\n : ,
prefix, format_timestamp(date, sizeof(date), c-usec)) =
0)
-utmp_wall(l, NULL);
+utmp_wall(l, NULL, NULL);
else
log_error(Failed to allocate wall message);
}
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index f395265..0435d40 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -257,7 +257,7 @@ static void warn_wall(enum action a) {
}
if (*p) {
-utmp_wall(p, NULL);
+utmp_wall(p, NULL, NULL);
return;
}
}
@@ -265,7 +265,7 @@ static void warn_wall(enum action a) {
if (!table[a])
return;
-utmp_wall(table[a], NULL);
+utmp_wall(table[a], NULL, NULL);
}
static bool avoid_bus(void) {
diff --git a/src/tty-ask-password-agent/tty-ask-password-agent.c
b/src/tty-ask-password-agent/tty-ask-password-agent.c
index 7a90e65..fa4d660 100644
--- a/src/tty-ask-password-agent/tty-ask-password-agent.c
+++ b/src/tty-ask-password-agent/tty-ask-password-agent.c
@@ -538,7 +538,7 @@ static int show_passwords(void) {
free(p);
if (wall) {
-utmp_wall(wall, wall_tty_match);
+utmp_wall(wall, NULL, wall_tty_match);
free(wall);
}
}
--
1.7.10.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC][PATCH v2 2/2] journald: add support for wall forwarding
This will let journald forward logs as messages sent to all logged in users (like wall). Two options are added: * ForwardToWall (default yes) * MaxLevelWall (default emerg) 'ForwardToWall' is overridable by kernel command line option 'systemd.journald.forward_to_wall'. This is used to emulate the traditional syslogd behaviour of sending emergency messages to all logged in users. --- Makefile.am |2 ++ man/journald.conf.xml| 40 ++- src/journal/journald-gperf.gperf |2 ++ src/journal/journald-native.c|4 +++ src/journal/journald-server.c|8 + src/journal/journald-server.h|2 ++ src/journal/journald-stream.c|4 +++ src/journal/journald-syslog.c|4 +++ src/journal/journald-wall.c | 67 ++ src/journal/journald-wall.h | 26 +++ src/journal/journald.conf|2 ++ 11 files changed, 145 insertions(+), 16 deletions(-) create mode 100644 src/journal/journald-wall.c create mode 100644 src/journal/journald-wall.h diff --git a/Makefile.am b/Makefile.am index f99cef7..02a2fbf 100644 --- a/Makefile.am +++ b/Makefile.am @@ -3227,6 +3227,8 @@ libsystemd_journal_core_la_SOURCES = \ src/journal/journald-server.h \ src/journal/journald-console.c \ src/journal/journald-console.h \ + src/journal/journald-wall.c \ + src/journal/journald-wall.h \ src/journal/journald-native.c \ src/journal/journald-native.h \ src/journal/journald-rate-limit.c \ diff --git a/man/journald.conf.xml b/man/journald.conf.xml index a814ec1..239a2ec 100644 --- a/man/journald.conf.xml +++ b/man/journald.conf.xml @@ -381,24 +381,28 @@ termvarnameForwardToSyslog=/varname/term termvarnameForwardToKMsg=/varname/term termvarnameForwardToConsole=/varname/term +termvarnameForwardToWall=/varname/term listitemparaControl whether log messages received by the journal daemon shall be forwarded to a traditional syslog daemon, to the -kernel log buffer (kmsg), or to the -system console. These options take -boolean arguments. If forwarding to -syslog is enabled but no syslog daemon -is running, the respective option has -no effect. By default, only forwarding -to syslog is enabled. These settings -may be overridden at boot time with -the kernel command line options +kernel log buffer (kmsg), to the +system console, or sent as wall +messages to all logged-in users. These +options take boolean arguments. If +forwarding to syslog is enabled but no +syslog daemon is running, the +respective option has no effect. By +default, only forwarding to syslog and +wall is enabled. These settings may be +overridden at boot time with the +kernel command line options literalsystemd.journald.forward_to_syslog=/literal, - literalsystemd.journald.forward_to_kmsg=/literal + literalsystemd.journald.forward_to_kmsg=/literal, + literalsystemd.journald.forward_to_console=/literal and - literalsystemd.journald.forward_to_console=/literal. + literalsystemd.journald.forward_to_wall=/literal. When forwarding to the console, the TTY to log to can be changed with varnameTTYPath=/varname, @@ -410,12 +414,14 @@ termvarnameMaxLevelSyslog=/varname/term termvarnameMaxLevelKMsg=/varname/term termvarnameMaxLevelConsole=/varname/term +termvarnameMaxLevelWall=/varname/term listitemparaControls the maximum log level of messages that are stored -on disk, forwarded to syslog, kmsg or -the console (if
