[systemd-devel] [PATCH] allow udev to correctly handle 'change' after device has disappeared
From: Neil Brown nfbr...@suse.com
Date: Thu, 8 Nov 2012 10:39:06 +0100
Subject: [PATCH] If a 'change' event does not get handled by udev until
after the device has subsequently disappeared, udev mis-handles
it. This can happen with 'md' devices which emit a change
event and then a remove event when they are stopped. It is
normally only noticed if udev is very busy (lots of arrays
being stopped at once) or the machine is otherwise loaded
and reponding slowly.
There are two problems.
1/ udev_device_new_from_syspath() will refuse to create the device
structure if the device does not exist in /sys, and particularly if
the uevent file does not exist.
If a 'db' file does exist, that is sufficient evidence that the device
is genuine and should be created. Equally if we have just received an
event from the kernel about the device, it must be real.
This patch just disabled the test for the 'uevent' file, it doesn't
try imposing any other tests - it isn't clear that they are really
needed.
2/ udev_event_execute_rules() calls udev_device_read_db() on a 'device'
structure that is largely uninitialised and in particular does not
have the 'subsystem' set. udev_device_read_db() needs the subsystem
so it tries to read the 'subsystem' symlink out of sysfs. If the
device is already deleted, this naturally fails.
udev_event_execute_rules() knows the subsystem (as it was in the
event message) so this patch simply sets the subsystem for the device
structure to be loaded to match the subsystem of the device structure
that is handling the event.
With these two changes, deleted handling of change events will still
correctly remove any symlinks that are not needed any more.
---
src/libudev/libudev-device.c |2 --
src/udev/udev-event.c|2 ++
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/libudev/libudev-device.c b/src/libudev/libudev-device.c
index 08476e6..0ea5afe 100644
--- a/src/libudev/libudev-device.c
+++ b/src/libudev/libudev-device.c
@@ -662,8 +662,6 @@ _public_ struct udev_device
*udev_device_new_from_syspath(struct udev *udev, con
/* all devices require a uevent file */
util_strscpyl(file, sizeof(file), path, /uevent,
NULL);
-if (stat(file, statbuf) != 0)
-return NULL;
} else {
/* everything else just needs to be a directory */
if (stat(path, statbuf) != 0
|| !S_ISDIR(statbuf.st_mode)) diff --git a/src/udev/udev-event.c
b/src/udev/udev-event.c index 2b9fdf6..bc936f4 100644
--- a/src/udev/udev-event.c
+++ b/src/udev/udev-event.c
@@ -799,6 +799,8 @@ int udev_event_execute_rules(struct udev_event
*event, struct udev_rules *rules, } else {
event-dev_db =
udev_device_new_from_syspath(event-udev,
udev_device_get_syspath(dev)); if (event-dev_db != NULL) {
+ udev_device_set_subsystem(event-dev_db,
+
udev_device_get_subsystem(dev)); udev_device_read_db(event-dev_db,
NULL); udev_device_set_info_loaded(event-dev_db);
--
1.7.7
--
Robert Milasan
L3 Support Engineer
SUSE Linux (http://www.suse.com)
email: rmila...@suse.com
GPG fingerprint: B6FE F4A8 0FA3 3040 3402 6FE7 2F64 167C 1909 6D1A
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Client logging to journald without libsystemd-journal.so
I recently introduced support for libvirt logging to journald. Initially I had intended to use libsystemd-journal.so for the logging, however, in the end I made libvirt directly communicate with sendmsg(). First, I wanted to confirm two interface stability issues. - Is the client app - journald logging protocol considered to be ABI stable ? - Is the /run/systemd/journal/socket path considered to be stable ? Second, I wanted to mention why we couldn't use libsystemd-journal.so ourselves. The first problem is that there is no sd_journal_open/close API call to setup the file descriptor. The library uses a one time atomic global initialize to open its file descriptor which is then cached until exit() or execve() (it has SOCK_CLOEXEC set). The problem is that when libvirt does fork() to create client processes, one of the things it does is to iterate from 0 - sysconf(_SC_OPEN_MAX), closing every file descriptor, except those in its whitelist. Now I know there is the school of thought that says this is a bad idea, and that all code should correctly set O_CLOEXEC for all file descriptors. While a nice idea in theory, unfortunately this is not really practical for us in reality because there are too many 3rd party libraries we use which don't do this correctly. Not least because traditional UNIX APIs don't allow for atomically creating an FD with O_CLOEXEC set. So we're stuck with closing all FDs after fork() for a good long time yet. There are two things libsystemd-journal could do to help apps in this scenario. Either provide a way for apps to query the cached journal logging file descriptor, allowing them to explicitly leave it open. Alternatively provide explicit API to call to re-open the FD, which they could call after fork(). Possibly other solutions too, like requiring an explicit close/open like syslog though that has its own set of problems. The second blocker problem was figuring out a way to send log messages using only APIs declared async-signal safe. Again this is so that we can safely send log messages inbetween fork() and execve() which only permits async signal safe APIs. The sd_journal_send() API can't be used since it relies on vasprintf() which can allocate using malloc. The sd_journal_sendv() API is pretty close to what we'd want, but the way you have to format the iovec doesn't quite work. IIUC, it requires that each iovec contains a single formatted log item string KEY=VALUE. Populating data in such a way is inconvenient for libvirt. For libvirt it was easier for us to use two iovec elements for each log item, KEY= and VALUE, so that we can avoid doing the data copy implied by filling a single string with KEY=VALUE. The upshot is that we ended up filling an iovec[] ourselves, taking care of escaping '\n', and then directly sending it to journald. As long as the wire format and UNIX socket path are considered ABI stable by systemd devs, I'm fairly happy with the libvirt code as it. I just mention these issues in case you think it is desirable to add further libsystemd-journal.so APIs to make life easier for other applications doing logging in the future. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Client logging to journald without libsystemd-journal.so
On Thu, 2012-11-08 at 16:59 +0100, Daniel P. Berrange wrote: The problem is that when libvirt does fork() to create client processes, one of the things it does is to iterate from 0 - sysconf(_SC_OPEN_MAX), closing every file descriptor, except those in its whitelist. You could iterate over the fds and just set them CLOEXEC, rather than actually closing them at that point. That's what we do in GLib: http://git.gnome.org/browse/glib/tree/glib/gspawn.c?id=a9eb1907a6451cdfe68f5924b138cfbeebc4dcf1#n1164 As a general rule, your project isn't using a standard framework like APR or GLib, and is in the process of slowly growing its own Unix API damage control layer + Windows abstraction, usually worth looking at how they approach problems. Not least because traditional UNIX APIs don't allow for atomically creating an FD with O_CLOEXEC set Yeah, but it's not too hard to make portable wrappers for most cases: http://git.gnome.org/browse/glib/tree/glib/glib-unix.c?id=a9eb1907a6451cdfe68f5924b138cfbeebc4dcf1#n60 http://git.gnome.org/browse/glib/tree/gio/gsocket.c?id=a9eb1907a6451cdfe68f5924b138cfbeebc4dcf1#n521 The second blocker problem was figuring out a way to send log messages using only APIs declared async-signal safe. Again this is so that we can safely send log messages inbetween fork() and execve() which only permits async signal safe APIs. The sd_journal_send() API can't be used since it relies on vasprintf() which can allocate using malloc. The other approach is to use a pipe to write error messages back to the parent, and have it log them. That's probably what I'm going to change GLib to do. The sd_journal_sendv() API is pretty close to what we'd want, but the way you have to format the iovec doesn't quite work. IIUC, it requires that each iovec contains a single formatted log item string KEY=VALUE. Populating data in such a way is inconvenient for libvirt. For libvirt it was easier for us to use two iovec elements for each log item, KEY= and VALUE, so that we can avoid doing the data copy implied by filling a single string with KEY=VALUE. Hmm...yeah. Maybe the wire protocol could actually support this better. This does sound like something that could be improved, regardless. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] allow udev to correctly handle 'change' after device has disappeared
On Thu, 2012-11-08 at 11:13 +0100, Robert Milasan wrote:
From: Neil Brown nfbr...@suse.com
Date: Thu, 8 Nov 2012 10:39:06 +0100
Subject: [PATCH] If a 'change' event does not get handled by udev until
after the device has subsequently disappeared, udev mis-handles
it. This can happen with 'md' devices which emit a change
event and then a remove event when they are stopped. It is
normally only noticed if udev is very busy (lots of arrays
being stopped at once) or the machine is otherwise loaded
and reponding slowly.
There are two problems.
1/ udev_device_new_from_syspath() will refuse to create the device
structure if the device does not exist in /sys, and particularly if
the uevent file does not exist.
If a 'db' file does exist, that is sufficient evidence that the device
is genuine and should be created. Equally if we have just received an
event from the kernel about the device, it must be real.
This patch just disabled the test for the 'uevent' file, it doesn't
try imposing any other tests - it isn't clear that they are really
needed.
2/ udev_event_execute_rules() calls udev_device_read_db() on a 'device'
structure that is largely uninitialised and in particular does not
have the 'subsystem' set. udev_device_read_db() needs the subsystem
so it tries to read the 'subsystem' symlink out of sysfs. If the
device is already deleted, this naturally fails.
udev_event_execute_rules() knows the subsystem (as it was in the
event message) so this patch simply sets the subsystem for the device
structure to be loaded to match the subsystem of the device structure
that is handling the event.
With these two changes, deleted handling of change events will still
correctly remove any symlinks that are not needed any more.
The problem is that at the time the 'change' event is handled, the
device is already removed by the kernel, right? That way we fail to read
the database with the currently created symlinks?
The udev_device_new_from_syspath() is a public API from libudev. We
should probably not change that and not allow other tools than udev
itself, to create device structures for devices which are not around
anymore.
Any chance to check if the patch below fixes the issue you see too. It
would preserve the current libudev behavior.
Thanks,
Kay
diff --git a/src/libudev/libudev-device.c b/src/libudev/libudev-device.c
index 08476e6..b267141 100644
--- a/src/libudev/libudev-device.c
+++ b/src/libudev/libudev-device.c
@@ -246,7 +246,7 @@ static int udev_device_set_devtype(struct udev_device
*udev_device, const char *
return 0;
}
-static int udev_device_set_subsystem(struct udev_device *udev_device, const
char *subsystem)
+int udev_device_set_subsystem(struct udev_device *udev_device, const char
*subsystem)
{
free(udev_device-subsystem);
udev_device-subsystem = strdup(subsystem);
diff --git a/src/libudev/libudev-private.h b/src/libudev/libudev-private.h
index d233565..49cebc1 100644
--- a/src/libudev/libudev-private.h
+++ b/src/libudev/libudev-private.h
@@ -48,6 +48,7 @@ struct udev_list_entry *udev_get_properties_list_entry(struct
udev *udev);
/* libudev-device.c */
struct udev_device *udev_device_new(struct udev *udev);
mode_t udev_device_get_devnode_mode(struct udev_device *udev_device);
+int udev_device_set_subsystem(struct udev_device *udev_device, const char
*subsystem);
int udev_device_set_syspath(struct udev_device *udev_device, const char
*syspath);
int udev_device_set_devnode(struct udev_device *udev_device, const char
*devnode);
int udev_device_add_devlink(struct udev_device *udev_device, const char
*devlink);
diff --git a/src/udev/udev-event.c b/src/udev/udev-event.c
index 2b9fdf6..39f36f9 100644
--- a/src/udev/udev-event.c
+++ b/src/udev/udev-event.c
@@ -797,8 +797,10 @@ int udev_event_execute_rules(struct udev_event *event,
struct udev_rules *rules,
if (major(udev_device_get_devnum(dev)) != 0)
udev_node_remove(dev);
} else {
-event-dev_db = udev_device_new_from_syspath(event-udev,
udev_device_get_syspath(dev));
+event-dev_db = udev_device_new(event-udev);
if (event-dev_db != NULL) {
+udev_device_set_syspath(event-dev_db,
udev_device_get_syspath(dev));
+udev_device_set_subsystem(event-dev_db,
udev_device_get_subsystem(dev));
udev_device_read_db(event-dev_db, NULL);
udev_device_set_info_loaded(event-dev_db);
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Journal API demo application: tallow - a fail2ban replacement
On Thu, Nov 8, 2012 at 8:31 AM, William Douglas william.doug...@intel.com wrote: Kok, Auke-jan H auke-jan.h@intel.com writes: I wrote a demo application that uses the journal API to scan for SSH bruteforce logs in the journal, called tallow. Since Auke is on vacation now (and would *never* read email or work on projects on vacation ;) ) and has finally put this could out there, I want to ask about getting a general event response processor in the journal/systemd. In order to avoid 30 daemons each doing an inotify on the journal for their message of interest to pass by, I think having a simple .log-event type unit file be used by the journal would be a nice to have feature. An example of what I'm thinking of would be the following to run a processing script for each core dump: [Event] MessageID=fc2e22bc6ee647b6b90729ab34a250b1 (or SD_MESSAGE_COREDUMP) [Service] type=oneshot ExecStart=/usr/sbin/core-processor %data %pid Where Event can contain any journal field, conditions are done as normal ie ConditionFileExists and friends (including allowing ! prefixes). For the ExecStart line %data and %pid are examples of passing journal fields though I'm definitely looking for opinions on how this could best be done as it doesn't seem right to have them in the [Service] group but having some kind of ExecArguments in [Event] seems odd too. Anyway I'd like to hear people's opinions on why this feature is unneeded and what other way I should be doing this or maybe even this is a good idea and with some refinement could get merged in to systemd. Right, we already planned to have message activation in systemd. It will probably its own unit type, called .msgid, or something. The details are not entirely clear, it's just a bunch of ideas that moment. We need to sort out a few things, like what happens at startup, to prevent the 30 daemons to see all the old messages again and again and getting activated for them. How to properly wake up an already running daemon when a new message arrives. How to handle re-activation for services which exit at idle. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Journal API demo application: tallow - a fail2ban replacement
On Thu, Nov 8, 2012 at 8:54 AM, Kay Sievers k...@vrfy.org wrote: On Thu, Nov 8, 2012 at 8:31 AM, William Douglas william.doug...@intel.com wrote: Kok, Auke-jan H auke-jan.h@intel.com writes: I wrote a demo application that uses the journal API to scan for SSH bruteforce logs in the journal, called tallow. Since Auke is on vacation now (and would *never* read email or work on projects on vacation ;) ) and has finally put this could out there, I want to ask about getting a general event response processor in the journal/systemd. In order to avoid 30 daemons each doing an inotify on the journal for their message of interest to pass by, I think having a simple .log-event type unit file be used by the journal would be a nice to have feature. An example of what I'm thinking of would be the following to run a processing script for each core dump: [Event] MessageID=fc2e22bc6ee647b6b90729ab34a250b1 (or SD_MESSAGE_COREDUMP) [Service] type=oneshot ExecStart=/usr/sbin/core-processor %data %pid Where Event can contain any journal field, conditions are done as normal ie ConditionFileExists and friends (including allowing ! prefixes). For the ExecStart line %data and %pid are examples of passing journal fields though I'm definitely looking for opinions on how this could best be done as it doesn't seem right to have them in the [Service] group but having some kind of ExecArguments in [Event] seems odd too. Anyway I'd like to hear people's opinions on why this feature is unneeded and what other way I should be doing this or maybe even this is a good idea and with some refinement could get merged in to systemd. Right, we already planned to have message activation in systemd. It will probably its own unit type, called .msgid, or something. The details are not entirely clear, it's just a bunch of ideas that moment. Awesome! We need to sort out a few things, like what happens at startup, to prevent the 30 daemons to see all the old messages again and again and getting activated for them. How to properly wake up an already running daemon when a new message arrives. How to handle re-activation for services which exit at idle. Yes start up is interesting. I imagine an admin would probably want to be able to take action on messages that have happened before the journal and message activation are online. Is the BOOT_ID field useful for determining where to start processing these messages? Seems like it might be good to take an optional AfterJournal=Bool so some units could by pass on those earlier messages too. The already running daemon's I expect to have have a socket available for getting these messages, though I guess a SIGUSR# could work if there isn't need for much in the way of data transfer. For run once type processing, re-activation could work more like daemon@.service files. Each message event would just do a run with their cursor as the identifier. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Client logging to journald without libsystemd-journal.so
Sorry about the tone in the last message, it was unnecessary. There's just some history here dating from the libxml2 days... On Thu, 2012-11-08 at 17:38 +0100, Daniel P. Berrange wrote: Yeah, we've looked at borrowed code from GLib in a few cases now, notably threads and atomic ops. I've previously looked at GLib's process spawning code, but didn't notice this particular item. Originally we did have an API fairly similar to the g_spawn_async_with_pipes API, but it is proved fairly cumbersome to use, so we've put together a much more flexible API now [1]. Yeah, I've been working on a new one: https://bugzilla.gnome.org/show_bug.cgi?id=672102 Possible, though I feel it is a little nasty, not least because when when journald then uses SCM_CREDS to find out the sender identity it will be getting the wrong pid and potentially wrong uid/gid too. This is an interesting case...conceptually it's true that it's a new pid, but I think it's a lot more useful usually what *code* it's running; ordinarily, that'd be an executable. But here we're running code from the parent just before executing a new child. Pretty much any error in fork-before-exec should be fatal, right? So in the case where you're logging an error (e.g. setuid() failed, prctl() failed), the pid is going to be irrelevant anyways since the process will soon exit. The uid/gid - yes, but on the other hand, the uid associated with the message will be the one that's conceptually in control at the moment. Regardless though of the approach taken (log from parent, log from forked-before-exec'd child), it'd probably be good to include some standard structured field saying that the code is being run in a child setup. PREEXEC=1? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Client logging to journald without libsystemd-journal.so
On Thu, Nov 08, 2012 at 04:56:03PM -0500, Colin Walters wrote: Sorry about the tone in the last message, it was unnecessary. There's just some history here dating from the libxml2 days... No worries, no offence taken :-) On Thu, 2012-11-08 at 17:38 +0100, Daniel P. Berrange wrote: Yeah, we've looked at borrowed code from GLib in a few cases now, notably threads and atomic ops. I've previously looked at GLib's process spawning code, but didn't notice this particular item. Originally we did have an API fairly similar to the g_spawn_async_with_pipes API, but it is proved fairly cumbersome to use, so we've put together a much more flexible API now [1]. Yeah, I've been working on a new one: https://bugzilla.gnome.org/show_bug.cgi?id=672102 Possible, though I feel it is a little nasty, not least because when when journald then uses SCM_CREDS to find out the sender identity it will be getting the wrong pid and potentially wrong uid/gid too. This is an interesting case...conceptually it's true that it's a new pid, but I think it's a lot more useful usually what *code* it's running; ordinarily, that'd be an executable. But here we're running code from the parent just before executing a new child. Pretty much any error in fork-before-exec should be fatal, right? So in the case where you're logging an error (e.g. setuid() failed, prctl() failed), the pid is going to be irrelevant anyways since the process will soon exit. Hmm, good point. The uid/gid - yes, but on the other hand, the uid associated with the message will be the one that's conceptually in control at the moment. It is a tricky question really. If the code failed because it did not have permission to open the file, and the log contains the uid of the parent process, this could mislead the person analysing. At the same time I see your point that the uid/gid/pid should refer to the process in control which is the parent. Regardless though of the approach taken (log from parent, log from forked-before-exec'd child), it'd probably be good to include some standard structured field saying that the code is being run in a child setup. PREEXEC=1? If the log is sent from the child, you'd really want to also include the PID of the parent process, to allow the log messages to be directly correlated. A shame SCM_CREDS doesn't directly provide the parent-PID too Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Verbose output option when starting daemons manually
All, I have been using systemd for a few months now, and I must say, it is a great init system. I myself am no coder, else I would attempt to write something to do just this. One not-dealbreaking thing that I do find lacking is a verbose option for `systemctl start unit`, essentially running `journalctl -f -u unit` (and possibly for multiple dependent units as well). For most services, I feel like this would be a line or two of output just saying It worked! or It broke! but for services like netcfg@, or services that start dependencies, it could be useful to see what's getting started and how it's getting started. Again, feel free to ignore me, I don't know how feasible or practical this would be, but it seems like it would be useful. Again, sorry that I cannot put something together myself to at least show you. Thank you for your time. -- William Giokas | KaiSforza GnuPG Key: 0xE99A7F0F Fingerprint: F078 CFF2 45E8 1E72 6D5A 8653 CDF5 E7A5 E99A 7F0F pgphKEJ3jQMSs.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Verbose output option when starting daemons manually
On 11/09/2012 12:23 AM, William Giokas wrote: All, I have been using systemd for a few months now, and I must say, it is a great init system. I myself am no coder, else I would attempt to write something to do just this. One not-dealbreaking thing that I do find lacking is a verbose option for `systemctl start unit`, essentially running `journalctl -f -u unit` (and possibly for multiple dependent units as well). For most services, I feel like this would be a line or two of output just saying It worked! or It broke! but for services like netcfg@, or services that start dependencies, it could be useful to see what's getting started and how it's getting started. Again, feel free to ignore me, I don't know how feasible or practical this would be, but it seems like it would be useful. Again, sorry that I cannot put something together myself to at least show you. Thank you for your time. Not the first and probably not the last that expected that behavior and proposed this. What's lacking is the status to be shown when units are manually started/reloaded/restart/stopped there is just one slight problem implementing that which is you dont want that output when the service is started at boot time or shutdown... perhaps that could be solved by introducing specific boot-start and shutdown-stop switches which would only be used to start unit or shut down units at boot-up/shutdown JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Verbose output option when starting daemons manually
On Fri, Nov 09, 2012 at 12:45:22AM +, Jóhann B. Guðmundsson wrote: Not the first and probably not the last that expected that behavior and proposed this. What's lacking is the status to be shown when units are manually started/reloaded/restart/stopped there is just one slight problem implementing that which is you dont want that output when the service is started at boot time or shutdown... perhaps that could be solved by introducing specific boot-start and shutdown-stop switches which would only be used to start unit or shut down units at boot-up/shutdown JBG Yes, this is something I thought of, and if it is simply a flag when invoking systemctl (such as `systemctl --verbose start unit`), then it would not introduce anything to the boot/poweroff output. -- William Giokas | KaiSforza GnuPG Key: 0xE99A7F0F Fingerprint: F078 CFF2 45E8 1E72 6D5A 8653 CDF5 E7A5 E99A 7F0F pgppgVGI8j556.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Verbose output option when starting daemons manually
On Fri, Nov 09, 2012 at 12:45:22AM +, Jóhann B. Guðmundsson wrote: What's lacking is the status to be shown when units are manually started/reloaded/restart/stopped there is just one slight problem implementing that which is you dont want that output when the service is started at boot time or shutdown... perhaps that could be solved by introducing specific boot-start and shutdown-stop switches which would only be used to start unit or shut down units at boot-up/shutdown We already have verbose indicator, used on boot-up/shutdown; it is responsible for pretty display of Starting foo... [ OK ] Started foo. So this would be if (istty() !show_status) do the journal output -- Tomasz Torcz 72-| 80-| xmpp: zdzich...@chrome.pl 72-| 80-| ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
