[systemd-devel] [PATCH] ldconfig: dont run it if ldconfig is not installed

2014-07-30 Thread Umut Tezduyar Lindskog
---
 units/ldconfig.service |1 +
 1 file changed, 1 insertion(+)

diff --git a/units/ldconfig.service b/units/ldconfig.service
index 43c145b..09a2b74 100644
--- a/units/ldconfig.service
+++ b/units/ldconfig.service
@@ -13,6 +13,7 @@ Conflicts=shutdown.target
 After=systemd-readahead-collect.service systemd-readahead-replay.service 
systemd-remount-fs.service
 Before=sysinit.target shutdown.target systemd-update-done.service
 ConditionNeedsUpdate=/etc
+ConditionFileIsExecutable=/sbin/ldconfig
 
 [Service]
 Type=oneshot
-- 
1.7.10.4

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


Re: [systemd-devel] [PATCH] ldconfig: dont run it if ldconfig is not installed

2014-07-30 Thread Andrey Borzenkov
On Wed, Jul 30, 2014 at 11:02 AM, Umut Tezduyar Lindskog
umut.tezdu...@axis.com wrote:
 ---
  units/ldconfig.service |1 +
  1 file changed, 1 insertion(+)

 diff --git a/units/ldconfig.service b/units/ldconfig.service
 index 43c145b..09a2b74 100644
 --- a/units/ldconfig.service
 +++ b/units/ldconfig.service
 @@ -13,6 +13,7 @@ Conflicts=shutdown.target
  After=systemd-readahead-collect.service systemd-readahead-replay.service 
 systemd-remount-fs.service
  Before=sysinit.target shutdown.target systemd-update-done.service
  ConditionNeedsUpdate=/etc
 +ConditionFileIsExecutable=/sbin/ldconfig



Is it really possible on Linux?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] ldconfig: dont run it if ldconfig is not installed

2014-07-30 Thread Umut Tezduyar Lindskog
Hi,

On Wed, Jul 30, 2014 at 9:23 AM, Andrey Borzenkov arvidj...@gmail.com wrote:
 On Wed, Jul 30, 2014 at 11:02 AM, Umut Tezduyar Lindskog
 umut.tezdu...@axis.com wrote:
 ---
  units/ldconfig.service |1 +
  1 file changed, 1 insertion(+)

 diff --git a/units/ldconfig.service b/units/ldconfig.service
 index 43c145b..09a2b74 100644
 --- a/units/ldconfig.service
 +++ b/units/ldconfig.service
 @@ -13,6 +13,7 @@ Conflicts=shutdown.target
  After=systemd-readahead-collect.service systemd-readahead-replay.service 
 systemd-remount-fs.service
  Before=sysinit.target shutdown.target systemd-update-done.service
  ConditionNeedsUpdate=/etc
 +ConditionFileIsExecutable=/sbin/ldconfig



 Is it really possible on Linux?

I guess so since our embedded product doesn't have /sbin/ldconfig.
Umut

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


Re: [systemd-devel] lastlog and friends

2014-07-30 Thread Karel Zak
On Tue, Jul 29, 2014 at 09:28:42PM +0200, Lennart Poettering wrote:
 On Tue, 29.07.14 14:43, Karel Zak (k...@redhat.com) wrote:
 
  
  
   systemd TODO:
  
  - Replace utmp, wtmp, btmp, and lastlog completely with journal
  
  
   Can someone elaborate and provide more details, ideas, .. ?
 
 Basically, we just want to have a nice tool that can dump data similar
 to lastlog or last to stdout, originating from the journal.

in util-linux 2.25 (f21, and backported to rhel6 and rhel7) we have
introduced lslogins. It's mostly motived by requests from classic
admis (RH customers) who after migration to Linux complains that all
unixes have logins command.

It's designed like lsblk(8), so it's easy to extend, and it's possible
add another sources for data. Now it reads info from libc
(getpwent()), utmp, wtmp, lastlog and also from journal to get last
user's messages.

$ sudo ./lslogins kzak
m
Username:   kzak
UID:1000
Gecos field:Karel Zak,Home Office,123   
Home directory: /home/kzak  
Shell:  /bin/bash   
No login:   no  
Password is locked: no  
Password not required:  no  
Login by password disabled: no  
Primary group:  kzak
GID:1000
Supplementary groups:   test,mock   
Supplementary group IDs:1001,988
Last login: Jul29/09:30 
Last terminal:  pts/5   
Last hostname:  localhost   
Failed login:   Jul29/18:22 
Failed login terminal:  :0  
Hushed: no  
Password expiration warn interval:  7   
Password changed:   2013-Jan16  
Maximum change time:9   
Running processes:  51  

Last logs:
Jul 30 09:35:01 gnome-session[1516]:and actually has type UTF8_STRING format 8 
n_items 0.
Jul 30 09:35:01 gnome-session[1516]:This is most likely an application bug, not 
a window manager bug.
Jul 30 09:35:01 gnome-session[1516]:The window has title=mutt 
class=terminology name=mutt


$ sudo ./lslogins --system-accs
UID USER   PROC PWD-LOCK PWD-DENY LAST-LOGIN GECOS
988 uuidd 001UUID generator helper 
daemon
989 geoclue   001User for geoclue
990 unbound   001Unbound DNS resolver
991 lightdm   001
992 nm-openconnect001NetworkManager user for 
OpenConnect
993 openvpn   001OpenVPN
994 radvd 001radvd user
995 pulse 001PulseAudio System Daemon
996 colord101User for colord
997 chrony101
998 saslauth  001Saslauthd user
999 polkitd   101User for polkitd

etc..

   The current lastlog is sparse file and it's difficult to use for backup 
   programs or integrity checkers, etc. So requests from users/customers
   are pretty common.
   
   The idea (from someone from RH) is to have very simple and tiny
   library that provides unified API for different backends (classic
   lastlog, systemd journal, etc.) to keep applications portable.
   Something like:
  
 https://github.com/marmolak/liblastlog2
  
   Frankly, I'd like to see something more than only lastlog, but also
   utmp, wtmp support.
 
 Honestly, this sounds like something awfully peripheral to deserve a
 library of its own. 

Yes, I have many doubts too... 

 Also, a library whose primary purpose is to be abstraction glue to
 support one backend that is supposed to be the backend of the future and
 one that is really something that should go away sounds like a bad
 idea. I mean, what would the benefit be?  Eventually people should just

The primary goal for the library was to replace the current ugly lastlog
file format with a better format.

Karel

-- 
 Karel Zak  k...@redhat.com
 http://karelzak.blogspot.com
___

Re: [systemd-devel] [PATCH] udevd: add --event-timeout commandline option

2014-07-30 Thread Hannes Reinecke

On 07/29/2014 04:13 PM, Kay Sievers wrote:

On Tue, Jul 29, 2014 at 9:06 AM, Hannes Reinecke h...@suse.de wrote:

On large configurations some events take longer than the
default 30 seconds. Killing those events will leave the
machine halfway configured.

So add a commandline option '--event-timeout' to handle these cases.


Applied. But with a follow-up commit, I changed the timeout logic. We
do not need or want several independent timeouts for the same thing.
Please check.


Hmm. You sure this is correct?


@@ -1462,14 +1454,6 @@ static int add_rule(struct udev_rules *rules, 
char *line,
 rule_add_key(rule_tmp, 
TK_A_DEVLINK_PRIO, op, NULL, prio);

 }

-pos = strstr(value, event_timeout=);
-if (pos != NULL) {
-int tout = 
atoi(pos[strlen(event_timeout=)]);

-
-rule_add_key(rule_tmp, 
TK_M_EVENT_TIMEOUT, op, NULL, tout);

-}
-
-pos = strstr(value, string_escape=);
 if (pos != NULL) {
 pos = pos[strlen(string_escape=)];
 if (startswith(pos, none))

Looks like the line 'pos = strstr(value, string_escape=);' should 
have been deleted ...


Cheers,

Hannes
--
Dr. Hannes Reinecke   zSeries  Storage
h...@suse.de  +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] keymap: Add microphone mute keymap for Dell Latitude

2014-07-30 Thread Hui Wang
On the Dell Latitude, the mic mute key event is generated by wmi
driver, the keycode assigned to this hotkey from kernel is
KEY_MICMUTE (248), this keycode is too big for xorg to handle,
in the xorg, the XF86AudioMicMute is assigned to F20.

Please refer to 4e648ea0 of xkeyboard-config.

BugLink: https://bugs.launchpad.net/bugs/1326684
BugLink: https://bugs.launchpad.net/bugs/1339998
Signed-off-by: Hui Wang hui.w...@canonical.com
---
 hwdb/60-keyboard.hwdb | 4 
 1 file changed, 4 insertions(+)

diff --git a/hwdb/60-keyboard.hwdb b/hwdb/60-keyboard.hwdb
index c7ff4e4..70e372b 100644
--- a/hwdb/60-keyboard.hwdb
+++ b/hwdb/60-keyboard.hwdb
@@ -229,6 +229,10 @@ keyboard:dmi:bvn*:bvr*:bd*:svnDell*:pnPrecision*:pvr*
 keyboard:dmi:bvn*:bvr*:bd*:svnDell*:pnXPS*:pvr*
  KEYBOARD_KEY_8c=!unknown
 
+# Dell Latitude microphone mute
+keyboard:name:Dell WMI hotkeys:dmi:bvn*:bvr*:bd*:svnDell*:pnLatitude*
+ KEYBOARD_KEY_150=f20   # Mic mute toggle
+
 ###
 # Everex
 ###
-- 
1.9.1

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


[systemd-devel] [PATCH] Fixup commit dd5eddd28a74a49607a8fffcaf960040dba98479

2014-07-30 Thread Hannes Reinecke
Commit dd5eddd28a74a49607a8fffcaf960040dba98479 accidentally
removed one line too many.

Signed-off-by: Hannes Reinecke h...@suse.de
---
 src/udev/udev-rules.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/udev/udev-rules.c b/src/udev/udev-rules.c
index 59bc124..cc56215 100644
--- a/src/udev/udev-rules.c
+++ b/src/udev/udev-rules.c
@@ -1436,6 +1436,7 @@ static int add_rule(struct udev_rules *rules, char *line,
 rule_add_key(rule_tmp, TK_A_DEVLINK_PRIO, op, 
NULL, prio);
 }
 
+pos = strstr(value, string_escape=);
 if (pos != NULL) {
 pos = pos[strlen(string_escape=)];
 if (startswith(pos, none))
-- 
1.8.4.5

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


Re: [systemd-devel] [PATCH] sysv: order initscripts which provide $network before network.target

2014-07-30 Thread Lukáš Nykrýn
Since there was no comment I have pushed it to the git, we need that
patch in fedora.

Lukas

Lukas Nykryn píše v St 23. 07. 2014 v 13:04 +0200:
 Due to recent changes where $network maps to network-online.target
 it is not guaranteed that initscript which provides networking will
 be terminated after network.target during shutdown which is against LSB.
 ---
  src/sysv-generator/sysv-generator.c | 5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/src/sysv-generator/sysv-generator.c 
 b/src/sysv-generator/sysv-generator.c
 index 5206279..9a869ba 100644
 --- a/src/sysv-generator/sysv-generator.c
 +++ b/src/sysv-generator/sysv-generator.c
 @@ -482,6 +482,11 @@ static int load_sysv(SysvStub *s) {
  r = strv_extend(s-wants, 
 m);
  if (r  0)
  return log_oom();
 +if (streq(m, 
 SPECIAL_NETWORK_ONLINE_TARGET)) {
 +r = 
 strv_extend(s-before, SPECIAL_NETWORK_TARGET);
 +if (r  0)
 +return 
 log_oom();
 +}
  }
  
  if (r  0)


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


Re: [systemd-devel] [PATCH] sysv: order initscripts which provide $network before network.target

2014-07-30 Thread Jóhann B. Guðmundsson


On 07/23/2014 11:04 AM, Lukas Nykryn wrote:

Due to recent changes where $network maps to network-online.target


Ah so that's why people are experiencing slowdown and breakage, you 
probably can close few bugs in bz.rh due to this change and from my pov


network-online should just have been left to be enable in Fedora by the 
administrator as it started out to be the case...


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


Re: [systemd-devel] [PATCH] keymap: Add microphone mute keymap for Dell Latitude

2014-07-30 Thread Martin Pitt
Hello Wang,

Hui Wang [2014-07-30 16:09 +0800]:
 On the Dell Latitude, the mic mute key event is generated by wmi
 driver, the keycode assigned to this hotkey from kernel is
 KEY_MICMUTE (248), this keycode is too big for xorg to handle,
 in the xorg, the XF86AudioMicMute is assigned to F20.

Thanks! Applied.

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] Fixup commit dd5eddd28a74a49607a8fffcaf960040dba98479

2014-07-30 Thread Kay Sievers
On Wed, Jul 30, 2014 at 10:10 AM, Hannes Reinecke h...@suse.de wrote:
 Commit dd5eddd28a74a49607a8fffcaf960040dba98479 accidentally
 removed one line too many.

Applied.

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


[systemd-devel] Support for pre-restart check

2014-07-30 Thread Ansgar Burchardt
Hi,

while looking at how to convert sysvinit scripts to service files in
Debian, I noticed that some scripts do an additional sanity check during
the restart action. That is, they run an extra command to validate the
configuration and only restart the service on success.

Systemd doesn't seem to provide such an option so far. Would you think
this is something one would like to see? If yes, what about the
following idea:

Add an ExecRestartPre option in the [Service] section. These commands
are executed when a restart is requested, before the service is stopped.
If they fail, the restart is aborted with an error.

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


Re: [systemd-devel] [PATCH 2/2] socket: Introduce SCTP support

2014-07-30 Thread Mantas Mikulėnas
On Mon, Jul 28, 2014 at 9:48 AM, Susant Sahani sus...@redhat.com wrote:
 This patch adds SCTP protcol support for socket activation.
 SCTP socket can be configured via the conf parameter
 'ListenStreamControlTrans' which is kind of too long.

I thought SCTP is usually used with SOCK_SEQPACKET, in which case the
existing ListenSequentialPacket would work?

Maybe there should be some syntax for specifying the protocol in
ListenStream/ListenDatagram, to allow for various odd things like
stream/SCTP and dgram/UDPLITE etc.

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] Support for pre-restart check

2014-07-30 Thread Reindl Harald

Am 30.07.2014 12:22, schrieb Ansgar Burchardt:
 while looking at how to convert sysvinit scripts to service files in
 Debian, I noticed that some scripts do an additional sanity check during
 the restart action. That is, they run an extra command to validate the
 configuration and only restart the service on success.
 
 Systemd doesn't seem to provide such an option so far. Would you think
 this is something one would like to see? If yes, what about the
 following idea:
 
 Add an ExecRestartPre option in the [Service] section. These commands
 are executed when a restart is requested, before the service is stopped.
 If they fail, the restart is aborted with an error

as sysadmin i say: oh yes, that would be cool!

the first canmdidate would be Apache httpd
ExecRestartPre=/usr/sbin/apachectl -t

that would cat cases where you hard restart httpd after
library updates and some other guy made a typo in a config
or is still woking on it

apachectl graceful in such cases refuses the restart



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


[systemd-devel] confine user(s) to a core with systemd + cgroup

2014-07-30 Thread lejeczek

sorry to bother developers
I've been reading, asking forums, etc, but failed to find an 
answer to one quick question:


how do I put users, their whole session from the moment they 
login into a cgroup cpuset?


I thought it would be CPUAffinity responsible for it either in
systemd-user-sessions or(and) in systemd-logind, but it does 
not work.


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


Re: [systemd-devel] Support for pre-restart check

2014-07-30 Thread Jóhann B. Guðmundsson


On 07/30/2014 10:22 AM, Ansgar Burchardt wrote:

Hi,

while looking at how to convert sysvinit scripts to service files in
Debian, I noticed that some scripts do an additional sanity check during
the restart action. That is, they run an extra command to validate the
configuration and only restart the service on success.

Systemd doesn't seem to provide such an option so far. Would you think
this is something one would like to see? If yes, what about the
following idea:

Add an ExecRestartPre option in the [Service] section. These commands
are executed when a restart is requested, before the service is stopped.
If they fail, the restart is aborted with an error.



Re-sending to list due to simple clicking reply not reply-list mistake.

This has been discussed before and check the archive for that discussion 
but the bottom line is that this is not needed we already have 
ExecStartPre=, ExecStartPost=, ExecStop=, ExecStopPost=, or ExecReload= 
which cover those usecases


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


[systemd-devel] documentation and required version

2014-07-30 Thread Reindl Harald
http://www.freedesktop.org/software/systemd/man/systemd.exec.html

such error messages caused by list all sort of options
without any information when they where introduced are
really annoying - the docs should clearly say the minimum
required systemd version and the more options are added
the more important is that

Jul 30 13:17:09 rh systemd[1]: [/usr/lib/systemd/system/mysqld.service:10] 
Unknown lvalue 'RuntimeDirectory' in
section 'Service'
Jul 30 13:17:09 rh systemd[1]: [/usr/lib/systemd/system/mysqld.service:11] 
Unknown lvalue 'RuntimeDirectoryMode' in
section 'Service



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] Support for pre-restart check

2014-07-30 Thread Ansgar Burchardt
Hi,

On 07/30/2014 13:26, Jóhann B. Guðmundsson wrote:
 On 07/30/2014 10:22 AM, Ansgar Burchardt wrote:
 while looking at how to convert sysvinit scripts to service files in
 Debian, I noticed that some scripts do an additional sanity check during
 the restart action. That is, they run an extra command to validate the
 configuration and only restart the service on success.

 Systemd doesn't seem to provide such an option so far. Would you think
 this is something one would like to see? If yes, what about the
 following idea:

 Add an ExecRestartPre option in the [Service] section. These commands
 are executed when a restart is requested, before the service is stopped.
 If they fail, the restart is aborted with an error.

 This has been discussed before and check the archive for that discussion
 but the bottom line is that this is not needed we already have
 ExecStartPre=, ExecStartPost=, ExecStop=, ExecStopPost=, or ExecReload=
 which cover those usecases

I searched for such discussion, but did not find anything relevant. Do
you have a link?

And how would you use the existing Exec* options to cover this usecase?
ExecStart* certainly doesn't help, ExecReload only works for reload and
not for restart.  ExecStop is to actually stop the service (and should
not fail due to invalid configuration); ExecStopPost is too late.

Ansgar

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


Re: [systemd-devel] Support for pre-restart check

2014-07-30 Thread Michal Sekletar
On Wed, Jul 30, 2014 at 11:26:38AM +, Jóhann B. Guðmundsson wrote:
 
 On 07/30/2014 10:22 AM, Ansgar Burchardt wrote:
 Hi,
 
 while looking at how to convert sysvinit scripts to service files in
 Debian, I noticed that some scripts do an additional sanity check during
 the restart action. That is, they run an extra command to validate the
 configuration and only restart the service on success.
 
 Systemd doesn't seem to provide such an option so far. Would you think
 this is something one would like to see? If yes, what about the
 following idea:
 
 Add an ExecRestartPre option in the [Service] section. These commands
 are executed when a restart is requested, before the service is stopped.
 If they fail, the restart is aborted with an error.
 
 
 Re-sending to list due to simple clicking reply not reply-list mistake.
 
 This has been discussed before and check the archive for that
 discussion but the bottom line is that this is not needed we already
 have ExecStartPre=, ExecStartPost=, ExecStop=, ExecStopPost=, or
 ExecReload= which cover those usecases

If that is the case, we should really delete TODO item:

* maybe introduce ExecRestartPre

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


Re: [systemd-devel] documentation and required version

2014-07-30 Thread Tom Gundersen
On Wed, Jul 30, 2014 at 1:21 PM, Reindl Harald h.rei...@thelounge.net wrote:
 http://www.freedesktop.org/software/systemd/man/systemd.exec.html

 such error messages caused by list all sort of options
 without any information when they where introduced are
 really annoying - the docs should clearly say the minimum
 required systemd version and the more options are added
 the more important is that

 Jul 30 13:17:09 rh systemd[1]: [/usr/lib/systemd/system/mysqld.service:10] 
 Unknown lvalue 'RuntimeDirectory' in
 section 'Service'
 Jul 30 13:17:09 rh systemd[1]: [/usr/lib/systemd/system/mysqld.service:11] 
 Unknown lvalue 'RuntimeDirectoryMode' in
 section 'Service

Won't this be solved by using the man pages shipped with the version
of systemd you are using?

Cheers,

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


Re: [systemd-devel] Support for pre-restart check

2014-07-30 Thread Lennart Poettering
On Wed, 30.07.14 12:22, Ansgar Burchardt (ans...@debian.org) wrote:

 Hi,
 
 while looking at how to convert sysvinit scripts to service files in
 Debian, I noticed that some scripts do an additional sanity check during
 the restart action. That is, they run an extra command to validate the
 configuration and only restart the service on success.
 
 Systemd doesn't seem to provide such an option so far. Would you think
 this is something one would like to see? If yes, what about the
 following idea:
 
 Add an ExecRestartPre option in the [Service] section. These commands
 are executed when a restart is requested, before the service is stopped.
 If they fail, the restart is aborted with an error.

This has been a TODO item since a long time. The usecase seems valid. So
far nobody found the time to implement this though. Happy to take patches...

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] Support for pre-restart check

2014-07-30 Thread Reindl Harald

Am 30.07.2014 13:42, schrieb Ansgar Burchardt:
 On 07/30/2014 13:26, Jóhann B. Guðmundsson wrote:
 On 07/30/2014 10:22 AM, Ansgar Burchardt wrote:
 Add an ExecRestartPre option in the [Service] section. These commands
 are executed when a restart is requested, before the service is stopped.
 If they fail, the restart is aborted with an error.

 This has been discussed before and check the archive for that discussion
 but the bottom line is that this is not needed we already have
 ExecStartPre=, ExecStartPost=, ExecStop=, ExecStopPost=, or ExecReload=
 which cover those usecases
 
 I searched for such discussion, but did not find anything relevant. Do
 you have a link?
 
 And how would you use the existing Exec* options to cover this usecase?
 ExecStart* certainly doesn't help, ExecReload only works for reload and
 not for restart.  ExecStop is to actually stop the service (and should
 not fail due to invalid configuration); ExecStopPost is too late

they don't

ExecStopPost is too late, the service is stopped
ExecReload is a different game
ExecStartPre don't help to prevent the stop

hardly any of the existing options is able to *prevent stop*
and ignore the systemctl restart - that would be the semnatic
of a non existing ExecStopPre

Pre != Post



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] documentation and required version

2014-07-30 Thread Reindl Harald


Am 30.07.2014 13:58, schrieb Tom Gundersen:
 On Wed, Jul 30, 2014 at 1:21 PM, Reindl Harald h.rei...@thelounge.net wrote:
 http://www.freedesktop.org/software/systemd/man/systemd.exec.html

 such error messages caused by list all sort of options
 without any information when they where introduced are
 really annoying - the docs should clearly say the minimum
 required systemd version and the more options are added
 the more important is that

 Jul 30 13:17:09 rh systemd[1]: [/usr/lib/systemd/system/mysqld.service:10] 
 Unknown lvalue 'RuntimeDirectory' in
 section 'Service'
 Jul 30 13:17:09 rh systemd[1]: [/usr/lib/systemd/system/mysqld.service:11] 
 Unknown lvalue 'RuntimeDirectoryMode' in
 section 'Service
 
 Won't this be solved by using the man pages shipped with the version
 of systemd you are using?

no - for several reasons

* it's more comfortable to use a website with working links like
  http://www.freedesktop.org/software/systemd/man/systemd.kill.html
  mentioned as example in ExecStop=

* it's more comfortable to have STRG+F in a webbrowsers

* i currently maintain machines with 204, 208 and 215
  having *one* manual open which lists all available options
  and mention the minimum version of them gives a better picture




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] Support for pre-restart check

2014-07-30 Thread Jóhann B. Guðmundsson


On 07/30/2014 12:09 PM, Lennart Poettering wrote:

On Wed, 30.07.14 12:22, Ansgar Burchardt (ans...@debian.org) wrote:


Hi,

while looking at how to convert sysvinit scripts to service files in
Debian, I noticed that some scripts do an additional sanity check during
the restart action. That is, they run an extra command to validate the
configuration and only restart the service on success.

Systemd doesn't seem to provide such an option so far. Would you think
this is something one would like to see? If yes, what about the
following idea:

Add an ExecRestartPre option in the [Service] section. These commands
are executed when a restart is requested, before the service is stopped.
If they fail, the restart is aborted with an error.

This has been a TODO item since a long time. The usecase seems valid.


We discussed this either here on the mailinglist, in a bug report in 
bz.rh or in one of the hackfest and it's on that TODO list is there 
because in the beginning I thought this was required but
after we discussed this the behaviour and after going through the more 
or less all of the legacy sysv initscripts in Fedora simply using 
ExecStartPre and ExecStop covered this but by all means introduce this 
if you no longer think that is the case.


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


Re: [systemd-devel] documentation and required version

2014-07-30 Thread Mauricio Tavares
's

On Wed, Jul 30, 2014 at 8:08 AM, Reindl Harald h.rei...@thelounge.net wrote:


 Am 30.07.2014 13:58, schrieb Tom Gundersen:
 On Wed, Jul 30, 2014 at 1:21 PM, Reindl Harald h.rei...@thelounge.net 
 wrote:
 http://www.freedesktop.org/software/systemd/man/systemd.exec.html

 such error messages caused by list all sort of options
 without any information when they where introduced are
 really annoying - the docs should clearly say the minimum
 required systemd version and the more options are added
 the more important is that

 Jul 30 13:17:09 rh systemd[1]: [/usr/lib/systemd/system/mysqld.service:10] 
 Unknown lvalue 'RuntimeDirectory' in
 section 'Service'
 Jul 30 13:17:09 rh systemd[1]: [/usr/lib/systemd/system/mysqld.service:11] 
 Unknown lvalue 'RuntimeDirectoryMode' in
 section 'Service

 Won't this be solved by using the man pages shipped with the version
 of systemd you are using?

 no - for several reasons

 * it's more comfortable to use a website with working links like
   http://www.freedesktop.org/software/systemd/man/systemd.kill.html
   mentioned as example in ExecStop=

 * it's more comfortable to have STRG+F in a webbrowsers

 * i currently maintain machines with 204, 208 and 215
   having *one* manual open which lists all available options
   and mention the minimum version of them gives a better picture

  Tom, I see no reason why having the man page indicate when a
given option was introduced be any worse than your suggestion. Since
the online man page better be the latest one, if it stated when each
option was introduced Reindl can use the online page as he wants and
those who want to use the man page in their computers can do the same.
Everyone wins.


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

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


Re: [systemd-devel] Support for pre-restart check

2014-07-30 Thread Jóhann B. Guðmundsson


On 07/30/2014 12:02 PM, Reindl Harald wrote:

they don't


Perhaps not in your world which seems to differ from many but in the 
world that the guy that went through and migrated around 800 legacy sysv 
initscript you want the exact same check run before the service is 
started and we already cover that with ExecStartPre=


And of those 800 it was exception not a rule if those legacy sysv 
initscript simply did not call stop/start on restart...


Ansgar Burchardt will need to post the initscript he's migrating so we 
can see if it actually provides an valid usecase to implement this I 
would be very surprised if it actually did...


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


Re: [systemd-devel] Support for pre-restart check

2014-07-30 Thread Reindl Harald

Am 30.07.2014 14:19, schrieb Jóhann B. Guðmundsson:
 On 07/30/2014 12:09 PM, Lennart Poettering wrote:
 On Wed, 30.07.14 12:22, Ansgar Burchardt (ans...@debian.org) wrote:

 while looking at how to convert sysvinit scripts to service files in
 Debian, I noticed that some scripts do an additional sanity check during
 the restart action. That is, they run an extra command to validate the
 configuration and only restart the service on success.
 
 Systemd doesn't seem to provide such an option so far. Would you think
 this is something one would like to see? If yes, what about the
 following idea:
 
 Add an ExecRestartPre option in the [Service] section. These commands
 are executed when a restart is requested, before the service is stopped.
 If they fail, the restart is aborted with an error.
 This has been a TODO item since a long time. The usecase seems valid.
 
 We discussed this either here on the mailinglist, in a bug report in bz.rh or 
 in one of the hackfest and it's on
 that TODO list is there because in the beginning I thought this was required 
 but
 after we discussed this the behaviour and after going through the more or 
 less all of the legacy sysv initscripts
 in Fedora simply using ExecStartPre and ExecStop covered this but by all 
 means introduce this if you no longer
 think that is the case

*how* should that both help in calling apachectl -t *before* stop the
service and in case of a error-repsonse keep it running?

ExecStartPre can only prevent a not or no longer running service
to start again, ExecStopPost comes after it is stopped and a
ExecStopPre don't exist

ExecStopPre would be better suited as the pre-restart check because
it would achieve the goal and also prevent stop a service until it's
configuration is fixed - that catchs cases where you stop something
for whatever reason and expect it would be started at the next boot



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] Support for pre-restart check

2014-07-30 Thread Reindl Harald

Am 30.07.2014 14:35, schrieb Jóhann B. Guðmundsson:
 On 07/30/2014 12:02 PM, Reindl Harald wrote:
 they don't
 
 Perhaps not in your world which seems to differ from many

don't jump on that personal level

if you would have *read* really what you respond to and not
stop at the first two words you would realize the difference
without personal attacks - it's not a matter of worlds, it's
a *technical fact*

 but in the world that the guy that went through and migrated around 800 
 legacy sysv initscript you want the exact same check run before the 
 service is started and we already cover that with ExecStartPre=

nobody takes ExecStartPre away from you by add ExecStopPre

BTW:
what do you gain by that checkj in ExecStartPre?
ExecStart would fail anyways, so the service fails with or without

the topic is about something like ExecStopPre, what you can achieve
with it and not about which hero migrated how much sysv initscripts

 Ansgar Burchardt will need to post the initscript he's migrating so we can 
 see if it actually provides an valid usecase to implement this I would 
 be very surprised if it actually did...

step beside your migration consideration and come back to a generic level
by only consider migrations you could remove 80% of all options in systemd.exec

that below could be httpd and that's useful for a lot of other services
by just have the option to call a helper saying you don't stop me with
the current environment because of XYZ you won't be able to start me again

in case of httpd all what you need exists
for other services it could be implemented if there is a call

frankly that could be even useful outside the distribution world
for sanity checks implemented by the local administrator

Type=simple
ExecStartPre=/usr/sbin/apachectl -t
ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND
ExecStopPre=/usr/sbin/apachectl -t
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful




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] Support for pre-restart check

2014-07-30 Thread Jóhann B. Guðmundsson


On 07/30/2014 12:34 PM, Reindl Harald wrote:

*how*  should that both help in calling apachectl -t*before*  stop the
service and in case of a error-repsonse keep it running?


ExecStartPre= takes care of the startup check as in the usecase when the 
unit is not running and you initially configured the Apache daemon


Adding ExecStop= before actual ExecStop= line to stop the daemon takes 
care of preventing you from restarting you if you made configuration 
changes while the daemon/services was running should not continue with 
the stop process if the ExecStop command fails.


Anyway beside that point daemon,services that actual come with 
configuration file syntax checkers like apache does ( maybe in what 20 
or so range ) , are few and far between let alone those configuration 
syntax checker that actually exist out there fail properly if they do...


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


Re: [systemd-devel] Support for pre-restart check

2014-07-30 Thread Reindl Harald

Am 30.07.2014 15:04, schrieb Jóhann B. Guðmundsson:
 On 07/30/2014 12:34 PM, Reindl Harald wrote:
 *how* should that both help in calling apachectl -t *before* stop the
 service and in case of a error-repsonse keep it running?
 
 ExecStartPre= takes care of the startup check as in the usecase when 
 the unit is not running and you initially configured the Apache daemon

first: please don't ignore the last paragraphs!

takes care about what?
the service would fail with or without that

 Adding ExecStop= before actual ExecStop= line to stop the daemon 
 takes care of preventing you from restarting you if you made configuration 
 changes while the daemon/services was running should not continue with 
 the stop process if the ExecStop command fails.

but you don't need ExecStop for most services

systemd sends SIGTERM and so ExecStopPre would also affect
services without ExecStop lines which are most of mine

why? because they don't need CAP_KILL!
that's from production, no ExecStop used

[Service]
Type=simple
EnvironmentFile=-/etc/sysconfig/httpd
Environment=PATH=/usr/bin:/usr/sbin
ExecStart=/usr/sbin/httpd $OPTIONS -D FOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
Restart=always
RestartSec=1
PrivateTmp=yes
NoNewPrivileges=yes
CapabilityBoundingSet=CAP_DAC_OVERRIDE CAP_IPC_LOCK CAP_NET_BIND_SERVICE 
CAP_SETGID CAP_SETUID
ReadOnlyDirectories=/etc
ReadOnlyDirectories=/usr
ReadOnlyDirectories=/var/lib
InaccessibleDirectories=/home
InaccessibleDirectories=/media
InaccessibleDirectories=/root
InaccessibleDirectories=/proc
InaccessibleDirectories=/sys
InaccessibleDirectories=/run/console
InaccessibleDirectories=/run/dbus
InaccessibleDirectories=/run/lock
InaccessibleDirectories=/run/mount
InaccessibleDirectories=/run/systemd/generator
InaccessibleDirectories=/run/systemd/system
InaccessibleDirectories=/run/systemd/users
InaccessibleDirectories=/run/udev
InaccessibleDirectories=/run/user
InaccessibleDirectories=/var/lib/dbus
InaccessibleDirectories=/var/lib/rpm
InaccessibleDirectories=/var/lib/systemd
InaccessibleDirectories=/var/lib/yum
InaccessibleDirectories=/var/spool

 Anyway beside that point daemon,services that actual come with configuration 
 file syntax checkers like apache does (maybe in what 20 or so range), are 
 few and far between let alone those configuration syntax checker that
 actually exist out there fail properly if they do...

step away from syntax checkers shipped with daemons, they are
only one usecase (and maybe there would be some more in a few
years with reliebale ways to use them with systemd)

ExecStopPost could be any script written by the local administrator
which says you don't stop that service in case service A and B are
runnining which *hard fail* if you take them away the database and
so i ordered start/shutdown of the machine correctly but without
hard Requires= and their drawbacks in units files *

drawbacks of Requires=:
stop one service required by others stops them too, but start it don't
start them at the same moment which is good because as example mysqld
can run without dbmail-imapd but not the other way round

so one could optimize the environment that restart/stop mysqld only
is possible if dbamil-imapd is not running and systemctl restart
dbmail-imapd.service mysqld.service does the correct order by
After=/Before= in the services depending on mysqld



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] documentation and required version

2014-07-30 Thread Dave Reisner
On Wed, Jul 30, 2014 at 01:58:51PM +0200, Tom Gundersen wrote:
 On Wed, Jul 30, 2014 at 1:21 PM, Reindl Harald h.rei...@thelounge.net wrote:
  http://www.freedesktop.org/software/systemd/man/systemd.exec.html
 
  such error messages caused by list all sort of options
  without any information when they where introduced are
  really annoying - the docs should clearly say the minimum
  required systemd version and the more options are added
  the more important is that
 
  Jul 30 13:17:09 rh systemd[1]: [/usr/lib/systemd/system/mysqld.service:10] 
  Unknown lvalue 'RuntimeDirectory' in
  section 'Service'
  Jul 30 13:17:09 rh systemd[1]: [/usr/lib/systemd/system/mysqld.service:11] 
  Unknown lvalue 'RuntimeDirectoryMode' in
  section 'Service
 
 Won't this be solved by using the man pages shipped with the version
 of systemd you are using?

Sure, this works when you need to figure out if your current systemd
supports a directive. It doesn't work for the quasi-inverse question --
given a directive, what version of systemd do I need to support this?
For people who don't run the latest and greatest all the time, I can
understand why this might be valuable.

Maybe there's some way of using git history of the gperf files to
compile a systemd.availability manpage (similar to systemd.directives).

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


Re: [systemd-devel] [PATCH] Add tool to query resolved

2014-07-30 Thread Lennart Poettering
On Wed, 16.07.14 22:55, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

 ---
 Useful? Maybe as a test binary?

Added this now.

While for most testing getent hosts and getent ahosts should be good
enough, we probably should provide a tool that can resolve full RRs,
where getent isn't enough. I'll work on extending the tool to do just
that now.

Thanks!

Lennart

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


Re: [systemd-devel] documentation and required version

2014-07-30 Thread Zbigniew Jędrzejewski-Szmek
On Wed, Jul 30, 2014 at 08:32:44AM -0400, Mauricio Tavares wrote:
 's
 
 On Wed, Jul 30, 2014 at 8:08 AM, Reindl Harald h.rei...@thelounge.net wrote:
 
 
  Am 30.07.2014 13:58, schrieb Tom Gundersen:
  On Wed, Jul 30, 2014 at 1:21 PM, Reindl Harald h.rei...@thelounge.net 
  wrote:
  http://www.freedesktop.org/software/systemd/man/systemd.exec.html
 
  such error messages caused by list all sort of options
  without any information when they where introduced are
  really annoying - the docs should clearly say the minimum
  required systemd version and the more options are added
  the more important is that
 
  Jul 30 13:17:09 rh systemd[1]: 
  [/usr/lib/systemd/system/mysqld.service:10] Unknown lvalue 
  'RuntimeDirectory' in
  section 'Service'
  Jul 30 13:17:09 rh systemd[1]: 
  [/usr/lib/systemd/system/mysqld.service:11] Unknown lvalue 
  'RuntimeDirectoryMode' in
  section 'Service
 
  Won't this be solved by using the man pages shipped with the version
  of systemd you are using?
 
  no - for several reasons
 
  * it's more comfortable to use a website with working links like
http://www.freedesktop.org/software/systemd/man/systemd.kill.html
mentioned as example in ExecStop=
 
  * it's more comfortable to have STRG+F in a webbrowsers
 
  * i currently maintain machines with 204, 208 and 215
having *one* manual open which lists all available options
and mention the minimum version of them gives a better picture
 
   Tom, I see no reason why having the man page indicate when a
 given option was introduced be any worse than your suggestion. Since
 the online man page better be the latest one, if it stated when each
 option was introduced Reindl can use the online page as he wants and
 those who want to use the man page in their computers can do the same.
 Everyone wins.
Some of our man pages in section 3 partially have history, see e.g. [1].
I think having such information is very useful, but keeping it accurate
is harder then it might seem at first. For example look at
SocketUser/SocketGroup settings. They were added in systemd-214, but
then were backported to 208-stable and 204-stable, and appeared in
Fedora in a 204 update has Fedora 19 has been out for more than an a
year [2]. It turns out that in this case man pages distributed with
the system are a more accurate source of information then anything
that could be included by upstream. So I'd be happy to merge patches
which judiciously add history for manpages which describe API changes
(i.e. section 3), but in general I don't think we have the man power
to fully describe full history of all settings in systemd.

Zbyszek

[1] http://www.freedesktop.org/software/systemd/man/sd_journal_open.html#History
[2] https://admin.fedoraproject.org/updates/FEDORA-2014-8761/systemd-204-20.fc19
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] [PATCH] man: fix outdated example in systemd.network

2014-07-30 Thread Tom Gundersen
Applied. Thanks!

Tom

On Mon, Jul 28, 2014 at 6:10 AM, Hong Shick Pak h...@hspak.com wrote:
 The docs for the DHCP= was updated, but not the example.

 ---
  man/systemd.network.xml | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/man/systemd.network.xml b/man/systemd.network.xml
 index dc34154..b0a9792 100644
 --- a/man/systemd.network.xml
 +++ b/man/systemd.network.xml
 @@ -494,7 +494,7 @@ Gateway=192.168.0.1/programlisting
  Name=en*

  [Network]
 -DHCP=yes/programlisting
 +DHCP=both/programlisting
  /example

  example
 --
 2.0.3

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


Re: [systemd-devel] documentation and required version

2014-07-30 Thread Reindl Harald
Am 30.07.2014 17:31, schrieb Zbigniew Jędrzejewski-Szmek:
 Some of our man pages in section 3 partially have history, see e.g. [1].
 I think having such information is very useful, but keeping it accurate
 is harder then it might seem at first. For example look at
 SocketUser/SocketGroup settings. They were added in systemd-214, but
 then were backported to 208-stable and 204-stable, and appeared in
 Fedora in a 204 update has Fedora 19 has been out for more than an a
 year [2]

the distribution backports don't matter in that context

the important information is feature sounds cool, what
systemd version do i need at least with that i know how
how my plans have do look like - grab if there is a backport
is a different story, users need to know works on F20, F21
but not on F19 and RHEL7

options introduced with 208 as example are considered for
my own rpm packages after the last machine is on F20 and
if PrivateDevices would be available on F20 i would even
give priority the F20 migration of our infrastructure

 It turns out that in this case man pages distributed with
 the system are a more accurate source of information then anything
 that could be included by upstream. So I'd be happy to merge patches
 which judiciously add history for manpages which describe API changes
 (i.e. section 3), but in general I don't think we have the man power
 to fully describe full history of all settings in systemd

wrong way around - don't think that complicated
somebody wrote that text below, see my fixed version at the end

*now* it is a mess and likely nobody will be able to fix the past
*but* for new options Introduced with systemd-XXX would be a no-brainer
_

RuntimeDirectory=, RuntimeDirectoryMode=

Takes a list of directory names. If set, one or more directories by the 
specified names will be created below /run
(for system services) or below $XDG_RUNTIME_DIR (for user services) when the 
unit is started, and removed when the
unit is stopped. The directories will have the access mode specified in 
RuntimeDirectoryMode=, and will be owned by
the user and group specified in User= and Group=. Use this to manage one or 
more runtime directories of the unit
and bind their lifetime to the daemon runtime. The specified directory names 
must be relative, and may not include
a /, i.e. must refer to simple directories to create or remove. This is 
particularly useful for unprivileged
daemons that cannot create runtime directories in /run due to lack of 
privileges, and to make sure the runtime
directory is cleaned up automatically after use. For runtime directories that 
require more complex or different
configuration or lifetime guarantees, please consider using tmpfiles.d(5). 
Introduced with systemd-214



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] [SOLVED] systemd-networkd could not find udev device

2014-07-30 Thread Tom Gundersen
On Tue, Jul 29, 2014 at 8:38 AM, Raimonds Cicans r...@apollo.lv wrote:
 I found who is guilty: option CONFIG_GRKERNSEC_SYSFS_RESTRICT of grsecurity
 linux kernel patch
 This option restricts /sys file system for non root users

Thanks for tracking this down.

 But IMHO error message is misleading.

I improved this a bit, by also printing the reason for the error
(Operation not permitted probably in your case). I'd be happy to
take suggestions for changing the rest of the commit message, but keep
in mind that it is fairly generic (could not get the udev device for
whatever reason).

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


Re: [systemd-devel] assert() when restarting systemd-networkd

2014-07-30 Thread Tom Gundersen
On Sun, Jul 20, 2014 at 3:12 PM, Michael Olbrich
m.olbr...@pengutronix.de wrote:
 with the current git master (v215-293-g4e6029435111) restarting
 systemd-networkd triggers an assert() here:

 In netdev_join_handler():
 assert(IN_SET(link-state, LINK_STATE_ENSLAVING, LINK_STATE_FAILED,
   LINK_STATE_LINGER));

 gdb tells me that link-state is LINK_STATE_SETTING_ADDRESSES here.

 It doesn't happen all the time, but when it happens, then the assert()
 tiggers until the start limit kicks in.

I reworked this stuff a bit. Can you reproduce with current git?

Cheers,

Tom

 My configuration looks like this:
  eth0.network---
 [Match]
 Name=eth0

 [Network]
 DHCP=v4
 IPv4LL=yes
 MACVLAN=vlan0
  vlan0.netdev
 [NetDev]
 Name=vlan0
 Kind=macvlan
 [MACVLAN]
 Mode=private
  vlan0.network---
 [Match]
 Name=vlan0

 [Network]
 Address=10.1.42.4/24
 -

 After adding Environment=SYSTEMD_LOG_LEVEL=debug to the service the journal
 looks like this:

 Jul 01 00:13:39 BaseKit systemd[1]: Starting Network Service...
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: timestamp of 
 '/lib/systemd/network' changed
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: vlan0   : loaded 
 macvlan
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: sd-rtnl: discarding 20 bytes 
 of incoming message
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: vlan0   : link 3 added
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: vlan0   : udev 
 initialized link
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: vlan0   : netdev has 
 index 3
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: vlan0   : flags 
 change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: vlan0   : gained 
 carrier
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: eth0: link 2 added
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: eth0: udev 
 initialized link
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: eth0: flags 
 change: +UP +LOWER_UP +RUNNING +MULTICAST +BROADCAST
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: eth0: gained 
 carrier
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: lo  : link 1 added
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: lo  : udev 
 initialized link
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: lo  : flags 
 change: +LOOPBACK +UP +LOWER_UP +RUNNING
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: lo  : gained 
 carrier
 Jul 01 00:13:39 BaseKit systemd[1]: Started Network Service.
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: vlan0   : link state 
 is up-to-date
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: vlan0   : found 
 matching network '/lib/systemd/network/vlan0.network'
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: vlan0   : joined netdev
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: vlan0   : setting 
 addresses
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: 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
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: Got message type=method_return 
 sender=org.freedesktop.DBus destination=:1.26 object=n/a interface=n/a 
 member=n/a cookie=1 reply_cookie=1 error=n/a
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: eth0: getting 
 address failed: Device or resource busy
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: Got message type=signal 
 sender=org.freedesktop.DBus destination=:1.26 object=/org/freedesktop/DBus 
 interface=org.freedesktop.DBus member=NameAcquired cookie=2 reply_cookie=0 
 error=n/a
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: eth0: link state 
 is up-to-date
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: eth0: found 
 matching network '/lib/systemd/network/eth0.network'
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: eth0: acquiring 
 IPv4 link-local address
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: eth0: acquiring 
 DHCPv4 lease
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: DHCP CLIENT (0x97290dbb): 
 STARTED on ifindex 2 with address 52:54:0:12:34:56
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: eth0: enslaving by 
 'vlan0'
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: IPv4LL: PROBE
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: DHCP CLIENT (0x97290dbb): 
 DISCOVER
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: lo  : getting 
 address failed: Device or resource busy
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: DHCP CLIENT (0x97290dbb): OFFER
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: lo  : link state 
 is up-to-date
 Jul 01 00:13:39 BaseKit systemd-networkd[553]: lo  : unmanaged
 Jul 01 

Re: [systemd-devel] [SOLVED] systemd-networkd could not find udev device

2014-07-30 Thread Raimonds Cicans

On 30.07.2014 19:21, Tom Gundersen wrote:

On Tue, Jul 29, 2014 at 8:38 AM, Raimonds Cicans r...@apollo.lv wrote:

I found who is guilty: option CONFIG_GRKERNSEC_SYSFS_RESTRICT of grsecurity
linux kernel patch
This option restricts /sys file system for non root users

Thanks for tracking this down.


I have 2 similar systems with systemd.
One affected with this problem and other not affected.
On affected system systemd-networkd runs under systemd user.
On other system systemd-networkd runs under root user.
Can you explain why two similar systems use different users for 
systemd-networkd?


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


Re: [systemd-devel] [SOLVED] systemd-networkd could not find udev device

2014-07-30 Thread Tom Gundersen
On Wed, Jul 30, 2014 at 6:40 PM, Raimonds Cicans r...@apollo.lv wrote:
 On 30.07.2014 19:21, Tom Gundersen wrote:

 On Tue, Jul 29, 2014 at 8:38 AM, Raimonds Cicans r...@apollo.lv wrote:

 I found who is guilty: option CONFIG_GRKERNSEC_SYSFS_RESTRICT of
 grsecurity
 linux kernel patch
 This option restricts /sys file system for non root users

 Thanks for tracking this down.


 I have 2 similar systems with systemd.
 One affected with this problem and other not affected.
 On affected system systemd-networkd runs under systemd user.
 On other system systemd-networkd runs under root user.
 Can you explain why two similar systems use different users for
 systemd-networkd?

Originally networkd was ran as root, but we recently switched it over
to its own user. So I suppose your systems may be running slightly
different versions?

Cheers,

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


[systemd-devel] [PATCH v2 0/7] kdbus: improve user domain accounting

2014-07-30 Thread Djalal Harouni
Hi,

This is series v2 of:
http://lists.freedesktop.org/archives/systemd-devel/2014-July/021526.html

This series improves user domain accounting and fixes some bugs.

It should go on top of the kdbus: allow multiple policies series:
http://lists.freedesktop.org/archives/systemd-devel/2014-July/021514.html

The v2 fixes the race previously discussed but not fixed in v1 and which
was inherited from kdbus_domain_user_find_or_new().

If kdbus_domain_user_find_or_new() is called with same parameters and
if we do not find a previously linked domain user, then we release the
domain lock, and both threads will race to assign a different ID for the
same uid, thus, invalidating the users array. We fix this in this series
by using a new kdbus_domain_user_account() function which takes the same
domain lock to perform both find a previously domain user or create and
link a new one.

Summary:
Patches 1, 2 and 3 are preparation patches to improve the code.

Patch 4 fixes kdbus_domain_user_find_or_new(), callers assume that
kdbus_domain_user_find_or_new() will fail only with -ENOMEM, but it
may fail with -ESHUTDOWN, so adapt the code to return the appropriate
errors and fix all callers. This patch also fixes the discussed race in
kdbus_domain_user_find_or_new().

Patch 5 improves the bus user quota and reduces the number of domain
locks that might be taken in that path.
Currently kdbus_bus_new() execution path might take the domain lock 3 or
4 times, reduce this to max 1 or 2 times. The domain is the upper layer,
reducing the locks should reduce some overheads.

Patch 6 fixes a user quota accounting corruption.

Patch 7 kill dead code.

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


[systemd-devel] [PATCH v2 1/7] domain: add kdbus_domain_user_assign_id() to assign IDs to domain users

2014-07-30 Thread Djalal Harouni
Signed-off-by: Djalal Harouni tix...@opendz.org
---
 domain.c | 33 +
 1 file changed, 33 insertions(+)

diff --git a/domain.c b/domain.c
index c4912fa..af9d986 100644
--- a/domain.c
+++ b/domain.c
@@ -419,6 +419,39 @@ int kdbus_domain_make_user(struct kdbus_cmd_make *cmd, 
char **name)
 }
 
 /**
+ * kdbus_domain_user_assign_id() - allocate ID and assign in it to the
+ *domain user
+ * @domain:The domain of the user
+ * @user   The kdbus_domain_user object of the user
+ *
+ * Returns 0 if ID in [0, INT_MAX] is successfully assigned to the
+ * domain user. Negative errno on failure.
+ *
+ * The user index is used in arrays for accounting user quota in
+ * receiver queues.
+ *
+ * Caller must have the domain lock held and must ensure that the
+ * domain was not disconnected.
+ */
+static int kdbus_domain_user_assign_id(struct kdbus_domain *domain,
+  struct kdbus_domain_user *user)
+{
+   int ret;
+
+   /*
+* Allocate the smallest possible index for this user; used
+* in arrays for accounting user quota in receiver queues.
+*/
+   ret = idr_alloc(domain-user_idr, user, 0, 0, GFP_KERNEL);
+   if (ret  0)
+   return ret;
+
+   user-idr = ret;
+
+   return 0;
+}
+
+/**
  * kdbus_domain_user_find_or_new() - get a kdbus_domain_user object in a domain
  * @domain:The domain
  * @uid:   The uid of the user; INVALID_UID for an anonymous
-- 
1.9.3

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


[systemd-devel] [PATCH v2 2/7] domain: add __kdbus_domain_user_account() to account domain users

2014-07-30 Thread Djalal Harouni
Add __kdbus_domain_user_account() to account and link users into a
domain.

Signed-off-by: Djalal Harouni tix...@opendz.org
---
 domain.c | 70 
 domain.h |  4 
 2 files changed, 74 insertions(+)

diff --git a/domain.c b/domain.c
index af9d986..11d7439 100644
--- a/domain.c
+++ b/domain.c
@@ -452,6 +452,76 @@ static int kdbus_domain_user_assign_id(struct kdbus_domain 
*domain,
 }
 
 /**
+ * __kdbus_domain_user_account() - account a kdbus_domain_user object
+ *into the specified domain
+ * @domain:The domain of the user
+ * @uid:   The uid of the user; INVALID_UID for an
+ * anonymous user like a custom endpoint
+ * @user   Pointer to a reference where the accounted
+ * domain user will be stored.
+ *
+ * Return: 0 on success, negative errno on failure.
+ *
+ * On success: if there is a uid matching, then use the already
+ * accounted kdbus_domain_user, increment its reference counter and
+ * return it in the 'user' argument. Otherwise, allocate a new one,
+ * link it into the domain, then return it.
+ *
+ * On failure: the 'user' argument is not updated.
+ *
+ * Caller must have the domain lock held and must ensure that the
+ * domain was not disconnected.
+ */
+int __kdbus_domain_user_account(struct kdbus_domain *domain,
+   kuid_t uid,
+   struct kdbus_domain_user **user)
+{
+   int ret;
+   struct kdbus_domain_user *tmp_user;
+   struct kdbus_domain_user *u = NULL;
+
+   /* find uid and reference it */
+   if (uid_valid(uid)) {
+   hash_for_each_possible(domain-user_hash, tmp_user,
+  hentry, __kuid_val(uid)) {
+   if (!uid_eq(tmp_user-uid, uid))
+   continue;
+
+   u = kdbus_domain_user_ref(tmp_user);
+   goto out;
+   }
+   }
+
+   ret = -ENOMEM;
+   u = kzalloc(sizeof(*u), GFP_KERNEL);
+   if (!u)
+   return ret;
+
+   kref_init(u-kref);
+   u-domain = kdbus_domain_ref(domain);
+   u-uid = uid;
+   atomic_set(u-buses, 0);
+   atomic_set(u-connections, 0);
+
+   /* Assign user ID and link into domain */
+   ret = kdbus_domain_user_assign_id(domain, u);
+   if (ret  0)
+   goto exit_free;
+
+   /* UID hash map */
+   hash_add(domain-user_hash, u-hentry, __kuid_val(u-uid));
+
+out:
+   *user = u;
+   return 0;
+
+exit_free:
+   kdbus_domain_unref(u-domain);
+   kfree(u);
+   return ret;
+}
+
+/**
  * kdbus_domain_user_find_or_new() - get a kdbus_domain_user object in a domain
  * @domain:The domain
  * @uid:   The uid of the user; INVALID_UID for an anonymous
diff --git a/domain.h b/domain.h
index 9c477db..fd2940b 100644
--- a/domain.h
+++ b/domain.h
@@ -99,6 +99,10 @@ int kdbus_domain_new(struct kdbus_domain *parent, const char 
*name,
 int kdbus_domain_make_user(struct kdbus_cmd_make *cmd, char **name);
 struct kdbus_domain *kdbus_domain_find_by_major(unsigned int major);
 
+int __kdbus_domain_user_account(struct kdbus_domain *domain,
+   kuid_t uid,
+   struct kdbus_domain_user **user);
+
 struct kdbus_domain_user
 *kdbus_domain_user_find_or_new(struct kdbus_domain *domain, kuid_t uid);
 struct kdbus_domain_user *kdbus_domain_user_ref(struct kdbus_domain_user *u);
-- 
1.9.3

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


[systemd-devel] [PATCH v2 3/7] domain: add kdbus_domain_user_account()

2014-07-30 Thread Djalal Harouni
Add kdbus_domain_user_account() to account and link users into a
domain.

This function will take the domain lock, and it will be used as a
replacement for kdbus_domain_user_find_or_new().

Signed-off-by: Djalal Harouni tix...@opendz.org
---
 domain.c | 36 
 domain.h |  4 
 2 files changed, 40 insertions(+)

diff --git a/domain.c b/domain.c
index 11d7439..1e2c3c9 100644
--- a/domain.c
+++ b/domain.c
@@ -522,6 +522,42 @@ exit_free:
 }
 
 /**
+ * kdbus_domain_user_account() - account a kdbus_domain_user object
+ *  into the specified domain
+ * @domain:The domain of the user
+ * @uid:   The uid of the user; INVALID_UID for an
+ * anonymous user like a custom endpoint
+ * @user   Pointer to a reference where the accounted
+ * domain user will be stored.
+ *
+ * Return: 0 on success, negative errno on failure.
+ *
+ * On success: if there is a uid matching, then use the already
+ * accounted kdbus_domain_user, increment its reference counter and
+ * return it in the 'user' argument. Otherwise, allocate a new one,
+ * link it into the domain, then return it.
+ *
+ * On failure: the 'user' argument is not updated.
+ *
+ * This function will first check if the domain was not disconnected.
+ */
+int kdbus_domain_user_account(struct kdbus_domain *domain,
+ kuid_t uid,
+ struct kdbus_domain_user **user)
+{
+   int ret = -ESHUTDOWN;
+
+   mutex_lock(domain-lock);
+
+   if (!domain-disconnected)
+   ret = __kdbus_domain_user_account(domain, uid, user);
+
+   mutex_unlock(domain-lock);
+
+   return ret;
+}
+
+/**
  * kdbus_domain_user_find_or_new() - get a kdbus_domain_user object in a domain
  * @domain:The domain
  * @uid:   The uid of the user; INVALID_UID for an anonymous
diff --git a/domain.h b/domain.h
index fd2940b..c81589e 100644
--- a/domain.h
+++ b/domain.h
@@ -103,6 +103,10 @@ int __kdbus_domain_user_account(struct kdbus_domain 
*domain,
kuid_t uid,
struct kdbus_domain_user **user);
 
+int kdbus_domain_user_account(struct kdbus_domain *domain,
+ kuid_t uid,
+ struct kdbus_domain_user **user);
+
 struct kdbus_domain_user
 *kdbus_domain_user_find_or_new(struct kdbus_domain *domain, kuid_t uid);
 struct kdbus_domain_user *kdbus_domain_user_ref(struct kdbus_domain_user *u);
-- 
1.9.3

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


[systemd-devel] [PATCH v2 4/7] kdbus: improve user quota accounting by using kdbus_domain_user_account()

2014-07-30 Thread Djalal Harouni
Currently kdbus_domain_user_find_or_new() is used to find a user
domain or create a new one and link it into the domain.

kdbus_domain_user_find_or_new() may fail due to memory allocation
errors or if the domain was shutdown, but since callers will
receive only a NULL pointer on failure, they assume -ENOMEM and
ignore -ESHUTDOWN. Fix this in kdbus_domain_user_account() by returning
the appropriate error code.

There are also some races with kdbus_domain_user_find_or_new(), if it is
called with the same parameters and if we do not find a previously
linked domain user, then both threads will race to assign a different ID
for the same uid, thus, invalidating the users array. We fix this in the
new kdbus_domain_user_account() and __kdbus_domain_user_account() by
taking the domain lock only one time.

Replace some kdbus_domain_user_find_or_new() calls with
kdbus_domain_user_account(). The last one in bus.c is updated in the
next patch.

Signed-off-by: Djalal Harouni tix...@opendz.org
---
 connection.c | 12 ++--
 handle.c |  8 
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/connection.c b/connection.c
index 1658a92..8838029 100644
--- a/connection.c
+++ b/connection.c
@@ -2092,12 +2092,12 @@ int kdbus_conn_new(struct kdbus_ep *ep,
 */
if (ep-user)
conn-user = kdbus_domain_user_ref(ep-user);
-   else
-   conn-user = kdbus_domain_user_find_or_new(ep-bus-domain,
-  current_fsuid());
-   if (!conn-user) {
-   ret = -ENOMEM;
-   goto exit_free_meta;
+   else {
+   ret = kdbus_domain_user_account(ep-bus-domain,
+   current_fsuid(),
+   conn-user);
+   if (ret  0)
+   goto exit_free_meta;
}
 
/* lock order: domain - bus - ep - names - conn */
diff --git a/handle.c b/handle.c
index bf32c6e..d8e1dc6 100644
--- a/handle.c
+++ b/handle.c
@@ -464,11 +464,11 @@ static long kdbus_handle_ioctl_ep(struct file *file, 
unsigned int cmd,
 * endpoint users do not share the budget with the ordinary
 * users created for a UID.
 */
-   ep-user = kdbus_domain_user_find_or_new(
-   handle-ep-bus-domain, INVALID_UID);
-   if (!ep-user) {
+   ret = kdbus_domain_user_account(
+   handle-ep-bus-domain,
+   INVALID_UID, ep-user);
+   if (ret  0) {
kdbus_ep_unref(ep);
-   ret = -ENOMEM;
break;
}
 
-- 
1.9.3

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


[systemd-devel] [PATCH v2 5/7] bus: improve user quota accounting and domain locking

2014-07-30 Thread Djalal Harouni
Currently kdbus_bus_new() execution path might take the domain lock
three times on success, four times on failure.

kdbus_bus_new():
  = kdbus_domain_user_find_or_new(): takes it 2 times (and it is racy)
  +
  kdbus_bus_new(): take it an extra time to account the user and link
  the bus into the domain bus_list.

And as discussed in the previous patch kdbus_domain_user_find_or_new()
is racy, so convert to __kdbus_domain_user_account()

This allows also to improve the execution path to take the domain lock
only one time in case of success. On failure the domain lock will be
taken two times.

kdbus_bus_new():
  = take domain lock
  = check if domain is still active/connected
 = __kdbus_domain_user_account()
  ...

Signed-off-by: Djalal Harouni tix...@opendz.org
---
 bus.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/bus.c b/bus.c
index d09e3c6..9e2f41b 100644
--- a/bus.c
+++ b/bus.c
@@ -269,13 +269,6 @@ int kdbus_bus_new(struct kdbus_domain *domain,
if (ret  0)
goto exit_free_reg;
 
-   /* account the bus against the user */
-   b-user = kdbus_domain_user_find_or_new(domain, uid);
-   if (!b-user) {
-   ret = -ENOMEM;
-   goto exit_ep_unref;
-   }
-
/* link into domain */
mutex_lock(domain-lock);
if (domain-disconnected) {
@@ -283,6 +276,11 @@ int kdbus_bus_new(struct kdbus_domain *domain,
goto exit_unref_user_unlock;
}
 
+   /* account the bus against the user */
+   ret = __kdbus_domain_user_account(domain, uid, b-user);
+   if (ret  0)
+   goto exit_unref_user_unlock;
+
if (!capable(CAP_IPC_OWNER) 
atomic_inc_return(b-user-buses)  KDBUS_USER_MAX_BUSES) {
atomic_dec(b-user-buses);
@@ -300,7 +298,6 @@ int kdbus_bus_new(struct kdbus_domain *domain,
 exit_unref_user_unlock:
mutex_unlock(domain-lock);
kdbus_domain_user_unref(b-user);
-exit_ep_unref:
kdbus_ep_unref(b-ep);
 exit_free_reg:
kdbus_name_registry_free(b-name_registry);
-- 
1.9.3

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


[systemd-devel] [PATCH v2 6/7] connection: fix user quota accounting corruption

2014-07-30 Thread Djalal Harouni
First use kzalloc to allocate the users array, so we do not reference
unintialized values.

And free the old conn-msg_users array not the newly allocated 'users'
one.

Patch tested, and users will hit the KDBUS_CONN_MAX_MSGS_PER_USER limit
and fail with -ENOBUFS

Signed-off-by: Djalal Harouni tix...@opendz.org
---
 connection.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/connection.c b/connection.c
index 8838029..3cd84ce 100644
--- a/connection.c
+++ b/connection.c
@@ -636,13 +636,13 @@ static int kdbus_conn_queue_user_quota(struct kdbus_conn 
*conn,
unsigned int i;
 
i = 8 + KDBUS_ALIGN8(user);
-   users = kmalloc(sizeof(unsigned int) * i, GFP_KERNEL);
+   users = kzalloc(sizeof(unsigned int) * i, GFP_KERNEL);
if (!users)
return -ENOMEM;
 
memcpy(users, conn-msg_users,
   sizeof(unsigned int) * conn-msg_users_max);
-   kfree(users);
+   kfree(conn-msg_users);
conn-msg_users = users;
conn-msg_users_max = i;
}
-- 
1.9.3

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


[systemd-devel] [PATCH v2 7/7] domain: remove dead kdbus_domain_user_find_or_new()

2014-07-30 Thread Djalal Harouni
Signed-off-by: Djalal Harouni tix...@opendz.org
---
 domain.c | 67 
 domain.h |  2 --
 2 files changed, 69 deletions(-)

diff --git a/domain.c b/domain.c
index 1e2c3c9..eeb73ca 100644
--- a/domain.c
+++ b/domain.c
@@ -557,73 +557,6 @@ int kdbus_domain_user_account(struct kdbus_domain *domain,
return ret;
 }
 
-/**
- * kdbus_domain_user_find_or_new() - get a kdbus_domain_user object in a domain
- * @domain:The domain
- * @uid:   The uid of the user; INVALID_UID for an anonymous
- * user like a custom endpoint
- *
- * Return: a kdbus_domain_user, either freshly allocated or with the reference
- * counter increased. In case of memory allocation failure, NULL is returned.
- */
-struct kdbus_domain_user
-*kdbus_domain_user_find_or_new(struct kdbus_domain *domain, kuid_t uid)
-{
-   struct kdbus_domain_user *u;
-   int ret;
-
-   /* find uid and reference it */
-   if (uid_valid(uid)) {
-   mutex_lock(domain-lock);
-   hash_for_each_possible(domain-user_hash, u,
-  hentry, __kuid_val(uid)) {
-   if (!uid_eq(u-uid, uid))
-   continue;
-
-   kref_get(u-kref);
-   mutex_unlock(domain-lock);
-   return u;
-   }
-   mutex_unlock(domain-lock);
-   }
-
-   /* allocate a new user */
-   u = kzalloc(sizeof(*u), GFP_KERNEL);
-   if (!u)
-   return NULL;
-
-   kref_init(u-kref);
-   u-domain = kdbus_domain_ref(domain);
-   u-uid = uid;
-   atomic_set(u-buses, 0);
-   atomic_set(u-connections, 0);
-
-   /* link into domain */
-   mutex_lock(domain-lock);
-   if (domain-disconnected) {
-   mutex_unlock(domain-lock);
-   kfree(u);
-   return NULL;
-   }
-
-   /*
-* Allocate the smallest possible index for this user; used
-* in arrays for accounting user quota in receiver queues.
-*/
-   ret = idr_alloc(domain-user_idr, u, 0, 0, GFP_KERNEL);
-   if (ret  0) {
-   mutex_unlock(domain-lock);
-   return NULL;
-   }
-   u-idr = ret;
-
-   /* UID hash map */
-   hash_add(domain-user_hash, u-hentry, __kuid_val(u-uid));
-   mutex_unlock(domain-lock);
-
-   return u;
-}
-
 static void __kdbus_domain_user_free(struct kref *kref)
 {
struct kdbus_domain_user *user =
diff --git a/domain.h b/domain.h
index c81589e..0577e5d 100644
--- a/domain.h
+++ b/domain.h
@@ -107,8 +107,6 @@ int kdbus_domain_user_account(struct kdbus_domain *domain,
  kuid_t uid,
  struct kdbus_domain_user **user);
 
-struct kdbus_domain_user
-*kdbus_domain_user_find_or_new(struct kdbus_domain *domain, kuid_t uid);
 struct kdbus_domain_user *kdbus_domain_user_ref(struct kdbus_domain_user *u);
 struct kdbus_domain_user *kdbus_domain_user_unref(struct kdbus_domain_user *u);
 #endif
-- 
1.9.3

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


Re: [systemd-devel] Support for pre-restart check

2014-07-30 Thread Colin Guthrie
Reindl Harald wrote on 30/07/14 13:34:
 *how* should that both help in calling apachectl -t *before* stop the
 service and in case of a error-repsonse keep it running?

Note, just for clarity, you don't really want to run such a config test
when explicitly stopping a service - that should always succeed IMO
(unless you think that systemctl kill ... should be used in such
circumstances?)

 ExecStopPre would be better suited as the pre-restart check because
 it would achieve the goal and also prevent stop a service until it's
 configuration is fixed - that catchs cases where you stop something
 for whatever reason and expect it would be started at the next boo

I really think an ExecRestartPre (or perhaps a more explicit
ExecRestartCheck) would be a more sensible name (ExecStopPre implies it
would run when explicitly stopping which, as noted above, I think is a
bad plan). It wouldn't run when an ExecReload is given explicitly but if
that operation falls back to restart, it would.

I think the use case is pretty clear tho'. Config (or general machine
state) has transitioned from working to broken in the time since the
service was started and while it's really not a nice situation to find
yourself in (relying on a running service not crashng!), this at least
helps avoid nasty consequences for the most part while you work to fix
things.

Col



-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] [PATCH] allow systemd to manage loop device partitions

2014-07-30 Thread Kevin Wells
Hello,

A recent change to udev prevented loop partitions (ex. /dev/loop0p2) from
being managed by systemd.  I'd like to modify the rule to match only what
was intended, loop devices that aren't yet attached to anything.

git format-patch below.  I've never submitted a patch before, please let me
know if I did this wrong.


SYSTEMD_READY is currently set to 0 for all loop devices (loop[0-9]*)
that do not have a backing_file. Partitioned loop devices (ex. loop0p1),
however, are matched by this rule and excluded by systemd even though
they are active devices.

This change adds an additional check to the rule, ensuring that only
top level loop devices (loop[0-9]+$) are excluded from systemd.
---
 rules/99-systemd.rules.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rules/99-systemd.rules.in b/rules/99-systemd.rules.in
index c3ef81b..aa435c4 100644
--- a/rules/99-systemd.rules.in
+++ b/rules/99-systemd.rules.in
@@ -23,7 +23,7 @@ SUBSYSTEM==block, ENV{DEVTYPE}==disk, KERNEL==md*,
TEST!=md/array_state,
 SUBSYSTEM==block, ENV{DEVTYPE}==disk, KERNEL==md*,
ATTR{md/array_state}==|clear|inactive, ENV{SYSTEMD_READY}=0

 # Ignore loop devices that don't have any file attached
-SUBSYSTEM==block, KERNEL==loop[0-9]*, TEST!=loop/backing_file,
ENV{SYSTEMD_READY}=0
+SUBSYSTEM==block, KERNEL==loop[0-9]*, ENV{DEVTYPE}==disk,
TEST!=loop/backing_file, ENV{SYSTEMD_READY}=0

 # Ignore nbd devices in the add event, with change the nbd is ready
 ACTION==add, SUBSYSTEM==block, KERNEL==nbd*, ENV{SYSTEMD_READY}=0
-- 
2.0.3


Why add the check I did?
inactive loop devices have a DEVTYPE of disk and no backing file
active loop devices have a DEVTYPE of disk and a backing file
active loop partitions (loop*p*) have a DEVTYPE of partition and no backing
file

So, this change selects on both a DEVTYPE of disk and no backing file, so
we only get inactive loop devices, and not loop partitions, that might just
happen to be my root partition.

Thanks!

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


Re: [systemd-devel] Support for pre-restart check

2014-07-30 Thread Jóhann B. Guðmundsson


On 07/31/2014 12:16 AM, Colin Guthrie wrote:

I think the use case is pretty clear tho'. Config (or general machine
state) has transitioned from working to broken in the time since the
service was started and while it's really not a nice situation to find
yourself in (relying on a running service not crashng!), this at least
helps avoid nasty consequences for the most part while you work to fix
things.


The use case administrator want, is fixing their own lazyness and 
incompetence not having to run the configuration syntax checker by hand 
after they made changes to the configuration for one of those handful of 
daemon/service that actually come with those.


But let's continue on this path once that is implemented they want to be 
notified one way or another why the service failed to be restarted as in 
the actual failed line of the configuration mistake they made so they 
can go and fix it ( and apachctl -t purpose is... ) but that cannot be 
implemented in the status output because. remember they where to lazy to 
run the configuration syntax checker by hand after the change they made 
so they are to lazy to run systemctl status foo so you do realize the 
underlying problem for this cannot be solved right?


People tried in the past doing so by writing massive initscript that 
never worked...


Now that broken machine state is not limited to configuration changes 
since it could also happen due to an bad update or incompatable update ( 
configuration file syntax changes between releases, apache 2.2 vs 2.4 
for example ) so the only way you can try to solve this is by 
introducing a fake restart of the service which cannot be manually 
defined what is but has to be built in with the know of only turning it 
on or off for type units which covers *something* has changed can the 
service be restarted *safely* afterwards, if it does restart the service.


Bottom line if the intent is for systemd to solve the use case you 
stated the solution for this need to be a permanent fix that covers all 
service/daemons not yet another line that leads to administrators define 
another command to take care of that...


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