Re: [systemd-devel] systemd-logger and external syslog daemon
> -Original Message- > From: Lennart Poettering [mailto:lenn...@poettering.net] > Sent: Thursday, March 17, 2011 12:31 AM > To: Michael Biebl > Cc: Andrey Borzenkov; systemd-devel@lists.freedesktop.org; Rainer > Gerhards > Subject: Re: [systemd-devel] systemd-logger and external syslog daemon > > On Wed, 16.03.11 07:18, Michael Biebl (mbi...@gmail.com) wrote: > > > > > 2011/3/16 Lennart Poettering : > > > On Sat, 12.03.11 16:31, Andrey Borzenkov (arvidj...@mail.ru) wrote: > > > > > > > >> > > >> Attached patch preserves full syslog facility marker and simply > emits > > >> it back. So userspace is free to feed any facility it deems > > >> appropriate, not only LOG_USER. > > > > > > This is a good approach. Kay has independently prepped a patch for > this > > > now and it is already on its way into the kernel. It is hence very > > > likely that pretty soon there's no reason anymore to strip the > facility > > > from the log messages before echoing them into /proc/kmsg. > > > > > > As soon as that patch is in the standard kernel I'll fix systemd to > no > > > longer strip the facility. Kay will do the same for udev. And > Harald > > > hopefully for Dracut too. And then all messages should contain the > same > > > amount of information regardless which way the took to the syslog > > > daemon: directly via the /dev/log socket, or indirectly via the > kmsg queue. > > > > What happens if you run udev/dracut/systemd on a kernel without this > patch? > > You mean a new udev/dracut/systemd on an old kernel? The messages they > print would look a bit weird if they are used together with log msg > timestamping the way the kernel does it, since the kernel doesn't > recognize the prefix. (See Kay's post about this). But besides these > cosmetic issues nothing should really go wrong. > > (I wonder if we can find a nice way to detect whether the kernel is new > enough for this, so that we could strip the facility automatically for > older ones. Explcitily checking for kernel versions at runtime is evil > though... I can't think of a good way though...) Wouldn't it work to check if there is a "" right at the start of the message? I think that it is actual user data would be extremely improbable, so this should be a good enough indication. That way, we could pull the PRI even without the kernel patch (but, granted, it is kind of an interface change...). Rainer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "Inactive/dead" services that are enabled are indistinguishable from unused or oneshot services
On Thu, 17 Mar 2011 09:52:21 +0300 Andrey Borzenkov wrote: > On Thu, Feb 24, 2011 at 11:55 AM, Mike Kazantsev wrote: > > Something like "systemctl --enabled" would certainly be much more > > useful for such cases than the current "systemctl --all", yet > > there will still be a lot of "oneshot" stuff, which are supposed to be > > dead, so a separate state for "!oneshot && enabled && exited" services > > like "stopped" (in place of "inactive") and maybe a view like "systemctl > > --stopped" would be of a great help from my sysadmin's perspective. > > > > I understand that there's already a looong TODO, but maybe it's possible > > to cram such systemctl view option(s) somewhere in that list? > > > > I was vaguely thinking about adding generic selection option to > replace current ad-hoc ones, something like > > --state=enabled,!exited > > or even allowing generic filtering on specific property, like > > --query Type=socket,dbus > > The latter is probably the way to go as it can be used to implement > any custom query. And add better output format control of course :) It > just needs some proper, but not too complicated, syntax. > > Is it good enough for TODO? I think it'd be great, although syntax could be problematic indeed if "and" and "or" logic would be implemented. Simpliest (from my pov) thing that comes to mind is perl / bash / libpcap / etc syntax like "rule1 && ( rule2 || rule3 ) && ! rule4", disallowing multiple values for the sake of unity (i.e. "Type=socket || Type=dbus" instead of "Type=socket,dbus"). -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Thu, 17 Mar 2011 01:04:35 +0100 Lennart Poettering wrote: > On Wed, 16.03.11 14:39, Andrey Borzenkov (arvidj...@mail.ru) wrote: > > > > Or is rsyslog expected to provide a symlink in syslog.target.wants? > > > > > > > This is really orthogonal. As Lennart commented, it may be sensible to > > do both. But this symlink does not ensure syslog is actually started > > before syslog.target. > > Well, actually there is. > > If DefaultDependencies= is "yes" (which it is by default) for target > units then they'll automatically gain an After= for all untis they have > Wants= or Requires= on. > > (We currently do not document what DefaultDependencies= actually means > for the specific unit types. We probably should...) > Can this behavior be relied upon or this might change in future releases? It's just that this magic bit makes After= line in lots of units I've seen (and wrote) redundant, so can it be dropped and skipped in any new units or it's better to be explicit in this case? -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v20
On Wed, 16 Mar 2011 23:24:22 +0100 Lennart Poettering wrote: > On Wed, 16.03.11 16:14, Daniel Drake (d...@laptop.org) wrote: > > Any chance of a build for Fedora rawhide? Latest there is v18. > > F15 should have an up-to-date systemd, and it should migrate > automatically from there. It won't. "koji list-tagged dist-f16 systemd" shows there were already two fc16 builds tagged, so Koji inheritance will not do anything here. Michal ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Thu, Mar 17, 2011 at 3:04 AM, Lennart Poettering wrote: > On Wed, 16.03.11 14:39, Andrey Borzenkov (arvidj...@mail.ru) wrote: > >> > Or is rsyslog expected to provide a symlink in syslog.target.wants? >> > >> >> This is really orthogonal. As Lennart commented, it may be sensible to >> do both. But this symlink does not ensure syslog is actually started >> before syslog.target. > > Well, actually there is. > > If DefaultDependencies= is "yes" (which it is by default) for target > units then they'll automatically gain an After= for all untis they have > Wants= or Requires= on. > yet another undocumented magic ... > (We currently do not document what DefaultDependencies= actually means > for the specific unit types. We probably should...) > Yes, please. BTW I remember there were other magic directories besides xxx.wanted, should not they be documented as well? Are they also handled by "systemctl enable/disable"? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Thu, Mar 17, 2011 at 11:06 AM, Mike Kazantsev wrote: > On Thu, 17 Mar 2011 01:04:35 +0100 > Lennart Poettering wrote: >> If DefaultDependencies= is "yes" (which it is by default) for target >> units then they'll automatically gain an After= for all untis they have >> Wants= or Requires= on. > Can this behavior be relied upon or this might change in future > releases? > > It's just that this magic bit makes After= line in lots of units I've > seen (and wrote) redundant, so can it be dropped and skipped in any > new units or it's better to be explicit in this case? > Do you have that many target units? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Thu, 17 Mar 2011 12:41:34 +0300 Andrey Borzenkov wrote: > On Thu, Mar 17, 2011 at 11:06 AM, Mike Kazantsev wrote: > > On Thu, 17 Mar 2011 01:04:35 +0100 > > Lennart Poettering wrote: > >> If DefaultDependencies= is "yes" (which it is by default) for target > >> units then they'll automatically gain an After= for all untis they have > >> Wants= or Requires= on. > > > Can this behavior be relied upon or this might change in future > > releases? > > > > It's just that this magic bit makes After= line in lots of units I've > > seen (and wrote) redundant, so can it be dropped and skipped in any > > new units or it's better to be explicit in this case? > > > > Do you have that many target units? Ah, I missed the "target units" part, but even then "Requires=network.target + After=network.target" is a common enough pattern for services that need network to be up at startup and After= line is present in each one of them: /lib/systemd/system/noip.service:Requires=network.target /lib/systemd/system/dnscache.service:Requires=network.target /lib/systemd/system/tinydns.service:Requires=network.target /lib/systemd/system/remote-fs.target:Requires=network.target /lib/systemd/system/ziproxy.service:Requires=network.target /lib/systemd/system/ejabberd.service:Requires=network.target /lib/systemd/system/dhcpd.service:Requires=network.target ... -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Thu, Mar 17, 2011 at 1:59 PM, Mike Kazantsev wrote: > On Thu, 17 Mar 2011 12:41:34 +0300 > Andrey Borzenkov wrote: > >> On Thu, Mar 17, 2011 at 11:06 AM, Mike Kazantsev >> wrote: >> > On Thu, 17 Mar 2011 01:04:35 +0100 >> > Lennart Poettering wrote: >> >> If DefaultDependencies= is "yes" (which it is by default) for target >> >> units then they'll automatically gain an After= for all untis they have >> >> Wants= or Requires= on. >> >> > Can this behavior be relied upon or this might change in future >> > releases? >> > >> > It's just that this magic bit makes After= line in lots of units I've >> > seen (and wrote) redundant, so can it be dropped and skipped in any >> > new units or it's better to be explicit in this case? >> > >> >> Do you have that many target units? > > Ah, I missed the "target units" part, but even then > "Requires=network.target + After=network.target" is a common > enough pattern for services that need network to be up at startup and > After= line is present in each one of them: > Dependencies are added to target for units that it pulls. Not other way round. > /lib/systemd/system/noip.service:Requires=network.target > /lib/systemd/system/dnscache.service:Requires=network.target > /lib/systemd/system/tinydns.service:Requires=network.target > /lib/systemd/system/remote-fs.target:Requires=network.target > /lib/systemd/system/ziproxy.service:Requires=network.target > /lib/systemd/system/ejabberd.service:Requires=network.target > /lib/systemd/system/dhcpd.service:Requires=network.target I tentatively think that these should be either After or Requisite. Do you really want to start network every time one of those services gets started (assuming there were reasons to have network stopped at this moment)? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Dependency loop due to network filesystem and quotacheck; suboptimal loop resolution.
On Thu, Mar 17, 2011 at 4:43 AM, Lennart Poettering
wrote:
> On Thu, 10.03.11 00:42, Andrey Borzenkov (arvidj...@gmail.com) wrote:
>> It is not. Suggested patch attached.
>
>> From: Andrey Borzenkov
>> Subject: [PATCH] mount: do not add dependency on network filesystem to
>> quotacheck
>>
>> This creates loop:
>>
>> fs -> quotacheck -> basic -> network -> fs
>>
>> It does not look like quota was enabled for them in /etc/init.d/netfs
>> anyway. If quota is required, it probably should be implemented as
>> per mount point unit.
>
[...]
> Anywaym uf you rework this patch to check for the usrquota/grpquota
> options I'd merge it promptly
But it does not solve the problem of usrquota being set on a _netfs
filesystem. So either this has to be skipped completely or additional
unit provided.
> (or you can even merge it yourself, if
> Tollef grants you git access by then ;-)). Even better would be if you
> add a WANTS dep too, so that we can remove the service from being pulled
> in by default sysinit.target.
>
You mean Wants from mount unit to quotacheck unit?
>> Fixes https://qa.mandriva.com/show_bug.cgi?id=62746
>>
>> ---
>> src/mount.c | 14 --
>> 1 files changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/mount.c b/src/mount.c
>> index 0078010..61bbf50 100644
>> --- a/src/mount.c
>> +++ b/src/mount.c
>> @@ -412,9 +412,19 @@ static int mount_add_default_dependencies(Mount *m) {
>>
>> if (m->meta.manager->running_as == MANAGER_SYSTEM &&
>> !path_equal(m->where, "/")) {
>> + MountParameters *p;
>>
>> - if ((r = unit_add_dependency_by_name(UNIT(m), UNIT_BEFORE,
>> SPECIAL_QUOTACHECK_SERVICE, NULL, true)) < 0)
>> - return r;
>> + if (m->from_fragment)
>> + p = &m->parameters_fragment;
>> + else if (m->from_etc_fstab)
>> + p = &m->parameters_etc_fstab;
>> + else
>> + p = NULL;
>> +
>> + if (!p || (!mount_test_option(p->options, "_netdev") &&
>> + !(p->fstype && fstype_is_network(p->fstype
>> + if ((r = unit_add_dependency_by_name(UNIT(m),
>> UNIT_BEFORE, SPECIAL_QUOTACHECK_SERVICE, NULL, true)) < 0)
>> + return r;
>>
>> if ((r = unit_add_two_dependencies_by_name(UNIT(m),
>> UNIT_BEFORE, UNIT_CONFLICTS, SPECIAL_UMOUNT_TARGET, NULL, true)) < 0)
>> return r;
>
>
> Lennart
>
> --
> Lennart Poettering - Red Hat, Inc.
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Thu, 17 Mar 2011 14:32:26 +0300 Andrey Borzenkov wrote: > On Thu, Mar 17, 2011 at 1:59 PM, Mike Kazantsev wrote: > > On Thu, 17 Mar 2011 12:41:34 +0300 > > Andrey Borzenkov wrote: > > > >> On Thu, Mar 17, 2011 at 11:06 AM, Mike Kazantsev > >> wrote: > >> > On Thu, 17 Mar 2011 01:04:35 +0100 > >> > Lennart Poettering wrote: > >> >> If DefaultDependencies= is "yes" (which it is by default) for target > >> >> units then they'll automatically gain an After= for all untis they have > >> >> Wants= or Requires= on. > >> > >> > Can this behavior be relied upon or this might change in future > >> > releases? > >> > > >> > It's just that this magic bit makes After= line in lots of units I've > >> > seen (and wrote) redundant, so can it be dropped and skipped in any > >> > new units or it's better to be explicit in this case? > >> > > >> > >> Do you have that many target units? > > > > Ah, I missed the "target units" part, but even then > > "Requires=network.target + After=network.target" is a common > > enough pattern for services that need network to be up at startup and > > After= line is present in each one of them: > > > > Dependencies are added to target for units that it pulls. Not other way round. > Hm, indeed, I should've read that statement much more carefully. > > /lib/systemd/system/noip.service:Requires=network.target > > /lib/systemd/system/dnscache.service:Requires=network.target > > /lib/systemd/system/tinydns.service:Requires=network.target > > /lib/systemd/system/remote-fs.target:Requires=network.target > > /lib/systemd/system/ziproxy.service:Requires=network.target > > /lib/systemd/system/ejabberd.service:Requires=network.target > > /lib/systemd/system/dhcpd.service:Requires=network.target > > I tentatively think that these should be either After or Requisite. Do > you really want to start network every time one of those services gets > started (assuming there were reasons to have network stopped at this > moment)? Since they can't function without network (usually failing if interface doesn't exists), pulling in network as a dependency seem to be sensible thing to do, no point to start dependencies manually. Disabling the network in such configuration can be done by masking network.target, either via symlink to /dev/null or systemd.blacklist_units= parameter. After+Requisite seem to be an alternative, although enabling service and it's dependencies explicitly for it not to fail looks counter-intuitive to me - services usually pull in needed deps without requiring you to enable whole pyramid of them below, constantly failing on any missing piece. -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Dependency loop due to network filesystem and quotacheck; suboptimal loop resolution.
On Thu, 17.03.11 16:50, Andrey Borzenkov (arvidj...@gmail.com) wrote: > > On Thu, Mar 17, 2011 at 4:43 AM, Lennart Poettering > wrote: > > On Thu, 10.03.11 00:42, Andrey Borzenkov (arvidj...@gmail.com) wrote: > >> It is not. Suggested patch attached. > > > >> From: Andrey Borzenkov > >> Subject: [PATCH] mount: do not add dependency on network filesystem to > >> quotacheck > >> > >> This creates loop: > >> > >> fs -> quotacheck -> basic -> network -> fs > >> > >> It does not look like quota was enabled for them in /etc/init.d/netfs > >> anyway. If quota is required, it probably should be implemented as > >> per mount point unit. > > > [...] > > Anywaym uf you rework this patch to check for the usrquota/grpquota > > options I'd merge it promptly > > But it does not solve the problem of usrquota being set on a _netfs > filesystem. So either this has to be skipped completely or additional > unit provided. Well, isn't it kind of a misconfiguration if people use "usrquota,grpquota" on a network filesystem? But I guess an explicit check for _netdev and fstype_is_network(p->fstype) can't hurt. > > Tollef grants you git access by then ;-)). Even better would be if you > > add a WANTS dep too, so that we can remove the service from being pulled > > in by default sysinit.target. > > > > You mean Wants from mount unit to quotacheck unit? Yes, from all .mount units with usrquota or grpquota to quotacheck.service. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Dependency loop due to network filesystem and quotacheck; suboptimal loop resolution.
On Thu, Mar 17, 2011 at 5:44 PM, Lennart Poettering wrote: > On Thu, 17.03.11 16:50, Andrey Borzenkov (arvidj...@gmail.com) wrote: > >> >> On Thu, Mar 17, 2011 at 4:43 AM, Lennart Poettering >> wrote: >> > On Thu, 10.03.11 00:42, Andrey Borzenkov (arvidj...@gmail.com) wrote: >> >> It is not. Suggested patch attached. >> > >> >> From: Andrey Borzenkov >> >> Subject: [PATCH] mount: do not add dependency on network filesystem to >> >> quotacheck >> >> >> >> This creates loop: >> >> >> >> fs -> quotacheck -> basic -> network -> fs >> >> >> >> It does not look like quota was enabled for them in /etc/init.d/netfs >> >> anyway. If quota is required, it probably should be implemented as >> >> per mount point unit. >> > >> [...] >> > Anywaym uf you rework this patch to check for the usrquota/grpquota >> > options I'd merge it promptly >> >> But it does not solve the problem of usrquota being set on a _netfs >> filesystem. So either this has to be skipped completely or additional >> unit provided. > > Well, isn't it kind of a misconfiguration if people use > "usrquota,grpquota" on a network filesystem? Is ext4 on iSCSI target network file system? > But I guess an explicit > check for _netdev and fstype_is_network(p->fstype) can't hurt. > >> > Tollef grants you git access by then ;-)). Even better would be if you >> > add a WANTS dep too, so that we can remove the service from being pulled >> > in by default sysinit.target. >> > >> >> You mean Wants from mount unit to quotacheck unit? > > Yes, from all .mount units with usrquota or grpquota to quotacheck.service. > > Lennart > > -- > Lennart Poettering - Red Hat, Inc. > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Dependency loop due to network filesystem and quotacheck; suboptimal loop resolution.
On Thu, Mar 17, 2011 at 03:44:46PM +0100, Lennart Poettering wrote: > On Thu, 17.03.11 16:50, Andrey Borzenkov (arvidj...@gmail.com) wrote: > > > > > On Thu, Mar 17, 2011 at 4:43 AM, Lennart Poettering > > wrote: > > > On Thu, 10.03.11 00:42, Andrey Borzenkov (arvidj...@gmail.com) wrote: > > >> It is not. Suggested patch attached. > > > > > >> From: Andrey Borzenkov > > >> Subject: [PATCH] mount: do not add dependency on network filesystem to > > >> quotacheck > > >> > > >> This creates loop: > > >> > > >> fs -> quotacheck -> basic -> network -> fs > > >> > > >> It does not look like quota was enabled for them in /etc/init.d/netfs > > >> anyway. If quota is required, it probably should be implemented as > > >> per mount point unit. > > > > > [...] > > > Anywaym uf you rework this patch to check for the usrquota/grpquota > > > options I'd merge it promptly > > > > But it does not solve the problem of usrquota being set on a _netfs > > filesystem. So either this has to be skipped completely or additional > > unit provided. > > Well, isn't it kind of a misconfiguration if people use > "usrquota,grpquota" on a network filesystem? But I guess an explicit > check for _netdev and fstype_is_network(p->fstype) can't hurt. As for "_netdev", it is quite possible for quota-supporting filesystem (like ext*) to be mounted from network device (iSCSI, AoE or other). "_netfs" seem not to be documented in mount manpage. -- Tomasz TorczThere exists no separation between gods and men: xmpp: zdzich...@chrome.pl one blends softly casual into the other. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Dependency loop due to network filesystem and quotacheck; suboptimal loop resolution.
2011/3/17 Tomasz Torcz : > As for "_netdev", it is quite possible for quota-supporting filesystem (like > ext*) > to be mounted from network device (iSCSI, AoE or other). > "_netfs" seem not to be documented in mount manpage. > Oops, my bad. It was _netdev of course. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v20
On Thu, 17.03.11 10:07, Michal Schmidt (mschm...@redhat.com) wrote: > > On Wed, 16 Mar 2011 23:24:22 +0100 Lennart Poettering wrote: > > On Wed, 16.03.11 16:14, Daniel Drake (d...@laptop.org) wrote: > > > Any chance of a build for Fedora rawhide? Latest there is v18. > > > > F15 should have an up-to-date systemd, and it should migrate > > automatically from there. > > It won't. "koji list-tagged dist-f16 systemd" shows there were already > two fc16 builds tagged, so Koji inheritance will not do anything here. Ah, sorry. Thanks for the pointer. The two builds are untagged now, f16 should now inherit again from f15. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Dependency loop due to network filesystem and quotacheck; suboptimal loop resolution.
On Thu, Mar 17, 2011 at 4:43 AM, Lennart Poettering
wrote:
> Anywaym uf you rework this patch to check for the usrquota/grpquota
> options I'd merge it promptly (or you can even merge it yourself, if
> Tollef grants you git access by then ;-)). Even better would be if you
> add a WANTS dep too, so that we can remove the service from being pulled
> in by default sysinit.target.
Like attached patch?
From: Andrey Borzenkov
Subject: [PATCH] mount: pull in quota services from local mountpoints with usr/grpquota options
---
Makefile.am |4
src/mount.c | 19 +--
src/special.h |1 +
units/quotacheck.service.in |3 ---
units/quotaon.service |3 ---
5 files changed, 18 insertions(+), 12 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 8d23430..69759fe 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1332,10 +1332,6 @@ install-data-hook:
$(LN_S) $(systemunitdir)/getty@.service getty@tty4.service && \
$(LN_S) $(systemunitdir)/getty@.service getty@tty5.service && \
$(LN_S) $(systemunitdir)/getty@.service getty@tty6.service )
- ( cd $(DESTDIR)$(pkgsysconfdir)/system/local-fs.target.wants && \
- rm -f quotaon.service quotacheck.service && \
- $(LN_S) $(systemunitdir)/quotacheck.service quotacheck.service && \
- $(LN_S) $(systemunitdir)/quotaon.service quotaon.service )
( cd $(DESTDIR)$(pkgsysconfdir)/system/multi-user.target.wants && \
rm -f remote-fs.target && \
$(LN_S) $(systemunitdir)/remote-fs.target remote-fs.target )
diff --git a/src/mount.c b/src/mount.c
index 39525b6..9f4c72b 100644
--- a/src/mount.c
+++ b/src/mount.c
@@ -413,9 +413,24 @@ static int mount_add_default_dependencies(Mount *m) {
if (m->meta.manager->running_as == MANAGER_SYSTEM &&
!path_equal(m->where, "/")) {
+MountParameters *p;
-if ((r = unit_add_dependency_by_name(UNIT(m), UNIT_BEFORE, SPECIAL_QUOTACHECK_SERVICE, NULL, true)) < 0)
-return r;
+if (m->from_fragment)
+p = &m->parameters_fragment;
+else if (m->from_etc_fstab)
+p = &m->parameters_etc_fstab;
+else
+p = NULL;
+
+if (!p ||
+(!mount_test_option(p->options, "_netdev") &&
+!(p->fstype && fstype_is_network(p->fstype)) &&
+(mount_test_option(p->options, "usrquota") || mount_test_option(p->options, "grpquota"
+if ((r = unit_add_dependency_by_name(UNIT(m), UNIT_BEFORE, SPECIAL_QUOTACHECK_SERVICE, NULL, true)) < 0 ||
+(r = unit_add_dependency_by_name(UNIT(m), UNIT_BEFORE, SPECIAL_QUOTAON_SERVICE, NULL, true)) < 0 ||
+(r = unit_add_dependency_by_name(UNIT(m), UNIT_WANTS, SPECIAL_QUOTACHECK_SERVICE, NULL, true)) < 0 ||
+(r = unit_add_dependency_by_name(UNIT(m), UNIT_BEFORE, SPECIAL_QUOTAON_SERVICE, NULL, true)) < 0)
+return r;
if ((r = unit_add_two_dependencies_by_name(UNIT(m), UNIT_BEFORE, UNIT_CONFLICTS, SPECIAL_UMOUNT_TARGET, NULL, true)) < 0)
return r;
diff --git a/src/special.h b/src/special.h
index 2f2d9e7..b60e1e7 100644
--- a/src/special.h
+++ b/src/special.h
@@ -54,6 +54,7 @@
#define SPECIAL_SYSINIT_TARGET "sysinit.target"
#define SPECIAL_FSCK_SERVICE "fsck@.service"
#define SPECIAL_QUOTACHECK_SERVICE "quotacheck.service"
+#define SPECIAL_QUOTAON_SERVICE "quotaon.service"
#define SPECIAL_RESCUE_TARGET "rescue.target"
#define SPECIAL_EXIT_TARGET "exit.target"
#define SPECIAL_EMERGENCY_TARGET "emergency.target"
diff --git a/units/quotacheck.service.in b/units/quotacheck.service.in
index d46a335..ed1ddc5 100644
--- a/units/quotacheck.service.in
+++ b/units/quotacheck.service.in
@@ -18,6 +18,3 @@ RemainAfterExit=yes
ExecStart=@rootlibexecdir@/systemd-quotacheck
StandardOutput=syslog
TimeoutSec=0
-
-[Install]
-WantedBy=local-fs.target
diff --git a/units/quotaon.service b/units/quotaon.service
index ddb5128..2c7b36b 100644
--- a/units/quotaon.service
+++ b/units/quotaon.service
@@ -17,6 +17,3 @@ Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/quotaon -aug
StandardOutput=syslog
-
-[Install]
-WantedBy=local-fs.target
--
tg: (a49408e..) u/local-fs-quota (depends on: origin/master)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Dependency loop due to network filesystem and quotacheck; suboptimal loop resolution.
On Thu, 17.03.11 17:49, Andrey Borzenkov (arvidj...@gmail.com) wrote: > > On Thu, Mar 17, 2011 at 5:44 PM, Lennart Poettering > wrote: > > On Thu, 17.03.11 16:50, Andrey Borzenkov (arvidj...@gmail.com) wrote: > > > >> > >> On Thu, Mar 17, 2011 at 4:43 AM, Lennart Poettering > >> wrote: > >> > On Thu, 10.03.11 00:42, Andrey Borzenkov (arvidj...@gmail.com) wrote: > >> >> It is not. Suggested patch attached. > >> > > >> >> From: Andrey Borzenkov > >> >> Subject: [PATCH] mount: do not add dependency on network filesystem to > >> >> quotacheck > >> >> > >> >> This creates loop: > >> >> > >> >> fs -> quotacheck -> basic -> network -> fs > >> >> > >> >> It does not look like quota was enabled for them in /etc/init.d/netfs > >> >> anyway. If quota is required, it probably should be implemented as > >> >> per mount point unit. > >> > > >> [...] > >> > Anywaym uf you rework this patch to check for the usrquota/grpquota > >> > options I'd merge it promptly > >> > >> But it does not solve the problem of usrquota being set on a _netfs > >> filesystem. So either this has to be skipped completely or additional > >> unit provided. > > > > Well, isn't it kind of a misconfiguration if people use > > "usrquota,grpquota" on a network filesystem? > > Is ext4 on iSCSI target network file system? True. We will probably not be able to support quota for those, since we cannot block apps to access the fs while quotacheck is running. But I guess even if we cannot support it really this shouldn't be an excuse for a dep loop. Hence yepp, a patch that adds deps to quotacheck only iff a) a device has grpquota or usrquota set AND b) is not a network fs would be very good. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Dependency loop due to network filesystem and quotacheck; suboptimal loop resolution.
On Thu, 17.03.11 21:35, Andrey Borzenkov (arvidj...@gmail.com) wrote: > On Thu, Mar 17, 2011 at 4:43 AM, Lennart Poettering > wrote: > > Anywaym uf you rework this patch to check for the usrquota/grpquota > > options I'd merge it promptly (or you can even merge it yourself, if > > Tollef grants you git access by then ;-)). Even better would be if you > > add a WANTS dep too, so that we can remove the service from being pulled > > in by default sysinit.target. > > Like attached patch? Almost: > + > +if (!p || > +(!mount_test_option(p->options, "_netdev") && > +!(p->fstype && fstype_is_network(p->fstype)) && > +(mount_test_option(p->options, "usrquota") || > mount_test_option(p->options, "grpquota" > +if ((r = unit_add_dependency_by_name(UNIT(m), > UNIT_BEFORE, SPECIAL_QUOTACHECK_SERVICE, NULL, true)) < 0 || > +(r = unit_add_dependency_by_name(UNIT(m), > UNIT_BEFORE, SPECIAL_QUOTAON_SERVICE, NULL, true)) < 0 || > +(r = unit_add_dependency_by_name(UNIT(m), > UNIT_WANTS, SPECIAL_QUOTACHECK_SERVICE, NULL, true)) < 0 || > +(r = unit_add_dependency_by_name(UNIT(m), > UNIT_BEFORE, SPECIAL_QUOTAON_SERVICE, NULL, true)) < 0) > +return r; Please use unit_add_two_dependencies_by_name() instead here. That allows you to create the BEFORE and WANTS dep in one step. (Oh, and you are creating before quotaon.service twice, you want to replace one UNIT_BEFORE by UNIT_WANTS). But otherwise looks good. Please fix and then apply. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-logger and external syslog daemon
On Thu, 17.03.11 08:38, Rainer Gerhards (rgerha...@hq.adiscon.com) wrote: > > You mean a new udev/dracut/systemd on an old kernel? The messages they > > print would look a bit weird if they are used together with log msg > > timestamping the way the kernel does it, since the kernel doesn't > > recognize the prefix. (See Kay's post about this). But besides these > > cosmetic issues nothing should really go wrong. > > > > (I wonder if we can find a nice way to detect whether the kernel is new > > enough for this, so that we could strip the facility automatically for > > older ones. Explcitily checking for kernel versions at runtime is evil > > though... I can't think of a good way though...) > > Wouldn't it work to check if there is a "" right at the start of the > message? I think that it is actual user data would be extremely improbable, > so this should be a good enough indication. That way, we could pull the PRI > even without the kernel patch (but, granted, it is kind of an interface > change...). Hmm? The question is how we can detect whether it is safe to write messages to kmsg with PRI values with more than 3 bits. 2.6.39 and above will be able to handle that properly, even if you enable per-line printk kernel timestamping. On 2.6.38 only 3-bit-PRI values will look good if you use printk kernel timestamping. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "Inactive/dead" services that are enabled are indistinguishable from unused or oneshot services
On Thu, 17.03.11 10:20, Mike Kazantsev (mk.frag...@gmail.com) wrote: > On Thu, 17 Mar 2011 01:39:19 +0100 > Lennart Poettering wrote: > > > On Thu, 24.02.11 13:55, Mike Kazantsev (mk.frag...@gmail.com) wrote: > > > > > Something like "systemctl --enabled" would certainly be much more > > > useful for such cases than the current "systemctl --all", yet > > > there will still be a lot of "oneshot" stuff, which are supposed to be > > > dead, so a separate state for "!oneshot && enabled && exited" services > > > like "stopped" (in place of "inactive") and maybe a view like "systemctl > > > --stopped" would be of a great help from my sysadmin's perspective. > > > > Hmm, thinking about this: wouldn't it be a lot more useful for your case > > if we add an option which cuases services to enter fail if a service > > exits cleanly, but does so for no reason, i.e. without being asked to do > > that from systemd? > > > > or maybe that should even be the default for most services? After all > > only services which implement exit-on-idle would otherwise exit cleanly > > just for fun without being asked for that... > > > > I think it'd be an improvement, but that'd also give "failed" state a > bit more ambiguity, although maybe it's not such a bad thing. > > Experiencing several reboots on a machine with 50+ enabled daemons > I've noticed that some of them (mostly the ones, started via some > "laucher script" like apachectl, pg_ctl, ejabberdctl, etc) tend to > "cleanly" fail randomly on start just because GuessMainPID= mechanism > fails and systemd actually kills the service. Hmm, GuessPID= fails? Do you know why exactly? Ideas for improvements? The current logic is pretty simply: we look for all processes in the service cgroup which have PPID == 1. If there is only one of these, we assume it is the main process. In your case there hence must be more than once where this condition applies? Any recommendation would else we could check? > I understand that there's a limited number of reasons for such "clean > stop" (manual interaction, units like rsyslog.service, Conflicts=, > isolate, etc), but still it's a wrong way to approach the particular > problem. > > I've solved the problem for myself by writing a simple dbus-python > script (http://goo.gl/V6e7V). It shows exactly everything that's > enabled and not active (with "oneshot" exception), not some random > subset of this. Hmm, jupp. I agree, this is very useful. I added this to the todo list now. > Unfortunately, new rsyslog.service (and services using "systemctl stop" > directly) can affect such display, which I think shows the flawed > assumption that "enabled" in systemd means "should be active, > period" (with the exception of "oneshot" units) on my part, and I don't > know easy solution to this, short of adding another enabled-like state. Hmm, yeah. This problem is hard. But I think simply showing "enabled but not running" is already quite useful, even if a service on that list is not necessarily buggy, but just not hooked in by anything. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "Inactive/dead" services that are enabled are indistinguishable from unused or oneshot services
On Thu, 17.03.11 22:48, Lennart Poettering (lenn...@poettering.net) wrote: > > Unfortunately, new rsyslog.service (and services using "systemctl stop" > > directly) can affect such display, which I think shows the flawed > > assumption that "enabled" in systemd means "should be active, > > period" (with the exception of "oneshot" units) on my part, and I don't > > know easy solution to this, short of adding another enabled-like state. > > Hmm, yeah. This problem is hard. But I think simply showing "enabled but > not running" is already quite useful, even if a service on that list is > not necessarily buggy, but just not hooked in by anything. Thinking about this, maybe a simpler solution would be to add a switch to list all services that have been running since the boot but are not running anymore. That would be quite trivial to implement. Does that make sense to you? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "Inactive/dead" services that are enabled are indistinguishable from unused or oneshot services
On Thu, 17.03.11 09:52, Andrey Borzenkov (arvidj...@mail.ru) wrote: > > I understand that there's already a looong TODO, but maybe it's possible > > to cram such systemctl view option(s) somewhere in that list? > > > > I was vaguely thinking about adding generic selection option to > replace current ad-hoc ones, something like > > --state=enabled,!exited ! on the sell is always a bit weird. But this might be a good idea to have. > or even allowing generic filtering on specific property, like > > --query Type=socket,dbus Hmm, having this would make systemctl almost an SQL database ;-) I think we should try to figure out what exactly we need, instead of losing ourselves in inventing new matching languages. systemctl already has quite a long man page, and I'd prefer if it wouldnt become a novel. Maybe one option would be to introduce it as seperate 'systemd-query' tool or so? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "Inactive/dead" services that are enabled are indistinguishable from unused or oneshot services
On Thu, 17.03.11 12:52, Mike Kazantsev (mk.frag...@gmail.com) wrote: > > --query Type=socket,dbus > > > > The latter is probably the way to go as it can be used to implement > > any custom query. And add better output format control of course :) It > > just needs some proper, but not too complicated, syntax. > > > > Is it good enough for TODO? > > I think it'd be great, although syntax could be problematic indeed if > "and" and "or" logic would be implemented. > > Simpliest (from my pov) thing that comes to mind is perl / bash / > libpcap / etc syntax like "rule1 && ( rule2 || rule3 ) && ! rule4", > disallowing multiple values for the sake of unity (i.e. "Type=socket || > Type=dbus" instead of "Type=socket,dbus"). Hmm, I am not convinced we want to come up with our own matching syntax there. A different approach might be to just use awk here. awk has been invented for this kind of matching. So it might be nicer to just have a mode where we have an output that is easily processable by awk, and then people can do all matching with awk? awk is pretty well known and widely spoken. And I think it is pretty good with CSV style dumps, so maybe we should just support that nicely... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Thu, 17.03.11 13:06, Mike Kazantsev (mk.frag...@gmail.com) wrote: > On Thu, 17 Mar 2011 01:04:35 +0100 > Lennart Poettering wrote: > > > On Wed, 16.03.11 14:39, Andrey Borzenkov (arvidj...@mail.ru) wrote: > > > > > > Or is rsyslog expected to provide a symlink in syslog.target.wants? > > > > > > > > > > This is really orthogonal. As Lennart commented, it may be sensible to > > > do both. But this symlink does not ensure syslog is actually started > > > before syslog.target. > > > > Well, actually there is. > > > > If DefaultDependencies= is "yes" (which it is by default) for target > > units then they'll automatically gain an After= for all untis they have > > Wants= or Requires= on. > > > > (We currently do not document what DefaultDependencies= actually means > > for the specific unit types. We probably should...) > > > > Can this behavior be relied upon or this might change in future > releases? Yes. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Thu, 17.03.11 14:32, Andrey Borzenkov (arvidj...@mail.ru) wrote: > > Ah, I missed the "target units" part, but even then > > "Requires=network.target + After=network.target" is a common > > enough pattern for services that need network to be up at startup and > > After= line is present in each one of them: > > > > Dependencies are added to target for units that it pulls. Not other way round. > > > /lib/systemd/system/noip.service:Requires=network.target > > /lib/systemd/system/dnscache.service:Requires=network.target > > /lib/systemd/system/tinydns.service:Requires=network.target > > /lib/systemd/system/remote-fs.target:Requires=network.target > > /lib/systemd/system/ziproxy.service:Requires=network.target > > /lib/systemd/system/ejabberd.service:Requires=network.target > > /lib/systemd/system/dhcpd.service:Requires=network.target > > I tentatively think that these should be either After or Requisite. Do > you really want to start network every time one of those services gets > started (assuming there were reasons to have network stopped at this > moment)? Yes, I agree fully with Andrey. For two reasons: A) I think it is important to implement lose coupling, i.e. ejabber works fine without network, hence a Requires= is not really necessary. and B) Whether a service is enabled or not should be a decision of the admin he can control with "systemctl enable" and "systemctl". When you use Wants/Requires too often you bit by bit take this away from the admin, since simply enabling ejabber might also enable the network in your case, which is not necessarily what the admin wants. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Thu, 17.03.11 12:39, Andrey Borzenkov (arvidj...@mail.ru) wrote: > > (We currently do not document what DefaultDependencies= actually means > > for the specific unit types. We probably should...) > > > > Yes, please. > > BTW I remember there were other magic directories besides xxx.wanted, > should not they be documented as well? Are they also handled by > "systemctl enable/disable"? There's only .wants and .requires, nothing else. I have now added a bit of text about .requires to the man pages. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "Inactive/dead" services that are enabled are indistinguishable from unused or oneshot services
2011/3/17 Lennart Poettering : > Hmm, I am not convinced we want to come up with our own matching syntax > there. > > A different approach might be to just use awk here. awk has been > invented for this kind of matching. So it might be nicer to just have a > mode where we have an output that is easily processable by awk, and then > people can do all matching with awk? > > awk is pretty well known and widely spoken. And I think it is pretty > good with CSV style dumps, so maybe we should just support that nicely... +1 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Thu, 17.03.11 23:28, Lennart Poettering (lenn...@poettering.net) wrote: > > > (We currently do not document what DefaultDependencies= actually means > > > for the specific unit types. We probably should...) > > > > > > > Can this behavior be relied upon or this might change in future > > releases? > > Yes. With that I wanted to say that yes, you may rely on this behaviour. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] crypto: to show stars or not to show them
On Thursday 2011-03-17 00:27, Lennart Poettering wrote: >> >> Well, as I mentioned earlier, certain implementations use a >> three-star-per-character so that there is at least some feedback. How >> about using that? > >I am not sure I follow here, if we always show 3 asterisks then it >should be much easier to get an idea how long your password is. Not so much, because it is easier to lose track in counting 18 stars than it is for 6. Yeah, corner cases, let's forget about it. >What some programs do is randomly pick between 1 and 3 asterisks for >each char. That probably does make some sense, though might be quite >confusing to the user, dunno? I suppose it's the classical 1. Nature will produce a better idiot anytime. Ok so changing the amount per input character does not seem to go anywhere. >> Or, something crazy that just came to my mind is using one (or >> more) U+2501 per input character. Provided you have a proper >> font, this will produce a continuous line which is harder to >> estimate than chars having blank pixels between them. > >Well, but we cannot rely that the terminal used is unicode-capable. Note >that this prompt might be shown on serial terminals with weirdo >Windows-based software on the other side, which almost definitely cannot >to UTF-8. The only continuous line in 7 bit ascii we could draw is with >underscores, but that might be irritating, too? To use a past-time Kinder Surprise meme: “Telnet/Serial terminal program? Windows? UTF-8? But that's three things at once!” * Any user who knows what a terminal program for should be capable of grabbing PuTTY. * In fact, an uncounted number of Linux distributions have already deactivated the knobs in /etc/profile* that were used to detect whether an ssh client is classic 8-bit or UTF-8. * I think it is much more irritating that the Solaris console swaps ^H with Backspace. * When you are on serial, you don't really care what the visual representation for an entered password is, as long as it gets you in, the machine back up, and the boss happy. Meanwhile, I have two new suggestions. \e[37;47m* Upside: * US-ASCII compliant * Provides a continuous graphic representation on VT100-capable terminals * Color-suppressing terminals (like Windows 9x telnet.exe IIRC) would just display stars (in case 1), so that user group too is happy. Did I already mention you could use putty? * systemd already emits VT100 codes, so no additional annoyance would ensue. Downside: * It may not be very visible if you have weird tastes in terminal colors. An alternative would be simple inversion and spaces: \e[7m\x20 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] crypto: to show stars or not to show them
On Friday 2011-03-18 00:18, Jan Engelhardt wrote:
>
> \e[37;47m*
> \e[7m\x20
---
src/ask-password-api.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/src/ask-password-api.c b/src/ask-password-api.c
index 9c3dad9..fac2a2e 100644
--- a/src/ask-password-api.c
+++ b/src/ask-password-api.c
@@ -172,10 +172,20 @@ int ask_password_tty(
loop_write(ttyfd, "\b \b", 3, false);
}
} else {
+#ifdef pick_one
+/* No \b trickery needed */
+static const char s[] = "\e[7m \e[0m";
+#else
+/*
+ * Extra " \b" required so that the background color
+ * does not spill into a new line when wrapping.
+ */
+static const char s[] = " \b\e[37;47m*\e[0m";
+#endif
passphrase[p++] = c;
if (ttyfd >= 0)
-loop_write(ttyfd, "*", 1, false);
+loop_write(ttyfd, s, sizeof(s)-1, false);
}
}
--
# Created with git-export-patch
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Sat, 12.03.11 13:00, Andrey Borzenkov (arvidj...@mail.ru) wrote: > The problem is not limited to syslog and applies to all special > targets that serve as "virtual provides" > > Actually I think design should be reversed. The service that > implements this virtual provide (syslog, network, rpcbind, smtp, ...) > should pull in special target. This way you ensure > > - when service that provides functionality is started, corresponding > virtual target is started as indication, that functionality is > available > > - if there is no service with requested functionality, target is not > available. In other words - target is not faked to be started unless > functionality is available. This allows easy and logical check, > whether syslog (rpcbind, network, ...) was really provided by any > service - if unit is not started, it was not. To round this off, > specials should also refuse manual activation. So, Kay and I discussed this yesterday, and we came to the conclusion that Andrey's proposal is the right thing to do. It should be the specific implementations which pull in the generic targets and *not* the other way round. This might be surprising at first, but Andrey, Kay and I think this makes most sense. Here's an attempt of a longer explanation for this: First of all most of these special targets should eventually go away without replacement. They exist primarily to provide compatibility with SysV/LSB where generic facility names were a crucial requirement for ordering things properly. However, in a world with socket and bus activation this is not necessary anymore. If all services are socket and bus activatable, then all clients can just use them without the need to wait for anything explicitly. Currently existing targets of this kind are at least: nss-lookup.target, http-daemon.target, dbus.target, mail-transfer-agent.target, rpcbind.target, rtc-set.target, syslog.target. Of these dbus.target can probably be retired right now, since we only support bus activated dbus daemons. And syslog.target probably soon too, since all relevant syslog implementations have been patched by now. And rpcbind very likely too soon. Then there is network.target. This is a bit more complex case. $network in LSB headers is mostly use to synchronize services to the point where "the network is up". I generally believe that the idea that such a point in tim exists is just broken. Networks aren't static beasts anymore. They come and go. Machines move. Machines are reconfigured all the time. An application which is written in a way that it expects the network to be up from the moment it is started to the moment it exits is just broken. That's 90's style hacking, but in 2011 network software should acknowledge that things have changed and subscribe to netlink so that they follow network changes and can be started at any time. Thankfully a lot of software does that correctly now. However, we have to acknowledge that a lot of software still doesn't, for example stuff like ntpdate. For that reason we probably need to keep network.target for a while, even if it's mostly an indication of software sucking and not so much an indication of excellence on sw design. So, now let's have a close look at network.target, NetworkManager.service and network.service (i.e. the classic Fedora network init scripts. The ordering between these units is pretty clear: network.target should be AFTER the other two, and that's about it. But what about the requirement deps? The obvious choice would be to make network.target require (or want) the two services. But that would mean that any start transaction that includes network.target would also include the two services. And is this really what we want? No, clearly not I would say. network.target is supposed to be used to order the various network setup systems against the various network consuming services, but it shouldn't mean that just to enforce this ordering having apache.service in your transaction also causes you to have *all* the configured network setup implementations in it as well. i.e. if at boot NM and the old network scripts got started, and then the user stopped NM (but didn't disable it), then starting apache should definitely *not* start NM again. And hence there should *not* be a wants/requires dep from network.target on NM.service nor network.service. But what about the other direction? We definitely want network.target in the boot transaction if NM or network.service is part of it too. Because only then the network consuming services can be synchronized properly. Hence we want those two services pull in network.target, as a signal "Hey, we implement this, and when it is up, you can use it". So, here's what I am going to do now: a) Modify the Description= strings of the various target units where this applies to make clear that they exist for SysV/LSB compat only. b) Remove dbus.target c) Add a Wants+Before to syslog.socket on syslog.target. Since the socket is already e
Re: [systemd-devel] crypto: to show stars or not to show them
On Fri, 18.03.11 00:18, Jan Engelhardt (jeng...@medozas.de) wrote: > Meanwhile, I have two new suggestions. I have one too (or actually Kay came up with it), and I think you are going to like it: Start with showing input feedback as we currently do. If the user then presses TAB the stars disappear, and instead we show "(no echo)" or so. Then, the user can proceed with typing his password without asterisks. This should be strictly one way however: you can enter the no-echo mode but not leave it anymore. For two reasons: so that people cannot take over your machine and make visible what you explicitly wanted to hide: the length of your password. And secondly, there might be weird folks with Tabs in their passphrases (though they are probably going through hell if they do), and by pressing TAB twice they thus have a way to enter a single TAB. If you prep a patch for this logic I'd merge it right-away and I think both of us should be perfectly happy, right? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] crypto: to show stars or not to show them
+1 from me. I like the idea of being able to hide the password prompt, but not by default. It's one of those "Oh, someone is looking over my shoulder, I should hit tab" things. On a slightly different note; Would it be possible to watch for unprintable keys? For example, what about a single backspace/delete at the start of the prompt, before you've entered anything? I'm used to tab making things appear, not making things disappear. On the other hand, I'm used to backspace/delete making things disappear; so it feels more logical to me. On Thu, Mar 17, 2011 at 5:41 PM, Lennart Poettering wrote: > On Fri, 18.03.11 00:18, Jan Engelhardt (jeng...@medozas.de) wrote: > > > Meanwhile, I have two new suggestions. > > I have one too (or actually Kay came up with it), and I think you are > going to like it: > > Start with showing input feedback as we currently do. If the user then > presses TAB the stars disappear, and instead we show "(no echo)" or > so. Then, the user can proceed with typing his password without > asterisks. > > This should be strictly one way however: you can enter the no-echo mode > but not leave it anymore. For two reasons: so that people cannot take > over your machine and make visible what you explicitly wanted to hide: > the length of your password. And secondly, there might be weird folks > with Tabs in their passphrases (though they are probably going through > hell if they do), and by pressing TAB twice they thus have a way to > enter a single TAB. > > If you prep a patch for this logic I'd merge it right-away and I think > both of us should be perfectly happy, right? > > Lennart > > -- > Lennart Poettering - Red Hat, Inc. > ___ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel > -- [ Graham Cantin ] | (408) 890-7463 - Google Voice FindME [ NASA Ames Research ] | Building 19, Moffett Field, CA "As living spies we must recruit men who are intelligent but appear to be stupid; who seem to be dull but are strong in heart; men who are agile, vigorous, hardy, and brave; well-versed in lowly matters and able to endure hunger, cold, filth, and humiliation." - Tu Mu (803-825) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] Detect page size runtime
Hi all, Systemd hardcode page size as 4096(in macro.h), this is not always correct: """ Some architectures support multiple machine types with diffenent page sizes, and some machine types even support multiple page sizes themselves. """ This patch tries to detect page size runtime by sysconf(_SC_PAGESIZE), and uses 4096 as a failsafe value. Note we need memset vec to zero before call mincore(src/readahead-collect.c, 129) -- if the pagesize is not correct, we may randomly record wider range or more ranges to readahead. -- Regards, - cee1 0001-Detect-page-size-runtime.patch Description: Binary data ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Thu, 17.03.11 23:28, Lennart Poettering (lenn...@poettering.net) wrote: > On Thu, 17.03.11 13:06, Mike Kazantsev (mk.frag...@gmail.com) wrote: > > > On Thu, 17 Mar 2011 01:04:35 +0100 > > Lennart Poettering wrote: > > > > > On Wed, 16.03.11 14:39, Andrey Borzenkov (arvidj...@mail.ru) wrote: > > > > > > > > Or is rsyslog expected to provide a symlink in syslog.target.wants? > > > > > > > > > > > > > This is really orthogonal. As Lennart commented, it may be sensible to > > > > do both. But this symlink does not ensure syslog is actually started > > > > before syslog.target. > > > > > > Well, actually there is. > > > > > > If DefaultDependencies= is "yes" (which it is by default) for target > > > units then they'll automatically gain an After= for all untis they have > > > Wants= or Requires= on. > > > > > > (We currently do not document what DefaultDependencies= actually means > > > for the specific unit types. We probably should...) > > > > > > > Can this behavior be relied upon or this might change in future > > releases? > > Yes. Hah, turns out this is actually already documented, in systemd.target(5) where it should be. So yupp, it's so reliable, that this is already documented since a while ;-) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Special targets - should they Want or be WantedBy?
On Fri, 18 Mar 2011 00:34:19 +0100 Lennart Poettering wrote: > > But what about the other direction? We definitely want network.target in > the boot transaction if NM or network.service is part of it too. Because > only then the network consuming services can be synchronized > properly. Hence we want those two services pull in network.target, as a > signal "Hey, we implement this, and when it is up, you can use it". > > So, here's what I am going to do now: > > a) Modify the Description= strings of the various target units where >this applies to make clear that they exist for SysV/LSB compat only. > > b) Remove dbus.target > > c) Add a Wants+Before to syslog.socket on syslog.target. Since the >socket is already enough to make logging possible this is all that is >needed. > > d) fix the systemd code which parses LSB headers to interpret Provides >like this. > > e) patch NM upstream and NTP in F15 to add the necessary dependencies. > > And Andrey, thanks a lot for pointing us to this problem and the > solution! > > Questions? Anything we didn't think about? > That'd make all the systems with currently enabled services in network.target.wants misconfigured - network should fail on these unless something Requires= (or Wants=) network.target explicitly (which was marked as a wrong way to depend on network), so I think maybe some larger announcement for packagers is in order as well, to leave less broken systems and angry users as a result ;) -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] rsyslog drops messages in debug mode
Hi, when booting with systemd.log_level=debug, I get Mar 18 06:39:26 pluto rsyslogd-2177: imuxsock begins to drop messages from pid 1 due to rate-limiting ... Mar 18 06:39:31 pluto rsyslogd-2177: imuxsock lost 127 messages from pid 1 due to rate-limiting Note: I didn't explicitly use systemd.log_target=kmsg -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "Inactive/dead" services that are enabled are indistinguishable from unused or oneshot services
On Thu, 17 Mar 2011 22:48:36 +0100 Lennart Poettering wrote: > On Thu, 17.03.11 10:20, Mike Kazantsev (mk.frag...@gmail.com) wrote: > > > On Thu, 17 Mar 2011 01:39:19 +0100 > > Lennart Poettering wrote: > > > > Experiencing several reboots on a machine with 50+ enabled daemons > > I've noticed that some of them (mostly the ones, started via some > > "laucher script" like apachectl, pg_ctl, ejabberdctl, etc) tend to > > "cleanly" fail randomly on start just because GuessMainPID= mechanism > > fails and systemd actually kills the service. > > Hmm, GuessPID= fails? Do you know why exactly? Ideas for improvements? > > The current logic is pretty simply: we look for all processes in the > service cgroup which have PPID == 1. If there is only one of these, we > assume it is the main process. In your case there hence must be more > than once where this condition applies? Any recommendation would else we > could check? > For some services I've observed following behavior: * logs state that service received sigterm and is shutting down. * systemd status shows "Main PID" that differs from the one in the logs and/or pidfile. Thus I assume that in all these cases launcher forks more than one process and when the first forked one (which gets marked as "main") dies, systemd pulls the plug and just kills the rest of them. Problem seem to be related to timing and maybe some switch like GuessMainPIDAfterRunningForSec= would help, but it'd still be racy, so disabling pid guessing and using PIDFile= seem to be a better way to do it with app's cooperation, and all the apps with such complicated start seem to support pidfiles, so I don't think anything else is necessary there, unless pidfile-eradication becomes some kind of crusade, but then all such "launchers" should probably just go away as well. > > I understand that there's a limited number of reasons for such "clean > > stop" (manual interaction, units like rsyslog.service, Conflicts=, > > isolate, etc), but still it's a wrong way to approach the particular > > problem. > > > > I've solved the problem for myself by writing a simple dbus-python > > script (http://goo.gl/V6e7V). It shows exactly everything that's > > enabled and not active (with "oneshot" exception), not some random > > subset of this. > > Hmm, jupp. I agree, this is very useful. I added this to the todo list now. > Thanks! > > Unfortunately, new rsyslog.service (and services using "systemctl stop" > > directly) can affect such display, which I think shows the flawed > > assumption that "enabled" in systemd means "should be active, > > period" (with the exception of "oneshot" units) on my part, and I don't > > know easy solution to this, short of adding another enabled-like state. > > Hmm, yeah. This problem is hard. But I think simply showing "enabled but > not running" is already quite useful, even if a service on that list is > not necessarily buggy, but just not hooked in by anything. > I think Andrey's "systemctl --query" suggestion in this thread or special "systemd-query" tool should already be able to provide such functionality (and more), so it should be a good enough solution. Combined with "failed" state for dead-services-that-shouldn't-be it should be even better - services stopped via systemctl like that won't have "failed" state, so they can be easily filtered out by the same query tool or grep/awk. -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "Inactive/dead" services that are enabled are indistinguishable from unused or oneshot services
On Thu, 17 Mar 2011 22:58:00 +0100 Lennart Poettering wrote: > On Thu, 17.03.11 22:48, Lennart Poettering (lenn...@poettering.net) wrote: > > > > Unfortunately, new rsyslog.service (and services using "systemctl stop" > > > directly) can affect such display, which I think shows the flawed > > > assumption that "enabled" in systemd means "should be active, > > > period" (with the exception of "oneshot" units) on my part, and I don't > > > know easy solution to this, short of adding another enabled-like state. > > > > Hmm, yeah. This problem is hard. But I think simply showing "enabled but > > not running" is already quite useful, even if a service on that list is > > not necessarily buggy, but just not hooked in by anything. > > Thinking about this, maybe a simpler solution would be to add a switch > to list all services that have been running since the boot but are not > running anymore. That would be quite trivial to implement. Does that > make sense to you? > Looks like kinda "systemctl snapshot" diffs to me. It's not really hard to do now with systemctl, grep, sort and diff, plus some service which does initial snapshot late at boot, but it looks like a kludge to me - services tend to fail at boot as well, and desired system state (enabled/disabled) may change over uptime (i.e. new stuff installed, something got disabled), so it doesn't make sense anymore to compare anything to just a boot-state. Maybe it'd make sense to add ability to diff state snapshots in this regard, comparing (and saving) not just running but also enabled/masked services. It looks way out of scope of systemctl, too, and more in the realm of systemd-query tool, maybe developed separately, as it sounds more like a separate systemd-monitoring solution at this point ;) -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] "Inactive/dead" services that are enabled are indistinguishable from unused or oneshot services
On Thu, 17 Mar 2011 23:04:20 +0100 Lennart Poettering wrote: > On Thu, 17.03.11 09:52, Andrey Borzenkov (arvidj...@mail.ru) wrote: > > > I understand that there's already a looong TODO, but maybe it's possible > > > to cram such systemctl view option(s) somewhere in that list? > > > > > > > I was vaguely thinking about adding generic selection option to > > replace current ad-hoc ones, something like > > > > --state=enabled,!exited > > ! on the sell is always a bit weird. But this might be a good idea to > have. > > > or even allowing generic filtering on specific property, like > > > > --query Type=socket,dbus > > Hmm, having this would make systemctl almost an SQL database ;-) > > I think we should try to figure out what exactly we need, instead of > losing ourselves in inventing new matching languages. systemctl already > has quite a long man page, and I'd prefer if it wouldnt become a novel. > > Maybe one option would be to introduce it as seperate 'systemd-query' > tool or so? > Separate tool sound like a great idea to me. It'd also be nice if such tool had either machine-parseable output or some other interface, so it can be easily hooked up into existing monitoring solutions via snmp (for example) or provided some GUI or web interface without the need to re-implement querying logic again and again in each of these. -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] rsyslog drops messages in debug mode
On Fri, 18 Mar 2011 07:03:01 +0100 Michael Biebl wrote: > Hi, > > when booting with systemd.log_level=debug, I get > > Mar 18 06:39:26 pluto rsyslogd-2177: imuxsock begins to drop messages > from pid 1 due to rate-limiting > ... > Mar 18 06:39:31 pluto rsyslogd-2177: imuxsock lost 127 messages from > pid 1 due to rate-limiting > > Note: I didn't explicitly use systemd.log_target=kmsg > I believe it's an rsyslog (imuxsock module) newer feature to limit flow from extra-verbose apps by default, which you can tune or completely bypass, as described in the docs: http://www.rsyslog.com/doc/imuxsock.html -- Mike Kazantsev // fraggod.net signature.asc Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] rsyslog drops messages in debug mode
2011/3/18 Mike Kazantsev : > On Fri, 18 Mar 2011 07:03:01 +0100 > Michael Biebl wrote: > >> Hi, >> >> when booting with systemd.log_level=debug, I get >> >> Mar 18 06:39:26 pluto rsyslogd-2177: imuxsock begins to drop messages >> from pid 1 due to rate-limiting >> ... >> Mar 18 06:39:31 pluto rsyslogd-2177: imuxsock lost 127 messages from >> pid 1 due to rate-limiting >> >> Note: I didn't explicitly use systemd.log_target=kmsg >> > > I believe it's an rsyslog (imuxsock module) newer feature to limit flow > from extra-verbose apps by default, which you can tune or completely > bypass, as described in the docs: > I know that (and I forgot to add that I use rsyslog 5.7.8). My point rather is, that for a default rsyslog + systemd installation imho this should not happen. I'm wondering if the default values in rsyslog are too aggressive in that regard? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
