Re: [systemd-devel] Systemd-nspawn -- Canot add interface to container

2014-09-26 Thread James Lott 
Hello again!

Once again, thanks for all the help with getting my wireless interface moved 
into the container! Now I just have one more interface I'm having trouble 
with. I can't seem to move my ethernet interfaces into the container. I'm 
getting the same error, so I presume it's for the same reason. I can find the 
path to my physical devices in kernel space (they're both on a USB bus), but I 
can't figure out what device name I should pass to systemd-nspawn (or what 
other userspace program I could use to move one of the interfaces into a 
container's namespace). Thanks in advance for any pointers!

[root@host01 lanvpn]# systemd-nspawn --network-interface=eth1   
Spawning container lanvpn on /home/lanvpn.
Press ^] three times within 1s to kill container.
Failed to move interface eth1 to namespace: File exists
[root@host01 lanvpn]# ls -lah /sys/class/net/ | egrep 'eth[0-1] '   

 
lrwxrwxrwx  1 root root 0 Dec 31  1969 eth0 -> 
../../devices/platform/bcm2708_usb/usb1/1-1/1-1.1/1-1.1:1.0/net/eth0
lrwxrwxrwx  1 root root 0 Dec 31  1969 eth1 -> 
../../devices/platform/bcm2708_usb/usb1/1-1/1-1.3/1-1.3.1/1-1.3.1:1.0/net/eth1

On Thursday 25 September 2014 17:05:34 James Lott wrote:
> Shame on me for not spending more time trying to figure this out before
> responding. Please ignore my previous sad plea for help, I understand fully
> now exactly what you're saying, and was able to successfully move the phy0
> interface into my container.
> 
> At this point, my challenge is going to be coordinating the movement of this
> interface within a service file, so I don't need to do it manually when
> starting the container... but I suppose I can write an ExecStartPost script
> which can manage this.
> 
> Thanks again for all your help!
> 
> On Thursday 25 September 2014 16:25:02 James Lott wrote:
> > Hi Zbyszek,
> > 
> > Thanks for all your help! This is a new concept to me though, as I have
> > never tried to refer to a process inside of a container from outside of
> > the
> > container before (I did not realize this was possible). Since specifying
> > PID 1 would obviously be referring to the host system's init process,
> > would
> > you be willing to give me an example that might help me understand how I
> > can specify an in-container PID from the host system? Thanks again for
> > taking the time to help me grasp all of this :)
> > 
> > > On Sep 25, 2014, at 2:10 PM, Zbigniew Jędrzejewski-Szmek
> 
>  wrote:
> > >> On Thu, Sep 25, 2014 at 10:40:42AM -0700, James Lott wrote:
> > >> Hi Mantas,
> > >> 
> > >> Thanks for the clarification. The first thing I tried actually was
> > >> using
> > >> the PID of the systemd-nspawn instance, like so
> > >> 
> > >> [root@host01 lanvpn]# ps aux | grep -v grep | grep systemd-nspawn
> > >> root   143  0.0  0.3   2884   728 ?Ss   08:42   0:00
> > >> /usr/bin/systemd-nspawn --network-bridge=switch1 -bD /home/proxy -M 0
> > >> root  4564  0.7  0.6   2884  1124 pts/3S+   10:38   0:00
> > >> systemd-
> > >> nspawn --private-network
> > >> [root@host01 lanvpn]# iw phy phy0 set netns 4564
> > > 
> > > systemd-nspawn is *outside* of the container. You should use the child
> > > of
> > > systemd-nspawn, i.e. the init process, instead.
> > > 
> > > Zbyszek
> > 
> > ___
> > 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 2/3] bootchart: check return of strftime

2014-09-26 Thread Zbigniew Jędrzejewski-Szmek 
On Fri, Sep 26, 2014 at 10:01:31PM +0200, Thomas H.P. Andersen wrote:
> From: Thomas Hindoe Paaboel Andersen 
> 
> Found by coverity. Fixes: CID#996314 and #996312
> ---
>  src/bootchart/bootchart.c | 14 --
>  src/bootchart/svg.c   |  6 --
>  2 files changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/src/bootchart/bootchart.c b/src/bootchart/bootchart.c
> index 8ef5ad1..e127ad3 100644
> --- a/src/bootchart/bootchart.c
> +++ b/src/bootchart/bootchart.c
> @@ -389,7 +389,12 @@ int main(int argc, char *argv[]) {
>  
>  if (!of && (access(arg_output_path, R_OK|W_OK|X_OK) == 0)) {
>  t = time(NULL);
> -strftime(datestr, sizeof(datestr), "%Y%m%d-%H%M", 
> localtime(&t));
> +r = strftime(datestr, sizeof(datestr), 
> "%Y%m%d-%H%M", localtime(&t));
> +if (r <= 0) {
> +log_error("Failed to format time.");
> +return EXIT_FAILURE;
> +}

We don't expect this to fail, ever. Maybe assert_se() would be better?

(Likewise below and for the next patch...)

Zbyszek


> +
>  snprintf(output_file, PATH_MAX, 
> "%s/bootchart-%s.svg", arg_output_path, datestr);
>  of = fopen(output_file, "we");
>  }
> @@ -457,7 +462,12 @@ int main(int argc, char *argv[]) {
>  
>  if (!of) {
>  t = time(NULL);
> -strftime(datestr, sizeof(datestr), "%Y%m%d-%H%M", 
> localtime(&t));
> +r = strftime(datestr, sizeof(datestr), "%Y%m%d-%H%M", 
> localtime(&t));
> +if (r <= 0) {
> +log_error("Failed to format time.");
> +return EXIT_FAILURE;
> +}
> +
>  snprintf(output_file, PATH_MAX, "%s/bootchart-%s.svg", 
> arg_output_path, datestr);
>  of = fopen(output_file, "we");
>  }
> diff --git a/src/bootchart/svg.c b/src/bootchart/svg.c
> index 135883f..cb58246 100644
> --- a/src/bootchart/svg.c
> +++ b/src/bootchart/svg.c
> @@ -162,7 +162,7 @@ static void svg_title(const char *build) {
>  char *c;
>  FILE *f;
>  time_t t;
> -int fd;
> +int fd, r;
>  struct utsname uts;
>  
>  /* grab /proc/cmdline */
> @@ -196,7 +196,9 @@ static void svg_title(const char *build) {
>  
>  /* date */
>  t = time(NULL);
> -strftime(date, sizeof(date), "%a, %d %b %Y %H:%M:%S %z", 
> localtime(&t));
> +r = strftime(date, sizeof(date), "%a, %d %b %Y %H:%M:%S %z", 
> localtime(&t));
> +if (r <= 0)
> +fprintf(stderr, "Failed to format time\n");
>  
>  /* CPU type */
>  fd = openat(procfd, "cpuinfo", O_RDONLY);
> -- 
> 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 1/3] bootchart: parse userinput with safe_atoi

2014-09-26 Thread Zbigniew Jędrzejewski-Szmek 
On Fri, Sep 26, 2014 at 10:01:30PM +0200, Thomas H.P. Andersen wrote:
> From: Thomas Hindoe Paaboel Andersen 
> 
> Found by coverity. Fixes: CID#996409
> ---
>  src/bootchart/store.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/src/bootchart/store.c b/src/bootchart/store.c
> index ed683e8..3099ff1 100644
> --- a/src/bootchart/store.c
> +++ b/src/bootchart/store.c
> @@ -192,12 +192,14 @@ vmstat_next:
>  
>  m = buf;
>  while (m) {
> +int r;
> +
>  if (sscanf(m, "%s %*s %*s %*s %*s %*s %*s %s %s", key, rt, 
> wt) < 3)
>  goto schedstat_next;
>  
>  if (strstr(key, "cpu")) {
> -c = atoi((const char*)(key+3));
> -if (c > MAXCPUS)
> +r = safe_atoi((const char*)(key+3), &c);
> +if (r < 0 || c > MAXCPUS)
>  /* Oops, we only have room for MAXCPUS data 
> */
>  break;
>  sampledata->runtime[c] = atoll(rt);
Looks OK.

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

[systemd-devel] [PATCH] sd-dhcp-client: support non-Ethernet hardware addresses

2014-09-26 Thread Dan Williams 
Like Infiniband.  See RFC 4390 section 2.1 for details on DHCP
and Infiniband; chaddr is zeroed, hlen is set to 0, and htype
is set to ARPHRD_INFINIBAND because IB hardware addresses
are 20 bytes in length.
---
 src/libsystemd-network/dhcp-internal.h| 10 +++--
 src/libsystemd-network/dhcp-network.c | 54 -
 src/libsystemd-network/dhcp-packet.c  |  8 ++--
 src/libsystemd-network/sd-dhcp-client.c   | 66 +++
 src/libsystemd-network/sd-dhcp-server.c   |  8 ++--
 src/libsystemd-network/test-dhcp-client.c | 14 +--
 src/libsystemd-network/test-dhcp-option.c |  2 +-
 src/network/networkd-dhcp4.c  |  4 +-
 src/network/networkd-link.c   |  4 +-
 src/systemd/sd-dhcp-client.h  |  4 +-
 10 files changed, 130 insertions(+), 44 deletions(-)

*** Testing appreciated

diff --git a/src/libsystemd-network/dhcp-internal.h 
b/src/libsystemd-network/dhcp-internal.h
index 1069c8a..d358a49 100644
--- a/src/libsystemd-network/dhcp-internal.h
+++ b/src/libsystemd-network/dhcp-internal.h
@@ -20,22 +20,25 @@
 
   You should have received a copy of the GNU Lesser General Public License
   along with systemd; If not, see .
 ***/
 
 #include 
 #include 
+#include 
 #include 
 
 #include "socket-util.h"
 
 #include "sd-dhcp-client.h"
 #include "dhcp-protocol.h"
 
-int dhcp_network_bind_raw_socket(int index, union sockaddr_union *link, 
uint32_t xid, struct ether_addr mac_addr);
+int dhcp_network_bind_raw_socket(int index, union sockaddr_union *link,
+ uint32_t xid, const uint8_t *mac_addr,
+ size_t mac_addr_len, uint16_t arp_type);
 int dhcp_network_bind_udp_socket(be32_t address, uint16_t port);
 int dhcp_network_send_raw_socket(int s, const union sockaddr_union *link,
  const void *packet, size_t len);
 int dhcp_network_send_udp_socket(int s, be32_t address, uint16_t port,
  const void *packet, size_t len);
 
 int dhcp_option_append(DHCPMessage *message, size_t size, size_t *offset, 
uint8_t overload,
@@ -43,16 +46,17 @@ int dhcp_option_append(DHCPMessage *message, size_t size, 
size_t *offset, uint8_
 
 typedef int (*dhcp_option_cb_t)(uint8_t code, uint8_t len,
 const uint8_t *option, void *user_data);
 
 int dhcp_option_parse(DHCPMessage *message, size_t len,
   dhcp_option_cb_t cb, void *user_data);
 
-int dhcp_message_init(DHCPMessage *message, uint8_t op, uint32_t xid, uint8_t 
type,
-  size_t optlen, size_t *optoffset);
+int dhcp_message_init(DHCPMessage *message, uint8_t op, uint32_t xid,
+  uint8_t type, uint16_t arp_type, size_t optlen,
+  size_t *optoffset);
 
 uint16_t dhcp_packet_checksum(uint8_t *buf, size_t len);
 
 void dhcp_packet_append_ip_headers(DHCPPacket *packet, be32_t source_addr,
uint16_t source, be32_t destination_addr,
uint16_t destination, uint16_t len);
 
diff --git a/src/libsystemd-network/dhcp-network.c 
b/src/libsystemd-network/dhcp-network.c
index 1ced5cf..29e9993 100644
--- a/src/libsystemd-network/dhcp-network.c
+++ b/src/libsystemd-network/dhcp-network.c
@@ -18,27 +18,31 @@
 ***/
 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 
 #include "socket-util.h"
 
 #include "dhcp-internal.h"
 
-int dhcp_network_bind_raw_socket(int ifindex, union sockaddr_union *link,
- uint32_t xid, struct ether_addr mac_addr) {
-
+static int _bind_raw_socket(int ifindex, union sockaddr_union *link,
+uint32_t xid, const uint8_t *mac_addr,
+size_t mac_addr_len,
+const uint8_t *bcast_addr,
+const struct ether_addr *eth_mac,
+uint16_t arp_type, uint8_t dhcp_hlen) {
 struct sock_filter filter[] = {
 BPF_STMT(BPF_LD + BPF_W + BPF_LEN, 0), 
/* A <- packet length */
 BPF_JUMP(BPF_JMP + BPF_JGE + BPF_K, sizeof(DHCPPacket), 1, 0), 
/* packet >= DHCPPacket ? */
 BPF_STMT(BPF_RET + BPF_K, 0),  
/* ignore */
 BPF_STMT(BPF_LD + BPF_B + BPF_ABS, offsetof(DHCPPacket, 
ip.protocol)), /* A <- IP protocol */
 BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, IPPROTO_UDP, 1, 0),
/* IP protocol == UDP ? */
 BPF_STMT(BPF_RET + BPF_K, 0),  
/* ignore */
@@ -53,29 +57,29 @@ int dhcp_network_bind_raw_socket(int ifindex, union 
sockaddr_union *link,
 BPF_STMT(BPF_LD + BPF_H + BPF_ABS, offsetof(DHCPPacket, 
udp.dest)),/* A <- U

[systemd-devel] [PATCH] sd-dhcp6-client: support custom DUIDs

2014-09-26 Thread Dan Williams 
The caller may have an existing DUID that it wants to use, and may
want to use some other DUID generation scheme than systemd's
default DUID-EN.
---
 src/libsystemd-network/sd-dhcp6-client.c | 43 +++-
 src/systemd/sd-dhcp6-client.h|  2 ++
 2 files changed, 33 insertions(+), 12 deletions(-)

diff --git a/src/libsystemd-network/sd-dhcp6-client.c 
b/src/libsystemd-network/sd-dhcp6-client.c
index c190b56..87a3198 100644
--- a/src/libsystemd-network/sd-dhcp6-client.c
+++ b/src/libsystemd-network/sd-dhcp6-client.c
@@ -35,14 +35,16 @@
 #include "dhcp6-protocol.h"
 #include "dhcp6-internal.h"
 #include "dhcp6-lease-internal.h"
 
 #define SYSTEMD_PEN 43793
 #define HASH_KEY SD_ID128_MAKE(80,11,8c,c2,fe,4a,03,ee,3e,d6,0c,6f,36,39,14,09)
 
+#define MAX_DUID_LEN 32
+
 struct sd_dhcp6_client {
 RefCount n_ref;
 
 enum DHCP6State state;
 sd_event *event;
 int event_priority;
 int index;
@@ -58,20 +60,16 @@ struct sd_dhcp6_client {
 sd_event_source *receive_message;
 usec_t retransmit_time;
 uint8_t retransmit_count;
 sd_event_source *timeout_resend;
 sd_event_source *timeout_resend_expire;
 sd_dhcp6_client_cb_t cb;
 void *userdata;
-
-struct duid_en {
-uint16_t type; /* DHCP6_DUID_EN */
-uint32_t pen;
-uint8_t id[8];
-} _packed_ duid;
+uint8_t duid[MAX_DUID_LEN];
+size_t duid_len;
 };
 
 static const uint16_t default_req_opts[] = {
 DHCP6_OPTION_DNS_SERVERS,
 DHCP6_OPTION_DOMAIN_LIST,
 DHCP6_OPTION_NTP_SERVER,
 };
@@ -143,14 +141,27 @@ int sd_dhcp6_client_set_mac(sd_dhcp6_client *client,
 memcpy(&client->mac_addr, mac_addr, sizeof(client->mac_addr));
 else
 memset(&client->mac_addr, 0x00, sizeof(client->mac_addr));
 
 return 0;
 }
 
+int sd_dhcp6_client_set_duid(sd_dhcp6_client *client, uint8_t *duid,
+ size_t duid_len)
+{
+assert_return(client, -EINVAL);
+assert_return(duid, -EINVAL);
+assert_return(duid_len > 0 && duid_len <= MAX_DUID_LEN, -EINVAL);
+
+memcpy(&client->duid, duid, duid_len);
+client->duid_len = duid_len;
+
+   return 0;
+}
+
 int sd_dhcp6_client_set_request_option(sd_dhcp6_client *client,
uint16_t option) {
 size_t t;
 
 assert_return(client, -EINVAL);
 assert_return(client->state == DHCP6_STATE_STOPPED, -EBUSY);
 
@@ -304,15 +315,15 @@ static int client_send_message(sd_dhcp6_client *client, 
usec_t time_now) {
 r = dhcp6_option_append(&opt, &optlen, DHCP6_OPTION_ORO,
 client->req_opts_len * sizeof(be16_t),
 client->req_opts);
 if (r < 0)
 return r;
 
 r = dhcp6_option_append(&opt, &optlen, DHCP6_OPTION_CLIENTID,
-sizeof(client->duid), &client->duid);
+client->duid_len, &client->duid);
 if (r < 0)
 return r;
 
 elapsed_usec = time_now - client->transaction_start;
 if (elapsed_usec < 0x * USEC_PER_MSEC * 10)
 elapsed_time = htobe16(elapsed_usec / USEC_PER_MSEC / 10);
 else
@@ -612,15 +623,15 @@ static int client_parse_message(sd_dhcp6_client *client,
 case DHCP6_OPTION_CLIENTID:
 if (clientid) {
 log_dhcp6_client(client, "%s contains multiple 
clientids",
  
dhcp6_message_type_to_string(message->type));
 return -EINVAL;
 }
 
-if (optlen != sizeof(client->duid) ||
+if (optlen != client->duid_len ||
 memcmp(&client->duid, optval, optlen) != 0) {
 log_dhcp6_client(client, "%s DUID does not 
match",
  
dhcp6_message_type_to_string(message->type));
 
 return -EINVAL;
 }
 clientid = true;
@@ -1112,17 +1123,24 @@ sd_dhcp6_client *sd_dhcp6_client_unref(sd_dhcp6_client 
*client) {
 
 return NULL;
 }
 
 return client;
 }
 
+struct duid_en {
+uint16_t type; /* DHCP6_DUID_EN */
+uint32_t pen;
+uint8_t id[8];
+} _packed_;
+
 int sd_dhcp6_client_new(sd_dhcp6_client **ret)
 {
 _cleanup_dhcp6_client_unref_ sd_dhcp6_client *client = NULL;
+struct duid_en *duid;
 sd_id128_t machine_id;
 int r;
 size_t t;
 
 assert_return(ret, -EINVAL);
 
 client = new0(sd_dhcp6_client, 1);
@@ -1134,25 +1152,26 @@ int sd_dhcp6_client_new(sd_dhcp6_client **ret)
 client->

Re: [systemd-devel] [PATCH 1/3] bootchart: parse userinput with safe_atoi

2014-09-26 Thread Thomas H.P. Andersen 
Hi,

I am sending these small fixes for issues found with coverity for
review. I think that they are good to commit but I am sending them
here anyway because I cannot test them. My attempts to boot with
init=/usr/lib/systemd/systemd-bootchart hangs while starting udev.
Both with master, master + my changes, and also with the version
installed with fedora 21.

- Thomas

On Fri, Sep 26, 2014 at 10:01 PM, Thomas H.P. Andersen  wrote:
> From: Thomas Hindoe Paaboel Andersen 
>
> Found by coverity. Fixes: CID#996409
> ---
>  src/bootchart/store.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/src/bootchart/store.c b/src/bootchart/store.c
> index ed683e8..3099ff1 100644
> --- a/src/bootchart/store.c
> +++ b/src/bootchart/store.c
> @@ -192,12 +192,14 @@ vmstat_next:
>
>  m = buf;
>  while (m) {
> +int r;
> +
>  if (sscanf(m, "%s %*s %*s %*s %*s %*s %*s %s %s", key, rt, 
> wt) < 3)
>  goto schedstat_next;
>
>  if (strstr(key, "cpu")) {
> -c = atoi((const char*)(key+3));
> -if (c > MAXCPUS)
> +r = safe_atoi((const char*)(key+3), &c);
> +if (r < 0 || c > MAXCPUS)
>  /* Oops, we only have room for MAXCPUS data 
> */
>  break;
>  sampledata->runtime[c] = atoll(rt);
> --
> 2.1.0
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH 3/3] bootchart: use 'n/a' if PRETTY_NAME is not found

2014-09-26 Thread Thomas H.P. Andersen 
From: Thomas Hindoe Paaboel Andersen 

Spotted with coverity. If parsing both /etc/os-release and
/usr/lib/os-release fails then null would be passed on. The calls
to parse the two files are allowed to fail. A empty /etc may not
have had the /etc/os-release symlink restored yet and we just
try again in the loop. If for whatever reason that does not happen
then we now pass on 'n/a' instead of null.
---
 src/bootchart/bootchart.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/bootchart/bootchart.c b/src/bootchart/bootchart.c
index e127ad3..a359307 100644
--- a/src/bootchart/bootchart.c
+++ b/src/bootchart/bootchart.c
@@ -477,7 +477,7 @@ int main(int argc, char *argv[]) {
 exit (EXIT_FAILURE);
 }
 
-svg_do(build);
+svg_do(strna(build));
 
 fprintf(stderr, "systemd-bootchart wrote %s\n", output_file);
 
-- 
2.1.0

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

[systemd-devel] [PATCH 2/3] bootchart: check return of strftime

2014-09-26 Thread Thomas H.P. Andersen 
From: Thomas Hindoe Paaboel Andersen 

Found by coverity. Fixes: CID#996314 and #996312
---
 src/bootchart/bootchart.c | 14 --
 src/bootchart/svg.c   |  6 --
 2 files changed, 16 insertions(+), 4 deletions(-)

diff --git a/src/bootchart/bootchart.c b/src/bootchart/bootchart.c
index 8ef5ad1..e127ad3 100644
--- a/src/bootchart/bootchart.c
+++ b/src/bootchart/bootchart.c
@@ -389,7 +389,12 @@ int main(int argc, char *argv[]) {
 
 if (!of && (access(arg_output_path, R_OK|W_OK|X_OK) == 0)) {
 t = time(NULL);
-strftime(datestr, sizeof(datestr), "%Y%m%d-%H%M", 
localtime(&t));
+r = strftime(datestr, sizeof(datestr), "%Y%m%d-%H%M", 
localtime(&t));
+if (r <= 0) {
+log_error("Failed to format time.");
+return EXIT_FAILURE;
+}
+
 snprintf(output_file, PATH_MAX, "%s/bootchart-%s.svg", 
arg_output_path, datestr);
 of = fopen(output_file, "we");
 }
@@ -457,7 +462,12 @@ int main(int argc, char *argv[]) {
 
 if (!of) {
 t = time(NULL);
-strftime(datestr, sizeof(datestr), "%Y%m%d-%H%M", 
localtime(&t));
+r = strftime(datestr, sizeof(datestr), "%Y%m%d-%H%M", 
localtime(&t));
+if (r <= 0) {
+log_error("Failed to format time.");
+return EXIT_FAILURE;
+}
+
 snprintf(output_file, PATH_MAX, "%s/bootchart-%s.svg", 
arg_output_path, datestr);
 of = fopen(output_file, "we");
 }
diff --git a/src/bootchart/svg.c b/src/bootchart/svg.c
index 135883f..cb58246 100644
--- a/src/bootchart/svg.c
+++ b/src/bootchart/svg.c
@@ -162,7 +162,7 @@ static void svg_title(const char *build) {
 char *c;
 FILE *f;
 time_t t;
-int fd;
+int fd, r;
 struct utsname uts;
 
 /* grab /proc/cmdline */
@@ -196,7 +196,9 @@ static void svg_title(const char *build) {
 
 /* date */
 t = time(NULL);
-strftime(date, sizeof(date), "%a, %d %b %Y %H:%M:%S %z", 
localtime(&t));
+r = strftime(date, sizeof(date), "%a, %d %b %Y %H:%M:%S %z", 
localtime(&t));
+if (r <= 0)
+fprintf(stderr, "Failed to format time\n");
 
 /* CPU type */
 fd = openat(procfd, "cpuinfo", O_RDONLY);
-- 
2.1.0

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

[systemd-devel] [PATCH 1/3] bootchart: parse userinput with safe_atoi

2014-09-26 Thread Thomas H.P. Andersen 
From: Thomas Hindoe Paaboel Andersen 

Found by coverity. Fixes: CID#996409
---
 src/bootchart/store.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/src/bootchart/store.c b/src/bootchart/store.c
index ed683e8..3099ff1 100644
--- a/src/bootchart/store.c
+++ b/src/bootchart/store.c
@@ -192,12 +192,14 @@ vmstat_next:
 
 m = buf;
 while (m) {
+int r;
+
 if (sscanf(m, "%s %*s %*s %*s %*s %*s %*s %s %s", key, rt, wt) 
< 3)
 goto schedstat_next;
 
 if (strstr(key, "cpu")) {
-c = atoi((const char*)(key+3));
-if (c > MAXCPUS)
+r = safe_atoi((const char*)(key+3), &c);
+if (r < 0 || c > MAXCPUS)
 /* Oops, we only have room for MAXCPUS data */
 break;
 sampledata->runtime[c] = atoll(rt);
-- 
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-09-26 Thread Kay Sievers 
On Fri, Sep 26, 2014 at 6:14 PM, Tomas Henzl  wrote:
> I haven't noticed a single one technical reason why the by-path should be 
> moved out
> from udev and not fixed there when it's needed and most importantly how that 
> move
> would help the users of this feature.

Because it was changed several times already in the past, and it seems
people cannot make up their mind what is right here.

> The only point I can understand is that you don't like storage related code 
> in udev
> because you don't understand it and so you don't want to maintain it.
> I could try to explain that in case of any issues you may seek help in the 
> scsi-misc list,
> but well ok it's your decision.

Exactly, even the people involved doing the code seem to have problems
to sort it out. This code and use case is just too specific and a
niche, it should not be maintained in systemd/udev but in a separate
package where someone else takes the responsibility for it.

> This is I think by far not the last storage related code in udev, do you want 
> to
> remove the other parts too, like the by-uuid and the other by-* obvious 
> candidates ?

The generic, well-defined and generally useful parts like filesystem,
partition table properties, WWN IDs, ... will stay.

SCSI IDs will move to sg3_util. Specific ATA stuff and the rest of the
overly complex enterprise storage stuff will need a new home.

Kay
___
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-09-26 Thread Tomas Henzl 
On 09/25/2014 05:07 PM, Kay Sievers wrote:
> On Thu, Sep 25, 2014 at 1:57 PM, Tomas Henzl  wrote:
>> On 09/24/2014 05:03 PM, Kay Sievers wrote:
> Simple as: Don't add new features to systemd/udev, only fix bugs.
>> The by-path has been part of udev for a long time, the users of this
>> feature are from the same camp as the users of the,
>> 'enterprise storage'. Everyone has been happily using it,
>> until someone found out that the values shown are incorrect.
>> The patch posted here corrects the values so it can work as expected.
>> You probably were confused by something, but this is _not_ a new feature
>> it's a obvious bug fix.
>>
>> Please consider again inclusion of this patch.
> Sorry, we are better not changing the current, and possibly used link names.
> They are created that way since a long time and nobody knows who uses
> the current ones.
>
> Adding additional infrastructure to create more than one by-path link would
> be a new feature, which we will for various mentioned reasons not add to
> the current code, but which needs to happen in an external package,
> maintained/reviewed by someone with an enterprise-storage background
> and not live in the systemd code base.

I haven't noticed a single one technical reason why the by-path should be moved 
out
from udev and not fixed there when it's needed and most importantly how that 
move
would help the users of this feature.
The only point I can understand is that you don't like storage related code in 
udev
because you don't understand it and so you don't want to maintain it. 
I could try to explain that in case of any issues you may seek help in the 
scsi-misc list,
but well ok it's your decision.

This is I think by far not the last storage related code in udev, do you want to
remove the other parts too, like the by-uuid and the other by-* obvious 
candidates ?

Thanks,
Tomas

>
> I hope you understand the reasoning,
> Kay

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

Re: [systemd-devel] [RESEND][PATCH] systemd-tmpfiles: Fix IGNORE_DIRECTORY_PATH age handling

2014-09-26 Thread Tom Gundersen 
On Fri, Sep 26, 2014 at 12:46 PM, Richard Weinberger  wrote:
> Am 09.09.2014 11:09, schrieb Richard Weinberger:
>> If one has a config like:
>> d /tmp 1777 root root -
>> X /tmp/important_mount
>>
>> All files below /tmp/important_mount will be deleted as the
>> /tmp/important_mount item will spuriously inherit a max age of 0
>> from /tmp.
>> /tmp has a max age of 0 but age_set is (of course) false.
>>
>> This affects also the PrivateTmp feature of systemd.
>> All tmp files of such services will be deleted unconditionally
>> and can cause service failures and data loss.
>>
>> Fix this by checking ->age_set in the IGNORE_DIRECTORY_PATH logic.
>> ---
>>  src/tmpfiles/tmpfiles.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
>> index 79fd0b7..c8d4abb 100644
>> --- a/src/tmpfiles/tmpfiles.c
>> +++ b/src/tmpfiles/tmpfiles.c
>> @@ -1572,7 +1572,7 @@ static int read_config_file(const char *fn, bool 
>> ignore_enoent) {
>>  candidate_item = j;
>>  }
>>
>> -if (candidate_item) {
>> +if (candidate_item && candidate_item->age_set) {
>>  i->age = candidate_item->age;
>>  i->age_set = true;
>>  }
>>
>
> ping?
>
> Is there something horrible wrong with this patch or the submission itself?
> Please tell me. :)

Hi Richard,

Sorry for the delay in getting back to you!

Patch looks good. Applied.

Thanks!

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

Re: [systemd-devel] [systemd-commits] src/bus-proxyd test/bus-policy

2014-09-26 Thread Daniel Mack 
On 09/26/2014 01:16 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Sep 26, 2014 at 10:24:25AM +0200, Daniel Mack wrote:
>> On 09/26/2014 05:05 AM, Zbigniew Jędrzejewski-Szmek wrote:
>>> Hi,
>>> test-bus-policy fails intermittently in 'make distcheck'
>>>
>>> FAIL: test-bus-policy
>>> =
>>>
>>> Assertion 'policy_check_own(&p, &ucred, "org.test.test1") == true' failed 
>>> at ../src/bus-proxyd/test-bus-policy.c:58,
>>>  function main(). Aborting.
>>
>> Hmm. I don't see this here. What kind of setup are you running this on?
>> We make certain assumptions on existing users/groups on the target
>> system, and I'm not sure whether we should do that. Are uid/gid 1 valid
>> on your system?
> It only seems to fail inside distcheck, so it might be some race
> condition.

Hmm, no. I see it now. It's because distcheck calls test-bus-policy with
a relative path, and hence the policy file load fails.

I'm working on a fix for this.


Thanks,
Daniel

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

Re: [systemd-devel] [PATCH 1/7] make utmp/wtmp support configurable

2014-09-26 Thread Zbigniew Jędrzejewski-Szmek 
On Fri, Sep 26, 2014 at 10:00:30AM +0200, Emil Renner Berthing wrote:
> On 26 September 2014 04:43, Zbigniew Jędrzejewski-Szmek
>  wrote:
> > On Wed, Sep 24, 2014 at 05:25:00PM +0200, Emil Renner Berthing wrote:
> >> For now just stub out the functions in utmp-wtmp.h
> >> so code will still compile. These stubs will be
> >> removed in the last commit in this patch series.
> >> ---
> >>  Makefile.am | 34 
> >> +++---
> >>  configure.ac| 11 +++
> >>  man/runlevel.xml|  3 ++-
> >>  man/systemd-update-utmp.service.xml |  2 +-
> >>  src/core/build.h|  7 +++
> >>  src/shared/utmp-wtmp.h  | 28 
> >>  6 files changed, 76 insertions(+), 9 deletions(-)
> > Hm, I understand why this is wanted, but the approach is rather intrusive.
> > Can you instead modify utmp-wtmp.c to provide noop stubs when utmp
> > is disabled? Other places should simply call the utmp_* functions as before.
> > Possibly if there are other places where significant prepration is
> > done before calling utmp_*, like server_forward_wall, stub implementations
> > could be provided too, but only if it seems to make a significant difference
> > at runtime. In general please try to minimize ifdefs, we have too many
> > of those already.
> 
> This is exactly the approach taken in this first patch, except it uses
> static inline stubs in the header file. This is better, since is lets the
> compiler see that the functions doesn't do anything and in many
> cases it can compile out more code.
OK, I pushed 1/7 with some small changes. Most people are still going to compile
with utmp support, though.

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

Re: [systemd-devel] [systemd-commits] src/bus-proxyd test/bus-policy

2014-09-26 Thread Zbigniew Jędrzejewski-Szmek 
On Fri, Sep 26, 2014 at 10:24:25AM +0200, Daniel Mack wrote:
> On 09/26/2014 05:05 AM, Zbigniew Jędrzejewski-Szmek wrote:
> > Hi,
> > test-bus-policy fails intermittently in 'make distcheck'
> > 
> > FAIL: test-bus-policy
> > =
> > 
> > Assertion 'policy_check_own(&p, &ucred, "org.test.test1") == true' failed 
> > at ../src/bus-proxyd/test-bus-policy.c:58,
> >  function main(). Aborting.
> 
> Hmm. I don't see this here. What kind of setup are you running this on?
> We make certain assumptions on existing users/groups on the target
> system, and I'm not sure whether we should do that. Are uid/gid 1 valid
> on your system?
It only seems to fail inside distcheck, so it might be some race
condition. I'm running this on fairly normal F20 machine:

bin:x:1:1:bin:/bin:/sbin/nologin

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

Re: [systemd-devel] [RESEND][PATCH] systemd-tmpfiles: Fix IGNORE_DIRECTORY_PATH age handling

2014-09-26 Thread Richard Weinberger 
Am 09.09.2014 11:09, schrieb Richard Weinberger:
> If one has a config like:
> d /tmp 1777 root root -
> X /tmp/important_mount
> 
> All files below /tmp/important_mount will be deleted as the
> /tmp/important_mount item will spuriously inherit a max age of 0
> from /tmp.
> /tmp has a max age of 0 but age_set is (of course) false.
> 
> This affects also the PrivateTmp feature of systemd.
> All tmp files of such services will be deleted unconditionally
> and can cause service failures and data loss.
> 
> Fix this by checking ->age_set in the IGNORE_DIRECTORY_PATH logic.
> ---
>  src/tmpfiles/tmpfiles.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
> index 79fd0b7..c8d4abb 100644
> --- a/src/tmpfiles/tmpfiles.c
> +++ b/src/tmpfiles/tmpfiles.c
> @@ -1572,7 +1572,7 @@ static int read_config_file(const char *fn, bool 
> ignore_enoent) {
>  candidate_item = j;
>  }
>  
> -if (candidate_item) {
> +if (candidate_item && candidate_item->age_set) {
>  i->age = candidate_item->age;
>  i->age_set = true;
>  }
> 

ping?

Is there something horrible wrong with this patch or the submission itself?
Please tell me. :)

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

[systemd-devel] nss-mymachines and virtual machines

2014-09-26 Thread Simon Peeters 
hej,

In the light of my linux classes i was looking into hooking up vagrant
with machined in order to be able to use nss-mymachines to resolve the
ip address on the host-only adaptor. Unfortunatly the network side of
machined seems to only work with containers (since afaik it looks for
a veth pair).

It would be nice to enable this also for virtual machines (in this
case virtualbox).

we could:
 * allow the ip and optionally interface to be specified on machine creation.
   + ensures nobody can change it once the machine is running
   - would require yet another "create" dbus call
 * add the ip and interface as writable properties.
   + less code, easy to use.
   - allows any system process (not only the supervisor of the
machine) to modify this information at runtime.

Any ideas on this?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [HEADS-UP] Intent to remove readahead from systemd

2014-09-26 Thread Pacho Ramos 
El vie, 26-09-2014 a las 08:58 +0200, Tom Gundersen escribió:
> On Thu, Sep 25, 2014 at 6:40 PM, Pacho Ramos  wrote:
> > El jue, 25-09-2014 a las 16:44 +0200, Tom Gundersen escribió:
> >> On Thu, Aug 14, 2014 at 7:16 PM, Lennart Poettering
> >>  wrote:
> >> > So, I think with the release after the upcoming one we should just
> >> > remove it from the systemd package and just throw it on the pile of
> >> > historic cruft. So, yeah, here's the advance warning that this will be
> >> > happening...
> >> >
> >> > (Well, unless somebody from the community who cares and wants to invest
> >> > the necessary time in it steps up and gives it the love it really
> >> > needs. If nobody does until that release, I will delete the component
> >> > from systemd).
> >>
> >> No one objected to this, so I pushed the patch deleting it. If anyone
> >> wants to resurrect this in an external repo, it should be simple
> >> enough to extract it from git.
> >>
> >> Cheers,
> >>
> >> Tom
> >> ___
> >> systemd-devel mailing list
> >> systemd-devel@lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> >
> > Is there any other readahead implementation around that we could migrate
> > to? Well, not sure many laptops with SSD are sold in your area but, at
> > least in mine, most people still have (and buy) setups with rotational
> > hard drives that have a clear gain when running readahead (well, I can
> > see it every time I reboot and login on gnome-shell if I don't use
> > readahead)
> 
> I think the best bet would be someone who understands/knows/uses this
> stuff to resurrect systemd-readahead in a third-party repo and
> maintain it there. AFAIK, it was the best of the available options.
> 
> Cheers,
> 
> Tom

Yeah, the problem was that I ended up using it as it looked to be the
best option for doing this (even being "stalled"), the problem is that,
even if I "use" it actively, I don't "understand/know" it :S

Lets see if anyone finally is able to, at least, repackage it outside
systemd (even simply keeping it, for now, as good (=> better than other
alternatives) as it's currently) 

Best regards

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

Re: [systemd-devel] [HEADS-UP] Intent to remove readahead from systemd

2014-09-26 Thread Samuli Suominen 

On 26/09/14 09:58, Tom Gundersen wrote:
> On Thu, Sep 25, 2014 at 6:40 PM, Pacho Ramos  wrote:
>> El jue, 25-09-2014 a las 16:44 +0200, Tom Gundersen escribió:
>>> On Thu, Aug 14, 2014 at 7:16 PM, Lennart Poettering
>>>  wrote:
 So, I think with the release after the upcoming one we should just
 remove it from the systemd package and just throw it on the pile of
 historic cruft. So, yeah, here's the advance warning that this will be
 happening...

 (Well, unless somebody from the community who cares and wants to invest
 the necessary time in it steps up and gives it the love it really
 needs. If nobody does until that release, I will delete the component
 from systemd).
>>> No one objected to this, so I pushed the patch deleting it. If anyone
>>> wants to resurrect this in an external repo, it should be simple
>>> enough to extract it from git.
>>>
>>> Cheers,
>>>
>>> Tom
>>> ___
>>> systemd-devel mailing list
>>> systemd-devel@lists.freedesktop.org
>>> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>> Is there any other readahead implementation around that we could migrate
>> to? Well, not sure many laptops with SSD are sold in your area but, at
>> least in mine, most people still have (and buy) setups with rotational
>> hard drives that have a clear gain when running readahead (well, I can
>> see it every time I reboot and login on gnome-shell if I don't use
>> readahead)
> I think the best bet would be someone who understands/knows/uses this
> stuff to resurrect systemd-readahead in a third-party repo and
> maintain it there. AFAIK, it was the best of the available options.
>
> Cheers,
>
> Tom

This sounds like the best option to me too, anyone can pick up the
systemd-readahead
code and create a e.g. github repository for it

+1

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

Re: [systemd-devel] [systemd-commits] src/bus-proxyd test/bus-policy

2014-09-26 Thread Daniel Mack 
On 09/26/2014 05:05 AM, Zbigniew Jędrzejewski-Szmek wrote:
> Hi,
> test-bus-policy fails intermittently in 'make distcheck'
> 
> FAIL: test-bus-policy
> =
> 
> Assertion 'policy_check_own(&p, &ucred, "org.test.test1") == true' failed at 
> ../src/bus-proxyd/test-bus-policy.c:58,
>  function main(). Aborting.

Hmm. I don't see this here. What kind of setup are you running this on?
We make certain assumptions on existing users/groups on the target
system, and I'm not sure whether we should do that. Are uid/gid 1 valid
on your system?


Thanks,
Daniel

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

Re: [systemd-devel] [PATCH 1/7] make utmp/wtmp support configurable

2014-09-26 Thread Emil Renner Berthing 
On 26 September 2014 04:43, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Wed, Sep 24, 2014 at 05:25:00PM +0200, Emil Renner Berthing wrote:
>> For now just stub out the functions in utmp-wtmp.h
>> so code will still compile. These stubs will be
>> removed in the last commit in this patch series.
>> ---
>>  Makefile.am | 34 +++---
>>  configure.ac| 11 +++
>>  man/runlevel.xml|  3 ++-
>>  man/systemd-update-utmp.service.xml |  2 +-
>>  src/core/build.h|  7 +++
>>  src/shared/utmp-wtmp.h  | 28 
>>  6 files changed, 76 insertions(+), 9 deletions(-)
> Hm, I understand why this is wanted, but the approach is rather intrusive.
> Can you instead modify utmp-wtmp.c to provide noop stubs when utmp
> is disabled? Other places should simply call the utmp_* functions as before.
> Possibly if there are other places where significant prepration is
> done before calling utmp_*, like server_forward_wall, stub implementations
> could be provided too, but only if it seems to make a significant difference
> at runtime. In general please try to minimize ifdefs, we have too many
> of those already.

This is exactly the approach taken in this first patch, except it uses
static inline stubs in the header file. This is better, since is lets the
compiler see that the functions doesn't do anything and in many
cases it can compile out more code.

The following patches may eliminate a little more useless code,
but mostly they serve to align with the ocding style in other files,
where this noop-stubbing doesn't seem to be used much.
I am totally fine with only applying this first patch.

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

Re: [systemd-devel] [HEADS-UP] Intent to remove readahead from systemd

2014-09-26 Thread Tom Gundersen 
On Thu, Sep 25, 2014 at 6:38 PM, Daurnimator  wrote:
> On 25 September 2014 10:44, Tom Gundersen  wrote:
>>
>> I pushed the patch deleting it.
>
>
> Please ensure
> http://www.freedesktop.org/software/systemd/man/sd-readahead.html is updated
> ASAP with a deprecation note.

This page will go away next time the man-pages are regenerated. Please
note that the sd-readahead API was not provided by libsystemd.so (it
was just a drop-in file), so there should be no issue with
compatibility here.

Cheers,

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