Re: [systemd-devel] [PATCH] systemctl: introduce --now for enable, disable and mask

[Cam Hutchison]

jsyna...@redhat.com writes:

diff --git a/man/systemctl.xml b/man/systemctl.xml
index 4dbdfe1..951ce4d 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -456,6 +456,17 @@
   /varlistentry
 
   varlistentry
+termoption--now/option/term
+
+listitem
+  paraWhen used with commandenable/command, the units
+  will also be started. When used with commanddisable/command
+  or commandmask/command, the units will additionally be

Just a small nit: s/additionally/also/. You used the word also in the
previous sentence, and when I see different language being used in
different places in documentation, I wonder whether there is something
different about the cases.

+  stopped./para

Could you elaborate on ordering here? Is the unit first enabled then started,
and first stopped then disabled? Some other order? Indeterminate?

+/listitem
+  /varlistentry
+
+  varlistentry
 termoption--root=/option/term
 
 listitem
@@ -921,11 +932,12 @@ kobject-uevent 1 systemd-udevd-kernel.socket 
systemd-udevd.service
 the changes are taken into account immediately. Note that
 this does emphasisnot/emphasis have the effect of also
 starting any of the units being enabled. If this
-is desired, a separate commandstart/command command must
-be invoked for the unit. Also note that in case of instance
-enablement, symlinks named the same as instances are created in
-the install location, however they all point to the same
-template unit file./para
+is desired, either option--now/option should be used
+together with this command, or a separate commandstart/command

Similar to my nit above - this uses separate, the disable paragraph uses
additional. (I realise this is pre-existing language, but while you're here
it can be fixed).

+command must be invoked for the unit. Also note that in case of
+instance enablement, symlinks named the same as instances
+are created in the install location, however they all point to the
+same template unit file./para
 
 paraThis command will print the actions executed. This
 output may be suppressed by passing option--quiet/option.
@@ -980,9 +992,10 @@ kobject-uevent 1 systemd-udevd-kernel.socket 
systemd-udevd.service
 commandenable/command. This call implicitly reloads the
 systemd daemon configuration after completing the disabling
 of the units. Note that this command does not implicitly
-stop the units that are being disabled. If this is desired,
-an additional commandstop/command command should be
-executed afterwards./para
+stop the units that are being disabled. If this is desired, either
+option--now/option should be used together with this command, 
or
+an additional commandstop/command command should be executed

additional used here. See previous comment.

+afterwards./para
 
 paraThis command will print the actions executed. This
 output may be suppressed by passing option--quiet/option.
@@ -1128,7 +1141,9 @@ kobject-uevent 1 systemd-udevd-kernel.socket 
systemd-udevd.service
 activation of the unit, including enablement and manual
 activation. Use this option with care. This honors the
 option--runtime/option option to only mask temporarily
-until the next reboot of the system./para
+until the next reboot of the system. The option--now/option
+can be additionally used to ensure that the units are also
+stopped./para

Drop the word additionally since there is an also later in the sentence
(and options by their nature are additional).

   /listitem
 /varlistentry
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Both volatile and persistent journald logs

[Cam Hutchison]

Lennart Poettering lenn...@poettering.net writes:

On Thu, 23.04.15 06:58, Cam Hutchison (c...@xdna.net) wrote:

 The specifics of my logging that is temporarily volatile is captured in
 these rsyslog configs:
 
 local1.*/tmp/log/dnsmasq.log
 local4.*/tmp/log/ldap.log
 if $syslogfacility-text == 'kern' and $msg contains 'firewall:' then
 /tmp/log/firewall.log

journald does not allow seperate log files or filter expressions,
please use rsyslog or another syslog daemon for things like this.

I've got no real use for directing logs to files via these filter
expressions in a journald world. I'm happy with the filtering being
done on read-out instead of ingestion. These only go to separate
files because that's how syslog works.

But if I want to discriminate in order to direct logs to a volatile vs
persistent store then I would need some sort of pre-filtering and I can
see how that does not fit with journald's design.

However, even if I continue to use rsyslog with these filters, I don't
believe I will achieve what I want because the logs will first pass
through journald which will happily write them to its journal on
/var/log, creating the SSD write activity I'm trying to avoid.

For now I guess I'll just reduce the amount of logging. I should be able
to use NFLOG and ulogd2 to capture the firewall logs outside of
syslog/journald.

Thanks for your quick response.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Both volatile and persistent journald logs

[Cam Hutchison]

I am migrating to systemd/journald (via an upgrade from Debian wheezy to
jessie) and I've come across a problem migrating that is peculiar to my
setup.

I currently have /var/log on an SSD. I also have some noisy logs. In
attempt to not have rsyslog write continuously to the SSD, I have set up
some syslog facilities and special filters to log to /run/log files
instead of /var/log for those noise logs. I have an hourly cron job
that runs logrotate on the /run/log files and appends the rotated log
(the .1 file) to the persistent logs in /var/log.

I would like to be able to do something similar with journald.

The specifics of my logging that is temporarily volatile is captured in
these rsyslog configs:

local1.*/tmp/log/dnsmasq.log
local4.*/tmp/log/ldap.log
if $syslogfacility-text == 'kern' and $msg contains 'firewall:' then 
/tmp/log/firewall.log

I am aware that on an unclean shutdown these logs get lost. I am ok with
that. They are mostly useful for realtime debugging and not historical
analysis. In the rare event of an unclean shutdown, I accept this loss
(I've not yet had such a shutdown).

Is there a way to configure journald to do something similar?

Is there some other mechanism that can address excessive log writing to
an SSD?

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel