Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Sat, Mar 12, 2011 at 1:00 PM, Andrey Borzenkov arvidj...@mail.ru wrote: On Sat, Mar 12, 2011 at 3:14 AM, Michael Biebl mbi...@gmail.com wrote: 2011/3/12 Michael Biebl mbi...@gmail.com: 2011/3/11 Andrey Borzenkov arvidj...@mail.ru: On Fri, Mar 11, 2011 at 9:10 PM, Mike Kazantsev mk.frag...@gmail.com wrote: Btw, rsyslog.service seem to be installed into multi-user.target.wants, why not syslog.target, which seem to indicate the point where proper syslog daemon is running (according to systemd.special(7))? Actually good question (same as for portmap) - who should pull in syslog.target then? Yeah, I noticed this myself already. Quite a bit of syslog output ended up in /proc/kmsg during boot because rsyslog was started rather late (via multi-user.target). Afaics, there is not explicit symlink pulling in syslog.target, so I assume it is handled internally by systemd. Lennart? Turns out, that indeed syslog.target is not automatically started. I symlinked syslog.target into multi-user.target.wants and rsyslog.service into syslog.target.wants. Now all services with After=syslog.target are correctly started after rsyslog.service. Lennart, I think we should add those changes to systemd and rsyslog.service. The problem is not limited to syslog and applies to all special targets that serve as virtual provides Actually I think design should be reversed. The service that implements this virtual provide (syslog, network, rpcbind, smtp, ...) should pull in special target. This way you ensure - when service that provides functionality is started, corresponding virtual target is started as indication, that functionality is available - if there is no service with requested functionality, target is not available. In other words - target is not faked to be started unless functionality is available. This allows easy and logical check, whether syslog (rpcbind, network, ...) was really provided by any service - if unit is not started, it was not. To round this off, specials should also refuse manual activation. That does not apply to all specials; some of them do serve as virtual requires and pull in other services on demand. Think about bluetooth.target. Although (as Lennart replied regarding network) it should probably in reality be hci.tagret (or more generically - bt-device.target) rather than bluetooth.service, as it is exactly what we want to *pull* - specific driver for BT device. Which - in turn should pull in bluetooth.target as indication that BT is now available. Specials should really be generic statement this functionality is now available. Not means to achieve this functionality. Here is proof of concept patch. Notice that nfs fails utterly because it is started before rpc is ready without this patch (and yes, I know about socket activation for rpcbind, It is not the point here). rpcbind part is fixed by src/service.c patch. syslog part is fixed by addin Wants=syslog.target to rsyslog.service. Before [root@localhost ~]# systemctl --no-pager -p After -p Before -p Wants -p WantedBy -p Id show syslog.target rsyslog.service rpcbind.service rpcbind.target Id=syslog.target Wants= WantedBy= Before=dbus.service prefdm.service networkmanager.service acpid.service crond.service shorewall.service console-kit-daemon.service After=syslog.socket rsyslog.service Id=rsyslog.service Wants= WantedBy=multi-user.target Before=syslog.target shutdown.target After=local-fs.target basic.target Id=rpcbind.service Wants= WantedBy=rpcbind.target multi-user.target graphical.target Before=rpcbind.target shutdown.target multi-user.target graphical.target After=network.target basic.target Id=rpcbind.target Wants=rpcbind.service WantedBy= Before=netfs.service nfs-common.service After=rpcbind.service [root@localhost ~]# systemctl status syslog.target rsyslog.service rpcbind.service rpcbind.target syslog.target - Syslog Loaded: loaded (/lib/systemd/system/syslog.target) Active: inactive (dead) rsyslog.service - System Logging Service Loaded: loaded (/lib/systemd/system/rsyslog.service) Active: active (running) since Sat, 12 Mar 2011 13:59:24 +0300; 1min 14s ago Process: 797 ExecStartPre=/bin/systemctl stop systemd-kmsg-syslogd.service (code=exited, status=0/SUCCESS) Main PID: 856 (rsyslogd) CGroup: name=systemd:/system/rsyslog.service └ 856 /sbin/rsyslogd -n -c 4 rpcbind.service - LSB: Start the rpcbind daemon Loaded: loaded (/etc/rc.d/init.d/rpcbind) Active: active (running) since Sat, 12 Mar 2011 13:59:30 +0300; 1min 8s ago Process: 1474 ExecStart=/etc/rc.d/init.d/rpcbind start (code=exited, status=0/SUCCESS) Main PID: 1499 (rpcbind) CGroup: name=systemd:/system/rpcbind.service └ 1499 rpcbind -i rpcbind.target - RPC Port Mapper Loaded: loaded (/lib/systemd/system/rpcbind.target) Active: inactive (dead)
Re: [systemd-devel] systemd-logger and external syslog daemon
On Fri, Mar 11, 2011 at 8:35 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Fri, 11.03.11 19:41, Andrey Borzenkov (arvidj...@mail.ru) wrote:
Well ... the problem really is that format is supposed to be single
printable character, which does not really support bit operations and
such. What about attached (completely untested) path - which adds u
marker to anything written into /dev/kmsg?
Please don't do this. Let's not invent new interfaces here. Let's just
stick to traditional syslog which is perfectly capable of handling this,
because it allows for a full 8bit number between and which is 3 bits
priority plus 5 bits facility.
Then, let's fix the kernel side of kmsg to implicitly add in LOG_USER as
facility for everything coming in from /dev/kmsg that has has facility=0
set.
Basically what Kay suggested.
Facilities might not be the most powerful idea ever invented, but they
are useful to distuingish kernel from userspace messages, as there is
LOG_KERNEL for the former and all other facilities for the latter.
Attached patch preserves full syslog facility marker and simply emits
it back. So userspace is free to feed any facility it deems
appropriate, not only LOG_USER.
Compile tested only.
read_priority shamelessly borrowed from systemd :)
From: Andrey Borzenkov arvidj...@gmail.com
Subject: [PATCH] support full syslog facility+priority in printk
Add support for parsing full syslog facility+priority marker.
This allows early boot userspace to inject log messages with
correct facility so that these can be later processed by syslog
according to real source, and not misinterpreted as originated in kernel.
---
kernel/printk.c | 106 +--
1 files changed, 79 insertions(+), 27 deletions(-)
diff --git a/kernel/printk.c b/kernel/printk.c
index 3623152..7534158 100644
--- a/kernel/printk.c
+++ b/kernel/printk.c
@@ -515,6 +515,54 @@ static void _call_console_drivers(unsigned start,
}
/*
+ * Parse full syslog prefix and extract priority. Returns length of prefix
+ * or 0 if prefix is invalid
+ */
+static int read_priority(const char *buf, int *priority) {
+ const char *p = buf;
+ int a = 0, b = 0, c = 0;
+ int r, len;
+
+ if (*p++ != '')
+ return 0;
+
+ if ((*p == 'd' || *p == 'c') p[1] == '') {
+ r = *p;
+ len = 3;
+ goto out;
+ }
+
+ if (*p = '0' *p = '9')
+ c = *p++ - '0';
+ else
+ return 0;
+
+ if (*p = '0' *p = '9') {
+ b = c;
+ c = *p++ - '0';
+ } else
+ return 0;
+
+ if (*p = '0' *p = '9') {
+ a = b;
+ b = c;
+ c = *p++ - '0';
+ } else
+ return 0;
+
+ if (*p++ != '')
+ return 0;
+
+ r = '0' + ((100*a + 10*b + c) 7);
+ len = p - buf;
+
+out:
+ if (priority)
+ *priority = r;
+ return len;
+}
+
+/*
* Call the console drivers, asking them to write out
* log_buf[start] to log_buf[end - 1].
* The console_lock must be held.
@@ -529,13 +577,12 @@ static void call_console_drivers(unsigned start, unsigned end)
cur_index = start;
start_print = start;
while (cur_index != end) {
- if (msg_level 0 ((end - cur_index) 2)
-LOG_BUF(cur_index + 0) == ''
-LOG_BUF(cur_index + 1) = '0'
-LOG_BUF(cur_index + 1) = '7'
-LOG_BUF(cur_index + 2) == '') {
- msg_level = LOG_BUF(cur_index + 1) - '0';
- cur_index += 3;
+ int plen, prio;
+
+ plen = read_priority(LOG_BUF(cur_index), prio);
+ if (plen prio != 'd' prio != 'c') {
+ msg_level = prio - '0';
+ cur_index += plen;
start_print = cur_index;
}
while (cur_index != end) {
@@ -733,6 +780,7 @@ asmlinkage int vprintk(const char *fmt, va_list args)
unsigned long flags;
int this_cpu;
char *p;
+ int plen, prio;
boot_delay_msec();
printk_delay();
@@ -777,24 +825,21 @@ asmlinkage int vprintk(const char *fmt, va_list args)
p = printk_buf;
/* Do we have a loglevel in the string? */
- if (p[0] == '') {
- unsigned char c = p[1];
- if (c p[2] == '') {
- switch (c) {
- case '0' ... '7': /* loglevel */
-current_log_level = c - '0';
- /* Fallthrough - make sure we're on a new line */
- case 'd': /* KERN_DEFAULT */
-if (!new_text_line) {
- emit_log_char('\n');
- new_text_line = 1;
-}
- /* Fallthrough - skip the loglevel */
- case 'c': /* KERN_CONT */
-p += 3;
-break;
+ if ((plen = read_priority(p, prio))) {
+ switch (prio) {
+ case '0' ... '7': /* loglevel */
+ current_log_level = prio - '0';
+ /* Fallthrough - make sure we're on a new line */
+ case 'd': /* KERN_DEFAULT */
+ if (!new_text_line) {
+emit_log_char('\n');
+new_text_line = 1;
}
+ /* Fallthrough - skip the loglevel */
+ case 'c': /* KERN_CONT */
+ break;
}
+ p += plen;
}
/*
@@ -804,10 +849,17 @@ asmlinkage int vprintk(const char *fmt, va_list args)
for ( ; *p; p++) {
if (new_text_line) {
/* Always output the token */
- emit_log_char('');
- emit_log_char(current_log_level + '0');
- emit_log_char('');
- printed_len += 3;
+ if (plen prio != 'd' prio != 'c') {
+
[systemd-devel] service status has to be reset on upgrade SysV = native
I am working on set of RPM helper scripts for system unit packaging
and migration. One thing noted - when we migrate running SysV
service to unit with the same name, systemd status becomes quite
confused. It now accounts processes started by old SysV script as
belonging to new native unit. This is wrong. New unit may be split in
a totally different wat, use completely different start/stop commands
and be completely incompatible with old SysV script. Cf.
{pts/1}% sudo rpm -Uvh RPMS/noarch/foo-1-1-mdv2011.0.noarch.rpm
Подготовка... ### [100%]
1:foo### [100%]
{pts/1}% sudo service foo start
Starting foo (via systemctl): [ ОК ]
{pts/1}% systemctl status foo.service
foo.service - LSB: foo
Loaded: loaded (/etc/rc.d/init.d/foo)
Active: active (running) since Sat, 12 Mar 2011 20:48:56
+0300; 11s ago
Process: 11641 ExecStart=/etc/rc.d/init.d/foo start
(code=exited, status=0/SUCCESS)
Main PID: 11648 (sleep)
CGroup: name=systemd:/system/foo.service
└ 11648 /bin/sleep 1
{pts/1}% sudo rpm -Fvh RPMS/noarch/*
Подготовка... ### [100%]
1:foo### [100%]
{pts/1}% systemctl status foo.service
foo.service - Foo Service
Loaded: loaded (/lib/systemd/system/foo.service)
Active: active (running) since Sat, 12 Mar 2011 20:49:31 +0300; 3s ago
Main PID: 11648 (sleep)
CGroup: name=systemd:/system/foo.service
└ 11648 /bin/sleep 1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
