date:20141204


 mate-settings-daemon might expect to be run from within an X-session.
 These errors look like DISPLAY= isn't set, which is reasonable because
 systemd starts programs from a clean environment.

As mentioned in my post, $DISPLAY is correctly set and is in systemctl
environment. The command is run inside the X session

After more tests, I realized two variables were missing:
-$XAUTHORITY
In an effort to group runtime variables in one place, I set
XAUTHORITY=/run/user/1000/Xauthority.
So adding Environment=XAUTHORITY=/run/user/1000/Xauthority solved this issue.

-$DBUS_SESSION_BUS_ADDRESS
For reasons I ignore (far from being a dbus expert), the
$DBUS_SESSION_BUS_ADDRESS as returned by the
$systemctl --user show-environment did not work for mate-settings-daemon.
Instead, mate is looking for this file to connect to dbus :
~/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0
(machine.id-display). This file has the following content:
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-jszhQsZmjR,guid=be0e590886758c696ffc70175458d736
DBUS_SESSION_BUS_PID=8268
DBUS_SESSION_BUS_WINDOWID=16777217
So adding 
EnvironmentFile=%h/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0
solved the issue.

I am now with this service file:

~/.config/systemd/user/mate-settings-daemon.service

-
[Unit]
Description=Mate settings daemon

[Service]
Type=daemon
Environment=XAUTHORITY=/run/user/1000/Xauthority
EnvironmentFile=%h/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0
ExecStart=/usr/lib/mate-settings-daemon/mate-settings-daemon

[Install]
WantedBy=wm.target


it works and does what I am expecting (mate-settings are started
without any mate session being started).

-
gabx@hortensia ➤➤ ~ % systemctl --user status mate-settings-daemon
● mate-settings-daemon.service - Mate settings daemon
   Loaded: loaded
(/home/gabx/.config/systemd/user/mate-settings-daemon.service;
disabled)
   Active: active (running) since Thu 2014-12-04 09:34:39 CET; 9min ago
 Main PID: 5664 (mate-settings-d)
   CGroup: 
/user.slice/user-1000.slice/user@1000.service/mate-settings-daemon.service
   └─5664 /usr/lib/mate-settings-daemon/mate-settings-daemon




 Anyway, you really should talk to the mate developers to ask them
It is done, but still waiting for any hint...

Now my new questions:

It seems to me my setting is a dirty hack. I can't understand the
content of ~/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0.

-
$ myps dbus
.
154:gabx  1424 1  0 Nov29 ?00:00:00 dbus-launch
--autolaunch=77f348a2b3fb429b85a5de751ea9175a --binary-syntax
--close-stderr
.
---

Why this autolaunch ?
Why is the DBUS_SESSION_BUS_ADDRESS in this file set to
/tmp/dbus-jszhQsZmjR,guid=be0e590886758c696ffc70175458d736 when
$systemctl --user show-environment returns
DBUS_SESSION_BUS_ADDRESS=/run/user/1000/dbus/user_bus_socket ?
I am left with two adresses, which sounds to me confusing and weird.

Why is mate-settings-daemon listening to the adress in
~/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0 and not to the
one provided by systemctl ?


Even if my setup works, I would like to understand this story of two
dbus seesion adresses. Thank you for any explanation to light my
lantern.


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

Re: [systemd-devel] mate desktop user service file

2014-12-04 Thread Qu Wenruo



在 12/04/2014 04:56 PM, arnaud gaboury 写道:

mate-settings-daemon might expect to be run from within an X-session.
These errors look like DISPLAY= isn't set, which is reasonable because
systemd starts programs from a clean environment.

As mentioned in my post, $DISPLAY is correctly set and is in systemctl
environment. The command is run inside the X session

After more tests, I realized two variables were missing:
-$XAUTHORITY
In an effort to group runtime variables in one place, I set
XAUTHORITY=/run/user/1000/Xauthority.
So adding Environment=XAUTHORITY=/run/user/1000/Xauthority solved this issue.

-$DBUS_SESSION_BUS_ADDRESS
For reasons I ignore (far from being a dbus expert), the
$DBUS_SESSION_BUS_ADDRESS as returned by the
$systemctl --user show-environment did not work for mate-settings-daemon.
Instead, mate is looking for this file to connect to dbus :
~/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0
(machine.id-display). This file has the following content:
DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-jszhQsZmjR,guid=be0e590886758c696ffc70175458d736
DBUS_SESSION_BUS_PID=8268
DBUS_SESSION_BUS_WINDOWID=16777217
So adding 
EnvironmentFile=%h/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0
solved the issue.

I am now with this service file:

~/.config/systemd/user/mate-settings-daemon.service

-
[Unit]
Description=Mate settings daemon

[Service]
Type=daemon
Environment=XAUTHORITY=/run/user/1000/Xauthority
EnvironmentFile=%h/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0
ExecStart=/usr/lib/mate-settings-daemon/mate-settings-daemon

[Install]
WantedBy=wm.target


it works and does what I am expecting (mate-settings are started
without any mate session being started).

-
gabx@hortensia ➤➤ ~ % systemctl --user status mate-settings-daemon
● mate-settings-daemon.service - Mate settings daemon
Loaded: loaded
(/home/gabx/.config/systemd/user/mate-settings-daemon.service;
disabled)
Active: active (running) since Thu 2014-12-04 09:34:39 CET; 9min ago
  Main PID: 5664 (mate-settings-d)
CGroup: 
/user.slice/user-1000.slice/user@1000.service/mate-settings-daemon.service
└─5664 /usr/lib/mate-settings-daemon/mate-settings-daemon


Just to mention, the default 1.8.1 mate, will autostart 
mate-setting-daemon according to

its file in /etc/xdg/autostart/mate-settings-daemon.desktop:
--
[Desktop Entry]
Type=Application
Name=MATE Settings Daemon
A lot of i18n names
Exec=/usr/lib/mate-settings-daemon/mate-settings-daemon
OnlyShowIn=MATE;
X-MATE-Autostart-Phase=Initialization
X-MATE-Autostart-Notify=true
X-MATE-AutoRestart=true
--

So the problem does not involve systemd at all...

Thanks,
Qu



Anyway, you really should talk to the mate developers to ask them

It is done, but still waiting for any hint...

Now my new questions:

It seems to me my setting is a dirty hack. I can't understand the
content of ~/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0.

-
$ myps dbus
.
154:gabx  1424 1  0 Nov29 ?00:00:00 dbus-launch
--autolaunch=77f348a2b3fb429b85a5de751ea9175a --binary-syntax
--close-stderr
.
---

Why this autolaunch ?
Why is the DBUS_SESSION_BUS_ADDRESS in this file set to
/tmp/dbus-jszhQsZmjR,guid=be0e590886758c696ffc70175458d736 when
$systemctl --user show-environment returns
DBUS_SESSION_BUS_ADDRESS=/run/user/1000/dbus/user_bus_socket ?
I am left with two adresses, which sounds to me confusing and weird.

Why is mate-settings-daemon listening to the adress in
~/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0 and not to the
one provided by systemctl ?


Even if my setup works, I would like to understand this story of two
dbus seesion adresses. Thank you for any explanation to light my
lantern.


Regards.
___
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

[systemd-devel] [PATCH v10] tmpfiles, man: Add xattr support to tmpfiles

2014-12-04 Thread Maciej Wereski

This patch makes it possible to set extended attributes on files created
by tmpfiles. This can be especially used to set SMACK security labels on
volatile files and directories.

It is done by adding new line of type t. Such line should contain
attributes in Argument field, using following format:

name=value

All other fields are ignored.

If value contains spaces, then it must be surrounded by quotation marks.
User can also put quotation mark in value by escaping it with backslash.

Example:
D /var/run/cups - - - -
t /var/run/cups - - - - security.SMACK64=printing
---
v10:
* use strv_consume_pair()
* small refactorization and cleanup

v9:
* fully parse xattrs in one place
* remove potential double free()

v8:
* update man

v7:
* use strv_consume() instead of strv_extend()
* use only lsetxattr()
* do not label in 'z' option
* style fixes and cleanup

v6:
* rebase
* man fixes
* use glibc xattr
* use unquote_first_word() instead of own parsing logic

v5:
* fixes for HAVE_XATTR undefined
* use cunescape() instead of strreplace()
* cache result of strv_length()
* fix typo in manpage

v4:
* grammar fix in man
* style fix

v3:
* may be used instead of should be used in manpage
* use strv_isempty() instead of != NULL
* rework item_set_xattrs() with split_pair()
* remove copy_item_contents()
* use hashmap_replace() instead of removed copy_item_contents()
* use strv_extend() instead of strv_append()
* cleanup
---
 man/tmpfiles.d.xml  |  32 ---
 src/tmpfiles/tmpfiles.c | 139 
 2 files changed, 155 insertions(+), 16 deletions(-)

diff --git a/man/tmpfiles.d.xml b/man/tmpfiles.d.xml
index 1b14d69..4f2e640 100644
--- a/man/tmpfiles.d.xml
+++ b/man/tmpfiles.d.xml
@@ -343,6 +343,25 @@ L/tmp/foobar ----   
/dev/null/programlisting
 normal path
 names./para/listitem
 /varlistentry
+
+varlistentry
+termvarnamet/varname/term
+listitemparaSet extended
+attributes on item. It may be
+used in conjunction with other
+types (only varnamed/varname,
+varnameD/varname, 
varnamef/varname,
+varnameF/varname, 
varnameL/varname,
+varnamep/varname, 
varnamec/varname,
+varnameb/varname, makes sense).
+If used as a standalone line, then
+commandsystemd-tmpfiles/command
+will try to set extended
+attributes on specified path.
+This can be especially used to set
+SMACK labels.
+/para/listitem
+/varlistentry
 /variablelist
 
 paraIf the exclamation mark is used, this
@@ -430,7 +449,7 @@ r! /tmp/.X[0-9]*-lock/programlisting
 will not be modified. This parameter is
 ignored for varnamex/varname,
 varnamer/varname, varnameR/varname,
-varnameL/varname lines./para
+varnameL/varname, varnamet/varname 
lines./para
 
 paraOptionally, if prefixed with
 literal~/literal, the access mode is masked
@@ -462,8 +481,8 @@ r! /tmp/.X[0-9]*-lock/programlisting
 ownership will not be modified. These
 parameters are ignored for
 varnamex/varname, varnamer/varname,
-varnameR/varname, varnameL/varname
-lines./para
+varnameR/varname, varnameL/varname,
+varnamet/varname lines./para
 /refsect2
 
 refsect2
@@ -527,8 +546,8 @@ r! /tmp/.X[0-9]*-lock/programlisting
 specify a short string that is written to the
 file, suffixed by a newline. For
 varnameC/varname, specifies the source file
-or directory. Ignored for all other
-lines./para
+or directory. For varnamet/varname determines
+extended attributes to be set. Ignored for all other 
lines./para
 /refsect2
 
 /refsect1
@@ -540,7 +559,8 @@ r! /tmp/.X[0-9]*-lock/programlisting
 paracommandscreen/command needs two

Re: [systemd-devel] [PATCH] networkd: support vxlan parameters

Applied. Thanks!

On Sat, Nov 15, 2014 at 3:54 AM, Susant Sahani sus...@redhat.com wrote:
 V3: fix copy paste error
 V4: Make manual and config more readable

 Add vxlan paramertes to config.
 ---
  man/systemd.netdev.xml  | 30 
  src/network/networkd-netdev-gperf.gperf | 83 
 +
  src/network/networkd-netdev-vxlan.c | 81 
  src/network/networkd-netdev-vxlan.h | 10 
  src/network/networkd.h  | 11 +
  5 files changed, 176 insertions(+), 39 deletions(-)

 diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml
 index 275ee52..45934f2 100644
 --- a/man/systemd.netdev.xml
 +++ b/man/systemd.netdev.xml
 @@ -272,6 +272,36 @@
  to discover remote MAC 
 addresses./para
  /listitem
  /varlistentry
 +varlistentry
 +
 termvarnameFDBAgeingSec=/varname/term
 +listitem
 +paraThe lifetime of 
 Forwarding Database entry learnt by the kernel in seconds./para
 +/listitem
 +/varlistentry
 +varlistentry
 +
 termvarnameARPProxy=/varname/term
 +listitem
 +paraA boolean. When true, 
 enables ARP proxy./para
 +/listitem
 +/varlistentry
 +varlistentry
 +
 termvarnameL2MissNotification=/varname/term
 +listitem
 +paraA boolean. When true, 
 enables netlink LLADDR miss notifications./para
 +/listitem
 +/varlistentry
 +varlistentry
 +
 termvarnameL3MissNotification=/varname/term
 +listitem
 +paraA boolean. When true, 
 enables netlink IP ADDR miss notifications./para
 +/listitem
 +/varlistentry
 +varlistentry
 +
 termvarnameRouteShortCircuit=/varname/term
 +listitem
 +paraA boolean. When true 
 route short circuit is turned on./para
 +/listitem
 +/varlistentry
  /variablelist
  /refsect1
  refsect1
 diff --git a/src/network/networkd-netdev-gperf.gperf 
 b/src/network/networkd-netdev-gperf.gperf
 index c524ee5..b311ebe 100644
 --- a/src/network/networkd-netdev-gperf.gperf
 +++ b/src/network/networkd-netdev-gperf.gperf
 @@ -18,42 +18,47 @@ struct ConfigPerfItem;
  %struct-type
  %includes
  %%
 -Match.Host,  config_parse_net_condition, CONDITION_HOST, 
offsetof(NetDev, match_host)
 -Match.Virtualization,config_parse_net_condition, 
 CONDITION_VIRTUALIZATION,  offsetof(NetDev, match_virt)
 -Match.KernelCommandLine, config_parse_net_condition, 
 CONDITION_KERNEL_COMMAND_LINE, offsetof(NetDev, match_kernel)
 -Match.Architecture,  config_parse_net_condition, 
 CONDITION_ARCHITECTURE,offsetof(NetDev, match_arch)
 -NetDev.Description,  config_parse_string,0,  
offsetof(NetDev, description)
 -NetDev.Name, config_parse_ifname,0,  
offsetof(NetDev, ifname)
 -NetDev.Kind, config_parse_netdev_kind,   0,  
offsetof(NetDev, kind)
 -NetDev.MTUBytes, config_parse_iec_size,  0,  
offsetof(NetDev, mtu)
 -NetDev.MACAddress,   config_parse_hwaddr,0,  
offsetof(NetDev, mac)
 -VLAN.Id, config_parse_uint64,0,  
offsetof(VLan, id)
 -MACVLAN.Mode,config_parse_macvlan_mode,  0,  
offsetof(MacVlan, mode)
 -Tunnel.Local,config_parse_tunnel_address,0,  
offsetof(Tunnel, local)
 -Tunnel.Remote,   config_parse_tunnel_address,0,  
offsetof(Tunnel, remote)
 -Tunnel.TOS,  config_parse_unsigned,  0,

Re: [systemd-devel] [PATCH] networkd: Add bridge port path cost

Applied. Thanks! (sorry for the delay)

On Sat, Nov 15, 2014 at 4:17 AM, Susant Sahani sus...@redhat.com wrote:
 This patch add support to specify path cost of the
 bridge port to be configured via conf file.

 Exampe: conf

 file: br.netdev

 [NetDev]
 Name=br-test
 Kind=bridge

 file: br.network
 [Match]
 Name=em1

 [Network]
 Bridge=br-test

 [BridgePort]
 Cost=332

  bridge link
 2: em1 state UP : BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 master
 br-test state disabled priority 32 cost 332
 ---
  man/systemd.network.xml  | 13 +
  src/network/networkd-link.c  | 93 
 
  src/network/networkd-network-gperf.gperf |  1 +
  src/network/networkd-network.c   |  2 +-
  src/network/networkd.h   |  2 +
  5 files changed, 110 insertions(+), 1 deletion(-)

 diff --git a/man/systemd.network.xml b/man/systemd.network.xml
 index 4cc13b2..c9c946c 100644
 --- a/man/systemd.network.xml
 +++ b/man/systemd.network.xml
 @@ -505,6 +505,19 @@
  /refsect1

  refsect1
 +title[BridgePort] Section Options/title
 +paraThe literal[BridgePort]/literal section 
 accepts the following keys./para
 +variablelist class='network-directives'
 +varlistentry
 +termvarnameCost=/varname/term
 +listitem
 +  paraEach port in a bridge may 
 have different speed. Cost is used to decide which link to use. Faster 
 interfaces should have lower costs/para
 +/listitem
 +/varlistentry
 +/variablelist
 +/refsect1
 +
 +refsect1
  titleExample/title
  example
  title/etc/systemd/network/50-static.network/title
 diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
 index 26ef0fe..dbc804b 100644
 --- a/src/network/networkd-link.c
 +++ b/src/network/networkd-link.c
 @@ -705,6 +705,27 @@ int link_address_drop_handler(sd_rtnl *rtnl, 
 sd_rtnl_message *m, void *userdata)
  return 1;
  }

 +static int link_set_handler(sd_rtnl *rtnl, sd_rtnl_message *m, void 
 *userdata) {
 +_cleanup_link_unref_ Link *link = userdata;
 +int r;
 +
 +log_debug_link(link, set link);
 +
 +r = sd_rtnl_message_get_errno(m);
 +if (r  0  r != -EEXIST) {
 +log_struct_link(LOG_ERR, link,
 +MESSAGE=%-*s: could not join netdev: %s,
 +IFNAMSIZ,
 +link-ifname, strerror(-r),
 +ERRNO=%d, -r,
 +NULL);
 +link_enter_failed(link);
 +return 1;
 +}
 +
 +return 0;
 +}
 +
  static int set_hostname_handler(sd_bus *bus, sd_bus_message *m, void 
 *userdata,
  sd_bus_error *ret_error) {
  _cleanup_link_unref_ Link *link = userdata;
 @@ -826,6 +847,69 @@ int link_set_mtu(Link *link, uint32_t mtu) {
  return 0;
  }

 +static int link_set_bridge(Link *link) {
 +_cleanup_rtnl_message_unref_ sd_rtnl_message *req = NULL;
 +int r;
 +
 +assert(link);
 +assert(link-network);
 +
 +if(link-network-cost == 0)
 +return 0;
 +
 +r = sd_rtnl_message_new_link(link-manager-rtnl, req,
 + RTM_SETLINK, link-ifindex);
 +if (r  0) {
 +log_error_link(link, Could not allocate RTM_SETLINK 
 message);
 +return r;
 +}
 +
 +r = sd_rtnl_message_link_set_family(req, PF_BRIDGE);
 +if (r  0) {
 +log_error_link(link,
 +   Could not set message family %s, 
 strerror(-r));
 +return r;
 +}
 +
 +r = sd_rtnl_message_open_container(req, IFLA_PROTINFO);
 +if (r  0) {
 +log_error_link(link,
 +   Could not append IFLA_PROTINFO attribute: 
 %s,
 +   strerror(-r));
 +return r;
 +}
 +
 +if(link-network-cost != 0) {
 +r = sd_rtnl_message_append_u32(req, IFLA_BRPORT_COST, 
 link-network-cost);
 +if (r  0) {
 +log_error_link(link,
 +   Could not append IFLA_BRPORT_COST 
 attribute: %s,
 +   strerror(-r));
 +return r;
 +}
 +}
 +
 +r = sd_rtnl_message_close_container(req);
 +if (r  0) {
 +log_error_link(link,
 +   Could not append IFLA_LINKINFO attribute: 
 %s,
 +

Re: [systemd-devel] networkd: Support setting mtu / mac address by interface name

On Thu, Dec 4, 2014 at 3:50 AM, Lennart Poettering
lenn...@poettering.net wrote:
 Tom, I think it would make sense to allow Name= matches in the [Match]
 section of .link files, no?

Hm, so far I hesitated, as the most common scenarios is the one that
William has, namely to want to match on the name set by udev and not
the one set by the kernel. This we cannot really do in .link files as
it would be confusing for admins to figure out exactly what is being
matched on, and it could obviously become undecidable/nonterminating
depending on how we try to implement it.

 I mean, most of the times .link files are
 used to choose the name depending on other fields, but I think in all
 cases where the name is chosen at creation time of an interface (like
 for example for veth links), it should be Ok to match links based on
 the name they already have?

So this we could do (i.e., allow name matches if and only if the name
is set at creation time). Though, if the name is set at creation time,
shouldn't also all the other properties have been? Moreover, if we
give people this feature I'm pretty sure we'll get lots of people
expecting it to work also for any other sort of name and getting
confused when it doesn't.

So overall, not really convinced, but if there is a usecase for
matching on such limited types of names, I'm not very strongly against
it.

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

Re: [systemd-devel] mate desktop user service file

 Just to mention, the default 1.8.1 mate, will autostart mate-setting-daemon
 according to
 its file in /etc/xdg/autostart/mate-settings-daemon.desktop:
 --
 [Desktop Entry]
 Type=Application
 Name=MATE Settings Daemon
 A lot of i18n names
 Exec=/usr/lib/mate-settings-daemon/mate-settings-daemon
 OnlyShowIn=MATE;
 X-MATE-Autostart-Phase=Initialization
 X-MATE-Autostart-Notify=true
 X-MATE-AutoRestart=true
 --

 So the problem does not involve systemd at all...


I am NOT using mate, so the autostart is not starting. I use i3 wm and
Caja file manger. I only want to use mate-settings-daemon, nothing
else.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] 60-persistent-storage.rules: ignore partitions with ID_FS_TYPE of parent

2014-12-04 Thread harald

From: Harald Hoyer har...@redhat.com

If ID_FS_TYPE of a parent is already set,
then it's something like linux_raid_member or mpath_member
and the disk is already in use, so don't handle the partitions
---
 rules/60-persistent-storage.rules | 5 +
 1 file changed, 5 insertions(+)

diff --git a/rules/60-persistent-storage.rules 
b/rules/60-persistent-storage.rules
index 475b151..836e053 100644
--- a/rules/60-persistent-storage.rules
+++ b/rules/60-persistent-storage.rules
@@ -22,6 +22,11 @@ TEST==whole_disk, GOTO=persistent_storage_end
 # for partitions import parent information
 ENV{DEVTYPE}==partition, IMPORT{parent}=ID_*
 
+# If ID_FS_TYPE of a parent is already set,
+# then it's something like linux_raid_member or mpath_member
+# and the disk is already in use, so don't handle the partitions
+ENV{ID_FS_TYPE}==?*, GOTO=persistent_storage_end
+
 # virtio-blk
 KERNEL==vd*[!0-9], ATTRS{serial}==?*, ENV{ID_SERIAL}=$attr{serial}, 
SYMLINK+=disk/by-id/virtio-$env{ID_SERIAL}
 KERNEL==vd*[0-9], ATTRS{serial}==?*, ENV{ID_SERIAL}=$attr{serial}, 
SYMLINK+=disk/by-id/virtio-$env{ID_SERIAL}-part%n
-- 
2.1.0

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

Re: [systemd-devel] [PATCH] udevd: SAS: use SAS addr + PHY id in by-path whenever possible.

2014-12-04 Thread Harald Hoyer

On 22.09.2014 11:48, Maurizio Lombardi wrote:
 This patch changes the naming scheme for sas disks. The original names used
 disk's sas address and lun, the new scheme uses sas address of the
 nearest expander (if available) and a phy id of the used connection.
 If no expander is used, the phy id of hba phy is used.
 Note that names that refer to RAID or other abstract devices are
 unchanged.
 
 Name in raid configuration:
 hba_pci_address-sas-raid_sas_address-lunY-partZ
 
 Name in expander bare disk configuration:
 hba_pci_address-sas-expander_sas_address-phyX-lunY-partZ
 
 Name format without expanders:
 hba_pci_address-sas-phyX-lunY-partZ
 
 Signed-off-by: Maurizio Lombardi mlomb...@redhat.com


After convincing Kay Sievers, I am going to push this patch, as it fixes
obviously non-predictable symlinks.

To fix already released systemd versions, I would suggest to patch them in a
way, that it outputs both symlinks and add a release note, that the old
symlinks are deprecated.

In the long run, we really should outsource all specialized storage udev helper
code, as Kay mentioned in the various replies to this thread.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] mate desktop user service file

2014-12-04 Thread Simon McVittie

On 04/12/14 08:56, arnaud gaboury wrote:
 -$DBUS_SESSION_BUS_ADDRESS
 For reasons I ignore (far from being a dbus expert), the
 $DBUS_SESSION_BUS_ADDRESS as returned by the
 $systemctl --user show-environment did not work for mate-settings-daemon.
...
 $systemctl --user show-environment returns
 DBUS_SESSION_BUS_ADDRESS=/run/user/1000/dbus/user_bus_socket

You can ignore those reasons as much as you like, but ignoring them is
not going to make them go away.

You seem to be using some mechanism for starting 'systemd --user' that
gives it a DBUS_SESSION_BUS_ADDRESS that assumes dbus-daemon is being
started via a specific third-party implementation of a dbus.service for
the user bus, possibly from user-session-units. If you use the part of
user-session-units that assumes a dbus-daemon will be launched, but not
the part that actually launches the dbus-daemon, then I'm afraid you get
to keep both pieces.

Neither dbus nor systemd currently ships that dbus.service. When I
suggested adding one to dbus, Lennart asked me to use a different path
for the socket, then said he had no plans to support a non-kdbus user
bus at all ... so that feature request is on hold.
(https://bugs.freedesktop.org/show_bug.cgi?id=61301 if you're interested.)

Find what is setting DBUS_SESSION_BUS_ADDRESS, and make it not do that.

 So adding 
 EnvironmentFile=%h/.dbus/session-bus/77f348a2b3fb429b85a5de751ea9175a-0
 solved the issue.

FYI, 77f... is your D-Bus machine ID, found in /var/lib/dbus/machine-id
or /etc/machine-id.

 154:gabx  1424 1  0 Nov29 ?00:00:00 dbus-launch
 --autolaunch=77f348a2b3fb429b85a5de751ea9175a --binary-syntax
 --close-stderr
 
 Why this autolaunch ?

autolaunch is a mechanism to start a dbus-daemon per (machine, X11
display) pair when no dbus-daemon is running and an application tries to
connect to D-Bus. It mostly works via X11 properties; the files in
~/.dbus are a fallback.

If mate-settings-daemon can connect to X11 (a correct DISPLAY and
XAUTHORITY) and *does not* have DBUS_SESSION_BUS_ADDRESS in its
environment, it will use the autolaunch mechanism to get a bus.

Normally, Linux distributions and desktop environments also ensure that
a dbus-daemon is running for each X11 session. Since you seem to have
constructed your own desktop environment out of pieces, it's up to you
to decide how you launch your dbus-daemon and communicate its address to
the right places; autolaunch is the fallback mechanism for if you don't.

S

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

Re: [systemd-devel] systemd-networkd DHCPv6 Prefix Delegation

2014-12-04 Thread Patrik Flykt

On Thu, 2014-12-04 at 03:27 +0100, Tom Gundersen wrote:
 Patrik, do you have any plans for this? I agree, this is likely
 something we want.

I'm tempted to do something about it. Give me time until mid next week
and we'll see what happens.

Cheers,

Patrik


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

Re: [systemd-devel] [PATCH] 60-persistent-storage.rules: ignore partitions with ID_FS_TYPE of parent

2014-12-04 Thread Zbigniew Jędrzejewski-Szmek

On Thu, Dec 04, 2014 at 12:57:36PM +0100, har...@redhat.com wrote:
 From: Harald Hoyer har...@redhat.com
 
 If ID_FS_TYPE of a parent is already set,
 then it's something like linux_raid_member or mpath_member
 and the disk is already in use, so don't handle the partitions
Is this trying to fix an existing problem?

Zbyszek

 ---
  rules/60-persistent-storage.rules | 5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/rules/60-persistent-storage.rules 
 b/rules/60-persistent-storage.rules
 index 475b151..836e053 100644
 --- a/rules/60-persistent-storage.rules
 +++ b/rules/60-persistent-storage.rules
 @@ -22,6 +22,11 @@ TEST==whole_disk, GOTO=persistent_storage_end
  # for partitions import parent information
  ENV{DEVTYPE}==partition, IMPORT{parent}=ID_*
  
 +# If ID_FS_TYPE of a parent is already set,
 +# then it's something like linux_raid_member or mpath_member
 +# and the disk is already in use, so don't handle the partitions
 +ENV{ID_FS_TYPE}==?*, GOTO=persistent_storage_end
 +
  # virtio-blk
  KERNEL==vd*[!0-9], ATTRS{serial}==?*, ENV{ID_SERIAL}=$attr{serial}, 
 SYMLINK+=disk/by-id/virtio-$env{ID_SERIAL}
  KERNEL==vd*[0-9], ATTRS{serial}==?*, ENV{ID_SERIAL}=$attr{serial}, 
 SYMLINK+=disk/by-id/virtio-$env{ID_SERIAL}-part%n
 -- 
 2.1.0
 
 ___
 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] [PATCH] 60-persistent-storage.rules: ignore partitions with ID_FS_TYPE of parent

2014-12-04 Thread Harald Hoyer

On 04.12.2014 15:10, Zbigniew Jędrzejewski-Szmek wrote:
 On Thu, Dec 04, 2014 at 12:57:36PM +0100, har...@redhat.com wrote:
 From: Harald Hoyer har...@redhat.com

 If ID_FS_TYPE of a parent is already set,
 then it's something like linux_raid_member or mpath_member
 and the disk is already in use, so don't handle the partitions
 Is this trying to fix an existing problem?

yes, for mpath_member disk partitions, we should never ever advertise the
/dev/disk/by* symlinks or set SYSTEMD_READY for it.

 
 Zbyszek
 
 ---
  rules/60-persistent-storage.rules | 5 +
  1 file changed, 5 insertions(+)

 diff --git a/rules/60-persistent-storage.rules 
 b/rules/60-persistent-storage.rules
 index 475b151..836e053 100644
 --- a/rules/60-persistent-storage.rules
 +++ b/rules/60-persistent-storage.rules
 @@ -22,6 +22,11 @@ TEST==whole_disk, GOTO=persistent_storage_end
  # for partitions import parent information
  ENV{DEVTYPE}==partition, IMPORT{parent}=ID_*
  
 +# If ID_FS_TYPE of a parent is already set,
 +# then it's something like linux_raid_member or mpath_member
 +# and the disk is already in use, so don't handle the partitions
 +ENV{ID_FS_TYPE}==?*, GOTO=persistent_storage_end
 +
  # virtio-blk
  KERNEL==vd*[!0-9], ATTRS{serial}==?*, ENV{ID_SERIAL}=$attr{serial}, 
 SYMLINK+=disk/by-id/virtio-$env{ID_SERIAL}
  KERNEL==vd*[0-9], ATTRS{serial}==?*, ENV{ID_SERIAL}=$attr{serial}, 
 SYMLINK+=disk/by-id/virtio-$env{ID_SERIAL}-part%n
 -- 
 2.1.0

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

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

Re: [systemd-devel] systemd-networkd DHCPv6 Prefix Delegation

On Thu, Dec 4, 2014 at 2:32 PM, Patrik Flykt
patrik.fl...@linux.intel.com wrote:
 On Thu, 2014-12-04 at 03:27 +0100, Tom Gundersen wrote:
 Patrik, do you have any plans for this? I agree, this is likely
 something we want.

 I'm tempted to do something about it. Give me time until mid next week
 and we'll see what happens.

Great! Thanks!

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

Re: [systemd-devel] systemd.netdev: Tunnel should support ANY addresses for Local option

On Mon, Nov 24, 2014 at 8:38 PM, William Kennington
will...@wkennington.com wrote:
 Currently, networkd netdevs do not support tunnel devices which do not have
 a local address configured. This breaks the configuration of sit devices on
 my hosts which run dhcp for ipv4 configuration, which normally have local
 set to 0.0.0.0. Is there any chance we could remove the any check for the
 local endpoint address?

Done. Does this work for you as expected with current git?

Cheers,

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

Re: [systemd-devel] SIT tunnel does not work

Hi Tomasz,

Sorry to dig up such an old thread, but I just made some changes to
the sit handling, and at least for me it works now. This is the config
I'm currently using:

wireless.network ---8---

[Match]
Name=wlp3s0

[Network]
DHCP=yes
Tunnel=he

he.netdev ---8-

[NetDev]
Name=he
Kind=sit

[Tunnel]
Remote=222.333.444.555
TTL=255

he.network ---8-

[Match]
Name=he-ipv6

[Network]
Address=2001:470:11::2/64

[Route]
Gateway=2001:470:11::1
Source=2001:470:22::/48

[Route]
Gateway=2001:470:11::1
Source=2001:470:11::2/128

[Route]
Source=::/128

---8-


(you probably don't need the source routing stuff, but that's what I
was testing).



Do you still see problems with this on your end with current git?

Cheers,

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

Re: [systemd-devel] networkd: Support setting mtu / mac address by interface name

On Thu, 04.12.14 11:20, Tom Gundersen (t...@jklm.no) wrote:

  I mean, most of the times .link files are
  used to choose the name depending on other fields, but I think in all
  cases where the name is chosen at creation time of an interface (like
  for example for veth links), it should be Ok to match links based on
  the name they already have?
 
 So this we could do (i.e., allow name matches if and only if the name
 is set at creation time). Though, if the name is set at creation time,
 shouldn't also all the other properties have been? 

In nspawn we create veth links, and I *really* *really* don't want to
add tons of options there to set the MTU or suchlike. Setting these
properties really should be done within networkd I think.

I think it would be really useful if we could match on the container's
veth links by name, so that a .link file for it could be equally
expressive as the .network file already is.

 Moreover, if we
 give people this feature I'm pretty sure we'll get lots of people
 expecting it to work also for any other sort of name and getting
 confused when it doesn't.

Well, this is something we can fix by documentation, no?

Or maybe name the match option differently, maybe OriginalName= or
KernelName= or so, and then only matching interfaces where you know
that the name was selected by userspace in the first place?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] mate desktop user service file


 You seem to be using some mechanism for starting 'systemd --user' that
 gives it a DBUS_SESSION_BUS_ADDRESS that assumes dbus-daemon is being
 started via a specific third-party implementation of a dbus.service for
 the user bus, possibly from user-session-units. If you use the part of
 user-session-units that assumes a dbus-daemon will be launched, but not
 the part that actually launches the dbus-daemon, then I'm afraid you get
 to keep both pieces.

 Neither dbus nor systemd currently ships that dbus.service. When I
 suggested adding one to dbus, Lennart asked me to use a different path
 for the socket, then said he had no plans to support a non-kdbus user
 bus at all ... so that feature request is on hold.
 (https://bugs.freedesktop.org/show_bug.cgi?id=61301 if you're interested.)

 Find what is setting DBUS_SESSION_BUS_ADDRESS, and make it not do that.

 autolaunch is a mechanism to start a dbus-daemon per (machine, X11
 display) pair when no dbus-daemon is running and an application tries to
 connect to D-Bus. It mostly works via X11 properties; the files in
 ~/.dbus are a fallback.

After carefully reading dbus-launch(1), I understand now the fall back
mechanism.

Fom man :
You can always avoid autolaunch by manually setting DBUS_SESSION_BUS_ADDRESS

I have this drop-in config as recommanded by my distro (Archlinux) wiki[0]:

/etc/systemd/system/user@.service.d/dbus.conf
-
[Service]
Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/dbus/user_bus_socket
---

I start systemd --user as described in wiki.

[0]https://wiki.archlinux.org/index.php/Systemd/User
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] shutdown

On Fri, 31.10.14 18:50, Tom Deblauwe (deblauwe...@gmail.com) wrote:

 Hello,

Heya, sorry for the late reply. In case this is still open:

Which distribution is this?

 I'm using systemd, but can't seem to correctly shutdown. I have
 already:

What does can't seem to correctly shutdown mean? What precisely
fails? I assume it hangs somewhere? Where precisely?

 - checked: reboot -f works
 - enabled the debug-shell on vt9

When you shut down with debug on the kernel command line, is there
any indication where precisely it hangs? can you paste the last output 
somewhere?

 
 So I was hoping to issue the systemctl list-jobs command from the debug
 shell, however, it didn't allow me to type in commands. The debug shell
 allows me to type something but it is as if the shell is not receiving that
 input. So I can't use the debug shell it seems.
 
 So I decidec to execute journalctl -x -f while the sytem is running, and
 then do reboot. So I only see it gets to log Shutting down. but then
 nothing anymore.

Hmm, this smells like 4b5d8d0f22ae61ceb45a25391354ba53b43ee992 might
fix your issue? Could you verify that this is the issue you are
running into?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] networkd link state

2014-12-04 Thread O Neill, David M

Folks,

I would like to introduce a flag enable=Boolean in the networkd configuration 
files.
I am introducing new features that can create a large amount of configuration.

Deleting and restoring configuration can be quiet laborious
Renaming the files to another extension is possibly another option

This configuration will be under configuration management using tools such as 
chef/puppet/cfengine.

Typically net-tools/networkmanager etc has such a flag and existing in the 
ifcfg onboot / enabled.
Switch technology has the ability to turn on and off the port without deleting 
the configuration also.

What do you think?

Thanks

--
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.

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

Re: [systemd-devel] networkd link state

2014-12-04 Thread Jóhann B. Guðmundsson



On 12/04/2014 03:47 PM, O Neill, David M wrote:

What do you think?


I think this should be consisted with other unit enablement in systemd 
not handled by introducing a new enabled/disabled flag


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

Re: [systemd-devel] networkd link state

2014-12-04 Thread O Neill, David M

Thanks!

-Original Message-
From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On 
Behalf Of Jóhann B. Guðmundsson
Sent: Thursday, December 4, 2014 3:55 PM
To: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] networkd link state


On 12/04/2014 03:47 PM, O Neill, David M wrote:
 What do you think?

I think this should be consisted with other unit enablement in systemd not 
handled by introducing a new enabled/disabled flag

JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.

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

[systemd-devel] systemd-nspawn@.service is unusable

2014-12-04 Thread Peter Lemenkov

Hello All!

I'm playing with systemd-nspawn@.service and cannot make it work. It
seems that similar issues were discussed (and addressed upstream) in
Debian bug #770275 ( https://bugs.debian.org/770275 ) however I
believe I've hit by something else.

What I've done so far:

* Ensured that /var/lib/container exists
* Created both  /var/log/journal/machineid and
/var/lib/container/containername/var/log/journal/machineid
* Ensured that Storage=persistent is set in
/var/lib/container/containername/etc/systemd/journald.conf

Every my attempt to run systemctl status
systemd-nspawn@containername ended up like this:

https://paste.fedoraproject.org/156640/14177088/

Please note that systemd-journald fails so I can't find out what's
going on there. I'm stuck right here. Some other services failed as
well, and I can't login using machinectl login but that's another
story I believe.

Any advice on how to debug this and make
systemd-nspawn@containername usable are highly appreciate!


-- 
With best regards, Peter Lemenkov.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd link state

2014-12-04 Thread Brendan Hide


On 2014/12/04 17:54, Jóhann B. Guðmundsson wrote:


On 12/04/2014 03:47 PM, O Neill, David M wrote:

What do you think?


I think this should be consisted with other unit enablement in systemd 
not handled by introducing a new enabled/disabled flag
I think the idea has some merit. But I also think a *new* flag isn't the 
right, especially since we already have flags that (mostly) achieve this 
already.


Also, config-wise, admins don't work with separate unit files for every 
network interface - we have .net{dev,work} files.


br0.netdev:
[NetDev]
Name=br0
Kind=dummy
#^ currently valid, though I don't know what the results would be.
#Kind=bridge

enp0s25.network:
[Match]
Name=enp0s25
[Network]
DHCP=none
#^ currently valid, though I don't know what the results would be.
#Bridge=br0

The problem with this is that it could still be configured, even if in a 
broken state, where the admin might want that it leave the device alone 
completely or disabled (as in `ip link set enp0s25 down`). This might 
also cause a lot of noise in the logs if the config breakage isn't 
static. Again, I haven't tested and I don't know what the actual results 
would be.


Alternatively:
By {en,dis}able, we usually simply adjust whether or not a file will be 
found in a location. For example, renaming the file would work to a degree:

mv /etc/systemd/network/enp0s25.network{,.disable}

The only problem I see with this strategy would be if you have multiple 
rulesets with wildcards. For example you have this .disabled config for 
enp0s25 but you also have a less-specific ruleset for en* in a second 
(non-disabled) config. That less-specific ruleset could enable the 
interface with an unwanted configuration.


--
__
Brendan Hide
http://swiftspirit.co.za/
http://www.webafrica.co.za/?AFF1E97

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

Re: [systemd-devel] networkd link state

2014-12-04 Thread O Neill, David M

Jóhann/All,

If you could expand on how you solve the following:

Systemd-networkd is a single process and it reads its configuration from 
/etc/systemd/network.
How do unit files, solve a single process managing multiple netdevs?

Taking a switch as a use case with 64 ports, a port could have quite a lot of 
configuration associated with it; in a file such as 
/etc/system/network/sw0p1.link (network/link).
Are you suggesting we using symlinks like systemctl  manages daemons on boot to 
solve the enable/disabled problem?

Thanks
Dave.

-Original Message-
From: O Neill, David M 
Sent: Thursday, December 4, 2014 4:06 PM
To: 'Jóhann B. Guðmundsson'; systemd-devel@lists.freedesktop.org
Subject: RE: [systemd-devel] networkd link state

Thanks!

-Original Message-
From: systemd-devel [mailto:systemd-devel-boun...@lists.freedesktop.org] On 
Behalf Of Jóhann B. Guðmundsson
Sent: Thursday, December 4, 2014 3:55 PM
To: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] networkd link state


On 12/04/2014 03:47 PM, O Neill, David M wrote:
 What do you think?

I think this should be consisted with other unit enablement in systemd not 
handled by introducing a new enabled/disabled flag

JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Intel Shannon Limited
Registered in Ireland
Registered Office: Collinstown Industrial Park, Leixlip, County Kildare
Registered Number: 308263
Business address: Dromore House, East Park, Shannon, Co. Clare

This e-mail and any attachments may contain confidential material for the sole 
use of the intended recipient(s). Any review or distribution by others is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender and delete all copies.

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

Re: [systemd-devel] networkd link state

2014-12-04 Thread Jóhann B. Guðmundsson



On 12/04/2014 04:36 PM, Brendan Hide wrote:

On 2014/12/04 17:54, Jóhann B. Guðmundsson wrote:


On 12/04/2014 03:47 PM, O Neill, David M wrote:

What do you think?


I think this should be consisted with other unit enablement in 
systemd not handled by introducing a new enabled/disabled flag
I think the idea has some merit. But I also think a *new* flag isn't 
the right, especially since we already have flags that (mostly) 
achieve this already.


Also, config-wise, admins don't work with separate unit files for 
every network interface - we have .net{dev,work} files.


br0.netdev:
[NetDev]
Name=br0
Kind=dummy
#^ currently valid, though I don't know what the results would be.
#Kind=bridge

enp0s25.network:
[Match]
Name=enp0s25
[Network]
DHCP=none
#^ currently valid, though I don't know what the results would be.
#Bridge=br0

The problem with this is that it could still be configured, even if in 
a broken state, where the admin might want that it leave the device 
alone completely or disabled (as in `ip link set enp0s25 down`). This 
might also cause a lot of noise in the logs if the config breakage 
isn't static. Again, I haven't tested and I don't know what the actual 
results would be.


Alternatively:
By {en,dis}able, we usually simply adjust whether or not a file will 
be found in a location. For example, renaming the file would work to a 
degree:

mv /etc/systemd/network/enp0s25.network{,.disable}

The only problem I see with this strategy would be if you have 
multiple rulesets with wildcards. For example you have this .disabled 
config for enp0s25 but you also have a less-specific ruleset for en* 
in a second (non-disabled) config. That less-specific ruleset could 
enable the interface with an unwanted configuration.




To be consistent with construction of other type units we would have to 
introduce [Install] section and .network type units would have to be 
enabled/disabled ( most likely by create symlinks in network.target ) 
tjhen administrators simply run systemctl enable enp0s25.network or 
systemctl enable br0.netdev etc.


Tom probably has some insight why this route was not choicen to begin 
with in the overall design to handle enable/disable (if up/down ) of 
network devices?

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

Re: [systemd-devel] [PATCH] 60-persistent-storage.rules: ignore partitions with ID_FS_TYPE of parent

2014-12-04 Thread Andrei Borzenkov

В Thu, 04 Dec 2014 15:14:00 +0100
Harald Hoyer har...@redhat.com пишет:

 On 04.12.2014 15:10, Zbigniew Jędrzejewski-Szmek wrote:
  On Thu, Dec 04, 2014 at 12:57:36PM +0100, har...@redhat.com wrote:
  From: Harald Hoyer har...@redhat.com
 
  If ID_FS_TYPE of a parent is already set,
  then it's something like linux_raid_member or mpath_member
  and the disk is already in use, so don't handle the partitions
  Is this trying to fix an existing problem?
 
 yes, for mpath_member disk partitions, we should never ever advertise the
 /dev/disk/by* symlinks or set SYSTEMD_READY for it.

How is it going to work? I mean, first we get device, then it is
processed by multipathd. At the time rules are processed by udev, we
have no idea whether it will be added to mpath later.

 
  
  Zbyszek
  
  ---
   rules/60-persistent-storage.rules | 5 +
   1 file changed, 5 insertions(+)
 
  diff --git a/rules/60-persistent-storage.rules 
  b/rules/60-persistent-storage.rules
  index 475b151..836e053 100644
  --- a/rules/60-persistent-storage.rules
  +++ b/rules/60-persistent-storage.rules
  @@ -22,6 +22,11 @@ TEST==whole_disk, GOTO=persistent_storage_end
   # for partitions import parent information
   ENV{DEVTYPE}==partition, IMPORT{parent}=ID_*
   
  +# If ID_FS_TYPE of a parent is already set,
  +# then it's something like linux_raid_member or mpath_member
  +# and the disk is already in use, so don't handle the partitions
  +ENV{ID_FS_TYPE}==?*, GOTO=persistent_storage_end
  +
   # virtio-blk
   KERNEL==vd*[!0-9], ATTRS{serial}==?*, ENV{ID_SERIAL}=$attr{serial}, 
  SYMLINK+=disk/by-id/virtio-$env{ID_SERIAL}
   KERNEL==vd*[0-9], ATTRS{serial}==?*, ENV{ID_SERIAL}=$attr{serial}, 
  SYMLINK+=disk/by-id/virtio-$env{ID_SERIAL}-part%n
  -- 
  2.1.0
 
  ___
  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

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

Re: [systemd-devel] [PATCH] 60-persistent-storage.rules: ignore partitions with ID_FS_TYPE of parent

2014-12-04 Thread Harald Hoyer

On 04.12.2014 18:19, Andrei Borzenkov wrote:
 В Thu, 04 Dec 2014 15:14:00 +0100
 Harald Hoyer har...@redhat.com пишет:
 
 On 04.12.2014 15:10, Zbigniew Jędrzejewski-Szmek wrote:
 On Thu, Dec 04, 2014 at 12:57:36PM +0100, har...@redhat.com wrote:
 From: Harald Hoyer har...@redhat.com

 If ID_FS_TYPE of a parent is already set,
 then it's something like linux_raid_member or mpath_member
 and the disk is already in use, so don't handle the partitions
 Is this trying to fix an existing problem?

 yes, for mpath_member disk partitions, we should never ever advertise the
 /dev/disk/by* symlinks or set SYSTEMD_READY for it.
 
 How is it going to work? I mean, first we get device, then it is
 processed by multipathd. At the time rules are processed by udev, we
 have no idea whether it will be added to mpath later.

For the disk, we should/must the flag set immediately in 62-multipath.rules.

The partitions are processed later and IMPORT ID_FS_TYPE from the parent, just
one line above my suggested rule.

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

Re: [systemd-devel] networkd: Support setting mtu / mac address by interface name

On Thu, Dec 4, 2014 at 4:11 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Thu, 04.12.14 11:20, Tom Gundersen (t...@jklm.no) wrote:

  I mean, most of the times .link files are
  used to choose the name depending on other fields, but I think in all
  cases where the name is chosen at creation time of an interface (like
  for example for veth links), it should be Ok to match links based on
  the name they already have?

 So this we could do (i.e., allow name matches if and only if the name
 is set at creation time). Though, if the name is set at creation time,
 shouldn't also all the other properties have been?

 In nspawn we create veth links, and I *really* *really* don't want to
 add tons of options there to set the MTU or suchlike. Setting these
 properties really should be done within networkd I think.

 I think it would be really useful if we could match on the container's
 veth links by name, so that a .link file for it could be equally
 expressive as the .network file already is.

 Moreover, if we
 give people this feature I'm pretty sure we'll get lots of people
 expecting it to work also for any other sort of name and getting
 confused when it doesn't.

 Well, this is something we can fix by documentation, no?

 Or maybe name the match option differently, maybe OriginalName= or
 KernelName= or so, and then only matching interfaces where you know
 that the name was selected by userspace in the first place?

I like the idea of OriginalName, much less likely to get people
confused. I now implemented that, with the restriction that we cannot
match on renamed names. For now I left it open to match on ethX style
names, as people in principle could do sensible things like
OriginalName=eth* or even OriginalName=eth0 when we know there is
only one interface.

One thing to consider would be to disallow renaming from a .link file
where the OriginalName was used to match. That way we don't have the
somewhat odd situation that a .link file can only be applied once (we
do not remember the original name, so cannot match on that the second
time around, as that would be a mess)...

Testing and feedback welcome. Does this solve your problem William?

Cheers,

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

Re: [systemd-devel] mate desktop user service file

On Thu, Dec 4, 2014 at 4:20 PM, arnaud gaboury arnaud.gabo...@gmail.com wrote:

 You seem to be using some mechanism for starting 'systemd --user' that
 gives it a DBUS_SESSION_BUS_ADDRESS that assumes dbus-daemon is being
 started via a specific third-party implementation of a dbus.service for
 the user bus, possibly from user-session-units. If you use the part of
 user-session-units that assumes a dbus-daemon will be launched, but not
 the part that actually launches the dbus-daemon, then I'm afraid you get
 to keep both pieces.

 Neither dbus nor systemd currently ships that dbus.service. When I
 suggested adding one to dbus, Lennart asked me to use a different path
 for the socket, then said he had no plans to support a non-kdbus user
 bus at all ... so that feature request is on hold.
 (https://bugs.freedesktop.org/show_bug.cgi?id=61301 if you're interested.)

 Find what is setting DBUS_SESSION_BUS_ADDRESS, and make it not do that.
--
└─session-c2.scope
  ├─2908 login -- gabx
  ├─2911 -zsh
  ├─2929 /bin/sh /usr/bin/startx
  ├─2951 xinit /home/gabx/.xinitrc -- /etc/X11/xinit/xserverrc :0
vt1 -auth /tmp/serverauth.7yJtuNYzPM
  ├─2952 /usr/bin/Xorg.bin -nolisten tcp :0 vt1 -auth
/tmp/serverauth.7yJtuNYzPM vt1
  ├─2956 i3
  ├─2979 firefox-aurora
  ├─2980 i3bar --bar_id=bar-0 --socket=/run/user/1000/i3/ipc-socket.2956
  ├─2982 urxvt
  ├─2985 caja --no-desktop
  ├─2987 urxvt
  ├─2996 i3status --config=~/.config/i3/i3status.conf
  ├─3011 dbus-launch --autolaunch=77f348a2b3fb429b85a5de751ea9175a
--binary-syntax --close-stderr

---

Culprit is localized : i3

Thank you again for all your explanations.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] missing: define NET_NAME_UNKNOWN

2014-12-04 Thread Colin Walters

It's only exposed to userspace since

  commit 685343fc3ba61a1f6eef361b786601123db16c28
  Author: Tom Gundersen t...@jklm.no
  AuthorDate: Mon Jul 14 16:37:22 2014 +0200
  Commit: David S. Miller da...@davemloft.net
  CommitDate: Tue Jul 15 16:12:01 2014 -0700

to the kernel.
---
 src/shared/missing.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/shared/missing.h b/src/shared/missing.h
index a56d265..aef232b 100644
--- a/src/shared/missing.h
+++ b/src/shared/missing.h
@@ -582,6 +582,10 @@ static inline int setns(int fd, int nstype) {
 #  define NET_NAME_RENAMED 4
 #endif
 
+#ifndef NET_NAME_UNKNOWN
+#  define NET_NAME_UNKNOWN 0
+#endif
+
 #ifndef BPF_XOR
 #  define BPF_XOR 0xa0
 #endif
-- 
1.8.3.1

From 6568250e5ec1873b9b8df986fa07bd6e23ddf5a1 Mon Sep 17 00:00:00 2001
From: Colin Walters walt...@verbum.org
Date: Thu, 4 Dec 2014 13:11:03 -0500
Subject: [PATCH] missing: define NET_NAME_UNKNOWN

It's only exposed to userspace since

  commit 685343fc3ba61a1f6eef361b786601123db16c28
  Author: Tom Gundersen t...@jklm.no
  AuthorDate: Mon Jul 14 16:37:22 2014 +0200
  Commit: David S. Miller da...@davemloft.net
  CommitDate: Tue Jul 15 16:12:01 2014 -0700

to the kernel.
---
 src/shared/missing.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/src/shared/missing.h b/src/shared/missing.h
index a56d265..aef232b 100644
--- a/src/shared/missing.h
+++ b/src/shared/missing.h
@@ -582,6 +582,10 @@ static inline int setns(int fd, int nstype) {
 #  define NET_NAME_RENAMED 4
 #endif
 
+#ifndef NET_NAME_UNKNOWN
+#  define NET_NAME_UNKNOWN 0
+#endif
+
 #ifndef BPF_XOR
 #  define BPF_XOR 0xa0
 #endif
-- 
1.8.3.1

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

Re: [systemd-devel] [PATCH] missing: define NET_NAME_UNKNOWN

2014-12-04 Thread David Herrmann

Hi

On Thu, Dec 4, 2014 at 7:12 PM, Colin Walters walt...@verbum.org wrote:
 It's only exposed to userspace since

   commit 685343fc3ba61a1f6eef361b786601123db16c28
   Author: Tom Gundersen t...@jklm.no
   AuthorDate: Mon Jul 14 16:37:22 2014 +0200
   Commit: David S. Miller da...@davemloft.net
   CommitDate: Tue Jul 15 16:12:01 2014 -0700

 to the kernel.

Weird, this doesn't apply here.. but I cannot figure out why. I merged
it manually now (and moved the constant above the other NET_NAME
defines).

Applied! Thanks
David

 ---
  src/shared/missing.h | 4 
  1 file changed, 4 insertions(+)

 diff --git a/src/shared/missing.h b/src/shared/missing.h
 index a56d265..aef232b 100644
 --- a/src/shared/missing.h
 +++ b/src/shared/missing.h
 @@ -582,6 +582,10 @@ static inline int setns(int fd, int nstype) {
  #  define NET_NAME_RENAMED 4
  #endif

 +#ifndef NET_NAME_UNKNOWN
 +#  define NET_NAME_UNKNOWN 0
 +#endif
 +
  #ifndef BPF_XOR
  #  define BPF_XOR 0xa0
  #endif
 --
 1.8.3.1


 ___
 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] [PATCH] missing: define NET_NAME_UNKNOWN

Thanks!

On Thu, Dec 4, 2014 at 7:27 PM, David Herrmann dh.herrm...@gmail.com wrote:
 Hi

 On Thu, Dec 4, 2014 at 7:12 PM, Colin Walters walt...@verbum.org wrote:
 It's only exposed to userspace since

   commit 685343fc3ba61a1f6eef361b786601123db16c28
   Author: Tom Gundersen t...@jklm.no
   AuthorDate: Mon Jul 14 16:37:22 2014 +0200
   Commit: David S. Miller da...@davemloft.net
   CommitDate: Tue Jul 15 16:12:01 2014 -0700

 to the kernel.

 Weird, this doesn't apply here.. but I cannot figure out why. I merged
 it manually now (and moved the constant above the other NET_NAME
 defines).

 Applied! Thanks
 David

 ---
  src/shared/missing.h | 4 
  1 file changed, 4 insertions(+)

 diff --git a/src/shared/missing.h b/src/shared/missing.h
 index a56d265..aef232b 100644
 --- a/src/shared/missing.h
 +++ b/src/shared/missing.h
 @@ -582,6 +582,10 @@ static inline int setns(int fd, int nstype) {
  #  define NET_NAME_RENAMED 4
  #endif

 +#ifndef NET_NAME_UNKNOWN
 +#  define NET_NAME_UNKNOWN 0
 +#endif
 +
  #ifndef BPF_XOR
  #  define BPF_XOR 0xa0
  #endif
 --
 1.8.3.1


 ___
 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd: Support setting mtu / mac address by interface name

On Thu, 04.12.14 18:53, Tom Gundersen (t...@jklm.no) wrote:

  Moreover, if we
  give people this feature I'm pretty sure we'll get lots of people
  expecting it to work also for any other sort of name and getting
  confused when it doesn't.
 
  Well, this is something we can fix by documentation, no?
 
  Or maybe name the match option differently, maybe OriginalName= or
  KernelName= or so, and then only matching interfaces where you know
  that the name was selected by userspace in the first place?
 
 I like the idea of OriginalName, much less likely to get people
 confused. I now implemented that, with the restriction that we cannot
 match on renamed names. For now I left it open to match on ethX style
 names, as people in principle could do sensible things like
 OriginalName=eth* or even OriginalName=eth0 when we know there is
 only one interface.
 
 One thing to consider would be to disallow renaming from a .link file
 where the OriginalName was used to match. That way we don't have the
 somewhat odd situation that a .link file can only be applied once (we
 do not remember the original name, so cannot match on that the second
 time around, as that would be a mess)...

Maybe we should even store the original name in a udev property, so
that we can make this fully idempotent simply because we can always
check this new property for the original name passed down from the
kernel?

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd: Support setting mtu / mac address by interface name

On Thu, Dec 4, 2014 at 8:08 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Thu, 04.12.14 18:53, Tom Gundersen (t...@jklm.no) wrote:

  Moreover, if we
  give people this feature I'm pretty sure we'll get lots of people
  expecting it to work also for any other sort of name and getting
  confused when it doesn't.
 
  Well, this is something we can fix by documentation, no?
 
  Or maybe name the match option differently, maybe OriginalName= or
  KernelName= or so, and then only matching interfaces where you know
  that the name was selected by userspace in the first place?

 I like the idea of OriginalName, much less likely to get people
 confused. I now implemented that, with the restriction that we cannot
 match on renamed names. For now I left it open to match on ethX style
 names, as people in principle could do sensible things like
 OriginalName=eth* or even OriginalName=eth0 when we know there is
 only one interface.

 One thing to consider would be to disallow renaming from a .link file
 where the OriginalName was used to match. That way we don't have the
 somewhat odd situation that a .link file can only be applied once (we
 do not remember the original name, so cannot match on that the second
 time around, as that would be a mess)...

 Maybe we should even store the original name in a udev property, so
 that we can make this fully idempotent simply because we can always
 check this new property for the original name passed down from the
 kernel?

We got into lots of issues in the past with trying to track the
renaming from userspace (which is why NET_NAME_RENAMED and friends now
are exposed from the kernel), so I'd rather not get back into that
game. The issue is that processes can (and do) rename interfaces
outside of udev's control (possibly before udev is running), and we'll
then be left with knowing that a device was renamed (as the kernel
tells us that much), but not from what. I'd really prefer to keep this
dead simple and either say (as now) that the config is only applied
once if you rename the device, or say that the name-matching config
cannot rename.

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

Re: [systemd-devel] [PATCH v10] tmpfiles, man: Add xattr support to tmpfiles

On Thu, 04.12.14 10:32, Maciej Wereski (m.were...@partner.samsung.com) wrote:

 This patch makes it possible to set extended attributes on files created
 by tmpfiles. This can be especially used to set SMACK security labels on
 volatile files and directories.
 
 It is done by adding new line of type t. Such line should contain
 attributes in Argument field, using following format:

Looks good! Applied!

Thanks!

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCHv2] core: send sigabrt on watchdog timeout to get the stacktrace

On Tue, 28.10.14 15:34, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote:

Sorry for not reviewing this more quickly!

Patch looks great, wanted to apply it, but it unfortunately doesn't
apply anymore. Any chance you can rebase this? Will apply quickly
then!

Sorry for the delay,

Lennart

 if sigabrt doesn't do the job, follow regular shutdown
 routine, sigterm  sigkill.
 
 Umut:
 - I have done basic testing with suppressing sigabrt,
   suppressing both sigabrt  sigterm on client application.
 - Documentation needs to be updated. I wasn't sure if we
 should mention it in KillMode, KillSignal or WatchdogSec

Maybe in KillSignal= and briefly in WatchdogSec=? (given that they are
in different man pages, I think doing this in both places makes a ton
of sense)

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] bus: fix null pointer dereference

On Sun, 09.11.14 15:41, Ronny Chevalier (chevalier.ro...@gmail.com) wrote:

 CID#1237620
 ---
  src/libsystemd/sd-bus/bus-message.c | 3 +++
  1 file changed, 3 insertions(+)
 
 diff --git a/src/libsystemd/sd-bus/bus-message.c 
 b/src/libsystemd/sd-bus/bus-message.c
 index be36d9f..edadacf 100644
 --- a/src/libsystemd/sd-bus/bus-message.c
 +++ b/src/libsystemd/sd-bus/bus-message.c
 @@ -2048,6 +2048,7 @@ static int bus_message_close_variant(sd_bus_message *m, 
 struct bus_container *c)
  
  assert(m);
  assert(c);
 +assert(c-signature);
  
  if (!BUS_MESSAGE_IS_GVARIANT(m))
  return 0;
 @@ -2174,6 +2175,8 @@ _public_ int 
 sd_bus_message_close_container(sd_bus_message *m) {
  if (c-enclosing != SD_BUS_TYPE_ARRAY)
  if (c-signature  c-signature[c-index] != 0)
  return -EINVAL;
 +if (!c-signature  c-enclosing == SD_BUS_TYPE_VARIANT)
 +return -EINVAL;
  
  m-n_containers--;

The letter check is really unnecessary, we don't need to fail in this
case. 

Note that when a container is being put together the signature is
known and initialized at the time the container is opened. Hence when
a container was successfully opened, we know that we can also close it
again with an initialized signature.

The only reason why we allow the signature to be NULL in most cases,
is that when no container is open, and we hence put together the
top-level message object, then we don't know the signature yet, and it
grows as elements are added.

It's a bit of a weird assymetry in that regard: containers know the
signature in advance, but the message itself grows the signature as we
go... 

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] unit: ignore generated systemd-bootchart.service

On Thu, 04.12.14 12:46, WaLyong Cho (walyong@samsung.com) wrote:

Applied! Thanks!

 ---
  units/.gitignore | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/units/.gitignore b/units/.gitignore
 index e12d299..3613cee 100644
 --- a/units/.gitignore
 +++ b/units/.gitignore
 @@ -21,6 +21,7 @@
  /systemd-ask-password-wall.service
  /systemd-backlight@.service
  /systemd-binfmt.service
 +/systemd-bootchart.service
  /systemd-bus-proxyd@.service
  /systemd-firstboot.service
  /systemd-fsck-root.service
 -- 
 1.9.3
 
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd: Support setting mtu / mac address by interface name

2014-12-04 Thread William Kennington

In regards to the OS and syntax, this is NixOS. NixOS uses its own
expression language to configure the entire system, including the network
stack. If a user wanted to configure their system's networking stack, they
would modify the networking.* set of options in their
/etc/nixos/configuration.nix. Currently this is done with a set of
generated scripts run as systemd services with device based dependencies.
Ideally this would be directly translated to networkd syntax.

For example, a user might have this snippet as part of their config for
statically configuring one of their ethernet interfaces:

networking.interfaces.enp4s0 = {
  macAddress = de:ad:be:eef:ca:fe;
  mtu = 9000;
  ip4 = [
{ address = 10.0.0.2; prefixLength = 24; }
{ address = 10.0.0.3; prefixLength = 24; }
  ];
};

For link configuration, we are currently generating a
network-link-ifname.service which sets the mac address and mtu using
iproute2:
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces.nix#L691-L713

The networking options are all defined in:
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces.nix

Our current translator to networkd is:
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces-systemd.nix


Of course, the problem with just using kernel names is that our use case
assumes that the interface was already renamed by udev. Therefore, our
matching must be based on the post-udev name if it is to be backward
compatible. Ultimately it might be best to continue using our set of
scripts coupled with udev generated systemd device units, given our use
cases.

On Thu, Dec 4, 2014 at 9:53 AM, Tom Gundersen t...@jklm.no wrote:

 On Thu, Dec 4, 2014 at 4:11 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Thu, 04.12.14 11:20, Tom Gundersen (t...@jklm.no) wrote:
 
   I mean, most of the times .link files are
   used to choose the name depending on other fields, but I think in all
   cases where the name is chosen at creation time of an interface (like
   for example for veth links), it should be Ok to match links based on
   the name they already have?
 
  So this we could do (i.e., allow name matches if and only if the name
  is set at creation time). Though, if the name is set at creation time,
  shouldn't also all the other properties have been?
 
  In nspawn we create veth links, and I *really* *really* don't want to
  add tons of options there to set the MTU or suchlike. Setting these
  properties really should be done within networkd I think.
 
  I think it would be really useful if we could match on the container's
  veth links by name, so that a .link file for it could be equally
  expressive as the .network file already is.
 
  Moreover, if we
  give people this feature I'm pretty sure we'll get lots of people
  expecting it to work also for any other sort of name and getting
  confused when it doesn't.
 
  Well, this is something we can fix by documentation, no?
 
  Or maybe name the match option differently, maybe OriginalName= or
  KernelName= or so, and then only matching interfaces where you know
  that the name was selected by userspace in the first place?

 I like the idea of OriginalName, much less likely to get people
 confused. I now implemented that, with the restriction that we cannot
 match on renamed names. For now I left it open to match on ethX style
 names, as people in principle could do sensible things like
 OriginalName=eth* or even OriginalName=eth0 when we know there is
 only one interface.

 One thing to consider would be to disallow renaming from a .link file
 where the OriginalName was used to match. That way we don't have the
 somewhat odd situation that a .link file can only be applied once (we
 do not remember the original name, so cannot match on that the second
 time around, as that would be a mess)...

 Testing and feedback welcome. Does this solve your problem William?

 Cheers,

 Tom

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

Re: [systemd-devel] networkd: Support setting mtu / mac address by interface name

Thanks for the links William. Looks like most of that should be
covered by networkd. I now also added support for MTU and MACAddress
to be set in the .network files. The intention here is that if you
ever disable a network at runtime, we will revert to the default
(.link-defined) settings. However, runtime configuration is not yet
implemented, so for now the only distinction between setting this in a
.link and a .network is that you can now match on the real ifname.

HTH,

Tom

On Thu, Dec 4, 2014 at 9:07 PM, William Kennington
will...@wkennington.com wrote:
In regards to the OS and syntax, this is NixOS. NixOS uses its own
expression language to configure the entire system, including the network
stack. If a user wanted to configure their system's networking stack, they
would modify the networking.* set of options in their
/etc/nixos/configuration.nix. Currently this is done with a set of generated
scripts run as systemd services with device based dependencies. Ideally this
would be directly translated to networkd syntax.

For example, a user might have this snippet as part of their config for
statically configuring one of their ethernet interfaces:

networking.interfaces.enp4s0 = {
macAddress = de:ad:be:eef:ca:fe;
mtu = 9000;
ip4 = [
{ address = 10.0.0.2; prefixLength = 24; }
{ address = 10.0.0.3; prefixLength = 24; }
];
};

For link configuration, we are currently generating a
network-link-ifname.service which sets the mac address and mtu using
iproute2:
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces.nix#L691-L713

The networking options are all defined in:
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces.nix

Our current translator to networkd is:
https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/tasks/network-interfaces-systemd.nix

Of course, the problem with just using kernel names is that our use case
assumes that the interface was already renamed by udev. Therefore, our
matching must be based on the post-udev name if it is to be backward
compatible. Ultimately it might be best to continue using our set of scripts
coupled with udev generated systemd device units, given our use cases.

On Thu, Dec 4, 2014 at 9:53 AM, Tom Gundersen t...@jklm.no wrote:

On Thu, Dec 4, 2014 at 4:11 PM, Lennart Poettering
lenn...@poettering.net wrote:
On Thu, 04.12.14 11:20, Tom Gundersen (t...@jklm.no) wrote:

I mean, most of the times .link files are
used to choose the name depending on other fields, but I think in all
cases where the name is chosen at creation time of an interface (like
for example for veth links), it should be Ok to match links based on
the name they already have?

So this we could do (i.e., allow name matches if and only if the name
is set at creation time). Though, if the name is set at creation time,
shouldn't also all the other properties have been?

In nspawn we create veth links, and I *really* *really* don't want to
add tons of options there to set the MTU or suchlike. Setting these
properties really should be done within networkd I think.

I think it would be really useful if we could match on the container's
veth links by name, so that a .link file for it could be equally
expressive as the .network file already is.

Moreover, if we
give people this feature I'm pretty sure we'll get lots of people
expecting it to work also for any other sort of name and getting
confused when it doesn't.

Well, this is something we can fix by documentation, no?

Or maybe name the match option differently, maybe OriginalName= or
KernelName= or so, and then only matching interfaces where you know
that the name was selected by userspace in the first place?

I like the idea of OriginalName, much less likely to get people
confused. I now implemented that, with the restriction that we cannot
match on renamed names. For now I left it open to match on ethX style
names, as people in principle could do sensible things like
OriginalName=eth* or even OriginalName=eth0 when we know there is
only one interface.

One thing to consider would be to disallow renaming from a .link file
where the OriginalName was used to match. That way we don't have the
somewhat odd situation that a .link file can only be applied once (we
do not remember the original name, so cannot match on that the second
time around, as that would be a mess)...

Testing and feedback welcome. Does this solve your problem William?

Cheers,

Tom

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

Re: [systemd-devel] reacting to unit failures (OnFailure)

2014-12-04 Thread Nekrasov, Alexander

If I may go back to RestartSec, this gives me an ability to sleep before 
attempting to restart. I could see where I might use that, but I also need 
another ability, which is to stop restarting a service if it keeps failing, and 
trigger OnFailure instead. 

Upstart has a respawn limit, something like 3 restarts in 180 seconds, and if 
it still fails after that - the job goes to failed state and is left stopped. 
Can I do the same with SystemD?


 -Original Message-
 From: Jóhann B. Guðmundsson [mailto:johan...@gmail.com]
 Sent: Tuesday, December 02, 2014 10:28 AM
 To: Nekrasov, Alexander; systemd-devel@lists.freedesktop.org
 Subject: Re: [systemd-devel] reacting to unit failures (OnFailure)
 
 
 On 12/02/2014 03:12 PM, Nekrasov, Alexander wrote:
  Lennart just gave me a solution, thank you. I'll use templates
 
  I have a system where components at the single node level have
 dependencies and HA policies, such as restart this many times within
 this interval, if still fails - run this action where action is a
 sequence of commands. Components provide this information in their own
 language and I have to generate systemd configuration for them. It's
 more complex than just rebooting the node so I couldn't use
 FailureAction.
 
 Right but you already have
 Restart=on-failure
 RestartSec=...
 
 and the likes to restart the services in graceful HA manner ( and at the
 sametime allowing it to fail gracefully ) so what I was curious about
 what else you are doing in the background since it might lead to a worse
 situation in HA setup by doing so depending on the HA setup ( split
 brains etc you know the drill ).
 
 JBG
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Option fail mentioned in systemd.mount(5)

2014-12-04 Thread Ivan Shapovalov

Hi all,

The systemd.mount(5) man page mentions an inexistent mount option fail in the
following context:

nofail, fail
With nofail this mount will be only wanted, not required, by the
local-fs.target. This means that the boot will continue even if this
mount point is not mounted successfully. Option fail has the opposite
meaning and is the default.

Specifying the option fail in fstab produces following message in the log:

kernel: EXT4-fs (sdc1): Unrecognized mount option fail or missing value

So the man page contradicts actual behavior. Should this statement be removed,
or what?

-- 
Ivan Shapovalov / intelfx /

signature.asc
Description: This is a digitally signed message part.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] segfault in timesyncd

On Thu, 06.11.14 16:32, Damien Robert (damien.olivier.rob...@gmail.com) wrote:

 Here are the logs:
 
 Nov 06 16:14:56 numenor systemd[1]: Started Network Time Synchronization.
 Nov 06 16:14:56 numenor systemd-timesyncd[4881]: Using NTP server 
 10.3.255.254:123 (10.3.255.254).
 Nov 06 16:15:06 numenor systemd-timesyncd[4881]: Timed out waiting for reply 
 from 10.3.255.254:123 (10.3.255.254).
 Nov 06 16:15:06 numenor kernel: systemd-timesyn[4881]: segfault at 8 ip 
 b77bea0a sp bfddf800 error 4 in systemd-timesyncd[b77b5000+1c000]
 Nov 06 16:15:06 numenor systemd[1]: systemd-timesyncd.service: main process 
 exited, code=killed, status=11/SEGV
 Nov 06 16:15:06 numenor systemd[1]: Unit systemd-timesyncd.service entered 
 failed state.
 Nov 06 16:15:06 numenor systemd[1]: systemd-timesyncd.service has no holdoff 
 time, scheduling restart.
 
 I don't understand why I don't get a core dump, sending SIGABRT to a 'sleep'
 does produce one:
 Nov 06 16:09:39 numenor systemd-coredump[4321]: Process 4315 (sleep) of user 
 100
 0 dumped core.
 And my systemd/system.conf does not have a DefaultLimitCORE, and indeed
 $ systemctl show systemd-timesyncd | grep LimitCORE
 LimitCORE=18446744073709551615

Hmm, so, by default we leave the RLIMIT_CORE setting unmodified how we
got it from the kernel. This is the right choice usually, if you use
systemd-coredump to collect the coredumps of the system, since that is
actually not affected by the resource limit. The resource limit only
applies to core dumps stored to disk.

You can change the system-wide default for RLIMIT_CORE in
system.conf. However, I'd instead suggest to make use of
systemd-coredump instead.

Thanks!

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] reacting to unit failures (OnFailure)

On Thu, 04.12.14 16:17, Nekrasov, Alexander (alexander.nekra...@emc.com) wrote:

 If I may go back to RestartSec, this gives me an ability to sleep
 before attempting to restart. I could see where I might use that,
 but I also need another ability, which is to stop restarting a
 service if it keeps failing, and trigger OnFailure instead.

 Upstart has a respawn limit, something like 3 restarts in 180
 seconds, and if it still fails after that - the job goes to failed
 state and is left stopped. Can I do the same with SystemD?

Yes, see StartLimitInterval=, StartLimitBurst=

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Option fail mentioned in systemd.mount(5)

On Fri, 05.12.14 00:20, Ivan Shapovalov (intelfx...@gmail.com) wrote:

 Hi all,
 
 The systemd.mount(5) man page mentions an inexistent mount option fail in 
 the
 following context:
 
 nofail, fail
 With nofail this mount will be only wanted, not required, by the
 local-fs.target. This means that the boot will continue even if this
 mount point is not mounted successfully. Option fail has the opposite
 meaning and is the default.
 
 Specifying the option fail in fstab produces following message in the log:
 
 kernel: EXT4-fs (sdc1): Unrecognized mount option fail or missing value
 
 So the man page contradicts actual behavior. Should this statement be removed,
 or what?

Indeed, neither util-linux nor actually our own code cares about the
fail option, and it is the default anyway.

I removed this now from the man page.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd link state

On Thu, 04.12.14 16:53, O Neill, David M (david.m.one...@intel.com) wrote:

 Jóhann/All,
 
 If you could expand on how you solve the following:
 
 Systemd-networkd is a single process and it reads its configuration
 from /etc/systemd/network.

 How do unit files, solve a single process managing multiple netdevs?
 
 Taking a switch as a use case with 64 ports, a port could have quite
 a lot of configuration associated with it; in a file such as
 /etc/system/network/sw0p1.link (network/link).

 Are you suggesting we using symlinks like systemctl manages daemons
 on boot to solve the enable/disabled problem?

Note that .link files and .network can be applied to multiple devices
the same way. The [Match] section specifies to which set of devices
a file of this kind applies. Normally, if you have a system with 64
ports, and all should run the same configuraiton, you'd just put one
file in place and make it match all 64 ports.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v4 3/4] unit: add UnitMask enum and get unit scope(mask) api from property

On Thu, 04.12.14 17:01, WaLyong Cho (walyong@samsung.com) wrote:

 On 12/04/2014 03:43 AM, Lennart Poettering wrote:
  On Tue, 02.12.14 23:29, WaLyong Cho (walyong@samsung.com) wrote:
  
  Hmm, what's the rationale for this? Can you elaborate?
 
 As you already noticed(on the 4th mail), this hash table is used to find
 unit can have a given property. As you said on 4th mail, if we use a
 special option for timer then this will not be needed.
 This can be also used in systemctl set-property and we can detect given
 property is supported by that unit or not before sending dbus. But, in
 most of case, systemctl set-property is called by user command line. And
 they will know which unit support which property. So, maybe this is not
 much needed.
 If you feel messy, I will add --timer-property= option.

Yeah, I'd prefer to keep the logic for all this on the client side
simple, and make the server side figure things out. Hence I think
--timer-property= is a good solution.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v4] Bootchart: use /proc/pid/mountinfo for root bdev

On Fri, 31.10.14 16:01, Timofey Titovets (nefelim...@gmail.com) wrote:

 
 +void get_rootbdev(char *rootbdev) {
 +FILE *file = fopen(/proc/self/mountinfo, r);
 +char mnt_point[PATH_MAX];
 +char mnt_source[PATH_MAX];
 +char t[256]; // Trash
 +while (file  strcmp(mnt_point, /)  !feof(file)){
 +fscanf(file, %s %s %s %s %s %s %s %s %s %s %s,
 +   t,t,t,t,
 +   mnt_point,  t,t,t,t,
 +   mnt_source, t);
 +}
 +if(!strcmp(mnt_point, /))
 +strncpy(rootbdev, mnt_source[5], 3);
 +fclose(file);
 +}
 +

Umm, the error handling is missing. We don't invoke functions from
variable definitions. We do not allocate over-sized buffers on the
stack. Either we do it with the right size or with dyanmic memory. We
generally don't use strcmp() for simple equality checks, but
streq(). We use _cleanup_xyz_ to automatically free resources. Please
have a look at the CODING_STYLE document in the repository.

In general, I wouldn't consult mountinfo for this at all. Instead
stat() the root fs, then use udev_device_new_from_devnum() on the
returned st_dev, and read the device symlinks from that.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Luks + lvm in initrd

On Tue, 28.10.14 23:51, Luca Bruno (lethalma...@gmail.com) wrote:

 Hi, I'm going on with my work to have systemd in initrd on NixOS (using
 dracut is a little complicated at the moment).
 Everything works fine, I've ported luks and lvm and both work separately.
 However I'm hitting a problem when using luks and lvm on top of luks.

 Any hints on where the culprit can be? Same happens with lvmetad.

The systemd develeopers generally don't really know LVM. LVM does
weird things with udev rules, and we cannot really help with that I
fear. Please ask the LVM folks for help.

In general much of the problems with LVM stem from the fact that they
their udev support is optional, and you need to enable it both in the
initrd and the host to work correctly.

But anyway, I am sorry, but I doubt many people on systemd-devel will
be able to help you.

Sorry,

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] unit A is WantedBy unit B but unit B does not Want unit A?

On Sat, 01.11.14 19:42, Andrei Borzenkov (arvidj...@gmail.com) wrote:

 Sometimes device gets Wants on mount point; sometimes not. I do not
 really understand why. Also different mount units apparently behave
 differently - e.g. mnt.mount forgets its history. It almost looks like
 mnt.mount is destroyed after it is unmounted and t.mount not ...

fstab entries that do not have noauto set get such a dependency
implicitly.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH rebased 1/3] cryptsetup-generator: Split main() into more functions and use hasmaps

On Tue, 02.12.14 18:49, Jan Janssen (medhe...@web.de) wrote:

Sorry for the long delay in reviewing these patches. Looks much better
than the chaotic code from before. Good work. Applied this one and the
two others. 

Thanks!

 ---
  man/systemd-cryptsetup-generator.xml  |   9 +-
  src/cryptsetup/cryptsetup-generator.c | 380 
 +-
  2 files changed, 199 insertions(+), 190 deletions(-)
 
 diff --git a/man/systemd-cryptsetup-generator.xml 
 b/man/systemd-cryptsetup-generator.xml
 index 3abb39d..ff94e88 100644
 --- a/man/systemd-cryptsetup-generator.xml
 +++ b/man/systemd-cryptsetup-generator.xml
 @@ -120,7 +120,7 @@
  activate the specified device as part
  of the boot process as if it was
  listed in
 -filename/etc/fstab/filename. This
 +filename/etc/crypttab/filename. This
  option may be specified more than once
  in order to set up multiple
  devices. varnamerd.luks.uuid=/varname
 @@ -130,9 +130,10 @@
  honored by both the main system and
  the initrd./para
  paraIf /etc/crypttab contains entries with
 -the same UUID, then the options for this 
 entry
 -will be used./para
 -paraIf /etc/crypttab exists, only those 
 UUID
 +the same UUID, then the name, keyfile and 
 options
 +specified there will be used. Otherwise the 
 device
 +will have the name 
 literalluks-UUID/literal./para
 +paraIf /etc/crypttab exists, only those 
 UUIDs
  specified on the kernel command line
  will be activated in the initrd or the real 
 root./para
  /listitem
 diff --git a/src/cryptsetup/cryptsetup-generator.c 
 b/src/cryptsetup/cryptsetup-generator.c
 index 45c23bb..c1581ef 100644
 --- a/src/cryptsetup/cryptsetup-generator.c
 +++ b/src/cryptsetup/cryptsetup-generator.c
 @@ -19,26 +19,34 @@
along with systemd; If not, see http://www.gnu.org/licenses/.
  ***/
  
 -#include string.h
  #include errno.h
 +#include string.h
  #include unistd.h
  
 +#include dropin.h
 +#include fileio.h
 +#include generator.h
 +#include hashmap.h
  #include log.h
 -#include util.h
 -#include unit-name.h
  #include mkdir.h
 -#include strv.h
 -#include fileio.h
  #include path-util.h
 -#include dropin.h
 -#include generator.h
 +#include strv.h
 +#include unit-name.h
 +#include util.h
 +
 +typedef struct crypto_device {
 +char *uuid;
 +char *options;
 +bool create;
 +} crypto_device;
  
  static const char *arg_dest = /tmp;
  static bool arg_enabled = true;
  static bool arg_read_crypttab = true;
 -static char **arg_disks = NULL;
 -static char **arg_options = NULL;
 -static char *arg_keyfile = NULL;
 +static bool arg_whitelist = false;
 +static Hashmap *arg_disks = NULL;
 +static char *arg_default_options = NULL;
 +static char *arg_default_keyfile = NULL;
  
  static bool has_option(const char *haystack, const char *needle) {
  const char *f = haystack;
 @@ -251,8 +259,54 @@ static int create_disk(
  return 0;
  }
  
 +static void free_arg_disks(void) {
 +crypto_device *d;
 +
 +while ((d = hashmap_steal_first(arg_disks))) {
 +free(d-uuid);
 +free(d-options);
 +free(d);
 +}
 +
 +hashmap_free(arg_disks);
 +}
 +
 +static crypto_device *get_crypto_device(const char *uuid) {
 +int r;
 +crypto_device *d;
 +
 +assert(uuid);
 +
 +d = hashmap_get(arg_disks, uuid);
 +if (!d) {
 +d = new0(struct crypto_device, 1);
 +if (!d)
 +return NULL;
 +
 +d-create = false;
 +d-options = NULL;
 +
 +d-uuid = strdup(uuid);
 +if (!d-uuid) {
 +free(d);
 +return NULL;
 +}
 +
 +r = hashmap_put(arg_disks, d-uuid, d);
 +if (r  0) {
 +free(d-uuid);
 +free(d);
 +return NULL;
 +}
 +}
 +
 +return d;
 +}
 +
  static int parse_proc_cmdline_item(const char *key, const char *value) {
  int r;
 +crypto_device *d;
 +_cleanup_free_ char *uuid = NULL, *uuid_value = NULL;
  
  if (STR_IN_SET(key, luks, rd.luks)  value) {
  
 @@ -272,19 +326,29 @@ static int parse_proc_cmdline_item(const char *key,

Re: [systemd-devel] [PATCH v2 5/5] mount: auto-detect iSCSI and FCoE as requiring network

On Mon, 01.12.14 16:47, Karel Zak (k...@redhat.com) wrote:

 On Mon, Dec 01, 2014 at 02:28:33PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
   Wouldn't be enough to use Chris' iSCSI and FCoE auto detection?
  Please see previous discussion... Detecting network might not be trivial
  if the devices are layered and there's a network-requiring device somewhere
  lower in the stack.
 
  Good point. (It would be possible to analyze whole stack by slave/holders
  relations, but I agree it's too complex and probably too fragile.)
 
   Anyway, if you still want to read userspace mount options than I can
   add something like:
   
mnt_inotify_mtab_add_watch()
mnt_inotify_mtab_rm_watch()
mnt_inotify_mtab_changed()
   
   to hide all the paths and private mtab/utab stuff.
  Maybe something more like what journal client code does here:
  
   mnt_mtab_get_fd() - epoll fd
   mnt_mtab_get_events() - EPOLLIN|EPOLLPRI
   mnt_mtab_process() - information what changed
 
  Hmm.. utab is optional and very often does not exist, and library
  uses rename(2) to do atomic update of the file. This is reason why
  Chris have used inotify for /run/mount directory (and Lennart asked
  for inotify API). I have doubts you can use epoll to monitor 
  directories, epoll is about I/O monitoring.

Well, what Zbigniew was suggesting is to hide the fact that inotify is
used away, and instead do that internally. I.e. provide three calls:
one that tells the user of this the fd to listen on, the second that
tells the user of this the poll events to listen on, and finally one
function to call when actually one of those poll events is triggred.

With such an API you have the liberty to change later on what
precisely you expose there. The fact that you watch a file would be
entirely opaque, it could one day be a pipe or socket, or even an fd
on some kernel fd, where you just tell us the kind of events you want
the user code to listen on.

This is how we wrap a lot of our own APIs, to allow integration into
arbitrary main loops, without restricting us to decide how precisely
the event is generated.

Does this make sense?

Would love to get an API in place for this in libmount, because I
don't really want to release systemd with the current code.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v2 5/5] mount: auto-detect iSCSI and FCoE as requiring network

On Sun, 23.11.14 20:33, Chris Leech (cle...@redhat.com) wrote:

 This adds auto detection for iSCSI and some FCoE drivers and treats
 mounts to file-systems on those devices as remote-fs.

Hmm, I am not too fond of having such subsystem-specific complexity in
systemd. 

Hmm, isn't this something that could be fixed in the kernel in a
generic way? Introduce a new generic sysfs attr in a block device that
indicates that some block device involves networking? Similar to the
rotational flag?

I mean, I am not convinced that systemd should be the place where this
is abstracted, I'd much rather see the kernel do this for us, and us
simply making use of the information. 

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /usr vs /etc for default distro units enablement

On Tue, 02.12.14 12:50, Didier Roche (didro...@ubuntu.com) wrote:

 Just to sum up other branches of this thread: we are trying to avoid having
 systemctl calls in debian/ubuntu postinst (or duplicated manual symlinks
 logic as we currently have).
 systemctl preset seems the cleanest path, but we want to ensure corner cases
 can be handled.
 
 d/u policy is to enable newly installed package by default (difference from
 other distributions)
 
 Le 02/12/2014 01:59, Lennart Poettering a écrit :
 On Fri, 28.11.14 11:15, Didier Roche (didro...@ubuntu.com) wrote:
 
 The distribution comes preinstalled with one dm, enable * - enable it, have
 the Alias=display-manager.service picking the right one.
 However, let's say the user installed then another dm, what happens? Both
 will be enabled if we systemctl preset new_service (as the discussion was
 to remove our debian enable service that was conditioned on the
 postinst).
 systemctl preset will fail if there are already conflicting
 symlinks. Hence the first installed DM wins, the second loses.
 
 Ok, that works with the initial install case then.
 However, if lightdm is installed and the admin install gdm, he will get a
 prompt (from postinst) asking him which dm to choose. How would you handle
 that (without messing manually with the symlinks or systemctl enable --force
 in the postinst?). Writing new presets in /etc which enables the chosen dm
 and disable other, then reloading preset file to reset that
 display-manager.service alias?

Hmm, I am pretty sure interactive updates are a bad idea. But then
again, I know that Debian likes them.

I think, if you install something new that conflicts with something
installed, then you should enable it if the policy says so and if the
existing package isn't enabled already. But if it is already enabled,
or if the policy says no, then leave it alone.

If you really want an UI in the mix here, I'd recommend just altering
the symlinks directly. (I mean, altering the symlinks manually is
completely OK. systemctl enable/disable/preset is simply supposed to
be a nicer helper there, but in no way should be the exclusive way to
access them).

 I don't think we should have systemctl preset new_service running under
 any condition as a wipe of /etc and then systemctl preset-all would give a
 potential different result (I'm not even sure how this will work with those
 alias, the first matching the alias wins and get the symlinks?)
 Dont follow? wipe?
 
 I meant deleting the entire /etc content (or I guess as you told using
 systemctl preset-all to reset to default):
 
 1. lightdm and gdm were installed on my system.
 2. gdm was enabled as the default display-manager.
 3. I then use systemctl preset-all
 - how the behavior of selecting the display-manager will be determined? See
 below implementing this with presets where enabling all services is the
 default.

Hmm, this is actually undefined currently. THe code for preset-all
iterates through the unit paths and processes the files in the order
they are read by readdir(), which is pretty much undefined. We really
should investigate what to do about that. Probably just order things
lexicographically. I added this to the TODO list for now.

 We can of course have an ubuntu-desktop.preset which disables all dms by
 lightdm, and an ubuntu-gnome.preset which disables all dms but gdm (and
 having those settings conflicting with each other), but it's seems that for
 every aliases, we need to maintain such a list (as we enable * by
 default)?
 Not following here. Different flavours of Ubuntu should probably just
 ship different preset files. (Or well, the main ubuntu should ship one
 that enables lightdm, and then the gnome flavour ship another preset
 file, with a lower name, tht overrides the lightdm line, and enables
 gdm instead).
 
 You meant disable, right? As our default is to enable all services.

Yeah, overrides meant disabling.

 So we need for any services shipping Aliases to have a preset list per
 flavor (if their behaviors differs) with:
 99-ubuntu-desktop.preset:
 enable lightdm.service
 disable kdm.service
 disable gdm.service
 disable nodm.service
 (and whatnot… dm files in distro)

Hmm, indeed I guess...

 Then, we would have 01-ubuntu-gnome.preset:
 enable gdm.service
 disable lightdm.service
 disable kdm.service
 …
 
 It seems maintaining this list in sync for all flavors would be a growing
 pain (this is a positive effect of the disable by default: you don't have to
 maintain such a list), or do you think we can come with something
 better?

Hmm, yuck. No good suggestion. I figure this problem doesn't exist
with the fedora default of everything is disabled by default...

All open to ideas...

 Finally, on the know what the administrator did on this machine, here are
 two cases that we can identify:
 
 I. if the administrator removes the service package, we usually keep current
 service state (enabled/disabled) on reinstall.
 So:
 foo.service enabled by default
 1.

Re: [systemd-devel] /usr vs /etc for default distro units enablement

On Tue, 02.12.14 20:02, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:

 On Tue, 2014-12-02 at 01:51 +0100, Lennart Poettering wrote:
  On Tue, 18.11.14 16:09, Michael Biebl (mbi...@gmail.com) wrote:
  
   2014-11-18 15:59 GMT+01:00 Colin Guthrie gm...@colin.guthr.ie:
For the avoidance of doubt, I believe that running systemctl preset
should only ever happen on *first* install, never on upgrade or such 
like.
   
   
   And what are you going to do, if the unit file changes?
   Say v1  had
   
   [Install]
   WantedBy=multi-user.target
   
   and version B has
   [Install]
   WantedBy=foo.target
  
  Package installs should probably not try to do something about this
  case, just leave things as is.
 
 I think this would be a very bad idea. Installing a system and then
 upgrading it should give you the same state as installing a newer system
 directly; silently leaving outdated configuration in use almost ensures
 that systems will fail/degrade over time.

Well, things are not that easy.

If distro Foobarix decides one day that from this day on sendmail
should be enabled again by default, what is the right upgrade path
for old installs? Should it be enabled now, because that's the new
default for new installs? Or should it stay disabled, since that's
what the user is accustomed to?

I am pretty sure the latter. 

I mean, of course, you can play games and try to guess if sendmail was
off when the upgrade took place simply because that used to be the
default, or because the user/admin really didn't want it to run, which
just accidentally happened to be the default. You have a 50/50 chance
to win this guess, which makes the excercise quite moot I'd say.

I'd really be conservative here: optional things that change their
default should be left as is on updates.

Of course, if something starts to be a necessity that wasn't one
strictly necessary then one should do something about this, but
usually in that case this would be a move from systemctl enable
units towards statically enabled ones anyway. But again: if something
was optional before, and is optional after, then be conservative,
don't change things...

  I mean, let's not forget that admins should be able to define their
  own targets and then enabled units in them and disable them
  elsewhere. Package upgrades should not manipulate that. The first
  installation of a package should enable a unit if that's what the
  preset policy says, but from that point on the configuration is admin
  configuration and not be changed anymore automatically.
 
 It's theoretically possible that the admin could have moved it to a
 different target, but that's the exception. The system should still
 sanely handle the normal case where the admin has changed nothing, and
 in that case leaving the unit in its original target is completely
 wrong.
 
 For example, if you move a unit from sysinit.target to multi-user.target
 and remove DefaultDependencies=no from the .service file, then leaving
 the installed symlink for sysinit.target will cause a dependency
 loop.

Sure, if you know that changes in your unit files actively break a
previous default, then you should do something about it, but I think
cases like this are best handled with careful, manually written
postinst scripts, that do the right thing in the most defensive
possible way. But blindly enabling all kinds of stuff just because the
upstream default changed is really not a good idea I think.

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-nspawn@.service is unusable