Re: [systemd-devel] [PATCH] systemd-detect-s390-virt: add virtualization detection on s390x

[Thomas Blume]

On Fri, 18 Jul 2014, Dan Horák wrote:


On Fri, 18 Jul 2014 13:42:21 +0200 (CEST)
Thomas Blume  wrote:


Ok, thanks for the input.
Attached is the new patch.


Thomas, do you know whether the VM00 info always refer to the top-level
virt, where the Linux guest runs? I've already seen a 2nd level z/VM
setup, so there were VM00 and VM01 info, but don't remember how they
were ordered.


I had a look around for this and talked to our s390 guys.
All information pointed to VM00 as top level virtualization.
If you have kvm stacked on z/VM, you should see z/VM as VM01 and kvm as VM00.
See for example:

https://www.mail-archive.com/kvm@vger.kernel.org/msg00625.html

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

Re: [systemd-devel] crypttab automount

[Jan]

Ralf Jung  ralfj.de> writes:

> 
> Hi all,
> 
> first of all, please forgive me if this is not the right list for
> questions of systemd users. In this case, I would appreciate if you
> could forward me to the right channel for my question. I couldn't find a
> "systemd-users" list.
> 
> In my laptop, I do have an encrypted partition on a second HDD that I
> want to be be mounted automatically, but without delaying the boot.
> Concretely, I have the following in my /etc/crypttab:
> 
> >  store   UUID=...  /some/keyfile luks
> 

You were looking for the "noauto" option for crypttab (it's in the manpage,
btw).
The unit will then only get activated when the automount point is accessed.
As far
as I know, this will only work if the corresponding fstab device is from
/dev/mapper/.

Jan

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

Re: [systemd-devel] [PATCH 1/2] core: do not add default dependencies to /usr mount unit

[Jon Severinsson]

At Tuesday 22 July 2014 04:46:31 Andrey Borzenkov wrote:
> But what exact problem does it solve?

Units thinking they can read from /usr before local-fs-pre.target
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 1/2] core: do not add default dependencies to /usr mount unit

[Andrey Borzenkov]

В Tue, 22 Jul 2014 00:39:13 +0200
Jon Severinsson  пишет:

> This makes no difference if /usr was mounted in the initrd,
> and brings the behaviour of legacy systems closer to those
> with a propper initrd.

This should be documented in systemd.special(7) then.

But what exact problem does it solve?

> ---
>  src/core/mount.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/src/core/mount.c b/src/core/mount.c
> index 102bbef..39a9aaf 100644
> --- a/src/core/mount.c
> +++ b/src/core/mount.c
> @@ -380,7 +380,8 @@ static int mount_add_default_dependencies(Mount *m) {
>  if (!p)
>  return 0;
>  
> -if (path_equal(m->where, "/"))
> +if (path_equal(m->where, "/") ||
> +path_equal(m->where, "/usr"))
>  return 0;
>  
>  if (mount_is_network(p)) {

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

Re: [systemd-devel] [PATCH v2] readahead: use BTRFS_IOC_DEFRAG_RANGE

[Andrey Borzenkov]

В Mon, 21 Jul 2014 16:51:22 +0300
Timofey Titovets  пишет:

> Zbyszek, thanks for comment, i will work on fixing what you say and
> resend patch.
> 
> >> Just completed TODO:
> >> * readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG
> >
> > This is still not an explanation. What is the difference between the
> > two?
> 
> I can't explain it, because no i add this todo in TODO list (recursively 
> todo%)

I could not find any previous discussion on systemd list. TODO was
added by Lennart.

> >> -  - readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG 
> >> ioctl, with START_IO
> But as i understand start_io option force write data, without
> buffering in memory, to the disk.
> may be it have a sacral sense, i ask for comments in btrfs list for
> explaration and add explanation to the v3
> 

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

Re: [systemd-devel] [PATCH v2] readahead: use BTRFS_IOC_DEFRAG_RANGE

[Andrey Borzenkov]

В Mon, 21 Jul 2014 18:15:37 +0300
Timofey Titovets  пишет:

> Zbyszek, i research problem and i found what in btrfs.h
> struct btrfs_ioctl_defrag_range_args  not defined
> This acceptable if i add it in missing.h like:
> /* btrfs_ioctl_defrag_range_args now 21.07.2014
>  * not defined in btrfs.h and duplicated from /fs/btrfs/ctree.h
>  */
> #ifdef HAVE_LINUX_BTRFS_H
> struct btrfs_ioctl_defrag_range_args {
> uint64_t start; /* start byte = 0 */
> uint64_t len;   /* whole file uint64_t-1 */
> uint64_t flags; /* start_io 2 */
> uint32_t extent_thresh; /* 0 */
> uint32_t compress_type;
> uint32_t unused[4];
> };
> #endif
> 

I think it should really be discussed on btrfs list. It must be
properly exported to user space if user space is going to use it.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] networkd: fix reporting errors from hostnamed

[Michael Marineau]

The return value may be -EINVAL or a positive errno from the dbus
message. Check both ranges, otherwise most errors are silently ignored.
---
 src/network/networkd-link.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
index 7a0f30b..be879fd 100644
--- a/src/network/networkd-link.c
+++ b/src/network/networkd-link.c
@@ -845,7 +845,9 @@ static int set_hostname_handler(sd_bus *bus, sd_bus_message 
*m, void *userdata,
 
 r = sd_bus_message_get_errno(m);
 if (r < 0)
-log_warning_link(link, "Could not set hostname: %s", 
strerror(-r));
+r = -r;
+if (r > 0)
+log_warning_link(link, "Could not set hostname: %s", 
strerror(r));
 
 return 1;
 }
-- 
1.8.5.5

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

Re: [systemd-devel] sysusers and login.defs checks

[Colin Guthrie]

'Twas brillig, and Lennart Poettering at 21/07/14 23:28 did gyre and gimble:
> On Mon, 21.07.14 15:43, Lennart Poettering (lenn...@poettering.net) wrote:
> 
>>> While I appreciate sysusers is intended primarily for bootstrapping
>>> /etc, I guess the general consensus is to move package pre/post scripts
>>> over to use sysusers instead anyway. Thus the tool should really check
>>> /etc/login.defs at runtime if it's present before falling back to its
>>> defaults. Those defaults could be set from a compile time check of
>>> login.defs too.
>>
>> I am pretty strongly against this. Making this administrator
>> configurable apepars very wrong, this really should be a decision for
>> the distribution vendor, and that's it.  We shouldn't design a system
>> that comes to completely different results if you boot it up with and
>> without /etc populated...
> 
> Here's another idea: maybe we can bind this to the "users" group. Many
> distributions (not all...) have this group and add regular users to
> it. Maybe that's what we should use on top of the numeric UID boundary
> check: if some user is either >= 1000 or is a member of the "users"
> group we will consider him or her a regular user instead of a system
> user. In many cases this should magically make things work. And even where
> this isn't sufficient we at least have a nice solution to tell people:
> make your user a member of "users" and it will properly be recognised as
> regular user.
> 
> Happy to add a patch for this!

And I guess this heuristic would be easy enough to add to
accountsservice too.

I guess it's OK to do this kind of user lookup stuff from the journal
code (i.e. server_fix_perms())?

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 2/2] units: add RequiresMountsFor=/usr/… to various systemd service files

[Jon Severinsson]

Unless both /usr and /usr/local is mounted in the initrd these
services might miss some of their configuration otherwise.
---
 units/systemd-binfmt.service.in | 1 +
 units/systemd-modules-load.service.in   | 1 +
 units/systemd-sysctl.service.in | 1 +
 units/systemd-sysusers.service.in   | 1 +
 units/systemd-timedated.service.in  | 1 +
 units/systemd-tmpfiles-setup.service.in | 1 +
 6 files changed, 6 insertions(+)

diff --git a/units/systemd-binfmt.service.in b/units/systemd-binfmt.service.in
index 02dfe77..a8fe42e 100644
--- a/units/systemd-binfmt.service.in
+++ b/units/systemd-binfmt.service.in
@@ -11,6 +11,7 @@ Documentation=man:systemd-binfmt.service(8) man:binfmt.d(5)
 Documentation=https://www.kernel.org/doc/Documentation/binfmt_misc.txt
 DefaultDependencies=no
 Conflicts=shutdown.target
+RequiresMountsFor=/usr/lib/binfmt.d /usr/local/lib/binfmt.d
 After=systemd-readahead-collect.service systemd-readahead-replay.service 
proc-sys-fs-binfmt_misc.automount
 Before=sysinit.target shutdown.target
 ConditionPathIsReadWrite=/proc/sys/
diff --git a/units/systemd-modules-load.service.in 
b/units/systemd-modules-load.service.in
index 32deb52..0619037 100644
--- a/units/systemd-modules-load.service.in
+++ b/units/systemd-modules-load.service.in
@@ -10,6 +10,7 @@ Description=Load Kernel Modules
 Documentation=man:systemd-modules-load.service(8) man:modules-load.d(5)
 DefaultDependencies=no
 Conflicts=shutdown.target
+RequiresMountsFor=/usr/lib/modules-load.d /usr/local/lib/modules-load.d
 After=systemd-readahead-collect.service systemd-readahead-replay.service
 Before=sysinit.target shutdown.target
 ConditionCapability=CAP_SYS_MODULE
diff --git a/units/systemd-sysctl.service.in b/units/systemd-sysctl.service.in
index ade9dc3..a40bd12 100644
--- a/units/systemd-sysctl.service.in
+++ b/units/systemd-sysctl.service.in
@@ -10,6 +10,7 @@ Description=Apply Kernel Variables
 Documentation=man:systemd-sysctl.service(8) man:sysctl.d(5)
 DefaultDependencies=no
 Conflicts=shutdown.target
+RequiresMountsFor=/usr/lib/sysctl.d /usr/local/lib/sysctl.d
 After=systemd-readahead-collect.service systemd-readahead-replay.service
 After=systemd-modules-load.service
 Before=sysinit.target shutdown.target
diff --git a/units/systemd-sysusers.service.in 
b/units/systemd-sysusers.service.in
index 69fea11..d7fb678 100644
--- a/units/systemd-sysusers.service.in
+++ b/units/systemd-sysusers.service.in
@@ -10,6 +10,7 @@ Description=Create System Users
 Documentation=man:sysusers.d(5) man:systemd-sysusers.service(8)
 DefaultDependencies=no
 Conflicts=shutdown.target
+RequiresMountsFor=/usr/lib/sysusers.d /usr/local/lib/sysusers.d
 After=systemd-readahead-collect.service systemd-readahead-replay.service 
systemd-remount-fs.service
 Before=sysinit.target shutdown.target systemd-update-done.service
 ConditionNeedsUpdate=/etc
diff --git a/units/systemd-timedated.service.in 
b/units/systemd-timedated.service.in
index fe5ccb4..6385738 100644
--- a/units/systemd-timedated.service.in
+++ b/units/systemd-timedated.service.in
@@ -9,6 +9,7 @@
 Description=Time & Date Service
 Documentation=man:systemd-timedated.service(8) man:localtime(5)
 Documentation=http://www.freedesktop.org/wiki/Software/systemd/timedated
+RequiresMountsFor=/usr/share/zoneinfo
 
 [Service]
 ExecStart=@rootlibexecdir@/systemd-timedated
diff --git a/units/systemd-tmpfiles-setup.service.in 
b/units/systemd-tmpfiles-setup.service.in
index 72ab083..b968e83 100644
--- a/units/systemd-tmpfiles-setup.service.in
+++ b/units/systemd-tmpfiles-setup.service.in
@@ -10,6 +10,7 @@ Description=Create Volatile Files and Directories
 Documentation=man:tmpfiles.d(5) man:systemd-tmpfiles(8)
 DefaultDependencies=no
 Conflicts=shutdown.target
+RequiresMountsFor=/usr/lib/tmpfiles.d /usr/local/lib/tmpfiles.d
 After=systemd-readahead-collect.service systemd-readahead-replay.service 
local-fs.target systemd-sysusers.service
 Before=sysinit.target shutdown.target
 RefuseManualStop=yes
-- 
2.0.1

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

[systemd-devel] [PATCH 1/2] core: do not add default dependencies to /usr mount unit

[Jon Severinsson]

This makes no difference if /usr was mounted in the initrd,
and brings the behaviour of legacy systems closer to those
with a propper initrd.
---
 src/core/mount.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/core/mount.c b/src/core/mount.c
index 102bbef..39a9aaf 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -380,7 +380,8 @@ static int mount_add_default_dependencies(Mount *m) {
 if (!p)
 return 0;
 
-if (path_equal(m->where, "/"))
+if (path_equal(m->where, "/") ||
+path_equal(m->where, "/usr"))
 return 0;
 
 if (mount_is_network(p)) {
-- 
2.0.1

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

[systemd-devel] [PATCH] core: collapse JOB_RELOAD on an inactive unit into JOB_NOP [v2]

[Jon Severinsson]

The old behavior is inconsistent and confusing, this commit simplifies matters 
significantly:

Before this commit:
  * systemctl try-restart on any inactive unit returns *success* immediately
  * systemctl reload on an inactive unit without a queued start job returns 
*failure* immediately
  * systemctl reload on an inactive unit supporting reload with a queued start 
job blocks until the unit is started
  * systemctl reload on an inactive unit not supporting reload with a queued 
start returns *failure* immediately
  * systemctl reload-or-try-restart on an inactive unit supporting reload 
blocks until the unit is started
  * systemctl reload-or-try-restart on an inactive unit not supporting reload 
returns *success* immediately

With this commit:
  * systemctl try-restart, reload and reload-or-try-restart on any inactive 
unit returns *success* immediately

By not blocking on a queued start job this also fixes a deadlock when
one job calls systemctl reload or reload-or-try-restart on a unit with
a start job ordered later in the transaction.
---
 src/core/job.c  |  5 +
 src/core/unit.c | 10 ++
 2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/src/core/job.c b/src/core/job.c
index dc4f441..ff94f73 100644
--- a/src/core/job.c
+++ b/src/core/job.c
@@ -362,6 +362,11 @@ void job_type_collapse(JobType *t, Unit *u) {
 
 switch (*t) {
 
+case JOB_RELOAD:
+s = unit_active_state(u);
+if (UNIT_IS_INACTIVE_OR_FAILED(s))
+*t = JOB_NOP;
+
 case JOB_TRY_RESTART:
 s = unit_active_state(u);
 if (UNIT_IS_INACTIVE_OR_DEACTIVATING(s))
diff --git a/src/core/unit.c b/src/core/unit.c
index b68796a..2a5897a 100644
--- a/src/core/unit.c
+++ b/src/core/unit.c
@@ -1389,12 +1389,14 @@ int unit_reload(Unit *u) {
 if (state == UNIT_RELOADING)
 return -EALREADY;
 
-if (state != UNIT_ACTIVE) {
-log_warning_unit(u->id, "Unit %s cannot be reloaded because it 
is inactive.",
- u->id);
-return -ENOEXEC;
+if (UNIT_IS_INACTIVE_OR_FAILED(state)) {
+log_debug_unit(u->id, "Unit %s cannot be reloaded because it 
is inactive.", u->id);
+return -EALREADY;
 }
 
+if (state != UNIT_ACTIVE)
+return -EAGAIN;
+
 following = unit_following(u);
 if (following) {
 log_debug_unit(u->id, "Redirecting reload request from %s to 
%s.",
-- 
2.0.1

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

Re: [systemd-devel] sysusers and login.defs checks

[Lennart Poettering]

On Mon, 21.07.14 15:43, Lennart Poettering (lenn...@poettering.net) wrote:

> > While I appreciate sysusers is intended primarily for bootstrapping
> > /etc, I guess the general consensus is to move package pre/post scripts
> > over to use sysusers instead anyway. Thus the tool should really check
> > /etc/login.defs at runtime if it's present before falling back to its
> > defaults. Those defaults could be set from a compile time check of
> > login.defs too.
> 
> I am pretty strongly against this. Making this administrator
> configurable apepars very wrong, this really should be a decision for
> the distribution vendor, and that's it.  We shouldn't design a system
> that comes to completely different results if you boot it up with and
> without /etc populated...

Here's another idea: maybe we can bind this to the "users" group. Many
distributions (not all...) have this group and add regular users to
it. Maybe that's what we should use on top of the numeric UID boundary
check: if some user is either >= 1000 or is a member of the "users"
group we will consider him or her a regular user instead of a system
user. In many cases this should magically make things work. And even where
this isn't sufficient we at least have a nice solution to tell people:
make your user a member of "users" and it will properly be recognised as
regular user.

Happy to add a patch for this!

Lennart

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

[systemd-devel] Start Up services using systemd

[Bharath Chandra]

Hi,

I am trying to analyze what all services that would start during boot up
process statically, i.e just by looking into the unit files, without
running the system. I have understood the dependecies of unit files using
Wants, Requires,After but i do not find all of the services which are
listed under a specific target.wants directory to be in active state.

Eg: All the services are not loaded which are present under
multi-user.target.wants directory. I am new to systemd. Kindly help me in
understanding the dependencies.

Thanks & Regards,
Bharath Chandra Elluru.
Contact Number:785-979-4875.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] systemd-verify: call help() and exit if no CL-argument

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jul 21, 2014 at 08:04:33PM +0200, Daniel Buch wrote:
> Im not sure if we want the help approach or just fail?
> 
> I can change this and resed if you want.
> 
> Assertion 'strv_uniq(ans)' failed at src/verify/verify.c:53, function 
> generate_path(). Aborting.
> [1]4795 abort (core dumped)  systemd-verify
Hm, it was supposed to do nothing in that case.

But Lennart wants it the code merged with systemd-analyze (or systemctl).
I'll add a check when doing that.

> -int c;
> +int c, left;
>  
>  assert(argc >= 1);
>  assert(argv);
>  
>  opterr = 0;
>  
> +left = argc - optind;
> +
> +if (left <= 0) {
> +help();
> +return -EINVAL;
> +}
(I really hate the "print help on error" approach, because it usually
obscures the error. In addition, help() prints to stdout, which is
wrong.)

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

Re: [systemd-devel] [systemd-commits] 4 commits - man/systemd.netdev.xml src/libsystemd src/network

[Tom Gundersen]

On Mon, Jul 21, 2014 at 8:44 PM, Lennart Poettering
 wrote:
> On Mon, 21.07.14 11:36, Tom Gundersen (tome...@kemper.freedesktop.org) wrote:
>
>> +if (b->miimon != 0) {
>> +r = sd_rtnl_message_append_u32(m, IFLA_BOND_MIIMON,
>> b->miimon / 1000);
>
> We have these nice USEC_PER_MSEC-style macro definitions which make it a
> little bit clearer what we are converting here from what into
> what... please use that instead of writing "1000"...


Indeed. Fixed.

Thanks!

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

Re: [systemd-devel] [systemd-commits] 4 commits - man/systemd.netdev.xml src/libsystemd src/network

[Lennart Poettering]

On Mon, 21.07.14 11:36, Tom Gundersen (tome...@kemper.freedesktop.org) wrote:

> +if (b->miimon != 0) {
> +r = sd_rtnl_message_append_u32(m, IFLA_BOND_MIIMON,
> b->miimon / 1000);

We have these nice USEC_PER_MSEC-style macro definitions which make it a
little bit clearer what we are converting here from what into
what... please use that instead of writing "1000"...

(we stole those from gstreamer btw)

Lennart

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

[systemd-devel] [PATCH] systemd-verify: call help() and exit if no CL-argument

[Daniel Buch]

Im not sure if we want the help approach or just fail?

I can change this and resed if you want.

Assertion 'strv_uniq(ans)' failed at src/verify/verify.c:53, function 
generate_path(). Aborting.
[1]4795 abort (core dumped)  systemd-verify
---
 src/verify/verify.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/verify/verify.c b/src/verify/verify.c
index c1a3da8..b9f4372 100644
--- a/src/verify/verify.c
+++ b/src/verify/verify.c
@@ -300,13 +300,20 @@ static int parse_argv(int argc, char *argv[]) {
 {}
 };
 
-int c;
+int c, left;
 
 assert(argc >= 1);
 assert(argv);
 
 opterr = 0;
 
+left = argc - optind;
+
+if (left <= 0) {
+help();
+return -EINVAL;
+}
+
 while ((c = getopt_long(argc, argv, ":h", options, NULL)) >= 0)
 switch (c) {
 
-- 
2.0.2

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

[systemd-devel] [PATCH v3] readahead: use BTRFS_IOC_DEFRAG_RANGE

[Timofey Titovets]

Just completed TODO:
* readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG 
ioctl, with START_IO


commit d3fc81bd6a5a046b22600ac1204df220c93d2c15 refs/tags/v30
Author: Lennart Poettering 
Date:   Wed Jun 15 15:39:10 2011 +0200

update TODO

i no add this todo in TODO list (recursively todo %), and as this my 
opinion may be not relevant with author.


As i understand start_io option force write data after defragment, 
without buffering it in memory.



v1 -> v2
Fixed spelling in TODO

v2 -> v3
Deleted todo from code
Fix compilation issues
Delete fallback code, because BTRFS_IOC_DEFRAG_RANGE supported as 2.6.29 
oldest longterm 2.6.32.63



 TODO  |  1 -
 src/readahead/readahead-collect.c | 15 ---
 src/shared/missing.h  | 16 
 3 files changed, 28 insertions(+), 4 deletions(-)

diff --git a/TODO b/TODO
index bfa06de..636d25f 100644
--- a/TODO
+++ b/TODO
@@ -570,7 +570,6 @@ Features:
 * readahead:
   - drop /.readahead on bigger upgrades with yum
   - move readahead files into /var (look for them with .path units?)
-  - readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG 
ioctl, with START_IO
   - readahead: when bumping /sys readahead variable save mtime and 
compare later to detect changes
   - readahead: make use of EXT4_IOC_MOVE_EXT, as used by 
http://e4rat.sourceforge.net/


diff --git a/src/readahead/readahead-collect.c 
b/src/readahead/readahead-collect.c

index c1afd0d..c641f9a 100644
--- a/src/readahead/readahead-collect.c
+++ b/src/readahead/readahead-collect.c
@@ -48,6 +48,10 @@
 #include 
 #endif

+#ifdef HAVE_BTRFS_IOCTL_H
+#include 
+#endif
+
 #ifdef HAVE_FANOTIFY_INIT
 #include 
 #endif
@@ -78,10 +82,15 @@ static usec_t starttime;
 #define SECTOR_TO_PTR(s) ULONG_TO_PTR((s)+1)
 #define PTR_TO_SECTOR(p) (PTR_TO_ULONG(p)-1)

-static int btrfs_defrag(int fd) {
-struct btrfs_ioctl_vol_args data = { .fd = fd };
+static int btrfs_defrag(int fd){
+static struct btrfs_ioctl_defrag_range_args range = {
+.start = 0,
+.len = (uint64_t)-1,
+.flags = 2,
+.extent_thresh = 1
+};

-return ioctl(fd, BTRFS_IOC_DEFRAG, &data);
+return ioctl(fd, BTRFS_IOC_DEFRAG_RANGE, &range);
 }

 static int pack_file(FILE *pack, const char *fn, bool on_btrfs) {
diff --git a/src/shared/missing.h b/src/shared/missing.h
index 818d704..8f54dc8 100644
--- a/src/shared/missing.h
+++ b/src/shared/missing.h
@@ -186,6 +186,17 @@ static inline int fanotify_mark(int fanotify_fd, 
unsigned int flags, uint64_t ma

 #define BTRFS_UUID_SIZE 16
 #endif

+#ifndef HAVE_BTRFS_IOCTL_H
+struct btrfs_ioctl_defrag_range_args {
+uint64_t start; /* start byte = 0 */
+uint64_t len;   /* whole file uint64_t-1 */
+uint64_t flags; /* start_io 2 */
+uint32_t extent_thresh; /* rewrite extents 0 */
+uint32_t compress_type; /* unspecified -> zlib */
+uint32_t unused[4]; /* reserved */
+};
+#endif
+
 #ifndef HAVE_LINUX_BTRFS_H
 struct btrfs_ioctl_vol_args {
 int64_t fd;
@@ -213,6 +224,11 @@ struct btrfs_ioctl_fs_info_args {
 #define BTRFS_IOC_DEFRAG _IOW(BTRFS_IOCTL_MAGIC, 2, struct 
btrfs_ioctl_vol_args)

 #endif

+#ifndef BTRFS_IOC_DEFRAG_RANGE
+#define BTRFS_IOC_DEFRAG_RANGE _IOW(BTRFS_IOCTL_MAGIC, 16, \
+   struct 
btrfs_ioctl_defrag_range_args)

+#endif
+
 #ifndef BTRFS_IOC_DEV_INFO
 #define BTRFS_IOC_DEV_INFO _IOWR(BTRFS_IOCTL_MAGIC, 30, \
  struct btrfs_ioctl_dev_info_args)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH v2] Refuse mount on symlink

[Timofey Titovets]

Just complete TODO:
* refuse mounting on symlinks

I not add this TODO, but i think what it avoid potential security 
{and/or} bug issues


if systemd try mounting entry from fstab on symlink, user get something 
systemctl status symlink.mount

● symlink.mount - /symlink
   Loaded: loaded (/etc/fstab)
   Active: failed (Result: resources)
Where: /symlink
 What: tmpfs
 Docs: man:fstab(5)
   man:systemd-fstab-generator(8)

Jul 21 19:10:39 beplan.lan systemd[1]: Mounting /symlink...
Jul 21 19:10:39 beplan.lan systemd[1]: symlink.mount: Directory /symlink 
to mount over is not empty, mounting anyway.
Jul 21 19:10:39 beplan.lan systemd[1]: symlink.mount failed to run 
'mount' task: Too many levels of symbolic links

Jul 21 19:10:39 beplan.lan systemd[1]: Failed to mount /symlink.
Jul 21 19:10:39 beplan.lan systemd[1]: Unit symlink.mount entered failed 
state.


can be pulled from:
https://github.com/Nefelim4ag/systemd.git


 TODO  |  2 --
 src/core/mount.c  | 13 +
 src/core/mount.h  |  2 ++
 src/shared/util.c | 12 
 src/shared/util.h |  2 ++
 5 files changed, 29 insertions(+), 2 deletions(-)

diff --git a/TODO b/TODO
index 4a1313d..fd5105d 100644
--- a/TODO
+++ b/TODO
@@ -54,8 +54,6 @@ Features:

 * order OnCalendar timer units after timer-sync.target if 
DefaultDependencies=no so that we don't trigger them prematurely


-* refuse mounting on symlinks
-
 * logind: allow users to kill or lock their own sessions

 * add new gpt type for btrfs volumes
diff --git a/src/core/mount.c b/src/core/mount.c
index 102bbef..6bef486 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -826,6 +826,15 @@ void warn_if_dir_nonempty(const char *unit, const 
char* where) {

NULL);
 }

+int fail_if_symlink(const char *unit, const char* where) {
+assert(where);
+
+if (!is_symlink(where))
+return 0;
+
+return -ELOOP;
+}
+
 static void mount_enter_unmounting(Mount *m) {
 int r;

@@ -876,6 +885,10 @@ static void mount_enter_mounting(Mount *m) {
 if (p && mount_is_bind(p))
 mkdir_p_label(p->what, m->directory_mode);

+r = fail_if_symlink(m->meta.id, m->where);
+if (r < 0)
+goto fail;
+
 if (m->from_fragment)
 r = exec_command_set(
 m->control_command,
diff --git a/src/core/mount.h b/src/core/mount.h
index 2dcb663..5fc1fe1 100644
--- a/src/core/mount.h
+++ b/src/core/mount.h
@@ -128,3 +128,5 @@ const char* mount_result_to_string(MountResult i) 
_const_;

 MountResult mount_result_from_string(const char *s) _pure_;

 void warn_if_dir_nonempty(const char *unit, const char* where);
+
+int fail_if_symlink(const char *unit, const char* where);
\ No newline at end of file
diff --git a/src/shared/util.c b/src/shared/util.c
index 4fda31c..d13c6e6 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -6866,3 +6866,15 @@ int take_password_lock(const char *root) {

 return fd;
 }
+
+int is_symlink(const char *path) {
+struct stat info;
+
+if (lstat(path, &info) < 0)
+return -errno;
+
+if (S_ISLNK(info.st_mode))
+return 1;
+
+return 0;
+}
\ No newline at end of file
diff --git a/src/shared/util.h b/src/shared/util.h
index d9d525e..90cb45b 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -973,3 +973,5 @@ char *tempfn_random(const char *p);
 bool is_localhost(const char *hostname);

 int take_password_lock(const char *root);
+
+int is_symlink(const char *path);
\ No newline at end of file
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd read-only RootFS for flash-menory usage ?

[Lennart Poettering]

On Sat, 19.07.14 16:04, lux-integ (lux-in...@btconnect.com) wrote:

> Greetings,
> 
> I have a computer with  these
> --OS Linux 64bit BLFS  Linux
> --relatively recent version of systemd
> --no hard disk  but instead   compact flash disk
> 
> 
> I am running vanilla systemd ( i.e.  as compiled from source code   and 
> without any   change in scripts ) successfully.
> 
> I want to protect the flash card by minimisng the amount of writes and  
> erases 
> so I want to create  a /var partition in RAM for logfiles and mount   
> /var on booting  as R/W and the rest as readonly.  I have a number of 
> questions:-
> 
> 
> --Can systemd be run from a read-only root filesystem ?

Sure.

> --If the   suggestion above  (/var in RAM   and   rest  of FS is RO) is not 
> feasible  is there an alternative/better solution?

It's totally feasible. Very recent systemd versions should be able to
set up the most basic stuff in /var automatically, if it is unpopulated
at boot, like it is if you make it a tmpfs. 

Just make /var a tmpfs via fstab and things should mostly work.

Note though that some third-party packages might have problems though if
/var is flushed on every boot. But via some tmpfiles snippets it should
be relatively easy to reconstruct the bits that are necessary for those
at boot.

Lennart

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

Re: [systemd-devel] [PATCH v2] readahead: use BTRFS_IOC_DEFRAG_RANGE

[Timofey Titovets]

Zbyszek, i research problem and i found what in btrfs.h
struct btrfs_ioctl_defrag_range_args  not defined
This acceptable if i add it in missing.h like:
/* btrfs_ioctl_defrag_range_args now 21.07.2014
 * not defined in btrfs.h and duplicated from /fs/btrfs/ctree.h
 */
#ifdef HAVE_LINUX_BTRFS_H
struct btrfs_ioctl_defrag_range_args {
uint64_t start; /* start byte = 0 */
uint64_t len;   /* whole file uint64_t-1 */
uint64_t flags; /* start_io 2 */
uint32_t extent_thresh; /* 0 */
uint32_t compress_type;
uint32_t unused[4];
};
#endif

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

Re: [systemd-devel] logind has no holdoff time

[poma]

On 21.07.2014 11:56, poma wrote:

On 20.07.2014 23:20, poma wrote:


What's so special about i686!?

systemd[1]: Failed to start Login Service.
systemd[1]: Unit systemd-logind.service entered failed state.
systemd[1]: systemd-logind.service has no holdoff time, scheduling restart.
https://bugzilla.redhat.com/show_bug.cgi?id=1121419



https://bugzilla.redhat.com/show_bug.cgi?id=1120473#c1



Resolved via DIY method. :)
https://bugzilla.redhat.com/show_bug.cgi?id=1121419#c6


poma


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

Re: [systemd-devel] [PATCH] Refuse mount on symlink

[Timofey Titovets]

2014-07-21 17:11 GMT+03:00 Lennart Poettering :
> That would follow our usual coding style very closely...

I know >_<, i do bad looking error codes >_<
Lennart, thanks for explanation, i will fix it and resend patch.

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

Re: [systemd-devel] sysusers and login.defs checks

[Colin Guthrie]

'Twas brillig, and Lennart Poettering at 21/07/14 14:43 did gyre and gimble:
> I am totally not convinced that this would be a good idea, sorry.

No worries, that's why I asked first ;)

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

Re: [systemd-devel] [PATCH] Refuse mount on symlink

[Lennart Poettering]

On Sat, 19.07.14 16:15, Timofey Titovets (nefelim...@gmail.com) wrote:

Heya,

> +int fail_if_symlink(const char *unit, const char* where) {
> +assert(where);
> +
> +if (!is_symlink(where))
> +return 0;
> +
> +log_warning_unit(unit,
> + "%s Refuse mount on symlink: %s",
> + unit, strerror(1));

strerror(1)? Where does the "1" come from?

> +
> +return -1;

We strictly follow the logic to return "errno"-style negative error
numbers, we never make up numeric ones, like "-1".

In this case "return -ELOOP" sounds appropriate, I'd say..."

> +
> +bool is_symlink(const char *path) {
> +struct stat info;
> +
> +lstat(path, &info);

You need to handle the case whether the path doesn't exist at all, or
the lstat() fails for other reasons. I think it would be a good idea to
change is_symlink() to return an "int", and then simply return the
negative errno on failure, and 0 or 1 otherwise:

if (lstat(path, &info) < 0)
return -errno;

That would follow our usual coding style very closely...

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] [systemd-commits] 10 commits - .gitignore Makefile.am Makefile-man.am man/systemd-journal-remote.xml man/systemd.unit.xml man/systemd-verify.xml src/core src/shared src/systemctl s

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jul 21, 2014 at 03:18:54PM +0200, Lennart Poettering wrote:
> On Sun, 20.07.14 17:44, Zbigniew Jędrzejewski-Szmek 
> (zbys...@kemper.freedesktop.org) wrote:
> 
> Zibigniew,
> 
> > New commits:
> > commit 0e8415f2e5c42e87ca3b7a96138675f64696cb7a
> > Author: Zbigniew J??drzejewski-Szmek 
> > Date:   Sun Jul 20 19:28:58 2014 -0400
> > 
> > man: add systemd-verify(1)
> 
> sounds like really useful functionality, but I am pretty sure this
> shouldn't be a tool of its own, but rather simply a verb either of
> "systemctl" or "systemd-analyze" (slightly leaning to the latter)...

Yeah, when I was writing it, I was wondering whether another binary in /usr/bin/
is worth it. Moving the code to systemd-analyze should be trivial.

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

[systemd-devel] [PATCH] Refuse mount on symlink

[Timofey Titovets]

Just completed TODO:
* refuse mounting on symlinks

I not add this TODO, but i think what it avoid potential 
security{and/or} bug issues


If systemd try mounting entry from fstab on symlink, user get something 
like that:

Jul 19 15:49:38 beplan.lan systemd[1]: Mounting /var/tmp/symlink...
Jul 19 15:49:38 beplan.lan systemd[1]: var-tmp-symlink.mount Refuse 
mount on symlink: Operation not permitted


Can be pulled from:
https://github.com/Nefelim4ag/systemd.git


 TODO  |  2 --
 src/core/mount.c  | 17 +
 src/core/mount.h  |  2 ++
 src/shared/util.c | 11 +++
 src/shared/util.h |  2 ++
 5 files changed, 32 insertions(+), 2 deletions(-)

diff --git a/TODO b/TODO
index bfa06de..be58ff3 100644
--- a/TODO
+++ b/TODO
@@ -55,8 +55,6 @@ Features:

 * order OnCalendar timer units after timer-sync.target if 
DefaultDependencies=no so that we don't trigger them prematurely


-* refuse mounting on symlinks
-
 * logind: allow users to kill or lock their own sessions

 * add new gpt type for btrfs volumes
diff --git a/src/core/mount.c b/src/core/mount.c
index 102bbef..e5e8e94 100644
--- a/src/core/mount.c
+++ b/src/core/mount.c
@@ -826,6 +826,19 @@ void warn_if_dir_nonempty(const char *unit, const 
char* where) {

NULL);
 }

+int fail_if_symlink(const char *unit, const char* where) {
+assert(where);
+
+if (!is_symlink(where))
+return 0;
+
+log_warning_unit(unit,
+ "%s Refuse mount on symlink: %s",
+ unit, strerror(1));
+
+return -1;
+}
+
 static void mount_enter_unmounting(Mount *m) {
 int r;

@@ -876,6 +889,10 @@ static void mount_enter_mounting(Mount *m) {
 if (p && mount_is_bind(p))
 mkdir_p_label(p->what, m->directory_mode);

+r = fail_if_symlink(m->meta.id, m->where);
+if (r < 0)
+goto fail;
+
 if (m->from_fragment)
 r = exec_command_set(
 m->control_command,
diff --git a/src/core/mount.h b/src/core/mount.h
index 2dcb663..5fc1fe1 100644
--- a/src/core/mount.h
+++ b/src/core/mount.h
@@ -128,3 +128,5 @@ const char* mount_result_to_string(MountResult i) 
_const_;

 MountResult mount_result_from_string(const char *s) _pure_;

 void warn_if_dir_nonempty(const char *unit, const char* where);
+
+int fail_if_symlink(const char *unit, const char* where);
\ No newline at end of file
diff --git a/src/shared/util.c b/src/shared/util.c
index 4fda31c..f389e74 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -6866,3 +6866,14 @@ int take_password_lock(const char *root) {

 return fd;
 }
+
+bool is_symlink(const char *path) {
+struct stat info;
+
+lstat(path, &info);
+
+if (S_ISLNK(info.st_mode))
+return 1;
+
+return 0;
+}
\ No newline at end of file
diff --git a/src/shared/util.h b/src/shared/util.h
index d9d525e..6a438b7 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -973,3 +973,5 @@ char *tempfn_random(const char *p);
 bool is_localhost(const char *hostname);

 int take_password_lock(const char *root);
+
+bool is_symlink(const char *path);
\ No newline at end of file
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v2] readahead: use BTRFS_IOC_DEFRAG_RANGE

[Timofey Titovets]

Zbyszek, thanks for comment, i will work on fixing what you say and
resend patch.

>> Just completed TODO:
>> * readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG
>
> This is still not an explanation. What is the difference between the
> two?

I can't explain it, because no i add this todo in TODO list (recursively todo%)
>> -  - readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG 
>> ioctl, with START_IO
But as i understand start_io option force write data, without
buffering in memory, to the disk.
may be it have a sacral sense, i ask for comments in btrfs list for
explaration and add explanation to the v3

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

Re: [systemd-devel] sysusers and login.defs checks

[Lennart Poettering]

On Mon, 21.07.14 13:11, Colin Guthrie (gm...@colin.guthr.ie) wrote:

> That said, it's also not inconceivable that the login.defs is updated
> but user accounts still exist that are in the 500-1000 range. So perhaps
> we should consider adding the same kind of heuristics for handling the
> 500->1000 jump that accountsservice has[1]? i.e. we add a
> is_system_user() utility function or similar where this heuristic can be
> an optional thing (like in accountsservice). What are the thoughts here?
> IMO, I'd say that we should just honour login.defs and forget about
> heuristics - anything upgraded should keep it's old login.defs values
> and not update them. Only if you do a fresh install or manually renumber
> your users should you change login.defs otherwise strange things will
> happen to you (e.g. on login screen user lists, in user editing GUIs, in
> coredump handling and other places). WDYT?

I am much more open about code that magically detects where the boundary
is, when allocating a new system users... But I don't see how this could
work in real life. The accountssserice code doesn't appear too
convincing to me... There are system users with login sheels, and there
are normal accounts that have been disabled, I really don#t find a logic
bound to either of that particularly striking I must say...

What could work better is to check the home directory. If it is "/" or
something in /var we can be reasonably sure that something is a system
user, but if it isn't we have no clue...

> Also, while SYS_[UG]ID_MAX is currently parsed from login.defs during
> configure, and I proposed to fall back to [UG]ID_MIN-1, I notice a few
> things...
> 
> [I'll drop my "[UG]ID" syntax from now on... assume it's there!]
> 
> 1. When the bump from 500 to 1000 was done in Fedora[2], SYS_UID_MAX was
> added. But SYS_UID_MIN was also added. We do not currently parse this,
> but perhaps we should and sysusers should refuse to work if we cannot
> find a suitable UID to allocate?
> 
> 2. Or perhaps we should consider whether the SYS_UID_MIN/MAX is useful
> at all? Perhaps if not much uses it, it should just be killed off and we
> should always just use UID_MIN-1?
> 
> Personally, I'd just go with 2 - the fact there are two settings to
> represent a boundary point makes no sense to me - although there may be
> valid reasons to leave a gap there?

As i understand the current stuff in Fedora's login.defs, the idea is
that 1-200 is left for statically assigned system users, 201-999 for
dynamically assigned system users, and 1000-6 for normal users.

Based on this, static system users are allocated growing from 1 upwards,
dynamic system users are allocated growing from 999 downwards, and
normal users from 1000 upwards.

In sysusers we don't care much abotu the actual ranges, we just allocate
from some specified start value downards, and that start value is a
compile time option, that defaults to 999 or is SYS_UID_MAX from
login.defs, should that be available...

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] How to reduce systemd logging to syslog ?

[Reindl Harald]

Am 21.07.2014 15:18, schrieb Mantas Mikulėnas:
> On Mon, Jul 21, 2014 at 1:41 AM,   wrote:
>> 2014-07-20T00:15:01.978142-07:00 core systemd[1]: Starting 
>> Session 2 of user root.
>> 2014-07-20T00:15:01.979526-07:00 core systemd[1]: Started 
>> Session 2 of user root.
>> 2014-07-20T00:30:01.065850-07:00 core systemd[1]: Starting 
>> Session 3 of user root.
>> 2014-07-20T00:30:01.067825-07:00 core systemd[1]: Started 
>> Session 3 of user root.
>> 2014-07-20T00:45:01.155187-07:00 core systemd[1]: Starting 
>> Session 4 of user root.
>> 2014-07-20T00:45:01.182571-07:00 core systemd[1]: Started 
>> Session 4 of user root.
> 
> Looks like something – perhaps a cron daemon – opens a logind session
> every 15 minutes. But if I remember correctly, background jobs are not
> meant to do that at all? It might be that the log spam is caused by
> misconfigured /etc/pam.d/cron or something such...

no it is caused by systemd and intentionally..
in F21 you get much more lines for cronjobs
https://bugzilla.redhat.com/show_bug.cgi?id=1072368#c3

Jan 15 04:07:01 testserver systemd[29118]: Starting Default.
Jan 15 04:07:01 testserver systemd[29118]: Reached target Default.
Jan 15 04:07:01 testserver systemd[29118]: Startup finished in 3ms.
Jan 15 04:07:01 testserver systemd[1]: Started User Manager for 0.
Jan 15 04:07:01 testserver systemd[1]: Stopping User Manager for 0...
Jan 15 04:07:01 testserver systemd[29118]: Stopping Default.
Jan 15 04:07:01 testserver systemd[29118]: Stopped target Default.
Jan 15 04:07:01 testserver systemd[29118]: Starting Shutdown.
Jan 15 04:07:01 testserver systemd[29118]: Reached target Shutdown.
Jan 15 04:07:01 testserver systemd[29118]: Starting Exit the Session...
Jan 15 04:07:01 testserver systemd[29118]: Received SIGRTMIN+24 from PID 29138 
(kill).
Jan 15 04:07:01 testserver systemd[1]: Stopped User Manager for 0.
Jan 15 04:07:01 testserver systemd[1]: Stopping user-0.slice.
Jan 15 04:07:01 testserver systemd[1]: Removed slice user-0.slice.
Jan 15 04:08:01 testserver systemd[1]: Starting user-0.slice.
Jan 15 04:08:01 testserver systemd[1]: Created slice user-0.slice.
Jan 15 04:08:01 testserver systemd[1]: Starting User Manager for 0...
Jan 15 04:08:01 testserver systemd[29149]: Failed to open private bus 
connection: Failed to connect to socket
/run/user/0/dbus/user_bus_socket: No such file or directory
Jan 15 04:08:01 testserver systemd[29149]: Starting Default.
Jan 15 04:08:01 testserver systemd[29149]: Reached target Default.
Jan 15 04:08:01 testserver systemd[29149]: Startup finished in 3ms.
Jan 15 04:08:01 testserver systemd[1]: Started User Manager for 0.
Jan 15 04:08:01 testserver systemd[1]: Stopping User Manager for 0...
Jan 15 04:08:01 testserver systemd[29149]: Stopping Default.
Jan 15 04:08:01 testserver systemd[29149]: Stopped target Default.
Jan 15 04:08:01 testserver systemd[29149]: Starting Shutdown.
Jan 15 04:08:01 testserver systemd[29149]: Reached target Shutdown.
Jan 15 04:08:01 testserver systemd[29149]: Starting Exit the Session...
Jan 15 04:08:01 testserver systemd[29149]: Received SIGRTMIN+24 from PID 29169 
(kill).
Jan 15 04:08:01 testserver systemd[1]: Stopped User Manager for 0.
Jan 15 04:08:01 testserver systemd[1]: Stopping user-0.slice.
Jan 15 04:08:01 testserver systemd[1]: Removed slice user-0.slice.
Jan 15 04:09:01 testserver systemd[1]: Starting user-0.slice.
Jan 15 04:09:01 testserver systemd[1]: Created slice user-0.slice.
Jan 15 04:09:01 testserver systemd[1]: Starting User Manager for 0...
Jan 15 04:09:01 testserver systemd[29181]: Failed to open private bus 
connection: Failed to connect to socket
/run/user/0/dbus/user_bus_socket: No such file or directory
Jan 15 04:09:01 testserver systemd[29181]: Starting Default.
Jan 15 04:09:01 testserver systemd[29181]: Reached target Default.
Jan 15 04:09:01 testserver systemd[29181]: Startup finished in 3ms.
Jan 15 04:09:01 testserver systemd[1]: Started User Manager for 0.
Jan 15 04:09:01 testserver systemd[1]: Stopping User Manager for 0...
Jan 15 04:09:01 testserver systemd[29181]: Stopping Default.
Jan 15 04:09:01 testserver systemd[29181]: Stopped target Default.
Jan 15 04:09:01 testserver systemd[29181]: Starting Shutdown.
Jan 15 04:09:01 testserver systemd[29181]: Reached target Shutdown.
Jan 15 04:09:01 testserver systemd[29181]: Starting Exit the Session...
Jan 15 04:09:01 testserver systemd[29181]: Received SIGRTMIN+24 from PID 29201 
(kill).
Jan 15 04:09:01 testserver systemd[1]: Stopped User Manager for 0.
Jan 15 04:09:01 testserver systemd[1]: Stopping user-0.slice.
Jan 15 04:09:01 testserver systemd[1]: Removed slice user-0.slice.
Jan 15 04:10:01 testserver systemd[1]: Starting user-0.slice.
Jan 15 04:10:01 testserver systemd[1]: Created slice user-0.slice.
Jan 15 04:10:01 testserver systemd[1]: Starting User Manager for 0...
Jan 15 04:10:01 testserver systemd[1]: Starting user-48.slice.
Jan

Re: [systemd-devel] sysusers and login.defs checks

[Lennart Poettering]

On Mon, 21.07.14 04:16, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> > I can't really think of any reason as to why this would genuinely help,
> > but then I can't think why a regular user.
> > 
> > Not a big deal in this case really tho' - I think the original argument
> > still stands.
> I agree. Not reading /etc/login.defs makes the tool troublesome for
> existing installations.
> 
> I've experienced a related problem, where coredumps would not be
> visible for my user on a Fedora machine which has been upgraded over
> many versions.  It turns out that the user had uid 500 or something
> like that, and systemd-coredump treated the account as as a system
> account.

Sure, the transition will create problems, but it necessarily will. 

What matters really is that we don't allow things that we shouldn't
allow, but if things are not allowed that should be allowed, then that's
much less problematic, but simply a negative cosnequence of the
transition...

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] sysusers: Preserve label of /etc/{passwd, group}

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jul 21, 2014 at 10:26:20AM +0200, Miroslav Grepl wrote:
> On 07/13/2014 10:35 PM, Colin Walters wrote:
> >On Sat, Jul 12, 2014, at 06:48 AM, Zbigniew Jędrzejewski-Szmek wrote:
> >>please excuse my possibly ignorant questions, selinux is not my forte.
> >>If the files are nonexistent, will this fail? But sysusers should be
> >>able to create /etc from scratch.
> >True, fixed.
> >
> >>Why cannot the same code as in write_string_file_atomic_label be used
> >>instead?
> >We're writing more than one line, and in addition we need to look up the
> >label for /etc/passwd even if we're operating on a chroot.
> >>BTW, you're returning -1 here, but should be -errno.
> >This code is gone now; new patch attached.
> >
> # ls -Z /etc/passwd* /etc/group*
> 
> with this patch?
-rw-r--r--. root root system_u:object_r:passwd_file_t:s0 /etc/group
-rw-r--r--. root root system_u:object_r:passwd_file_t:s0 /etc/passwd

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

Re: [systemd-devel] sysusers and login.defs checks

[Lennart Poettering]

On Sun, 20.07.14 22:38, Colin Guthrie (gm...@colin.guthr.ie) wrote:

> 
> 'Twas brillig, and Colin Guthrie at 20/07/14 22:31 did gyre and gimble:
> > Those defaults could be set from a compile time check of
> > login.defs too.
> 
> FWIW, at least here, /etc/login.defs is not readable by regular users so
> any build system that builds as non-root won't even get those defaults
> anyway, so that's probably another argument for runtime checks too...

That sounds snake-oilish and broken, really...

Either way, there's a configure option --with-system-uid-max= (as well
as --with-system-gid-max=) to make the right choice for your
distribution...

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] sysusers and login.defs checks

[Lennart Poettering]

On Sun, 20.07.14 22:31, Colin Guthrie (gm...@colin.guthr.ie) wrote:

> Hi,
> 
> We're still using 500 as our [UG]ID_MIN in /etc/login.defs, but I'm
> looking to change that to be more in line with what everyone else seems
> to do.
> 
> One thing I found while looking at the sysusers code was that the only
> values read from /etc/login.defs were SYSTEM_[UG]ID_MAX and they were
> only read a compile (or rather configure) time, not at runtime.

Yeah, that's an intended design decision.

> While I appreciate sysusers is intended primarily for bootstrapping
> /etc, I guess the general consensus is to move package pre/post scripts
> over to use sysusers instead anyway. Thus the tool should really check
> /etc/login.defs at runtime if it's present before falling back to its
> defaults. Those defaults could be set from a compile time check of
> login.defs too.

I am pretty strongly against this. Making this administrator
configurable apepars very wrong, this really should be a decision for
the distribution vendor, and that's it.  We shouldn't design a system
that comes to completely different results if you boot it up with and
without /etc populated...

Also, the specific configuration file contains more configuration
options that are obsolete, than configuration options that aren't. From
chfn settings, to pam_console support, to the ability to override the
timezone or erase characters. Yuck!

I am fully aware that many distributions are transitioning from from 500
system users to 1000 system users, but I also don't see how this
transition would be made any easier by keeping a user configuration file
around for this. I mean, ultimately you will still have the problem that
in the range 500-999 you might end uo with both users interleaved with
each other... The best thing to do is in this case is live with it, and
make sure we never bind strictly security-relevant decisions to the
boundary, but only use it as a hint...

> So, I propose the following:
> 
> 1. Modify configure to check /etc/login.defs for SYSTEM_[UG]ID_MAX but
> fall back to [UG]ID_MIN-1 if not found.
> 2. Modify sysusers.c to do the same check at runtime
> 
> If I cook up a patch will that be accepted?

I am totally not convinced that this would be a good idea, sorry.

Lennart

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

Re: [systemd-devel] How to reduce systemd logging to syslog ?

[Lennart Poettering]

On Mon, 21.07.14 16:18, Mantas Mikulėnas (graw...@gmail.com) wrote:

> On Mon, Jul 21, 2014 at 1:41 AM,   wrote:
> > 2014-07-20T00:15:01.978142-07:00 core systemd[1]: Starting 
> > Session 2 of user root.
> > 2014-07-20T00:15:01.979526-07:00 core systemd[1]: Started 
> > Session 2 of user root.
> > 2014-07-20T00:30:01.065850-07:00 core systemd[1]: Starting 
> > Session 3 of user root.
> > 2014-07-20T00:30:01.067825-07:00 core systemd[1]: Started 
> > Session 3 of user root.
> > 2014-07-20T00:45:01.155187-07:00 core systemd[1]: Starting 
> > Session 4 of user root.
> > 2014-07-20T00:45:01.182571-07:00 core systemd[1]: Started 
> > Session 4 of user root.
> 
> Looks like something – perhaps a cron daemon – opens a logind session
> every 15 minutes. But if I remember correctly, background jobs are not
> meant to do that at all? It might be that the log spam is caused by
> misconfigured /etc/pam.d/cron or something such...

Well, cron jobs should open proper PAM sessions when this is about
running normal users' jobs. But I am really shure it shouldn't bother if
this about system user's jobs. PAM sessions are primarily something to
set the environment for unpriviliged user code, but system users are
different there...

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] How to reduce systemd logging to syslog ?

[Mantas Mikulėnas]

On Mon, Jul 21, 2014 at 1:41 AM,   wrote:
> 2014-07-20T00:15:01.978142-07:00 core systemd[1]: Starting 
> Session 2 of user root.
> 2014-07-20T00:15:01.979526-07:00 core systemd[1]: Started 
> Session 2 of user root.
> 2014-07-20T00:30:01.065850-07:00 core systemd[1]: Starting 
> Session 3 of user root.
> 2014-07-20T00:30:01.067825-07:00 core systemd[1]: Started 
> Session 3 of user root.
> 2014-07-20T00:45:01.155187-07:00 core systemd[1]: Starting 
> Session 4 of user root.
> 2014-07-20T00:45:01.182571-07:00 core systemd[1]: Started 
> Session 4 of user root.

Looks like something – perhaps a cron daemon – opens a logind session
every 15 minutes. But if I remember correctly, background jobs are not
meant to do that at all? It might be that the log spam is caused by
misconfigured /etc/pam.d/cron or something such...

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

Re: [systemd-devel] [systemd-commits] 10 commits - .gitignore Makefile.am Makefile-man.am man/systemd-journal-remote.xml man/systemd.unit.xml man/systemd-verify.xml src/core src/shared src/systemctl s

[Lennart Poettering]

On Sun, 20.07.14 17:44, Zbigniew Jędrzejewski-Szmek 
(zbys...@kemper.freedesktop.org) wrote:

Zibigniew,

> New commits:
> commit 0e8415f2e5c42e87ca3b7a96138675f64696cb7a
> Author: Zbigniew J??drzejewski-Szmek 
> Date:   Sun Jul 20 19:28:58 2014 -0400
> 
> man: add systemd-verify(1)

sounds like really useful functionality, but I am pretty sure this
shouldn't be a tool of its own, but rather simply a verb either of
"systemctl" or "systemd-analyze" (slightly leaning to the latter)...

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] How to reduce systemd logging to syslog ?

[Lennart Poettering]

On Sun, 20.07.14 15:41, sur...@emailengine.net (sur...@emailengine.net) wrote:

> That's a LOT of not very useful "Started Session ## of user root"
> noise in system logs that gets in the way of managing my system.
> Those messages are EnergizerBunny-entries -- they just keep going, and
> going, and going.  They're clearly NOT telling me anything helpful --
> like that there's a problem, or a state change from "good->bad".

Well, the are telling you that a system unit got started and stopped
then. 

> How do I turn that level of systemd logging to my syslog OFF, or
> reduce it to something more reasonable?  If systemd wants to log to
> its journal that's one thing -- I understand that we're supposed to
> "just filter out what you need".  But syslog's a different story.

Well, rsyslog nowadays picks its data up from the journal on its own,
journald doesn't forward anything to it anymore. Hence use rsyslog's
filtering to configure what exactly you want it to pick up. 

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] Warnings from recent commits

[Samuli Suominen]

On 21/07/14 16:05, Thomas H.P. Andersen wrote:
> On Mon, Jul 21, 2014 at 4:18 AM, Zbigniew Jędrzejewski-Szmek
>  wrote:
>> On Thu, Jul 17, 2014 at 08:51:52PM +0200, Thomas H.P. Andersen wrote:
>>> From recent commits I have noticed the following new issues from
>>> static analysis with scan-build and with clang. I am not sure how they
>>> should be fixed (or even if) but I just though I would let you know.
>>>
>>> 1) src/shared/barrier.c in barrier_read starting at line 274
>>>
>>> if (pfd[1].revents) {
>>> len = read(b->them, &buf, sizeof(buf));
>>> ...
>>> } else if (pfd[0].revents & (POLLHUP | POLLERR | POLLNVAL)) {
>>> ...
>>> buf = BARRIER_ABORTION;
>>> }
>>>
>>> If neither if/else if are true then buf will be used unset.
>>>
>>> 2) src/resolve/resolved-dns-scope.c in dns_scope_tcp_socket
>>> if s->link is null then ifindex will not be set but will be used later in:
>>>
>>> } else if (srv->family == AF_INET6) {
>>> sa.in6.sin6_port = htobe16(53);
>>> sa.in6.sin6_addr = srv->address.in6;
>>> sa.in6.sin6_scope_id = ifindex;
>>> salen = sizeof(sa.in6);
>>>
>>> 3) I see a couple of these:
>>>
>>> In file included from src/resolve/resolved-gperf.c:8:
>>> In file included from ./src/resolve/resolved.h:34:
>>> In file included from ./src/resolve/resolved-dns-query.h:33:
>>> In file included from ./src/resolve/resolved-dns-scope.h:33:
>>> ./src/resolve/resolved-dns-cache.h:45:3: warning: redefinition of
>>> typedef 'DnsCacheItem' is a C11 feature [-Wtypedef-redefinition]
>>> } DnsCacheItem;
>>>   ^
>>> ./src/resolve/resolved-dns-cache.h:31:29: note: previous definition is here
>>> typedef struct DnsCacheItem DnsCacheItem;
>> I'd simply add -Wno-typedef-redefinition to CLAGS... This is one
>> of those cases where the medicine is worse than the disease.
> Fine by me. Typedef redefinition was added in gcc 4.6 so we will need that.
>

4.6 is the minimum dependency as-is, for eg. _Static_assert,
DISABLE_WARNING_{DECLARATION_AFTER_STATEMENT,FORMAT_NONLITERAL,MISSING_PROTOTYPES,NONNULL},
REENABLE_WARNING
Just to get the udev part of the systemd tree compiled with gcc-4.5 or
older, you need something like,
http://510524.bugs.gentoo.org/attachment.cgi?id=380992

Just saying, that 4.6 minimum wouldn't be a new thing, it's been around
for several releases now

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

Re: [systemd-devel] crypttab automount

[Mantas Mikulėnas]

On Mon, Jul 21, 2014 at 3:18 PM, Ralf Jung  wrote:
> I also tried to figure out how to manually create an appropriate
> "systemd-cryptsetup@" instance so that I wasn't restricted by the
> crypttab generator (and could control the dependencies myself), but I
> couldn't figure out how to tell such an instance the necessary
> parameters (like the keyfile). I couldn't even find the
> "systemd-cryptsetup@.service" template file. It seems to me that I
> either misunderstood that template stuff, or there's special magic going
> on for this template.

When "foo@bar.service" is accessed, systemd first searches for the
exact name "foo@bar.service", and only then for "foo@.service", to
allow certain instances to be customized.

Since systemd-cryptsetup@.service is only used through the cryptsetup
generator, and since there are quite a few parameters (all of which
really couldn't fit within a single "instance" value), the generator
uses this feature and creates a separate unit with the right
parameters for each instance, so systemd never needs to fall back to
looking for the template unit.

Look in /run/systemd/generator for the output of all generators. Use
the generated systemd-cryptsetup@*.service units as base for your
custom ones. (The administrator overrides in /etc always take priority
over generated and package-distributed units in /run and /lib.)

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

Re: [systemd-devel] Warnings from recent commits

[Thomas H.P. Andersen]

On Mon, Jul 21, 2014 at 4:18 AM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Thu, Jul 17, 2014 at 08:51:52PM +0200, Thomas H.P. Andersen wrote:
>> From recent commits I have noticed the following new issues from
>> static analysis with scan-build and with clang. I am not sure how they
>> should be fixed (or even if) but I just though I would let you know.
>>
>> 1) src/shared/barrier.c in barrier_read starting at line 274
>>
>> if (pfd[1].revents) {
>> len = read(b->them, &buf, sizeof(buf));
>> ...
>> } else if (pfd[0].revents & (POLLHUP | POLLERR | POLLNVAL)) {
>> ...
>> buf = BARRIER_ABORTION;
>> }
>>
>> If neither if/else if are true then buf will be used unset.
>>
>> 2) src/resolve/resolved-dns-scope.c in dns_scope_tcp_socket
>> if s->link is null then ifindex will not be set but will be used later in:
>>
>> } else if (srv->family == AF_INET6) {
>> sa.in6.sin6_port = htobe16(53);
>> sa.in6.sin6_addr = srv->address.in6;
>> sa.in6.sin6_scope_id = ifindex;
>> salen = sizeof(sa.in6);
>>
>> 3) I see a couple of these:
>>
>> In file included from src/resolve/resolved-gperf.c:8:
>> In file included from ./src/resolve/resolved.h:34:
>> In file included from ./src/resolve/resolved-dns-query.h:33:
>> In file included from ./src/resolve/resolved-dns-scope.h:33:
>> ./src/resolve/resolved-dns-cache.h:45:3: warning: redefinition of
>> typedef 'DnsCacheItem' is a C11 feature [-Wtypedef-redefinition]
>> } DnsCacheItem;
>>   ^
>> ./src/resolve/resolved-dns-cache.h:31:29: note: previous definition is here
>> typedef struct DnsCacheItem DnsCacheItem;
>
> I'd simply add -Wno-typedef-redefinition to CLAGS... This is one
> of those cases where the medicine is worse than the disease.

Fine by me. Typedef redefinition was added in gcc 4.6 so we will need that.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH v2] readahead: use BTRFS_IOC_DEFRAG_RANGE

[Zbigniew Jędrzejewski-Szmek]

On Mon, Jul 21, 2014 at 09:38:57AM +0300, Timofey Titovets wrote:
> Just completed TODO:
> * readahead: use BTRFS_IOC_DEFRAG_RANGE instead of BTRFS_IOC_DEFRAG

This is still not an explanation. What is the difference between the
two?

> 
> //i save BTRFS_IOC_DEFRAG as fallback, because
> BTRFS_IOC_DEFRAG_RANGE not working (as i know) on several old
> kernels
> 
> v1 -> v2
> Fixed spelling in TODO
> 
> 
>  TODO  |  1 -
>  src/readahead/readahead-collect.c | 22 +-
>  src/shared/missing.h  | 18 ++
>  3 files changed, 35 insertions(+), 6 deletions(-)
> 
> diff --git a/TODO b/TODO
> index bfa06de..636d25f 100644
> --- a/TODO
> +++ b/TODO
> @@ -570,7 +570,6 @@ Features:
>  * readahead:
>- drop /.readahead on bigger upgrades with yum
>- move readahead files into /var (look for them with .path units?)
> -  - readahead: use BTRFS_IOC_DEFRAG_RANGE instead of
> BTRFS_IOC_DEFRAG ioctl, with START_IO
>- readahead: when bumping /sys readahead variable save mtime and
> compare later to detect changes
>- readahead: make use of EXT4_IOC_MOVE_EXT, as used by
> http://e4rat.sourceforge.net/
> 
> diff --git a/src/readahead/readahead-collect.c
> b/src/readahead/readahead-collect.c
> index c1afd0d..7cec5c4 100644
> --- a/src/readahead/readahead-collect.c
> +++ b/src/readahead/readahead-collect.c
> @@ -78,12 +78,24 @@ static usec_t starttime;
>  #define SECTOR_TO_PTR(s) ULONG_TO_PTR((s)+1)
>  #define PTR_TO_SECTOR(p) (PTR_TO_ULONG(p)-1)
> 
> -static int btrfs_defrag(int fd) {
> -struct btrfs_ioctl_vol_args data = { .fd = fd };
> +static int btrfs_defrag_hybrid(int fd){
> +int ret;
> +struct btrfs_ioctl_defrag_range_args range;
> +struct btrfs_ioctl_vol_args fallback;
> +range.start = 0;
> +range.len = (uint64_t)-1;
> +range.flags = 2;
> +range.extent_thresh = 1;
Please use static initalization as in:

 struct btrfs_ioctl_defrag_range_args range = {
   .start = 0,
   .len = -1,
   ...
  };

and the same for the other arg.

> 
> -return ioctl(fd, BTRFS_IOC_DEFRAG, &data);
> -}
> +fallback.fd=fd;
> +
> +ret = ioctl(fd, BTRFS_IOC_DEFRAG_RANGE, &range);
> 
> +if (ret < 0)
> +  return ioctl(fd, BTRFS_IOC_DEFRAG, &fallback);
> +
> +return ret;
> +}
>  static int pack_file(FILE *pack, const char *fn, bool on_btrfs) {
>  struct stat st;
>  void *start = MAP_FAILED;
> @@ -118,7 +130,7 @@ static int pack_file(FILE *pack, const char *fn,
> bool on_btrfs) {
>  }
> 
>  if (on_btrfs)
> -btrfs_defrag(fd);
> +btrfs_defrag_hybrid(fd);
You can skip the name change, we just have one function like that
anyway.

> 
>  l = PAGE_ALIGN(st.st_size);
>  start = mmap(NULL, l, PROT_READ, MAP_SHARED, fd, 0);
> diff --git a/src/shared/missing.h b/src/shared/missing.h
> index 818d704..29cf80e 100644
> --- a/src/shared/missing.h
> +++ b/src/shared/missing.h
> @@ -186,6 +186,19 @@ static inline int fanotify_mark(int
> fanotify_fd, unsigned int flags, uint64_t ma
>  #define BTRFS_UUID_SIZE 16
>  #endif
> 
> +/* TODO: Fix: won't compile if
> + * btrfs_ioctl_defrag_range_args
> + * included in ifdef HAVE_LINUX_BTRFS_H
> + */
> +struct btrfs_ioctl_defrag_range_args {
> +uint64_t start; /* start byte = 0 */
> +uint64_t len;   /* whole file uint64_t-1 */
> +uint64_t flags; /* start_io 2 */
> +uint32_t extent_thresh; /* 0 */
> +uint32_t compress_type;
> +uint32_t unused[4];
> +};
Try adding -E to the normal gcc options (you can use make V=1 to see them). This
will give you the proprocessed output.

Zbyszek


> +
>  #ifndef HAVE_LINUX_BTRFS_H
>  struct btrfs_ioctl_vol_args {
>  int64_t fd;
> @@ -213,6 +226,11 @@ struct btrfs_ioctl_fs_info_args {
>  #define BTRFS_IOC_DEFRAG _IOW(BTRFS_IOCTL_MAGIC, 2, struct
> btrfs_ioctl_vol_args)
>  #endif
> 
> +#ifndef BTRFS_IOC_DEFRAG_RANGE
> +#define BTRFS_IOC_DEFRAG_RANGE _IOW(BTRFS_IOCTL_MAGIC, 16, \
> +   struct
> btrfs_ioctl_defrag_range_args)
> +#endif
> +
>  #ifndef BTRFS_IOC_DEV_INFO
>  #define BTRFS_IOC_DEV_INFO _IOWR(BTRFS_IOCTL_MAGIC, 30, \
>   struct btrfs_ioctl_dev_info_args)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] crypttab automount

[Ralf Jung]

Hi all,

first of all, please forgive me if this is not the right list for
questions of systemd users. In this case, I would appreciate if you
could forward me to the right channel for my question. I couldn't find a
"systemd-users" list.

In my laptop, I do have an encrypted partition on a second HDD that I
want to be be mounted automatically, but without delaying the boot.
Concretely, I have the following in my /etc/crypttab:

>  store   UUID=...  /some/keyfile luks

and the following in /etc/fstab:

> /dev/mapper/store /mnt/storeext4
> errors=remount-ro,noauto,comment=systemd.automount 0   2

Looking at the output of "systemd-analyze plot", I can see that
"systemd-cryptsetup@store.service" is still run automatically on startup
(that's good), and it delays boot (that's bad). Naturally, opening the
device takes about one second as the system computes (from my password)
the key to decrypt the actual device key.
According to "systemctl show", it is "Before" cryptsetup.target, which
is "Before" lvm2-activation.service, which is "Before" local-fs.target.
Thus, opening that cryptdevice delays boot for no good reason.
How can I set up my system such that the rest of boot does not wait for
/dev/mapper/store to be opened?

I looked for some kind of option to add to /etc/crypttab, similar to the
"automount" in /etc/fstab, but found nothing like that.
I also tried to figure out how to manually create an appropriate
"systemd-cryptsetup@" instance so that I wasn't restricted by the
crypttab generator (and could control the dependencies myself), but I
couldn't figure out how to tell such an instance the necessary
parameters (like the keyfile). I couldn't even find the
"systemd-cryptsetup@.service" template file. It seems to me that I
either misunderstood that template stuff, or there's special magic going
on for this template.

I am using systemd 208 on Debian Testing. LVM is used for the main disk,
but is totally unrelated to this second HDD.
Please let me know if you need any further information.

Kind regards
Ralf

PS: Please keep me in CC, I am not subscribed to the list.


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

Re: [systemd-devel] [PATCH] journald: check if socket is in connected state before forwarding to syslog

[Umut Tezduyar Lindskog]

On Mon, Jul 21, 2014 at 1:04 PM, Piotr Wilczek  wrote:
> On 07/11/2014 01:16 PM, Lennart Poettering wrote:
>>
>> On Fri, 11.07.14 13:02, Piotr Wilczek (p.wilc...@samsung.com) wrote:
>>
 B) Now, as a shortcut we use the same sock actually, via sendto() to
 also pass data to /run/systemd/journal/syslog, which is where a
 secondary syslog server should listen on, which will then also receieve
 the data. THis one is likely to fail, because journald starts very
 early, and syslog daemons start very late, hence for the initial time
 no message can be delivered at all. Moreover, in many setups there is
 no secondary syslog, so this will fail each and every single time, but
 that's intended really.

 Now, your patch apparently looks for errors wth step A), and you argue
 you want to get rid of CPU load of B), which I can't follow. Since A
 and B are actually kinda separate they just happen to use the same
 socket, because that was easier...

>>>
>>> The CPU load is higher becouse now messages are sent to a socket that is
>>> not
>>> in a connected state. I wanted to avoid that with the present
>>> configuration.
>>
>>
>> Hmm? Why does that create higher CPU load, and also what does "connected
>> state" mean event? It's a SOCK_DGRAM socket, and your code changed the
>> listening bit, event though you say the sending bit is the one that
>> costs?
>>
>> Still not grokking at wall what you want to do...
>>
>
> The CPU usage is to prepare, send and (maybe) handle sending error. All
> unnecessary because we (and apparently others) don't need it.
> I wanted to automatically disable it on error but in wrong way so scratch
> it.
>
> It would be the best to disable forwarding to syslog by default.
http://cgit.freedesktop.org/systemd/systemd/commit/?id=46b131574fdd7d77c15a0919ca9010cad7aa6ac7
Umut
>
> Piotr
>
>> Lennart
>>
>
> ___
> 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] sysusers and login.defs checks

[Colin Guthrie]

'Twas brillig, and Zbigniew Jędrzejewski-Szmek at 21/07/14 03:16 did
gyre and gimble:
> I agree. Not reading /etc/login.defs makes the tool troublesome for
> existing installations.
> 
> I've experienced a related problem, where coredumps would not be
> visible for my user on a Fedora machine which has been upgraded over
> many versions.  It turns out that the user had uid 500 or something
> like that, and systemd-coredump treated the account as as a system
> account.

Yeah, I see that the SYSTEM_UID_MAX define is used in a few places
(namely the journal and sysusers).

I guess this should be abstracted out and changed such that it reads
login.defs and uses that value at runtime.

That said, it's also not inconceivable that the login.defs is updated
but user accounts still exist that are in the 500-1000 range. So perhaps
we should consider adding the same kind of heuristics for handling the
500->1000 jump that accountsservice has[1]? i.e. we add a
is_system_user() utility function or similar where this heuristic can be
an optional thing (like in accountsservice). What are the thoughts here?
IMO, I'd say that we should just honour login.defs and forget about
heuristics - anything upgraded should keep it's old login.defs values
and not update them. Only if you do a fresh install or manually renumber
your users should you change login.defs otherwise strange things will
happen to you (e.g. on login screen user lists, in user editing GUIs, in
coredump handling and other places). WDYT?




Also, while SYS_[UG]ID_MAX is currently parsed from login.defs during
configure, and I proposed to fall back to [UG]ID_MIN-1, I notice a few
things...

[I'll drop my "[UG]ID" syntax from now on... assume it's there!]

1. When the bump from 500 to 1000 was done in Fedora[2], SYS_UID_MAX was
added. But SYS_UID_MIN was also added. We do not currently parse this,
but perhaps we should and sysusers should refuse to work if we cannot
find a suitable UID to allocate?

2. Or perhaps we should consider whether the SYS_UID_MIN/MAX is useful
at all? Perhaps if not much uses it, it should just be killed off and we
should always just use UID_MIN-1?

Personally, I'd just go with 2 - the fact there are two settings to
represent a boundary point makes no sense to me - although there may be
valid reasons to leave a gap there?

Col


[1] http://cgit.freedesktop.org/accountsservice/tree/src/user-classify.c#n84

[2]
http://pkgs.fedoraproject.org/cgit/shadow-utils.git/commit/shadow-utils.login.defs?id=5d7612da5b7be0c7ce8bad72c4d69a8f347696db


-- 

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

Re: [systemd-devel] [PATCH] journald: check if socket is in connected state before forwarding to syslog

[Piotr Wilczek]

On 07/11/2014 01:16 PM, Lennart Poettering wrote:

On Fri, 11.07.14 13:02, Piotr Wilczek (p.wilc...@samsung.com) wrote:


B) Now, as a shortcut we use the same sock actually, via sendto() to
also pass data to /run/systemd/journal/syslog, which is where a
secondary syslog server should listen on, which will then also receieve
the data. THis one is likely to fail, because journald starts very
early, and syslog daemons start very late, hence for the initial time
no message can be delivered at all. Moreover, in many setups there is
no secondary syslog, so this will fail each and every single time, but
that's intended really.

Now, your patch apparently looks for errors wth step A), and you argue
you want to get rid of CPU load of B), which I can't follow. Since A
and B are actually kinda separate they just happen to use the same
socket, because that was easier...



The CPU load is higher becouse now messages are sent to a socket that is not
in a connected state. I wanted to avoid that with the present
configuration.


Hmm? Why does that create higher CPU load, and also what does "connected
state" mean event? It's a SOCK_DGRAM socket, and your code changed the
listening bit, event though you say the sending bit is the one that
costs?

Still not grokking at wall what you want to do...



The CPU usage is to prepare, send and (maybe) handle sending error. All 
unnecessary because we (and apparently others) don't need it.
I wanted to automatically disable it on error but in wrong way so 
scratch it.


It would be the best to disable forwarding to syslog by default.

Piotr


Lennart




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

Re: [systemd-devel] logind has no holdoff time

[poma]

On 20.07.2014 23:20, poma wrote:


What's so special about i686!?

systemd[1]: Failed to start Login Service.
systemd[1]: Unit systemd-logind.service entered failed state.
systemd[1]: systemd-logind.service has no holdoff time, scheduling restart.
https://bugzilla.redhat.com/show_bug.cgi?id=1121419



https://bugzilla.redhat.com/show_bug.cgi?id=1120473#c1


poma


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

Re: [systemd-devel] How to reduce systemd logging to syslog ?

[Reindl Harald]

Am 21.07.2014 03:10, schrieb sur...@emailengine.net:
> On Sun, Jul 20, 2014, at 05:31 PM, Zbigniew Jędrzejewski-Szmek wrote:
>> 2. tell systemd to log less with 'systemd-analyze set-log-level notice'.
> 
> Won't that lower the log level 'into' the journal as well?  

hopefully

> I'm happy to have that populated with a high level of detail -- I just 
> don't want 'noisy' info in my *syslog*

then edit rsyslog.conf and filter them
rsyslog becomes all data which are logged
but it can filter and journald can't

# systemd-logind not in /var/log/messages
:programname, isequal, "systemd-logind" -/var/log/secure
:programname, isequal, "systemd-logind" ~
:msg, contains, "Starting Session" ~
:msg, contains, "Started Session" ~
:msg, contains, "Stopping Session" ~
:msg, contains, "Stopped Session" ~



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] Thoughts about /etc/crypttab keyscript options

[Marc Haber]

Hi,

I was recently bitten by the issue that systemd does not support the
keyscript= option in /etc/crypttab. I don't know whether keyscript= is
a Debian extension, but the migration to systemd (which was pulled in
by some new version of - I think - Network Manager) broke my system's
boot process, leaving me with all my filesystems locked since already
the root fs used to be unlocked by a keyscript.

I have read the thread (from 2012?) where those things were discussed
here and I understand that I should replace my keyscript with a
passwort agent. Things would then work like this:

(1)
systemd would try to unlock the root file system and place a ask.xxx
file in /run/systemd/ask-password

(2)
All running PasswordAgents (including my, non-interactive one and
all interactive ones) would act on that ask.xxx file.

(3)
The interactive password agents would present an interactive password
request.

(4)
My PasswordAgent indicates taking responsibility by unlinking the
ask.xxx file from /run/systemd/ask-password. The interactive password
agents will remove their interactive requests then. The user will
therefore see the password request popping up for a very short period
of time, if at all.

(5)
Should my PasswordAgent need a password to act itself (like a PIN for
a hardware device, for example), it would place its own ask.xxx file
in /run/systemd/ask-password. The interactive PasswordAgents would
act on that, obtain the password/PIN interactively from the user and
return it to my PasswordAgent.

(6)
My PasswordAgent would then obtain the password for the file system
itself and return it to systemd which can now proceed to unlock the
file system.


Am I understanding things correctly so far?


If so, this leaves the task to write "my" PasswordAgent. I have found
some example code in python for a password agent.

To use this to unlock the root fs, an entire python installation would
need to go in my initramfs, right? And if I want to keep things
simple, the best idea would be to write my PasswordAgent in a compiled
language which would only need the binary and its libs in the
initramfs, right?

Is there code for an example PasswordAgent in C++ which I can use as a
template? I am quite reluctant to write a program which needs to to
complex string processing and is bound to run as root in C because my
C experience is somewhat lacking.

Can you please recommend a way to allow me to migrate to systemd?
Without keyscript= being supported in /etc/crypttab, I need to replace
my 50 line key script written in POSIX shell and would like to keep
things simple.

Thank you very much for your consideration.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature |  How to make an American Quilt | Fax: *49 621 31958062
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] sysusers: Preserve label of /etc/{passwd, group}

[Miroslav Grepl]

On 07/13/2014 10:35 PM, Colin Walters wrote:

On Sat, Jul 12, 2014, at 06:48 AM, Zbigniew Jędrzejewski-Szmek wrote:

please excuse my possibly ignorant questions, selinux is not my forte.
If the files are nonexistent, will this fail? But sysusers should be
able to create /etc from scratch.

True, fixed.


Why cannot the same code as in write_string_file_atomic_label be used
instead?

We're writing more than one line, and in addition we need to look up the
label for /etc/passwd even if we're operating on a chroot.
  

BTW, you're returning -1 here, but should be -errno.

This code is gone now; new patch attached.



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

Colin,
how does look

# ls -Z /etc/passwd* /etc/group*

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