[systemd-devel] How to quiet cron sessions logging with systemd-212?
After upgrading systemd 208 - 212, every single cron job creates this flood in systemd journal: juuni 09 09:20:01 xps14 crond[15112]: pam_unix(crond:session): session opened for user root by (uid=0) juuni 09 09:20:01 xps14 systemd[15113]: pam_unix(systemd-user:session): session opened for user root by (uid=0) juuni 09 09:20:01 xps14 systemd[1]: Starting user-0.slice. juuni 09 09:20:01 xps14 systemd[1]: Created slice user-0.slice. juuni 09 09:20:01 xps14 systemd[1]: Starting User Manager for UID 0... juuni 09 09:20:01 xps14 systemd[1]: Starting Session 107 of user root. juuni 09 09:20:01 xps14 systemd[1]: Started Session 107 of user root. juuni 09 09:20:02 xps14 systemd[15113]: Starting Paths. juuni 09 09:20:02 xps14 systemd[15113]: Reached target Paths. juuni 09 09:20:02 xps14 systemd[15113]: Starting Timers. juuni 09 09:20:02 xps14 systemd[15113]: Reached target Timers. juuni 09 09:20:02 xps14 systemd[15113]: Starting Sockets. juuni 09 09:20:02 xps14 systemd[15113]: Reached target Sockets. juuni 09 09:20:02 xps14 systemd[15113]: Starting Basic System. juuni 09 09:20:02 xps14 systemd[15113]: Reached target Basic System. juuni 09 09:20:02 xps14 systemd[15113]: Starting Default. juuni 09 09:20:02 xps14 systemd[15113]: Reached target Default. juuni 09 09:20:02 xps14 systemd[15113]: Startup finished in 31ms. juuni 09 09:20:02 xps14 systemd[1]: Started User Manager for UID 0. juuni 09 09:20:02 xps14 CROND[15116]: (root) CMD (test -x /usr/sbin/run-crons /usr/sbin/run-crons ) juuni 09 09:20:02 xps14 CROND[15112]: pam_unix(crond:session): session closed for user root juuni 09 09:20:02 xps14 systemd[1]: Stopping User Manager for UID 0... juuni 09 09:20:02 xps14 systemd[15113]: Stopping Default. juuni 09 09:20:02 xps14 systemd[15113]: Stopped target Default. juuni 09 09:20:02 xps14 systemd[15113]: Stopping Basic System. juuni 09 09:20:02 xps14 systemd[15113]: Stopped target Basic System. juuni 09 09:20:02 xps14 systemd[15113]: Stopping Paths. juuni 09 09:20:02 xps14 systemd[15113]: Stopped target Paths. juuni 09 09:20:02 xps14 systemd[15113]: Stopping Timers. juuni 09 09:20:02 xps14 systemd[15113]: Stopped target Timers. juuni 09 09:20:02 xps14 systemd[15113]: Stopping Sockets. juuni 09 09:20:02 xps14 systemd[15113]: Stopped target Sockets. juuni 09 09:20:02 xps14 systemd[15113]: Starting Shutdown. juuni 09 09:20:02 xps14 systemd[15113]: Reached target Shutdown. juuni 09 09:20:02 xps14 systemd[15113]: Starting Exit the Session... juuni 09 09:20:02 xps14 systemd[15113]: Received SIGRTMIN+24 from PID 15128 (kill). juuni 09 09:20:02 xps14 systemd[15114]: pam_unix(systemd-user:session): session closed for user root juuni 09 09:20:02 xps14 systemd[1]: Stopped User Manager for UID 0. juuni 09 09:20:02 xps14 systemd[1]: Stopping user-0.slice. juuni 09 09:20:02 xps14 systemd[1]: Removed slice user-0.slice. Can I quiet this down somehow? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
Hi Leonid, On Sun, Jun 08, 2014 at 12:33:44PM +, Rusty Bird wrote: Adding to Djalal's and Mantas's examples, the systemd host may also be a gateway with its firewall configured to forward only *some* packets. If systemd itself is a server (you mean journald really, yes?) systemd host = The machine that systemd runs on In the example, this machine is a gateway/router, so it's the Linux kernel (not systemd itself or any service) that receives packets from other machines in your network and forwards them towards their destination. how can I protect the machine with yet another target? Why there is no way to tell systemd directly to start listening only after network.target is up? On a related note, what do you do about things like sshd.socket (or crap like cups.socket) which are not ordered against anything network-related? network-pre.target is intended to block the initial configuration of the network interfaces (your Ethernet card, your WiFi radio) so that it doesn't matter what software component is listening for, or trying to send, packets: The machine remains cut off from all* network links until the firewall initialization succeeds. * Except, if you bring up a network interface during early boot, e.g. using the kernel parameter ip= or an initramfs. In that case, it's your own responsibility to bring it down before systemd takes over. If you care about leaks. Rusty signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-network-wait-online symlinks to systemd-networkd
Hi Dave, On Sun, Jun 8, 2014 at 3:37 PM, Dave Reisner d...@falconindy.com wrote: Commit 2dcf7ec6ec added the following to Makefile.am: +GENERAL_ALIASES += \ + $(systemunitdir)/systemd-networkd.service $(pkgsysconfdir)/system/multi-user.target.wants/systemd-networkd.service \ + $(systemunitdir)/systemd-networkd.service $(pkgsysconfdir)/system/network-online.target.wants/systemd-networkd-wait-online.service Which, of course, results in systemd-networkd-wait-online being a symlink to systemd-networkd. This doesn't seem correct at all. Shouldn't it link to systemd-networkd-wait-online.service? Indeed, that's a copy-paste error. Feel free to fix up, or I'll do it when I get home tonight. On a related topic, could we please stop shipping hardcoded symlinks in /etc in favor of documented reccomendations for downstream packagers? I believe the aim here is to make ./autogen.sh c make sudo make install give the recommended installation. I suppose one alternative would be to ship some preset instead (and hook into that from make install) which should be simpler to drop from the package? -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
I think there's also another problem – logind starts the user manager instance for cronjobs while it shouldn't do so for batch stuff. Probably a PAM configuration issue. -- Mantas Mikulėnas graw...@gmail.com On Jun 9, 2014 9:34 AM, Leho Kraav l...@kraav.com wrote: After upgrading systemd 208 - 212, every single cron job creates this flood in systemd journal: juuni 09 09:20:01 xps14 crond[15112]: pam_unix(crond:session): session opened for user root by (uid=0) juuni 09 09:20:01 xps14 systemd[15113]: pam_unix(systemd-user:session): session opened for user root by (uid=0) juuni 09 09:20:01 xps14 systemd[1]: Starting user-0.slice. juuni 09 09:20:01 xps14 systemd[1]: Created slice user-0.slice. juuni 09 09:20:01 xps14 systemd[1]: Starting User Manager for UID 0... juuni 09 09:20:01 xps14 systemd[1]: Starting Session 107 of user root. juuni 09 09:20:01 xps14 systemd[1]: Started Session 107 of user root. juuni 09 09:20:02 xps14 systemd[15113]: Starting Paths. juuni 09 09:20:02 xps14 systemd[15113]: Reached target Paths. juuni 09 09:20:02 xps14 systemd[15113]: Starting Timers. juuni 09 09:20:02 xps14 systemd[15113]: Reached target Timers. juuni 09 09:20:02 xps14 systemd[15113]: Starting Sockets. juuni 09 09:20:02 xps14 systemd[15113]: Reached target Sockets. juuni 09 09:20:02 xps14 systemd[15113]: Starting Basic System. juuni 09 09:20:02 xps14 systemd[15113]: Reached target Basic System. juuni 09 09:20:02 xps14 systemd[15113]: Starting Default. juuni 09 09:20:02 xps14 systemd[15113]: Reached target Default. juuni 09 09:20:02 xps14 systemd[15113]: Startup finished in 31ms. juuni 09 09:20:02 xps14 systemd[1]: Started User Manager for UID 0. juuni 09 09:20:02 xps14 CROND[15116]: (root) CMD (test -x /usr/sbin/run-crons /usr/sbin/run-crons ) juuni 09 09:20:02 xps14 CROND[15112]: pam_unix(crond:session): session closed for user root juuni 09 09:20:02 xps14 systemd[1]: Stopping User Manager for UID 0... juuni 09 09:20:02 xps14 systemd[15113]: Stopping Default. juuni 09 09:20:02 xps14 systemd[15113]: Stopped target Default. juuni 09 09:20:02 xps14 systemd[15113]: Stopping Basic System. juuni 09 09:20:02 xps14 systemd[15113]: Stopped target Basic System. juuni 09 09:20:02 xps14 systemd[15113]: Stopping Paths. juuni 09 09:20:02 xps14 systemd[15113]: Stopped target Paths. juuni 09 09:20:02 xps14 systemd[15113]: Stopping Timers. juuni 09 09:20:02 xps14 systemd[15113]: Stopped target Timers. juuni 09 09:20:02 xps14 systemd[15113]: Stopping Sockets. juuni 09 09:20:02 xps14 systemd[15113]: Stopped target Sockets. juuni 09 09:20:02 xps14 systemd[15113]: Starting Shutdown. juuni 09 09:20:02 xps14 systemd[15113]: Reached target Shutdown. juuni 09 09:20:02 xps14 systemd[15113]: Starting Exit the Session... juuni 09 09:20:02 xps14 systemd[15113]: Received SIGRTMIN+24 from PID 15128 (kill). juuni 09 09:20:02 xps14 systemd[15114]: pam_unix(systemd-user:session): session closed for user root juuni 09 09:20:02 xps14 systemd[1]: Stopped User Manager for UID 0. juuni 09 09:20:02 xps14 systemd[1]: Stopping user-0.slice. juuni 09 09:20:02 xps14 systemd[1]: Removed slice user-0.slice. Can I quiet this down somehow? ___ 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-netword]
On 7 Jun 2014 21:57, Unknown contact+systemd...@volcanis.me wrote: Hello. It is said in the man systemd-netword-wait-online.service: systemd-networkd-wait-online is a one-shot system service that waits for the network to be configured. By default, it will wait for all links it is aware of and which are managed by systemd-networkd.service(8) to be fully configured or failed, and for at least one link to gain a carrier. What exactly mean configured or failed, in this context ? If i have two interface managed by systemd-networkd, one which is up and fully configured and one another that is not (like, an ethernet interface with no cable plugged in), does that mean this other one is failed ? In which state is he ? It would be in the 'configuring' state. I.e. it is waiting for the cable to be plugged, so it is not yet ready. I think (maybe wrongly) this should be precised somewhere, because I searched for fail in the associated man pages, and found nothing. Indeed, this should be documented. Cheers, Tom ___ 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-213: regression with zram
Alexander E. Patrakov patra...@gmail.com schrieb: I have upgraded systemd from 212 to 213 on two my Gentoo boxes, and see the same regression here: zram swap space does not get activated. It looks like systemd tries to activate swap before the RUN+=mkswap part of the udev rule finishes. Here are the relevant lines from my configuration files. Are they indeed supposed to work, or were working only by pure luck? I switched to zswap because of this. This also looks more appropriate for my workload. Maybe that's an option? At least if you do have a physical swap device (and in that cased I'd prefer zswap over zram). -- 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-213: regression with zram
09.06.2014 19:26, Kai Krakow wrote: Alexander E. Patrakov patra...@gmail.com schrieb: I have upgraded systemd from 212 to 213 on two my Gentoo boxes, and see the same regression here: zram swap space does not get activated. It looks like systemd tries to activate swap before the RUN+=mkswap part of the udev rule finishes. Here are the relevant lines from my configuration files. Are they indeed supposed to work, or were working only by pure luck? I switched to zswap because of this. This also looks more appropriate for my workload. Maybe that's an option? At least if you do have a physical swap device (and in that cased I'd prefer zswap over zram). Please don't persuade me to hide or tolerate bugs. Even if zswap is more appropriate, I would like to get a comment on my zram issue from systemd maintainers. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-network-wait-online symlinks to systemd-networkd
On Mon, Jun 09, 2014 at 10:12:35AM +0200, Tom Gundersen wrote: Hi Dave, On Sun, Jun 8, 2014 at 3:37 PM, Dave Reisner d...@falconindy.com wrote: Commit 2dcf7ec6ec added the following to Makefile.am: +GENERAL_ALIASES += \ + $(systemunitdir)/systemd-networkd.service $(pkgsysconfdir)/system/multi-user.target.wants/systemd-networkd.service \ + $(systemunitdir)/systemd-networkd.service $(pkgsysconfdir)/system/network-online.target.wants/systemd-networkd-wait-online.service Which, of course, results in systemd-networkd-wait-online being a symlink to systemd-networkd. This doesn't seem correct at all. Shouldn't it link to systemd-networkd-wait-online.service? Indeed, that's a copy-paste error. Feel free to fix up, or I'll do it when I get home tonight. Thanks for confirming -- pushed. On a related topic, could we please stop shipping hardcoded symlinks in /etc in favor of documented reccomendations for downstream packagers? I believe the aim here is to make ./autogen.sh c make sudo make install give the recommended installation. I suppose one alternative would be to ship some preset instead (and hook into that from make install) which should be simpler to drop from the package? Well, hooking into 'make install' doesn't really change the end result if there's no way to disable the hook. I strongly believe that the overbearing majority of systemd users are installing systemd from their distro's package manager, and not 'make install'. Since writes to /etc in this case are likely discouraged (as they override the site admin), it'd be really nice to separate out these additions somehow. d ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-213: regression with zram
09.06.2014 20:11, Kay Sievers wrote:
On Mon, Jun 9, 2014 at 4:02 PM, Alexander E. Patrakov
patra...@gmail.com wrote:
09.06.2014 19:26, Kai Krakow wrote:
Alexander E. Patrakov patra...@gmail.com schrieb:
I have upgraded systemd from 212 to 213 on two my Gentoo boxes, and see
the same regression here: zram swap space does not get activated. It
looks like systemd tries to activate swap before the RUN+=mkswap part of
the udev rule finishes.
Here are the relevant lines from my configuration files. Are they indeed
supposed to work, or were working only by pure luck?
I switched to zswap because of this. This also looks more appropriate for
my
workload. Maybe that's an option? At least if you do have a physical swap
device (and in that cased I'd prefer zswap over zram).
Please don't persuade me to hide or tolerate bugs. Even if zswap is more
appropriate, I would like to get a comment on my zram issue from systemd
maintainers.
I don't know of anybody working on systemd, using this
horrible-to-configure facility.
I have no idea how stuff should work, but it *might* need some
ENV{SYSTEMD_READY}=0 fiddling.
Let's decompose the question then. Maybe you know how at least one of
the steps should work.
1. Is it correct that swap units created from /etc/fstab have
dependencies on the devices mentioned in the first column? What kind of
dependencies?
2. At what point in time (just after getting the uevent, after setting
sysfs attributes, after running the RUN programs) is the dependency on
the device node considered satisfied?
Module parameters to configure devices, sysfs attributes to
re-configure pre-created dead devices, ...; given the fact, that it
is relatively recent technology, such terribly outdated and
have-always-been-broken concepts should never have been merged into
the kernel.
A valid observation, but still - the semantics need to be documented
(even if the document says undefined) in systemd.device(5) or
elsewhere WRT dependencies and ordering.
--
Alexander E. Patrakov
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-213: regression with zram
On Mon, Jun 9, 2014 at 4:31 PM, Alexander E. Patrakov
patra...@gmail.com wrote:
09.06.2014 20:11, Kay Sievers wrote:
On Mon, Jun 9, 2014 at 4:02 PM, Alexander E. Patrakov
patra...@gmail.com wrote:
09.06.2014 19:26, Kai Krakow wrote:
Alexander E. Patrakov patra...@gmail.com schrieb:
I have upgraded systemd from 212 to 213 on two my Gentoo boxes, and see
the same regression here: zram swap space does not get activated. It
looks like systemd tries to activate swap before the RUN+=mkswap part
of
the udev rule finishes.
Here are the relevant lines from my configuration files. Are they
indeed
supposed to work, or were working only by pure luck?
I switched to zswap because of this. This also looks more appropriate
for
my
workload. Maybe that's an option? At least if you do have a physical
swap
device (and in that cased I'd prefer zswap over zram).
Please don't persuade me to hide or tolerate bugs. Even if zswap is more
appropriate, I would like to get a comment on my zram issue from systemd
maintainers.
I don't know of anybody working on systemd, using this
horrible-to-configure facility.
I have no idea how stuff should work, but it *might* need some
ENV{SYSTEMD_READY}=0 fiddling.
Let's decompose the question then. Maybe you know how at least one of the
steps should work.
1. Is it correct that swap units created from /etc/fstab have dependencies
on the devices mentioned in the first column? What kind of dependencies?
2. At what point in time (just after getting the uevent, after setting sysfs
attributes, after running the RUN programs) is the dependency on the device
node considered satisfied?
Just guessing around after looking at the rules you pasted, the devices
seem to be created unconditionally, and only later, after manual
configuration of the same devices be useful to the system. There is no
way for systemd to find that out, so systemd's dependencies on
configuration + devices + original uevents will unlikely work as
expected.
Module parameters to configure devices, sysfs attributes to
re-configure pre-created dead devices, ...; given the fact, that it
is relatively recent technology, such terribly outdated and
have-always-been-broken concepts should never have been merged into
the kernel.
A valid observation, but still - the semantics need to be documented (even
if the document says undefined) in systemd.device(5) or elsewhere WRT
dependencies and ordering.
It looks like the same model as device-mapper, MD, loop; systemd has
no native idea about them and when to bring up devices. Original
device events are suppressed with SYSTEMD_READY=0, and new events
later re-triggered when the devices are usable for systemd to pick
them up.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] no fsck at boot
'Twas brillig, and Reindl Harald at 08/06/14 13:59 did gyre and gimble: touch /forcefsck leads in deprecated warnings but in fact at least on Fedora 19 *you need it* because the fsck don't happen otherwise for sure, the last reboot of the machine below complaind too so why don't it happen at boot? Via what mechanism did you trigger the fsck at boot (other than /forcefsck)? e.g. did you pass fsck.mode=force on the kernel command line (as the deprecated warning suggests)? Did this not trigger things correctly? Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On Mon, Jun 09, 2014 at 10:48:31AM +0300, Leho Kraav wrote: Date: Mon, 09 Jun 2014 10:48:31 +0300 From: Leho Kraav l...@kraav.com To: Reindl Harald h.rei...@thelounge.net, systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] How to quiet cron sessions logging with systemd-212? User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 On 09.06.2014 10:43, Reindl Harald wrote: nobody cares because the developers point of view is that what is interesting for them needs to be also faced by the sysadmin otherwise this would be only logged in debug-mode and bugreports not closed: https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c3 frankly if that messages would at least have a prefix or a different process than systemd one could filter them out with rsyslog.conf without supress relevant boot messages Thanks for the info. I tried googling for this relatively hard, couldn't find that bug. Language on that bug is probably counterproductive, but other than that, some reasonably sensible way should exist to simply stop logging crap, not relying on just output filtering. What you see are authpriv-level logs, so it would be a really bad idea to suppress them, regardless of their source. Currently, journald doesn't provide any means of log processing, so your only choice is to filter logs when viewing them using journalctl command line or grep/awk; you can not control what is logged when and where. If you want log processing (multiple log directories, advanced filtering, etc.), use syslog-ng or rsyslog. For example, one can setup a special logfile for systemd-related messages with a given syslog facility (authpriv, daemon, etc.). HTH, -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpERrsRV4Zx0.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks
On Mon, Jun 09, 2014 at 07:57:29AM +, Rusty Bird wrote: Date: Mon, 09 Jun 2014 07:57:29 + From: Rusty Bird rustyb...@openmailbox.org To: systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] [PATCH] Add a network-pre.target to avoid firewall leaks Hi Leonid, On Sun, Jun 08, 2014 at 12:33:44PM +, Rusty Bird wrote: Adding to Djalal's and Mantas's examples, the systemd host may also be a gateway with its firewall configured to forward only *some* packets. If systemd itself is a server (you mean journald really, yes?) systemd host = The machine that systemd runs on In the example, this machine is a gateway/router, so it's the Linux kernel (not systemd itself or any service) that receives packets from other machines in your network and forwards them towards their destination. how can I protect the machine with yet another target? Why there is no way to tell systemd directly to start listening only after network.target is up? On a related note, what do you do about things like sshd.socket (or crap like cups.socket) which are not ordered against anything network-related? network-pre.target is intended to block the initial configuration of the network interfaces (your Ethernet card, your WiFi radio) so that it doesn't matter what software component is listening for, or trying to send, packets: The machine remains cut off from all* network links until the firewall initialization succeeds. * Except, if you bring up a network interface during early boot, e.g. using the kernel parameter ip= or an initramfs. In that case, it's your own responsibility to bring it down before systemd takes over. If you care about leaks. Cool. I see your point now. Thanks, Leonid. -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpM1WBQnbBym.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-network-wait-online symlinks to systemd-networkd
'Twas brillig, and Dave Reisner at 09/06/14 15:08 did gyre and gimble: On a related topic, could we please stop shipping hardcoded symlinks in /etc in favor of documented reccomendations for downstream packagers? I believe the aim here is to make ./autogen.sh c make sudo make install give the recommended installation. I suppose one alternative would be to ship some preset instead (and hook into that from make install) which should be simpler to drop from the package? Well, hooking into 'make install' doesn't really change the end result if there's no way to disable the hook. I strongly believe that the overbearing majority of systemd users are installing systemd from their distro's package manager, and not 'make install'. Since writes to /etc in this case are likely discouraged (as they override the site admin), it'd be really nice to separate out these additions somehow. I don't necessarily disagree with the above comment but in terms of raw numbers, how many systemd packagers are there vs. how many users wanting to run it from their own build from source? If there are more of the latter then the fact that it works OOTB for them, while pushing a little bit of overhead onto the packagers seems the correct behaviour... If, however, there are more packagers, than catering to them seems more correct. Kinda hard to tell the numbers but the point I wanted to make is that you shouldn't consider the number of people installing systemd from packages as this number is sort of irrelevant if the packager is doing their job right regardless of the OOTB behaviour. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-213: regression with zram
Alexander E. Patrakov patra...@gmail.com schrieb:
09.06.2014 19:26, Kai Krakow wrote:
Alexander E. Patrakov patra...@gmail.com schrieb:
I have upgraded systemd from 212 to 213 on two my Gentoo boxes, and see
the same regression here: zram swap space does not get activated. It
looks like systemd tries to activate swap before the RUN+=mkswap part of
the udev rule finishes.
Here are the relevant lines from my configuration files. Are they indeed
supposed to work, or were working only by pure luck?
I switched to zswap because of this. This also looks more appropriate for
my workload. Maybe that's an option? At least if you do have a physical
swap device (and in that cased I'd prefer zswap over zram).
Please don't persuade me to hide or tolerate bugs. Even if zswap is more
appropriate, I would like to get a comment on my zram issue from systemd
maintainers.
I didn't mean to persuade you but zram looks a little bit broken to me with
respect to configuration. So if zswap would be an option for you, it might
be the way to go instead of trying to work around quirks that cannot be
fixed easily. Of course, it is only an option if you also use a physical
swap device.
I had most success with putting zram statically into the kernel and put the
num_devices parameter into the kernel cmdline. But still you need to
mkswap these unprepared devices first - and that's not that easy with
systemd. I gave up on that part because it never worked out as expected and
instead went with zswap. However, that is a few months ago now and there
might be options to make it work now.
But even before systemd (with openrc), I had to mkswap first, then swapon. I
wasn't able to handle this automatically and reliably just through fstab.
The whole process of configuring the device first, then formatting the
device, and only then use it, makes it almost impossible to use it the way
systemd does things (execute on discovery).
The best way to go with systemd is probably by creating a service template
that does the above steps (configure, prepare, use) and depends on disovery
of the devices. Then enable as many service instances as you need and do not
put them into fstab. Something like:
# /etc/systemd/system/zram-swap@.service
...
[Service]
EnvironmentFile=/etc/conf.d/zram
ExecStartPre=echo -n $((1024*1024*$SIZE)) /sys/block/%I/disksize
ExecStartPre=/sbin/mkswap /dev/%I
ExecStart=swapon /dev/%I
ExecStop=swapoff /dev/%I
$ systemctl enable zram-swap@zram{0,1,2,3}.service
I'm leaving out the [Unit] block and the dependencies to be used because I
have no way to test such a setup here. So it is left as an excercise. ;-)
But I think that's the only way to go. You cannot use it in fstab because
the device is just not ready at the time when systemd parses through fstab.
--
Replies to list only preferred.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] tmpfiles: Fix journal file permissions broken by a606871
They shouldn't be executable nor world-readable. --- tmpfiles.d/systemd.conf | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/tmpfiles.d/systemd.conf b/tmpfiles.d/systemd.conf index c5910f8..d6c4da3 100644 --- a/tmpfiles.d/systemd.conf +++ b/tmpfiles.d/systemd.conf @@ -25,7 +25,9 @@ d /run/systemd/netif 0755 systemd-network systemd-network - d /run/systemd/netif/links 0755 systemd-network systemd-network - d /run/systemd/netif/leases 0755 systemd-network systemd-network - -m /var/log/journal 2755 root systemd-journal - - -Z /var/log/journal/%m 2755 root systemd-journal - - -m /run/log/journal 2755 root systemd-journal - - -Z /run/log/journal/%m 2755 root systemd-journal - - +z /var/log/journal 2755 root systemd-journal - - +z /var/log/journal/%m 2755 root systemd-journal - - +z /var/log/journal/%m/* 0640 root systemd-journal - - +z /run/log/journal 2755 root systemd-journal - - +z /run/log/journal/%m 2755 root systemd-journal - - +z /run/log/journal/%m/* 0640 root systemd-journal - - -- 2.0.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] no fsck at boot
Am 09.06.2014 17:05, schrieb Colin Guthrie: 'Twas brillig, and Reindl Harald at 08/06/14 13:59 did gyre and gimble: touch /forcefsck leads in deprecated warnings but in fact at least on Fedora 19 *you need it* because the fsck don't happen otherwise for sure, the last reboot of the machine below complaind too so why don't it happen at boot? Via what mechanism did you trigger the fsck at boot (other than /forcefsck)? e.g. did you pass fsck.mode=force on the kernel command line (as the deprecated warning suggests)? Did this not trigger things correctly? uhm you stripped the relevant part of my message * the filesystem has reached the time for next fsck * the kernel says it's time * before systemd did happended automatically * that is why ext4 defines the fsck interval at all signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
Am 09.06.2014 17:28, schrieb Leonid Isaev: On Mon, Jun 09, 2014 at 10:48:31AM +0300, Leho Kraav wrote: Date: Mon, 09 Jun 2014 10:48:31 +0300 From: Leho Kraav l...@kraav.com To: Reindl Harald h.rei...@thelounge.net, systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] How to quiet cron sessions logging with systemd-212? User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 On 09.06.2014 10:43, Reindl Harald wrote: nobody cares because the developers point of view is that what is interesting for them needs to be also faced by the sysadmin otherwise this would be only logged in debug-mode and bugreports not closed: https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c3 frankly if that messages would at least have a prefix or a different process than systemd one could filter them out with rsyslog.conf without supress relevant boot messages Thanks for the info. I tried googling for this relatively hard, couldn't find that bug. Language on that bug is probably counterproductive, but other than that, some reasonably sensible way should exist to simply stop logging crap, not relying on just output filtering. What you see are authpriv-level logs, so it would be a really bad idea to suppress them, regardless of their source no user needs them, there are already logs which command was started for which user from crond with just 3 lines Jun 9 19:01:01 rawhide CROND[1696]: (root) CMD (run-parts /etc/cron.hourly) Jun 9 19:01:01 rawhide run-parts[1696]: (/etc/cron.hourly) starting 0anacron Jun 9 19:01:01 rawhide run-parts[1705]: (/etc/cron.hourly) finished 0anacron Jun 9 20:01:01 rawhide CROND[1735]: (root) CMD (run-parts /etc/cron.hourly) Jun 9 20:01:01 rawhide run-parts[1735]: (/etc/cron.hourly) starting 0anacron Jun 9 20:01:01 rawhide run-parts[1744]: (/etc/cron.hourly) finished 0anacron they are introduced in that floody way with recent systemd all the decades before crond did run fine, logs exactly what you need to know if /var/log/secure and /var/log/crond without writing *hundret thousands* loglines all day long on machines with a lot of cronjobs signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: Fix journal file permissions broken by a606871
On Mon, Jun 09, 2014 at 08:05:35PM +0200, Jan Alexander Steffens (heftig) wrote: They shouldn't be executable nor world-readable. Why do you think they should not be? --- tmpfiles.d/systemd.conf | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/tmpfiles.d/systemd.conf b/tmpfiles.d/systemd.conf index c5910f8..d6c4da3 100644 --- a/tmpfiles.d/systemd.conf +++ b/tmpfiles.d/systemd.conf @@ -25,7 +25,9 @@ d /run/systemd/netif 0755 systemd-network systemd-network - d /run/systemd/netif/links 0755 systemd-network systemd-network - d /run/systemd/netif/leases 0755 systemd-network systemd-network - -m /var/log/journal 2755 root systemd-journal - - -Z /var/log/journal/%m 2755 root systemd-journal - - -m /run/log/journal 2755 root systemd-journal - - -Z /run/log/journal/%m 2755 root systemd-journal - - +z /var/log/journal 2755 root systemd-journal - - +z /var/log/journal/%m 2755 root systemd-journal - - +z /var/log/journal/%m/* 0640 root systemd-journal - - +z /run/log/journal 2755 root systemd-journal - - +z /run/log/journal/%m 2755 root systemd-journal - - +z /run/log/journal/%m/* 0640 root systemd-journal - - What type of system did you test this change on? Did you try a box with no journal at all and have it create one on startup that can then be read by all users? thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: Fix journal file permissions broken by a606871
On Mon, Jun 9, 2014 at 8:30 PM, Greg KH gre...@linuxfoundation.org wrote: Why do you think they should not be? Executability is just nonsense, while world-readability goes against the systemd-journald manpage, which claims that, by default, only users in the systemd-journal system group can read journals not their own. What type of system did you test this change on? Did you try a box with no journal at all and have it create one on startup that can then be read by all users? Just my laptop. systemd-tmpfiles kept overwriting the modes of the journal files to 0755, even though they should be 0640 to match the above claim. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] no fsck at boot
10.06.2014 00:04, Reindl Harald wrote: Am 09.06.2014 17:05, schrieb Colin Guthrie: 'Twas brillig, and Reindl Harald at 08/06/14 13:59 did gyre and gimble: touch /forcefsck leads in deprecated warnings but in fact at least on Fedora 19 *you need it* because the fsck don't happen otherwise for sure, the last reboot of the machine below complaind too so why don't it happen at boot? Via what mechanism did you trigger the fsck at boot (other than /forcefsck)? e.g. did you pass fsck.mode=force on the kernel command line (as the deprecated warning suggests)? Did this not trigger things correctly? uhm you stripped the relevant part of my message * the filesystem has reached the time for next fsck * the kernel says it's time * before systemd did happended automatically * that is why ext4 defines the fsck interval at all Please paste your /etc/fstab file. If it has 0 0 as the last two fields, then, of course, systemd will not call fsck. If there are different numbers there, sure, let's debug. Also, now the entity that is supposed to check your root filesystem is dracut. Are you using it? Does the problem go away if you regenerate your initramfs? -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Soliciting feedback for golang bindings to the systemd journal C API
Hello! We've been working on golang bindings to the systemd journal interface (sd-journal.h), as well as a higher level go API which builds on the bindings. The immediate goal is to replace the use of forked calls to journalctl in a project. To that end, we've been wrapping only the subset of sd-journal.h necessary to build the go API necessary to support existing journalctl usages. The work is currently taking place in my fork of the go-systemd project: https://github.com/ironcladlou/go-systemd/compare/cgo-journal (The only test code there is a work-in-progress scratchpad I've been using for iterative development- actual tests are forthcoming once we're satisfied there won't be any more API churn.) We've observed a segfault during this simple test, but only once: http://fpaste.org/107299/14019224/ I've had no success reproducing the segfault. My first thought was a race when closing the journal while dealing with the setup or execution of sd_journal_wait, but no amount of concurrent closing or other access to the sd_journal instance has led me to the same error. Any advice for reproducing the segfault would be greatly appreciated. We're interested in getting feedback on the cgo bindings and go API. Does anybody else out there see a need for these bindings? All suggestions and contributions are very welcome. -- Dan Mace OpenShift, PaaS by Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On Mon, Jun 09, 2014 at 08:08:43PM +0200, Reindl Harald wrote:
Date: Mon, 09 Jun 2014 20:08:43 +0200
From: Reindl Harald h.rei...@thelounge.net
To: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] How to quiet cron sessions logging with
systemd-212?
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
Thunderbird/24.5.0
Am 09.06.2014 17:28, schrieb Leonid Isaev:
On Mon, Jun 09, 2014 at 10:48:31AM +0300, Leho Kraav wrote:
Date: Mon, 09 Jun 2014 10:48:31 +0300
From: Leho Kraav l...@kraav.com
To: Reindl Harald h.rei...@thelounge.net,
systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] How to quiet cron sessions logging with
systemd-212?
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101
Thunderbird/24.5.0
On 09.06.2014 10:43, Reindl Harald wrote:
nobody cares because the developers point of view is that what is
interesting for them needs to be also faced by the sysadmin
otherwise this would be only logged in debug-mode and bugreports
not closed: https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c3
frankly if that messages would at least have a prefix or a different
process than systemd one could filter them out with rsyslog.conf
without supress relevant boot messages
Thanks for the info. I tried googling for this relatively hard, couldn't
find that bug.
Language on that bug is probably counterproductive, but other than that,
some reasonably sensible way should exist to simply stop logging crap, not
relying on just output filtering.
What you see are authpriv-level logs, so it would be a really bad idea to
suppress them, regardless of their source
no user needs them, there are already logs which command was
started for which user from crond with just 3 lines
If you don't need them -- OK, but don't speak for the others. Why systemd
should be treated any differently than other programs? If it generates authpriv
messages -- they should be collected, not ignored. What about normal, i.e.
user-initiated logins -- should they be logged?
Jun 9 19:01:01 rawhide CROND[1696]: (root) CMD (run-parts /etc/cron.hourly)
Jun 9 19:01:01 rawhide run-parts[1696]: (/etc/cron.hourly) starting 0anacron
Jun 9 19:01:01 rawhide run-parts[1705]: (/etc/cron.hourly) finished 0anacron
Jun 9 20:01:01 rawhide CROND[1735]: (root) CMD (run-parts /etc/cron.hourly)
Jun 9 20:01:01 rawhide run-parts[1735]: (/etc/cron.hourly) starting 0anacron
Jun 9 20:01:01 rawhide run-parts[1744]: (/etc/cron.hourly) finished 0anacron
they are introduced in that floody way with recent systemd
all the decades before crond did run fine, logs exactly what
you need to know if /var/log/secure and /var/log/crond
without writing *hundret thousands* loglines all day long
on machines with a lot of cronjobs
But why can't you write a syslog filter which uses facility as well as program
name? So if you believe that systemd-generated messages are useless, drop them,
or store them in a volatile location like /run/log. Something like this (in
syslog-ng language):
---
destination d_systemd { file(/run/log/systemd.log); };
filter f_daemon { facility(daemon) and not level(debug) and not \
program(systemd); };
filter f_systemd { program(systemd); };
log { source(src); filter(f_systemd); destination(d_systemd); };
---
--
Leonid Isaev
GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4
C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D
pgpz5kfVKZuoL.pgp
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] no fsck at boot
10.06.2014 00:57, Reindl Harald wrote: Am 09.06.2014 20:45, schrieb Alexander E. Patrakov: 10.06.2014 00:04, Reindl Harald wrote: Am 09.06.2014 17:05, schrieb Colin Guthrie: 'Twas brillig, and Reindl Harald at 08/06/14 13:59 did gyre and gimble: touch /forcefsck leads in deprecated warnings but in fact at least on Fedora 19 *you need it* because the fsck don't happen otherwise for sure, the last reboot of the machine below complaind too so why don't it happen at boot? Via what mechanism did you trigger the fsck at boot (other than /forcefsck)? e.g. did you pass fsck.mode=force on the kernel command line (as the deprecated warning suggests)? Did this not trigger things correctly? uhm you stripped the relevant part of my message * the filesystem has reached the time for next fsck * the kernel says it's time * before systemd did happended automatically * that is why ext4 defines the fsck interval at all Please paste your /etc/fstab file. If it has 0 0 as the last two fields, then, of course, systemd will not call fsck. If there are different numbers there, sure, let's debug. Also, now the entity that is supposed to check your root filesystem is dracut. Are you using it? Does the problem go away if you regenerate your initramfs? i know how to deal with fstab and column 6 is not zero as well as the initramfs is regenrated all the time because kernel updates which are *the reason* for reboots on servers at all what disturbs me is they warning about touch /forcefsck while it's currently the *only* option to trigger a recommended fsck at boot on a remote-server (and no add kernel params for that in the grub-config and remove them after is not a sane way for sysadmins maintaining 10,20,30 remote servers) UUID=209aeed4-95bd-4eb0-bdfa-fb346b603ce9 /boot ext4 defaults 0 1 UUID=22f62744-8fd7-4090-aff8-b35ef38b4b74 / ext4 defaults,commit=5,inode_readahead_blks=128,noatime,nodiratime,noquota 0 1 UUID=0b95905b-02c5-444b-af9e-7615cabebb38 /mnt/data ext4 defaults,commit=5,inode_readahead_blks=128,noatime,nodiratime,noquota,nosuid 0 2 OK. Let's try eliminating some more reasons why fsck can be skipped. 1. The root filesystem is mounted read-write at boot [but note that this doesn't explain failures to check other filesystems] 2. The generator did not run for some unknown reason. 3. Some other error that got hopefully logged. Could you please attach the output of: ls -lR /run/systemd/generator journalctl -b Also, could you please try replacing some non-critical UUID=... lines (e.g. for /boot) in your fstab by direct device references of the form /dev/disk/by-uuid/209aeed4-95bd-4eb0-bdfa-fb346b603ce9 or even /dev/mdX, just to see if that's UUID who triggers the bug for you? To avoid getting an inaccessible server if that misfires, you can also append nofail to the options for /boot. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] no fsck at boot
Am 09.06.2014 21:26, schrieb Alexander E. Patrakov: 10.06.2014 00:57, Reindl Harald wrote: Am 09.06.2014 20:45, schrieb Alexander E. Patrakov: 10.06.2014 00:04, Reindl Harald wrote: Am 09.06.2014 17:05, schrieb Colin Guthrie: 'Twas brillig, and Reindl Harald at 08/06/14 13:59 did gyre and gimble: touch /forcefsck leads in deprecated warnings but in fact at least on Fedora 19 *you need it* because the fsck don't happen otherwise for sure, the last reboot of the machine below complaind too so why don't it happen at boot? Via what mechanism did you trigger the fsck at boot (other than /forcefsck)? e.g. did you pass fsck.mode=force on the kernel command line (as the deprecated warning suggests)? Did this not trigger things correctly? uhm you stripped the relevant part of my message * the filesystem has reached the time for next fsck * the kernel says it's time * before systemd did happended automatically * that is why ext4 defines the fsck interval at all Please paste your /etc/fstab file. If it has 0 0 as the last two fields, then, of course, systemd will not call fsck. If there are different numbers there, sure, let's debug. Also, now the entity that is supposed to check your root filesystem is dracut. Are you using it? Does the problem go away if you regenerate your initramfs? i know how to deal with fstab and column 6 is not zero as well as the initramfs is regenrated all the time because kernel updates which are *the reason* for reboots on servers at all what disturbs me is they warning about touch /forcefsck while it's currently the *only* option to trigger a recommended fsck at boot on a remote-server (and no add kernel params for that in the grub-config and remove them after is not a sane way for sysadmins maintaining 10,20,30 remote servers) UUID=209aeed4-95bd-4eb0-bdfa-fb346b603ce9 /boot ext4 defaults 0 1 UUID=22f62744-8fd7-4090-aff8-b35ef38b4b74 / ext4 defaults,commit=5,inode_readahead_blks=128,noatime,nodiratime,noquota 0 1 UUID=0b95905b-02c5-444b-af9e-7615cabebb38 /mnt/data ext4 defaults,commit=5,inode_readahead_blks=128,noatime,nodiratime,noquota,nosuid 0 2 OK. Let's try eliminating some more reasons why fsck can be skipped. 1. The root filesystem is mounted read-write at boot [but note that this doesn't explain failures to check other filesystems] 2. The generator did not run for some unknown reason. 3. Some other error that got hopefully logged. Could you please attach the output of: ls -lR /run/systemd/generator journalctl -b Also, could you please try replacing some non-critical UUID=... lines (e.g. for /boot) in your fstab by direct device references of the form /dev/disk/by-uuid/209aeed4-95bd-4eb0-bdfa-fb346b603ce9 or even /dev/mdX, just to see if that's UUID who triggers the bug for you? To avoid getting an inaccessible server if that misfires, you can also append nofail to the options for /boot systemd even pretends it does the fsck, i have nothing more to say on that topic except remove the deprecation warning and output the volume-label at least additionally to the UUID [root@localhost:~]$ journalctl -b | grep File System Jun 08 14:51:15 localhost systemd[1]: Starting Local File Systems. Jun 08 14:51:15 localhost systemd[1]: Reached target Local File Systems. Jun 08 14:51:16 localhost systemd[1]: Starting Initrd Root File System. Jun 08 14:51:16 localhost systemd[1]: Reached target Initrd Root File System. Jun 08 14:51:16 localhost systemd[1]: Starting Initrd File Systems. Jun 08 14:51:16 localhost systemd[1]: Reached target Initrd File Systems. Jun 08 14:51:19 localhost systemd[1]: Started File System Check on Root Device. Jun 08 14:51:19 localhost systemd[1]: Starting Remount Root and Kernel File Systems... Jun 08 14:51:19 localhost systemd[1]: Started Remount Root and Kernel File Systems. Jun 08 14:51:19 localhost systemd[1]: Starting Local File Systems (Pre). Jun 08 14:51:19 localhost systemd[1]: Reached target Local File Systems (Pre). Jun 08 14:51:20 localhost systemd[1]: Starting File System Check on /dev/disk/by-uuid/209aeed4-95bd-4eb0-bdfa-fb346b603ce9... Jun 08 14:51:20 localhost systemd[1]: Started File System Check on /dev/disk/by-uuid/209aeed4-95bd-4eb0-bdfa-fb346b603ce9. Jun 08 14:51:20 localhost systemd[1]: Starting File System Check on /dev/disk/by-uuid/0b95905b-02c5-444b-af9e-7615cabebb38... Jun 08 14:51:21 localhost systemd[1]: Started File System Check on /dev/disk/by-uuid/0b95905b-02c5-444b-af9e-7615cabebb38. Jun 08 14:51:21 localhost systemd[1]: Starting Local File Systems. Jun 08 14:51:21 localhost systemd[1]: Reached target Local File Systems. [root@localhost:~]$ journalctl -b | grep e2fsck Jun 08 14:51:19 localhost kernel: EXT4-fs (md127): warning: checktime reached, running e2fsck is recommended Jun 08 14:51:20 localhost kernel: EXT4-fs (md126): warning: checktime reached, running e2fsck is recommended Jun 08 14:51:21 localhost kernel: EXT4-fs (md125): warning:
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
Am 09.06.2014 21:07, schrieb Leonid Isaev: On Mon, Jun 09, 2014 at 08:08:43PM +0200, Reindl Harald wrote: all the decades before crond did run fine, logs exactly what you need to know if /var/log/secure and /var/log/crond without writing *hundret thousands* loglines all day long on machines with a lot of cronjobs If you don't need them -- OK, but don't speak for the others. Why systemd should be treated any differently than other programs? because Lennart to ospeaks for others the way he closed that bugreport? why can't there be at least a config option to disable creating them at all? because other programs *never ever* procude *that lot* of loglines all day long - look at the simple calculation in the bugreport on our production infrastrcuture these messages would be *a lot* more than all other logs summarized *and* they are spitted to /var/log/messages to make things worst But why can't you write a syslog filter which uses facility as well as program name? So if you believe that systemd-generated messages are useless, drop them because you *can not* distinguish between *that* user messages and system message sbecause they have systemd as program name common, the PID changes and you don't want to drop *system messages* from systemd if they would contain a unique string / prefix to distinguish from cronjobs triggered messages i would have written a rsyslog filter as for a lot of other noise long ago however - the *large amount* of that messages even if you drop them consumes useless ressources on virtualization clusters and blow up the systemd-journal signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On Mon, Jun 09, 2014 at 09:19:20PM +0200, Reindl Harald wrote: [...] on our production infrastrcuture these messages would be *a lot* more than all other logs summarized *and* they are spitted to /var/log/messages to make things worst But why can't you write a syslog filter which uses facility as well as program name? So if you believe that systemd-generated messages are useless, drop them because you *can not* distinguish between *that* user messages and system message sbecause they have systemd as program name common, the PID changes and you don't want to drop *system messages* from systemd So, systemd starts certain things on _any_ user login: be it a real user, or a daemon. However, if you already have logs from the daemon (cron) or a login program (login), why keep systemd-generated messages? I'd put them in a separate file... if they would contain a unique string / prefix to distinguish Do you have something concrete in mind? from cronjobs triggered messages i would have written a rsyslog filter as for a lot of other noise long ago however - the *large amount* of that messages even if you drop them consumes useless ressources on virtualization clusters and blow up the systemd-journal If resources are an issue, don't use the journal. In my experience, it consumes ~4x space compared to syslog (on a firewall machine, after 2 months uptime)... -- Leonid Isaev GPG fingerprints: DA92 034D B4A8 EC51 7EA6 20DF 9291 EE8A 043C B8C4 C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D pgpkW9mGeOXcS.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
Am 09.06.2014 22:32, schrieb Leonid Isaev: On Mon, Jun 09, 2014 at 09:19:20PM +0200, Reindl Harald wrote: [...] on our production infrastrcuture these messages would be *a lot* more than all other logs summarized *and* they are spitted to /var/log/messages to make things worst But why can't you write a syslog filter which uses facility as well as program name? So if you believe that systemd-generated messages are useless, drop them because you *can not* distinguish between *that* user messages and system message sbecause they have systemd as program name common, the PID changes and you don't want to drop *system messages* from systemd So, systemd starts certain things on _any_ user login: be it a real user, or a daemon. However * why do it need to do that much stuff * why can't it keep that stuff long-running you have already /usr/lib/systemd/systemd --user and (sd-pam) processes for every userid ever started a cronjob running all the time - so why flood the logs every minute again? if you already have logs from the daemon (cron) or a login program (login), why keep systemd-generated messages? I'd put them in a separate file... if i can put them in a seperate file i can filter them out if they would contain a unique string / prefix to distinguish Do you have something concrete in mind? systemd-user: or whatever that would also make clear the we *do not* start all sorts of targets, the flooding log in misleading anyways that below is just *not true* from the users point of view Jun 9 22:36:07 rawhide systemd[1]: Starting User Manager for UID 0... Jun 9 22:36:07 rawhide systemd[607]: Starting Paths. Jun 9 22:36:07 rawhide systemd[607]: Reached target Paths. Jun 9 22:36:07 rawhide systemd[607]: Starting Timers. Jun 9 22:36:07 rawhide systemd[607]: Reached target Timers. Jun 9 22:36:07 rawhide systemd[607]: Starting Sockets. Jun 9 22:36:07 rawhide systemd[607]: Reached target Sockets. Jun 9 22:36:07 rawhide systemd[607]: Starting Basic System. Jun 9 22:36:07 rawhide systemd[607]: Reached target Basic System. Jun 9 22:36:07 rawhide systemd[607]: Starting Default. Jun 9 22:36:07 rawhide systemd[607]: Reached target Default. Jun 9 22:36:07 rawhide systemd[607]: Startup finished in 9ms. Jun 9 22:36:07 rawhide systemd[1]: Started User Manager for UID 0. from cronjobs triggered messages i would have written a rsyslog filter as for a lot of other noise long ago however - the *large amount* of that messages even if you drop them consumes useless ressources on virtualization clusters and blow up the systemd-journal If resources are an issue, don't use the journal. In my experience, it consumes ~4x space compared to syslog (on a firewall machine, after 2 months uptime)... i don't use the journal, the configuration of journald is like below the log-flood makes things even worser because it leads to early rotation and purges systemctl status whatever.service informations by purging the memory-journal if it comes to ressource usage: all that dropped messages (if you could drop/filter them) are producing data and overhead in general, only because you manage to not see things that don't mean they produce no overhead [root@rawhide ~]# cat /etc/systemd/journald.conf [Journal] Storage=volatile Compress=no RateLimitInterval=10s RateLimitBurst=500 RuntimeMaxUse=15M signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] no fsck at boot
'Twas brillig, and Reindl Harald at 09/06/14 19:57 did gyre and gimble: what disturbs me is they warning about touch /forcefsck while it's currently the *only* option to trigger a recommended fsck at boot on a remote-server (and no add kernel params for that in the grub-config and remove them after is not a sane way for sysadmins maintaining 10,20,30 remote servers) As has been mentioned numerous times, these warnings are there because if you need to use something to force an fsck (this current problem not withstanding) then modifying the suspect filesystem in question is a really bad idea! The warnings are in place to cover this use case and to discourage it as a first port of call without giving it proper thought. In this particular case where you are actually (presumably) quite happy with the filesystem, then using this trigger mechanism is perfectly fine and you can ignore the warnings happy in the knowledge that you know better. Of course there are ways (extensions or patches I forget which) to tell grub to do something one-time only (IIRC there is a system called rebootin which does this). Such an approach would achieve the same simplicity you crave with the touch approach but via the kernel command line trigger instead. This would mean you wouldn't have to manually edit and later restore your grub command line each time and, assuming /boot is separate from /, you could trigger all this while / is mounted ro. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Soliciting feedback for golang bindings to the systemd journal C API
The CoreOS crew has already done most of this work by writing a native Go implementation (rather than wrapping the C APIs). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: Fix journal file permissions broken by a606871
On Mon, Jun 09, 2014 at 08:37:18PM +0200, Jan Alexander Steffens wrote: On Mon, Jun 9, 2014 at 8:30 PM, Greg KH gre...@linuxfoundation.org wrote: Why do you think they should not be? Executability is just nonsense, while world-readability goes against the systemd-journald manpage, which claims that, by default, only users in the systemd-journal system group can read journals not their own. What type of system did you test this change on? Did you try a box with no journal at all and have it create one on startup that can then be read by all users? Just my laptop. systemd-tmpfiles kept overwriting the modes of the journal files to 0755, even though they should be 0640 to match the above claim. Ok, let me test this on a system that previously was requring this change later tonight and let you know if it still all works properly for me... thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v5 12/14] autoconf: xen: enable explicit preference option for xenstored preference
On Wed, Jun 04, 2014 at 07:52:56PM -0700, Cameron Norman wrote:
On Wed, Jun 4, 2014 at 5:31 PM, Luis R. Rodriguez mcg...@suse.com wrote:
On Sun, Jun 01, 2014 at 08:15:47AM +0200, Lennart Poettering wrote:
On Fri, 30.05.14 01:29, Luis R. Rodriguez (mcg...@suse.com) wrote:
I'm cc'ing a few security folks as I'd appreciate review on the ideas
here,
in particular that of a launcher idea on system to replace alternatives
on the
ExecStart= line of a systemd service unit file, alternative ideas are of
course welcomed. I'm also Cc'ing systemd-devel as this subject was
reviewed
a little while ago with nothing concrete being recommended but instead a
few
options being now archived as possibilities. I'm looking for a bit wider
review of the approaches and recomendations.
Some general background for non xen folks: old xen requires the launch of
a daemon which implements supports of the xenstore, which is the database
that xen uses for information about guests / dom0. There are two
supported
daemons, xenstored (C version) and oxenstored (Ocaml version) but they
do the
same thing. Right now old init lets you override which one you pick
through
an environment variable on /etc/{sysconfig,default}/xencommons, the
script
will use the appropriate on there. Systemd doesn't let you use variables
on
the ExecStart line of a service unit file so alternatives are required.
The reason I'm being very careful here this could set a precedent and at
least for the launcher idea it'd require the usage of getenv() and
execve(),
and secure alternatives for these (secure_getenv(), execve_nosecurity())
have either been merged or suggested before for Linux. The systemd
discussion
is only specific to Linux but if we have a launcher we could consider it
for
other supported OSes. All that said I'd like proper review of the
security
implications of *all* strategies but obviously in particular the launcher
idea. I want to tread carefuly before setting precedents.
You can also just invoke a shell script from ExecStart=. I mean, we try
to deemphesize them in the boot process, but there's nothing wrong with
using shell, if you need to parse shell configuraiton fragments and just
want to execute on ot another program...
I tried this and it didn't work given that systemd expects sd_notify()
to be called from the parent process, in this case the shell script.
Just use exec before the daemon command. I am pretty certain it can be
just like this:
ExecStart=/bin/sh -c exec $XENSTORED
xenstored then has the same PID as the sh process, and $NOTIFY_SOCKET
works just fine.
Actually this does work on a test unit I just built. I'll proceed with
this approach since I haven't heard back from others and I think
this is the best approach now.
Luis
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tmpfiles: Fix journal file permissions broken by a606871
On Mon, Jun 09, 2014 at 08:05:35PM +0200, Jan Alexander Steffens (heftig) wrote: They shouldn't be executable nor world-readable. --- tmpfiles.d/systemd.conf | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/tmpfiles.d/systemd.conf b/tmpfiles.d/systemd.conf index c5910f8..d6c4da3 100644 --- a/tmpfiles.d/systemd.conf +++ b/tmpfiles.d/systemd.conf @@ -25,7 +25,9 @@ d /run/systemd/netif 0755 systemd-network systemd-network - d /run/systemd/netif/links 0755 systemd-network systemd-network - d /run/systemd/netif/leases 0755 systemd-network systemd-network - -m /var/log/journal 2755 root systemd-journal - - -Z /var/log/journal/%m 2755 root systemd-journal - - -m /run/log/journal 2755 root systemd-journal - - -Z /run/log/journal/%m 2755 root systemd-journal - - +z /var/log/journal 2755 root systemd-journal - - +z /var/log/journal/%m 2755 root systemd-journal - - +z /var/log/journal/%m/* 0640 root systemd-journal - - +z /run/log/journal 2755 root systemd-journal - - +z /run/log/journal/%m 2755 root systemd-journal - - +z /run/log/journal/%m/* 0640 root systemd-journal - - I've tested this out and it seems to work for me, no objection from me for this to be applied, thanks. greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?
On Mon, Jun 9, 2014 at 4:42 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 09.06.2014 22:32, schrieb Leonid Isaev: On Mon, Jun 09, 2014 at 09:19:20PM +0200, Reindl Harald wrote: [...] on our production infrastrcuture these messages would be *a lot* more than all other logs summarized *and* they are spitted to /var/log/messages to make things worst But why can't you write a syslog filter which uses facility as well as program name? So if you believe that systemd-generated messages are useless, drop them because you *can not* distinguish between *that* user messages and system message sbecause they have systemd as program name common, the PID changes and you don't want to drop *system messages* from systemd So, systemd starts certain things on _any_ user login: be it a real user, or a daemon. However * why do it need to do that much stuff * why can't it keep that stuff long-running you have already /usr/lib/systemd/systemd --user and (sd-pam) processes for every userid ever started a cronjob running all the time - so why flood the logs every minute again? Now that you mention it, you can cut down on a lot of the log spam by enabling linger for root and other users which run cron jobs. loginctl enable-linger user This will keep a systemd user instance running so that a new one is not spawned every time cron wakes up. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] HandleLidSwitch v204
I need to run Fedora 19 (systemd 204) for a particular piece of software on a laptop, and I'm having trouble disabling suspend when I shut the screen. My default target is multi-user.target, and the laptop is not connected to any external monitors. I made the following change to /etc/systemd/logind.conf and rebooted: HandleLidSwitch=ignore However, the systemd is still suspending. What else do I need to change to disable this behavior? Thanks, Justin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
