Re: [systemd-devel] Masking .network files
On Sat, Apr 5, 2014 at 12:43 AM, Leonid Isaev wrote:
> I seem to have a strange issue with the way networkd processes its
> configuration files. The machine is actually a systemd-nspawn container with
> a static IP address, so I had to mask the default 80-container-host0.network
> and create a custom config. Both real and virtual machines are up-to-date
> archlinux [testing] installations.
So the best way to do this is to name your custom config file either
the same as what you are overriding (if the overridden file should
anyway never be used, which is the case for what you describe), or
simply name it starting with a lower number. That way the first
matching file will be applied.
The 'masking' logic that you know from unit files does not really make
much sense for .network files (but maybe this is something we should
change...). Symlinks to /dev/null are just treated as empty .network
files, so their meaning is "no [Match] section", which matches
everything and "no [Network] section", which does nothing. I suppose
this may be used to express "ignore any subsequent .network files",
but I doubt that is a particularly useful thing to do.
> -
> $ file /{etc,usr/lib}/systemd/network/80-container-host0.network
> /etc/systemd/network/80-container-host0.network: symbolic link to `/dev/null'
> /usr/lib/systemd/network/80-container-host0.network: ASCII text
> $ cat /etc/systemd/network/eth.network
> [Match]
> Name=host0
>
> [Network]
> Address=10.137.0.2/24
> Gateway=10.137.0.1
>
> [DHCPv4]
> UseDNS=false
> -
>
> However, this new .network file is never picked up by systemd-networkd (it
> does provide a working network setup if the host0 interface is renamed). Here
> is the debug output:
>
> -
> Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: timestamp of
> '/etc/systemd/network' changed
> Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: timestamp of
> '/run/systemd/network' changed
> Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: Skipping overridden
> file: /usr/lib/systemd/network/80-container-host0.network.
> Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: Configuration
> file /etc/systemd/network/80-container-host0.network is marked world-writable.
> Please remove world writability permission bits. Proceeding anyway.
> Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: found matching
> network '/etc/systemd/network/80-container-host0.network'
> Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: requesting link
> status
> Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: bringing link up
> Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: link configured
> Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: link (with ifindex
> 22) added
> Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: found matching network
> '/etc/systemd/network/80-container-host0.network'
> Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: requesting link status
> Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: bringing link up
> Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: link configured
> Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: link (with ifindex 1)
> added
> Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: MAC address:
> 36:9a:b1:98:ab:e1
> Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: link status
> updated: -> 0x00011043
> Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: link is up
> Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: carrier on
> Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: Sent message
> type=method_call sender=n/a destination=org.freedesktop.DBus
> object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello
> cookie=1 reply_cookie=0 error=n/a
> Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: Got message
> type=method_return sender=org.freedesktop.DBus destination=:1.8 object=n/a
> interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a
> Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: link status updated:
> -> 0x00010049
> Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: link is up
> Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: carrier on
> Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: Got message type=signal
> sender=org.freedesktop.DBus destination=:1.8 object=/org/freedesktop/DBus
> interface=org.freedesktop.DBus member=NameAcquired cookie=2 reply_cookie=0
> error=n/a
> Apr 04 21:29:02 lxc_archtest systemd-networkd[128]: Received SIGINT.
> Apr 04 21:29:02 lxc_archtest systemd-networkd[128]: Assertion
> 's->event->state != SD_EVENT_FINISHED' failed at
> src/libsystemd/sd-event/sd-event.c:1308, function
> sd_event_source_set_enabled(). Ignoring.
> Apr 04 21:29:02 lxc_archtest systemd-networkd[128]: Assertion
> 's->event->state != SD_EVENT_FINISHED' failed at
> src/libsystemd/sd-event/sd-event.c:1308, function
> sd_event_source_set_enabled(). Ignoring.
> Apr 04 21
Re: [systemd-devel] [PATCH] core: Make sure a stamp file exists for all Persistent=true timers
On Wed, Apr 2, 2014 at 8:18 PM, Thomas Bächler wrote: > If a persistent timer has no stamp file yet, it behaves just like a normal > timer until it runs for the first time. If the system is always shut down > while the timer is supposed to run, a stamp file is never created and > Peristent=true has no effect. > > This patch fixes this by creating a stamp file with the current time > when the timer is first started. If timers are started at early boot (which sounds like a common scenario), I guess /var will not yet be writable so this will be a noop, no? Maybe it would be better to write out these files at shutdown instead (before unmounting anything)? Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Masking .network files
On 05/04/14 12:26, Tom Gundersen wrote: > matching file will be applied. The 'masking' logic that you know from > unit files does not really make much sense for .network files (but > maybe this is something we should change...). Symlinks to /dev/null > are just treated as empty .network files, so their meaning is "no > [Match] section", which matches everything and "no [Network] section", > which does nothing. I suppose this may be used to express "ignore any > subsequent .network files", but I doubt that is a particularly useful > thing to do. I know you are talking about .network files, but can I get verify on... You can still override /lib/systemd/network/99-default.link by symlinking /etc/systemd/network/99-default.link to /dev/null, right? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Masking .network files
On Sat, Apr 5, 2014 at 11:39 AM, Samuli Suominen wrote: > On 05/04/14 12:26, Tom Gundersen wrote: >> matching file will be applied. The 'masking' logic that you know from >> unit files does not really make much sense for .network files (but >> maybe this is something we should change...). Symlinks to /dev/null >> are just treated as empty .network files, so their meaning is "no >> [Match] section", which matches everything and "no [Network] section", >> which does nothing. I suppose this may be used to express "ignore any >> subsequent .network files", but I doubt that is a particularly useful >> thing to do. > > I know you are talking about .network files, but can I get verify on... > > You can still override /lib/systemd/network/99-default.link by > symlinking /etc/systemd/network/99-default.link to /dev/null, right? Hm, yes. But the same logic applies, any subsequent .link files would also be masked (but such subsequent .link files would never have applied in the first place as 99-default.link matches everything. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-git Build failed
I am running Archlinux with a custom 3.18.1 Kernel. Full system is upgraded.
Usually systemd-git build fine using the AUR package[1]. The last two
builds(first one was with linux 3.17) with these errors:
***
src/libsystemd/sd-rtnl/rtnl-types.c:72:52: error: 'IFLA_BOND_MAX'
undeclared here (not in a function)
static const NLType rtnl_link_info_data_bond_types[IFLA_BOND_MAX + 1] = {
^
src/libsystemd/sd-rtnl/rtnl-types.c:73:10: error: 'IFLA_BOND_MODE'
undeclared here (not in a function)
[IFLA_BOND_MODE]= { .type = NLA_U8 },
^
src/libsystemd/sd-rtnl/rtnl-types.c:73:9: error: array index in
initializer not of integer type
[IFLA_BOND_MODE]= { .type = NLA_U8 },
^
src/libsystemd/sd-rtnl/rtnl-types.c:73:9: error: (near initialization
for 'rtnl_link_info_data_bond_types')
src/libsystemd/sd-rtnl/rtnl-types.c:73:9: error: field name not in
record or union initializer
src/libsystemd/sd-rtnl/rtnl-types.c:73:9: error: (near initialization
for 'rtnl_link_info_data_bond_types')
src/libsystemd/sd-rtnl/rtnl-types.c:74:10: error:
'IFLA_BOND_ACTIVE_SLAVE' undeclared here (not in a function)
[IFLA_BOND_ACTIVE_SLAVE]= { .type = NLA_U32 },
^
src/libsystemd/sd-rtnl/rtnl-types.c:74:9: error: array index in
initializer not of integer type
[IFLA_BOND_ACTIVE_SLAVE]= { .type = NLA_U32 },
^
src/libsystemd/sd-rtnl/rtnl-types.c:74:9: error: (near initialization
for 'rtnl_link_info_data_bond_types')
src/libsystemd/sd-rtnl/rtnl-types.c:74:9: error: field name not in
record or union initializer
src/libsystemd/sd-rtnl/rtnl-types.c:74:9: error: (near initialization
for 'rtnl_link_info_data_bond_types')
src/libsystemd/sd-rtnl/rtnl-types.c:72:21: warning:
'rtnl_link_info_data_bond_types' defined but not used
[-Wunused-variable]
static const NLType rtnl_link_info_data_bond_types[IFLA_BOND_MAX + 1] = {
^
Makefile:11868: recipe for target
'src/libsystemd/sd-rtnl/libsystemd_internal_la-rtnl-types.lo' failed
./configure CFLAGS='-g -O0 -ftrapv' --enable-compat-libs
--enable-kdbus --sysconfdir=/etc --localstatedir=/var
--libdir=/usr/lib --enable-gtk-doc
Am I missing something ? Did I disabled anything when building my
kernel which could be the root of this issue ?
TY for help.
[1]https://aur.archlinux.org/packages/systemd-git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-git Build failed
On 04/05/2014 02:00 PM, arnaud gaboury wrote:
> I am running Archlinux with a custom 3.18.1 Kernel. Full system is upgraded.
>
Are you from the future? I doubt that networkd supports kernels from the
future :|
> Usually systemd-git build fine using the AUR package[1]. The last two
> builds(first one was with linux 3.17) with these errors:
>
> ***
> src/libsystemd/sd-rtnl/rtnl-types.c:72:52: error: 'IFLA_BOND_MAX'
> undeclared here (not in a function)
> static const NLType rtnl_link_info_data_bond_types[IFLA_BOND_MAX + 1] = {
> ^
> src/libsystemd/sd-rtnl/rtnl-types.c:73:10: error: 'IFLA_BOND_MODE'
> undeclared here (not in a function)
> [IFLA_BOND_MODE]= { .type = NLA_U8 },
> ^
> src/libsystemd/sd-rtnl/rtnl-types.c:73:9: error: array index in
> initializer not of integer type
> [IFLA_BOND_MODE]= { .type = NLA_U8 },
> ^
> src/libsystemd/sd-rtnl/rtnl-types.c:73:9: error: (near initialization
> for 'rtnl_link_info_data_bond_types')
> src/libsystemd/sd-rtnl/rtnl-types.c:73:9: error: field name not in
> record or union initializer
> src/libsystemd/sd-rtnl/rtnl-types.c:73:9: error: (near initialization
> for 'rtnl_link_info_data_bond_types')
> src/libsystemd/sd-rtnl/rtnl-types.c:74:10: error:
> 'IFLA_BOND_ACTIVE_SLAVE' undeclared here (not in a function)
> [IFLA_BOND_ACTIVE_SLAVE]= { .type = NLA_U32 },
> ^
> src/libsystemd/sd-rtnl/rtnl-types.c:74:9: error: array index in
> initializer not of integer type
> [IFLA_BOND_ACTIVE_SLAVE]= { .type = NLA_U32 },
> ^
> src/libsystemd/sd-rtnl/rtnl-types.c:74:9: error: (near initialization
> for 'rtnl_link_info_data_bond_types')
> src/libsystemd/sd-rtnl/rtnl-types.c:74:9: error: field name not in
> record or union initializer
> src/libsystemd/sd-rtnl/rtnl-types.c:74:9: error: (near initialization
> for 'rtnl_link_info_data_bond_types')
> src/libsystemd/sd-rtnl/rtnl-types.c:72:21: warning:
> 'rtnl_link_info_data_bond_types' defined but not used
> [-Wunused-variable]
> static const NLType rtnl_link_info_data_bond_types[IFLA_BOND_MAX + 1] = {
> ^
> Makefile:11868: recipe for target
> 'src/libsystemd/sd-rtnl/libsystemd_internal_la-rtnl-types.lo' failed
>
>
> ./configure CFLAGS='-g -O0 -ftrapv' --enable-compat-libs
> --enable-kdbus --sysconfdir=/etc --localstatedir=/var
> --libdir=/usr/lib --enable-gtk-doc
>
> Am I missing something ? Did I disabled anything when building my
> kernel which could be the root of this issue ?
>
> TY for help.
>
Jokes aside.
If the 3.18 was a typo and if that's 3.8 kernel, then you might have
some trouble:
http://lists.freedesktop.org/archives/systemd-devel/2014-March/018347.html
But that's related to userspace headers, linux-api-headers.
>
>
> [1]https://aur.archlinux.org/packages/systemd-git
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
--
Note: My last name is not Krejzi.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] logind: export *IgnoreInhibited settings to DBus
---
src/login/logind-dbus.c | 4
1 file changed, 4 insertions(+)
diff --git a/src/login/logind-dbus.c b/src/login/logind-dbus.c
index 0af6714..0e58955 100644
--- a/src/login/logind-dbus.c
+++ b/src/login/logind-dbus.c
@@ -1922,6 +1922,10 @@ const sd_bus_vtable manager_vtable[] = {
SD_BUS_PROPERTY("HandleSuspendKey", "s", property_get_handle_action,
offsetof(Manager, handle_suspend_key), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY("HandleHibernateKey", "s", property_get_handle_action,
offsetof(Manager, handle_hibernate_key), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY("HandleLidSwitch", "s", property_get_handle_action,
offsetof(Manager, handle_lid_switch), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY("PowerKeyIgnoreInhibited", "b", NULL,
offsetof(Manager, power_key_ignore_inhibited), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY("SuspendKeyIgnoreInhibited", "b", NULL,
offsetof(Manager, suspend_key_ignore_inhibited), SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY("HibernateKeyIgnoreInhibited", "b", NULL,
offsetof(Manager, hibernate_key_ignore_inhibited),
SD_BUS_VTABLE_PROPERTY_CONST),
+SD_BUS_PROPERTY("LidSwitchIgnoreInhibited", "b", NULL,
offsetof(Manager, lid_switch_ignore_inhibited), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY("IdleAction", "s", property_get_handle_action,
offsetof(Manager, idle_action), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY("IdleActionUSec", "t", NULL, offsetof(Manager,
idle_action_usec), SD_BUS_VTABLE_PROPERTY_CONST),
SD_BUS_PROPERTY("PreparingForShutdown", "b", property_get_preparing,
0, 0),
--
1.9.1.377.g96e67c8
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Masking .network files
Hi,
On Sat, 5 Apr 2014 11:26:17 +0200
Tom Gundersen wrote:
> On Sat, Apr 5, 2014 at 12:43 AM, Leonid Isaev wrote:
> > I seem to have a strange issue with the way networkd processes its
> > configuration files. The machine is actually a systemd-nspawn container
> > with a static IP address, so I had to mask the default
> > 80-container-host0.network and create a custom config. Both real and
> > virtual machines are up-to-date archlinux [testing] installations.
>
> So the best way to do this is to name your custom config file either
> the same as what you are overriding (if the overridden file should
> anyway never be used, which is the case for what you describe), or
> simply name it starting with a lower number. That way the first
> matching file will be applied.
Thanks for the explanation.
I figured that much, just wanted to know whether it was a 'feature'.
>
> The 'masking' logic that you know from unit files does not really make
> much sense for .network files (but maybe this is something we should
> change...). Symlinks to /dev/null are just treated as empty .network
> files, so their meaning is "no [Match] section", which matches
> everything and "no [Network] section", which does nothing.
I don't know the grand goal of networkd, so it's just an opinion, but it seems
odd that the daemon will touch interfaces it shouldn't just because there is a
masked .network file (what if I want a given iface to stay down after boot).
> I suppose
> this may be used to express "ignore any subsequent .network files",
> but I doubt that is a particularly useful thing to do.
Wouldn't this be a bad thing? Because a distribution/upstream can break lots
of boxes by providing e.g. /usr/lib/systemd/network/30-stupid-default.network
which most people will automatically (and naively) mask...
Best,
L.
>
> > -
> > $ file /{etc,usr/lib}/systemd/network/80-container-host0.network
> > /etc/systemd/network/80-container-host0.network: symbolic link to
> > `/dev/null' /usr/lib/systemd/network/80-container-host0.network: ASCII text
> > $ cat /etc/systemd/network/eth.network
> > [Match]
> > Name=host0
> >
> > [Network]
> > Address=10.137.0.2/24
> > Gateway=10.137.0.1
> >
> > [DHCPv4]
> > UseDNS=false
> > -
> >
> > However, this new .network file is never picked up by systemd-networkd (it
> > does provide a working network setup if the host0 interface is renamed).
> > Here is the debug output:
> >
> > -
> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: timestamp of
> > '/etc/systemd/network' changed
> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: timestamp of
> > '/run/systemd/network' changed
> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: Skipping overridden
> > file: /usr/lib/systemd/network/80-container-host0.network.
> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: Configuration
> > file /etc/systemd/network/80-container-host0.network is marked
> > world-writable. Please remove world writability permission bits.
> > Proceeding anyway. Apr 04 21:29:00 lxc_archtest systemd-networkd[128]:
> > host0: found matching network
> > '/etc/systemd/network/80-container-host0.network' Apr 04 21:29:00
> > lxc_archtest systemd-networkd[128]: host0: requesting link status
> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: bringing link up
> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: link configured
> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: link (with
> > ifindex 22) added
> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: found matching
> > network '/etc/systemd/network/80-container-host0.network'
> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: requesting link
> > status Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: bringing
> > link up Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: link
> > configured Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: link
> > (with ifindex 1) added
> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: MAC address:
> > 36:9a:b1:98:ab:e1
> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: link status
> > updated: -> 0x00011043
> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: link is up
> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: carrier on
> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: Sent message
> > type=method_call sender=n/a destination=org.freedesktop.DBus
> > object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello
> > cookie=1 reply_cookie=0 error=n/a Apr 04 21:29:00 lxc_archtest
> > systemd-networkd[128]: Got message type=method_return
> > sender=org.freedesktop.DBus destination=:1.8 object=n/a interface=n/a
> > member=n/a cookie=1 reply_cookie=1 error=n/a Apr 04 21:29:00 lxc_archtest
> > systemd-networkd[128]: lo: link status updated: -> 0x00010049 Apr
> > 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: link is up Apr 04
> > 21:29:00 lxc_archtest sys
Re: [systemd-devel] [PATCH] core: Make sure a stamp file exists for all Persistent=true timers
On Sat, Apr 05, 2014 at 11:35:24AM +0200, Tom Gundersen wrote: > On Wed, Apr 2, 2014 at 8:18 PM, Thomas Bächler wrote: > > If a persistent timer has no stamp file yet, it behaves just like a normal > > timer until it runs for the first time. If the system is always shut down > > while the timer is supposed to run, a stamp file is never created and > > Peristent=true has no effect. > > > > This patch fixes this by creating a stamp file with the current time > > when the timer is first started. > > If timers are started at early boot (which sounds like a common > scenario), I guess /var will not yet be writable so this will be a > noop, no? Maybe it would be better to write out these files at > shutdown instead (before unmounting anything)? Isn't timers.target starter after sysinit.target, i.e. after /var has been mounted? Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: Make sure a stamp file exists for all Persistent=true timers
Am 05.04.2014 11:35, schrieb Tom Gundersen: > On Wed, Apr 2, 2014 at 8:18 PM, Thomas Bächler wrote: >> If a persistent timer has no stamp file yet, it behaves just like a normal >> timer until it runs for the first time. If the system is always shut down >> while the timer is supposed to run, a stamp file is never created and >> Peristent=true has no effect. >> >> This patch fixes this by creating a stamp file with the current time >> when the timer is first started. > > If timers are started at early boot (which sounds like a common > scenario), I guess /var will not yet be writable so this will be a > noop, no? Maybe it would be better to write out these files at > shutdown instead (before unmounting anything)? I failed to hit "reply all" last time, so apologies for sending you this mail twice, Tom. Persistent=true timers have an implicit dependency on RequiresMountsFor=/var/lib/systemd/timers. $ systemctl show -p RequiresMountsFor updatedb.timer RequiresMountsFor=/var/lib/systemd/timers $ systemctl cat updatedb.timer # /usr/lib/systemd/system/updatedb.timer [Unit] Description=Daily locate database update [Timer] OnCalendar=daily AccuracySec=12h Persistent=true 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-git Build failed
On Sat, Apr 05, 2014 at 02:00:33PM +0200, arnaud gaboury wrote:
> I am running Archlinux with a custom 3.18.1 Kernel. Full system is upgraded.
>
> Usually systemd-git build fine using the AUR package[1]. The last two
> builds(first one was with linux 3.17) with these errors:
>
> ***
> src/libsystemd/sd-rtnl/rtnl-types.c:72:52: error: 'IFLA_BOND_MAX'
> undeclared here (not in a function)
> static const NLType rtnl_link_info_data_bond_types[IFLA_BOND_MAX + 1] = {
Can you check with latest git?
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] journal-remote-parse: avoid passing null to memchr
From: Thomas Hindoe Paaboel Andersen
Found with scan-build
---
src/journal/journal-remote-parse.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/src/journal/journal-remote-parse.c
b/src/journal/journal-remote-parse.c
index 142de0e..239ff38 100644
--- a/src/journal/journal-remote-parse.c
+++ b/src/journal/journal-remote-parse.c
@@ -40,7 +40,7 @@ void source_free(RemoteSource *source) {
static int get_line(RemoteSource *source, char **line, size_t *size) {
ssize_t n, remain;
-char *c;
+char *c = NULL;
char *newbuf = NULL;
size_t newsize = 0;
@@ -49,7 +49,9 @@ static int get_line(RemoteSource *source, char **line, size_t
*size) {
assert(source->filled <= source->size);
assert(source->buf == NULL || source->size > 0);
-c = memchr(source->buf, '\n', source->filled);
+if (source->buf)
+c = memchr(source->buf, '\n', source->filled);
+
if (c != NULL)
goto docopy;
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] cryptsetup: copy value, not key for (rd.)luks.key
From: Matthew Monaco
---
Really? No one has used this?
src/cryptsetup/cryptsetup-generator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/cryptsetup/cryptsetup-generator.c
b/src/cryptsetup/cryptsetup-generator.c
index 75d56dd..f4eeb2a 100644
--- a/src/cryptsetup/cryptsetup-generator.c
+++ b/src/cryptsetup/cryptsetup-generator.c
@@ -287,7 +287,7 @@ static int parse_proc_cmdline_item(const char *key, const
char *value) {
} else if (STR_IN_SET(key, "luks.key", "rd.luks.key") && value) {
free(arg_keyfile);
-arg_keyfile = strdup(key);
+arg_keyfile = strdup(value);
if (!arg_keyfile)
return log_oom();
--
1.9.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] journal-remote-parse: avoid passing null to memchr
On Sat, Apr 05, 2014 at 09:09:47PM +0200, Thomas H.P. Andersen wrote:
> static int get_line(RemoteSource *source, char **line, size_t *size) {
> ssize_t n, remain;
> -char *c;
> +char *c = NULL;
> char *newbuf = NULL;
> size_t newsize = 0;
>
> @@ -49,7 +49,9 @@ static int get_line(RemoteSource *source, char **line,
> size_t *size) {
> assert(source->filled <= source->size);
> assert(source->buf == NULL || source->size > 0);
>
> -c = memchr(source->buf, '\n', source->filled);
> +if (source->buf)
> +c = memchr(source->buf, '\n', source->filled);
> +
> if (c != NULL)
Looks good. Please push.
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not "debug"
On Sat, Apr 05, 2014 at 07:11:47AM +0200, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Apr 03, 2014 at 04:08:15PM +0200, Hannes Reinecke wrote: > > From: Greg KH > > > > If the kernel is started with "debug", that's for the kernel to switch > > into debug mode. We should rely on a namespace for our options, like > > everything else (with the exception of "quiet"). Some people want to > > only debug the kernel, not systemd, and the opposite as well so make > > everyone happy. > Essentialy, this patch adds systemd.debug as an alias for > systemd.log_level=debug systemd.log_target=console. But it doesn't > really fix anything, just moves the initial problem to a different set > of options. What needs to be "fixed"? > This isn't useful. In addition, it is reasonable to use "debug" to > turn on verbose mode for the kernel + init combo, since in practice > this is what people need to diagnose boot problems. Well, the intersection of people that have a problem with both the kernel and systemd at boot time are probably quite small. As a kernel developer, I tell people to turn on debug all the time to find issues in different drivers and the like. They aren't having any problems with systemd, so any extra messages that it causes, isn't going to be helpful. Probably the same thing happens for people who are having problems with systemd. So I thought it would make more sense to have separate options, as the two things really are two different projects / code bases. Having the same flag makes it easy for a small subset of people who would be doing work in both areas, and even then, having to add a simple "systemd.debug" flag to the command line for that doesn't seem to be a big deal. thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] LXC not working with systemd 209 or later
On 04/04/14 23:17, Leonid Isaev wrote: On Fri, 04 Apr 2014 21:19:45 +0100 John Lane wrote: [...] I did this: systemd-nspawn -bD /srv/lxc/testcontainer Starting the container this way is pretty-much instantaneous. You can log in and halt it cleanly. Now that's interesting... 3. How do you mount API filesystems into the container (your config doesn't have /sys and /proc entries)? Try putting the fstab generated by the archlinux template (because that one I tested and it works). AIUI systemd does this automatically. They are mounted in my container. # df /proc /proc/sys /sys Filesystem 1K-blocks Used Available Use% Mounted on proc 0 0 0- /proc proc 0 0 0- /proc sysfs 0 0 0- /sys You are right, a container can be run without any lxc.mount entries at all. However, FYI, the following works and gives verbose logging output. lxc-start -n testcontainer /usr/lib/systemd/systemd -- --log-target=console --log-level=debug ... which is? I am now at the point where I have 2 containers, one created by lxc-archlinux (which works) and one created using what I believe are similar equivalent steps. They both have the exact same lxc config and the exact same packages installed. I still have the problem, but I have discovered more info... I get "user@0.service start operation timed out. Terminating." I tried to execute "systemd --user" manually and got "Trying to run as user instance, but $XDG_RUNTIME_DIR is not set". I've been digging around and noticed in the journal: Failed to open private bus connection: Failed to connect to socket /run/user/0/dbus/user_bus_socket: No such file or directory and pam_systemd(login:session): Failed to create session: Connection timed out I believe the problem lies in pam_systemd timing out (hence the login delay) because it can't talk to systemd-logind due to some IPC problem that I can't work out yet... It's difficult to say what's going on without a verbose journal output... Can you obtain one? Can you post your container creation scripts, so that I try to reproduce your issue over the weekend? Ok, now this is wierd. I have distilled the problem down to the bare bones. I have a "build_container" script (http://pastebin.com/raw.php?i=RhDFhRZi) that will create a container called "testcontainer". It exhibits the problems I see. Now, if I rename that container to, say "testc", and restart it (changing nothing else at all) then it works fine. I am totally confused but it appears that the container's name affects how systemd operates...? if you can try it and see if the same happens to you that would be very helpful. $ ./build_container $ lxc-start -n testcontainer it starts: will see journal output in the console boot messages, like this: "<30>systemd[1]: Set hostname to ." you can log in as root. no password. Long delay. Eventual "user@0.service start operation timed out. Terminating" You can then "halt". slow to stop. "user@0.service start operation timed out. Terminating" takes 90 seconds. Eventually stops, host prompt returned. Now, with the container stopped, rename it: $ mv /var/lib/lxc/testcontainer /var/lib/lxc/testc Start the container again (with the new name) $ lxc-start -n testc it starts, instantly and without journal output in the console boot messages. you can log in as root. no password. instant prompt display. you can "halt". Immediate and quick termination. I don't know what to make of that. Actually, you can avoid the above. Here's another test with just "lxc-create" $ lxc-create -n testcontainer -t archlinux -- -P util-linux $ lxc-start -n testcontainer Same problem. (rename container as before but also edit the rootfs path in the /var/lib/lxc/testc/config file) Puzzled! I'll re-run this test tomorrow and capture full journal output if you need it but I've had enough for one day. J Also, what's the answer to Tom's question? just answered that one too (actually did so yesterday but forgot to press "send"!) Cheers, ___ 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] LXC not working with systemd 209 or later
On 04/04/14 13:10, Tom Gundersen wrote: On Thu, Apr 3, 2014 at 7:53 PM, John Lane wrote: What I find is that the login prompt never results in a prompt. I enter the correct user/password and it takes an age before redisplaying the login prompt. If apply 208 before starting the container then it works as expected. Are you using the official arch package of systemd in your container? If not, make sure that your pam files in the container match the Arch pam package. I.e., the upstream default of system-auth, must be replaced by Arch's system-login entries in /etc/pam.d/systemd-user HTH, Tom pacman -Qo /etc/pam.d/systemd-user /etc/pam.d/systemd-user is owned by systemd 212-1 cat /etc/pam.d/systemd-user #%PAM-1.0 # Used by systemd when launching systemd user instances. account include system-login session include system-login auth required pam_deny.so password required pam_deny.so I am using the stock Arch systemd package. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not "debug"
On Sat, Apr 05, 2014 at 01:16:12PM -0700, Greg KH wrote: > On Sat, Apr 05, 2014 at 07:11:47AM +0200, Zbigniew Jędrzejewski-Szmek wrote: > > On Thu, Apr 03, 2014 at 04:08:15PM +0200, Hannes Reinecke wrote: > > > From: Greg KH > > > > > > If the kernel is started with "debug", that's for the kernel to switch > > > into debug mode. We should rely on a namespace for our options, like > > > everything else (with the exception of "quiet"). Some people want to > > > only debug the kernel, not systemd, and the opposite as well so make > > > everyone happy. > > Essentialy, this patch adds systemd.debug as an alias for > > systemd.log_level=debug systemd.log_target=console. But it doesn't > > really fix anything, just moves the initial problem to a different set > > of options. > > What needs to be "fixed"? The fact that kernel in debug + systemd in debug mode mode produced enough data to case a failed boot. I didn't follow the details of what exactly broke, but at least systemd is (was?) logging a stupid assertion. > > This isn't useful. In addition, it is reasonable to use "debug" to > > turn on verbose mode for the kernel + init combo, since in practice > > this is what people need to diagnose boot problems. > > Well, the intersection of people that have a problem with both the > kernel and systemd at boot time are probably quite small. As a kernel > developer, I tell people to turn on debug all the time to find issues in > different drivers and the like. They aren't having any problems with > systemd, so any extra messages that it causes, isn't going to be > helpful. It's a tradeoff, and there are cases where one meaning or the other would be more convenient. We can certainly find lots or examples and counterexamples... E.g. for me the recent slew of issues with boot getting stuck in F20, which seemed to have been caused by a combination of kernel, systemd, plymouth, and gdm or kdm issues, was quite important and visible. Having 'debug' as one-stop option for less experienced users was totally appropriate. In fact, this setting has been interpreted this way by systemd for a while now, and this bug report is the first complaint about that that I'm aware of. The whole issue started with bug #76935: the original reporter was seemingly unaware of available kernel commandline options, and his comments fairly quickly degenerated to rude personal attacks. It's something that one sees quite often: a complaint, a reply how requested goals can be achieved and why things are implemented the way they are, followed by demands of having it "my way", followed by a fit and swearing. Then come "Anonymous Helpers". I really don't see why we should deal with this shit and waste time on people who evidently want to vent their frustration rather than solve a bug. > Probably the same thing happens for people who are having problems with > systemd. > > So I thought it would make more sense to have separate options, as the > two things really are two different projects / code bases. Having the > same flag makes it easy for a small subset of people who would be doing > work in both areas, and even then, having to add a simple > "systemd.debug" flag to the command line for that doesn't seem to be a > big deal. We already have systemd.log_level=debug which is well known... And usually systemd debugging is most useful together with kernel debugging, so the shared interpretation makes the most sense for us. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not "debug"
On Sat, Apr 5, 2014 at 11:22 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Apr 05, 2014 at 01:16:12PM -0700, Greg KH wrote: >> On Sat, Apr 05, 2014 at 07:11:47AM +0200, Zbigniew Jędrzejewski-Szmek wrote: >> > On Thu, Apr 03, 2014 at 04:08:15PM +0200, Hannes Reinecke wrote: >> > > From: Greg KH >> > > >> > > If the kernel is started with "debug", that's for the kernel to switch >> > > into debug mode. We should rely on a namespace for our options, like >> > > everything else (with the exception of "quiet"). Some people want to >> > > only debug the kernel, not systemd, and the opposite as well so make >> > > everyone happy. >> > Essentialy, this patch adds systemd.debug as an alias for >> > systemd.log_level=debug systemd.log_target=console. But it doesn't >> > really fix anything, just moves the initial problem to a different set >> > of options. >> >> What needs to be "fixed"? > The fact that kernel in debug + systemd in debug mode mode produced > enough data to case a failed boot. I didn't follow the details of what > exactly broke, but at least systemd is (was?) logging a stupid > assertion. > >> > This isn't useful. In addition, it is reasonable to use "debug" to >> > turn on verbose mode for the kernel + init combo, since in practice >> > this is what people need to diagnose boot problems. >> >> Well, the intersection of people that have a problem with both the >> kernel and systemd at boot time are probably quite small. As a kernel >> developer, I tell people to turn on debug all the time to find issues in >> different drivers and the like. They aren't having any problems with >> systemd, so any extra messages that it causes, isn't going to be >> helpful. > It's a tradeoff, and there are cases where one meaning or the other > would be more convenient. We can certainly find lots or examples and > counterexamples... E.g. for me the recent slew of issues with boot > getting stuck in F20, which seemed to have been caused by a > combination of kernel, systemd, plymouth, and gdm or kdm issues, was > quite important and visible. Having 'debug' as one-stop option for > less experienced users was totally appropriate. > > In fact, this setting has been interpreted this way by systemd for a > while now, and this bug report is the first complaint about that that > I'm aware of. > > The whole issue started with bug #76935: the original reporter was > seemingly unaware of available kernel commandline options, and his > comments fairly quickly degenerated to rude personal attacks. It's > something that one sees quite often: a complaint, a reply how > requested goals can be achieved and why things are implemented the way > they are, followed by demands of having it "my way", followed by a fit > and swearing. Then come "Anonymous Helpers". I really don't see why we > should deal with this shit and waste time on people who evidently want > to vent their frustration rather than solve a bug. > >> Probably the same thing happens for people who are having problems with >> systemd. >> >> So I thought it would make more sense to have separate options, as the >> two things really are two different projects / code bases. Having the >> same flag makes it easy for a small subset of people who would be doing >> work in both areas, and even then, having to add a simple >> "systemd.debug" flag to the command line for that doesn't seem to be a >> big deal. > We already have systemd.log_level=debug which is well known... And > usually systemd debugging is most useful together with kernel debugging, > so the shared interpretation makes the most sense for us. Btw, I don't think what makes the most sense to "us" (systemd devs) is really that important, nor what makes sense to kernel devs. All of us are more than capable of passing whatever combination of commandline options necessary to get the effect we want. What we should care about is people who don't spend all their time debugging kernel/init. I.e., end-users, support channels, etc. As long as people are not even arguing from that point of view, I don't think we will get anywhere with this... -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not "debug"
Am 05.04.2014 23:22, schrieb Zbigniew Jędrzejewski-Szmek: > The whole issue started with bug #76935: the original reporter was > seemingly unaware of available kernel commandline options, and his > comments fairly quickly degenerated to rude personal attacks. It's > something that one sees quite often: a complaint, a reply how > requested goals can be achieved and why things are implemented the way > they are, followed by demands of having it "my way", followed by a fit > and swearing. Then come "Anonymous Helpers". I really don't see why we > should deal with this shit and waste time on people who evidently want > to vent their frustration rather than solve a bug. cause and effect, the rude attacks maybe because ignorance and frustration about the "we are always right" attitude what makes sense *to you* is not the only relevant thing! http://lkml.org/lkml/2012/10/3/484 http://www.spinics.net/lists/kernel/msg1716484.html https://plus.google.com/u/0/+TheodoreTso/posts/K7ijdmxJ8PF i guess Kay will now remove me from that list because as affected user i have to shut up in general but that does not change anything in casue and effect and that there are enough people with zero understanding for ""I really don't see why we should deal with this shit" which is your userbase - if you are not interested in users you should make a private project but not the first most imporant piece after the kernel because that brings *responsibility* ___ no other software than systemd logs that much to *bury* any for a non-systemd-developer relevant infos even under normal operations http://www.spinics.net/lists/kernel/msg1716484.html Linus words "I personally find it annoying that it's always the same f*cking primadonna involved" are hardly because *that one* thing and should lead to consider things are handeled wrong instead continue with "I really don't see why we should deal with this shit" the following parapgraph talks also about a general attitude that anybody with critism is treated as enemy all the time and everything left and right of systemd is broken in general and has to be fixed because it stands in the way of systemd >> It does become a problem when you have a system service developer who >> thinks the universe revolves around him, and nobody else matters, and >> people sending him bug-reports are annoyances that should be ignored >> rather than acknowledged and fixed. At that point, it's a problem. 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 v4] use systemd.debug on the kernel command line, not "debug"
On Sat, Apr 05, 2014 at 11:32:50PM +0200, Tom Gundersen wrote: > On Sat, Apr 5, 2014 at 11:22 PM, Zbigniew Jędrzejewski-Szmek > wrote: > > On Sat, Apr 05, 2014 at 01:16:12PM -0700, Greg KH wrote: > >> On Sat, Apr 05, 2014 at 07:11:47AM +0200, Zbigniew Jędrzejewski-Szmek > >> wrote: > >> > On Thu, Apr 03, 2014 at 04:08:15PM +0200, Hannes Reinecke wrote: > >> > > From: Greg KH > >> > > > >> > > If the kernel is started with "debug", that's for the kernel to switch > >> > > into debug mode. We should rely on a namespace for our options, like > >> > > everything else (with the exception of "quiet"). Some people want to > >> > > only debug the kernel, not systemd, and the opposite as well so make > >> > > everyone happy. > >> > Essentialy, this patch adds systemd.debug as an alias for > >> > systemd.log_level=debug systemd.log_target=console. But it doesn't > >> > really fix anything, just moves the initial problem to a different set > >> > of options. > >> > >> What needs to be "fixed"? > > The fact that kernel in debug + systemd in debug mode mode produced > > enough data to case a failed boot. I didn't follow the details of what > > exactly broke, but at least systemd is (was?) logging a stupid > > assertion. > > > >> > This isn't useful. In addition, it is reasonable to use "debug" to > >> > turn on verbose mode for the kernel + init combo, since in practice > >> > this is what people need to diagnose boot problems. > >> > >> Well, the intersection of people that have a problem with both the > >> kernel and systemd at boot time are probably quite small. As a kernel > >> developer, I tell people to turn on debug all the time to find issues in > >> different drivers and the like. They aren't having any problems with > >> systemd, so any extra messages that it causes, isn't going to be > >> helpful. > > It's a tradeoff, and there are cases where one meaning or the other > > would be more convenient. We can certainly find lots or examples and > > counterexamples... E.g. for me the recent slew of issues with boot > > getting stuck in F20, which seemed to have been caused by a > > combination of kernel, systemd, plymouth, and gdm or kdm issues, was > > quite important and visible. Having 'debug' as one-stop option for > > less experienced users was totally appropriate. > > > > In fact, this setting has been interpreted this way by systemd for a > > while now, and this bug report is the first complaint about that that > > I'm aware of. > > > > The whole issue started with bug #76935: the original reporter was > > seemingly unaware of available kernel commandline options, and his > > comments fairly quickly degenerated to rude personal attacks. It's > > something that one sees quite often: a complaint, a reply how > > requested goals can be achieved and why things are implemented the way > > they are, followed by demands of having it "my way", followed by a fit > > and swearing. Then come "Anonymous Helpers". I really don't see why we > > should deal with this shit and waste time on people who evidently want > > to vent their frustration rather than solve a bug. > > > >> Probably the same thing happens for people who are having problems with > >> systemd. > >> > >> So I thought it would make more sense to have separate options, as the > >> two things really are two different projects / code bases. Having the > >> same flag makes it easy for a small subset of people who would be doing > >> work in both areas, and even then, having to add a simple > >> "systemd.debug" flag to the command line for that doesn't seem to be a > >> big deal. > > We already have systemd.log_level=debug which is well known... And > > usually systemd debugging is most useful together with kernel debugging, > > so the shared interpretation makes the most sense for us. > > Btw, I don't think what makes the most sense to "us" (systemd devs) is > really that important, nor what makes sense to kernel devs. All of us > are more than capable of passing whatever combination of commandline > options necessary to get the effect we want. What we should care about > is people who don't spend all their time debugging kernel/init. I.e., > end-users, support channels, etc. As long as people are not even > arguing from that point of view, I don't think we will get anywhere > with this... Well, the example with F20 boot bugs I cite was exactly about that. > > Having 'debug' as one-stop option for > > less experienced users was totally appropriate. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not "debug"
On Sat, Apr 5, 2014 at 11:44 PM, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Apr 05, 2014 at 11:32:50PM +0200, Tom Gundersen wrote: >> On Sat, Apr 5, 2014 at 11:22 PM, Zbigniew Jędrzejewski-Szmek >> wrote: >> > On Sat, Apr 05, 2014 at 01:16:12PM -0700, Greg KH wrote: >> >> On Sat, Apr 05, 2014 at 07:11:47AM +0200, Zbigniew Jędrzejewski-Szmek >> >> wrote: >> >> > On Thu, Apr 03, 2014 at 04:08:15PM +0200, Hannes Reinecke wrote: >> >> > > From: Greg KH >> >> > > >> >> > > If the kernel is started with "debug", that's for the kernel to switch >> >> > > into debug mode. We should rely on a namespace for our options, like >> >> > > everything else (with the exception of "quiet"). Some people want to >> >> > > only debug the kernel, not systemd, and the opposite as well so make >> >> > > everyone happy. >> >> > Essentialy, this patch adds systemd.debug as an alias for >> >> > systemd.log_level=debug systemd.log_target=console. But it doesn't >> >> > really fix anything, just moves the initial problem to a different set >> >> > of options. >> >> >> >> What needs to be "fixed"? >> > The fact that kernel in debug + systemd in debug mode mode produced >> > enough data to case a failed boot. I didn't follow the details of what >> > exactly broke, but at least systemd is (was?) logging a stupid >> > assertion. >> > >> >> > This isn't useful. In addition, it is reasonable to use "debug" to >> >> > turn on verbose mode for the kernel + init combo, since in practice >> >> > this is what people need to diagnose boot problems. >> >> >> >> Well, the intersection of people that have a problem with both the >> >> kernel and systemd at boot time are probably quite small. As a kernel >> >> developer, I tell people to turn on debug all the time to find issues in >> >> different drivers and the like. They aren't having any problems with >> >> systemd, so any extra messages that it causes, isn't going to be >> >> helpful. >> > It's a tradeoff, and there are cases where one meaning or the other >> > would be more convenient. We can certainly find lots or examples and >> > counterexamples... E.g. for me the recent slew of issues with boot >> > getting stuck in F20, which seemed to have been caused by a >> > combination of kernel, systemd, plymouth, and gdm or kdm issues, was >> > quite important and visible. Having 'debug' as one-stop option for >> > less experienced users was totally appropriate. >> > >> > In fact, this setting has been interpreted this way by systemd for a >> > while now, and this bug report is the first complaint about that that >> > I'm aware of. >> > >> > The whole issue started with bug #76935: the original reporter was >> > seemingly unaware of available kernel commandline options, and his >> > comments fairly quickly degenerated to rude personal attacks. It's >> > something that one sees quite often: a complaint, a reply how >> > requested goals can be achieved and why things are implemented the way >> > they are, followed by demands of having it "my way", followed by a fit >> > and swearing. Then come "Anonymous Helpers". I really don't see why we >> > should deal with this shit and waste time on people who evidently want >> > to vent their frustration rather than solve a bug. >> > >> >> Probably the same thing happens for people who are having problems with >> >> systemd. >> >> >> >> So I thought it would make more sense to have separate options, as the >> >> two things really are two different projects / code bases. Having the >> >> same flag makes it easy for a small subset of people who would be doing >> >> work in both areas, and even then, having to add a simple >> >> "systemd.debug" flag to the command line for that doesn't seem to be a >> >> big deal. >> > We already have systemd.log_level=debug which is well known... And >> > usually systemd debugging is most useful together with kernel debugging, >> > so the shared interpretation makes the most sense for us. >> >> Btw, I don't think what makes the most sense to "us" (systemd devs) is >> really that important, nor what makes sense to kernel devs. All of us >> are more than capable of passing whatever combination of commandline >> options necessary to get the effect we want. What we should care about >> is people who don't spend all their time debugging kernel/init. I.e., >> end-users, support channels, etc. As long as people are not even >> arguing from that point of view, I don't think we will get anywhere >> with this... > Well, the example with F20 boot bugs I cite was exactly about that. Yes, indeed you did cover that. Bad phrasing from my side. What I meant is that the counter argument (i.e., the argument why we should change the current behavior) is not being made in terms of what is the most useful to the majority of our user-base, merely what is the most useful to kernel developers... -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mail
Re: [systemd-devel] [PATCH v4] use systemd.debug on the kernel command line, not "debug"
On Sat, Apr 5, 2014 at 4:16 PM, Greg KH wrote: > On Sat, Apr 05, 2014 at 07:11:47AM +0200, Zbigniew Jędrzejewski-Szmek wrote: >> On Thu, Apr 03, 2014 at 04:08:15PM +0200, Hannes Reinecke wrote: >> > From: Greg KH >> > >> > If the kernel is started with "debug", that's for the kernel to switch >> > into debug mode. We should rely on a namespace for our options, like >> > everything else (with the exception of "quiet"). Some people want to >> > only debug the kernel, not systemd, and the opposite as well so make >> > everyone happy. >> Essentialy, this patch adds systemd.debug as an alias for >> systemd.log_level=debug systemd.log_target=console. But it doesn't >> really fix anything, just moves the initial problem to a different set >> of options. > > What needs to be "fixed"? > >> This isn't useful. In addition, it is reasonable to use "debug" to >> turn on verbose mode for the kernel + init combo, since in practice >> this is what people need to diagnose boot problems. > > Well, the intersection of people that have a problem with both the > kernel and systemd at boot time are probably quite small. As a kernel > developer, I tell people to turn on debug all the time to find issues in > different drivers and the like. They aren't having any problems with > systemd, so any extra messages that it causes, isn't going to be > helpful. > > Probably the same thing happens for people who are having problems with > systemd. > > So I thought it would make more sense to have separate options, as the > two things really are two different projects / code bases. Having the > same flag makes it easy for a small subset of people who would be doing > work in both areas, and even then, having to add a simple > "systemd.debug" flag to the command line for that doesn't seem to be a > big deal. > > thanks, > > greg k-h "init.debug" would be better than "systemd.debug", in my opinion. It is shorter (less typing and no possible end-user confusion over "systemd.debug" vs. "system.debug"), and it is init-agnostic. Other init systems (OpenRC, Upstart, etc.) would be able to add their own support for this, if they want, without requiring an init-specific kernel parameter. It just seems a lot simpler this way. Jason ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Masking .network files
On Sat, Apr 5, 2014 at 5:06 PM, Leonid Isaev wrote: > Hi, > > On Sat, 5 Apr 2014 11:26:17 +0200 > Tom Gundersen wrote: > >> On Sat, Apr 5, 2014 at 12:43 AM, Leonid Isaev wrote: >> > I seem to have a strange issue with the way networkd processes its >> > configuration files. The machine is actually a systemd-nspawn container >> > with a static IP address, so I had to mask the default >> > 80-container-host0.network and create a custom config. Both real and >> > virtual machines are up-to-date archlinux [testing] installations. >> >> So the best way to do this is to name your custom config file either >> the same as what you are overriding (if the overridden file should >> anyway never be used, which is the case for what you describe), or >> simply name it starting with a lower number. That way the first >> matching file will be applied. > > Thanks for the explanation. > > I figured that much, just wanted to know whether it was a 'feature'. > >> >> The 'masking' logic that you know from unit files does not really make >> much sense for .network files (but maybe this is something we should >> change...). Symlinks to /dev/null are just treated as empty .network >> files, so their meaning is "no [Match] section", which matches >> everything and "no [Network] section", which does nothing. > > I don't know the grand goal of networkd, so it's just an opinion, but it seems > odd that the daemon will touch interfaces it shouldn't just because there is a > masked .network file (what if I want a given iface to stay down after boot). > >> I suppose >> this may be used to express "ignore any subsequent .network files", >> but I doubt that is a particularly useful thing to do. > > Wouldn't this be a bad thing? Because a distribution/upstream can break lots > of boxes by providing e.g. /usr/lib/systemd/network/30-stupid-default.network > which most people will automatically (and naively) mask... So in general "masking" .network files (in the sense applied to unit files) does not make much sense, and will probably not behave as you would expect from knowing unit files. We may very well want to change this in networkd, but need to think a bit about precisely how (the whole logic is quite different from unit files, so copying the same behavior doesn't quite work I think). >> > /etc/systemd/network/80-container-host0.network: symbolic link to >> > `/dev/null' /usr/lib/systemd/network/80-container-host0.network: ASCII text >> > $ cat /etc/systemd/network/eth.network >> > [Match] >> > Name=host0 >> > >> > [Network] >> > Address=10.137.0.2/24 >> > Gateway=10.137.0.1 >> > >> > [DHCPv4] >> > UseDNS=false >> > - >> > >> > However, this new .network file is never picked up by systemd-networkd (it >> > does provide a working network setup if the host0 interface is renamed). >> > Here is the debug output: >> > >> > - >> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: timestamp of >> > '/etc/systemd/network' changed >> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: timestamp of >> > '/run/systemd/network' changed >> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: Skipping overridden >> > file: /usr/lib/systemd/network/80-container-host0.network. >> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: Configuration >> > file /etc/systemd/network/80-container-host0.network is marked >> > world-writable. Please remove world writability permission bits. >> > Proceeding anyway. Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: >> > host0: found matching network >> > '/etc/systemd/network/80-container-host0.network' Apr 04 21:29:00 >> > lxc_archtest systemd-networkd[128]: host0: requesting link status >> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: bringing link up >> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: link configured >> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: link (with >> > ifindex 22) added >> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: found matching >> > network '/etc/systemd/network/80-container-host0.network' >> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: requesting link >> > status Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: bringing >> > link up Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: link >> > configured Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: lo: link >> > (with ifindex 1) added >> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: MAC address: >> > 36:9a:b1:98:ab:e1 >> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: link status >> > updated: -> 0x00011043 >> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: link is up >> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: host0: carrier on >> > Apr 04 21:29:00 lxc_archtest systemd-networkd[128]: Sent message >> > type=method_call sender=n/a destination=org.freedesktop.DBus >> > object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello >> > cookie=1 r
Re: [systemd-devel] Masking .network files
On Sun, 6 Apr 2014 01:12:45 +0200 Tom Gundersen wrote: > So in general "masking" .network files (in the sense applied to unit > files) does not make much sense, and will probably not behave as you > would expect from knowing unit files. We may very well want to change > this in networkd, but need to think a bit about precisely how (the > whole logic is quite different from unit files, so copying the same > behavior doesn't quite work I think). My question is much simpler: why are empty .network files and files with an empty [Match] section treated equally? Clearly, empty files still "do something". AFAIU networkd compiles a list of all .network "units" before applying their settings, so one can check that a file is empty and kick it off the list, no? But please note that I haven't looked at the code in detail, so feel free to ignore me if the above makes no sense. Best, L. -- Leonid Isaev GnuPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D 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] [PATCH v4] use systemd.debug on the kernel command line, not "debug"
On Sat, Apr 5, 2014 at 4:06 PM, Jason St. John wrote: > "init.debug" would be better than "systemd.debug", in my opinion. It > is shorter (less typing and no possible end-user confusion over > "systemd.debug" vs. "system.debug"), and it is init-agnostic. Other > init systems (OpenRC, Upstart, etc.) would be able to add their own > support for this, if they want, without requiring an init-specific > kernel parameter. > > It just seems a lot simpler this way. It would be a little odd given how "systemd." is how other probably portable options get namespaced. Arguably, systemd.log_level would become init.log_level. I'm not against it, but it couldn't be just init.debug. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
