Re: [systemd-devel] [RFC] activate on DBus signal

[WaLyong Cho]

On 2015년 04월 09일 02:05, Lennart Poettering wrote:
> On Mon, 23.03.15 17:54, WaLyong Cho (walyong@samsung.com) wrote:
> 
>> Hi,
>>
>> Now, I'm looking for a method to a service be activated on special DBus
>> signal. If a process is running for waiting some of DBus signal this can
>> be useful.
>>
>> I already told with Simon in DBus mailing list.
>>
>> see this thread:
>> http://lists.freedesktop.org/archives/dbus/2015-March/016607.html
>>
>> Simon said:
>> "If it did, there are some nasty ordering constraints - I certainly
>> wouldn't want to have to delay delivery of a broadcast until all
>> interested services had started up! - so I don't think adding this
>> feature would be a good idea."
>>
>> How about also support for DBus signal?
> 
> Hmm, so this has come up before, but this is really nasty to support,
> and I am not convinced we really want this.
> 
> First of all, in a kdbus world this would require kernel support, so
> that the kernel will listen and queue messages on behalf of userspace,
> and that would be quite a major change...
> 
> In general, so far activation was limited to *explicit* messages sent to
> the service in question, services would never be activated as possibly
> unintended side-effect of unrelated broadcast messages, and that's a
> really good property...
> 
>> Then, make systemd to monitor DBus. And if a matched signal was sent,
>> activate the service.
> 
> Well, it's not that simple, we'd also have to queue the signal, and
> all following messages, and pass that on to the activated
> service... And that's pretty nasty. It's already pretty nasty for the
> current logic but it would be even more complex with a match logic...

Is sd_bus_add_match() useful on here? I thought about...
Add option for subscribe signal as SubscribeSignal= and can take option
such like SubscribeSignal=path=/org/freedesktop/systemd1
interface=org.freedesktop.systemd1.Manager member=Subscribe. Then when
the unit(busname seems to be suit but the busname is only supported for
kdbus. So I'm not sure. anyway) is loaded, call the sd_bus_add_match()
with the parsed strv and register its callback.

To transport this missed signal(for who want to listen), another option
will be required to specify method call what will be sent with missed
signal. Because we really not wants duplicated signal is broadcasted.
Assume the option is SubscribeCallback= and can take like
SubscribeCallback=path=/foo/bar/waldo interface=foo.bar.waldo.quux
member=missedsignal.

On the callback(what is called by sd_bus_match()), will send a method
call to the specified address with a argument for missed signal contents.

I know, this is very strange and seems not cool. And maybe the
activation will really slow. But seems not impossible.

But, ahead, even if you agree this is possible, those option should be
controlled by other unit(not service). busname seems to be suit but I'm
not sure the busname unit can joint with currently used DBus1.


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

Re: [systemd-devel] regarding to cgroup siblings mask

[WaLyong Cho]

On 2015년 04월 09일 01:48, Lennart Poettering wrote:
> On Tue, 24.03.15 20:29, WaLyong Cho (walyong@samsung.com) wrote:
> 
>> Hi,
>>
>> In recent systemd(from some month ago), when a unit has a mask for cpu
>> or blockio or memory, this mask is also propagated to siblings by
>> unit_get_target_mask().
>> According to some of comments, it seems intentional.
>>
>> Could anyone explain why?
> 
> I added this after talking to Tejun. It's basically what the kernel
> will effectively do in "sane behaviour" mode too.
> 
> Basically, the kernel really wants to avoid having to compare
> individual processes against groups, because behaviour is unclear
> then. They want to comapre groups against groups and processes against
> processes, but not groups against processes, since in many cases
> behaviour is very unclear then. To avoid the ambighities this creates
> entirely the answer is to not allow this, and hence always propagate
> all controller memberships not only towards the root, but also sideways.

OK, understood but I'm not sure the compare group properties came under
for all of cgroup subsystem. In case of CPUShares=, BlockIOWeight= such
like take weight as value, should be. But in case of CPUQuota=,
MemoryLimit=, it just a problems of own. Those are not racing with other
groups. So for this kind of properties do not need to be propagated to
siblings.

I'm not sure this make sense. But if yes, below patch will only
propagate proportional or relative properties.
http://lists.freedesktop.org/archives/systemd-devel/2015-March/029885.html


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

Re: [systemd-devel] Check if systems is container in "systemd-remount-fs.service"

[Cristian Rodríguez]

On Wed, Apr 8, 2015 at 6:55 PM, Lennart Poettering
 wrote:
> On Tue, 17.03.15 10:54, Peter Paule (systemd-de...@fedux.org) wrote:
>
>> Hi,
>>
>> does it make sense to check if the system is started as a container in
>> "systemd-remount-fs.service" and only start the service if the system is NOT
>> a container?
>
> Why?
The service always fail when running in a container.. for example

systemd-nspawn -D / -xb

Apr 08 23:59:30 xps15z systemd-remount-fs[16]: /bin/mount for / exited
with exit status 1.
Apr 08 23:59:30 xps15z systemd-remount-fs[16]: mount: can't find
UUID=01a467ea-82ff-4d5a-a8a1-f2fb4e797ea0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] 42-usb-hid-pm.rules: Fix tests for removable state

[Matthew Garrett]

From: Matthew Garrett 

We only care about whether our direct parent is removable, not whether any
further points up the tree are - the kernel will take care of policy for
those itself. This enables autosuspend on devices where the root hub reports
that its removable state is unknown.
---
 rules/42-usb-hid-pm.rules | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/rules/42-usb-hid-pm.rules b/rules/42-usb-hid-pm.rules
index 4c300da..3721219 100644
--- a/rules/42-usb-hid-pm.rules
+++ b/rules/42-usb-hid-pm.rules
@@ -28,9 +28,9 @@ ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="14dd", 
ATTR{idProduct}=="0002"
 
 # USB HID devices that are internal to the machine should also be safe to 
autosuspend
 
-ACTION=="add", SUBSYSTEM=="usb", SUBSYSTEMS=="usb", 
ATTRS{removable}=="removable", GOTO="usb_hid_pm_end"
-ACTION=="add", SUBSYSTEM=="usb", SUBSYSTEMS=="usb", 
ATTRS{removable}=="unknown", GOTO="usb_hid_pm_end"
+ACTION=="add", SUBSYSTEM=="usb", SUBSYSTEMS=="usb", 
ATTR{../removable}=="removable", GOTO="usb_hid_pm_end"
+ACTION=="add", SUBSYSTEM=="usb", SUBSYSTEMS=="usb", 
ATTR{../removable}=="unknown", GOTO="usb_hid_pm_end"
 
-ACTION=="add", SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="03", 
ATTRS{removable}=="fixed", TEST=="../power/control", 
ATTR{../power/control}="auto"
+ACTION=="add", SUBSYSTEM=="usb", ATTR{bInterfaceClass}=="03", 
ATTR{../removable}=="fixed", TEST=="../power/control", 
ATTR{../power/control}="auto"
 
 LABEL="usb_hid_pm_end"
-- 
2.1.0

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

Re: [systemd-devel] [PATCH 1/6] udev: builtin-keyboard: move fetching the device node up

[Peter Hutterer]

On Wed, Apr 08, 2015 at 07:41:06PM +0200, Lennart Poettering wrote:
> On Mon, 23.03.15 11:30, Peter Hutterer (peter.hutte...@who-t.net) wrote:
> 
> > No point parsing the properties if we can't get the devnode to apply them
> > later. Plus, this makes future additions easier to slot in.
> 
> Hmm, Peter, this series was never pushed?
> 
> (Just making sure this is not forgotten...)

not forgotten, just idling for potential further comments from Kay after the
EV_ABS_OVERRIDE -> EVDEV_ABS rename. I'll push this tomorrow if no further
changes are required.

See message ID:


Cheers,
   Peter


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

Re: [systemd-devel] networkd: Is auto-negotiation turned off when specifying parameters in a link file?

[poma]

On 08.04.2015 23:05, Lennart Poettering wrote:
> On Wed, 08.04.15 22:13, Paul Menzel (paulepan...@users.sourceforge.net) wrote:
> 
>>> Wouldn't it suffice to unplug the ethernet cable, then use ethtool to
>>> turn this on, then replug it, and measuring the time until networkd
>>> notices the link beat is back?
>>
>> It would. But this is a rented Hetzner server and I have no access to
>> the data center. Do you have another idea. Please keep in mind that I
>> also only have remote access using that NIC. ;-)
> 
> Then, I figure a udev rule should do. Something like this (untested:)
> 
> ACTION=="add", SUBSYSTEM=="net", KERNEL!="lo", RUN+="/usr/bin/ethtool $name 
> ..."
> 
> Replace the "..." of course with the ethool options you need.
> 
> This would then be run immediately when the device appears. If this
> makes a measurable difference, then let us know.
> 
> Lennart
> 

/etc/udev/rules.d/10-speed1G-enp1s6.rules
ACTION=="add", SUBSYSTEM=="net", RUN+="/usr/sbin/ethtool -s enp1s6 advertise 
0x20"

:03 systemd[1]: Starting Network Service...
:05 systemd-networkd[1612]: enp1s6  : link configured
:05 systemd-networkd[1612]: enp1s6  : gained carrier
:06 systemd-networkd[1612]: enp1s6  : lost carrier
:09 systemd-networkd[1612]: enp1s6  : gained carrier

~~~

/etc/udev/rules.d/10-speed1G-enp1s6.rules-

:15 systemd[1]: Starting Network Service...
:17 systemd-networkd[1633]: enp1s6  : link configured
:17 systemd-networkd[1633]: enp1s6  : gained carrier


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

Re: [systemd-devel] Check if systems is container in "systemd-remount-fs.service"

[Lennart Poettering]

On Tue, 17.03.15 10:54, Peter Paule (systemd-de...@fedux.org) wrote:

> Hi,
> 
> does it make sense to check if the system is started as a container in
> "systemd-remount-fs.service" and only start the service if the system is NOT
> a container?

Why? I mean, we should apply /etc/fstab if it is configured. 

What's the rationale for your proposed change?

> 
> [Unit]
> Description=Remount Root and Kernel File Systems
> Documentation=man:systemd-remount-fs.service(8)
> Documentation=http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
> DefaultDependencies=no
> Conflicts=shutdown.target
> After=systemd-fsck-root.service
> Before=local-fs-pre.target local-fs.target shutdown.target
> Wants=local-fs-pre.target
> ConditionPathExists=/etc/fstab
> ConditionVirtualization=!container
> 
> [Service]
> Type=oneshot
> RemainAfterExit=yes
> ExecStart=/usr/lib/systemd/systemd-remount-fs
> 
> /pp
> 
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Lennart

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

Re: [systemd-devel] not running ExecStop= when stopping "activating" services?

[Lennart Poettering]

On Fri, 20.03.15 12:43, Nekrasov, Alexander (alexander.nekra...@emc.com) wrote:

> > This is intentional (see commit 3f6c78dc); I do not think intention was
> > as much "do not run ExecStopPost" as "do not spend time if starting
> > failed anyway"). There is currently no way to change it, it is
> > hardcoded. I guess you will need to present use case and explain what
> > is broken with current behavior.
> 
> [AN] here's the case. Often start-up of a service isn't just a one
> step, like starting a process. They need to bind LUNs, take locks,
> mount stuff, create structures, reformat DBs, create pid files,
> etc., before they want to report "ready" to the system. The main
> thing is, start-up is often a multi-step process, and the steps
> often make changes that are persistent. If that process is
> interrupted, there needs to be code run to make sure what's left is
> either cleaned up or made consistent. The kernel won't do the
> cleanup, so just killing off the processes in the c group isn't
> enough. The cleanup code also needs to be run after a failure, or a
> stop. Since systemd provides an ExecStop= option, that's an obvious
> place to hook cleanup code to, much like the catch section in a C++
> code. But for that to be useful, we must have a guarantee that the
> ExecStop will be called. There are obvious exception, such as the
> whole node crashing, where it won't be called, but that's
> understood.

Hmm, but there's ExecStopPost= for cases like this, isn't this enough?

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 4/4] Add a new tmpfiles.d snippets to set the NOCOW the journal.

[Lennart Poettering]

On Sun, 22.03.15 20:53, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> On Fri, Mar 20, 2015 at 07:06:28PM +0100, Goffredo Baroncelli wrote:
> > Hi Zbyszek,
> > 
> > On 2015-03-21 14:37, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Mon, Mar 16, 2015 at 08:33:52PM +0100, Goffredo Baroncelli wrote:
> > >> From: Goffredo Baroncelli 
> > >>
> > >> Add a new tmpfiles.d snippets to set the NOCOW attributes for the
> > >> journal files. This allow better perfomance when the root file system
> > >> is BTRFS. Pay attention that the NOCOW flags disables the checksum and
> > >> prevent scrub to rebuild a corrupted journal.
> > > I now merged patches 1-3/4, but not this one. Setting/unsetting
> > > attributes seems to be generally useful, so the rest stands on its
> > > own. The reason I held back with the last patch is that setting of the
> > > attributes through tmpfiles should be added together with the removal
> > > of the same functionality from journald. 
> > 
> > You are right, the patch #4 and the removal of the current code are coupled;
> > with the patch #1..#3 included, I will re-issue the #4 with another patch 
> > which reverts the code. And the discussion will restart.
> > 
> > 
> > 
> > > But there are some details to
> > > work out.
> > > 
> > > Setting +C on /var/log/journal/%m has smaller scope than the code in
> > > journal-file.c now. For example it does not cover files opened by
> > > systemd-journal-remote. 
> > 
> > I am not familiar with s*d-journal-remote; from the man page it seems that 
> > the log are stored /by default) in /var/log/journal/remote/ ; if so it is 
> > sufficient to add a line like
> > 
> > +h /var/log/journal/remote - - - - +C
> 
> That's the problem: current functionality works no matter where you
> store the files, but it's hard to provide the same level of
> flexibility with the tmpfiles-based solution.

Well, but we never store files outside of /var/log/journal,
/var/log/journal/%m and /var/log/journal/remote/, do we? 

I think this is close enough to be useful.

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] CapabilityBoundingSet vs. ExecReload (kill)

[Lennart Poettering]

On Wed, 18.03.15 19:56, Nusenu (nus...@openmailbox.org) wrote:

> Hi,
> 
> I'm currently preparing a systemd service file for tor [1].
> 
> We make use of CapabilityBoundingSet and first we had it set to:
> 
> CapabilityBoundingSet = CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE
> 
> but after noticing that reloads fail I added CAP_KILL for reload to
> work *via* the systemctl command.
> 
> CAP_KILL is not required if you reload the process manually (kill -HUP
> $PID) without using systemctl.
> 
> That tells me that the ExecReload command (kill) is also restricted by
> CapabilityBoundingSet. Is this expected and does that imply that every
> service requires CAP_KILL for proper reloads with systemctl?
> Is it possible to specify distinct CapabilityBoundingSets for the
> service (ExecStart) and the reload (ExecReload)?

Simply set PermissionsStartOnly=yes in your unit file. If so, the
permission-related settings (includeing CapabilityBoundingSet=) will
only be applied to ExecStart=, not the ExecReload= or the other lines.

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] fstab-generator: Support root on tmpfs

[Lennart Poettering]

On Sun, 22.03.15 00:57, Tobias Hunger (tobias.hun...@gmail.com) wrote:

BTW, if you are interested, I'd be willing to take this one step
further even, and default to tmpfs as root fs, if only mount.usr= is
specified on the kernel cmdline, and root= is missing.

Lennart

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

Re: [systemd-devel] [PATCH 2/2] Add +C attrib to the journal files directories

[Lennart Poettering]

On Sat, 21.03.15 12:56, Goffredo Baroncelli (kreij...@libero.it) wrote:

> From: Goffredo Baroncelli 
> 
> Add +C attrib to the journal files directories. The journal file format
> behaves bad on a BTRFS filesystem: the performances decrease during the
> time.
> To avoid this issue, this tmpfile.d snippet sets the NOCOW attribute to the
> journal files directories, so newly created journal files inherit the NCOOW
> attribute.

I think it would be good if much of this explanation would actually be
in the tmpfiles snippet. 

> 
> Be aware that the NOCOW attribute disables the BTRFS checksums, prevent BTRFS
> to rebuild a corrupted file in a RAIDx filesystem. However the perfomances
> increase.
> In a single disk filesystem (or a filesystem without redundancy) it is safe
> to use the NOCOW flags.
> ---
>  tmpfiles.d/journal-nocow.conf | 19 +++
>  1 file changed, 19 insertions(+)
>  create mode 100644 tmpfiles.d/journal-nocow.conf
> 
> diff --git a/tmpfiles.d/journal-nocow.conf b/tmpfiles.d/journal-nocow.conf
> new file mode 100644
> index 000..8d9c1e8
> --- /dev/null
> +++ b/tmpfiles.d/journal-nocow.conf
> @@ -0,0 +1,19 @@
> +#  This file is part of systemd.
> +#
> +#  systemd is free software; you can redistribute it and/or modify it
> +#  under the terms of the GNU Lesser General Public License as published by
> +#  the Free Software Foundation; either version 2.1 of the License, or
> +#  (at your option) any later version.
> +
> +# See tmpfiles.d(5) for details
> +
> +# set the journal file as NOCOW; make sense only for BTRFS
> filesystem

This will not set "the journal file" as NOCOW, but will set the flag
for the directory as a whole. Please explain this more accurately.

> +# WARNING: the NOCOW attribute disables the BTRFS checksums, prevent BTRFS
> +#  to rebuild a corrupted file in a RAIDx filesystem. It is suggested
> +#  to disables these setting in this kind of filesystem.
> +#  However in a single disk filesystem (or a filesystem without 
> +#  redundancy) it is safe to use the NOCOW flag.
> +#  Setting the NOCOW flag the perfomances increase.

This is not correct english.

> +
> +h /var/log/journal/%m - - - - +C
> +h /var/log/journal/remote - - - - +C

I think /var/log/journal itself should also get this treatment.

Lennart

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

Re: [systemd-devel] [PATCH 1/2] Revert patch 11689d2a which force the NOCOW attribute

[Lennart Poettering]

On Sat, 21.03.15 12:56, Goffredo Baroncelli (kreij...@libero.it) wrote:

> From: Goffredo Baroncelli 
> 
> Revert patch 11689d2a, which force the NOCOW attribute for the journal files.
> This patch was introduced to allievate the perfomances problem that
> journald shows on the BTRFS filesystem.
> 

>  #include "btrfs-util.h"
>  #include "journal-def.h"
> @@ -142,17 +141,8 @@ void journal_file_close(JournalFile *f) {
>  if (f->mmap && f->fd >= 0)
>  mmap_cache_close_fd(f->mmap, f->fd);
>  
> -if (f->fd >= 0 && f->defrag_on_close) {
> -
> -/* Be friendly to btrfs: turn COW back on again now,
> - * and defragment the file. We won't write to the file
> - * ever again, hence remove all fragmentation, and
> - * reenable all the good bits COW usually provides
> - * (such as data checksumming). */
> -
> -(void) chattr_fd(f->fd, false, FS_NOCOW_FL);
> -(void) btrfs_defrag_fd(f->fd);
> -}
> +if (f->fd >= 0 && f->defrag_on_close)
> +btrfs_defrag_fd(f->fd);

I think this part should probably stay... I mean, it's actually
without effect since btrfs doesn't allow unsetting the COW flag right
now if the file is non-empty. But I still think we should do this, in
case it learns it one day. And after rotating the file there's really
no need to disable COW anymore...

>  
>  /* btrfs doesn't cope well with our write pattern and
>   * fragments heavily. Let's defrag all files we rotate */
> -
> -(void) chattr_path(p, false, FS_NOCOW_FL);
>  (void) btrfs_defrag(p);

This case is similar.

>  
>  log_warning("File %s corrupted or uncleanly shut down, renaming and 
> replacing.", fname);
> diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
> index 55c7786..abb9d0c 100644
> --- a/src/journal/journalctl.c
> +++ b/src/journal/journalctl.c
> @@ -1290,7 +1290,7 @@ static int setup_keys(void) {
>  size_t mpk_size, seed_size, state_size, i;
>  uint8_t *mpk, *seed, *state;
>  ssize_t l;
> -int fd = -1, r;
> +int fd = -1, r, attr = 0;
>  sd_id128_t machine, boot;
>  char *p = NULL, *k = NULL;
>  struct FSSHeader h;
> @@ -1385,9 +1385,13 @@ static int setup_keys(void) {
>  
>  /* Enable secure remove, exclusion from dump, synchronous
>   * writing and in-place updating */
> -r = chattr_fd(fd, true, 
> FS_SECRM_FL|FS_NODUMP_FL|FS_SYNC_FL|FS_NOCOW_FL);
> -if (r < 0)
> -log_warning_errno(errno, "Failed to set file attributes: 
> %m");
> +if (ioctl(fd, FS_IOC_GETFLAGS, &attr) < 0)
> +log_warning_errno(errno, "FS_IOC_GETFLAGS failed: %m");
> +
> +attr |= FS_SECRM_FL|FS_NODUMP_FL|FS_SYNC_FL|FS_NOCOW_FL;
> +
> +if (ioctl(fd, FS_IOC_SETFLAGS, &attr) < 0)
> +log_warning_errno(errno, "FS_IOC_SETFLAGS failed: %m");

This is unrelated, and should not be reverted at all.

Lennart

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

Re: [systemd-devel] networkd: Is auto-negotiation turned off when specifying parameters in a link file?

[Lennart Poettering]

On Wed, 08.04.15 22:13, Paul Menzel (paulepan...@users.sourceforge.net) wrote:

> > Wouldn't it suffice to unplug the ethernet cable, then use ethtool to
> > turn this on, then replug it, and measuring the time until networkd
> > notices the link beat is back?
> 
> It would. But this is a rented Hetzner server and I have no access to
> the data center. Do you have another idea. Please keep in mind that I
> also only have remote access using that NIC. ;-)

Then, I figure a udev rule should do. Something like this (untested:)

ACTION=="add", SUBSYSTEM=="net", KERNEL!="lo", RUN+="/usr/bin/ethtool $name ..."

Replace the "..." of course with the ethool options you need.

This would then be run immediately when the device appears. If this
makes a measurable difference, then let us know.

Lennart

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

Re: [systemd-devel] [PATCH 2/4] Allow systemd-tmpfiles to set the file/directory attributes

[Lennart Poettering]

On Wed, 08.04.15 21:21, Goffredo Baroncelli (kreij...@libero.it) wrote:

> >> +const unsigned all_flags = FS_NOATIME_FL|FS_SYNC_FL|FS_DIRSYNC_FL|
> >> +FS_APPEND_FL|FS_COMPR_FL|FS_NODUMP_FL|FS_EXTENT_FL|
> >> +FS_IMMUTABLE_FL|FS_JOURNAL_DATA_FL|FS_SECRM_FL|FS_UNRM_FL|
> >> +FS_NOTAIL_FL|FS_TOPDIR_FL|FS_NOCOW_FL;
> >> +char *p = item->argument;
> >> +enum {
> >> +MODE_ADD,
> >> +MODE_DEL,
> >> +MODE_SET
> >> +} mode = MODE_ADD;
> >> +unsigned long value = 0, mask = 0;
> > 
> > And now it is "unsigned long", not just "unsigned anymore?
> 
> For 32 bit, the ioctl FS_IOC_GETFLAGS seems to be defined with an
> "int" as argument; for 64bit, the argument is a long; however
> chattr_fd() uses unsigned... Yes this is a mess; probably "int" is a
> good answer

Well, the kernel is a bit confused, but as far as I can see it
generally treats it as "unsigned". Only in the ext234 code there's
this gem that it calls get_user() and pretends it was an int, while
reading it into an unsigned.  btrfs never falls for that, and neither
do most other file systems afaics.

e2fsprogs is also confused. It treats it mostly as "unsigned long",
but then converts it to "int" right before issueing the ioctl. 

I guess the kernel devs haven't understood the concept of "type
safety" yet, or even worse, of "types" ;-)

But anway, I'd stay close to the kernel, so let's make this an
"unsigned".

Flag fields that are signed would be weird anyway...

> >> +if (lstat(path, &st) == 0 &&
> >> +!S_ISREG(st.st_mode) && !S_ISDIR(st.st_mode)) {
> >> +return 0;
> >> +}
> > 
> > Why do we need this check? What happens if we apply this onto
> > a device node, or socket, or whatever? 
> 
> I copied this check from the source of chattr; the reason is:
> 
> (from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=152029#10)
> [...]
> >$ lsattr /dev/dri/card0
> >s-S--- /dev/dri/card0
> >Segmentation fault (core dumped)
> >
> >$ ls -al /dev/dri/card0
> >crw-rw-rw-1 root root 226,   0 jun 30 11:12 /dev/dri/card0
> 
> lsattr and chattr can not work against device files, since they use
> ioctl's which are supported by the ext2 filesystem, but which aren't
> supported by normal devices (and unfortunately normal devices don't
> forwawrd the ioctl on to the ext2 filesystem).  In this case, the ioctl
> used by lsattr is apparently also implemented by the DRI device driver,
> but probably does something completely different.  So the returned
> device structure contains garbage, which causes lsattr to core dump
> [...]

I see, this is indeed a real problem (and in fact we might need to fix
this for a couple of other fs related ioctls, too).

Either way, this really should be an fstat() on the opened file and
not a stat() before, due to TOCTTOU.

Anyway, I now made the necessary changes, and changed a few other
things too, and gave it some testing. Please have a look if it still
looks good to you!

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 v2 1/2] configure: allow setting EFI_CC

[Marc-Antoine Perennou]

---
 configure.ac | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 1608c83..7e4a574 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1147,8 +1147,7 @@ fi
 AM_CONDITIONAL(ENABLE_EFI, [test "x$have_efi" = "xyes"])
 
 # 
--
-EFI_CC=gcc
-AC_SUBST([EFI_CC])
+AC_CHECK_TOOL(EFI_CC, gcc)
 
 EFI_ARCH=`echo $host | sed "s/\(-\).*$//"`
 
-- 
2.3.3

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

[systemd-devel] [PATCH v2 2/2] build: allow setting OBJCOPY

[Marc-Antoine Perennou]

---
 Makefile.am  | 4 ++--
 configure.ac | 1 +
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 9b769ee..397a71c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2596,7 +2596,7 @@ $(systemd_boot_solib): $(systemd_boot_objects)
nm -D -u $@ | grep ' U ' && exit 1 || :
 
 $(systemd_boot): $(systemd_boot_solib)
-   $(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \
+   $(AM_V_GEN)$(OBJCOPY) -j .text -j .sdata -j .data -j .dynamic \
  -j .dynsym -j .rel -j .rela -j .reloc \
  --target=efi-app-$(EFI_ARCH) $< $@
 
@@ -2634,7 +2634,7 @@ $(stub_solib): $(stub_objects)
nm -D -u $@ | grep ' U ' && exit 1 || :
 
 $(stub): $(stub_solib)
-   $(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \
+   $(AM_V_GEN)$(OBJCOPY) -j .text -j .sdata -j .data -j .dynamic \
  -j .dynsym -j .rel -j .rela -j .reloc \
  --target=efi-app-$(EFI_ARCH) $< $@
 
diff --git a/configure.ac b/configure.ac
index 7e4a574..6d7c2af 100644
--- a/configure.ac
+++ b/configure.ac
@@ -119,6 +119,7 @@ GOBJECT_INTROSPECTION_CHECK([1.31.1])
AM_CONDITIONAL([HAVE_INTROSPECTION], [false])
enable_introspection=no])
 
+AC_CHECK_TOOL(OBJCOPY, objcopy)
 AC_CHECK_TOOL(STRINGS, strings)
 AC_CHECK_TOOL(GPERF, gperf)
 if test -z "$GPERF" ; then
-- 
2.3.3

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

Re: [systemd-devel] [PATCH 2/2] build: allow setting OBJCOPY

[Marc-Antoine Perennou]

On 8 April 2015 at 22:24, Mike Gilbert  wrote:
> On Wed, Apr 8, 2015 at 4:08 PM, Marc-Antoine Perennou
>  wrote:
>> Signed-off-by: Marc-Antoine Perennou 
>> ---
>>  Makefile.am  | 4 ++--
>>  configure.ac | 3 +++
>>  2 files changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index 9b769ee..397a71c 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -2596,7 +2596,7 @@ $(systemd_boot_solib): $(systemd_boot_objects)
>> nm -D -u $@ | grep ' U ' && exit 1 || :
>>
>>  $(systemd_boot): $(systemd_boot_solib)
>> -   $(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \
>> +   $(AM_V_GEN)$(OBJCOPY) -j .text -j .sdata -j .data -j .dynamic \
>>   -j .dynsym -j .rel -j .rela -j .reloc \
>>   --target=efi-app-$(EFI_ARCH) $< $@
>>
>> @@ -2634,7 +2634,7 @@ $(stub_solib): $(stub_objects)
>> nm -D -u $@ | grep ' U ' && exit 1 || :
>>
>>  $(stub): $(stub_solib)
>> -   $(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \
>> +   $(AM_V_GEN)$(OBJCOPY) -j .text -j .sdata -j .data -j .dynamic \
>>   -j .dynsym -j .rel -j .rela -j .reloc \
>>   --target=efi-app-$(EFI_ARCH) $< $@
>>
>> diff --git a/configure.ac b/configure.ac
>> index 0722841..faf1596 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -83,6 +83,9 @@ AC_PROG_AWK
>>
>>  AC_PROG_CC_C99
>>
>> +AC_ARG_VAR(OBJCOPY, [The objcopy binary])
>> +test -z "$ac_cv_env_OBJCOPY_value" && OBJCOPY=objcopy
>
> Why not use AC_CHECK_TOOL here?
>
> https://www.gnu.org/software/autoconf/manual/autoconf.html#Generic-Programs

Heh, indeed, forgot about this one. Thanks!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 2/2] build: allow setting OBJCOPY

[Mike Gilbert]

On Wed, Apr 8, 2015 at 4:08 PM, Marc-Antoine Perennou
 wrote:
> Signed-off-by: Marc-Antoine Perennou 
> ---
>  Makefile.am  | 4 ++--
>  configure.ac | 3 +++
>  2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile.am b/Makefile.am
> index 9b769ee..397a71c 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -2596,7 +2596,7 @@ $(systemd_boot_solib): $(systemd_boot_objects)
> nm -D -u $@ | grep ' U ' && exit 1 || :
>
>  $(systemd_boot): $(systemd_boot_solib)
> -   $(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \
> +   $(AM_V_GEN)$(OBJCOPY) -j .text -j .sdata -j .data -j .dynamic \
>   -j .dynsym -j .rel -j .rela -j .reloc \
>   --target=efi-app-$(EFI_ARCH) $< $@
>
> @@ -2634,7 +2634,7 @@ $(stub_solib): $(stub_objects)
> nm -D -u $@ | grep ' U ' && exit 1 || :
>
>  $(stub): $(stub_solib)
> -   $(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \
> +   $(AM_V_GEN)$(OBJCOPY) -j .text -j .sdata -j .data -j .dynamic \
>   -j .dynsym -j .rel -j .rela -j .reloc \
>   --target=efi-app-$(EFI_ARCH) $< $@
>
> diff --git a/configure.ac b/configure.ac
> index 0722841..faf1596 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -83,6 +83,9 @@ AC_PROG_AWK
>
>  AC_PROG_CC_C99
>
> +AC_ARG_VAR(OBJCOPY, [The objcopy binary])
> +test -z "$ac_cv_env_OBJCOPY_value" && OBJCOPY=objcopy

Why not use AC_CHECK_TOOL here?

https://www.gnu.org/software/autoconf/manual/autoconf.html#Generic-Programs
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] networkd: Is auto-negotiation turned off when specifying parameters in a link file?

[Paul Menzel]

Am Dienstag, den 07.04.2015, 18:37 +0200 schrieb Lennart Poettering:
> On Mon, 06.04.15 22:16, Paul Menzel wrote:
> 
> > Am Freitag, den 03.04.2015, 16:47 +0200 schrieb Lennart Poettering:
> > > On Thu, 02.04.15 13:11, Paul Menzel wrote:
> > 
> > > > some network cards with certain cables and devices take up to five
> > > > seconds so that the link is up [1].
> > > > 
> > > > $ sudo journalctl -u systemd-networkd
> > > > -- Logs begin at Fr 2015-03-20 17:39:31 CET, end at So 
> > > > 2015-03-22 08:39:39 CET. --
> > > > Mär 20 17:39:31 myhostname systemd-networkd[245]: lo
> > > >   : gained carrier
> > > > Mär 20 17:39:31 myhostname systemd-networkd[245]: eth0  
> > > >   : link configured
> > > > Mär 20 17:39:34 myhostname systemd-networkd[245]: eth0  
> > > >   : gained carrier
> > > > 
> > > > This is annoying if the system is up, but you cannot log into a server
> > > > because the NIC is so slow configuring the link.
> > > > 
> > > > The Linux kernel module developers from the e1000-devel mailing list
> > > > suggested the following [2]:
> > > > 
> > > > > Both sides either need to be forced or both sides need to be auto-neg.
> > > > > Otherwise the auto-negotiation process will usually detect link (the
> > > > > physical signal) but fail to find duplex (since one side is not
> > > > > talking) and default to the lowest common denominator, e.g. half
> > > > > duplex.  So, you could try forcing speed, it may look right on your
> > > > > end but if you have no visibility to the other end it could be running
> > > > > at half duplex.
> > > > >
> > > > > You may be able to speed up the auto negotiation process by
> > > > > exclusively advertising 1000 Mbps Full Duplex.
> > > > >
> > > > > # ethtool -s ethX advertise 0x20
> > > > 
> > > > In the IRC channel #syst...@irc.freenode.net somebody told me to look
> > > > into systemd’s network link configuration (`man systemd.link`).
> > > > 
> > > > Reading the manual page, it’s not clear to me, if auto-negotiation is
> > > > going to be disabled, if the following is set.
> > > > 
> > > > BitsPerSecond=1G
> > > > Duplex=Full
> > > > 
> > > > Is that equivalent to `ethtool -s ethX advertise 0x20`? If not, how
> > > > could I set that up?
> > > 
> > > BitsPerSecond= and Duplex= are equivalent to "ethtool speed" and
> > > "ethtool duplex". 
> > > 
> > > We currently have no setting in .link files that was equivalent to
> > > "ethtool advertise". Maybe we could add that, Tom?
> > > 
> > > Paul, are you sure that this will really cut 5s from the configuration
> > > time? Did you try this?
> > 
> > I am not sure and didn’t try this, as I do not know where to integrate
> > that `ethtool -s eth0 advertise …` call. In udev or `systemd-networkd`?
> > 
> > If somebody could help me, how I can test this, I’ll report my findings
> > back.
> 
> Wouldn't it suffice to unplug the ethernet cable, then use ethtool to
> turn this on, then replug it, and measuring the time until networkd
> notices the link beat is back?

It would. But this is a rented Hetzner server and I have no access to
the data center. Do you have another idea. Please keep in mind that I
also only have remote access using that NIC. ;-)


Thanks,

Paul


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

[systemd-devel] [PATCH 2/2] build: allow setting OBJCOPY

[Marc-Antoine Perennou]

Signed-off-by: Marc-Antoine Perennou 
---
 Makefile.am  | 4 ++--
 configure.ac | 3 +++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 9b769ee..397a71c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2596,7 +2596,7 @@ $(systemd_boot_solib): $(systemd_boot_objects)
nm -D -u $@ | grep ' U ' && exit 1 || :
 
 $(systemd_boot): $(systemd_boot_solib)
-   $(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \
+   $(AM_V_GEN)$(OBJCOPY) -j .text -j .sdata -j .data -j .dynamic \
  -j .dynsym -j .rel -j .rela -j .reloc \
  --target=efi-app-$(EFI_ARCH) $< $@
 
@@ -2634,7 +2634,7 @@ $(stub_solib): $(stub_objects)
nm -D -u $@ | grep ' U ' && exit 1 || :
 
 $(stub): $(stub_solib)
-   $(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \
+   $(AM_V_GEN)$(OBJCOPY) -j .text -j .sdata -j .data -j .dynamic \
  -j .dynsym -j .rel -j .rela -j .reloc \
  --target=efi-app-$(EFI_ARCH) $< $@
 
diff --git a/configure.ac b/configure.ac
index 0722841..faf1596 100644
--- a/configure.ac
+++ b/configure.ac
@@ -83,6 +83,9 @@ AC_PROG_AWK
 
 AC_PROG_CC_C99
 
+AC_ARG_VAR(OBJCOPY, [The objcopy binary])
+test -z "$ac_cv_env_OBJCOPY_value" && OBJCOPY=objcopy
+
 AC_PATH_PROG([M4], [m4])
 AC_PATH_PROG([XSLTPROC], [xsltproc])
 
-- 
2.3.3

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

[systemd-devel] [PATCH 1/2] configure: allow setting EFI_CC

[Marc-Antoine Perennou]

and only fallback to gcc
---
 configure.ac | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 1608c83..0722841 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1147,8 +1147,8 @@ fi
 AM_CONDITIONAL(ENABLE_EFI, [test "x$have_efi" = "xyes"])
 
 # 
--
-EFI_CC=gcc
-AC_SUBST([EFI_CC])
+AC_ARG_VAR(EFI_CC, [Compiler to be used for EFI stub])
+test -z "$ac_cv_env_EFI_CC_value" && EFI_CC=gcc
 
 EFI_ARCH=`echo $host | sed "s/\(-\).*$//"`
 
-- 
2.3.3

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

[systemd-devel] [PATCH 2/2] udev: Allow detection of udevadm settle timeout

[Nir Soffer]

When udevadm settle times out, it exits with exit code 1. This make it
impossible for users to detect a timeout and handle real errors.  Now we
use exit code 3 on timeouts.
---
 src/udev/udevadm-settle.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/udev/udevadm-settle.c b/src/udev/udevadm-settle.c
index 715d2e7..8f9ae81 100644
--- a/src/udev/udevadm-settle.c
+++ b/src/udev/udevadm-settle.c
@@ -29,6 +29,8 @@
 #include "udev.h"
 #include "util.h"
 
+#define EXIT_TIMEOUT 3
+
 static void help(void) {
 printf("%s settle OPTIONS\n\n"
"Wait for pending udev events.\n\n"
@@ -142,8 +144,10 @@ static int adm_settle(struct udev *udev, int argc, char 
*argv[]) {
 break;
 }
 
-if (now(CLOCK_MONOTONIC) >= deadline)
+if (now(CLOCK_MONOTONIC) >= deadline) {
+rc = EXIT_TIMEOUT;
 break;
+}
 
 /* wake up when queue is empty */
 if (poll(pfd, 1, MSEC_PER_SEC) > 0 && pfd[0].revents & POLLIN)
-- 
1.9.3

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

Re: [systemd-devel] [PATCH 2/4] Allow systemd-tmpfiles to set the file/directory attributes

[Goffredo Baroncelli]

On 2015-04-08 20:36, Lennart Poettering wrote:
> On Mon, 16.03.15 20:33, Goffredo Baroncelli (kreij...@libero.it) wrote:
> 
> Sorry for warming up this old thread, but a few issues I see with this?
> 
>>  RECURSIVE_RELABEL_PATH = 'Z',
>> +SET_ATTRIB = 'h',
>> +RECURSIVE_SET_ATTRIB = 'H',
>>  } ItemType;
>>  
>>  typedef struct Item {
>> @@ -108,12 +111,15 @@ typedef struct Item {
>>  usec_t age;
>>  
>>  dev_t major_minor;
>> +int attrib_value;
>> +int attrib_mask;
> 
> I thought this was unsigned now?

Sew below



> 
>>  
>> +static int get_attrib_from_arg(Item *item) {
>> +static const unsigned attributes[] = {
>> +[(uint8_t)'A'] = FS_NOATIME_FL,/* do not update atime */
>> +[(uint8_t)'S'] = FS_SYNC_FL,  /* Synchronous updates */
>> +[(uint8_t)'D'] = FS_DIRSYNC_FL,   /* dirsync behaviour 
>> (directories only) */
>> +[(uint8_t)'a'] = FS_APPEND_FL,/* writes to file may 
>> only append */
>> +[(uint8_t)'c'] = FS_COMPR_FL, /* Compress file */
>> +[(uint8_t)'d'] = FS_NODUMP_FL,/* do not dump file */
>> +[(uint8_t)'e'] = FS_EXTENT_FL,/* Top of directory 
>> hierarchies*/
>> +[(uint8_t)'i'] = FS_IMMUTABLE_FL, /* Immutable file */
>> +[(uint8_t)'j'] = FS_JOURNAL_DATA_FL, /* Reserved for ext3 */
>> +[(uint8_t)'s'] = FS_SECRM_FL, /* Secure deletion */
>> +[(uint8_t)'u'] = FS_UNRM_FL,  /* Undelete */
>> +[(uint8_t)'t'] = FS_NOTAIL_FL,/* file tail should not 
>> be merged */
>> +[(uint8_t)'T'] = FS_TOPDIR_FL,/* Top of directory 
>> hierarchies*/
>> +[(uint8_t)'C'] = FS_NOCOW_FL, /* Do not cow file */
>> +};
> 
> Hmm, that's quite a sparse array! It wastes 116 entries, just to
> store 13 entries... I think this should really be an array fo structs
> with the chars and their flag, which we iterate through... 

I accepted a suggestion of Zbyszek; this solution avoids to loop over the 
list... 
> 
>> +const unsigned all_flags = FS_NOATIME_FL|FS_SYNC_FL|FS_DIRSYNC_FL|
>> +FS_APPEND_FL|FS_COMPR_FL|FS_NODUMP_FL|FS_EXTENT_FL|
>> +FS_IMMUTABLE_FL|FS_JOURNAL_DATA_FL|FS_SECRM_FL|FS_UNRM_FL|
>> +FS_NOTAIL_FL|FS_TOPDIR_FL|FS_NOCOW_FL;
>> +char *p = item->argument;
>> +enum {
>> +MODE_ADD,
>> +MODE_DEL,
>> +MODE_SET
>> +} mode = MODE_ADD;
>> +unsigned long value = 0, mask = 0;
> 
> And now it is "unsigned long", not just "unsigned anymore?

For 32 bit, the ioctl FS_IOC_GETFLAGS seems to be defined with an "int" as 
argument; for 64bit, the argument is a long; however chattr_fd() uses 
unsigned... Yes this is a mess; probably "int" is a good answer

> 
>> +
>> +static int path_set_attrib(Item *item, const char *path) {
>> +_cleanup_close_ int fd = -1;
>> +int r;
>> +unsigned f;
>> +struct stat st;
>> +
>> +/* do nothing */
>> +if (item->attrib_mask == 0 || !item->attrib_set)
>> +return 0;
>> +/*
>> + * It is OK to ignore an lstat() error, because the error
>> + * will be catch by the open() below anyway
>> + */
>> +if (lstat(path, &st) == 0 &&
>> +!S_ISREG(st.st_mode) && !S_ISDIR(st.st_mode)) {
>> +return 0;
>> +}
> 
> Why do we need this check? What happens if we apply this onto
> a device node, or socket, or whatever? 

I copied this check from the source of chattr; the reason is:

(from https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=152029#10)
[...]
>$ lsattr /dev/dri/card0
>s-S--- /dev/dri/card0
>Segmentation fault (core dumped)
>
>$ ls -al /dev/dri/card0
>crw-rw-rw-1 root root 226,   0 jun 30 11:12 /dev/dri/card0

lsattr and chattr can not work against device files, since they use
ioctl's which are supported by the ext2 filesystem, but which aren't
supported by normal devices (and unfortunately normal devices don't
forwawrd the ioctl on to the ext2 filesystem).  In this case, the ioctl
used by lsattr is apparently also implemented by the DRI device driver,
but probably does something completely different.  So the returned
device structure contains garbage, which causes lsattr to core dump
[...]


> 
> I really don#t like this seperate lstat() + open(). If it all it
> should be open() + fstat(), to avoid TTOCTOU issues...
> 
>> +fd = open(path, O_RDONLY|O_NONBLOCK|O_CLOEXEC);
>> +
>> +if (fd < 0)
>> +return log_error_errno(errno, "Cannot open \"%s\": %m", 
>> path);
>>  
>> +case SET_ATTRIB:
>> +case RECURSIVE_SET_ATTRIB:
>> +if (!i.argument) {
>> +log_error("[%s:%u] Set attrib requires
>> argument.", fname, lin

Re: [systemd-devel] [PATCH 2/5] udev.pc: install to pkgconfiglibdir

[Kay Sievers]

On Wed, Apr 8, 2015 at 8:50 PM, Marc-Antoine Perennou
 wrote:
> Well, on one hand, we may have the need for multilib stuff to find the
> native binaries, as you said.
>
> On the other hand we have my case. Just a bit of background so that
> you understand where these patches come from:
> I'm developper for the Exherbo distribution, and we recently changed
> completely our filesystem layout when we introduced full
> cross-compilation support.
> We now have everything in /usr/arch (when you put stuff into /usr/lib/arch).
> We thus have complete trees for each arch with
> /usr/arch/{bin,sbin,lib,libexec,include} and want those to be
> completely independant.
> We try to keep as vanilla as possible and I think we're quite good at
> it, but inevitably we reach corner cases where it's impossible.

Yeah, that all makes sense. And we can have both. :)

> If you think it might make sense to have everything in
> libdir/pkgconfig (depite the redundancy of information), I'd be very
> happy.
> If instead you go and put everything into /usr/share/pkgconfig, it
> won't hurt that much for us to keep this patch downstream.

Right, we have to find out what we want to support here, cross-compile
or secondary arch things.

Only one thing is clear at the moment, that the current status makes
no sense. :)

We got $libdir for the secondary arch:
  
http://cgit.freedesktop.org/systemd/systemd/commit/?id=eb39a6239c631873db62f6a942e6cb3dab0a2db4

But then we took $libdir as the reason to move the file and make it
inaccessible for the secondary arch:
  
http://cgit.freedesktop.org/systemd/systemd/commit/?id=aec432c6134146e138124c4130be2ee89dca07fa

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

Re: [systemd-devel] [PATCH 2/5] udev.pc: install to pkgconfiglibdir

[Marc-Antoine Perennou]

On 8 April 2015 at 20:24, Kay Sievers  wrote:
> On Wed, Apr 8, 2015 at 8:10 PM, Marc-Antoine Perennou
>  wrote:
>> On 8 April 2015 at 20:02, Kay Sievers  wrote:
>>> On Wed, Apr 8, 2015 at 7:52 PM, Marc-Antoine Perennou
>>>  wrote:
 On 8 April 2015 at 19:46, Kay Sievers  wrote:
> On Wed, Apr 8, 2015 at 7:34 PM, Marc-Antoine Perennou
>  wrote:
>> On 8 April 2015 at 18:47, Kay Sievers  wrote:
>>> On Tue, Apr 7, 2015 at 8:54 PM, Marc-Antoine Perennou
>>>  wrote:
 ---
  Makefile.am | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

 diff --git a/Makefile.am b/Makefile.am
 index 9fa4223..9b769ee 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -3725,8 +3725,7 @@ udevconfdir = $(sysconfdir)/udev
  dist_udevconf_DATA = \
 src/udev/udev.conf

 -sharepkgconfigdir = $(datadir)/pkgconfig
 -sharepkgconfig_DATA = \
 +pkgconfiglib_DATA += \
 src/udev/udev.pc
>>>
>>> This is all backwards. The systemd.pc file is also in the wrong 
>>> location.
>>>
>>> These GENERIC files are supposed to be found by the primary AND the
>>> secondary arch at the same time, at the GENERIC location, not in a
>>> arch-specific libdir.
>>>
>>> How would the 32bit build find this file on a 64bit 
>>> compat-arch/multilib system?
>>>
>>> Kay
>>
>> Well, let's imagine a full cross-compilation toolchain, with
>> CHOST-prefixed tools.
>>
>> x86_64 stuff will get built with x86_64-pc-linux-gnu-gcc
>> i686 stuff will get built with i686-pc-linux-gnu-gcc
>> (and you could add a lot of non-native archs here like arm, mips & co)
>>
>> x86_64-pc-linux-gnu-pkg-config will look into /usr/lib64/pkgconfig and
>> /usr/share/pkgconfig
>> i686-pc-linux-gnu-pkg-config will look into /usr/lib32/pkgconfig and
>> /usr/share/pkgconfig
>>
>> You says that systemd is in the wrong location, so let's see what's
>> going on with its
>> current location, and then if we move it to /usr/share
>>
>> Current location, libdir/pkgconfig/systemd.pc
>>
>> x86_64-pc-linux-gnu-pkg-config finds /usr/lib64/pkgconfig/systemd.pc 
>> containing,
>> amongst other things, libdir which is arch specific, /usr/lib64 and
>> systemdutildir
>> which contains arch-specific binaries (yes, /usr/lib64/systemd/systemd 
>> *is* an
>> ELF64 binary using an x86_64 interpreter.
>>
>> i686-pc-linux-gnu-pkg-config finds /usr/lib32/pkgconfig/systemd.pc 
>> (since it has
>> been cross-compiled too) and is pretty happy with that.
>>
>> arm-whatever-pkg-config finds /usr/arm-whatever/lib/systemd.pc and is
>> happy with it.
>>
>> If you move it to /usr/share/pkgconfig
>>
>> x86_64-pc-linux-gnu-pkg-config finds /usr/share/pkgconfig/systemd.pc
>> and is happy with it
>>
>> i686-pc-linux-gnu-pkg-config finds /usr/share/pkgconfig/systemd.pc and
>> tries linking to
>> x86_64 libraries
>>
>> arm-whatever-pkg-config finds /usr/share/pkgconfig/systemd.pc and
>> tries linking to
>> x86_64 libraries + it gets the path towards binaries its target won't
>> even be able to execute.
>>
>>
>> Hope that helps understanding the rational of putting pkgconfig files
>> pointing to
>> arch-specific libs/bins into an arch-specific place.
>>
>>
>> A good example of a pkgconfig file that is ok to install into
>> /usr/share/pkgconfig is
>> xorg-macros.pc which only leads to arch-independants macros.
>
> The point is, the purpose of that file is not cross-compiling. It is
> meant to provide information for the i686 toolchain which is nativly
> compiled on a x86_64 primary host.
>
> How is the i686 tool supposed to find the primary values of the
> installed native x86_64 tools if things are moved like you propose?
>

 Why would it need to?
>>>
>>> Because it is the purpose of that file. The version of systemd which
>>> is installed is described in that file. Tools that build on this host
>>> want the values of this systemd.
>>>
> The entire idea of adding $libdir to a file that is installed in
> $libdir to point to itself makes no sense at all, but that was the
> reason it was moved in the first place.

 Agreed about the redundancy, but what if the arm tool wants to find
 installed arm tools, and not x86_64?
>>>
>>> This is not a systemd problem. Systemd is the base system, and that is
>>> described in that file, not something that is foreign to the base
>>> system.
>>>
>>> With the original intended purpose of these files, they just belong
>>> into one single common location describing the currently
>>> running/primary/common system values.
>>>
>>> $libdir was added to indicate the primary architecture. That only
>>> makes sense w

Re: [systemd-devel] [PATCH 1/4] Add change_attr_fd()

[Lennart Poettering]

On Wed, 08.04.15 20:37, Lennart Poettering (lenn...@poettering.net) wrote:

> On Mon, 16.03.15 20:33, Goffredo Baroncelli (kreij...@libero.it) wrote:
> 
> >  
> > +int change_attr_fd(int fd, unsigned value, unsigned mask) {
> > +unsigned old_attr, new_attr;
> > +
> > +assert(fd >= 0);
> > +
> > +if (mask == 0)
> > +return 0;
> > +
> > +if (ioctl(fd, FS_IOC_GETFLAGS, &old_attr) < 0)
> > +return -errno;
> > +
> > +new_attr = (old_attr & ~mask) |(value & mask);
> > +
> > +if (new_attr == old_attr)
> > +return 0;
> > +
> > +if (ioctl(fd, FS_IOC_SETFLAGS, &new_attr) < 0)
> > +return -errno;
> > +
> > +return 0;
> > +}
> > +
> 
> With this added chattr_fd() is kinda redundant, no?

I fixed this now.

Lennart

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

Re: [systemd-devel] [RFC] activate on DBus signal

[Simon McVittie]

On 08/04/15 18:05, Lennart Poettering wrote:
> In general, so far activation was limited to *explicit* messages sent to
> the service in question, services would never be activated as possibly
> unintended side-effect of unrelated broadcast messages, and that's a
> really good property...

Yes. The same reasoning exists in dbus-daemon.

> Well, it's not that simple, we'd also have to queue the signal, and
> all following messages, and pass that on to the activated
> service... And that's pretty nasty. It's already pretty nasty for the
> current logic but it would be even more complex with a match logic...

Yes. The same problems exist in dbus-daemon.

> I doubt this will fly...

That's what I said on dbus@, for remarkably similar reasons. It's
reassuring that systemd developers agree.

In answer to the original question, I suspect that wanting to do this
might be a sign that you should re-think your design. If you described
the high-level problem(s) you wanted to solve (not in abstract terms
like "I want to run a service in response to a broadcast", but in more
concrete terms like maybe "I want to start a VPN whenever we join a
wireless network"), perhaps someone could suggest a better way to solve it.

However, if you have re-thought it and concluded that yes, you really do
want what you initially asked for, I think this is the only way to do it
in current D-Bus, and also the only way that will be supported in kdbus:

* have your own signal-listening service that listens for the
  "interesting" broadcasts, and has a configurable map from broadcast
  characteristics to something to activate for that broadcast
* have that signal-listening daemon either send a unicast message
  to the activatable service (which will cause activation as a
  side-effect), or explicitly ask dbus-daemon or systemd to
  activate it
* when the activatable service starts up, it performs state-recovery
  to catch up on the broadcasts that it missed, including the one that
  resulted in its activation

... all of which can be done right now, if you really need to, without
any changes to either systemd or dbus.

-- 
Simon McVittie
Collabora Ltd. 

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

Re: [systemd-devel] [PATCH 1/4] Add change_attr_fd()

[Lennart Poettering]

On Mon, 16.03.15 20:33, Goffredo Baroncelli (kreij...@libero.it) wrote:

>  
> +int change_attr_fd(int fd, unsigned value, unsigned mask) {
> +unsigned old_attr, new_attr;
> +
> +assert(fd >= 0);
> +
> +if (mask == 0)
> +return 0;
> +
> +if (ioctl(fd, FS_IOC_GETFLAGS, &old_attr) < 0)
> +return -errno;
> +
> +new_attr = (old_attr & ~mask) |(value & mask);
> +
> +if (new_attr == old_attr)
> +return 0;
> +
> +if (ioctl(fd, FS_IOC_SETFLAGS, &new_attr) < 0)
> +return -errno;
> +
> +return 0;
> +}
> +

With this added chattr_fd() is kinda redundant, no?

Lennart

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

Re: [systemd-devel] [PATCH 2/4] Allow systemd-tmpfiles to set the file/directory attributes

[Lennart Poettering]

On Mon, 16.03.15 20:33, Goffredo Baroncelli (kreij...@libero.it) wrote:

Sorry for warming up this old thread, but a few issues I see with this?

>  RECURSIVE_RELABEL_PATH = 'Z',
> +SET_ATTRIB = 'h',
> +RECURSIVE_SET_ATTRIB = 'H',
>  } ItemType;
>  
>  typedef struct Item {
> @@ -108,12 +111,15 @@ typedef struct Item {
>  usec_t age;
>  
>  dev_t major_minor;
> +int attrib_value;
> +int attrib_mask;

I thought this was unsigned now?

>  
> +static int get_attrib_from_arg(Item *item) {
> +static const unsigned attributes[] = {
> +[(uint8_t)'A'] = FS_NOATIME_FL,/* do not update atime */
> +[(uint8_t)'S'] = FS_SYNC_FL,  /* Synchronous updates */
> +[(uint8_t)'D'] = FS_DIRSYNC_FL,   /* dirsync behaviour 
> (directories only) */
> +[(uint8_t)'a'] = FS_APPEND_FL,/* writes to file may only 
> append */
> +[(uint8_t)'c'] = FS_COMPR_FL, /* Compress file */
> +[(uint8_t)'d'] = FS_NODUMP_FL,/* do not dump file */
> +[(uint8_t)'e'] = FS_EXTENT_FL,/* Top of directory 
> hierarchies*/
> +[(uint8_t)'i'] = FS_IMMUTABLE_FL, /* Immutable file */
> +[(uint8_t)'j'] = FS_JOURNAL_DATA_FL, /* Reserved for ext3 */
> +[(uint8_t)'s'] = FS_SECRM_FL, /* Secure deletion */
> +[(uint8_t)'u'] = FS_UNRM_FL,  /* Undelete */
> +[(uint8_t)'t'] = FS_NOTAIL_FL,/* file tail should not be 
> merged */
> +[(uint8_t)'T'] = FS_TOPDIR_FL,/* Top of directory 
> hierarchies*/
> +[(uint8_t)'C'] = FS_NOCOW_FL, /* Do not cow file */
> +};

Hmm, that's quite a sparse array! It wastes 116 entries, just to
store 13 entries... I think this should really be an array fo structs
with the chars and their flag, which we iterate through... 

> +const unsigned all_flags = FS_NOATIME_FL|FS_SYNC_FL|FS_DIRSYNC_FL|
> +FS_APPEND_FL|FS_COMPR_FL|FS_NODUMP_FL|FS_EXTENT_FL|
> +FS_IMMUTABLE_FL|FS_JOURNAL_DATA_FL|FS_SECRM_FL|FS_UNRM_FL|
> +FS_NOTAIL_FL|FS_TOPDIR_FL|FS_NOCOW_FL;
> +char *p = item->argument;
> +enum {
> +MODE_ADD,
> +MODE_DEL,
> +MODE_SET
> +} mode = MODE_ADD;
> +unsigned long value = 0, mask = 0;

And now it is "unsigned long", not just "unsigned anymore?

> +
> +static int path_set_attrib(Item *item, const char *path) {
> +_cleanup_close_ int fd = -1;
> +int r;
> +unsigned f;
> +struct stat st;
> +
> +/* do nothing */
> +if (item->attrib_mask == 0 || !item->attrib_set)
> +return 0;
> +/*
> + * It is OK to ignore an lstat() error, because the error
> + * will be catch by the open() below anyway
> + */
> +if (lstat(path, &st) == 0 &&
> +!S_ISREG(st.st_mode) && !S_ISDIR(st.st_mode)) {
> +return 0;
> +}

Why do we need this check? What happens if we apply this onto
a device node, or socket, or whatever? 

I really don#t like this seperate lstat() + open(). If it all it
should be open() + fstat(), to avoid TTOCTOU issues...

> +fd = open(path, O_RDONLY|O_NONBLOCK|O_CLOEXEC);
> +
> +if (fd < 0)
> +return log_error_errno(errno, "Cannot open \"%s\": %m", 
> path);
>  
> +case SET_ATTRIB:
> +case RECURSIVE_SET_ATTRIB:
> +if (!i.argument) {
> +log_error("[%s:%u] Set attrib requires
> argument.", fname, line);

Please don't abbreviate words like "attrib" in human language...

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 4/5] configure: allow setting EFI_CC

[Marc-Antoine Perennou]

On 7 April 2015 at 20:54, Marc-Antoine Perennou
 wrote:
> and only fallback to gcc
> ---
>  configure.ac | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/configure.ac b/configure.ac
> index 1608c83..56340a2 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -1147,7 +1147,7 @@ fi
>  AM_CONDITIONAL(ENABLE_EFI, [test "x$have_efi" = "xyes"])
>
>  # 
> --
> -EFI_CC=gcc
> +EFI_CC="${EFI_CC:-gcc}"
>  AC_SUBST([EFI_CC])
>
>  EFI_ARCH=`echo $host | sed "s/\(-\).*$//"`
> --
> 2.3.3
>


Please ignore this patch, a better version is coming of this 4/5 and of 5/5.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 2/5] udev.pc: install to pkgconfiglibdir

[Kay Sievers]

On Wed, Apr 8, 2015 at 8:10 PM, Marc-Antoine Perennou
 wrote:
> On 8 April 2015 at 20:02, Kay Sievers  wrote:
>> On Wed, Apr 8, 2015 at 7:52 PM, Marc-Antoine Perennou
>>  wrote:
>>> On 8 April 2015 at 19:46, Kay Sievers  wrote:
 On Wed, Apr 8, 2015 at 7:34 PM, Marc-Antoine Perennou
  wrote:
> On 8 April 2015 at 18:47, Kay Sievers  wrote:
>> On Tue, Apr 7, 2015 at 8:54 PM, Marc-Antoine Perennou
>>  wrote:
>>> ---
>>>  Makefile.am | 3 +--
>>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/Makefile.am b/Makefile.am
>>> index 9fa4223..9b769ee 100644
>>> --- a/Makefile.am
>>> +++ b/Makefile.am
>>> @@ -3725,8 +3725,7 @@ udevconfdir = $(sysconfdir)/udev
>>>  dist_udevconf_DATA = \
>>> src/udev/udev.conf
>>>
>>> -sharepkgconfigdir = $(datadir)/pkgconfig
>>> -sharepkgconfig_DATA = \
>>> +pkgconfiglib_DATA += \
>>> src/udev/udev.pc
>>
>> This is all backwards. The systemd.pc file is also in the wrong location.
>>
>> These GENERIC files are supposed to be found by the primary AND the
>> secondary arch at the same time, at the GENERIC location, not in a
>> arch-specific libdir.
>>
>> How would the 32bit build find this file on a 64bit compat-arch/multilib 
>> system?
>>
>> Kay
>
> Well, let's imagine a full cross-compilation toolchain, with
> CHOST-prefixed tools.
>
> x86_64 stuff will get built with x86_64-pc-linux-gnu-gcc
> i686 stuff will get built with i686-pc-linux-gnu-gcc
> (and you could add a lot of non-native archs here like arm, mips & co)
>
> x86_64-pc-linux-gnu-pkg-config will look into /usr/lib64/pkgconfig and
> /usr/share/pkgconfig
> i686-pc-linux-gnu-pkg-config will look into /usr/lib32/pkgconfig and
> /usr/share/pkgconfig
>
> You says that systemd is in the wrong location, so let's see what's
> going on with its
> current location, and then if we move it to /usr/share
>
> Current location, libdir/pkgconfig/systemd.pc
>
> x86_64-pc-linux-gnu-pkg-config finds /usr/lib64/pkgconfig/systemd.pc 
> containing,
> amongst other things, libdir which is arch specific, /usr/lib64 and
> systemdutildir
> which contains arch-specific binaries (yes, /usr/lib64/systemd/systemd 
> *is* an
> ELF64 binary using an x86_64 interpreter.
>
> i686-pc-linux-gnu-pkg-config finds /usr/lib32/pkgconfig/systemd.pc (since 
> it has
> been cross-compiled too) and is pretty happy with that.
>
> arm-whatever-pkg-config finds /usr/arm-whatever/lib/systemd.pc and is
> happy with it.
>
> If you move it to /usr/share/pkgconfig
>
> x86_64-pc-linux-gnu-pkg-config finds /usr/share/pkgconfig/systemd.pc
> and is happy with it
>
> i686-pc-linux-gnu-pkg-config finds /usr/share/pkgconfig/systemd.pc and
> tries linking to
> x86_64 libraries
>
> arm-whatever-pkg-config finds /usr/share/pkgconfig/systemd.pc and
> tries linking to
> x86_64 libraries + it gets the path towards binaries its target won't
> even be able to execute.
>
>
> Hope that helps understanding the rational of putting pkgconfig files
> pointing to
> arch-specific libs/bins into an arch-specific place.
>
>
> A good example of a pkgconfig file that is ok to install into
> /usr/share/pkgconfig is
> xorg-macros.pc which only leads to arch-independants macros.

 The point is, the purpose of that file is not cross-compiling. It is
 meant to provide information for the i686 toolchain which is nativly
 compiled on a x86_64 primary host.

 How is the i686 tool supposed to find the primary values of the
 installed native x86_64 tools if things are moved like you propose?

>>>
>>> Why would it need to?
>>
>> Because it is the purpose of that file. The version of systemd which
>> is installed is described in that file. Tools that build on this host
>> want the values of this systemd.
>>
 The entire idea of adding $libdir to a file that is installed in
 $libdir to point to itself makes no sense at all, but that was the
 reason it was moved in the first place.
>>>
>>> Agreed about the redundancy, but what if the arm tool wants to find
>>> installed arm tools, and not x86_64?
>>
>> This is not a systemd problem. Systemd is the base system, and that is
>> described in that file, not something that is foreign to the base
>> system.
>>
>> With the original intended purpose of these files, they just belong
>> into one single common location describing the currently
>> running/primary/common system values.
>>
>> $libdir was added to indicate the primary architecture. That only
>> makes sense when the file is in a common location, not in libdir. Like
>> described in the man page:
>>   
>> http://www.freedesktop.org/software/systemd/man/file-hierarchy.html#/usr/lib/arch-id
>>

Re: [systemd-devel] [PATCH 1/2] Update IFA_MAX adding IFA_FLAGS

[Lennart Poettering]

On Wed, 08.04.15 20:04, Alexander Sverdlin (alexander.sverd...@gmail.com) wrote:

> Hello Lennart,
> 
> On 08/04/15 12:57, Lennart Poettering wrote:
> >> Fixes the following compilation problem:
> >> > src/libsystemd/sd-rtnl/rtnl-types.c:361:9: error: array index in 
> >> > initializer exceeds array bounds
> >> >  [IFA_FLAGS] = { .type = NLA_U32 },
> >> >  ^
> >> > src/libsystemd/sd-rtnl/rtnl-types.c:361:9: error: (near initialization 
> >> > for 'rtnl_address_types')
> >> > 
> >> > Also include if_addr.h into missing.h so that it's possible to
> >> > redefine __IFA_MAX.
> > I feel a bit uneasy about changing definitions from the header
> 
> Hmm, that's what actually happened in 81577dc2, for instance...

Well, I think we should still avoid it (though I wasn't aware of this commit).

> > files. Adding is fine, but altering them is something we should be
> > carefuly with. Hence I commited a different fix now:
> 
> Oh, this is cryptic, especially for people familiar with netlink, but not 
> introduced to patching
> missing.h... This is error prone, because one requires such not obvious 
> construct in every place
> where IFA_FLAGS will be used. It will be eventually detected by compiler, but 
> it's far more safe
> to redefine the IFA_MAX...

I think the lesson is really to stay away from IFA_MAX and similar 
definitions...

Lennart

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

Re: [systemd-devel] [PATCH 2/5] udev.pc: install to pkgconfiglibdir

[Marc-Antoine Perennou]

On 8 April 2015 at 20:02, Kay Sievers  wrote:
> On Wed, Apr 8, 2015 at 7:52 PM, Marc-Antoine Perennou
>  wrote:
>> On 8 April 2015 at 19:46, Kay Sievers  wrote:
>>> On Wed, Apr 8, 2015 at 7:34 PM, Marc-Antoine Perennou
>>>  wrote:
 On 8 April 2015 at 18:47, Kay Sievers  wrote:
> On Tue, Apr 7, 2015 at 8:54 PM, Marc-Antoine Perennou
>  wrote:
>> ---
>>  Makefile.am | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index 9fa4223..9b769ee 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -3725,8 +3725,7 @@ udevconfdir = $(sysconfdir)/udev
>>  dist_udevconf_DATA = \
>> src/udev/udev.conf
>>
>> -sharepkgconfigdir = $(datadir)/pkgconfig
>> -sharepkgconfig_DATA = \
>> +pkgconfiglib_DATA += \
>> src/udev/udev.pc
>
> This is all backwards. The systemd.pc file is also in the wrong location.
>
> These GENERIC files are supposed to be found by the primary AND the
> secondary arch at the same time, at the GENERIC location, not in a
> arch-specific libdir.
>
> How would the 32bit build find this file on a 64bit compat-arch/multilib 
> system?
>
> Kay

 Well, let's imagine a full cross-compilation toolchain, with
 CHOST-prefixed tools.

 x86_64 stuff will get built with x86_64-pc-linux-gnu-gcc
 i686 stuff will get built with i686-pc-linux-gnu-gcc
 (and you could add a lot of non-native archs here like arm, mips & co)

 x86_64-pc-linux-gnu-pkg-config will look into /usr/lib64/pkgconfig and
 /usr/share/pkgconfig
 i686-pc-linux-gnu-pkg-config will look into /usr/lib32/pkgconfig and
 /usr/share/pkgconfig

 You says that systemd is in the wrong location, so let's see what's
 going on with its
 current location, and then if we move it to /usr/share

 Current location, libdir/pkgconfig/systemd.pc

 x86_64-pc-linux-gnu-pkg-config finds /usr/lib64/pkgconfig/systemd.pc 
 containing,
 amongst other things, libdir which is arch specific, /usr/lib64 and
 systemdutildir
 which contains arch-specific binaries (yes, /usr/lib64/systemd/systemd 
 *is* an
 ELF64 binary using an x86_64 interpreter.

 i686-pc-linux-gnu-pkg-config finds /usr/lib32/pkgconfig/systemd.pc (since 
 it has
 been cross-compiled too) and is pretty happy with that.

 arm-whatever-pkg-config finds /usr/arm-whatever/lib/systemd.pc and is
 happy with it.

 If you move it to /usr/share/pkgconfig

 x86_64-pc-linux-gnu-pkg-config finds /usr/share/pkgconfig/systemd.pc
 and is happy with it

 i686-pc-linux-gnu-pkg-config finds /usr/share/pkgconfig/systemd.pc and
 tries linking to
 x86_64 libraries

 arm-whatever-pkg-config finds /usr/share/pkgconfig/systemd.pc and
 tries linking to
 x86_64 libraries + it gets the path towards binaries its target won't
 even be able to execute.


 Hope that helps understanding the rational of putting pkgconfig files
 pointing to
 arch-specific libs/bins into an arch-specific place.


 A good example of a pkgconfig file that is ok to install into
 /usr/share/pkgconfig is
 xorg-macros.pc which only leads to arch-independants macros.
>>>
>>> The point is, the purpose of that file is not cross-compiling. It is
>>> meant to provide information for the i686 toolchain which is nativly
>>> compiled on a x86_64 primary host.
>>>
>>> How is the i686 tool supposed to find the primary values of the
>>> installed native x86_64 tools if things are moved like you propose?
>>>
>>
>> Why would it need to?
>
> Because it is the purpose of that file. The version of systemd which
> is installed is described in that file. Tools that build on this host
> want the values of this systemd.
>
>>> The entire idea of adding $libdir to a file that is installed in
>>> $libdir to point to itself makes no sense at all, but that was the
>>> reason it was moved in the first place.
>>
>> Agreed about the redundancy, but what if the arm tool wants to find
>> installed arm tools, and not x86_64?
>
> This is not a systemd problem. Systemd is the base system, and that is
> described in that file, not something that is foreign to the base
> system.
>
> With the original intended purpose of these files, they just belong
> into one single common location describing the currently
> running/primary/common system values.
>
> $libdir was added to indicate the primary architecture. That only
> makes sense when the file is in a common location, not in libdir. Like
> described in the man page:
>   
> http://www.freedesktop.org/software/systemd/man/file-hierarchy.html#/usr/lib/arch-id
>
> Kay

Even if I don't fully agree with it, I understand your point, we'll
then maintain this patch downstream.

Thanks for the details about this refusal.

Marc-Antoine
_

Re: [systemd-devel] [PATCH 1/2] Update IFA_MAX adding IFA_FLAGS

[Alexander Sverdlin]

Hello Lennart,

On 08/04/15 12:57, Lennart Poettering wrote:
>> Fixes the following compilation problem:
>> > src/libsystemd/sd-rtnl/rtnl-types.c:361:9: error: array index in 
>> > initializer exceeds array bounds
>> >  [IFA_FLAGS] = { .type = NLA_U32 },
>> >  ^
>> > src/libsystemd/sd-rtnl/rtnl-types.c:361:9: error: (near initialization for 
>> > 'rtnl_address_types')
>> > 
>> > Also include if_addr.h into missing.h so that it's possible to
>> > redefine __IFA_MAX.
> I feel a bit uneasy about changing definitions from the header

Hmm, that's what actually happened in 81577dc2, for instance...

> files. Adding is fine, but altering them is something we should be
> carefuly with. Hence I commited a different fix now:

Oh, this is cryptic, especially for people familiar with netlink, but not 
introduced to patching
missing.h... This is error prone, because one requires such not obvious 
construct in every place
where IFA_FLAGS will be used. It will be eventually detected by compiler, but 
it's far more safe
to redefine the IFA_MAX...

> http://cgit.freedesktop.org/systemd/systemd/commit/?id=de79f906ab614dd0d53129c4d4aa18a964864f39
> 
> Please test!

Though, it compiles fine now.

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

Re: [systemd-devel] drop-ins and watchdogs question

[Lennart Poettering]

On Sat, 21.03.15 13:07, Alison Chaiken (ali...@she-devel.com) wrote:

Heya,

> and type 'systemctl daemon-reexec'.   As expected, 'sudo lsof
> /dev/watchdog' shows no one is holding file open.   However, the
> system does not reboot!I'm not sure if this is because of the way
> that the softdog works, or because I haven't overridden the property
> properly.I can see that if I just removed the
> /run/systemd/system.conf file, that RuntimeWatchdogSec should be
> unchanged upon daemon-reexec, but I would think that manually
> overriding it by setting it to zero should have the intended result
> here.   Which leads to the questions:

When we close the device we turn off the watchdog in the kernel, to
avoid that the system reboots automatically shortly after. The "wdctl"
tool from util-linux should show that.

> -- Is there a way to get systemd to dump what values it's using for
> the variables in system.conf?   'systemctl show-environment' doesn't
> do it.

systemctl show -a.

> -- In a realistic situation, how would drop-in configuration files in
> /run/systemd be created?   I guess a script in the initrd could do it.
>Presumably configuration of a feature like a watchdog that is
> needed early in boot is better handled through
> /etc/systemd/system.conf.

What precisely are you trying to do?

Most of our configuration files in very recent versions support
drop-ins now.

Lennart

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

Re: [systemd-devel] [PATCH 2/5] udev.pc: install to pkgconfiglibdir

[Kay Sievers]

On Wed, Apr 8, 2015 at 7:52 PM, Marc-Antoine Perennou
 wrote:
> On 8 April 2015 at 19:46, Kay Sievers  wrote:
>> On Wed, Apr 8, 2015 at 7:34 PM, Marc-Antoine Perennou
>>  wrote:
>>> On 8 April 2015 at 18:47, Kay Sievers  wrote:
 On Tue, Apr 7, 2015 at 8:54 PM, Marc-Antoine Perennou
  wrote:
> ---
>  Makefile.am | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/Makefile.am b/Makefile.am
> index 9fa4223..9b769ee 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -3725,8 +3725,7 @@ udevconfdir = $(sysconfdir)/udev
>  dist_udevconf_DATA = \
> src/udev/udev.conf
>
> -sharepkgconfigdir = $(datadir)/pkgconfig
> -sharepkgconfig_DATA = \
> +pkgconfiglib_DATA += \
> src/udev/udev.pc

 This is all backwards. The systemd.pc file is also in the wrong location.

 These GENERIC files are supposed to be found by the primary AND the
 secondary arch at the same time, at the GENERIC location, not in a
 arch-specific libdir.

 How would the 32bit build find this file on a 64bit compat-arch/multilib 
 system?

 Kay
>>>
>>> Well, let's imagine a full cross-compilation toolchain, with
>>> CHOST-prefixed tools.
>>>
>>> x86_64 stuff will get built with x86_64-pc-linux-gnu-gcc
>>> i686 stuff will get built with i686-pc-linux-gnu-gcc
>>> (and you could add a lot of non-native archs here like arm, mips & co)
>>>
>>> x86_64-pc-linux-gnu-pkg-config will look into /usr/lib64/pkgconfig and
>>> /usr/share/pkgconfig
>>> i686-pc-linux-gnu-pkg-config will look into /usr/lib32/pkgconfig and
>>> /usr/share/pkgconfig
>>>
>>> You says that systemd is in the wrong location, so let's see what's
>>> going on with its
>>> current location, and then if we move it to /usr/share
>>>
>>> Current location, libdir/pkgconfig/systemd.pc
>>>
>>> x86_64-pc-linux-gnu-pkg-config finds /usr/lib64/pkgconfig/systemd.pc 
>>> containing,
>>> amongst other things, libdir which is arch specific, /usr/lib64 and
>>> systemdutildir
>>> which contains arch-specific binaries (yes, /usr/lib64/systemd/systemd *is* 
>>> an
>>> ELF64 binary using an x86_64 interpreter.
>>>
>>> i686-pc-linux-gnu-pkg-config finds /usr/lib32/pkgconfig/systemd.pc (since 
>>> it has
>>> been cross-compiled too) and is pretty happy with that.
>>>
>>> arm-whatever-pkg-config finds /usr/arm-whatever/lib/systemd.pc and is
>>> happy with it.
>>>
>>> If you move it to /usr/share/pkgconfig
>>>
>>> x86_64-pc-linux-gnu-pkg-config finds /usr/share/pkgconfig/systemd.pc
>>> and is happy with it
>>>
>>> i686-pc-linux-gnu-pkg-config finds /usr/share/pkgconfig/systemd.pc and
>>> tries linking to
>>> x86_64 libraries
>>>
>>> arm-whatever-pkg-config finds /usr/share/pkgconfig/systemd.pc and
>>> tries linking to
>>> x86_64 libraries + it gets the path towards binaries its target won't
>>> even be able to execute.
>>>
>>>
>>> Hope that helps understanding the rational of putting pkgconfig files
>>> pointing to
>>> arch-specific libs/bins into an arch-specific place.
>>>
>>>
>>> A good example of a pkgconfig file that is ok to install into
>>> /usr/share/pkgconfig is
>>> xorg-macros.pc which only leads to arch-independants macros.
>>
>> The point is, the purpose of that file is not cross-compiling. It is
>> meant to provide information for the i686 toolchain which is nativly
>> compiled on a x86_64 primary host.
>>
>> How is the i686 tool supposed to find the primary values of the
>> installed native x86_64 tools if things are moved like you propose?
>>
>
> Why would it need to?

Because it is the purpose of that file. The version of systemd which
is installed is described in that file. Tools that build on this host
want the values of this systemd.

>> The entire idea of adding $libdir to a file that is installed in
>> $libdir to point to itself makes no sense at all, but that was the
>> reason it was moved in the first place.
>
> Agreed about the redundancy, but what if the arm tool wants to find
> installed arm tools, and not x86_64?

This is not a systemd problem. Systemd is the base system, and that is
described in that file, not something that is foreign to the base
system.

With the original intended purpose of these files, they just belong
into one single common location describing the currently
running/primary/common system values.

$libdir was added to indicate the primary architecture. That only
makes sense when the file is in a common location, not in libdir. Like
described in the man page:
  
http://www.freedesktop.org/software/systemd/man/file-hierarchy.html#/usr/lib/arch-id

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

Re: [systemd-devel] [PATCH v2 2/4] udev: Update pointingstick rules to allow setting ibm trackpoint sensitivity

[Kay Sievers]

On Tue, Apr 7, 2015 at 7:06 AM, Peter Hutterer  wrote:
> On Fri, Apr 03, 2015 at 04:11:58PM +0200, Hans de Goede wrote:

>> +TEST=="../../../sensitivity", ENV{POINTINGSTICK_SENSITIVITY}!="", \
>> +  ATTR{../../../sensitivity}="$env{POINTINGSTICK_SENSITIVITY}"
>>
>>  LABEL="pointingstick_end"
>
> hmm, not the nicest rule but I couldn't find anything simpler. Kay, any idea
> how do do this with fewer relative path specs?

We cannot really ship any "../../../". This would encode a fixed
number of steps from the child device to the parent device, but the
kernel must be free to insert more devices in the chain of devices
without breaking our logic.

This stuff probably needs to be implemented in code looking up a
specific parent, and not just using udev rules.

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

Re: [systemd-devel] [PATCH 2/5] udev.pc: install to pkgconfiglibdir

[Marc-Antoine Perennou]

On 8 April 2015 at 19:46, Kay Sievers  wrote:
> On Wed, Apr 8, 2015 at 7:34 PM, Marc-Antoine Perennou
>  wrote:
>> On 8 April 2015 at 18:47, Kay Sievers  wrote:
>>> On Tue, Apr 7, 2015 at 8:54 PM, Marc-Antoine Perennou
>>>  wrote:
 ---
  Makefile.am | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

 diff --git a/Makefile.am b/Makefile.am
 index 9fa4223..9b769ee 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -3725,8 +3725,7 @@ udevconfdir = $(sysconfdir)/udev
  dist_udevconf_DATA = \
 src/udev/udev.conf

 -sharepkgconfigdir = $(datadir)/pkgconfig
 -sharepkgconfig_DATA = \
 +pkgconfiglib_DATA += \
 src/udev/udev.pc
>>>
>>> This is all backwards. The systemd.pc file is also in the wrong location.
>>>
>>> These GENERIC files are supposed to be found by the primary AND the
>>> secondary arch at the same time, at the GENERIC location, not in a
>>> arch-specific libdir.
>>>
>>> How would the 32bit build find this file on a 64bit compat-arch/multilib 
>>> system?
>>>
>>> Kay
>>
>> Well, let's imagine a full cross-compilation toolchain, with
>> CHOST-prefixed tools.
>>
>> x86_64 stuff will get built with x86_64-pc-linux-gnu-gcc
>> i686 stuff will get built with i686-pc-linux-gnu-gcc
>> (and you could add a lot of non-native archs here like arm, mips & co)
>>
>> x86_64-pc-linux-gnu-pkg-config will look into /usr/lib64/pkgconfig and
>> /usr/share/pkgconfig
>> i686-pc-linux-gnu-pkg-config will look into /usr/lib32/pkgconfig and
>> /usr/share/pkgconfig
>>
>> You says that systemd is in the wrong location, so let's see what's
>> going on with its
>> current location, and then if we move it to /usr/share
>>
>> Current location, libdir/pkgconfig/systemd.pc
>>
>> x86_64-pc-linux-gnu-pkg-config finds /usr/lib64/pkgconfig/systemd.pc 
>> containing,
>> amongst other things, libdir which is arch specific, /usr/lib64 and
>> systemdutildir
>> which contains arch-specific binaries (yes, /usr/lib64/systemd/systemd *is* 
>> an
>> ELF64 binary using an x86_64 interpreter.
>>
>> i686-pc-linux-gnu-pkg-config finds /usr/lib32/pkgconfig/systemd.pc (since it 
>> has
>> been cross-compiled too) and is pretty happy with that.
>>
>> arm-whatever-pkg-config finds /usr/arm-whatever/lib/systemd.pc and is
>> happy with it.
>>
>> If you move it to /usr/share/pkgconfig
>>
>> x86_64-pc-linux-gnu-pkg-config finds /usr/share/pkgconfig/systemd.pc
>> and is happy with it
>>
>> i686-pc-linux-gnu-pkg-config finds /usr/share/pkgconfig/systemd.pc and
>> tries linking to
>> x86_64 libraries
>>
>> arm-whatever-pkg-config finds /usr/share/pkgconfig/systemd.pc and
>> tries linking to
>> x86_64 libraries + it gets the path towards binaries its target won't
>> even be able to execute.
>>
>>
>> Hope that helps understanding the rational of putting pkgconfig files
>> pointing to
>> arch-specific libs/bins into an arch-specific place.
>>
>>
>> A good example of a pkgconfig file that is ok to install into
>> /usr/share/pkgconfig is
>> xorg-macros.pc which only leads to arch-independants macros.
>
> The point is, the purpose of that file is not cross-compiling. It is
> meant to provide information for the i686 toolchain which is nativly
> compiled on a x86_64 primary host.
>
> How is the i686 tool supposed to find the primary values of the
> installed native x86_64 tools if things are moved like you propose?
>

Why would it need to?

> The entire idea of adding $libdir to a file that is installed in
> $libdir to point to itself makes no sense at all, but that was the
> reason it was moved in the first place.
>
> Kay

Agreed about the redundancy, but what if the arm tool wants to find
installed arm tools, and not x86_64?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 5/5] build: use $(OBJCOPY)

[Kay Sievers]

On Wed, Apr 8, 2015 at 7:36 PM, Marc-Antoine Perennou
 wrote:
> On 8 April 2015 at 19:03, Kay Sievers  wrote:
>> On Tue, Apr 7, 2015 at 8:54 PM, Marc-Antoine Perennou
>>  wrote:
>>> ---
>>>  Makefile.am | 4 ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Makefile.am b/Makefile.am
>>> index 9b769ee..397a71c 100644
>>> --- a/Makefile.am
>>> +++ b/Makefile.am
>>> @@ -2596,7 +2596,7 @@ $(systemd_boot_solib): $(systemd_boot_objects)
>>> nm -D -u $@ | grep ' U ' && exit 1 || :
>>>
>>>  $(systemd_boot): $(systemd_boot_solib)
>>> -   $(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \
>>> +   $(AM_V_GEN)$(OBJCOPY) -j .text -j .sdata -j .data -j .dynamic \
>>
>> This does not build here. I don't see who would define OBJCOPY.
>>
>> Kay
>
> Someone with a full CHOST-prefixed compilation toolchain would.
> I agree there should be a default value here, though, will send another
> fixed patch for this.

Please just test such stuff for the common setup before sending it
out, which is NOT cross-compilation. :)

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

Re: [systemd-devel] [PATCH 2/5] udev.pc: install to pkgconfiglibdir

[Kay Sievers]

On Wed, Apr 8, 2015 at 7:34 PM, Marc-Antoine Perennou
 wrote:
> On 8 April 2015 at 18:47, Kay Sievers  wrote:
>> On Tue, Apr 7, 2015 at 8:54 PM, Marc-Antoine Perennou
>>  wrote:
>>> ---
>>>  Makefile.am | 3 +--
>>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/Makefile.am b/Makefile.am
>>> index 9fa4223..9b769ee 100644
>>> --- a/Makefile.am
>>> +++ b/Makefile.am
>>> @@ -3725,8 +3725,7 @@ udevconfdir = $(sysconfdir)/udev
>>>  dist_udevconf_DATA = \
>>> src/udev/udev.conf
>>>
>>> -sharepkgconfigdir = $(datadir)/pkgconfig
>>> -sharepkgconfig_DATA = \
>>> +pkgconfiglib_DATA += \
>>> src/udev/udev.pc
>>
>> This is all backwards. The systemd.pc file is also in the wrong location.
>>
>> These GENERIC files are supposed to be found by the primary AND the
>> secondary arch at the same time, at the GENERIC location, not in a
>> arch-specific libdir.
>>
>> How would the 32bit build find this file on a 64bit compat-arch/multilib 
>> system?
>>
>> Kay
>
> Well, let's imagine a full cross-compilation toolchain, with
> CHOST-prefixed tools.
>
> x86_64 stuff will get built with x86_64-pc-linux-gnu-gcc
> i686 stuff will get built with i686-pc-linux-gnu-gcc
> (and you could add a lot of non-native archs here like arm, mips & co)
>
> x86_64-pc-linux-gnu-pkg-config will look into /usr/lib64/pkgconfig and
> /usr/share/pkgconfig
> i686-pc-linux-gnu-pkg-config will look into /usr/lib32/pkgconfig and
> /usr/share/pkgconfig
>
> You says that systemd is in the wrong location, so let's see what's
> going on with its
> current location, and then if we move it to /usr/share
>
> Current location, libdir/pkgconfig/systemd.pc
>
> x86_64-pc-linux-gnu-pkg-config finds /usr/lib64/pkgconfig/systemd.pc 
> containing,
> amongst other things, libdir which is arch specific, /usr/lib64 and
> systemdutildir
> which contains arch-specific binaries (yes, /usr/lib64/systemd/systemd *is* an
> ELF64 binary using an x86_64 interpreter.
>
> i686-pc-linux-gnu-pkg-config finds /usr/lib32/pkgconfig/systemd.pc (since it 
> has
> been cross-compiled too) and is pretty happy with that.
>
> arm-whatever-pkg-config finds /usr/arm-whatever/lib/systemd.pc and is
> happy with it.
>
> If you move it to /usr/share/pkgconfig
>
> x86_64-pc-linux-gnu-pkg-config finds /usr/share/pkgconfig/systemd.pc
> and is happy with it
>
> i686-pc-linux-gnu-pkg-config finds /usr/share/pkgconfig/systemd.pc and
> tries linking to
> x86_64 libraries
>
> arm-whatever-pkg-config finds /usr/share/pkgconfig/systemd.pc and
> tries linking to
> x86_64 libraries + it gets the path towards binaries its target won't
> even be able to execute.
>
>
> Hope that helps understanding the rational of putting pkgconfig files
> pointing to
> arch-specific libs/bins into an arch-specific place.
>
>
> A good example of a pkgconfig file that is ok to install into
> /usr/share/pkgconfig is
> xorg-macros.pc which only leads to arch-independants macros.

The point is, the purpose of that file is not cross-compiling. It is
meant to provide information for the i686 toolchain which is nativly
compiled on a x86_64 primary host.

How is the i686 tool supposed to find the primary values of the
installed native x86_64 tools if things are moved like you propose?

The entire idea of adding $libdir to a file that is installed in
$libdir to point to itself makes no sense at all, but that was the
reason it was moved in the first place.

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

Re: [systemd-devel] [PATCH 1/6] udev: builtin-keyboard: move fetching the device node up

[David Herrmann]

Hi

On Wed, Apr 8, 2015 at 7:41 PM, Lennart Poettering
 wrote:
> On Mon, 23.03.15 11:30, Peter Hutterer (peter.hutte...@who-t.net) wrote:
>
>> No point parsing the properties if we can't get the devnode to apply them
>> later. Plus, this makes future additions easier to slot in.
>
> Hmm, Peter, this series was never pushed?
>
> (Just making sure this is not forgotten...)

There's still discussion on patches 5 and 6 (and cross-discussion with
Hans' series). Kay and me discussed the hwdb modalias namespace mess
and need to push the changes before we can apply these. We're on it.

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

Re: [systemd-devel] [PATCH 1/6] udev: builtin-keyboard: move fetching the device node up

[Lennart Poettering]

On Mon, 23.03.15 11:30, Peter Hutterer (peter.hutte...@who-t.net) wrote:

> No point parsing the properties if we can't get the devnode to apply them
> later. Plus, this makes future additions easier to slot in.

Hmm, Peter, this series was never pushed?

(Just making sure this is not forgotten...)

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 5/5] build: use $(OBJCOPY)

[Marc-Antoine Perennou]

On 8 April 2015 at 19:03, Kay Sievers  wrote:
> On Tue, Apr 7, 2015 at 8:54 PM, Marc-Antoine Perennou
>  wrote:
>> ---
>>  Makefile.am | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index 9b769ee..397a71c 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -2596,7 +2596,7 @@ $(systemd_boot_solib): $(systemd_boot_objects)
>> nm -D -u $@ | grep ' U ' && exit 1 || :
>>
>>  $(systemd_boot): $(systemd_boot_solib)
>> -   $(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \
>> +   $(AM_V_GEN)$(OBJCOPY) -j .text -j .sdata -j .data -j .dynamic \
>
> This does not build here. I don't see who would define OBJCOPY.
>
> Kay

Someone with a full CHOST-prefixed compilation toolchain would.
I agree there should be a default value here, though, will send another
fixed patch for this.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 2/5] udev.pc: install to pkgconfiglibdir

[Marc-Antoine Perennou]

On 8 April 2015 at 18:47, Kay Sievers  wrote:
> On Tue, Apr 7, 2015 at 8:54 PM, Marc-Antoine Perennou
>  wrote:
>> ---
>>  Makefile.am | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/Makefile.am b/Makefile.am
>> index 9fa4223..9b769ee 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -3725,8 +3725,7 @@ udevconfdir = $(sysconfdir)/udev
>>  dist_udevconf_DATA = \
>> src/udev/udev.conf
>>
>> -sharepkgconfigdir = $(datadir)/pkgconfig
>> -sharepkgconfig_DATA = \
>> +pkgconfiglib_DATA += \
>> src/udev/udev.pc
>
> This is all backwards. The systemd.pc file is also in the wrong location.
>
> These GENERIC files are supposed to be found by the primary AND the
> secondary arch at the same time, at the GENERIC location, not in a
> arch-specific libdir.
>
> How would the 32bit build find this file on a 64bit compat-arch/multilib 
> system?
>
> Kay

Well, let's imagine a full cross-compilation toolchain, with
CHOST-prefixed tools.

x86_64 stuff will get built with x86_64-pc-linux-gnu-gcc
i686 stuff will get built with i686-pc-linux-gnu-gcc
(and you could add a lot of non-native archs here like arm, mips & co)

x86_64-pc-linux-gnu-pkg-config will look into /usr/lib64/pkgconfig and
/usr/share/pkgconfig
i686-pc-linux-gnu-pkg-config will look into /usr/lib32/pkgconfig and
/usr/share/pkgconfig

You says that systemd is in the wrong location, so let's see what's
going on with its
current location, and then if we move it to /usr/share

Current location, libdir/pkgconfig/systemd.pc

x86_64-pc-linux-gnu-pkg-config finds /usr/lib64/pkgconfig/systemd.pc containing,
amongst other things, libdir which is arch specific, /usr/lib64 and
systemdutildir
which contains arch-specific binaries (yes, /usr/lib64/systemd/systemd *is* an
ELF64 binary using an x86_64 interpreter.

i686-pc-linux-gnu-pkg-config finds /usr/lib32/pkgconfig/systemd.pc (since it has
been cross-compiled too) and is pretty happy with that.

arm-whatever-pkg-config finds /usr/arm-whatever/lib/systemd.pc and is
happy with it.

If you move it to /usr/share/pkgconfig

x86_64-pc-linux-gnu-pkg-config finds /usr/share/pkgconfig/systemd.pc
and is happy with it

i686-pc-linux-gnu-pkg-config finds /usr/share/pkgconfig/systemd.pc and
tries linking to
x86_64 libraries

arm-whatever-pkg-config finds /usr/share/pkgconfig/systemd.pc and
tries linking to
x86_64 libraries + it gets the path towards binaries its target won't
even be able to execute.


Hope that helps understanding the rational of putting pkgconfig files
pointing to
arch-specific libs/bins into an arch-specific place.


A good example of a pkgconfig file that is ok to install into
/usr/share/pkgconfig is
xorg-macros.pc which only leads to arch-independants macros.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Supporting ExecStartPre= and friends in `systemctl set-property` or `systemd-run -p`

[Lennart Poettering]

On Mon, 23.03.15 17:49, Ivan Shapovalov (intelfx...@gmail.com) wrote:

> On 2015-03-23 at 13:45 +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Mon, Mar 23, 2015 at 04:04:28PM +0300, Ivan Shapovalov wrote:
> > > Hello,
> > > 
> > > is it possible/allowed/desired to support assigning ExecStartPre= and
> > > similar options via dbus interface, i. e. in `systemctl set-property` or
> > > `systemd-run -p`?
> > > 
> > > I'm hitting a usecase when I need to run a service with multiple
> > > executed processes via `systemd-run`. I think this makes sense to
> > > support, isn't it?
> > Sounds like creating a transient unit would be better.
> 
> That is, ..?
> How can I create a unit that will be removed as soon as it's
> stopped?

Normally all services are GC'ed the moment they are fully stopped and
didn't fail. That means you can simply use systemd-run, and they will
go away automatically after termination unless they fail...

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] Supporting ExecStartPre= and friends in `systemctl set-property` or `systemd-run -p`

[Lennart Poettering]

On Mon, 23.03.15 16:04, Ivan Shapovalov (intelfx...@gmail.com) wrote:

> Hello,
> 
> is it possible/allowed/desired to support assigning ExecStartPre= and
> similar options via dbus interface, i. e. in `systemctl set-property` or
> `systemd-run -p`?

So far our philosophy for allowing dynamically changable properties is
that we do this only for properties we can actually really alter
dynamically at runtime. For example, properties that map to cgroup
attributes are of this kind, as we can pass them to the kernel
immediately so that they take effect. However, other properties, like
for example the nice level are not of this kind, since we can
reasonably set them only while forking off processes, and afterwards
it is not clear what to set them on (just the main process? all
processes? and what to do if the service altered its own nice level,
and applied different levels to different procecesses, what do we do
then?).

ExecStartPre= is a property we cannot really adjust dynamically, after
all it specifies what to execute, and that's only relevant during
service startup?

> I'm hitting a usecase when I need to run a service with multiple
> executed processes via `systemd-run`. I think this makes sense to
> support, isn't it?

Can you elaborate on this? A service with multiple processes?
In parallel? Normally we recommend a 1:1 mapping between services and
forked off processes, i.e. never fork off multiple processes for the
same service (unless the service does that internally...). The only
exception to this logic is for Type=oneshot services, where we allow
multiple processes, but only serialized, not parallel.

Anyway, I don't really grok what you want to to...

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] systemctl: Use logind for --firmware-setup if possible

[Lennart Poettering]

On Wed, 08.04.15 19:05, Jan Janssen (medhe...@web.de) wrote:

> What's the point in retrying if you got EOPNOTSUPP the first time?
> :P

Well, dunno. Actually the main reason I swapped around the order of
the two ways, is to avoid whitelisting or blacklisting error
cases... I mean, there are certain cases where it makes sense to try
the other way (EPERM, EACCES, ...), and others where it clearly doesn't
(ENOTSUPP, ...), but I really wanted to avoid to list them all
here. Hence I figured we should do the cheap thing first, and then the
expensive thing, without any kind of optimizations via error code
whitelists/blacklists... If you follow what I mean...

Does that make any sense?

> 
> Jan
> 
> On 2015-04-08 18:24, Lennart Poettering wrote:
> >On Wed, 08.04.15 16:49, Jan Janssen (medhe...@web.de) wrote:
> >
> >Awesome! Thanks!
> >
> >Applied! (Though I took the liberty to swap the order around, to first
> >try direct access, and only the fall back via logind.
> >
> >Thanks,
> >
> >Lennart
> >
> >>---
> >>  src/systemctl/systemctl.c | 43 ++-
> >>  1 file changed, 38 insertions(+), 5 deletions(-)
> >>
> >>diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
> >>index ae87e44..caa8d07 100644
> >>--- a/src/systemctl/systemctl.c
> >>+++ b/src/systemctl/systemctl.c
> >>@@ -2913,6 +2913,41 @@ static int check_inhibitors(sd_bus *bus, enum action 
> >>a) {
> >>  #endif
> >>  }
> >>
> >>+static int prepare_firmware_setup(sd_bus *bus) {
> >>+int r;
> >>+_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
> >>+
> >>+if (!arg_firmware_setup)
> >>+return 0;
> >>+
> >>+#ifdef HAVE_LOGIND
> >>+r = sd_bus_call_method(
> >>+bus,
> >>+"org.freedesktop.login1",
> >>+"/org/freedesktop/login1",
> >>+"org.freedesktop.login1.Manager",
> >>+"SetRebootToFirmwareSetup",
> >>+&error,
> >>+NULL,
> >>+"b", true);
> >>+if (r < 0)
> >>+log_error("Cannot indicate to EFI to boot into setup mode: 
> >>%s", bus_error_message(&error, r));
> >>+
> >>+/* No point trying to fall back. */
> >>+if (r == -EOPNOTSUPP)
> >>+return r;
> >>+#endif
> >>+
> >>+if (arg_transport != BUS_TRANSPORT_LOCAL)
> >>+return log_error_errno(-EINVAL, "Cannot remotely indicate 
> >>to EFI to boot into setup mode.");
> >>+
> >>+r = efi_set_reboot_to_firmware(true);
> >>+if (r < 0)
> >>+return log_error_errno(r, "Cannot indicate to EFI to boot 
> >>into setup mode: %m");
> >>+
> >>+return 0;
> >>+}
> >>+
> >>  static int start_special(sd_bus *bus, char **args) {
> >>  enum action a;
> >>  int r;
> >>@@ -2930,11 +2965,9 @@ static int start_special(sd_bus *bus, char **args) {
> >>  return -EPERM;
> >>  }
> >>
> >>-if (arg_firmware_setup) {
> >>-r = efi_set_reboot_to_firmware(true);
> >>-if (r < 0)
> >>-return log_error_errno(r, "Cannot indicate to EFI 
> >>to boot into setup mode: %m");
> >>-}
> >>+r = prepare_firmware_setup(bus);
> >>+if (r < 0)
> >>+return r;
> >>
> >>  if (a == ACTION_REBOOT && args[1]) {
> >>  r = update_reboot_param_file(args[1]);
> >>--
> >>2.3.5
> >>
> >>___
> >>systemd-devel mailing list
> >>systemd-devel@lists.freedesktop.org
> >>http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> >
> >
> >Lennart
> >


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] [RFC] activate on DBus signal

[Lennart Poettering]

On Mon, 23.03.15 17:54, WaLyong Cho (walyong@samsung.com) wrote:

> Hi,
> 
> Now, I'm looking for a method to a service be activated on special DBus
> signal. If a process is running for waiting some of DBus signal this can
> be useful.
> 
> I already told with Simon in DBus mailing list.
> 
> see this thread:
> http://lists.freedesktop.org/archives/dbus/2015-March/016607.html
> 
> Simon said:
> "If it did, there are some nasty ordering constraints - I certainly
> wouldn't want to have to delay delivery of a broadcast until all
> interested services had started up! - so I don't think adding this
> feature would be a good idea."
> 
> How about also support for DBus signal?

Hmm, so this has come up before, but this is really nasty to support,
and I am not convinced we really want this.

First of all, in a kdbus world this would require kernel support, so
that the kernel will listen and queue messages on behalf of userspace,
and that would be quite a major change...

In general, so far activation was limited to *explicit* messages sent to
the service in question, services would never be activated as possibly
unintended side-effect of unrelated broadcast messages, and that's a
really good property...

> Then, make systemd to monitor DBus. And if a matched signal was sent,
> activate the service.

Well, it's not that simple, we'd also have to queue the signal, and
all following messages, and pass that on to the activated
service... And that's pretty nasty. It's already pretty nasty for the
current logic but it would be even more complex with a match logic...

I doubt this will fly...

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] [PATCH] systemctl: Use logind for --firmware-setup if possible

[Jan Janssen]

What's the point in retrying if you got EOPNOTSUPP the first time? :P

Jan

On 2015-04-08 18:24, Lennart Poettering wrote:

On Wed, 08.04.15 16:49, Jan Janssen (medhe...@web.de) wrote:

Awesome! Thanks!

Applied! (Though I took the liberty to swap the order around, to first
try direct access, and only the fall back via logind.

Thanks,

Lennart


---
  src/systemctl/systemctl.c | 43 ++-
  1 file changed, 38 insertions(+), 5 deletions(-)

diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index ae87e44..caa8d07 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -2913,6 +2913,41 @@ static int check_inhibitors(sd_bus *bus, enum action a) {
  #endif
  }

+static int prepare_firmware_setup(sd_bus *bus) {
+int r;
+_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
+
+if (!arg_firmware_setup)
+return 0;
+
+#ifdef HAVE_LOGIND
+r = sd_bus_call_method(
+bus,
+"org.freedesktop.login1",
+"/org/freedesktop/login1",
+"org.freedesktop.login1.Manager",
+"SetRebootToFirmwareSetup",
+&error,
+NULL,
+"b", true);
+if (r < 0)
+log_error("Cannot indicate to EFI to boot into setup mode: %s", 
bus_error_message(&error, r));
+
+/* No point trying to fall back. */
+if (r == -EOPNOTSUPP)
+return r;
+#endif
+
+if (arg_transport != BUS_TRANSPORT_LOCAL)
+return log_error_errno(-EINVAL, "Cannot remotely indicate to EFI to 
boot into setup mode.");
+
+r = efi_set_reboot_to_firmware(true);
+if (r < 0)
+return log_error_errno(r, "Cannot indicate to EFI to boot into 
setup mode: %m");
+
+return 0;
+}
+
  static int start_special(sd_bus *bus, char **args) {
  enum action a;
  int r;
@@ -2930,11 +2965,9 @@ static int start_special(sd_bus *bus, char **args) {
  return -EPERM;
  }

-if (arg_firmware_setup) {
-r = efi_set_reboot_to_firmware(true);
-if (r < 0)
-return log_error_errno(r, "Cannot indicate to EFI to boot 
into setup mode: %m");
-}
+r = prepare_firmware_setup(bus);
+if (r < 0)
+return r;

  if (a == ACTION_REBOOT && args[1]) {
  r = update_reboot_param_file(args[1]);
--
2.3.5

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



Lennart


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

Re: [systemd-devel] [PATCH 5/5] build: use $(OBJCOPY)

[Kay Sievers]

On Tue, Apr 7, 2015 at 8:54 PM, Marc-Antoine Perennou
 wrote:
> ---
>  Makefile.am | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile.am b/Makefile.am
> index 9b769ee..397a71c 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -2596,7 +2596,7 @@ $(systemd_boot_solib): $(systemd_boot_objects)
> nm -D -u $@ | grep ' U ' && exit 1 || :
>
>  $(systemd_boot): $(systemd_boot_solib)
> -   $(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \
> +   $(AM_V_GEN)$(OBJCOPY) -j .text -j .sdata -j .data -j .dynamic \

This does not build here. I don't see who would define OBJCOPY.

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

Re: [systemd-devel] Questions about timedatectl and NTP

[Jakub Klinkovský]

On 08.04.15 at 18:35, Lennart Poettering wrote:
> On Wed, 08.04.15 16:11, Jakub Klinkovský (j@gmx.com) wrote:
> > That's not what I meant. The man page for 'timedatectl status' currently 
> > says:
> > 
> > Show current settings of the system clock and RTC, including whether
> > network time synchronization is enabled. Note that the network time
> > synchronization state simply reflects whether the 
> > systemd-timesyncd.service
> > unit is enabled. ...
> > 
> > The "time synchronization state" in this context refers to both fields 
> > reported
> > by timedatectl status, "Network Time on" and "NTP synchronized". I think 
> > there
> > is more disambiguation needed.
> 
> Indeed!
> 
> I reworded this sentence a bit now. Please have a look!

Now that brings consistency, thank you!

-- 
Jakub Klinkovský


pgpV0nAm3xNgN.pgp
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] regarding to cgroup siblings mask

[Lennart Poettering]

On Tue, 24.03.15 20:29, WaLyong Cho (walyong@samsung.com) wrote:

> Hi,
> 
> In recent systemd(from some month ago), when a unit has a mask for cpu
> or blockio or memory, this mask is also propagated to siblings by
> unit_get_target_mask().
> According to some of comments, it seems intentional.
> 
> Could anyone explain why?

I added this after talking to Tejun. It's basically what the kernel
will effectively do in "sane behaviour" mode too.

Basically, the kernel really wants to avoid having to compare
individual processes against groups, because behaviour is unclear
then. They want to comapre groups against groups and processes against
processes, but not groups against processes, since in many cases
behaviour is very unclear then. To avoid the ambighities this creates
entirely the answer is to not allow this, and hence always propagate
all controller memberships not only towards the root, but also sideways.

> In our system, some of service have MemoryLimit= options. By this
> options, all of other services also create its own cgroup in memory. In
> mobile system(or some of other embedded system), this can be heavy load.
> 
> If this can be configurable, how about add a configuration for cgroup
> mask propagation to siblings?

The option for this will go away in the kernel too eventually, and we
shouldn't intrdouce an option for behaviour we already know now we
cannot support for long.

I hope this makes some sense,

Lennart

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

Re: [systemd-devel] [PATCH 2/5] udev.pc: install to pkgconfiglibdir

[Kay Sievers]

On Tue, Apr 7, 2015 at 8:54 PM, Marc-Antoine Perennou
 wrote:
> ---
>  Makefile.am | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/Makefile.am b/Makefile.am
> index 9fa4223..9b769ee 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -3725,8 +3725,7 @@ udevconfdir = $(sysconfdir)/udev
>  dist_udevconf_DATA = \
> src/udev/udev.conf
>
> -sharepkgconfigdir = $(datadir)/pkgconfig
> -sharepkgconfig_DATA = \
> +pkgconfiglib_DATA += \
> src/udev/udev.pc

This is all backwards. The systemd.pc file is also in the wrong location.

These GENERIC files are supposed to be found by the primary AND the
secondary arch at the same time, at the GENERIC location, not in a
arch-specific libdir.

How would the 32bit build find this file on a 64bit compat-arch/multilib system?

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

Re: [systemd-devel] fsckd needs to go -- possible compromise?

[Kay Sievers]

On Wed, Apr 8, 2015 at 4:18 PM, Martin Pitt  wrote:
> Lennart Poettering [2015-04-07 16:14 +0200]:
>> Well, the asnc IO socket handling thing was not dealt with. The newest
>> patches still use fgets().
>> [...]
>> The killer issue really is the safety issue. We shouldn't include
>> code in systemd that makes dangerous things like killing running
>> fscks an easily accessible operation, that has a graphical UI and
>> requires no authentication.
>
> So, would you reconsider your position if we address the two things
> above? I. e. replace fgets() by our own async buffering, and entirely
> remove the cancel support? Then we'd still get a proper feedback
> during boot instead of leaving the user in the dark why booting is
> stuck, but it stays noninteractive.

I don't think there is enough justification for a fsck daemon. Large
filesystems which need fsck in userspace are a thing from the past and
insufficiently developed technology for today's operating system
tasks. Basic filesystem consistency and maintenance tasks belong into
the kernel and nowhere else.

We made it just fine into the year 2015 with the support for the
legacy filesystems, and we did not need a specialized daemon so far.
Therefore, we can except that the current level of support will be
sufficient for the coming years. We will support them well enough
until everybody will finally realize that they do not solve the
problems we face today, and that they need to be replaced.

Please keep things like fsckd in the distribution that wants to make
such promises about legacy technology. Systemd upstream should focus
on current and future technologies and not pimp up outdated
facilities, waste our time and and add more complex logic and rules in
the basic boot process.

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

Re: [systemd-devel] Questions about timedatectl and NTP

[Lennart Poettering]

On Wed, 08.04.15 16:11, Jakub Klinkovský (j@gmx.com) wrote:

> On 08.04.15 at 13:18, Lennart Poettering wrote:
> > On Tue, 07.04.15 19:26, Jakub Klinkovský (j@gmx.com) wrote:
> > > After looking at the code more thoroughly, I must say that this commit 
> > > [1] is
> > > not entirely correct and might bring some more confusion. There are two
> > > different states being reported. The (former) "NTP enabled" field refers 
> > > to, as
> > > you say, only the systemd-timesyncd's status, but the "NTP synchronized" 
> > > field
> > > is general, glibc's adjtimex is used to report the status [2].
> > > 
> > > [1]: 
> > > http://cgit.freedesktop.org/systemd/systemd/commit/?id=ff5921bae27b4f3fedb339a3a32dc527c9b3a88c
> > > [2]:
> > > http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/time-util.c#n864
> > 
> > adjtimex is mostly only useful for the NTP sync loop, hence I figured
> > we should continue to call this field NTP.
> 
> That's not what I meant. The man page for 'timedatectl status' currently says:
> 
> Show current settings of the system clock and RTC, including whether
> network time synchronization is enabled. Note that the network time
> synchronization state simply reflects whether the 
> systemd-timesyncd.service
> unit is enabled. ...
> 
> The "time synchronization state" in this context refers to both fields 
> reported
> by timedatectl status, "Network Time on" and "NTP synchronized". I think there
> is more disambiguation needed.

Indeed!

I reworded this sentence a bit now. Please have a look!

> As a nitpick, the example in the man page still shows "NTP enabled" instead of
> "Network Time on" in the timedatectl's output:
> http://cgit.freedesktop.org/systemd/systemd/tree/man/timedatectl.xml#n198

Indeed! Fixed!

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] [PATCH] systemctl: Use logind for --firmware-setup if possible

[Lennart Poettering]

On Wed, 08.04.15 16:49, Jan Janssen (medhe...@web.de) wrote:

Awesome! Thanks!

Applied! (Though I took the liberty to swap the order around, to first
try direct access, and only the fall back via logind.

Thanks,

Lennart

> ---
>  src/systemctl/systemctl.c | 43 ++-
>  1 file changed, 38 insertions(+), 5 deletions(-)
> 
> diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
> index ae87e44..caa8d07 100644
> --- a/src/systemctl/systemctl.c
> +++ b/src/systemctl/systemctl.c
> @@ -2913,6 +2913,41 @@ static int check_inhibitors(sd_bus *bus, enum action 
> a) {
>  #endif
>  }
>  
> +static int prepare_firmware_setup(sd_bus *bus) {
> +int r;
> +_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
> +
> +if (!arg_firmware_setup)
> +return 0;
> +
> +#ifdef HAVE_LOGIND
> +r = sd_bus_call_method(
> +bus,
> +"org.freedesktop.login1",
> +"/org/freedesktop/login1",
> +"org.freedesktop.login1.Manager",
> +"SetRebootToFirmwareSetup",
> +&error,
> +NULL,
> +"b", true);
> +if (r < 0)
> +log_error("Cannot indicate to EFI to boot into setup mode: 
> %s", bus_error_message(&error, r));
> +
> +/* No point trying to fall back. */
> +if (r == -EOPNOTSUPP)
> +return r;
> +#endif
> +
> +if (arg_transport != BUS_TRANSPORT_LOCAL)
> +return log_error_errno(-EINVAL, "Cannot remotely indicate to 
> EFI to boot into setup mode.");
> +
> +r = efi_set_reboot_to_firmware(true);
> +if (r < 0)
> +return log_error_errno(r, "Cannot indicate to EFI to boot 
> into setup mode: %m");
> +
> +return 0;
> +}
> +
>  static int start_special(sd_bus *bus, char **args) {
>  enum action a;
>  int r;
> @@ -2930,11 +2965,9 @@ static int start_special(sd_bus *bus, char **args) {
>  return -EPERM;
>  }
>  
> -if (arg_firmware_setup) {
> -r = efi_set_reboot_to_firmware(true);
> -if (r < 0)
> -return log_error_errno(r, "Cannot indicate to EFI to 
> boot into setup mode: %m");
> -}
> +r = prepare_firmware_setup(bus);
> +if (r < 0)
> +return r;
>  
>  if (a == ACTION_REBOOT && args[1]) {
>  r = update_reboot_param_file(args[1]);
> -- 
> 2.3.5
> 
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel


Lennart

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

Re: [systemd-devel] systemd-resolved service ignores UseDNS=false

[Lennart Poettering]

On Wed, 25.03.15 04:20, Mikhail Morfikov (mmorfi...@gmail.com) wrote:

> In the systemd-resolved manual we can read something like this:
> 
>   The DNS servers contacted are determined from the global settings in
>   resolved.conf(5), the per-link static settings in .network files, and
>   the per-link dynamic settings received over DHCP.
> 
> 1. Let's say that I have set all the three settings, which one will be
> applied?

Per-interface DHCP acquired DNS servers take precedence over manually
configured per-interface DHCP servers.

Global settings are used only if no per-interface DNS server settings
are known.

> 2. If I set the global settings via the /etc/systemd/resolved.conf file,
> for instance:
> 
> [Resolve]
> DNS=127.0.2.1
> FallbackDNS=208.67.222.222 208.67.220.220
> 
> will this local resolver be used all the time, even when dhcp
> server sends an ip address of other resolver in the network to
> the client?

No. It is only used if no per-interface DNS servers are known. They
always take precedence.

In this case FallbackDNS= is without effect, since it is only used if no
other DNS servers is configured. In fact FallbackDNS= only makes sense
if you leave DNS= empty in which case it is read from
/etc/resolv.conf instead. In that case FallbackDNS= is used when
/etc/resolv.conf is missing or contains no entries.

> So UseDNS is set to false, and I thought the system will be using
> the local resolver, but it sometimes uses the local settings and
> sometimes not -- it depends on restarting the systemd-resolved
> service, for example:

You need to set UseDNS= to false and DNS= to the empty list in the
interface file. 

Use "networkctl status -a" to check which per-interface DNS servers
are being used.

> # ls -al /etc/resolv.conf
> lrwxrwxrwx 1 root root 32 2015-02-27 23:52:39 /etc/resolv.conf -> 
> /run/systemd/resolve/resolv.conf
> 
> # cat /etc/resolv.conf
> nameserver 127.0.2.1
> nameserver 192.168.1.1
> search mhouse.lh
> 
> # systemctl restart systemd-resolved.service
> # cat /etc/resolv.conf
> nameserver 192.168.1.1
> nameserver 127.0.2.1
> search mhouse.lh
> 
> (I've cut the comments for readability)

Ah, this is actually a bug. The order wasn't stable. I fixed that now:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=822db23cfa98a9fbc48f41e11caafb6f1017e052

> 3. Shouldn't there be just one resolver in the /etc/resolv.conf
> file?

We write the global servers out first, followed by the per-interface ones.

> 4. How to force the system to use the one particular resolver no matter
> what? I know I could probably do that by creating a static file instead
> of a link (and maybe chattr +i if necessary), but I want to do this
> using the systemd native tools if that is possible of course.

Turn off UseDNS= for all interfaces and set DNS= for them to the empty string.

> 5. Is the /etc/resolv.conf file necessary  when using systemd?

Nope. Not if you list "resolve" instead of "dns" in your nsswitch.conf.

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] systemctl: Use logind for --firmware-setup if possible

[Jan Janssen]

---
 src/systemctl/systemctl.c | 43 ++-
 1 file changed, 38 insertions(+), 5 deletions(-)

diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index ae87e44..caa8d07 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -2913,6 +2913,41 @@ static int check_inhibitors(sd_bus *bus, enum action a) {
 #endif
 }
 
+static int prepare_firmware_setup(sd_bus *bus) {
+int r;
+_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
+
+if (!arg_firmware_setup)
+return 0;
+
+#ifdef HAVE_LOGIND
+r = sd_bus_call_method(
+bus,
+"org.freedesktop.login1",
+"/org/freedesktop/login1",
+"org.freedesktop.login1.Manager",
+"SetRebootToFirmwareSetup",
+&error,
+NULL,
+"b", true);
+if (r < 0)
+log_error("Cannot indicate to EFI to boot into setup mode: 
%s", bus_error_message(&error, r));
+
+/* No point trying to fall back. */
+if (r == -EOPNOTSUPP)
+return r;
+#endif
+
+if (arg_transport != BUS_TRANSPORT_LOCAL)
+return log_error_errno(-EINVAL, "Cannot remotely indicate to 
EFI to boot into setup mode.");
+
+r = efi_set_reboot_to_firmware(true);
+if (r < 0)
+return log_error_errno(r, "Cannot indicate to EFI to boot into 
setup mode: %m");
+
+return 0;
+}
+
 static int start_special(sd_bus *bus, char **args) {
 enum action a;
 int r;
@@ -2930,11 +2965,9 @@ static int start_special(sd_bus *bus, char **args) {
 return -EPERM;
 }
 
-if (arg_firmware_setup) {
-r = efi_set_reboot_to_firmware(true);
-if (r < 0)
-return log_error_errno(r, "Cannot indicate to EFI to 
boot into setup mode: %m");
-}
+r = prepare_firmware_setup(bus);
+if (r < 0)
+return r;
 
 if (a == ACTION_REBOOT && args[1]) {
 r = update_reboot_param_file(args[1]);
-- 
2.3.5

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

Re: [systemd-devel] Question about relationship between systemd v219 and kernel version.

[ChangKeun Im]

Thanks for advice.
I will check git log of README to see the history.

Changkeun Im(임창근)



2015-04-08 19:30 GMT+09:00 Lennart Poettering :

> On Tue, 07.04.15 17:41, Dimitri John Ledkov (dimitri.j.led...@intel.com)
> wrote:
>
> > On 6 April 2015 at 01:12, Lennart Poettering 
> wrote:
> > > On Mon, 06.04.15 06:17, 임창근 (ck21...@samsung.com) wrote:
> > >
> > >> Hello EveryOne.
> > >>
> > >> I wonder that If I use kernel v3.4 with systemd v219, systemd-run
> function is work or not.
> > >> Because My target have kernel v3.4 and systemd v216.
> > >
> > > Please check the README shipped in the tarball, it always lists the
> > > minimal kernel version systemd requires. For 219 the minimal kernel
> > > version is 3.7.
> >
> > I was meant to ask a while back, would it be possible to have degraded
> > systemd for lower kernels? Quite a few current Android-like phones
> > will be stuck on 3.4 forever, e.g. those that are shipping SailfishOS
> > / Ubuntu for Phones / etc. Thus support for 3.4 is desirable to be
> > maintained, because of the Android phones.
>
> The last time the kernel requirement was bumped because firmware
> loading support was dropped from systemd. Kernel 3.7 gained support
> for in-kernel loading. Supporting older kernels would hence mean
> readding that code to udev, and that's just not going to happen...
>
> If you don't need firmware loading I think there's a good chance that
> systemd will just work on older kernels. YMMV.
>
> Check the git log of README to see the history how the kernel
> requirement was bumped, and why.
>
> Lennart
>
> --
> Lennart Poettering, Red Hat
> ___
> 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] fsckd needs to go -- possible compromise?

[Martin Pitt]

Hello all,

Lennart Poettering [2015-04-07 16:14 +0200]:
> Well, the asnc IO socket handling thing was not dealt with. The newest
> patches still use fgets().
> [...]
> The killer issue really is the safety issue. We shouldn't include
> code in systemd that makes dangerous things like killing running
> fscks an easily accessible operation, that has a graphical UI and
> requires no authentication.

So, would you reconsider your position if we address the two things
above? I. e. replace fgets() by our own async buffering, and entirely
remove the cancel support? Then we'd still get a proper feedback
during boot instead of leaving the user in the dark why booting is
stuck, but it stays noninteractive.

Thanks,

Martin

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

Re: [systemd-devel] [PATCH v2] journalctl: Improve boot ID lookup

[Jan Janssen]

On 2015-04-08 14:39, Lennart Poettering wrote:

On Thu, 02.04.15 17:08, Jan Janssen (medhe...@web.de) wrote:


This method should greatly improve offset based lookup. We now don't have
to aggregate the full boot listing just so we can jump to a specific position,
which can be a real pain on big journals just for a mere "-b -1" case.

As an additional benefit --list-boots should improve slightly too, because
we now need to do less seeking.

Note that there can be a change in boot order with this lookup method
because it will use the order of boots in the journal, not the realtime stamp
stored in them. That's arguably better, though.

https://bugs.freedesktop.org/show_bug.cgi?id=72601
---
Hi,

today I realized that it would be nice if we could do without the cursor 
seeking.
Turns out we can! I could swear that I tested sd_journal_flush_matches() would
reset our position in the journal. But it seems that sd_journal_next/previous
will advance just fine from the last position we were in, even after a flush.

Though, I would still like someone with better journal internals knowledge 
confirm
that this is how it's supposed to work.

Some testing/timing from others than me would be nice too.


Hmm, the patch is hard to read, can you explain what precisely the new
algorithm is you propose?

Lennart



Yeah, patches like these always do end up looking messy. It's much 
easier to read after applying it.


Well, it jumps from one boot to the next boot using _BOOT_ID matches. It 
starts at the journal head to get the boot ID, makes a _BOOT_ID match 
and then comes from the opposite journal direction (tail) to get the end 
a boot. And then flushes the matches, and advances the journal from that 
exact position one further (which gives us the start and ID of our next 
boot). Rinse and repeat.
Note, v1 differs in that it assumes sd_journal_flush_matches() will also 
reset the position we are in the journal at that moment. That version 
went around that by using a cursor and seeking to the after flushing. 
Hence why I wonder if this behavior of slush_matches is expected/desired 
or not.


This is much faster for relative boot ID lookups, for the very reason 
that you don't have to look at all boots. Though, it does make the 
assumption that all boots (IDs) are assumed to not interleave 
(constellations like "A B A C" cannot happen), which afaik would be 
satisfied on single host machines.


Later after sending this patch I realized that it could probably break 
on journals with more than one machine ID, since then boot IDs can 
interleave due to them running in parallel, breaking a important 
assumption. Though, I *should* be able to fix that by adding some 
_MACHINE_ID matches in the mix.


Adding machine ID matches would make --list-boots behavior differ quite 
a lot. For one, with this approach, there isn't any global ordering of 
boots across machine IDs. Personally, I find this ordering (although you 
can define it as *a* valid ordering) to be useless. Doing a "journalctl 
-b boodID-1" match, for example, should use that bootID's machine ID to 
get to the previous boot (of that machine). Right now it can get you any 
bootID from any other machine, so long as it was booted right before it.


So yeah, I will make this patch work for journals with more than one 
machine ID if this approach is desired.


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

Re: [systemd-devel] Questions about timedatectl and NTP

[Jakub Klinkovský]

On 08.04.15 at 13:18, Lennart Poettering wrote:
> On Tue, 07.04.15 19:26, Jakub Klinkovský (j@gmx.com) wrote:
> > After looking at the code more thoroughly, I must say that this commit [1] 
> > is
> > not entirely correct and might bring some more confusion. There are two
> > different states being reported. The (former) "NTP enabled" field refers 
> > to, as
> > you say, only the systemd-timesyncd's status, but the "NTP synchronized" 
> > field
> > is general, glibc's adjtimex is used to report the status [2].
> > 
> > [1]: 
> > http://cgit.freedesktop.org/systemd/systemd/commit/?id=ff5921bae27b4f3fedb339a3a32dc527c9b3a88c
> > [2]:
> > http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/time-util.c#n864
> 
> adjtimex is mostly only useful for the NTP sync loop, hence I figured
> we should continue to call this field NTP.

That's not what I meant. The man page for 'timedatectl status' currently says:

Show current settings of the system clock and RTC, including whether
network time synchronization is enabled. Note that the network time
synchronization state simply reflects whether the systemd-timesyncd.service
unit is enabled. ...

The "time synchronization state" in this context refers to both fields reported
by timedatectl status, "Network Time on" and "NTP synchronized". I think there
is more disambiguation needed.

As a nitpick, the example in the man page still shows "NTP enabled" instead of
"Network Time on" in the timedatectl's output:
http://cgit.freedesktop.org/systemd/systemd/tree/man/timedatectl.xml#n198

-- 
Jakub Klinkovský


pgpCA5eOGgIA3.pgp
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd unit checker tool

[Zbigniew Jędrzejewski-Szmek]

On Wed, Apr 08, 2015 at 03:11:55PM +0200, Przemyslaw Kedzierski wrote:
> On 04/07/2015 07:02 PM, Zbigniew Jędrzejewski-Szmek wrote:
> >On Tue, Apr 07, 2015 at 12:36:31PM -0400, Rahul Sundaram wrote:
> 
> >>Perhaps packaging guidelines should recommend running this command or it
> >>should be part of the macro that packages include that logs warnings when
> >>unit files has any of these issues
> >
> 
> We are interested in a tool that could be run automatically,
> like rpmlint, at finish of build process.
OK, I guess I wasn't clear: current systemd-analyze verify can
be run automatically, but the output cannot be used to automatically
reject a unit.

> It could read and check unit files from one service alone or in
> context of all of them. This should be controlled by options.
> There will be defined a set of rules, for both methods

> Of course should be configurable the source of unit files used to
> build a graph - currently installed in build system, from other
> rpm's,
> maybe from image? (what to do if target systemd will be too new than
> running on build system)
> 
> Is there only possible to check typos and syntax errors in case of
> testing single unit file?
> For example, problems like these: 
> http://lists.freedesktop.org/archives/systemd-devel/2011-March/001800.html

Not currently, but I'm sure this could be added without much hassle.

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

Re: [systemd-devel] systemd unit checker tool

[Przemyslaw Kedzierski]

On 04/07/2015 07:02 PM, Zbigniew Jędrzejewski-Szmek wrote:

On Tue, Apr 07, 2015 at 12:36:31PM -0400, Rahul Sundaram wrote:



Perhaps packaging guidelines should recommend running this command or it
should be part of the macro that packages include that logs warnings when
unit files has any of these issues




We are interested in a tool that could be run automatically,
like rpmlint, at finish of build process.
It could read and check unit files from one service alone or in context 
of all of them. This should be controlled by options.

There will be defined a set of rules, for both methods

Of course should be configurable the source of unit files used to build 
a graph - currently installed in build system, from other rpm's,
maybe from image? (what to do if target systemd will be too new than 
running on build system)


Is there only possible to check typos and syntax errors in case of 
testing single unit file?
For example, problems like these: 
http://lists.freedesktop.org/archives/systemd-devel/2011-March/001800.html


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

Re: [systemd-devel] [PATCH v2] journalctl: Improve boot ID lookup

[Lennart Poettering]

On Thu, 02.04.15 17:08, Jan Janssen (medhe...@web.de) wrote:

> This method should greatly improve offset based lookup. We now don't have
> to aggregate the full boot listing just so we can jump to a specific position,
> which can be a real pain on big journals just for a mere "-b -1" case.
> 
> As an additional benefit --list-boots should improve slightly too, because
> we now need to do less seeking.
> 
> Note that there can be a change in boot order with this lookup method
> because it will use the order of boots in the journal, not the realtime stamp
> stored in them. That's arguably better, though.
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=72601
> ---
> Hi,
> 
> today I realized that it would be nice if we could do without the cursor 
> seeking.
> Turns out we can! I could swear that I tested sd_journal_flush_matches() would
> reset our position in the journal. But it seems that sd_journal_next/previous
> will advance just fine from the last position we were in, even after a flush.
> 
> Though, I would still like someone with better journal internals knowledge 
> confirm
> that this is how it's supposed to work.
> 
> Some testing/timing from others than me would be nice too.

Hmm, the patch is hard to read, can you explain what precisely the new
algorithm is you propose?

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] Questions about timedatectl and NTP

[Lennart Poettering]

On Tue, 07.04.15 19:26, Jakub Klinkovský (j@gmx.com) wrote:

> On 07.04.15 at 16:40, Lennart Poettering wrote:
> > On Sun, 05.04.15 13:25, Jakub Klinkovský (j@gmx.com) wrote:
> > 
> > > As per systemd 216 NEWS [1], alternative NTP implementations should add
> > > Conflicts=systemd-timesyncd.service to be recognized by systemd, which
> > > ntpd.service on Arch Linux does. But still, active ntpd.service does not 
> > > seem
> > > to be recognized by timedatectl:
> > 
> > Correct, timedatectl only shows systemd-timesyncd's status now. I have
> > now updated the man page to clarify this.
> 
> After looking at the code more thoroughly, I must say that this commit [1] is
> not entirely correct and might bring some more confusion. There are two
> different states being reported. The (former) "NTP enabled" field refers to, 
> as
> you say, only the systemd-timesyncd's status, but the "NTP synchronized" field
> is general, glibc's adjtimex is used to report the status [2].
> 
> [1]: 
> http://cgit.freedesktop.org/systemd/systemd/commit/?id=ff5921bae27b4f3fedb339a3a32dc527c9b3a88c
> [2]:
> http://cgit.freedesktop.org/systemd/systemd/tree/src/shared/time-util.c#n864

adjtimex is mostly only useful for the NTP sync loop, hence I figured
we should continue to call this field NTP.

> > Hmm, I have now renamed this in the man page and the output to
> > "network time synchronization", to disconnect this a bit from the
> > low-level technology, and as a side-effect hopefully removing the
> > confusion with the classic ntp package.
> 
> I agree with using "network time synchronization" in the man page, but can we
> make it "timesyncd enabled" (or similar) instead of "Network Time on" in the
> timedatectl's output? The idea is to refer explicitly to systemd-timesyncd in
> order to avoid confusion with every other network time syncing tool, not only
> ntpd.

I'd like to leave this as a documentation detail. If people run more
complex NTP implementations they should really know what they are
doing anyway...

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] fsckd needs to go

[Lennart Poettering]

On Wed, 08.04.15 13:03, Reindl Harald (h.rei...@thelounge.net) wrote:

> >>https://bugzilla.redhat.com/show_bug.cgi?id=1105877
> >
> >Hmm? i don't understand what that bug is about? Is it about /forcefsck
> >being ignored?
> 
> it is about "warning: checktime reached, running e2fsck is recommended" but
> the check didn't happen and that you *need* to "touch /forcefsck" while it
> should happen automatically

OK, reassigned to the kernel. it's somewhere between the kernel ane
e2fsck to figure this out. We will always call fsck, it's up to fsck
to do something, and if it decides not to, then it would needs to say
why, and get the kernel in sync...

> >And what does this bug have to do with systemd?
> 
> i don't get your reasoning for "Maybe the right fix for Ubuntu is to stop
> enabling the "routine" check logic?" because as seen a few months ago this
> routine check is important, otherwise you may not notice existing corruption
> (for whatever reason) until it is too late

Well, the file system folks at RH decided this makes no sense long
ago, please bring this up with them. Also note that the change RH was
carrying a long time is now upstream (see Martin's link), hence bring
this up with them.

systemd is not involved in this.

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] fsckd needs to go

[Reindl Harald]

Am 08.04.2015 um 12:48 schrieb Lennart Poettering:

On Wed, 08.04.15 12:31, Reindl Harald (h.rei...@thelounge.net) wrote:




Am 08.04.2015 um 12:27 schrieb Lennart Poettering:

Well, the routine check is only done by Ubuntu/Debian, it is not
enabled on any enterprise distro or on Fedora. Maybe Ubuntu/Debian
should also turn this off?

Note that the routine check is not different than a normal check
really, it just is triggered by a mount counter instead of a dirty
flag, that's all. Hence it makes little difference what you cancel,
both is dangerous, and a bad idea to allow unauthenticated.

Also, to my knowledge plymouth on Ubuntu never showed a different UI
for both cases, did it? How is the admin supposed to know when it is
just dangerous to cancel the fsck (in your "routine" check case), and
when it is extra dangerous (in the non-"routine" check case)?

Maybe the right fix for Ubuntu is to stop enabling the "routine" check
logic?


why would you want to disable it?

short before christmas i had a faulty ext4 FS needing even manual
confirmation of repairs - i don't think it's a good idea to not trigger that
automatically and frankly it *should have been* triggered that way

https://bugzilla.redhat.com/show_bug.cgi?id=1105877


Hmm? i don't understand what that bug is about? Is it about /forcefsck
being ignored?


it is about "warning: checktime reached, running e2fsck is recommended" 
but the check didn't happen and that you *need* to "touch /forcefsck" 
while it should happen automatically



And what does this bug have to do with systemd?


i don't get your reasoning for "Maybe the right fix for Ubuntu is to 
stop enabling the "routine" check logic?" because as seen a few months 
ago this routine check is important, otherwise you may not notice 
existing corruption (for whatever reason) until it is too late




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

Re: [systemd-devel] [PATCH 2/2] missing.h: Define IFA_F_NOPREFIXROUTE

[Lennart Poettering]

On Tue, 07.04.15 23:05, Alexander Sverdlin (alexander.sverd...@gmail.com) wrote:

> IFA_F_NOPREFIXROUTE is a usual #define appeared in Linux 3.14, so 
> AC_CHECK_DECLS
> is not necessary

Applied! THanks!

> ---
> 
> Fixes second systemd compilation problem against Linux 3.12 uapi headers.
> 
>  src/shared/missing.h | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/src/shared/missing.h b/src/shared/missing.h
> index 86c917b..e029167 100644
> --- a/src/shared/missing.h
> +++ b/src/shared/missing.h
> @@ -866,6 +866,10 @@ static inline int setns(int fd, int nstype) {
>  #define IFA_MAX (__IFA_MAX - 1)
>  #endif
> 
> +#ifndef IFA_F_NOPREFIXROUTE
> +#define IFA_F_NOPREFIXROUTE 0x200
> +#endif
> +
>  #ifndef MAX_AUDIT_MESSAGE_LENGTH
>  #define MAX_AUDIT_MESSAGE_LENGTH 8970
>  #endif
> 


Lennart

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

Re: [systemd-devel] [PATCH 1/2] Update IFA_MAX adding IFA_FLAGS

[Lennart Poettering]

On Tue, 07.04.15 23:05, Alexander Sverdlin (alexander.sverd...@gmail.com) wrote:

> Fixes the following compilation problem:
> src/libsystemd/sd-rtnl/rtnl-types.c:361:9: error: array index in initializer 
> exceeds array bounds
>  [IFA_FLAGS] = { .type = NLA_U32 },
>  ^
> src/libsystemd/sd-rtnl/rtnl-types.c:361:9: error: (near initialization for 
> 'rtnl_address_types')
> 
> Also include if_addr.h into missing.h so that it's possible to
> redefine __IFA_MAX.

I feel a bit uneasy about changing definitions from the header
files. Adding is fine, but altering them is something we should be
carefuly with. Hence I commited a different fix now:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=de79f906ab614dd0d53129c4d4aa18a964864f39

Please test!

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] fsckd needs to go

[Lennart Poettering]

On Wed, 08.04.15 12:31, Reindl Harald (h.rei...@thelounge.net) wrote:

> 
> 
> Am 08.04.2015 um 12:27 schrieb Lennart Poettering:
> >Well, the routine check is only done by Ubuntu/Debian, it is not
> >enabled on any enterprise distro or on Fedora. Maybe Ubuntu/Debian
> >should also turn this off?
> >
> >Note that the routine check is not different than a normal check
> >really, it just is triggered by a mount counter instead of a dirty
> >flag, that's all. Hence it makes little difference what you cancel,
> >both is dangerous, and a bad idea to allow unauthenticated.
> >
> >Also, to my knowledge plymouth on Ubuntu never showed a different UI
> >for both cases, did it? How is the admin supposed to know when it is
> >just dangerous to cancel the fsck (in your "routine" check case), and
> >when it is extra dangerous (in the non-"routine" check case)?
> >
> >Maybe the right fix for Ubuntu is to stop enabling the "routine" check
> >logic?
> 
> why would you want to disable it?
> 
> short before christmas i had a faulty ext4 FS needing even manual
> confirmation of repairs - i don't think it's a good idea to not trigger that
> automatically and frankly it *should have been* triggered that way
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1105877

Hmm? i don't understand what that bug is about? Is it about /forcefsck
being ignored? And what does this bug have to do with systemd?

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] fsckd needs to go

[Martin Pitt]

Lennart Poettering [2015-04-08 12:27 +0200]:
> Maybe the right fix for Ubuntu is to stop enabling the "routine" check
> logic? 

This already happened a while ago, through

  http://git.whamcloud.com/tools/e2fsprogs.git/commitdiff/3daf592646

So this indeed only affects older/upgraded installations.

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] fsckd needs to go

[Reindl Harald]

Am 08.04.2015 um 12:27 schrieb Lennart Poettering:

Well, the routine check is only done by Ubuntu/Debian, it is not
enabled on any enterprise distro or on Fedora. Maybe Ubuntu/Debian
should also turn this off?

Note that the routine check is not different than a normal check
really, it just is triggered by a mount counter instead of a dirty
flag, that's all. Hence it makes little difference what you cancel,
both is dangerous, and a bad idea to allow unauthenticated.

Also, to my knowledge plymouth on Ubuntu never showed a different UI
for both cases, did it? How is the admin supposed to know when it is
just dangerous to cancel the fsck (in your "routine" check case), and
when it is extra dangerous (in the non-"routine" check case)?

Maybe the right fix for Ubuntu is to stop enabling the "routine" check
logic?


why would you want to disable it?

short before christmas i had a faulty ext4 FS needing even manual 
confirmation of repairs - i don't think it's a good idea to not trigger 
that automatically and frankly it *should have been* triggered that way


https://bugzilla.redhat.com/show_bug.cgi?id=1105877



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] Question about relationship between systemd v219 and kernel version.

[Lennart Poettering]

On Tue, 07.04.15 17:41, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote:

> On 6 April 2015 at 01:12, Lennart Poettering  wrote:
> > On Mon, 06.04.15 06:17, 임창근 (ck21...@samsung.com) wrote:
> >
> >> Hello EveryOne.
> >>
> >> I wonder that If I use kernel v3.4 with systemd v219, systemd-run function 
> >> is work or not.
> >> Because My target have kernel v3.4 and systemd v216.
> >
> > Please check the README shipped in the tarball, it always lists the
> > minimal kernel version systemd requires. For 219 the minimal kernel
> > version is 3.7.
> 
> I was meant to ask a while back, would it be possible to have degraded
> systemd for lower kernels? Quite a few current Android-like phones
> will be stuck on 3.4 forever, e.g. those that are shipping SailfishOS
> / Ubuntu for Phones / etc. Thus support for 3.4 is desirable to be
> maintained, because of the Android phones.

The last time the kernel requirement was bumped because firmware
loading support was dropped from systemd. Kernel 3.7 gained support
for in-kernel loading. Supporting older kernels would hence mean
readding that code to udev, and that's just not going to happen...

If you don't need firmware loading I think there's a good chance that
systemd will just work on older kernels. YMMV. 

Check the git log of README to see the history how the kernel
requirement was bumped, and why.

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] fsckd needs to go

[Lennart Poettering]

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

> Reindl Harald [2015-04-08 10:32 +0200]:
> > nobody needs to ability to cancel a fsck because hardly anybody has a
> > insight if the moment doing so is horrible dangerous and givne that fsck
> > don't run for fun why would you want to interrupt it and risk data loss?
> 
> You don't risk data loss by interrupting a routine check (that still
> happens on ext[234] every so often).

Well, the routine check is only done by Ubuntu/Debian, it is not
enabled on any enterprise distro or on Fedora. Maybe Ubuntu/Debian
should also turn this off?

Note that the routine check is not different than a normal check
really, it just is triggered by a mount counter instead of a dirty
flag, that's all. Hence it makes little difference what you cancel,
both is dangerous, and a bad idea to allow unauthenticated.

Also, to my knowledge plymouth on Ubuntu never showed a different UI
for both cases, did it? How is the admin supposed to know when it is
just dangerous to cancel the fsck (in your "routine" check case), and
when it is extra dangerous (in the non-"routine" check case)?

Maybe the right fix for Ubuntu is to stop enabling the "routine" check
logic? 

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] fsckd needs to go

[Lennart Poettering]

On Tue, 07.04.15 18:02, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote:

> On 3 April 2015 at 05:58, Lennart Poettering  wrote:
> > Heya,
> >
> > so we discussed the whole fsckd situation a bit more here in Berlin,
> > and we came to the conclusion that fsckd really should not exist the
> > way it does in systemd.
> >
> > To start with, the code is really wrong, it should never have been
> > merged in its current state, the read/write logic for the sockets is
> > completely borked (I cannot even boot my own machine reliably with
> > it!). And to my knowledge there has been no attempt to fix all of
> > that, even though I asked for it. It also doesn't do at all what I
> > suggested initially, as the flow of data is now fsck → systemd-fsck →
> > systemd-fsckd → plymouth, and that's just crazy, that's two steps too
> > many. systemd is supposed to be a few components playing well
> > together, but certainly not a baroque network of components where data
> > is passed though four hoops before it reaches the destination...
> >
> > Then, there's my general reservation with fsckd at all: file systems
> > that still require offline fsck are certainly not the future, but we
> > develop stuff for the future, and the idea to kill an fsck process
> > while it is running is also very very questionnable. There's a reason
> 
> Is this about progress & control data or all things fsck?

Well, ext234 require fsck, there's no way around it. We need to call
it, and we will. But the idea of beefing this up with an UI and
specifically with an unauthenticated way to kill fsck while it is
ongoing, which is an inherently unsafe operation, is what I have
issues with.

> IMHO we do need to continue support ext4, and running fsck.ext4 when
> enforced, at least from initramfs, with progress output to the user
> and ability to cancel. Or is even fsck.ext4 obsolete these days and
> shouldn't be run automatically any more?

Nope. ext2, ext3, ext4, fat require an fsck tool to be run, and we
will.

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] recent udev dependency change delays plymouth and udev

[Lennart Poettering]

On Tue, 07.04.15 18:10, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote:

> On 2 April 2015 at 00:39, Martin Pitt  wrote:
> > Hello all,
> >
> > The recent commit
> > http://cgit.freedesktop.org/systemd/systemd/commit/?id=d99ce933 (which
> > also made it into v219-stable at
> > http://cgit.freedesktop.org/systemd/systemd-stable/commit/?h=v219-stable&id=b238b0eaf71)
> > fixed a typo in udevd's dependencies, which now results in udev
> > waiting for systemd-hwdb-update.service.
> >
> > While this is certainly "correct" especially for stateless systems, it
> > is quite a bit inconvenient as it now causes a long dependency chain:
> >
> > plymouth-start.service → systemd-udevd.service → 
> > systemd-hwdb-update.service →
> > systemd-remount-fs.service → systemd-fsck-root.service → 
> > systemd-fsckd.socket
> >
> 
> I dislike building hwdb on boot, thus locally I make sure that update
> mechanisms have up to date @udevlibexecdir@/hwdb.bin and thus
> systemd-hwdb-update.service is not run.
> 
> If triggers rebuild the database, shouldn't the update-process /
> conditions be modified such that the database is not rebuild on boot?

Hmm? I cannot parse this?

The hwdb rebuild is only done at boot if /etc/.updated is older than
/usr, or non-existant. If your distro upgrade routine updates /etc in
full before rebooting, you can just touch that file afterrwards, and
the service will not trigger...

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 debug blocking service start?

[Lennart Poettering]

On Wed, 08.04.15 10:31, Kai Hendry (hen...@webconverger.com) wrote:

> 
> 
> On Tue, 7 Apr 2015, at 11:13 PM, Lennart Poettering wrote:
> > What does "networkctl status" say when this happens? And "networkctl
> > status -a"?
> 
> Oooh, I love those commands. Here is the output which says I'm routable:
> 
> http://s.natalian.org/2015-04-08/networkctl.txt
> 
> 
> Maybe all of this has something to do with the way I've setup
> systemd-networkd. I have dejavu now... quite possibly this all is
> related to:
> https://bugs.freedesktop.org/show_bug.cgi?id=89352

When you turn on debug logging for networkd, do you see what it is
doing on that "configuring" interface?

Normally, networkd should care for that interface only if there is a
carrier on it, which it isn't here...

Tom, maybe you got an idea?

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] Question about relationship between systemd v219 and kernel version.

[Greg KH]

On Wed, Apr 08, 2015 at 08:59:40AM +, "Jóhann B. Guðmundsson" wrote:
> 
> 
> On 04/08/2015 06:53 AM, Greg KH wrote:
> >"all"?  Ubuntu ships newer kernels than 3.4, if not, please take it up
> >with that vendor, it's not the community's job to support obsolete,
> >years-old software that everyone has moved on from a long time ago for
> >very good reasons.
> 
> Hmm there has to be some fundamental reason why vendors keep sticking with
> old out date kernels and cant move or be nudged forwardwith the rest of the
> world by the community and it's processes  which begs the question if the
> LTSI process flawed or simply not working which might be due to...
> 
> Too many long term kernel releases in circulations?

Hah, no, companies keep wanting me to do more releases, to do their work
for them for free:(

> The lifecycle of the long term kernel releases?

2 years isn't long enough for something that is given to them "for
free"?  If not, then please pay an engineer to do the work.

> Too many invasive changes between kernel release?

No.

> Too many regressions between kernel release?

Nope.

The real reason is embedded companies not getting their patches
upstream, so it's their fault it is a lot of work to move to new kernel
releases.  For companies that do get their work merge, moving to a new
kernel is a trivial exercise.

> Bidirectional communication between vendors and the kernel community ( which
> might prevent the necessary adjustment to long term kernel/LTSi etc. )

Am I really not talking to enough people / companies?  If not, please
let me know who I should be talking to.  A week doesn't go by that I'm
not in contact with some company about this topic, I'm not working blind
here at all.

thanks,

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

Re: [systemd-devel] Question about relationship between systemd v219 and kernel version.

[Jóhann B. Guðmundsson]

On 04/08/2015 06:53 AM, Greg KH wrote:

"all"?  Ubuntu ships newer kernels than 3.4, if not, please take it up
with that vendor, it's not the community's job to support obsolete,
years-old software that everyone has moved on from a long time ago for
very good reasons.


Hmm there has to be some fundamental reason why vendors keep sticking 
with old out date kernels and cant move or be nudged forwardwith the 
rest of the world by the community and it's processes  which begs the 
question if the LTSI process flawed or simply not working which might be 
due to...


Too many long term kernel releases in circulations?

The lifecycle of the long term kernel releases?

Too many invasive changes between kernel release?

Too many regressions between kernel release?

Bidirectional communication between vendors and the kernel community ( 
which might prevent the necessary adjustment to long term kernel/LTSi 
etc. )


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

Re: [systemd-devel] fsckd needs to go

[Martin Pitt]

Reindl Harald [2015-04-08 10:32 +0200]:
> nobody needs to ability to cancel a fsck because hardly anybody has a
> insight if the moment doing so is horrible dangerous and givne that fsck
> don't run for fun why would you want to interrupt it and risk data loss?

You don't risk data loss by interrupting a routine check (that still
happens on ext[234] every so often).

But anyway, I don't mind much dropping the cancel ability, but we do
want a proper progress report. fsck can take an effing long time with
large spinning rust, and without progress report users will just
consider the boot hanging/broken and switch off the machine. That's a
lot riskier :-)

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


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

Re: [systemd-devel] fsckd needs to go

[Reindl Harald]

Am 08.04.2015 um 03:02 schrieb Dimitri John Ledkov:

Is this about progress & control data or all things fsck?

IMHO we do need to continue support ext4, and running fsck.ext4 when
enforced, at least from initramfs, with progress output to the user
and ability to cancel


nobody needs to ability to cancel a fsck because hardly anybody has a 
insight if the moment doing so is horrible dangerous and givne that fsck 
don't run for fun why would you want to interrupt it and risk data loss?




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

Re: [systemd-devel] [PATCH 1/3] sd-rtnl: Always enable IFA_FLAGS

[Patrik Flykt]

On Tue, 2015-04-07 at 21:13 +0200, Alexander Sverdlin wrote:
> But if the backend code for this flag appears first in Linux 3.14
> (https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=479840ffdbe4),
> working around the compilation issue (against older uapi headers) will
> not help with the fact that networkd will fail in 851c9f82736
> (systemd-networkd: Use IFA_F_NOPREFIXROUTE with IPv6 addresses)?

I'll fix that logic now that compilation works.

Cheers,

Patrik


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