[systemd-devel] udev rules fails to set attribute on boot on CentOS 6.6

[Angelos Ching]

Hi guys,

I'm not exactly sure if I'm asking the right question in the right 
place, please let me know if this is not the right place for this question.


I'm setting up SR-IOV for my Intel I350 igb on CentOS 6.6 
(2.6.32-504.el6.x86_64, udev 147) using udev. I have modified a rule I 
used in CentOS 7 (3.10.0-123.el7.x86_64, udev 208). When I do "udevadm 
test" on CentOS 6.6, the rule is matched correctly and sets the 
sriov_numvfs attribute to the desired number and enables SR-IOV accordingly:


# cat /etc/udev/rules.d/igbsriov.rules
KERNEL==":01:00.0", SUBSYSTEM=="pci", DRIVER=="igb", 
ATTR{vendor}=="0x8086", ATTR{device}=="0x1521", 
WAIT_FOR="/sys/bus/pci/devices/:01:00.0/sriov_numvfs", 
ATTR{sriov_numvfs}="7"


However, when the computer is reboot, sriov_numvfs attribute is not set 
until I perform "udevadm trigger"


Any ideas what I may be missing?

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

Re: [systemd-devel] [PATCHv2 1/4] systemctl: cat, edit: improve unit load error reporting

[Zbigniew Jędrzejewski-Szmek]

Looks good. Pushed all four.

Zbyszek

On Thu, Feb 05, 2015 at 01:56:57AM +0300, Ivan Shapovalov wrote:
> - report actual load error for units which could not be loaded
> - make unit_find_paths() report all kinds of errors it encounters
>   (for consistency)
> - consistently handle not-found errors in cat() and edit()
> ---
>  src/systemctl/systemctl.c | 54 
> +++
>  1 file changed, 40 insertions(+), 14 deletions(-)
> 
> diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
> index 462f7fd..083b618 100644
> --- a/src/systemctl/systemctl.c
> +++ b/src/systemctl/systemctl.c
> @@ -2309,9 +2309,12 @@ static int unit_find_paths(sd_bus *bus,
>  
>  if (!avoid_bus_cache && !unit_name_is_template(unit_name)) {
>  _cleanup_bus_error_free_ sd_bus_error error = 
> SD_BUS_ERROR_NULL;
> +_cleanup_bus_message_unref_ sd_bus_message *unit_load_error 
> = NULL;
>  _cleanup_free_ char *unit = NULL;
>  _cleanup_free_ char *path = NULL;
>  _cleanup_strv_free_ char **dropins = NULL;
> +_cleanup_strv_free_ char **load_error = NULL;
> +char *unit_load_error_name, *unit_load_error_message;
>  
>  unit = unit_dbus_path_from_name(unit_name);
>  if (!unit)
> @@ -2320,6 +2323,31 @@ static int unit_find_paths(sd_bus *bus,
>  if (need_daemon_reload(bus, unit_name) > 0)
>  warn_unit_file_changed(unit_name);
>  
> +r = sd_bus_get_property(
> +bus,
> +"org.freedesktop.systemd1",
> +unit,
> +"org.freedesktop.systemd1.Unit",
> +"LoadError",
> +&error,
> +&unit_load_error,
> +"(ss)");
> +if (r < 0)
> +return log_error_errno(r, "Failed to get LoadError: 
> %s", bus_error_message(&error, r));
> +
> +r = sd_bus_message_read(
> +unit_load_error,
> +"(ss)",
> +&unit_load_error_name,
> +&unit_load_error_message);
> +if (r < 0)
> +return bus_log_parse_error(r);
> +
> +if (!isempty(unit_load_error_name)) {
> +log_error("Unit %s is not loaded: %s", unit_name, 
> unit_load_error_message);
> +return 0;
> +}
> +
>  r = sd_bus_get_property_string(
>  bus,
>  "org.freedesktop.systemd1",
> @@ -2387,6 +2415,9 @@ static int unit_find_paths(sd_bus *bus,
>  r = unit_file_find_dropin_paths(lp->unit_path, NULL, 
> names, dropin_paths);
>  }
>  
> +if (r == 0)
> +log_error("No files found for %s.", unit_name);
> +
>  return r;
>  }
>  
> @@ -4588,10 +4619,8 @@ static int cat(sd_bus *bus, char **args) {
>  r = unit_find_paths(bus, *name, avoid_bus_cache, &lp, 
> &fragment_path, &dropin_paths);
>  if (r < 0)
>  return r;
> -else if (r == 0) {
> -log_warning("Unit %s does not have any files on 
> disk", *name);
> -continue;
> -}
> +else if (r == 0)
> +return -ENOENT;
>  
>  if (first)
>  first = false;
> @@ -5940,9 +5969,13 @@ static int find_paths_to_edit(sd_bus *bus, char 
> **names, char ***paths) {
>  r = unit_find_paths(bus, *name, avoid_bus_cache, &lp, &path, 
> NULL);
>  if (r < 0)
>  return r;
> -else if (r == 0 || !path)
> +else if (r == 0)
> +return -ENOENT;
> +else if (!path) {
>  // FIXME: support units with path==NULL (no 
> FragmentPath)
> -return log_error_errno(ENOENT, "Unit %s not found, 
> cannot edit.", *name);
> +log_error("No fragment exists for %s.", *name);
> +return -ENOENT;
> +}
>  
>  if (arg_full)
>  r = unit_file_create_copy(*name, path, user_home, 
> user_runtime, &new_path, &tmp_path);
> @@ -5981,19 +6014,12 @@ static int edit(sd_bus *bus, char **args) {
>  if (r < 0)
>  return log_error_errno(r, "Failed to expand names: %m");
>  
> -if (!names) {
> -log_error("No unit name found by expanding names");
> -return -ENOENT;
> -}
> -

Re: [systemd-devel] [PATCH] hwdb: Bind "toolbox" buttons to the Windows key

[Zbigniew Jędrzejewski-Szmek]

On Wed, Feb 04, 2015 at 06:46:10PM +0100, Bastien Nocera wrote:
> One would expect pressing the button to go to an overview / show
> applications mode, we thus map it to leftmeta, the Windows key.
> 
> See https://bugzilla.gnome.org/show_bug.cgi?id=658602#c17

Applied.

Zbyszek

>   KEYBOARD_KEY_6c=direction  # rotate
> - KEYBOARD_KEY_68=f13# toolbox
> + KEYBOARD_KEY_68=leftmeta   # toolbox
>   KEYBOARD_KEY_6b=esc# escape
>   KEYBOARD_KEY_6d=right  # right on d-pad
>   KEYBOARD_KEY_6e=left   # left on d-pad
> @@ -601,7 +601,7 @@ keyboard:dmi:bvn*:bvr*:bd*:svnLENOVO*:pnThinkPad*X6*:pvr*
>  # ThinkPad X41 Tablet
>  keyboard:dmi:bvn*:bvr*:bd*:svnIBM*:pn18666TU:pvr*
>   KEYBOARD_KEY_6c=direction  # rotate
> - KEYBOARD_KEY_68=f13# toolbox
> + KEYBOARD_KEY_68=leftmeta   # toolbox
>   KEYBOARD_KEY_6b=esc# escape
>   KEYBOARD_KEY_69=enter  # enter on d-pad
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'

[Zbigniew Jędrzejewski-Szmek]

On Wed, Feb 04, 2015 at 09:53:20PM +0100, Michael Biebl wrote:
> [grr, accidentally dropped the mailing list on my previous reply]
> 
> 2015-02-04 21:48 GMT+01:00 Lennart Poettering :
> > On Wed, 04.02.15 21:15, Michael Biebl (mbi...@gmail.com) wrote:
> >
> >> 2015-02-04 2:12 GMT+01:00 Lennart Poettering :
> >> > On Wed, 04.02.15 02:05, Michael Biebl (mbi...@gmail.com) wrote:
> >> >
> >> >>
> >> >>
> >> >> [1] 
> >> >> http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/debian/rules?id=8341218591c79b4fcfd2542b765b605faff8690b
> >> >
> >> > That hack is actually not that ugly... Though incomplete since it will
> >> > only add refs to runlevel[1-5], but not 0,6...
> >>
> >> Does it? It adds the wants symlinks to poweroff and reboot as well,
> >> and runlevel 0 and 6 are symlinks to those targets:
> >
> > Well, but the goal here is to make sure runlevel0.target and
> > runlevel6.target are at least once referenced. For
> > runlevel[1-5].target this is nicely achieved by pulling in
> > systemd-update-utmp-runlevel.service, since that actually contains
> > After= deps for those 5 runlevel targets... But it doesn't for 0 and 6,
> > which hence never get loaded, thus not fixing the problem for them...
> >
> >> > But I still think the .wants symlinks from sysv-generator might be the
> >> > better hack to apply...
> >>
> >> Do you mean, generating the same set of symlinks as above from within
> >> the sysv-generator?
> >> I guess I could cobble together a patch for that.
> >
> > No, s-u-u-r.s should not be involved really...
> >
> > Instead, the generator should iterate through runlevel0-6.target, then
> > check where they point and add a .wants symlink from their destination
> > to themselves. When systemd tries to load the .wants/ symlinks it will
> > load these alias, figure out they point back to the respective
> > targets, merge the targets. Finally, it will realize that the wants
> > link is actually on itself, which it suppresses and all is good.
> >
> >> Alternatively, we could just create those symlink on make install, if
> >> sysv support is enabled.
> >
> > The benefit of a generator is that people can reassign what their
> > runlevels mean simply by overriding the one symlink in
> > /etc/systemd/system for it. We will then derive the other symlink from
> > that, automatically.
> 
> Since the original patch is from Zbyszek, I'm bringing him into the loop here.
> 
> Just want to know why he didn't considered pushing this patch upstream.
> Apparently already two distros patch this downstream, so having a fix
> upstream would imho make sense.
Because it was just a hack :)

Maybe Lennart's idea with the sysv generator is a better thing.

Zbyszek

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

Re: [systemd-devel] Mediacast to TV - MiracleCast - Open-Source Miracast - Wifi-Display on linux

[Dan Williams]

On Wed, 2015-02-04 at 00:47 +0100, poma wrote:
> On 03.02.2015 18:43, David Herrmann wrote:
> > Hi
> > 
> > On Tue, Feb 3, 2015 at 6:36 PM, poma  wrote:
> >> On 02.02.2015 19:58, David Herrmann wrote:
> >>> As I'm not really interested in hacking on network-managers, I've
> >>> decided to stop working on MiracleCast. If, some day, there's a
> >>> working P2P stack on linux, I might resurrect it. But it sounds more
> >>> likely that I'll refer to the Intel solution (WYSIWIDI) instead.
> >>> There're also gstreamer plugins for WFD now, so maybe give them a try?
> >>>
> >>
> >> gst-rtsp-server-wfd
> >> https://github.com/Samsung/gst-rtsp-server-wfd/blob/master/README.md
> >>
> >> Pre-conditions:
> >>
> >> This module is running on established p2p connection with wifi direct, 
> >> which means that you have to setup this network environment to run this 
> >> module. I hope this link would be very helpful. ( 
> >> http://cgit.freedesktop.org/~dvdhrm/miracle )
> >>
> >> You are referring to them, they are referring to you. :)
> > 
> > They provide a gstreamer plugin for Miracast, but quite frankly didn't
> > bother hacking on Wifi P2P. Hence, they refer to my miracle-wifid hack
> > to provide a P2P link. If NM provides a P2P API, you can just set it
> > up via nmcli and then use the gst modules to run Miracast (or you can
> > just use the ConnMan API right now).
> > 
> > Thanks
> > David
> > 
> 
> 
> Well at least there is an open RFE - Network Manager
> [enh] Add support for WiFi P2P (aka WiFi Direct)
> https://bugzilla.gnome.org/show_bug.cgi?id=734073
> 
> And in this thread I see Patrik Flykt - ConnMan.
> Connman WiFi p2p API evaluation
> https://mail.gnome.org/archives/networkmanager-list/2015-January/msg00018.html
> 
> Let's see if NetworkMan can learn from ConnMan. :)

Of course it can learn something :)  We'd rather have NetworkManager
share an API with ConnMan here instead of needlessly re-inventing the
wheel.  I think we came to quasi-agreement in the mail thread you link
to, but need to write up a final spec and get agreement from Patrik.
This might also be a good project for a community member to help out
with too.  So if anyone is interested in the NetworkManager side of
P2P/Direct (and I know some are) please raise your hand!

Dan

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

Re: [systemd-devel] Container, private network and socket activation

[Mikhail Morfikov]

> That indicates that the systemd or apache inside the container do not
> correctly make use of the the socket passed into them. You need to
> make sure that inside the container you have pretty much the same
> .socket unit running as on the host. The ListStream lines must be
> identical, so that systemd inside the container recognizes the sockets
> passed in from the host as the ones to use for apache. The only
> difference for the socket units is that on the host they should
> activate the container, in the container they should activate apache.
> ...
> Well, because the socket wasn't passed on right the connection on it
> will still be queued after the container exits again. systemd will
> thus immediately spawn the container again. 
> 
> Basically, if you fix your issue #1, your issue #3 will be magically
> fixed too.

Now I understand the mechanizm, at least I think so.

Unfortunately I have apache 2.4.x . I tried to apply the patches
Christian Seiler mentioned, but I was unable to build the package. I
think I have to wait a little bit longer in order to make it work.

Anyway, I tried to reproduce the ssh example (it can be found here:
http://0pointer.net/blog/projects/socket-activated-containers.html)
just for testing purposes, and I dont't experience the rebooting issue
anymore, but there's another thing:

morfik:~$ ssh -p 23 192.168.10.10
^C
morfik:~$ ssh -p 23 192.168.10.10
ssh: connect to host 192.168.10.10 port 23: Connection refused

The container started when I had tried to connect for the first
time, but I couldn't connect to this port after that, and I have no
idea why. I tried to figure out what went wrong, but I failed.

# machinectl status debian-tree -l --no-pager
debian-tree
   Since: Thu 2015-02-05 00:21:41 CET; 1min 16s ago
  Leader: 103953 (systemd)
 Service: nspawn; class container
Root: /media/Kabi/debian-tree
 Address: 192.168.10.10
  fe80::1474:8dff:fe79:6b44
  OS: Debian GNU/Linux 8 (jessie)
Unit: machine-debian\x2dtree.scope
  ├─103953 /lib/systemd/systemd 3
  └─system.slice
├─dbus.service
│ └─104069 /usr/bin/dbus-daemon --system --address=systemd: 
--nofork --nopidfile --systemd-activation
├─cron.service
│ └─104043 /usr/sbin/cron -f
├─apache2.service
│ ├─104481 /usr/sbin/apache2 -k start
│ ├─104485 /usr/sbin/apache2 -k start
│ ├─104511 /usr/sbin/apache2 -k start
│ ├─104512 /usr/sbin/apache2 -k start
│ ├─104513 /usr/sbin/apache2 -k start
│ ├─104515 /usr/sbin/apache2 -k start
│ └─104516 /usr/sbin/apache2 -k start
├─system-sshd.slice
│ └─sshd@0-192.168.10.10:23-192.168.10.10:51767.service
│   ├─104041 sshd: [accepted]
│   └─104042 sshd: [net]
├─systemd-journald.service
│ └─103975 /lib/systemd/systemd-journald
├─systemd-logind.service
│ └─104046 /lib/systemd/systemd-logind
├─mysql.service
│ ├─104090 /bin/sh /usr/bin/mysqld_safe
│ └─104453 /usr/sbin/mysqld --basedir=/usr 
--datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql 
--log-error=/var/log/mysql/error.log --pid-file=/var/run/mysqld/mysqld.pid 
--socket=/var/run/mysqld/mysqld.sock --port=
├─console-getty.service
│ └─104208 /sbin/agetty --noclear --keep-baud console 
115200 38400 9600 vt102
└─rsyslog.service
  └─104088 /usr/sbin/rsyslogd -n

Then I logged into the container:

root:~# machinectl login debian-tree
  
...
root@www:/home/morfik# netstat -tupan
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address   Foreign Address State   
PID/Program name
tcp0  0 192.168.10.10:  0.0.0.0:*   LISTEN  
483/mysqld
tcp6   0  0 :::80   :::*LISTEN  
511/apache2
tcp6   0  0 :::22   :::*LISTEN  
1/systemd
tcp6   0  0 :::443  :::*LISTEN  
511/apache2

Nothing listens on the port 23, why?

Still inside of the container:

root@www:/home/morfik#  tree /etc/systemd/system
/etc/systemd/system
|-- getty.target.wants
|   `-- getty@tty1.service -> /lib/systemd/system/getty@.service
|-- multi-user.target.wants
|   |-- cron.service -> /lib/systemd/system/cron.service
|   |-- remote-fs.target -> /lib/systemd/system/remote-fs.target
|   `-- rsyslog.service -> /lib/systemd/syste

Re: [systemd-devel] bug 88401 / daemon-reload causes Type=oneshot services to be re-started / path_coldplug() is non-deserialization-aware

[Ivan Shapovalov]

On 2015-01-28 at 22:29 +0300, Ivan Shapovalov wrote:
> On 2015-01-28 at 20:15 +0100, Lennart Poettering wrote:
> > On Sun, 18.01.15 04:21, Ivan Shapovalov (intelfx...@gmail.com) wrote:
> > 
> > > Hi folks,
> > > 
> > > I'm trying to fix this bug:
> > > https://bugs.freedesktop.org/show_bug.cgi?id=88401
> > > 
> > > The initial problem (as reported) looks following: performing a reload
> > > (maybe implicitly) re-starts alsa-restore.service if it is enabled.
> > > 
> > > With a bit of debugging I've apparently found a root cause. Explanation
> > > following.
> > > 
> > > Suppose we have CUPS installed and org.cups.cupsd.{path,service} are
> > > started.
> > > 
> > > We enter manager_reload(), units are serialized, reset, re-read,
> > > deserialized and then cold-plugged. (Note that e. g. unit_notify() has
> > > special "protection" to avoid spawning jobs when a reload is in
> > > progress.)
> > > 
> > > So, if org.cups.cupsd.path is started, *it is almost first to be
> > > cold-plugged*. The call chain is:
> > > 
> > > unit_coldplug()
> > > path_coldplug()
> > > path_enter_waiting() // recheck == true
> > > path_check_good() // returns true
> > > path_enter_running()
> > > manager_add_job() // at this point we're fucked up
> > > 
> > > So, a job is enqueued for org.cups.cupsd.service. This is already wrong,
> > > because a reload should never enqueue any jobs (IIUC). So, the job is
> > > enqueued... remember that almost all units are inactive by now. Thus we
> > > end up re-starting half a system (the whole basic.target) as
> > > dependencies.
> > > 
> > > Questions:
> > > - is my analysis correct?
> > > - if yes, then how to fix this? Maybe add a similar
> > >   "if (UNIT(p)->manager->n_reloading <= 0)" check to
> > >   path_enter_running() to avoid calling manager_add_job() during
> > >   reloading?
> > 
> > Hmm, how does this relate to the ALSA case? I mean, the alsa units
> > don't use .path units, do they?
> 
> The .path unit from CUPS is triggered and starts its .service unit
> *while the service unit's state has not yet been coldplugged*.
> Actually, almost nothing is coldplugged at that point. Thus the
> basic.target is effectively re-started with all its dependencies,
> ignoring all existing state (because it is not yet coldplugged). This
> is the actual bug, and it is the root cause of the reported bug.
> 
> Reported bug, on the other hand, happens due to
> 1) the above-described bug (not related to alsa) takes place;
> 2) alsa-restore.service is Type=oneshot, RemainAfterExit=false and
>WantedBy=basic.target.
> 
> Hope it makes things clearer...

Ping? Lennart, do you understand what's going on, or should I try to
describe things more carefully?

// I would like to get this fixed before v219 ;)

Thanks.
-- 
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

[systemd-devel] [PATCHv2 2/4] systemctl: cat: fix error handling

[Ivan Shapovalov]

- correctly check for local vs. remote transport
- return after receiving error from expand_names()
---
 src/systemctl/systemctl.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 083b618..567b467 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -4594,8 +4594,8 @@ static int cat(sd_bus *bus, char **args) {
 
 assert(args);
 
-if (arg_host) {
-log_error("Option --host cannot be used with 'cat'");
+if (arg_transport != BUS_TRANSPORT_LOCAL) {
+log_error("Cannot remotely cat units");
 return -EINVAL;
 }
 
@@ -4605,7 +4605,7 @@ static int cat(sd_bus *bus, char **args) {
 
 r = expand_names(bus, args + 1, NULL, &names);
 if (r < 0)
-log_error_errno(r, "Failed to expand names: %m");
+return log_error_errno(r, "Failed to expand names: %m");
 
 avoid_bus_cache = !bus || avoid_bus();
 
-- 
2.2.2

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

[systemd-devel] [PATCHv2 3/4] systemctl: cat, edit: further polish error messages

[Ivan Shapovalov]

---
 src/systemctl/systemctl.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 567b467..384ae02 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -4578,7 +4578,7 @@ static int init_home_and_lookup_paths(char **user_home, 
char **user_runtime, Loo
 
 r = lookup_paths_init_from_scope(lp, arg_scope, arg_root);
 if (r < 0)
-return log_error_errno(r, "Failed to lookup unit lookup paths: 
%m");
+return log_error_errno(r, "Failed to query unit lookup paths: 
%m");
 
 return 0;
 }
@@ -5725,11 +5725,11 @@ static int create_edit_temp_file(const char *new_path, 
const char *original_path
 
 r = tempfn_random(new_path, &t);
 if (r < 0)
-return log_error_errno(r, "Failed to determine temporary 
filename for %s: %m", new_path);
+return log_error_errno(r, "Failed to determine temporary 
filename for \"%s\": %m", new_path);
 
 r = mkdir_parents(new_path, 0755);
 if (r < 0) {
-log_error_errno(r, "Failed to create directories for %s: %m", 
new_path);
+log_error_errno(r, "Failed to create directories for \"%s\": 
%m", new_path);
 free(t);
 return r;
 }
@@ -5738,12 +5738,12 @@ static int create_edit_temp_file(const char *new_path, 
const char *original_path
 if (r == -ENOENT) {
 r = touch(t);
 if (r < 0) {
-log_error_errno(r, "Failed to create temporary file 
%s: %m", t);
+log_error_errno(r, "Failed to create temporary file 
\"%s\": %m", t);
 free(t);
 return r;
 }
 } else if (r < 0) {
-log_error_errno(r, "Failed to copy %s to %s: %m", 
original_path, t);
+log_error_errno(r, "Failed to copy \"%s\" to \"%s\": %m", 
original_path, t);
 free(t);
 return r;
 }
@@ -5851,7 +5851,7 @@ static int unit_file_create_copy(const char *unit_name,
 if (!path_equal(fragment_path, tmp_new_path) && access(tmp_new_path, 
F_OK) == 0) {
 char response;
 
-r = ask_char(&response, "yn", "%s already exists, are you sure 
to overwrite it with %s? [(y)es, (n)o] ", tmp_new_path, fragment_path);
+r = ask_char(&response, "yn", "\"%s\" already exists. 
Overwrite with \"%s\"? [(y)es, (n)o] ", tmp_new_path, fragment_path);
 if (r < 0) {
 free(tmp_new_path);
 return r;
@@ -5865,7 +5865,7 @@ static int unit_file_create_copy(const char *unit_name,
 
 r = create_edit_temp_file(tmp_new_path, fragment_path, &tmp_tmp_path);
 if (r < 0) {
-log_error_errno(r, "Failed to create temporary file for %s: 
%m", tmp_new_path);
+log_error_errno(r, "Failed to create temporary file for 
\"%s\": %m", tmp_new_path);
 free(tmp_new_path);
 return r;
 }
@@ -6001,7 +6001,7 @@ static int edit(sd_bus *bus, char **args) {
 assert(args);
 
 if (!on_tty()) {
-log_error("Cannot edit units if we are not on a tty");
+log_error("Cannot edit units if not on a tty");
 return -EINVAL;
 }
 
@@ -6030,12 +6030,12 @@ static int edit(sd_bus *bus, char **args) {
  * It's useful if the user wants to cancel its modification
  */
 if (null_or_empty_path(*tmp)) {
-log_warning("Edition of %s canceled: temporary file 
empty", *original);
+log_warning("Editing \"%s\" canceled: temporary file 
is empty", *original);
 continue;
 }
 r = rename(*tmp, *original);
 if (r < 0) {
-r = log_error_errno(errno, "Failed to rename %s to %s: 
%m", *tmp, *original);
+r = log_error_errno(errno, "Failed to rename \"%s\" to 
\"%s\": %m", *tmp, *original);
 goto end;
 }
 }
-- 
2.2.2

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

[systemd-devel] [PATCHv2 4/4] systemctl: unit_find_paths(): unify error handling in two code pathes

[Ivan Shapovalov]

---
 src/systemctl/systemctl.c | 63 ++-
 1 file changed, 35 insertions(+), 28 deletions(-)

diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 384ae02..2d70ff1 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -2293,6 +2293,9 @@ static int unit_find_paths(sd_bus *bus,
LookupPaths *lp,
char **fragment_path,
char ***dropin_paths) {
+
+_cleanup_free_ char *path = NULL;
+_cleanup_strv_free_ char **dropins = NULL;
 int r;
 
 /**
@@ -2311,8 +2314,6 @@ static int unit_find_paths(sd_bus *bus,
 _cleanup_bus_error_free_ sd_bus_error error = 
SD_BUS_ERROR_NULL;
 _cleanup_bus_message_unref_ sd_bus_message *unit_load_error = 
NULL;
 _cleanup_free_ char *unit = NULL;
-_cleanup_free_ char *path = NULL;
-_cleanup_strv_free_ char **dropins = NULL;
 _cleanup_strv_free_ char **load_error = NULL;
 char *unit_load_error_name, *unit_load_error_message;
 
@@ -2359,28 +2360,17 @@ static int unit_find_paths(sd_bus *bus,
 if (r < 0)
 return log_error_errno(r, "Failed to get FragmentPath: 
%s", bus_error_message(&error, r));
 
-r = sd_bus_get_property_strv(
-bus,
-"org.freedesktop.systemd1",
-unit,
-"org.freedesktop.systemd1.Unit",
-"DropInPaths",
-&error,
-&dropins);
-if (r < 0)
-return log_error_errno(r, "Failed to get DropInPaths: 
%s", bus_error_message(&error, r));
-
-r = 0;
-if (!isempty(path)) {
-*fragment_path = path;
-path = NULL;
-r = 1;
-}
-
-if (dropin_paths && !strv_isempty(dropins)) {
-*dropin_paths = dropins;
-dropins = NULL;
-r = 1;
+if (dropin_paths) {
+r = sd_bus_get_property_strv(
+bus,
+"org.freedesktop.systemd1",
+unit,
+"org.freedesktop.systemd1.Unit",
+"DropInPaths",
+&error,
+&dropins);
+if (r < 0)
+return log_error_errno(r, "Failed to get 
DropInPaths: %s", bus_error_message(&error, r));
 }
 } else {
 _cleanup_set_free_ Set *names;
@@ -2393,7 +2383,7 @@ static int unit_find_paths(sd_bus *bus,
 if (r < 0)
 return r;
 
-r = unit_file_find_path(lp, unit_name, fragment_path);
+r = unit_file_find_path(lp, unit_name, &path);
 if (r < 0)
 return r;
 
@@ -2405,14 +2395,31 @@ static int unit_find_paths(sd_bus *bus,
 return log_oom();
 
 if (!streq(template, unit_name)) {
-r = unit_file_find_path(lp, template, 
fragment_path);
+r = unit_file_find_path(lp, template, &path);
 if (r < 0)
 return r;
 }
 }
 
-if (dropin_paths)
-r = unit_file_find_dropin_paths(lp->unit_path, NULL, 
names, dropin_paths);
+if (dropin_paths) {
+r = unit_file_find_dropin_paths(lp->unit_path, NULL, 
names, &dropins);
+if (r < 0)
+return r;
+}
+}
+
+r = 0;
+
+if (!isempty(path)) {
+*fragment_path = path;
+path = NULL;
+r = 1;
+}
+
+if (dropin_paths && !strv_isempty(dropins)) {
+*dropin_paths = dropins;
+dropins = NULL;
+r = 1;
 }
 
 if (r == 0)
-- 
2.2.2

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

[systemd-devel] [PATCHv2 1/4] systemctl: cat, edit: improve unit load error reporting

[Ivan Shapovalov]

- report actual load error for units which could not be loaded
- make unit_find_paths() report all kinds of errors it encounters
  (for consistency)
- consistently handle not-found errors in cat() and edit()
---
 src/systemctl/systemctl.c | 54 +++
 1 file changed, 40 insertions(+), 14 deletions(-)

diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 462f7fd..083b618 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -2309,9 +2309,12 @@ static int unit_find_paths(sd_bus *bus,
 
 if (!avoid_bus_cache && !unit_name_is_template(unit_name)) {
 _cleanup_bus_error_free_ sd_bus_error error = 
SD_BUS_ERROR_NULL;
+_cleanup_bus_message_unref_ sd_bus_message *unit_load_error = 
NULL;
 _cleanup_free_ char *unit = NULL;
 _cleanup_free_ char *path = NULL;
 _cleanup_strv_free_ char **dropins = NULL;
+_cleanup_strv_free_ char **load_error = NULL;
+char *unit_load_error_name, *unit_load_error_message;
 
 unit = unit_dbus_path_from_name(unit_name);
 if (!unit)
@@ -2320,6 +2323,31 @@ static int unit_find_paths(sd_bus *bus,
 if (need_daemon_reload(bus, unit_name) > 0)
 warn_unit_file_changed(unit_name);
 
+r = sd_bus_get_property(
+bus,
+"org.freedesktop.systemd1",
+unit,
+"org.freedesktop.systemd1.Unit",
+"LoadError",
+&error,
+&unit_load_error,
+"(ss)");
+if (r < 0)
+return log_error_errno(r, "Failed to get LoadError: 
%s", bus_error_message(&error, r));
+
+r = sd_bus_message_read(
+unit_load_error,
+"(ss)",
+&unit_load_error_name,
+&unit_load_error_message);
+if (r < 0)
+return bus_log_parse_error(r);
+
+if (!isempty(unit_load_error_name)) {
+log_error("Unit %s is not loaded: %s", unit_name, 
unit_load_error_message);
+return 0;
+}
+
 r = sd_bus_get_property_string(
 bus,
 "org.freedesktop.systemd1",
@@ -2387,6 +2415,9 @@ static int unit_find_paths(sd_bus *bus,
 r = unit_file_find_dropin_paths(lp->unit_path, NULL, 
names, dropin_paths);
 }
 
+if (r == 0)
+log_error("No files found for %s.", unit_name);
+
 return r;
 }
 
@@ -4588,10 +4619,8 @@ static int cat(sd_bus *bus, char **args) {
 r = unit_find_paths(bus, *name, avoid_bus_cache, &lp, 
&fragment_path, &dropin_paths);
 if (r < 0)
 return r;
-else if (r == 0) {
-log_warning("Unit %s does not have any files on disk", 
*name);
-continue;
-}
+else if (r == 0)
+return -ENOENT;
 
 if (first)
 first = false;
@@ -5940,9 +5969,13 @@ static int find_paths_to_edit(sd_bus *bus, char **names, 
char ***paths) {
 r = unit_find_paths(bus, *name, avoid_bus_cache, &lp, &path, 
NULL);
 if (r < 0)
 return r;
-else if (r == 0 || !path)
+else if (r == 0)
+return -ENOENT;
+else if (!path) {
 // FIXME: support units with path==NULL (no 
FragmentPath)
-return log_error_errno(ENOENT, "Unit %s not found, 
cannot edit.", *name);
+log_error("No fragment exists for %s.", *name);
+return -ENOENT;
+}
 
 if (arg_full)
 r = unit_file_create_copy(*name, path, user_home, 
user_runtime, &new_path, &tmp_path);
@@ -5981,19 +6014,12 @@ static int edit(sd_bus *bus, char **args) {
 if (r < 0)
 return log_error_errno(r, "Failed to expand names: %m");
 
-if (!names) {
-log_error("No unit name found by expanding names");
-return -ENOENT;
-}
-
 r = find_paths_to_edit(bus, names, &paths);
 if (r < 0)
 return r;
 
-if (strv_isempty(paths)) {
-log_error("Cannot find any units to edit");
+if (strv_isempty(paths))
 return -ENOENT;
-}
 
 r = run_editor(paths);
 if (r < 0)
-- 
2.2.2

Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services

[Jóhann B. Guðmundsson]

On 02/04/2015 09:20 PM, Lennart Poettering wrote:

On Wed, 04.02.15 22:01, Lennart Poettering (lenn...@poettering.net) wrote:


>On Wed, 04.02.15 15:06, Martin Pitt (martin.p...@ubuntu.com) wrote:
>

> >Hey,
> >
> >Lennart Poettering [2015-02-04 13:42 +0100]:

> > >Well, but their enablement status so far is not ignored. i.e. if you
> > >drop in a unit file, as well as a sysv script, and the latter is
> > >enabled, but the former not, then systemd currently reads that so that
> > >the sysv one is overriden by the native one, and the native one is
> > >considered enabled.
> > >
> > >With this change you alter that behaviour. Is that really desired?

> >
> >Since it's rather confusing what happens in this case, we made
> >systemctl sync the status to update-rc.d (the chkconfig equivalent in
> >Debian) on enable/disable:
> >
> >   
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/systemctl-don-t-skip-native-units-when-enabling-disa.patch
> >
> >That of course doesn't change the behaviour with manual rc?.d/ symlinks.
> >
> >But if you have a native unit, I think it's rather unexpected if you
> >disable it with systemctl, enable it in sysv, but still get it
> >started.

>
>I'd claim the opposite. Let's say you have foobar.rpm installed in one
>version that only carried a sysvinit script. Now you upgrade it to a
>version that has a service file. The fact that it was enabled
>should not change... Hence, if it is enabled via sysv or via units
>doesn't matter really right now...

Anyway, not too convinced that this is really the better option, but
not too opposed either. Hence I am OK if something like this goes in.



Could not a downstream use a component based preset file hack to 
overcome this?


+ this is extremely limited to Debian and Debian based distribution 
these days and since you don't seem to recall what happened in Fedora 
during the "transaction" period where users had to manually enable 
services ( again ) after the change from the legacy script to unit in 
components during upgrades ( that chkconfig hack FPC came up with, 
approved, implemented and had everybody follow to handle upgrades did 
not work, like many other decision FPC has come up with and made in 
their infinite collective wisdom ).


I expect Debian to do the same sane thing as everyone else did back in 
the day and strike out that components will be allowed to migrate to 
units after beta ( or no later then just before the final release ), so 
end users running the latest stable version of Debian that started with 
an installed sys script wont suddenly find themselves in midst of it's 
release cycle switching to units.


Those doing " release upgrades" can as always expect breakage and or 
manual intervention of some sort so manually enable stuff again is not 
to overcoming and is not a usecase to consider.


Then next thing the Debian community will realize is that once 
maintainers have made the switch to use units they will have to stick 
the legacy sysv initscript in a separated sub component which will 
depend on a virtual provide for all the other init systems ( that is if 
the maintainers want to support those et all ).


The Debian maintainers and or it's leader can already cut corners in 
exhausting decision making and policy handling and just look at how all 
the other distribution ( fedora,opensuse,mageia etc ) handled this and 
have handle this and follow it ( as oppose to re-invent the wheel ) and 
keep all workarounds and hacks to support that transformation and 
multiple init system downstream ( like everyone else had to do ).


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

[systemd-devel] systemd-nspawn create container under unprivileged user

[Vasiliy Tolstov]

Hello!
Does it possible to create container as regular user? Oh what capabilities
i need to add to create container not using root?

-- 
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru
jabber: v...@selfip.ru
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd not discovering all devices at bootup, and thus no network is configured

[Keller, Jacob E]

Hi again,

On Tue, 2015-02-03 at 19:00 +, Keller, Jacob E wrote:
> Hey,
> 
> I've recently been using systemd-networkd to great success on a few of
> my machines here. However I ran into an interesting problem on at least
> 2 machines so far. I've included the output of journal for
> systemd-networkd with Environment=SYSTEMD_LOG_LEVEL=debug as was
> suggested on another post. In addition the only network file I have
> configured is em0.network which contains the following,
> 
> $cat /etc/systemd/network/em0.network
> [Match]
> Name=em0
> 
> [Network]
> DHCP=Yes
> 
> The journalctl for systemd-networkd after bootup is,
> 
> -- Logs begin at Mon 2012-12-31 20:02:09 PST, end at Tue 2015-02-03 10:57:09 
> PST. --
> Feb 03 10:37:44 jekeller-copperpass systemd-networkd[1055]: timestamp of 
> '/etc/systemd/network' changed
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : 
> flags change: +MULTICAST +BROADCAST
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : 
> link 7 added
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : 
> udev initialized link
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : 
> saved original MTU: 1500
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0  : 
> flags change: +MULTICAST +BROADCAST
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0  : 
> link 8 added
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0  : 
> udev initialized link
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0  : 
> saved original MTU: 1500
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: Sent message 
> type=method_call sender=n/a destination=org.freedesktop.DBus 
> object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello 
> cookie=1 reply_cookie=0 error=n/a
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : 
> MAC address: 7e:5e:7c:31:44:4d
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0  : 
> MAC address: b6:ec:a9:4b:e5:42
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : 
> getting address failed: Device or resource busy
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : 
> link state is up-to-date
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br0 : 
> unmanaged
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: Got message 
> type=method_return sender=org.freedesktop.DBus destination=:1.7 object=n/a 
> interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: Got message 
> type=signal sender=org.freedesktop.DBus destination=:1.7 
> object=/org/freedesktop/DBus interface=org.freedesktop.DBus 
> member=NameAcquired cookie=2 reply_cookie=0 error=n/a
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0  : 
> link state is up-to-date
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: br-geneve0  : 
> unmanaged
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: rtnl: received 
> address for a nonexistent link (1), ignoring
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: rtnl: received 
> address for a nonexistent link (1), ignoring
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0  : 
> flags change: +MULTICAST +BROADCAST
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0  : 
> link 9 added
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0  : 
> udev initialized link
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0  : 
> saved original MTU: 1500
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0  : 
> link state is up-to-date
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0  : 
> unmanaged
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: rtnl: received 
> address for a nonexistent link (1), ignoring
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: rtnl: received 
> address for a nonexistent link (1), ignoring
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic  : 
> flags change: +MULTICAST +BROADCAST
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic  : 
> link 10 added
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic  : 
> udev initialized link
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic  : 
> saved original MTU: 1500
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic  : 
> MAC address: 52:54:00:84:d2:d5
> Feb 03 10:37:45 jekeller-copperpass systemd-networkd[1055]: virbr0-nic  : 
> link state is up-to-date
> Feb 03 10:37:45 jekeller-copperpass systemd-netw

Re: [systemd-devel] Deadlocks with reloading jobs which are part of current transaction [was: [PATCH] Avoid reloading services when shutting down]

[Uoti Urpala]

On Wed, 2015-02-04 at 21:57 +0100, Lennart Poettering wrote:
> OK, let's try this again, with an example:
> 
> a) you have one service mydaemon.service
> 
> b) you have a preparation service called
>mydaemon-convert-config.service that takes config from somewhere,
>converts it into a suitable format for mydaemon.service's binary
> 
> Now, you change that config that is located somewhere, issue a restart
> request for m-c-c.s, issue a reload request for mydaemon.service.
> 
> Now, something like this should always have the result that your
> config change is applied to mydaemon.service. Regardless if
> mydaemon.service's start was queued, is already started or is
> currently being started. You are suggesting that the reload can
> suppressed when a start is already enqueued, but that's really not the
> case, because you first have to run m-c-c.s, before you can reload...

I do not see why that would cause any problems with removing the
blocking.

If you mean literally running "systemctl restart
mydaemon-convert-config.service; systemctl reload mydaemon.service" then
this should still work fine - the first "restart" will block until the
operation is complete and new config exists, and then the "reload"
guarantees that no old config is in use. However, I don't see why you'd
include the part about creating the new configuration via
mydaemon-convert-config.service in this case - the new configuration
already exists before any "reload" functionality is invoked, so why the
irrelevant complication of creating that configuration via another
service? It seems you are implicitly assuming some kind of parallel
execution of the restart and the reload?

If you mean something like "systemctl restart --no-block
mydaemon-convert-config.service; systemctl reload mydaemon.service", I
don't see why you'd ever /expect/ this to work with any reload semantics
- isn't this clear user error, and will be racy with current systemd
code just as much as the proposed fix? There are no ordering constraints
here, any more than there would be about starting two services and
expecting the first request to be started first. And in any case I'd
consider the semantics of reload to be "switch to configuration equal or
newer than what existed *when the reload was requested*", without any
guarantees that changes from operations queued but not finished before
calling reload would be taken into account.

So unless I completely misunderstood your example, it seems that this
does NOT demonstrate any problems with removing the blocking.


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

Re: [systemd-devel] [PATCH] Avoid reloading services when shutting down

[Reindl Harald]

Am 04.02.2015 um 22:31 schrieb Lennart Poettering:

On Wed, 04.02.15 22:25, Reindl Harald (h.rei...@thelounge.net) wrote:


Am 04.02.2015 um 21:57 schrieb Lennart Poettering:

OK, let's try this again, with an example:

a) you have one service mydaemon.service

b) you have a preparation service called
mydaemon-convert-config.service that takes config from somewhere,
converts it into a suitable format for mydaemon.service's binary

Now, you change that config that is located somewhere, issue a restart
request for m-c-c.s, issue a reload request for mydaemon.service.

Now, something like this should always have the result that your
config change is applied to mydaemon.service. Regardless if
mydaemon.service's start was queued, is already started or is
currently being started. You are suggesting that the reload can
suppressed when a start is already enqueued


which is true

the config change *after* issue restart should not affect the already
pending (for whatever reason) restart because this is *unpredictable*
bahvior - if i expect that config change to get effective i would issue
"systemctl reload" *before* the restart command


We don't make guarantees like that. This is UNIX, we have no
transaction file system.

We do make guarantees about that if you changed your config and issue
a reload, we will not drop that reload. We do not make guarantees
whether changing your config concurrently with the daemon confuses the
daemon or not. That's between the user and the daemon, we are not involved


i know that all but *you said* above "like this should always have the 
result that your config change is applied to mydaemon.service. 
Regardless if mydaemon.service's start was queued, is already started or 
is currently being started"


that is all i referred to

no - my config change shoul *not* get applied when the daemon "is 
currently being started" because that is aksing for luck and race 
conditions and leads in unpredictable behavior


if you (systemd) know that the system is about shut down there is no 
point in reload services at that time




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] slow systemd-networkd DHCP client on wlan0 with systemd v217

[Tom Gundersen]

On Wed, Feb 4, 2015 at 2:41 PM, Patrik Flykt
 wrote:
>
> Hi,
>
> On Tue, 2015-02-03 at 17:27 +0100, Lennart Poettering wrote:
>> > Is the resume event detected somehow in systemd?
>>
>> The kernel unfortunately provides no API for this right now. However,
>> if logind is the one suspending the machine, then it sends out a
>> PrepareForSleep() signal before doing so. systemd-resolved already
>> hooks into that:
>>
>> http://cgit.freedesktop.org/systemd/systemd/tree/src/resolve/resolved-bus.c#n684
>>
>> Tom mentioned he's already looking into adding similar code to
>> networkd to handle this properly.
>
> Latest upstream works fine for me. Links break at suspend and are
> enabled at restore with PrepareForSleep() handled. Both versions of DHCP
> properly stop and start at these events.


Yeah, so on all the hardware I had tried so far we got proper
IFF_LOWER_{DOWN,UP} events on suspend/resume. Turns out that is not
always the case, so added the logic to listen for logind for this.
Please let me know if anyone notices problems.

Cheers,

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

Re: [systemd-devel] [PATCH] Avoid reloading services when shutting down

[Lennart Poettering]

On Wed, 04.02.15 22:25, Reindl Harald (h.rei...@thelounge.net) wrote:

> Am 04.02.2015 um 21:57 schrieb Lennart Poettering:
> >OK, let's try this again, with an example:
> >
> >a) you have one service mydaemon.service
> >
> >b) you have a preparation service called
> >mydaemon-convert-config.service that takes config from somewhere,
> >converts it into a suitable format for mydaemon.service's binary
> >
> >Now, you change that config that is located somewhere, issue a restart
> >request for m-c-c.s, issue a reload request for mydaemon.service.
> >
> >Now, something like this should always have the result that your
> >config change is applied to mydaemon.service. Regardless if
> >mydaemon.service's start was queued, is already started or is
> >currently being started. You are suggesting that the reload can
> >suppressed when a start is already enqueued
> 
> which is true
> 
> the config change *after* issue restart should not affect the already
> pending (for whatever reason) restart because this is *unpredictable*
> bahvior - if i expect that config change to get effective i would issue
> "systemctl reload" *before* the restart command

We don't make guarantees like that. This is UNIX, we have no
transaction file system.

We do make guarantees about that if you changed your config and issue
a reload, we will not drop that reload. We do not make guarantees
whether changing your config concurrently with the daemon confuses the
daemon or not. That's between the user and the daemon, we are not involved.

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] Avoid reloading services when shutting down

[Reindl Harald]

Am 04.02.2015 um 21:57 schrieb Lennart Poettering:

OK, let's try this again, with an example:

a) you have one service mydaemon.service

b) you have a preparation service called
mydaemon-convert-config.service that takes config from somewhere,
converts it into a suitable format for mydaemon.service's binary

Now, you change that config that is located somewhere, issue a restart
request for m-c-c.s, issue a reload request for mydaemon.service.

Now, something like this should always have the result that your
config change is applied to mydaemon.service. Regardless if
mydaemon.service's start was queued, is already started or is
currently being started. You are suggesting that the reload can
suppressed when a start is already enqueued


which is true

the config change *after* issue restart should not affect the already 
pending (for whatever reason) restart because this is *unpredictable* 
bahvior - if i expect that config change to get effective i would issue 
"systemctl reload" *before* the restart command


if you say that is expected behavior than all the warnings about "you 
need to enter systemctl deamon-reload because the unit file changed" are 
pointless and you could just reload automagically all the time




signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services

[Lennart Poettering]

On Wed, 04.02.15 22:01, Lennart Poettering (lenn...@poettering.net) wrote:

> On Wed, 04.02.15 15:06, Martin Pitt (martin.p...@ubuntu.com) wrote:
> 
> > Hey,
> > 
> > Lennart Poettering [2015-02-04 13:42 +0100]:
> > > Well, but their enablement status so far is not ignored. i.e. if you
> > > drop in a unit file, as well as a sysv script, and the latter is
> > > enabled, but the former not, then systemd currently reads that so that
> > > the sysv one is overriden by the native one, and the native one is
> > > considered enabled.
> > > 
> > > With this change you alter that behaviour. Is that really desired?
> > 
> > Since it's rather confusing what happens in this case, we made
> > systemctl sync the status to update-rc.d (the chkconfig equivalent in
> > Debian) on enable/disable:
> > 
> >   
> > http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/systemctl-don-t-skip-native-units-when-enabling-disa.patch
> > 
> > That of course doesn't change the behaviour with manual rc?.d/ symlinks.
> > 
> > But if you have a native unit, I think it's rather unexpected if you
> > disable it with systemctl, enable it in sysv, but still get it
> > started.
> 
> I'd claim the opposite. Let's say you have foobar.rpm installed in one
> version that only carried a sysvinit script. Now you upgrade it to a
> version that has a service file. The fact that it was enabled 
> should not change... Hence, if it is enabled via sysv or via units
> doesn't matter really right now...

Anyway, not too convinced that this is really the better option, but
not too opposed either. Hence I am OK if something like this goes in. 

That said, please make sure to share the code from src/share/install.c
for this, do not introduce a new search logic for unit files.

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] sysv-generator: Skip init scripts for existing native services

[Uoti Urpala]

On Wed, 2015-02-04 at 22:02 +0100, Lennart Poettering wrote:
> On Wed, 04.02.15 21:26, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:
> > Isn't this change also relevant to the creation of .wants symlinks, and
> > avoiding generating .wants links from the wrong targets?
> > 
> > As in, the case where you override a rcS.d sysvinit service with a
> > multi-user.target systemd unit (or other less common runlevel
> > combinations for distros that don't have any rcS.d level sysv any more).
> > You want to avoid generating a .wants symlink from an early boot target,
> > even if a generated unit file itself would be shadowed by the native
> > unit.
> 
> systemd does not support sysv scripts for early-boot targets
> anymore. This has been removed long ago.

Yes, but Debian patches rcS.d support back in because they still haven't
managed to create native units for every package. And as the comment in
parenthesis says, the same issue still exists in principle on other
distros with other runlevels (though is less common and important than
on Debian).


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

Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services

[Michael Biebl]

2015-02-04 22:01 GMT+01:00 Lennart Poettering :
>> But if you have a native unit, I think it's rather unexpected if you
>> disable it with systemctl, enable it in sysv, but still get it
>> started.
>
> I'd claim the opposite. Let's say you have foobar.rpm installed in one
> version that only carried a sysvinit script. Now you upgrade it to a
> version that has a service file. The fact that it was enabled
> should not change...

It should be the packages duty, to properly enable the unit on
upgrades, depending on the sysv state.

Take your example and cosider one day you drop the sysv init script as
you only want to continue shipping the native service file.
Do you want to have the service suddenly be disabled now?


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services

[Lennart Poettering]

On Wed, 04.02.15 21:26, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:

> On Wed, 2015-02-04 at 15:06 +0100, Martin Pitt wrote:
> > Lennart Poettering [2015-02-04 13:42 +0100]:
> > > Well, but their enablement status so far is not ignored. i.e. if you
> > > drop in a unit file, as well as a sysv script, and the latter is
> > > enabled, but the former not, then systemd currently reads that so that
> > > the sysv one is overriden by the native one, and the native one is
> > > considered enabled.
> > > 
> > > With this change you alter that behaviour. Is that really desired?
> 
> > So in that regard it would be an intended behaviour change indeed.
> > But either way this is a corner case for sure. I just wouldn't like to
> > carry this patch forever as it's relatively unimportant.
> > 
> > Maybe Jon can chime in about his intentions with this?
> 
> Isn't this change also relevant to the creation of .wants symlinks, and
> avoiding generating .wants links from the wrong targets?
> 
> As in, the case where you override a rcS.d sysvinit service with a
> multi-user.target systemd unit (or other less common runlevel
> combinations for distros that don't have any rcS.d level sysv any more).
> You want to avoid generating a .wants symlink from an early boot target,
> even if a generated unit file itself would be shadowed by the native
> unit.

systemd does not support sysv scripts for early-boot targets
anymore. This has been removed long ago.

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] sysv-generator: Skip init scripts for existing native services

[Lennart Poettering]

On Wed, 04.02.15 15:06, Martin Pitt (martin.p...@ubuntu.com) wrote:

> Hey,
> 
> Lennart Poettering [2015-02-04 13:42 +0100]:
> > Well, but their enablement status so far is not ignored. i.e. if you
> > drop in a unit file, as well as a sysv script, and the latter is
> > enabled, but the former not, then systemd currently reads that so that
> > the sysv one is overriden by the native one, and the native one is
> > considered enabled.
> > 
> > With this change you alter that behaviour. Is that really desired?
> 
> Since it's rather confusing what happens in this case, we made
> systemctl sync the status to update-rc.d (the chkconfig equivalent in
> Debian) on enable/disable:
> 
>   
> http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/systemctl-don-t-skip-native-units-when-enabling-disa.patch
> 
> That of course doesn't change the behaviour with manual rc?.d/ symlinks.
> 
> But if you have a native unit, I think it's rather unexpected if you
> disable it with systemctl, enable it in sysv, but still get it
> started.

I'd claim the opposite. Let's say you have foobar.rpm installed in one
version that only carried a sysvinit script. Now you upgrade it to a
version that has a service file. The fact that it was enabled 
should not change... Hence, if it is enabled via sysv or via units
doesn't matter really right now...

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] Deadlocks with reloading jobs which are part of current transaction [was: [PATCH] Avoid reloading services when shutting down]

[Lennart Poettering]

On Wed, 04.02.15 22:10, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:

> On Wed, 2015-02-04 at 19:36 +0100, Lennart Poettering wrote:
> > On Wed, 04.02.15 20:19, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:
> > > You're missing an essential point here: there's a distinction between
> > > skipping reloads for services which have not not been dispatched, and
> > > skipping reloads for services for which startup code is already running
> > > (and may be using existing configuration) but which have not reached
> > > full "running" status yet.
> > > 
> > > The former is the correct behavior (but currently handled wrong by
> > > systemd!), and never causes races. Only the latter can cause races like
> > > described above.
> > 
> > These two cases aren't that different. If somebody pushes an
> > additional job into the queue that wants to run before the reload but
> > after the service is up you cannot ot flush out the reload just
> > because the service has not started yet...
> 
> I cannot parse what you're trying to say here, if it's anything
> meaningful. 

No, usually what I am babbling is not meaningful at all...

> Your "wants to run before the reload" sounds like you're
> talking about guaranteeing that a reload NOT happen before something
> else runs, but that would be nonsense - the "guarantee" would guarantee
> nothing semantically relevant (if systemd only starts executing the
> service binary *after* the reload has been queued, it cannot use any
> pre-reload-order config at any point; there's no "guaranteed to use old
> config" guarantee of any form possible!).

OK, let's try this again, with an example:

a) you have one service mydaemon.service

b) you have a preparation service called
   mydaemon-convert-config.service that takes config from somewhere,
   converts it into a suitable format for mydaemon.service's binary

Now, you change that config that is located somewhere, issue a restart
request for m-c-c.s, issue a reload request for mydaemon.service.

Now, something like this should always have the result that your
config change is applied to mydaemon.service. Regardless if
mydaemon.service's start was queued, is already started or is
currently being started. You are suggesting that the reload can
suppressed when a start is already enqueued, but that's really not the
case, because you first have to run m-c-c.s, before you can reload...

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] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'

[Michael Biebl]

[grr, accidentally dropped the mailing list on my previous reply]

2015-02-04 21:48 GMT+01:00 Lennart Poettering :
> On Wed, 04.02.15 21:15, Michael Biebl (mbi...@gmail.com) wrote:
>
>> 2015-02-04 2:12 GMT+01:00 Lennart Poettering :
>> > On Wed, 04.02.15 02:05, Michael Biebl (mbi...@gmail.com) wrote:
>> >
>> >>
>> >>
>> >> [1] 
>> >> http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/debian/rules?id=8341218591c79b4fcfd2542b765b605faff8690b
>> >
>> > That hack is actually not that ugly... Though incomplete since it will
>> > only add refs to runlevel[1-5], but not 0,6...
>>
>> Does it? It adds the wants symlinks to poweroff and reboot as well,
>> and runlevel 0 and 6 are symlinks to those targets:
>
> Well, but the goal here is to make sure runlevel0.target and
> runlevel6.target are at least once referenced. For
> runlevel[1-5].target this is nicely achieved by pulling in
> systemd-update-utmp-runlevel.service, since that actually contains
> After= deps for those 5 runlevel targets... But it doesn't for 0 and 6,
> which hence never get loaded, thus not fixing the problem for them...
>
>> > But I still think the .wants symlinks from sysv-generator might be the
>> > better hack to apply...
>>
>> Do you mean, generating the same set of symlinks as above from within
>> the sysv-generator?
>> I guess I could cobble together a patch for that.
>
> No, s-u-u-r.s should not be involved really...
>
> Instead, the generator should iterate through runlevel0-6.target, then
> check where they point and add a .wants symlink from their destination
> to themselves. When systemd tries to load the .wants/ symlinks it will
> load these alias, figure out they point back to the respective
> targets, merge the targets. Finally, it will realize that the wants
> link is actually on itself, which it suppresses and all is good.
>
>> Alternatively, we could just create those symlink on make install, if
>> sysv support is enabled.
>
> The benefit of a generator is that people can reassign what their
> runlevels mean simply by overriding the one symlink in
> /etc/systemd/system for it. We will then derive the other symlink from
> that, automatically.

Since the original patch is from Zbyszek, I'm bringing him into the loop here.

Just want to know why he didn't considered pushing this patch upstream.
Apparently already two distros patch this downstream, so having a fix
upstream would imho make sense.


Michael


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Deadlocks with reloading jobs which are part of current transaction [was: [PATCH] Avoid reloading services when shutting down]

[Uoti Urpala]

On Wed, 2015-02-04 at 19:36 +0100, Lennart Poettering wrote:
> On Wed, 04.02.15 20:19, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:
> > You're missing an essential point here: there's a distinction between
> > skipping reloads for services which have not not been dispatched, and
> > skipping reloads for services for which startup code is already running
> > (and may be using existing configuration) but which have not reached
> > full "running" status yet.
> > 
> > The former is the correct behavior (but currently handled wrong by
> > systemd!), and never causes races. Only the latter can cause races like
> > described above.
> 
> These two cases aren't that different. If somebody pushes an
> additional job into the queue that wants to run before the reload but
> after the service is up you cannot ot flush out the reload just
> because the service has not started yet...

I cannot parse what you're trying to say here, if it's anything
meaningful. Your "wants to run before the reload" sounds like you're
talking about guaranteeing that a reload NOT happen before something
else runs, but that would be nonsense - the "guarantee" would guarantee
nothing semantically relevant (if systemd only starts executing the
service binary *after* the reload has been queued, it cannot use any
pre-reload-order config at any point; there's no "guaranteed to use old
config" guarantee of any form possible!).


> Whether you change config in your current context, or you do so from a
> new unit's context is no difference: we cannot move anything that is
> supposed to happen after that change before it, and we cannot remove it
> either...

If no code from a service is currently running, it's already guaranteed
that every request issued to the service in the future will use the new
config (no old state exists, and any newly started process will
obviously load the new config). Thus the requirements for a reload are
already fulfilled; the operation is complete, and there is nothing more
to do. Unnecessary waiting only causes deadlocks for no benefit
whatsoever.

> There are some forms of coalescing possible, but we already do all of
> the ones that are safe...

This is not exactly "coalescing" - it's just immediately returning
success if there is no service code running (either in "running" state
or in startup state where a process already exists and could have read
the old config before it was changed).

Removing the current incorrect blocking and returning success
immediately is 100% safe, in the following strictly defined sense:
All requests handled by the service after "systemctl reload" has
returned will use a version of config equal or newer than the one that
was in effect when the reload call was started.

If you still want claim that removing the blocking would not be safe,
please try to construct a sequence of operations where such non-blocking
behavior would lead to failure (failure defined as: the service
processes a request using configuration older than what existed when
"reload" was requested). I'm confident that it is impossible to
construct such a counterexample.


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

Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services

[Michael Biebl]

2015-02-04 13:42 GMT+01:00 Lennart Poettering :
>> Hello all,
>>
>> a little while ago, Jon Severinsson wrote a sysv generator
>> optimization to not go through all the parsing of init.d scripts and
>> creation of units if there already is a native unit for that name. As
>> they are put into generator.late they would be ignored anyway.
>
> Well, but their enablement status so far is not ignored. i.e. if you
> drop in a unit file, as well as a sysv script, and the latter is
> enabled, but the former not, then systemd currently reads that so that
> the sysv one is overriden by the native one, and the native one is
> considered enabled.

I actually find it confusing, if the enablement state of the sysv init
script overrides the native one.
What were the reasons to do it this way?

The following behaviour is imho more consistent:
a/ only a sysv init script available: use sysv init script and its
enablement state
b/ only a native service file: use native service file and its enablement state
c/ both sysv init script and native service file available: use native
service file and its enablement state.

Take an example, where a single sysv init script foo was split up into
multipe systemd unit, like foo.service, foo.socket and bar.service.

Isn't it inconsistent, if now, only foo.service was enabled?



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services

[Uoti Urpala]

On Wed, 2015-02-04 at 15:06 +0100, Martin Pitt wrote:
> Lennart Poettering [2015-02-04 13:42 +0100]:
> > Well, but their enablement status so far is not ignored. i.e. if you
> > drop in a unit file, as well as a sysv script, and the latter is
> > enabled, but the former not, then systemd currently reads that so that
> > the sysv one is overriden by the native one, and the native one is
> > considered enabled.
> > 
> > With this change you alter that behaviour. Is that really desired?

> So in that regard it would be an intended behaviour change indeed.
> But either way this is a corner case for sure. I just wouldn't like to
> carry this patch forever as it's relatively unimportant.
> 
> Maybe Jon can chime in about his intentions with this?

Isn't this change also relevant to the creation of .wants symlinks, and
avoiding generating .wants links from the wrong targets?

As in, the case where you override a rcS.d sysvinit service with a
multi-user.target systemd unit (or other less common runlevel
combinations for distros that don't have any rcS.d level sysv any more).
You want to avoid generating a .wants symlink from an early boot target,
even if a generated unit file itself would be shadowed by the native
unit.


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

Re: [systemd-devel] Deadlocks with reloading jobs which are part of current transaction [was: [PATCH] Avoid reloading services when shutting down]

[Lennart Poettering]

On Wed, 04.02.15 20:19, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote:

> On Wed, 2015-02-04 at 16:38 +0100, Lennart Poettering wrote:
> > On Wed, 04.02.15 15:25, Martin Pitt (martin.p...@ubuntu.com) wrote:
> > > Lennart Poettering [2015-02-04 13:27 +0100]:
> > > > On Wed, 04.02.15 08:56, Martin Pitt (martin.p...@ubuntu.com) wrote:
> > > > >  - Don't enqueue a reload if the service to be reloaded isn't running.
> > > > >E. g. postfix.service "inactive/dead" in
> > > > >https://bugs.debian.org/635777 or smbd.service "start/waiting" in
> > > > >https://launchpad.net/bugs/1417010.  This would completely avoid
> > > > >the deadlock in most situations already, and doesn't change the
> > > > >semantics for working use cases either, so this should even be
> > > > >applicable for upstream?
> > > > 
> > > > No, this would open up the door for races. The guarantee we give
> > > > around blocking operations, is that by the time they return the
> > > > operation or an equivalent has been executed. More specifically, if
> > > > you start a service, and it is in "starting", and then issue a
> > > > "reload" or "restart", and it returns you *know* that the
> > > > configuration that was on disk at the time you issued the "reload" or
> > > > "restart" -- or a newer one -- is in place. If you'd suppress the
> > > > reload/restart in this case, then you will not get that guarantee,
> > > > because the configuration ultimately loaded might be the one from the
> > > > time the daemon was first put into starting mode at.
> 
> You're missing an essential point here: there's a distinction between
> skipping reloads for services which have not not been dispatched, and
> skipping reloads for services for which startup code is already running
> (and may be using existing configuration) but which have not reached
> full "running" status yet.
> 
> The former is the correct behavior (but currently handled wrong by
> systemd!), and never causes races. Only the latter can cause races like
> described above.

These two cases aren't that different. If somebody pushes an
additional job into the queue that wants to run before the reload but
after the service is up you cannot ot flush out the reload just
because the service has not started yet... 

Whether you change config in your current context, or you do so from a
new unit's context is no difference: we cannot move anything that is
supposed to happen after that change before it, and we cannot remove it
either...

There are some forms of coalescing possible, but we already do all of
the ones that are safe...

> Fixing the systemd semantics should fix most of the bootup deadlock
> cases. This is not a "sysv workaround" or anything like that. The
> current systemd semantics are wrong and undesirable for new code,
> regardless of any legacy compatibility issues. Fixing them would give
> semantics that are more logically correct and work better in
> practice.

No, totally not. THe current semantics give the necessary guarantees
that changing a config file from any context you like or queing a file
config change from any config you like, and then queuing a reload will
take effect, regardless if there's a job for the unit already queued,
running or anything else.

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] Deadlocks with reloading jobs which are part of current transaction [was: [PATCH] Avoid reloading services when shutting down]

[Uoti Urpala]

On Wed, 2015-02-04 at 16:38 +0100, Lennart Poettering wrote:
> On Wed, 04.02.15 15:25, Martin Pitt (martin.p...@ubuntu.com) wrote:
> > Lennart Poettering [2015-02-04 13:27 +0100]:
> > > On Wed, 04.02.15 08:56, Martin Pitt (martin.p...@ubuntu.com) wrote:
> > > >  - Don't enqueue a reload if the service to be reloaded isn't running.
> > > >E. g. postfix.service "inactive/dead" in
> > > >https://bugs.debian.org/635777 or smbd.service "start/waiting" in
> > > >https://launchpad.net/bugs/1417010.  This would completely avoid
> > > >the deadlock in most situations already, and doesn't change the
> > > >semantics for working use cases either, so this should even be
> > > >applicable for upstream?
> > > 
> > > No, this would open up the door for races. The guarantee we give
> > > around blocking operations, is that by the time they return the
> > > operation or an equivalent has been executed. More specifically, if
> > > you start a service, and it is in "starting", and then issue a
> > > "reload" or "restart", and it returns you *know* that the
> > > configuration that was on disk at the time you issued the "reload" or
> > > "restart" -- or a newer one -- is in place. If you'd suppress the
> > > reload/restart in this case, then you will not get that guarantee,
> > > because the configuration ultimately loaded might be the one from the
> > > time the daemon was first put into starting mode at.

You're missing an essential point here: there's a distinction between
skipping reloads for services which have not not been dispatched, and
skipping reloads for services for which startup code is already running
(and may be using existing configuration) but which have not reached
full "running" status yet.

The former is the correct behavior (but currently handled wrong by
systemd!), and never causes races. Only the latter can cause races like
described above.

Fixing the systemd semantics should fix most of the bootup deadlock
cases. This is not a "sysv workaround" or anything like that. The
current systemd semantics are wrong and undesirable for new code,
regardless of any legacy compatibility issues. Fixing them would give
semantics that are more logically correct and work better in practice.

IIRC the smbd.service case was just a buggy circular service definition
and can not be reasonably fixed by any systemd-side semantics change; if
I remember that correctly, it should not be used as an example in any
discussion of systemd-side changes.


> > Hm, I don't quite understand this. If you reload a service which isn't
> > currently running, systemctl will fail. It's just currently going to
> > enqueue the reload request, and executing the job will fail due to the
> > "not active" check in unit_reload(). The problem with that is just
> > that systemctl doesn't fail immediately with "the unit is not active",
> > but blocks on the queued request. So if you don't have pending jobs,
> > the net result is the same, but with pending jobs you can easily get a
> > deadlock.
> 
> Again, if a "start" job is already queued and in progress of being
> dispatched, we need to queue the reload job, to get the right
> guarantess.
> 
> It's not that hard to see, is it?

You're correct about the "in progress of being dispatched" case, but the
problem case is when systemd incorrectly blocks when no client side code
using old configuration has been actually dispatched yet (only a queued
start inside systemd). The latter systemd misbehavior causes the
deadlocks. The "in progress of being dispatched" case typically does not
cause deadlocks, because the already running startup will normally
finish without blocking on anything, and then the new reload can run, so
there's no lock.


> We must execute the jobs in order. If there's start job in progress,
> or a reload job, and we queue a reload job, then we need to wait for
> the start job or reload job to finish, to begin with the new reload
> job. Otherwise you cannot give the guarantee I pointed out above.

Again, that's literally correct but talking about the wrong case. The
relevant case is the one where there ISN'T a "job in progress", only a
queued one.


This was discussed before, last mail being:
http://lists.freedesktop.org/archives/systemd-devel/2014-October/024612.html
(no replies to that one).


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

[systemd-devel] [PATCH] hwdb: Bind "toolbox" buttons to the Windows key

[Bastien Nocera]

One would expect pressing the button to go to an overview / show
applications mode, we thus map it to leftmeta, the Windows key.

See https://bugzilla.gnome.org/show_bug.cgi?id=658602#c17
---
 hwdb/60-keyboard.hwdb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hwdb/60-keyboard.hwdb b/hwdb/60-keyboard.hwdb
index 56fbbb1..94f36d9 100644
--- a/hwdb/60-keyboard.hwdb
+++ b/hwdb/60-keyboard.hwdb
@@ -590,7 +590,7 @@ 
keyboard:dmi:bvn*:bvr*:bd*:svnLENOVO*:pn*:pvrThinkPad*X2*Tablet*
 # ThinkPad X6 Tablet
 keyboard:dmi:bvn*:bvr*:bd*:svnLENOVO*:pnThinkPad*X6*:pvr*
  KEYBOARD_KEY_6c=direction  # rotate
- KEYBOARD_KEY_68=f13# toolbox
+ KEYBOARD_KEY_68=leftmeta   # toolbox
  KEYBOARD_KEY_6b=esc# escape
  KEYBOARD_KEY_6d=right  # right on d-pad
  KEYBOARD_KEY_6e=left   # left on d-pad
@@ -601,7 +601,7 @@ keyboard:dmi:bvn*:bvr*:bd*:svnLENOVO*:pnThinkPad*X6*:pvr*
 # ThinkPad X41 Tablet
 keyboard:dmi:bvn*:bvr*:bd*:svnIBM*:pn18666TU:pvr*
  KEYBOARD_KEY_6c=direction  # rotate
- KEYBOARD_KEY_68=f13# toolbox
+ KEYBOARD_KEY_68=leftmeta   # toolbox
  KEYBOARD_KEY_6b=esc# escape
  KEYBOARD_KEY_69=enter  # enter on d-pad
 
-- 
2.1.0


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

Re: [systemd-devel] [systemd-commits] src/timesync

[Zbigniew Jędrzejewski-Szmek]

On Wed, Feb 04, 2015 at 06:24:13PM +0100, Lennart Poettering wrote:
> On Wed, 04.02.15 18:18, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> 
> > On Wed, Feb 04, 2015 at 06:10:40PM +0100, Lennart Poettering wrote:
> > > On Wed, 04.02.15 17:09, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) 
> > > wrote:
> > > 
> > > > On Wed, Feb 04, 2015 at 08:06:44AM -0800, Lennart Poettering wrote:
> > > > >  src/timesync/timesyncd-manager.c |4 ++--
> > > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > > 
> > > > > New commits:
> > > > > commit 7e3254b3bae19221afefdb87b61ff92c755fd2f4
> > > > > Author: Lennart Poettering 
> > > > > Date:   Wed Feb 4 17:00:23 2015 +0100
> > > > > 
> > > > > timesyncd: downgrade more log messages from LOG_INFO to LOG_DEBUG
> > > > > 
> > > > > https://bugs.freedesktop.org/show_bug.cgi?id=87505
> > > > > 
> > > > > Let's make timesyncd less chatty.
> > > > > 
> > > > > diff --git a/src/timesync/timesyncd-manager.c 
> > > > > b/src/timesync/timesyncd-manager.c
> > > > > index d3c62c9..223671c 100644
> > > > > --- a/src/timesync/timesyncd-manager.c
> > > > > +++ b/src/timesync/timesyncd-manager.c
> > > > > @@ -285,7 +285,7 @@ static int manager_clock_watch(sd_event_source 
> > > > > *source, int fd, uint32_t revents
> > > > >  }
> > > > >  
> > > > >  /* resync */
> > > > > -log_info("System time changed. Resyncing.");
> > > > > +log_debug("System time changed. Resyncing.");
> > > > >  m->poll_resync = true;
> > > > >  
> > > > >  return manager_send_request(m);
> > > > > @@ -740,7 +740,7 @@ static int manager_begin(Manager *m) {
> > > > >  m->poll_interval_usec = NTP_POLL_INTERVAL_MIN_SEC * 
> > > > > USEC_PER_SEC;
> > > > >  
> > > > >  server_address_pretty(m->current_server_address, &pretty);
> > > > > -log_info("Using NTP server %s (%s).", strna(pretty), 
> > > > > m->current_server_name->string);
> > > > > +log_debug("Using NTP server %s (%s).", strna(pretty), 
> > > > > m->current_server_name->string);
> > > > >  sd_notifyf(false, "STATUS=Using Time Server %s (%s).", 
> > > > > strna(pretty), m->current_server_name->string);
> > > > 
> > > > Hm, but isn't the problem elsewhere? The bug report stated that ipv6
> > > > router advertisements cause timesyncd to resync, spamming the time 
> > > > servers.
> > > 
> > > Indeed. Reopened.
> > > 
> > > Not sure what the right approach here is though...
> >
> > Maybe we should just set a flag and ignore network changes until the
> > normal time for the next sync comes, if we were already sucessfully
> > synced.
> 
> Hmm, what about this:
> 
> - If we managed to get a successful sync, don't act on the event, just
>   wait for the next normal resync
That's what I meant.

> - If we did not manage to get a successful sync, try again
>   immediately, but not any more often than once per 10s or so...
I think we should fall back here too, maybe more slowly. In case we can't
connect, we shouldn't spam the network too much.

> I think this should make the thing pretty robust and responsive to
> network changes when necessary, but not flood the network needlessly?

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

Re: [systemd-devel] [systemd-commits] src/timesync

[Lennart Poettering]

On Wed, 04.02.15 18:18, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> On Wed, Feb 04, 2015 at 06:10:40PM +0100, Lennart Poettering wrote:
> > On Wed, 04.02.15 17:09, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) 
> > wrote:
> > 
> > > On Wed, Feb 04, 2015 at 08:06:44AM -0800, Lennart Poettering wrote:
> > > >  src/timesync/timesyncd-manager.c |4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > New commits:
> > > > commit 7e3254b3bae19221afefdb87b61ff92c755fd2f4
> > > > Author: Lennart Poettering 
> > > > Date:   Wed Feb 4 17:00:23 2015 +0100
> > > > 
> > > > timesyncd: downgrade more log messages from LOG_INFO to LOG_DEBUG
> > > > 
> > > > https://bugs.freedesktop.org/show_bug.cgi?id=87505
> > > > 
> > > > Let's make timesyncd less chatty.
> > > > 
> > > > diff --git a/src/timesync/timesyncd-manager.c 
> > > > b/src/timesync/timesyncd-manager.c
> > > > index d3c62c9..223671c 100644
> > > > --- a/src/timesync/timesyncd-manager.c
> > > > +++ b/src/timesync/timesyncd-manager.c
> > > > @@ -285,7 +285,7 @@ static int manager_clock_watch(sd_event_source 
> > > > *source, int fd, uint32_t revents
> > > >  }
> > > >  
> > > >  /* resync */
> > > > -log_info("System time changed. Resyncing.");
> > > > +log_debug("System time changed. Resyncing.");
> > > >  m->poll_resync = true;
> > > >  
> > > >  return manager_send_request(m);
> > > > @@ -740,7 +740,7 @@ static int manager_begin(Manager *m) {
> > > >  m->poll_interval_usec = NTP_POLL_INTERVAL_MIN_SEC * 
> > > > USEC_PER_SEC;
> > > >  
> > > >  server_address_pretty(m->current_server_address, &pretty);
> > > > -log_info("Using NTP server %s (%s).", strna(pretty), 
> > > > m->current_server_name->string);
> > > > +log_debug("Using NTP server %s (%s).", strna(pretty), 
> > > > m->current_server_name->string);
> > > >  sd_notifyf(false, "STATUS=Using Time Server %s (%s).", 
> > > > strna(pretty), m->current_server_name->string);
> > > 
> > > Hm, but isn't the problem elsewhere? The bug report stated that ipv6
> > > router advertisements cause timesyncd to resync, spamming the time 
> > > servers.
> > 
> > Indeed. Reopened.
> > 
> > Not sure what the right approach here is though...
>
> Maybe we should just set a flag and ignore network changes until the
> normal time for the next sync comes, if we were already sucessfully
> synced.

Hmm, what about this:

- If we managed to get a successful sync, don't act on the event, just
  wait for the next normal resync

- If we did not manage to get a successful sync, try again
  immediately, but not any more often than once per 10s or so...

I think this should make the thing pretty robust and responsive to
network changes when necessary, but not flood the network needlessly?

Makes 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 1/2] Add sd_event_loop_timeout to sd_event

[Lennart Poettering]

On Wed, 04.02.15 17:40, Didier Roche (didro...@ubuntu.com) wrote:

> Le 04/02/2015 17:10, Lennart Poettering a écrit :
> >On Wed, 04.02.15 17:05, Didier Roche (didro...@ubuntu.com) wrote:
> >
> >>Hey,
> >>
> >>I rewrote a version of this patch including the feedback on the list. As per
> >>IRC discussion, (and after giving up the busy loop for a rewrite with
> >>epool), I did rebase it again on sd_event.
> >>
> >>I'm only proposing there up for review the 2 first patches (without plymouth
> >>communication, cancel support, i18n, man pages and the service and socket)
> >>so that I don't have to rebase all other 10 patches on a moving
> >>ground.
> >Tom just added support for installing timer events with a NULL
> >callback, that trigger event loop exit. I kinda prefer that solution
> >over a new call sd_event_loop() with timeout.
> >
> >  sd_event_add_time(event, NULL, CLOCK_MONOTONIC, now(CLOCK_MONOTONIC) + 
> > 5 * USEC_PER_SEC, NULL, NULL);
> 
> So, it means that I need to reset it after any received activity, is that
> ok? (as this will be really frequent as each clients in parallel can send a
> message each 50ms). The goal is to have a global "inactivity" timeout.
> 
> I didn't see a way to cancel this event source though?

Oh, I see, you actually want a real idle logic, not just a normal
timer.

So far, for daemons like timedated, localed and so on, we are using an
idle logic that is implemented in bus_event_loop_with_idle() in
src/libsystemd/sd-bus/bus-util.c. It does considerably more than what
you need (since it contains all the magic to racefully do exit-on-idle
for bus services so that no bus messages are lost). 

I think the best would be to take inspiration from that code, isolate
there basic minimum out of it, without all the dbus logic, and then
stick that in your C file.

We can generalize such exit-on-idle logic one day, somewhere between
sd-bus and sd-event, but that requires considerabe design work, so
that we find a generic solution that works for you and also covers
this dbus case without hacks. For now it's hence better if you just
take inspiration from bus_event_loop_with_idle(), drop all the
bus-specific bits, and stick it in your .c 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] [systemd-commits] src/timesync

[Zbigniew Jędrzejewski-Szmek]

On Wed, Feb 04, 2015 at 06:10:40PM +0100, Lennart Poettering wrote:
> On Wed, 04.02.15 17:09, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> 
> > On Wed, Feb 04, 2015 at 08:06:44AM -0800, Lennart Poettering wrote:
> > >  src/timesync/timesyncd-manager.c |4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > 
> > > New commits:
> > > commit 7e3254b3bae19221afefdb87b61ff92c755fd2f4
> > > Author: Lennart Poettering 
> > > Date:   Wed Feb 4 17:00:23 2015 +0100
> > > 
> > > timesyncd: downgrade more log messages from LOG_INFO to LOG_DEBUG
> > > 
> > > https://bugs.freedesktop.org/show_bug.cgi?id=87505
> > > 
> > > Let's make timesyncd less chatty.
> > > 
> > > diff --git a/src/timesync/timesyncd-manager.c 
> > > b/src/timesync/timesyncd-manager.c
> > > index d3c62c9..223671c 100644
> > > --- a/src/timesync/timesyncd-manager.c
> > > +++ b/src/timesync/timesyncd-manager.c
> > > @@ -285,7 +285,7 @@ static int manager_clock_watch(sd_event_source 
> > > *source, int fd, uint32_t revents
> > >  }
> > >  
> > >  /* resync */
> > > -log_info("System time changed. Resyncing.");
> > > +log_debug("System time changed. Resyncing.");
> > >  m->poll_resync = true;
> > >  
> > >  return manager_send_request(m);
> > > @@ -740,7 +740,7 @@ static int manager_begin(Manager *m) {
> > >  m->poll_interval_usec = NTP_POLL_INTERVAL_MIN_SEC * 
> > > USEC_PER_SEC;
> > >  
> > >  server_address_pretty(m->current_server_address, &pretty);
> > > -log_info("Using NTP server %s (%s).", strna(pretty), 
> > > m->current_server_name->string);
> > > +log_debug("Using NTP server %s (%s).", strna(pretty), 
> > > m->current_server_name->string);
> > >  sd_notifyf(false, "STATUS=Using Time Server %s (%s).", 
> > > strna(pretty), m->current_server_name->string);
> > 
> > Hm, but isn't the problem elsewhere? The bug report stated that ipv6
> > router advertisements cause timesyncd to resync, spamming the time servers.
> 
> Indeed. Reopened.
> 
> Not sure what the right approach here is though...
Maybe we should just set a flag and ignore network changes until the
normal time for the next sync comes, if we were already sucessfully
synced.

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

Re: [systemd-devel] [systemd-commits] src/timesync

[Lennart Poettering]

On Wed, 04.02.15 17:09, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> On Wed, Feb 04, 2015 at 08:06:44AM -0800, Lennart Poettering wrote:
> >  src/timesync/timesyncd-manager.c |4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > New commits:
> > commit 7e3254b3bae19221afefdb87b61ff92c755fd2f4
> > Author: Lennart Poettering 
> > Date:   Wed Feb 4 17:00:23 2015 +0100
> > 
> > timesyncd: downgrade more log messages from LOG_INFO to LOG_DEBUG
> > 
> > https://bugs.freedesktop.org/show_bug.cgi?id=87505
> > 
> > Let's make timesyncd less chatty.
> > 
> > diff --git a/src/timesync/timesyncd-manager.c 
> > b/src/timesync/timesyncd-manager.c
> > index d3c62c9..223671c 100644
> > --- a/src/timesync/timesyncd-manager.c
> > +++ b/src/timesync/timesyncd-manager.c
> > @@ -285,7 +285,7 @@ static int manager_clock_watch(sd_event_source *source, 
> > int fd, uint32_t revents
> >  }
> >  
> >  /* resync */
> > -log_info("System time changed. Resyncing.");
> > +log_debug("System time changed. Resyncing.");
> >  m->poll_resync = true;
> >  
> >  return manager_send_request(m);
> > @@ -740,7 +740,7 @@ static int manager_begin(Manager *m) {
> >  m->poll_interval_usec = NTP_POLL_INTERVAL_MIN_SEC * 
> > USEC_PER_SEC;
> >  
> >  server_address_pretty(m->current_server_address, &pretty);
> > -log_info("Using NTP server %s (%s).", strna(pretty), 
> > m->current_server_name->string);
> > +log_debug("Using NTP server %s (%s).", strna(pretty), 
> > m->current_server_name->string);
> >  sd_notifyf(false, "STATUS=Using Time Server %s (%s).", 
> > strna(pretty), m->current_server_name->string);
> 
> Hm, but isn't the problem elsewhere? The bug report stated that ipv6
> router advertisements cause timesyncd to resync, spamming the time servers.

Indeed. Reopened.

Not sure what the right approach here is though...

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 2/2] fsckd daemon for inter-fsckd communication

[Zbigniew Jędrzejewski-Szmek]

On Wed, Feb 04, 2015 at 05:50:29PM +0100, Didier Roche wrote:
> Le 04/02/2015 17:24, Zbigniew Jędrzejewski-Szmek a écrit :
> 
> Thanks again for the quick review! Fixed if not commented (sorry,
> some issues were back due to the refactoring).
> >On Wed, Feb 04, 2015 at 05:06:45PM +0100, Didier Roche wrote:
> >>+typedef struct Clients {
> >>+struct Manager *manager;
> >>+int fd;
> >>+dev_t devnum;
> >>+size_t cur;
> >>+size_t max;
> >>+int pass;
> >>+double percent;
> >>+size_t buflen;
> >>+
> >>+LIST_FIELDS(struct Clients, clients);
> >>+} Clients;
> >Would be better to call this Client.
> >
> >>+typedef struct Manager {
> >>+sd_event *event;
> >>+Clients *clients;
> >But still 'Client *clients' here.
> 
> Right, I can't decide (due to the list) what's the best one, what do
> you think?
We use singular in other cases like this.

> >>+if (!client)
> >>+return log_oom();
> >>+client->fd = new_client_fd;
> >>+client->manager = m;
> >>+LIST_PREPEND(clients, m->clients, client);
> >>+r = sd_event_add_io(m->event, NULL, client->fd, EPOLLIN, 
> >>progress_handler, client);
> >>+if (r < 0) {
> >>+remove_client(&(m->clients), client);
> >>+return r;
> >>+}
> >I think you can do this in opposite order, and then the clean-up will
> >not be necessary.
> I need to delete the client item and close the new fd (which is part
> of remove_client()), and I can't assign the add_io event before the
> client instantiated. So, it will be another free() + safe_close()
> rather then remove_client(). Does it makes sense still to add this?
I guess no.

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

Re: [systemd-devel] [PATCH 2/2] fsckd daemon for inter-fsckd communication

[Didier Roche]

Le 04/02/2015 17:24, Zbigniew Jędrzejewski-Szmek a écrit :

Thanks again for the quick review! Fixed if not commented (sorry, some 
issues were back due to the refactoring).

On Wed, Feb 04, 2015 at 05:06:45PM +0100, Didier Roche wrote:

+typedef struct Clients {
+struct Manager *manager;
+int fd;
+dev_t devnum;
+size_t cur;
+size_t max;
+int pass;
+double percent;
+size_t buflen;
+
+LIST_FIELDS(struct Clients, clients);
+} Clients;

Would be better to call this Client.


+typedef struct Manager {
+sd_event *event;
+Clients *clients;

But still 'Client *clients' here.


Right, I can't decide (due to the list) what's the best one, what do you 
think?

+if (!client)
+return log_oom();
+client->fd = new_client_fd;
+client->manager = m;
+LIST_PREPEND(clients, m->clients, client);
+r = sd_event_add_io(m->event, NULL, client->fd, EPOLLIN, 
progress_handler, client);
+if (r < 0) {
+remove_client(&(m->clients), client);
+return r;
+}

I think you can do this in opposite order, and then the clean-up will
not be necessary.
I need to delete the client item and close the new fd (which is part of 
remove_client()), and I can't assign the add_io event before the client 
instantiated. So, it will be another free() + safe_close() rather then 
remove_client(). Does it makes sense still to add this?





+typedef struct FsckProgress {
+dev_t devnum;
+unsigned long cur;
+unsigned long max;
+int pass;
+} FsckProgress;

I think I asked about that before, but not 100% sure: shouldn't those be size_t?
If they are disk offsets, than long is not enough.


Sorry, I only changed it in fsckd.c and fsck.c, done in the passing 
struct now.


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

Re: [systemd-devel] Deadlocks with reloading jobs which are part of current transaction [was: [PATCH] Avoid reloading services when shutting down]

[Martin Pitt]

Lennart Poettering [2015-02-04 16:38 +0100]:
> Sure, I can only recommend again: in the the glue code that calls out
> to "systemctl" from "service", you can add the code to use --no-block
> or --job-mode=ignore-dependencies , if you notice you are in shutdown
> mode...

Yeah, I agree that given all the options that's the best heuristics
for now.

> > > Modern code, that talks directly to systemctl, that uses hook scripts,
> > > should always use --no-block for these cases.
> > 
> > Yeah, for sure. We just don't have that luxury easily, as first these
> > scripts don't call systemctl but "service" (for the Debianists: or
> > invoke-rc.d, but same difference), it will take some time to find
> > all these occurrences, and people will hate us for having to add stuff
> > like
> > 
> >   if (running under systemd)
> >systemctl --no-block reload foo
> >   else
> >service foo reload
> 
> I am not proposing anything like that.

Right, this was just a reply to "modern code that talks directly to
systemctl", and we can't do that while we support more than one init
system. Sorry for the misunderstanding.

> > > >  - Don't enqueue a reload if the service to be reloaded isn't running.
> > > >E. g. postfix.service "inactive/dead" in
> > > >https://bugs.debian.org/635777 or smbd.service "start/waiting" in
> > > >https://launchpad.net/bugs/1417010.  This would completely avoid
> > > >the deadlock in most situations already, and doesn't change the
> > > >semantics for working use cases either, so this should even be
> > > >applicable for upstream?

For the record, this was already discussed here:
http://lists.freedesktop.org/archives/systemd-devel/2014-July/021457.html
continuation:
http://lists.freedesktop.org/archives/systemd-devel/2014-August/022048.html

> I mean, if you want precise sysv semantics you can just use
> --job-mode=ignore-dependencies always, since sysv ignore all deps too
> when sysv scripts are involved.

"Always" sounds rather unsafe to me, as we would totally ignore a
unit's Requires/Wants= then. Doing it if !systemctl is-system-running
sounds ok.

> I'd strongly encourage you to work around this on client side in the
> sysv glue, not breaking the guarantess that systemd-aware code needs
> when issuing commands.

Yes, I prefer that as well. (That's what I meant with "distro side"..)

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 1/2] Add sd_event_loop_timeout to sd_event

[Didier Roche]

Le 04/02/2015 17:10, Lennart Poettering a écrit :

On Wed, 04.02.15 17:05, Didier Roche (didro...@ubuntu.com) wrote:


Hey,

I rewrote a version of this patch including the feedback on the list. As per
IRC discussion, (and after giving up the busy loop for a rewrite with
epool), I did rebase it again on sd_event.

I'm only proposing there up for review the 2 first patches (without plymouth
communication, cancel support, i18n, man pages and the service and socket)
so that I don't have to rebase all other 10 patches on a moving
ground.

Tom just added support for installing timer events with a NULL
callback, that trigger event loop exit. I kinda prefer that solution
over a new call sd_event_loop() with timeout.

  sd_event_add_time(event, NULL, CLOCK_MONOTONIC, now(CLOCK_MONOTONIC) + 5 
* USEC_PER_SEC, NULL, NULL);


So, it means that I need to reset it after any received activity, is 
that ok? (as this will be really frequent as each clients in parallel 
can send a message each 50ms). The goal is to have a global "inactivity" 
timeout.


I didn't see a way to cancel this event source though?
Didier



That line should be enough to mak an even loop exit after 5s...

Lennart



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

Re: [systemd-devel] [PATCH 2/2] fsckd daemon for inter-fsckd communication

[Zbigniew Jędrzejewski-Szmek]

On Wed, Feb 04, 2015 at 05:06:45PM +0100, Didier Roche wrote:
> +typedef struct Clients {
> +struct Manager *manager;
> +int fd;
> +dev_t devnum;
> +size_t cur;
> +size_t max;
> +int pass;
> +double percent;
> +size_t buflen;
> +
> +LIST_FIELDS(struct Clients, clients);
> +} Clients;
Would be better to call this Client.

> +typedef struct Manager {
> +sd_event *event;
> +Clients *clients;
But still 'Client *clients' here.

> +if ((fabs(current_percent - m->percent) > 0.01) || 
> (current_numdevices != m->numdevices)) {
Again, too much parens.

> +client = malloc(sizeof(Clients));
new0(Client, 1)

(Unless you initialize all fields, it's better to zero out the structure.)

> +if (!client)
> +return log_oom();
> +client->fd = new_client_fd;
> +client->manager = m;
> +LIST_PREPEND(clients, m->clients, client);
> +r = sd_event_add_io(m->event, NULL, client->fd, EPOLLIN, 
> progress_handler, client);
> +if (r < 0) {
> +remove_client(&(m->clients), client);
> +return r;
> +}
I think you can do this in opposite order, and then the clean-up will
not be necessary.

> +m = new0(Manager, 1);
> +if (!m)
> +return -ENOMEM;
> +
> +r = sd_event_default(&m->event);
> +if (r < 0)
> +return r;
> +
> +m->clients = NULL;
> +m->connection_fd = fd;
> +
> +m->console = fopen("/dev/console", "we");
> +if (!m->console)
> +return log_error_errno(errno, "Can't connect to 
> /dev/console: %m");
> +m->percent = 100;
> +m->numdevices = 0;
> +m->clear = 0;
Since structure is initialized to zero, there's no need to set stuff to 0 again.

> +typedef struct FsckProgress {
> +dev_t devnum;
> +unsigned long cur;
> +unsigned long max;
> +int pass;
> +} FsckProgress;
I think I asked about that before, but not 100% sure: shouldn't those be size_t?
If they are disk offsets, than long is not enough.

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

Re: [systemd-devel] [PATCH 1/2] Add sd_event_loop_timeout to sd_event

[Lennart Poettering]

On Wed, 04.02.15 17:05, Didier Roche (didro...@ubuntu.com) wrote:

> Hey,
> 
> I rewrote a version of this patch including the feedback on the list. As per
> IRC discussion, (and after giving up the busy loop for a rewrite with
> epool), I did rebase it again on sd_event.
> 
> I'm only proposing there up for review the 2 first patches (without plymouth
> communication, cancel support, i18n, man pages and the service and socket)
> so that I don't have to rebase all other 10 patches on a moving
> ground.

Tom just added support for installing timer events with a NULL
callback, that trigger event loop exit. I kinda prefer that solution
over a new call sd_event_loop() with timeout.

 sd_event_add_time(event, NULL, CLOCK_MONOTONIC, now(CLOCK_MONOTONIC) + 5 * 
USEC_PER_SEC, NULL, NULL);

That line should be enough to mak an even loop exit after 5s...

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-commits] src/timesync

[Zbigniew Jędrzejewski-Szmek]

On Wed, Feb 04, 2015 at 08:06:44AM -0800, Lennart Poettering wrote:
>  src/timesync/timesyncd-manager.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> New commits:
> commit 7e3254b3bae19221afefdb87b61ff92c755fd2f4
> Author: Lennart Poettering 
> Date:   Wed Feb 4 17:00:23 2015 +0100
> 
> timesyncd: downgrade more log messages from LOG_INFO to LOG_DEBUG
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=87505
> 
> Let's make timesyncd less chatty.
> 
> diff --git a/src/timesync/timesyncd-manager.c 
> b/src/timesync/timesyncd-manager.c
> index d3c62c9..223671c 100644
> --- a/src/timesync/timesyncd-manager.c
> +++ b/src/timesync/timesyncd-manager.c
> @@ -285,7 +285,7 @@ static int manager_clock_watch(sd_event_source *source, 
> int fd, uint32_t revents
>  }
>  
>  /* resync */
> -log_info("System time changed. Resyncing.");
> +log_debug("System time changed. Resyncing.");
>  m->poll_resync = true;
>  
>  return manager_send_request(m);
> @@ -740,7 +740,7 @@ static int manager_begin(Manager *m) {
>  m->poll_interval_usec = NTP_POLL_INTERVAL_MIN_SEC * 
> USEC_PER_SEC;
>  
>  server_address_pretty(m->current_server_address, &pretty);
> -log_info("Using NTP server %s (%s).", strna(pretty), 
> m->current_server_name->string);
> +log_debug("Using NTP server %s (%s).", strna(pretty), 
> m->current_server_name->string);
>  sd_notifyf(false, "STATUS=Using Time Server %s (%s).", 
> strna(pretty), m->current_server_name->string);

Hm, but isn't the problem elsewhere? The bug report stated that ipv6
router advertisements cause timesyncd to resync, spamming the time servers.

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

[systemd-devel] [PATCH 1/2] Add sd_event_loop_timeout to sd_event

[Didier Roche]

Hey,

I rewrote a version of this patch including the feedback on the list. As 
per IRC discussion, (and after giving up the busy loop for a rewrite 
with epool), I did rebase it again on sd_event.


I'm only proposing there up for review the 2 first patches (without 
plymouth communication, cancel support, i18n, man pages and the service 
and socket) so that I don't have to rebase all other 10 patches on a 
moving ground.


I'm opened to any feedback and fixes to do :)
Cheers,
Didier
>From 52d3c92280ec6198a0566bd3a077c0fbb6990782 Mon Sep 17 00:00:00 2001
From: Didier Roche 
Date: Wed, 4 Feb 2015 16:40:44 +0100
Subject: [PATCH 1/2] Add sd_event_loop_timeout to sd_event

sd_event_loop_timeout adds a timeout parameter to sd_event_loop() to timeout
the whole event loop after some time of inactivity.
---
 src/libsystemd/sd-event/sd-event.c | 10 +++---
 src/systemd/sd-event.h |  1 +
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/src/libsystemd/sd-event/sd-event.c b/src/libsystemd/sd-event/sd-event.c
index f9fa54d..8dd3e16 100644
--- a/src/libsystemd/sd-event/sd-event.c
+++ b/src/libsystemd/sd-event/sd-event.c
@@ -2496,7 +2496,7 @@ _public_ int sd_event_run(sd_event *e, uint64_t timeout) {
 return r;
 }
 
-_public_ int sd_event_loop(sd_event *e) {
+_public_ int sd_event_loop_timeout(sd_event *e, uint64_t timeout) {
 int r;
 
 assert_return(e, -EINVAL);
@@ -2506,8 +2506,8 @@ _public_ int sd_event_loop(sd_event *e) {
 sd_event_ref(e);
 
 while (e->state != SD_EVENT_FINISHED) {
-r = sd_event_run(e, (uint64_t) -1);
-if (r < 0)
+r = sd_event_run(e, timeout);
+if (r < 0 || (r == 0 && timeout != (uint64_t) -1))
 goto finish;
 }
 
@@ -2518,6 +2518,10 @@ finish:
 return r;
 }
 
+_public_ int sd_event_loop(sd_event *e) {
+return sd_event_loop_timeout(e, (uint64_t) -1);
+}
+
 _public_ int sd_event_get_fd(sd_event *e) {
 
 assert_return(e, -EINVAL);
diff --git a/src/systemd/sd-event.h b/src/systemd/sd-event.h
index 25a10f9..53e2382 100644
--- a/src/systemd/sd-event.h
+++ b/src/systemd/sd-event.h
@@ -90,6 +90,7 @@ int sd_event_prepare(sd_event *e);
 int sd_event_wait(sd_event *e, uint64_t timeout);
 int sd_event_dispatch(sd_event *e);
 int sd_event_run(sd_event *e, uint64_t timeout);
+int sd_event_loop_timeout(sd_event *e, uint64_t timeout);
 int sd_event_loop(sd_event *e);
 int sd_event_exit(sd_event *e, int code);
 
-- 
2.1.4

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

[systemd-devel] [PATCH 2/2] fsckd daemon for inter-fsckd communication

[Didier Roche]

>From 74291bace60f64efb96287f8170df4c38058cc46 Mon Sep 17 00:00:00 2001
From: Didier Roche 
Date: Wed, 4 Feb 2015 16:42:47 +0100
Subject: [PATCH 2/2] fsckd daemon for inter-fsckd communication

Add systemd-fsckd multiplexer which accepts multiple systemd-fsck
instances to connect to it and sends progress report. systemd-fsckd then
computes and writes to /dev/console the number of devices currently being
checked and the minimum fsck progress. This will be used for interactive
progress report and cancelling in plymouth.

systemd-fsckd stops on idle when no systemd-fsck is connected.

Make the necessary changes to systemd-fsck to connect to the systemd-fsckd
socket.
---
 .gitignore |   1 +
 Makefile.am|  13 ++
 src/fsck/fsck.c|  88 +
 src/fsckd/Makefile |   1 +
 src/fsckd/fsckd.c  | 370 +
 src/fsckd/fsckd.h  |  34 +
 6 files changed, 453 insertions(+), 54 deletions(-)
 create mode 12 src/fsckd/Makefile
 create mode 100644 src/fsckd/fsckd.c
 create mode 100644 src/fsckd/fsckd.h

diff --git a/.gitignore b/.gitignore
index ab6d9d1..9400e75 100644
--- a/.gitignore
+++ b/.gitignore
@@ -74,6 +74,7 @@
 /systemd-evcat
 /systemd-firstboot
 /systemd-fsck
+/systemd-fsckd
 /systemd-fstab-generator
 /systemd-getty-generator
 /systemd-gnome-ask-password-agent
diff --git a/Makefile.am b/Makefile.am
index c463f23..e0e8bc6 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -389,6 +389,7 @@ rootlibexec_PROGRAMS = \
 	systemd-remount-fs \
 	systemd-reply-password \
 	systemd-fsck \
+	systemd-fsckd \
 	systemd-machine-id-commit \
 	systemd-ac-power \
 	systemd-sysctl \
@@ -2355,6 +2356,18 @@ systemd_fsck_LDADD = \
 	libsystemd-shared.la
 
 # --
+systemd_fsckd_SOURCES = \
+	src/fsckd/fsckd.c \
+	$(NULL)
+
+systemd_fsckd_LDADD = \
+	libsystemd-internal.la \
+	libsystemd-label.la \
+	libsystemd-shared.la \
+	libudev-internal.la \
+	$(NULL)
+
+# --
 systemd_machine_id_commit_SOURCES = \
 	src/machine-id-commit/machine-id-commit.c \
 	src/core/machine-id-setup.c \
diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
index 20b7940..9d9739b 100644
--- a/src/fsck/fsck.c
+++ b/src/fsck/fsck.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "sd-bus.h"
 #include "libudev.h"
@@ -39,6 +40,8 @@
 #include "fileio.h"
 #include "udev-util.h"
 #include "path-util.h"
+#include "socket-util.h"
+#include "fsckd/fsckd.h"
 
 static bool arg_skip = false;
 static bool arg_force = false;
@@ -132,58 +135,42 @@ static void test_files(void) {
 arg_show_progress = true;
 }
 
-static double percent(int pass, unsigned long cur, unsigned long max) {
-/* Values stolen from e2fsck */
-
-static const int pass_table[] = {
-0, 70, 90, 92, 95, 100
+static int process_progress(int fd, dev_t device_num) {
+_cleanup_fclose_ FILE *f = NULL;
+usec_t last = 0;
+_cleanup_close_ int fsckd_fd = -1;
+static const union sockaddr_union sa = {
+.un.sun_family = AF_UNIX,
+.un.sun_path = FSCKD_SOCKET_PATH,
 };
 
-if (pass <= 0)
-return 0.0;
-
-if ((unsigned) pass >= ELEMENTSOF(pass_table) || max == 0)
-return 100.0;
-
-return (double) pass_table[pass-1] +
-((double) pass_table[pass] - (double) pass_table[pass-1]) *
-(double) cur / (double) max;
-}
-
-static int process_progress(int fd) {
-_cleanup_fclose_ FILE *console = NULL, *f = NULL;
-usec_t last = 0;
-bool locked = false;
-int clear = 0;
+fsckd_fd = socket(AF_UNIX, SOCK_STREAM | SOCK_CLOEXEC, 0);
+if (fsckd_fd < 0) {
+log_warning_errno(errno, "Cannot open fsckd socket, we won't report fsck progress: %m");
+return -errno;
+}
+if (connect(fsckd_fd, &sa.sa, offsetof(struct sockaddr_un, sun_path) + strlen(sa.un.sun_path)) < 0) {
+log_warning_errno(errno, "Cannot connect to fsckd socket, we won't report fsck progress: %m");
+return -errno;
+}
 
 f = fdopen(fd, "r");
 if (!f) {
-safe_close(fd);
+log_warning_errno(errno, "Cannot connect to fsck, we won't report fsck progress: %m");
 return -errno;
 }
 
-console = fopen("/dev/console", "we");
-if (!console)
-return -ENOMEM;
-
 while (!feof(f)) {
-int pass, m;
-unsigned long cur, max;
-_cleanup_free_ char *device = NULL;
-double p;
+int pass;
+size_t cur, max;
+ssize_t n;
 usec_t t;
+_cleanup_free_ char *device = NULL;
+Fsck

Re: [systemd-devel] [PATCHv2] sysctl: consider --prefix while parsing the files

[Zbigniew Jędrzejewski-Szmek]

On Wed, Feb 04, 2015 at 03:50:01PM +0100, Umut Tezduyar Lindskog wrote:
> not while applying the parsed sysctl values. Otherwise
> info "Overwriting earlier assignment of %s in file %s" is
> visible many times even though the given --prefix doesn't
> try to set the overridden value.
> ---
>  src/sysctl/sysctl.c | 32 
>  1 file changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/src/sysctl/sysctl.c b/src/sysctl/sysctl.c
> index 973e67e..b22aff5 100644
> --- a/src/sysctl/sysctl.c
> +++ b/src/sysctl/sysctl.c
> @@ -78,22 +78,6 @@ static int apply_sysctl(const char *property, const char 
> *value) {
>  n = stpcpy(p, "/proc/sys/");
>  strcpy(n, property);
>  
> -if (!strv_isempty(arg_prefixes)) {
> -char **i;
> -bool good = false;
> -
> -STRV_FOREACH(i, arg_prefixes)
> -if (path_startswith(p, *i)) {
> -good = true;
> -break;
> -}
> -
> -if (!good) {
> -log_debug("Skipping %s", p);
> -return 0;
> -}
> -}
> -
>  k = write_string_file(p, value);
>  if (k < 0) {
>  log_full(k == -ENOENT ? LOG_DEBUG : LOG_WARNING,
> @@ -173,6 +157,22 @@ static int parse_file(Hashmap *sysctl_options, const 
> char *path, bool ignore_eno
>  p = normalize_sysctl(strstrip(p));
>  value = strstrip(value);
>  
> +if (!strv_isempty(arg_prefixes)) {
> +char **i, *t;
> +bool good = false;
> +STRV_FOREACH(i, arg_prefixes) {
> +t = path_startswith(*i, "/proc/sys/");
> +if (t == NULL)
> +t = *i;
> +if (path_startswith(p, t)) {
> +good = true;
> +break;
> +}
> +}
> +if (!good)
> +continue;
> +}
While at it, wouldn't it be better to use a goto and do away with the
good variable. This will give a diff of -7/+3, a win also for readability imho.

Zbyszek
   

> +
>  existing = hashmap_get2(sysctl_options, p, &v);
>  if (existing) {
>  if (streq(value, existing))
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /proc and /sys get unmounted during boot from NFS, which results in boot error

[Lennart Poettering]

On Wed, 04.02.15 15:29, Olaf Leidinger (ol...@mescharet.de) wrote:

> Hey!
> 
> > Maybe something from your initrd is acting weird?
> 
> As far as I can tell, nothing from the initrd is running. It's
> basically ArchLinux's mkinitcpio run on gentoo - thus, pretty
> standard stuff.

"ps" should tell you what else is running when you run into this.

> So somehow these system calls must trigger the unmount. Probably some process 
> which 
> gets started by systemd performs similar system calls and thus
> spoils my boot.

The dumps you posted show no difference really...

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] Restart sequence: "systemctl restart rsyslog.service syslog.socket" often/sometimes fails

[Lennart Poettering]

On Wed, 04.02.15 15:53, Peter Valdemar Mørch (pe...@morch.com) wrote:

> On Wed, Feb 4, 2015 at 2:34 PM, Lennart Poettering
>  wrote:
> > This is something that can be fixed by adding stricter deps between
> > the service and the socket, so that the socket is always required to
> > be started before the service. Something for the respective package
> > maintainers upstream to fix.
> 
> So have I understood this correctly: That the order matters *is* a
> bug. Either in systemd (that provides
> /lib/systemd/system/syslog.socket) or in syslog-ng and rsyslog that
> provide e.g. /lib/systemd/system/syslog-ng.service ?

The latter.

> I'm worried that we manually have to figure out the correct ordering
> of names to "systemctl restart PATTERN" and would like to be able
> to rely on systemctl to figure that out for us. Is that a reasonable
> long-term expectation? (And the reason order/sequence isn't mentioned
> in the man page?)

systemd follows the relations expressed via the deps. If you don't
tell systemd the right deps, then things will be executed in any
order, and things might not work.

> I have no idea what they *should* be, but to show what they *are*,
> here i show for syslog-ng. Seems to me that syslog-ng is clear about
> syslog.socket being a dependency:

It would be a good idea to add Requires=syslog.socket here (or even
BindsTo=syslog.socket), as well as After=syslog.socket...

> > cat /lib/systemd/system/syslog-ng.service
> [Unit]
> Description=System Logger Daemon
> Documentation=man:syslog-ng(8)
> 
> [Service]
> Type=notify
> Sockets=syslog.socket
> ExecStart=/usr/sbin/syslog-ng -F
> ExecReload=/bin/kill -HUP $MAINPID
> StandardOutput=null
> Restart=on-failure

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] Deadlocks with reloading jobs which are part of current transaction [was: [PATCH] Avoid reloading services when shutting down]

[Lennart Poettering]

On Wed, 04.02.15 15:25, Martin Pitt (martin.p...@ubuntu.com) wrote:

> Lennart Poettering [2015-02-04 13:27 +0100]:
> > On Wed, 04.02.15 08:56, Martin Pitt (martin.p...@ubuntu.com) wrote:
> > 
> > > Lennart Poettering [2015-02-03 21:40 +0100]:
> > > > It's really about synchronous waiting on jobs. If you synchronously
> > > > wait for completion of jobs that are ordered against the job your are
> > > > part of yourself, then things will deadlock.
> > > 
> > > Indeed. The problem is that if you reload e. g. postfix from a DHCP or
> > > "network up/down" hook, such a script doesn't have the slightest idea
> > > whether it was run because the network changed at runtime (i. e. udev
> > > event or the user just selected a new network) or whether it happens
> > > as part of a systemd transaction (boot/shutdown). In the former case
> > > you do want to block, in the latter case you mustn't.
> > 
> > I don't see why you'd want to block in either case. Networking is
> > asynchronous anyway, there's really no point in blocking here. What
> > does this give you?
> 
> So far, if a hook or shell script calls e. g. "service foo restart",
> it can count on the service actually being reloaded after it finishes,
> and thus you can then interact with it immediately. That's not
> important for many scripts, but we can't just always make "service foo
> reload" async by using --no-block, as that would break compatibility
> with scripts which do rely on that behaviour. So we do need to
> conditionalize it to avoid the deadlocks under systemd.

Sure, I can only recommend again: in the the glue code that calls out
to "systemctl" from "service", you can add the code to use --no-block
or --job-mode=ignore-dependencies , if you notice you are in shutdown
mode...

> > Modern code, that talks directly to systemctl, that uses hook scripts,
> > should always use --no-block for these cases.
> 
> Yeah, for sure. We just don't have that luxury easily, as first these
> scripts don't call systemctl but "service" (for the Debianists: or
> invoke-rc.d, but same difference), it will take some time to find
> all these occurrences, and people will hate us for having to add stuff
> like
> 
>   if (running under systemd)
>systemctl --no-block reload foo
>   else
>service foo reload

I am not proposing anything like that.

Your /usr/sbin/service binary translates sysv requests into systemctl
requests, right? In that code, you can easily impliy --no-block or
--job-mode=ignore-dependencies under the right circumstances.

There's *no* reason to patch that into all scripts, just patch that
into your "service" binary...

> > I mean, you must have some code in Debian that forwards old sysv
> > restart/reload requests to systemctl. That's probably going to be in
> > /usr/sbin/service and maybe a few other places. Why can't you just add
> > the --no-block logic there, conditionalized to shutdown/reboot?
> 
> Well, we can; it's just as much an unreliable hack as the two existing
> patches :-) and I was wondering if we can't solve this in a more
> generic/distro agnostic way.

No it's not as broken. Because if you use "systemctl" then, you will
always get the strict and right systemd semantics. Only your sysv glue
code will degrade things to be closer to sysv then.

/usr/bin/service is distro-specifc, there's no way around that. Some
distros have it as C binary, others as shell script, all with slightly
different semantics. If you make it translate sysv scripts into
systemctl invocation, then that's precisely where you should add in
--no-block or --job-mode=ignore-dependencies.

> > >  - Don't enqueue a reload if the service to be reloaded isn't running.
> > >E. g. postfix.service "inactive/dead" in
> > >https://bugs.debian.org/635777 or smbd.service "start/waiting" in
> > >https://launchpad.net/bugs/1417010.  This would completely avoid
> > >the deadlock in most situations already, and doesn't change the
> > >semantics for working use cases either, so this should even be
> > >applicable for upstream?
> > 
> > No, this would open up the door for races. The guarantee we give
> > around blocking operations, is that by the time they return the
> > operation or an equivalent has been executed. More specifically, if
> > you start a service, and it is in "starting", and then issue a
> > "reload" or "restart", and it returns you *know* that the
> > configuration that was on disk at the time you issued the "reload" or
> > "restart" -- or a newer one -- is in place. If you'd suppress the
> > reload/restart in this case, then you will not get that guarantee,
> > because the configuration ultimately loaded might be the one from the
> > time the daemon was first put into starting mode at.
> 
> Hm, I don't quite understand this. If you reload a service which isn't
> currently running, systemctl will fail. It's just currently going to
> enqueue the reload request, and executing the job will fail due to the
> "not active" check in uni

Re: [systemd-devel] Restart sequence: "systemctl restart rsyslog.service syslog.socket" often/sometimes fails

[Peter Valdemar Mørch]

Thank you Lennart for your explanation about the enqueuing. Sounds
reasonable. And helps me understand! :-)

Here I reply to you a little out of order:

On Wed, Feb 4, 2015 at 2:34 PM, Lennart Poettering
 wrote:
> This is something that can be fixed by adding stricter deps between
> the service and the socket, so that the socket is always required to
> be started before the service. Something for the respective package
> maintainers upstream to fix.

So have I understood this correctly: That the order matters *is* a
bug. Either in systemd (that provides
/lib/systemd/system/syslog.socket) or in syslog-ng and rsyslog that
provide e.g. /lib/systemd/system/syslog-ng.service ?

I'm worried that we manually have to figure out the correct ordering
of names to "systemctl restart PATTERN" and would like to be able
to rely on systemctl to figure that out for us. Is that a reasonable
long-term expectation? (And the reason order/sequence isn't mentioned
in the man page?)

> Alternatively, only restart the service, don't bother with the socket...

That in fact is what we might end up doing as it fixes this instance
of the problem short-term. I just want to understand what is going on
to determine if we're going to run into headaches long-term.

> Whats are the precise ordering and requirement deps between those two
> services?

I have no idea what they *should* be, but to show what they *are*,
here i show for syslog-ng. Seems to me that syslog-ng is clear about
syslog.socket being a dependency:

> cat /lib/systemd/system/syslog-ng.service
[Unit]
Description=System Logger Daemon
Documentation=man:syslog-ng(8)

[Service]
Type=notify
Sockets=syslog.socket
ExecStart=/usr/sbin/syslog-ng -F
ExecReload=/bin/kill -HUP $MAINPID
StandardOutput=null
Restart=on-failure

[Install]
WantedBy=multi-user.target
Alias=syslog.service

> systemctl list-dependencies -l syslog-ng | cat
syslog-ng.service
● ├─syslog.socket
● ├─system.slice
● └─basic.target
●   ├─paths.target
●   │ └─acpid.path
●   ├─slices.target
●   │ ├─-.slice
●   │ └─system.slice
●   ├─sockets.target
●   │ ├─acpid.socket
●   │ ├─dbus.socket
●   │ ├─systemd-initctl.socket
●   │ ├─systemd-journald-dev-log.socket
●   │ ├─systemd-journald.socket
●   │ ├─systemd-shutdownd.socket
●   │ ├─systemd-udevd-control.socket
●   │ └─systemd-udevd-kernel.socket
●   ├─sysinit.target
●   │ ├─console-setup.service
●   │ ├─debian-fixup.service
●   │ ├─dev-hugepages.mount
●   │ ├─dev-mqueue.mount
●   │ ├─hdparm.service
●   │ ├─kbd.service
●   │ ├─keyboard-setup.service
●   │ ├─kmod-static-nodes.service
●   │ ├─networking.service
●   │ ├─nfs-common.service
●   │ ├─proc-sys-fs-binfmt_misc.automount
●   │ ├─rpcbind.service
●   │ ├─sys-fs-fuse-connections.mount
●   │ ├─sys-kernel-config.mount
●   │ ├─sys-kernel-debug.mount
●   │ ├─systemd-ask-password-console.path
●   │ ├─systemd-binfmt.service
●   │ ├─systemd-journal-flush.service
●   │ ├─systemd-journald.service
●   │ ├─systemd-modules-load.service
●   │ ├─systemd-random-seed.service
●   │ ├─systemd-sysctl.service
●   │ ├─systemd-tmpfiles-setup-dev.service
●   │ ├─systemd-tmpfiles-setup.service
●   │ ├─systemd-udev-trigger.service
●   │ ├─systemd-udevd.service
●   │ ├─systemd-update-utmp.service
●   │ ├─udev-finish.service
●   │ ├─vmware-tools.service
●   │ ├─cryptsetup.target
●   │ ├─local-fs.target
●   │ │ ├─-.mount
●   │ │ ├─jail-dev.mount
●   │ │ ├─jail-proc.mount
●   │ │ ├─jail-tftp-cliusers.mount
●   │ │ ├─systemd-fsck-root.service
●   │ │ └─systemd-remount-fs.service
●   │ └─swap.target
●   │   
├─dev-disk-by\x2duuid-37ac7cd8\x2d4a9c\x2d4118\x2d8192\x2d7ecaf6229d75.swap
●   │   
└─dev-disk-by\x2duuid-37ac7cd8\x2d4a9c\x2d4118\x2d8192\x2d7ecaf6229d75.swap
●   └─timers.target
● └─systemd-tmpfiles-clean.timer

Thanks,

Peter

-- 
Peter Valdemar Mørch
http://www.morch.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCHv2] sysctl: consider --prefix while parsing the files

[Umut Tezduyar Lindskog]

not while applying the parsed sysctl values. Otherwise
info "Overwriting earlier assignment of %s in file %s" is
visible many times even though the given --prefix doesn't
try to set the overridden value.
---
 src/sysctl/sysctl.c | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/src/sysctl/sysctl.c b/src/sysctl/sysctl.c
index 973e67e..b22aff5 100644
--- a/src/sysctl/sysctl.c
+++ b/src/sysctl/sysctl.c
@@ -78,22 +78,6 @@ static int apply_sysctl(const char *property, const char 
*value) {
 n = stpcpy(p, "/proc/sys/");
 strcpy(n, property);
 
-if (!strv_isempty(arg_prefixes)) {
-char **i;
-bool good = false;
-
-STRV_FOREACH(i, arg_prefixes)
-if (path_startswith(p, *i)) {
-good = true;
-break;
-}
-
-if (!good) {
-log_debug("Skipping %s", p);
-return 0;
-}
-}
-
 k = write_string_file(p, value);
 if (k < 0) {
 log_full(k == -ENOENT ? LOG_DEBUG : LOG_WARNING,
@@ -173,6 +157,22 @@ static int parse_file(Hashmap *sysctl_options, const char 
*path, bool ignore_eno
 p = normalize_sysctl(strstrip(p));
 value = strstrip(value);
 
+if (!strv_isempty(arg_prefixes)) {
+char **i, *t;
+bool good = false;
+STRV_FOREACH(i, arg_prefixes) {
+t = path_startswith(*i, "/proc/sys/");
+if (t == NULL)
+t = *i;
+if (path_startswith(p, t)) {
+good = true;
+break;
+}
+}
+if (!good)
+continue;
+}
+
 existing = hashmap_get2(sysctl_options, p, &v);
 if (existing) {
 if (streq(value, existing))
-- 
2.1.1

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

Re: [systemd-devel] /proc and /sys get unmounted during boot from NFS, which results in boot error

[Olaf Leidinger]

Hey!

> Maybe something from your initrd is acting weird?

As far as I can tell, nothing from the initrd is running. It's
basically ArchLinux's mkinitcpio run on gentoo - thus, pretty standard stuff.

> It might be interesting to strace PID 1 while you are doing this. And
> if that doesn't help strace the other processes you run, to see if any
> of them unmounts anything.


Good idea! Actually, I found out some more stuff.

1. It's not calling "ls /proc", it seems as if the auto-complete
   function of the running shell triggers the problem.

2. It's not restricted to auto-completing /proc, /home triggers it as
   well.

3. But it's not bash's fault, tcsh triggers it, too.

4. Auto-completing one level deeper, e.g. /usr/bin, doesn't trigger
   the unmount.


( note: I've two shells running: one started by the emergency shell and
  one started by the small dropbear server I manually started 
  for debugging purpose. Everything but dropbear is watched by strace.
  The problem, of course, also occurs without dropbear.)

$ strace -f -F -p 1 -p 179 -p191 -p177
Process 1 attached
Process 179 attached
Process 191 attached
Process 177 attached
[pid   177] wait4(-1,  
[pid   191] rt_sigsuspend([] 
[pid   179] read(16,  
[pid 1] fstat(14, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
[pid 1] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 
-1, 0) = 0x7faf0bd52000
[pid 1] read(14, "strace\n", 1024)  = 7
[pid 1] close(14)   = 0
[pid 1] munmap(0x7faf0bd52000, 4096) = 0
[pid 1] writev(3, [{"<31>", 4}, {"systemd", 7}, {"[1]: ", 5}, {"Child 202 
(strace) died (code=ex"..., 55}, {"\n", 1}], 5) = 72
[pid 1] open("/proc/202/cgroup", O_RDONLY|O_CLOEXEC) = 14
[pid 1] fstat(14, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
[pid 1] mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 
-1, 0) = 0x7faf0bd52000
[pid 1] read(14, "8:memory:/\n7:freezer:/\n6:devices"..., 1024) = 101
[pid 1] close(14)   = 0
[pid 1] munmap(0x7faf0bd52000, 4096) = 0
[pid 1] waitid(P_PID, 202, {si_signo=SIGCHLD, si_code=CLD_EXITED, 
si_pid=202, si_status=0, si_utime=0, si_stime=0}, WEXITED, NULL) = 0
[pid 1] waitid(P_ALL, 0, {}, WNOHANG|WEXITED|WNOWAIT, NULL) = 0
[pid 1] epoll_wait(4,  
[pid   179] <... read resumed> "\n", 1) = 1

[...]

( this was the only output from systemd, so I guess it's not guilty).


 auto-completing /proc

[pid   179] rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
[pid   179] write(2, "l", 1)= 1
[pid   179] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid   179] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid   179] read(0, "s", 1) = 1
[pid   179] rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
[pid   179] write(2, "s", 1)= 1
[pid   179] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid   179] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid   179] read(0, " ", 1) = 1
[pid   179] rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
[pid   179] write(2, " ", 1)= 1
[pid   179] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid   179] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid   179] read(0, "/", 1) = 1
[pid   179] rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
[pid   179] write(2, "/", 1)= 1
[pid   179] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid   179] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid   179] read(0, "p", 1) = 1
[pid   179] rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
[pid   179] write(2, "p", 1)= 1
[pid   179] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid   179] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid   179] read(0, "r", 1) = 1
[pid   179] rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
[pid   179] write(2, "r", 1)= 1
[pid   179] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid   179] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid   179] read(0, "o", 1) = 1
[pid   179] rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
[pid   179] write(2, "o", 1)= 1
[pid   179] rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
[pid   179] rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
[pid   179] read(0, "\t", 1)= 1

### tab is pushed here
[pid   179] openat(AT_FDCWD, "/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
[pid   179] getdents(3, /* 22 entries */, 32768) = 560
[pid   179] getdents(3, /* 0 entries */, 32768) = 0
[pid   179] close(3)= 0
[pid   179] stat("/proc", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid   179] rt_sigprocmask(SIG_BLOCK, [INT], [], 8) = 0
[pid   179] write(2, "c/", 2)  



# after a reboot: autocomplete, that doesn't trigger
[pid   179] read(0, "\t", 1)= 1
[pid   179] stat("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
[pid   179] openat(AT_FDCWD, "/usr/", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
[pid   179] getdents(3, /* 16 entries */, 32768) = 464
[pid   179] getdents(3, /* 0 e

Re: [systemd-devel] Deadlocks with reloading jobs which are part of current transaction [was: [PATCH] Avoid reloading services when shutting down]

[Martin Pitt]

Lennart Poettering [2015-02-04 13:27 +0100]:
> On Wed, 04.02.15 08:56, Martin Pitt (martin.p...@ubuntu.com) wrote:
> 
> > Lennart Poettering [2015-02-03 21:40 +0100]:
> > > It's really about synchronous waiting on jobs. If you synchronously
> > > wait for completion of jobs that are ordered against the job your are
> > > part of yourself, then things will deadlock.
> > 
> > Indeed. The problem is that if you reload e. g. postfix from a DHCP or
> > "network up/down" hook, such a script doesn't have the slightest idea
> > whether it was run because the network changed at runtime (i. e. udev
> > event or the user just selected a new network) or whether it happens
> > as part of a systemd transaction (boot/shutdown). In the former case
> > you do want to block, in the latter case you mustn't.
> 
> I don't see why you'd want to block in either case. Networking is
> asynchronous anyway, there's really no point in blocking here. What
> does this give you?

So far, if a hook or shell script calls e. g. "service foo restart",
it can count on the service actually being reloaded after it finishes,
and thus you can then interact with it immediately. That's not
important for many scripts, but we can't just always make "service foo
reload" async by using --no-block, as that would break compatibility
with scripts which do rely on that behaviour. So we do need to
conditionalize it to avoid the deadlocks under systemd.

> Modern code, that talks directly to systemctl, that uses hook scripts,
> should always use --no-block for these cases.

Yeah, for sure. We just don't have that luxury easily, as first these
scripts don't call systemctl but "service" (for the Debianists: or
invoke-rc.d, but same difference), it will take some time to find
all these occurrences, and people will hate us for having to add stuff
like

  if (running under systemd)
   systemctl --no-block reload foo
  else
   service foo reload

as that special case appears rather pointless for someone who hasn't
dealt with the details of systemd job transactions. That's not to say
that it shouldn't happen (perhaps adding a --no-block option to
service), but that takes time.

> I mean, you must have some code in Debian that forwards old sysv
> restart/reload requests to systemctl. That's probably going to be in
> /usr/sbin/service and maybe a few other places. Why can't you just add
> the --no-block logic there, conditionalized to shutdown/reboot?

Well, we can; it's just as much an unreliable hack as the two existing
patches :-) and I was wondering if we can't solve this in a more
generic/distro agnostic way.

> >  - Don't enqueue a reload if the service to be reloaded isn't running.
> >E. g. postfix.service "inactive/dead" in
> >https://bugs.debian.org/635777 or smbd.service "start/waiting" in
> >https://launchpad.net/bugs/1417010.  This would completely avoid
> >the deadlock in most situations already, and doesn't change the
> >semantics for working use cases either, so this should even be
> >applicable for upstream?
> 
> No, this would open up the door for races. The guarantee we give
> around blocking operations, is that by the time they return the
> operation or an equivalent has been executed. More specifically, if
> you start a service, and it is in "starting", and then issue a
> "reload" or "restart", and it returns you *know* that the
> configuration that was on disk at the time you issued the "reload" or
> "restart" -- or a newer one -- is in place. If you'd suppress the
> reload/restart in this case, then you will not get that guarantee,
> because the configuration ultimately loaded might be the one from the
> time the daemon was first put into starting mode at.

Hm, I don't quite understand this. If you reload a service which isn't
currently running, systemctl will fail. It's just currently going to
enqueue the reload request, and executing the job will fail due to the
"not active" check in unit_reload(). The problem with that is just
that systemctl doesn't fail immediately with "the unit is not active",
but blocks on the queued request. So if you don't have pending jobs,
the net result is the same, but with pending jobs you can easily get a
deadlock.

> Or in other words: if a script does this:
> 
># sed -i -e 's/something/somethingelse/' /etc/mydaemon.conf
># systemctl restart mydaemon.service
> 
> Then we *must* give the guarantee that when the second command returns
> the change just made to /etc/mydaemon.conf is in place, and not a
> previous config loaded.

Yes, that's fine. I only said "reload" above, as that's what
DHCP/network scripts usually do.

> (Now, this example is about restarts, but reload is pretty much the
> same

reload on an inactive unit will fail, restart will start it.

> Also: *why* for heaven's sake? Just add --no-block when you are
> running from these contexts, and all is good. I really don't get why
> you don't want to do that.

Well, I do, but special-casing that on boot/shutdown 

Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services

[Martin Pitt]

Hey,

Lennart Poettering [2015-02-04 13:42 +0100]:
> Well, but their enablement status so far is not ignored. i.e. if you
> drop in a unit file, as well as a sysv script, and the latter is
> enabled, but the former not, then systemd currently reads that so that
> the sysv one is overriden by the native one, and the native one is
> considered enabled.
> 
> With this change you alter that behaviour. Is that really desired?

Since it's rather confusing what happens in this case, we made
systemctl sync the status to update-rc.d (the chkconfig equivalent in
Debian) on enable/disable:

  
http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/systemctl-don-t-skip-native-units-when-enabling-disa.patch

That of course doesn't change the behaviour with manual rc?.d/ symlinks.

But if you have a native unit, I think it's rather unexpected if you
disable it with systemctl, enable it in sysv, but still get it
started. It seems to me that systemctl disable should win here --
after all, that's closer to the running systemd than the rc.d links.
So in that regard it would be an intended behaviour change indeed.
But either way this is a corner case for sure. I just wouldn't like to
carry this patch forever as it's relatively unimportant.

Maybe Jon can chime in about his intentions with this?

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] What's the correct way to configure encrypted volume and mount point?

[John Lane]

On 02/02/15 20:49, Lennart Poettering wrote:
> BTW, just to mention this. You can also just write:
>
> # systemctl start /home/myuser/data
That's good to know, thanks.
>
> This will automatically be translated to
> "home-myuser-data.mount". systemctl has some logic built in to
> translate strings that don't look like unit names into unit names.
>
> Essentially this hence means that this:
>
>a) mount /home/myuser/data
>b) systemctl start /home/myuser/data
>
> However, the latter respects the whole systemde depency logic, while
> the former just tries to mount the specified dir immediately, ignoring
> all deps.
yep, got that now. "mount" doesn't hit-up systemd so the deps don't happen.
I'll train my mind to remember option (b).


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

Re: [systemd-devel] slow systemd-networkd DHCP client on wlan0 with systemd v217

[Patrik Flykt]

Hi,

On Tue, 2015-02-03 at 17:27 +0100, Lennart Poettering wrote:
> > Is the resume event detected somehow in systemd? 
> 
> The kernel unfortunately provides no API for this right now. However,
> if logind is the one suspending the machine, then it sends out a
> PrepareForSleep() signal before doing so. systemd-resolved already
> hooks into that:
> 
> http://cgit.freedesktop.org/systemd/systemd/tree/src/resolve/resolved-bus.c#n684
> 
> Tom mentioned he's already looking into adding similar code to
> networkd to handle this properly.

Latest upstream works fine for me. Links break at suspend and are
enabled at restore with PrepareForSleep() handled. Both versions of DHCP
properly stop and start at these events.


Cheers,

Patrik


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

Re: [systemd-devel] Restart sequence: "systemctl restart rsyslog.service syslog.socket" often/sometimes fails

[Lennart Poettering]

On Wed, 04.02.15 11:13, Peter Valdemar Mørch (pe...@morch.com) wrote:

> First: Please let me know if this is an inappropriate place to ask this
> 
> # systemctl restart syslog.socket rsyslog.service
> 
> seems to always work. But
> 
> # systemctl restart  rsyslog.service syslog.socket
> 
> , the opposite sequence, seems to sometimes fail (details below). I'm
> wondering: Why is that?

Whats are the precise ordering and requirement deps between those two
services?

Note that the command will first enqueue the restart job for the first
mentioned service, then the restart job for the second service. It
will then wait for both jobs to complete. Depending on the deps it
might happen in the second case, that the service is first stopped,
and then the socket stopped, and then the service started again. Now,
when the socket is about to be started again too, the service will
already be up, but in non-socket-activation mode, at which point the
socket unit refuses to start up, in order to not corrupt the socket
the service created on its own without usage of socket activation.

This is something that can be fixed by adding stricter deps between
the service and the socket, so that the socket is always required to
be started before the service. Something for the respective package
maintainers upstream to fix.

Alternatively, only restart the service, don't bother with the socket...

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] sysctl: consider --prefix while parsing the files

[Lennart Poettering]

On Wed, 04.02.15 10:43, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote:

> not while applying the parsed sysctl values. Otherwise
> info "Overwriting earlier assignment of %s in file %s" is
> visible many times even though the given --prefix doesn't
> try to set the overridden value.

Looks conceptually OK. A few notes:

>  k = write_string_file(p, value);
>  if (k < 0) {
>  log_full(k == -ENOENT ? LOG_DEBUG : LOG_WARNING,
> @@ -173,6 +157,24 @@ static int parse_file(Hashmap *sysctl_options, const 
> char *path, bool ignore_eno
>  p = normalize_sysctl(strstrip(p));
>  value = strstrip(value);
>  
> +if (!strv_isempty(arg_prefixes)) {
> +char **i, *t;
> +bool good = false;
> +STRV_FOREACH(i, arg_prefixes) {
> +t = *i;
> +if (startswith(t, "/proc/sys/")) {
> +t = t + strlen("/proc/sys/");
> +}

Please use path_startswith() jhere.

Also, startswith() and path_startswith() actually return a pointer to
the first char after the spefied prefix. If you want to skip the
prefix anyway, it's nice to use that.

Also, please no {} around singl-line code blocks.

> +if (path_startswith(p, t)) {
> +good = true;
> +break;
> +}
> +}
> +if (!good) {
> +continue;
> +}

No {} around single-line code blocks.

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] sysv-generator: Skip init scripts for existing native services

[Lennart Poettering]

On Wed, 04.02.15 10:08, Martin Pitt (martin.p...@ubuntu.com) wrote:

> Hello all,
> 
> a little while ago, Jon Severinsson wrote a sysv generator
> optimization to not go through all the parsing of init.d scripts and
> creation of units if there already is a native unit for that name. As
> they are put into generator.late they would be ignored anyway.

Well, but their enablement status so far is not ignored. i.e. if you
drop in a unit file, as well as a sysv script, and the latter is
enabled, but the former not, then systemd currently reads that so that
the sysv one is overriden by the native one, and the native one is
considered enabled.

With this change you alter that behaviour. Is that really desired? 

(Not saying it wasn't desired, just pointing out the difference, and
asking for some consideration of this issue?)

> This is particularly relevant if you have lots of init.d scripts, like
> we have on Debian. Other than that it's not a behaviour change AFAICS.
> 
> I cleaned it up a bit and added a test case.
> 
> One thing I wonder about is whether native_unit_exists() should
> perhaps be moved into src/shared/? It might be useful for other stuff.

We have similar code in src/shared/install.c already, this should
really be unified...

I must say I kinda like the fact though that the sysv generator knows
nothing about native units so far...

Anyway, not totally opposed, but I'd like to hear some analysis first
why this change in behaviour does not matter.

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] Make seccomp protections in systemd-nspawn optional

[Lennart Poettering]

On Wed, 04.02.15 02:21, Jay Faulkner (j...@jvf.cc) wrote:

> > I am not particularly fond of the idea of adding a completely new
> > command line option for this though. Maybe we can find another way for
> > this.
> > 
> > For example, one option could be to split the seccomp syscall
> > blacklist in two: split out the kernel kmod related syscalls, and
> > only add them to the seccomp filter if arg_retain does not include
> > CAP_SYS_MODULE. This would then leave the module seccomp filters in
> > place by default, however, if you add the CAP_SYS_MODULE cap to the
> > container with --capability= then the seccomp filter is changed to
> > also allow the module loading sys calls.
> 
> I implemented this; the patch can be pulled directly from
> https://github.com/jayofdoom/systemd/pull/2.patch to prevent me from
> corrupting this along the way.

Applied, thanks!

> As a note; unlike what we discussed in IRC, someone passing capability=all
> will be covered for module loading in this situation, because all sets the
> bitmask to -1, effectively enabling all capabilities.

Yupp, I thought that was pretty much what I was saying on IRC.

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] Deadlocks with reloading jobs which are part of current transaction [was: [PATCH] Avoid reloading services when shutting down]

[Lennart Poettering]

On Wed, 04.02.15 08:56, Martin Pitt (martin.p...@ubuntu.com) wrote:

> Lennart Poettering [2015-02-03 21:40 +0100]:
> > It's really about synchronous waiting on jobs. If you synchronously
> > wait for completion of jobs that are ordered against the job your are
> > part of yourself, then things will deadlock.
> 
> Indeed. The problem is that if you reload e. g. postfix from a DHCP or
> "network up/down" hook, such a script doesn't have the slightest idea
> whether it was run because the network changed at runtime (i. e. udev
> event or the user just selected a new network) or whether it happens
> as part of a systemd transaction (boot/shutdown). In the former case
> you do want to block, in the latter case you mustn't.

I don't see why you'd want to block in either case. Networking is
asynchronous anyway, there's really no point in blocking here. What
does this give you?

Modern code, that talks directly to systemctl, that uses hook scripts,
should always use --no-block for these cases.

That said, non-crap code does not rely on hook scripts like this
anyway, and just subscribes to rtnl on its own.

> > Now, regardless which option you choose it's always a good idea to
> > keep this change as local as possible. Altering the state engine for
> > all operations is the worst solution...
> 
> Well, it's a problem which can happen in a lot of scenarios and isn't
> specific to which kind of service or hook script you have, so what's
> "local" is actually quite hard to define here.
> 
> I agree with Michael that involving a lot of shell commands which we
> then have to copy to lots of places (and find these places at all) is
> also not the best solution. So perhaps we could have some middle
> ground here and make systemctl a bit more clever?

Hmm? I don't follow here at all?

I mean, you must have some code in Debian that forwards old sysv
restart/reload requests to systemctl. That's probably going to be in
/usr/sbin/service and maybe a few other places. Why can't you just add
the --no-block logic there, conditionalized to shutdown/reboot?

>  - Don't enqueue a reload if the service to be reloaded isn't running.
>E. g. postfix.service "inactive/dead" in
>https://bugs.debian.org/635777 or smbd.service "start/waiting" in
>https://launchpad.net/bugs/1417010.  This would completely avoid
>the deadlock in most situations already, and doesn't change the
>semantics for working use cases either, so this should even be
>applicable for upstream?

No, this would open up the door for races. The guarantee we give
around blocking operations, is that by the time they return the
operation or an equivalent has been executed. More specifically, if
you start a service, and it is in "starting", and then issue a
"reload" or "restart", and it returns you *know* that the
configuration that was on disk at the time you issued the "reload" or
"restart" -- or a newer one -- is in place. If you'd suppress the
reload/restart in this case, then you will not get that guarantee,
because the configuration ultimately loaded might be the one from the
time the daemon was first put into starting mode at.

Or in other words: if a script does this:

   # sed -i -e 's/something/somethingelse/' /etc/mydaemon.conf
   # systemctl restart mydaemon.service

Then we *must* give the guarantee that when the second command returns
the change just made to /etc/mydaemon.conf is in place, and not a
previous config loaded. And we must guarantee that in any case,
regardless if the daemon is about to start, already started, reloaded
or anything else...

(Now, this example is about restarts, but reload is pretty much the
same, except that many people use async ExecReload= commands (for
example send a signal), which will break this guarantee, but that's on
them then, we recommend synchronous reload operations, to make this
race-free).

> 
> And/or
> 
>  - systemctl reload/restart could imply --no-block if the service is
>already enqueued in the current transaction. That would avoid this
>deadlock situation in more cases.

Opens the same race, as described above.

Also: *why* for heaven's sake? Just add --no-block when you are
running from these contexts, and all is good. I really don't get why
you don't want to do that.

> With that the remaining deadlock case would be trying to reload an
> already running service which isn't affected by the current
> transaction, but we haven't seen that in practice yet.
> 
> If you don't want this upstream, I'd keep it as a patch in Debian. But
> I can't really imagine that this wouldn't happen in Fedora or other
> distros? I mean, things like the ISC DHCP hooks aren't a Debianism,
> and a lot of existing software wasn't written with this "be careful on
> service reloads and guess whether you need --no-block" approach in
> mind, as it has never been a problem with other init systems.

On Fedora, these hook scripts use --no-block correctly, and I am
completely puzzled why you don't want this on Debian!

Re: [systemd-devel] DefaultDependencies=false on scopes

[Lennart Poettering]

On Tue, 03.02.15 21:03, Brandon Philips (bran...@ifup.co) wrote:

> Hey Lennart-
> 
> On Tue, Feb 3, 2015 at 10:32 AM, Brandon Philips  wrote:
> > On Tue, Feb 3, 2015 at 10:20 AM, Lennart Poettering
> >  wrote:
> >> I have added DefaultDependencies= for you now:
> >>
> >> http://cgit.freedesktop.org/systemd/systemd/commit/?id=261420ba2a20305ad271b6f5f380aa74c5c9dd50
> >
> > Thank you. I will work on getting Docker fixed up to fix this annoying 
> > behavior.
> 
> So, is this the best way to tell if the systemd I am working with
> supports setting this property on a scope?
> https://github.com/philips/libcontainer/blob/systemd-default-dependencies-false/cgroups/systemd/apply_systemd.go#L74

Hmm, I figure I am not hipster enough to read this Go code...

But yeah, if you check for ReadOnlyProperty when putting together a
scope, that sounds like an OK check.

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] [ANNOUNCE] systemd v218

[Simon McVittie]

On 03/02/15 23:43, Lennart Poettering wrote:

The way I understand /usr/local, it is the place where the admin
himself places his own scripts and stuff, as extensions for the host
OS.


Yes, that view is consistent with the FHS (and e.g. Debian Policy's 
interpretation of the FHS). "./configure --prefix=/usr/local" is meant 
to "mostly work" for most software, which means it should be possible to 
hook into systemd, dbus-daemon, etc. by dropping files into /usr/local.


> The way I understand /usr/local, it is the place where the admin
> himself places his own scripts and stuff, as extensions for the host
> OS. Where /opt is the stuff for 3rd party apps (app vendors), and /usr
> is for 2nd party stuff (OS vendor), /usr/local is for 1st party stuff
> (admin).

That's one version. Many OSs (including Debian and derivatives) have a 
slightly different interpretation where /usr is the system package 
manager's territory, regardless of whether the package came from Debian 
or not - things that came in a .deb go in /usr or occasionally /opt, 
while things that the sysadmin installed by hand go in /usr/local or 
occasionally /opt. Installing a .deb is allowed to have arbitrary 
effects on /usr (subject to the usual policies about not 
breaking/overwriting other packages without the metadata saying so), but 
the only thing it's allowed to do in /usr/local is to create/remove 
empty directories in the maintainer scripts.


> On Fri, 12.12.14 14:25, Colin Guthrie (gm...@colin.guthr.ie) wrote:
>> It feels very, very odd that /usr/local is being parsed at all here
>> when the --prefix arg does not include it.

There's plenty of precedent for including /usr/local/bin in $PATH, 
/usr/local/share/FOO in search paths, etc., usually before /usr so that 
local sysadmin changes can override what's provided in the OS. This 
comes with the obvious caveat that if the local sysadmin breaks things 
by installing incompatible versions in /usr/local, they get to solve it 
for themselves.


The distinction between "modules installed in /usr/local for software 
also installed in /usr/local" and "modules installed in /usr/local for 
software installed in /usr" is not new either: in Debian and its 
derivatives, Python from python.deb looks for modules in 
.../dist-packages instead of the usual .../site-packages, so that 
.../site-packages can be reserved for modules that will be loaded into a 
copy of Python that the sysadmin installed from source.



>> If the were experimenting, but ultimately didn't want to
>> use it, it seems odd to me that the actual packaged version of system
>> would read these files.

If they were experimenting with a new version of thermald (picking a 
random example of something that I have installed in /usr/local in the 
past), but systemd didn't pick it up, that would be a fairly useless 
experiment, since it wouldn't actually start :-)


If they were experimenting with it but decided not to keep it, that's a 
good time to remove it from /usr/local. Sysadmins who use /usr/local 
should really be looking at something like GNU stow to automate 
installation/removal (or preferably building their local stuff into a 
.deb/.rpm, at which point it can be in /usr instead).



The whole thing is really not thought to the end though. Some folks
have /usr/local on NFS, which we cannot handle, since we'll look into
it already before NFS is mounted for some things, and never check it
again...


I think "in general this should work, but your configuration is not a 
supported one" is an acceptable response to that, tbh. If a sysadmin 
wants this badly enough, they can put a hook in their initramfs to mount 
/usr/local.


--
Simon McVittie
Collabora Ltd. 

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

Re: [systemd-devel] Container, private network and socket activation

[Lennart Poettering]

On Wed, 04.02.15 04:40, Mikhail Morfikov (mmorfi...@gmail.com) wrote:


> 1. When I try to connect for the very first time, I get a timeout, even 
> though the container
> is working. I can cancel the connection immediately, and reconnect after 2-3 
> sec and then the
> page shows up. All subsequent connections work without a problem, just the 
> first one gets
> a timeout. Is there a way to fix this, so the first connection that boots the 
> system could
> be somehow delayed, so after a while the page would show up?

That indicates that the systemd or apache inside the container do not
correctly make use of the the socket passed into them. You need to
make sure that inside the container you have pretty much the same
.socket unit running as on the host. The ListStream lines must be
identical, so that systemd inside the container recognizes the sockets
passed in from the host as the ones to use for apache. The only
difference for the socket units is that on the host they should
activate the container, in the container they should activate apache.

> 2. Is there a way to shut down the container automatically after
> some period of inactivity?  Let's say there's no traffic for 30min,
> and after this time the container goes down.

No, this is not available. It's hard to know when a process is idle
from the outside. While some strategies here are thinkable, no code
for it exists.

> 3. How to stop the container manually? I'm asking because when I try via
> "systemctl stop mycontainer.service" , it stops, but:
> 
> ...
> Feb 04 04:15:58 morfikownia systemd-nspawn[14346]: Halting system.
> Feb 04 04:15:58 morfikownia systemd-machined[14353]: Machine debian-tree 
> terminated.
> Feb 04 04:15:58 morfikownia systemd-nspawn[14346]: Container debian-tree has 
> been shut down.
> Feb 04 04:15:58 morfikownia systemd[1]: Starting My little
> container...

Well, because the socket wasn't passed on right the connection on it
will still be queued after the container exits again. systemd will
thus immediately spawn the container again. 

Basically, if you fix your issue #1, your issue #3 will be magically
fixed too.

> 4. Is there a way to persist the interfaces (veth0 and veth1)? Because after 
> the container
> goes down, they're deleted, so I have to create them anew.

Hmm, good question. I don't think the kernel allows that... It
destroys veth links when either side's network namespace dies... Not
sure if we can do anything about this in a robust way...

Lennart

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

[systemd-devel] Restart sequence: "systemctl restart rsyslog.service syslog.socket" often/sometimes fails

[Peter Valdemar Mørch]

First: Please let me know if this is an inappropriate place to ask this

# systemctl restart syslog.socket rsyslog.service

seems to always work. But

# systemctl restart  rsyslog.service syslog.socket

, the opposite sequence, seems to sometimes fail (details below). I'm
wondering: Why is that?

And if I have a list of 20 PATTERNs, how do I devise the magical
pattern that ALWAYS works?

man systemctl[1] seems not to mention anything about sequence of PATTERN...s.

Depending on what hardware I try it occurs always, often, sometimes or
rarely. But trying it e.g. 1000 times seems to always trigger it at
sometimes. (A little scary that it doesn't always produce the same
result!!!)

BACKGROUND

I'm not quite certain that there is a need to restart syslog.socket
too. Let me know if that is the case.

But the question is still broader: How is the sequence of PATTERN...s
relevant for restart and how do I create a "good" sequence (even if we
omit syslog.socket).

Our app uses a number of system services (apache2, syslog-ng, mysql,
rabbitmq-server and some more). We have a randomly ordered list of
them. (Note we're actually using syslog-ng but the same ordering issue
also applies for rsyslog as shown above)

When we restore from a backup, we stop these services, put restored
data in place and start them again. Because of debian issue #751744:
"dh-systemd: postinst snippets should stop foo.socket during upgrades
too", syslog.socket is also in our list or it sometimes starts up
before we're done.

When we change configuration files, we restart that same list of
"names". So also syslog.socket.

DETAILS
===
root@capmon:~# journalctl -xn --show-cursor -l --no-pager | tail -n 1
-- cursor: 
s=7cdc228fff4d49ada9fbebdfaf72e357;i=7a3;b=916402c8a5c747938b040a03c16b0e60;m=9e7556e8;t=50e404b5811ad;x=59fdfb3b30d4bdfa

root@capmon:~# systemctl restart  rsyslog.service syslog.socket
Job for syslog.socket failed. See 'systemctl status syslog.socket' and
'journalctl -xn' for details.
A dependency job for rsyslog.service failed. See 'journalctl -xn' for details.

root@capmon:~# journalctl -xn
--after-cursor='s=7cdc228fff4d49ada9fbebdfaf72e357;i=7a3;b=916402c8a5c747938b040a03c16b0e60;m=9e7556e8;t=50e404b5811ad;x=59fdfb3b30d4bdfa'
-l --no-pager
-- Logs begin at Wed 2015-02-04 10:18:51 CET, end at Wed 2015-02-04
11:06:42 CET. --
Feb 04 11:06:42 capmon systemd[1]: Stopping System Logging Service...
-- Subject: Unit rsyslog.service has begun shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit rsyslog.service has begun shutting down.
Feb 04 11:06:42 capmon systemd[1]: Starting Syslog Socket.
-- Subject: Unit syslog.socket has begun with start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit syslog.socket has begun starting up.
Feb 04 11:06:42 capmon systemd[1]: Listening on Syslog Socket.
-- Subject: Unit syslog.socket has finished start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit syslog.socket has finished starting up.
-- 
-- The start-up result is done.
Feb 04 11:06:42 capmon systemd[1]: Starting System Logging Service...
-- Subject: Unit rsyslog.service has begun with start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit rsyslog.service has begun starting up.
Feb 04 11:06:42 capmon systemd[1]: Stopping Syslog Socket.
-- Subject: Unit syslog.socket has begun shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit syslog.socket has begun shutting down.
Feb 04 11:06:42 capmon systemd[1]: Starting Syslog Socket.
-- Subject: Unit syslog.socket has begun with start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit syslog.socket has begun starting up.
Feb 04 11:06:42 capmon systemd[1]: Socket service rsyslog.service
already active, refusing.
Feb 04 11:06:42 capmon systemd[1]: Failed to listen on Syslog Socket.
-- Subject: Unit syslog.socket has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit syslog.socket has failed.
-- 
-- The result is failed.
Feb 04 11:06:42 capmon systemd[1]: Dependency failed for System Logging Service.
-- Subject: Unit rsyslog.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit rsyslog.service has failed.
-- 
-- The result is dependency.

root@capmon:~# systemctl status syslog.socket -l
syslog.socket - Syslog Socket
   Loaded: loaded (/lib/systemd/system/syslog.socket; static)
   Active: inactive (dead) since Wed 2015-02-04 11:06:42 CET; 2min 58s ago
 Docs: man:systemd.special(7)
   http://www.freedesktop.org/wiki/Software/systemd/syslog
   Listen: /run/systemd/journal/syslog (Dat

[systemd-devel] [PATCH] sysctl: consider --prefix while parsing the files

[Umut Tezduyar Lindskog]

not while applying the parsed sysctl values. Otherwise
info "Overwriting earlier assignment of %s in file %s" is
visible many times even though the given --prefix doesn't
try to set the overridden value.
---
 src/sysctl/sysctl.c | 34 ++
 1 file changed, 18 insertions(+), 16 deletions(-)

diff --git a/src/sysctl/sysctl.c b/src/sysctl/sysctl.c
index 973e67e..9f9ecc2 100644
--- a/src/sysctl/sysctl.c
+++ b/src/sysctl/sysctl.c
@@ -78,22 +78,6 @@ static int apply_sysctl(const char *property, const char 
*value) {
 n = stpcpy(p, "/proc/sys/");
 strcpy(n, property);
 
-if (!strv_isempty(arg_prefixes)) {
-char **i;
-bool good = false;
-
-STRV_FOREACH(i, arg_prefixes)
-if (path_startswith(p, *i)) {
-good = true;
-break;
-}
-
-if (!good) {
-log_debug("Skipping %s", p);
-return 0;
-}
-}
-
 k = write_string_file(p, value);
 if (k < 0) {
 log_full(k == -ENOENT ? LOG_DEBUG : LOG_WARNING,
@@ -173,6 +157,24 @@ static int parse_file(Hashmap *sysctl_options, const char 
*path, bool ignore_eno
 p = normalize_sysctl(strstrip(p));
 value = strstrip(value);
 
+if (!strv_isempty(arg_prefixes)) {
+char **i, *t;
+bool good = false;
+STRV_FOREACH(i, arg_prefixes) {
+t = *i;
+if (startswith(t, "/proc/sys/")) {
+t = t + strlen("/proc/sys/");
+}
+if (path_startswith(p, t)) {
+good = true;
+break;
+}
+}
+if (!good) {
+continue;
+}
+}
+
 existing = hashmap_get2(sysctl_options, p, &v);
 if (existing) {
 if (streq(value, existing))
-- 
2.1.1

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

[systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services

[Martin Pitt]

Hello all,

a little while ago, Jon Severinsson wrote a sysv generator
optimization to not go through all the parsing of init.d scripts and
creation of units if there already is a native unit for that name. As
they are put into generator.late they would be ignored anyway.

This is particularly relevant if you have lots of init.d scripts, like
we have on Debian. Other than that it's not a behaviour change AFAICS.

I cleaned it up a bit and added a test case.

One thing I wonder about is whether native_unit_exists() should
perhaps be moved into src/shared/? It might be useful for other stuff.

Thanks,

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
From ae066ed5d5b7312eb8debc30970f6e56919fa7c7 Mon Sep 17 00:00:00 2001
From: Jon Severinsson 
Date: Wed, 2 Jul 2014 22:00:00 +0200
Subject: [PATCH] sysv-generator: Skip init scripts for existing native
 services

There's no need to do all the parsing and creation of service files if we
already have a native systemd unit for the processed SysV init script.
---
 src/sysv-generator/sysv-generator.c | 30 +-
 test/sysv-generator-test.py | 12 
 2 files changed, 41 insertions(+), 1 deletion(-)

diff --git a/src/sysv-generator/sysv-generator.c b/src/sysv-generator/sysv-generator.c
index 673f04d..3052326 100644
--- a/src/sysv-generator/sysv-generator.c
+++ b/src/sysv-generator/sysv-generator.c
@@ -723,6 +723,25 @@ static int fix_order(SysvStub *s, Hashmap *all_services) {
 return 0;
 }
 
+static int native_unit_exists(LookupPaths lp, char *name) {
+char **p;
+
+STRV_FOREACH(p, lp.unit_path) {
+struct stat st;
+_cleanup_free_ char *path = NULL;
+
+path = strjoin(*p, "/", name, NULL);
+if (!path)
+return -ENOMEM;
+
+if (lstat(path, &st) < 0)
+continue;
+
+return 1;
+}
+return 0;
+}
+
 static int enumerate_sysv(LookupPaths lp, Hashmap *all_services) {
 char **path;
 
@@ -768,6 +787,14 @@ static int enumerate_sysv(LookupPaths lp, Hashmap *all_services) {
 if (!fpath)
 return log_oom();
 
+r = native_unit_exists(lp, name);
+if (r < 0)
+return log_oom();
+if (r > 0) {
+log_debug("Native unit for %s already exists, skipping", *path);
+continue;
+}
+
 service = new0(SysvStub, 1);
 if (!service)
 return log_oom();
@@ -852,7 +879,8 @@ static int set_dependencies_from_rcnd(LookupPaths lp, Hashmap *all_services) {
 
 service = hashmap_get(all_services, name);
 if (!service){
-log_warning("Could not find init script for %s", name);
+log_debug("Ignoring %s symlink in %s, not generating %s.",
+  de->d_name, rcnd_table[i].path, name);
 continue;
 }
 
diff --git a/test/sysv-generator-test.py b/test/sysv-generator-test.py
index 5098519..89df72a 100644
--- a/test/sysv-generator-test.py
+++ b/test/sysv-generator-test.py
@@ -367,6 +367,18 @@ class SysvGeneratorTest(unittest.TestCase):
 self.assert_enabled('foo.bak.service', [])
 self.assert_enabled('foo.old.service', [])
 
+def test_existing_native_unit(self):
+'''existing native unit'''
+
+with open(os.path.join(self.unit_dir, 'foo.service'), 'w') as f:
+f.write('[Unit]\n')
+
+self.add_sysv('foo.sh', {'Provides': 'foo bar'}, enable=True)
+err, results = self.run_generator()
+self.assertEqual(list(results), [])
+# no enablement or alias links
+self.assertEqual(os.listdir(self.out_dir), [])
+
 
 if __name__ == '__main__':
 unittest.main(testRunner=unittest.TextTestRunner(stream=sys.stdout, verbosity=2))
-- 
2.1.4



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

Re: [systemd-devel] test-capabilities fail and systemd-timesyncd broken

[Daniel Buch]

Okay, Tom fixed this with 057255fbbf2ecb1c46e025b04087fa9340d9880d.

2015-02-03 21:50 GMT+01:00 Daniel Buch :

> Hi,
>
> This commit 51ddf61540976fc7b09ce5 solved systemd-resolved, but broke
> systemd-timesyncd. Atleast on my system.
>
> dbuch@dbuch-laptop ~ % lscpu | grep -i "byte"
> Byte Order:Little Endian
>
> dbuch@dbuch-laptop ~ % SYSTEMD_LOGLEVEL=debug sudo
> /usr/lib/systemd/systemd-timesyncd
> Failed to enable capabilities bits: Invalid argument
>
> I suspect the usage of log2u64() is wrong? Im not able to gork this, but
> hope this helps :)
>
> Kind regards, Daniel
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] "dynamic" uid allocation (was: [PATCH] loopback setup in unprivileged containers)

[Daniel P. Berrange]

On Tue, Feb 03, 2015 at 06:05:00PM +0100, Lennart Poettering wrote:
> On Tue, 03.02.15 16:34, Serge Hallyn (serge.hal...@ubuntu.com) wrote:
> 
> > > > the UID/GID on entire filesystem sub-trees given to containers with
> > > > userns is a real unpleasant thing to have to deal with. I'd not want
> > 
> > Of course you would *not* want to take a stock rootfs where uid == 0
> > and shift that into the container, as that would give root in the
> > container a chance to write root-owned files on the host to leverage
> > later in a convoluted attack :)  
> 
> Is this really a problem? I mean, the only way how this could be
> exploitable is if people make the container hierarchy accessible to
> other users, but that should be easy to prohibit by making the
> container's parent dir 0700, which we already do for nspawn's
> container in /var/lib/machines... The only other risk I can see here
> is that if people use traditional ext4 quota, then the container's
> disk usage will be added to the host's usage. But that's easy to
> avoid, by simply never placing container images and the host on the
> same quota device...
> 
> Also, in the case of systemd-nspawn we strongly emphasize usage with
> loopback devices. In that case there's no vulnerability at all, since
> the device is completely seperate from the host fs, and it will only
> be mounted in the container, but not in the host...

NB, that the container filesystem is visible via /proc/$PID/root,
but I agree with you in general. I don't see a reason to avoid
the scenario Serge mentioned. Indeed I think it is important that
we explicitly support it, because ultimately I think we need to
be able to take any arbitrary disk image and safely boot it in
either a container or virtual machine. ie we should not have to
build custom images just for containers - any such need should be
considered a failure of the technology / impl IMHO.

> > We might want to come up with a containers concensus that container
> > rootfs's are always shipped with uid range 0-65535 -> 10-165535.
> > That still leaves a chance for container A (mapped to 20-265535)
> > to write valid setuid-root binary for container B (mapped to
> > 30-365535), which isn't possible otherwise.  But that's better
> > than doing so for host-root.
> 
> Well, ultimately I'd recommend an automatism like this for container
> managers: 
> 
>a) if not otherwise configured, let's give each container their own
>   16bit of uids. This would mean each 32bit uid could be neatly
>   split into the upper 16bit that would become a "container" id,
>   plus the lower 16bit for the actual "virtual" UID.
> 
>b) we will never set up UID ranges orthogonal from GID ranges.
> 
>c) when a container image is started, the container manager first
>   checks the UID/GID owner of the root of the root file system. It
>   masks the lower 16bit away, and only looks for the upper 16bit.
> 
>d) It will then look for an unused container id (which means, an
>   unused range of 64K UIDs), and then shifts the offset it
>   identified following c) to this new container id.
> 
> With that in place it doesn't really matter which base people use in
> their containers, the container manager would do the right thing, and
> shift everything into the right place. Paranoid people could ship
> their container images shifted to some ID of their choice, and lazy
> folks could just ship their container images with base 0, but then
> must make sure they don't give anybody else access to the hierarchy,
> and don't confuse quota...


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Deadlocks with reloading jobs which are part of current transaction [was: [PATCH] Avoid reloading services when shutting down]

[Martin Pitt]

Hello all,

I changed the Subject: to make this thread a bit easier to find.

Lennart Poettering [2015-02-03 21:40 +0100]:
> It's really about synchronous waiting on jobs. If you synchronously
> wait for completion of jobs that are ordered against the job your are
> part of yourself, then things will deadlock.

Indeed. The problem is that if you reload e. g. postfix from a DHCP or
"network up/down" hook, such a script doesn't have the slightest idea
whether it was run because the network changed at runtime (i. e. udev
event or the user just selected a new network) or whether it happens
as part of a systemd transaction (boot/shutdown). In the former case
you do want to block, in the latter case you mustn't.

FTR, I'm currently debugging a similar issue on
https://launchpad.net/bugs/1417010 which isn't caught by the current
two Debian patches, so we need a more generic solution anyway.

> Now, regardless which option you choose it's always a good idea to
> keep this change as local as possible. Altering the state engine for
> all operations is the worst solution...

Well, it's a problem which can happen in a lot of scenarios and isn't
specific to which kind of service or hook script you have, so what's
"local" is actually quite hard to define here.

I agree with Michael that involving a lot of shell commands which we
then have to copy to lots of places (and find these places at all) is
also not the best solution. So perhaps we could have some middle
ground here and make systemctl a bit more clever?

 - Don't enqueue a reload if the service to be reloaded isn't running.
   E. g. postfix.service "inactive/dead" in
   https://bugs.debian.org/635777 or smbd.service "start/waiting" in
   https://launchpad.net/bugs/1417010.  This would completely avoid
   the deadlock in most situations already, and doesn't change the
   semantics for working use cases either, so this should even be
   applicable for upstream?

And/or

 - systemctl reload/restart could imply --no-block if the service is
   already enqueued in the current transaction. That would avoid this
   deadlock situation in more cases.

With that the remaining deadlock case would be trying to reload an
already running service which isn't affected by the current
transaction, but we haven't seen that in practice yet.

If you don't want this upstream, I'd keep it as a patch in Debian. But
I can't really imagine that this wouldn't happen in Fedora or other
distros? I mean, things like the ISC DHCP hooks aren't a Debianism,
and a lot of existing software wasn't written with this "be careful on
service reloads and guess whether you need --no-block" approach in
mind, as it has never been a problem with other init systems.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


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