Re: [systemd-devel] Factoring out initctl support

[Daniel Mack]

On 04/27/2016 12:29 AM, Felipe Sateler wrote:
> On Tue, 26 Apr 2016 17:28:34 +0200, Daniel Mack wrote:
> 
>> Hi Michael,
>>
>> On 04/15/2016 11:00 PM, Daniel Mack wrote:
>>> On 04/15/2016 10:47 PM, Michael Biebl wrote:
>>
>>> Including the built results of systemd-initctl into your .deb packet is
>>> not a solution? Making that an extra package causes too much trouble, I
>>> totally agree.
>>
>> Did you further think about this idea, would that be a solution?
> 
> I'm not sure I understood your proposal correctly, but each .deb package 
> is built from one source package. This implies that systemd-initctl 
> source would have to be somehow imported into the debian systemd source, 

Well, yes. At the same time when downstream patches are applied.

> and then used to build the shipped binary (ie, not importing the binary 
> artifacts alone).

I'm not sure if it's feasible, hence I'm asking.


Daniel

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

Re: [systemd-devel] Factoring out initctl support

[Daniel Mack]

Hi Michael,

On 04/15/2016 11:00 PM, Daniel Mack wrote:
> On 04/15/2016 10:47 PM, Michael Biebl wrote:

> Including the built results of systemd-initctl into your .deb packet is
> not a solution? Making that an extra package causes too much trouble, I
> totally agree.

Did you further think about this idea, would that be a solution?


Thanks,
Daniel

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

Re: [systemd-devel] Factoring out initctl support

[Daniel Mack]

On 04/15/2016 10:47 PM, Michael Biebl wrote:
> 2016-04-15 19:33 GMT+02:00 Daniel Mack <dan...@zonque.org>:
>> On 04/15/2016 07:03 PM, Mike Gilbert wrote:
>>> On Fri, Apr 15, 2016 at 11:43 AM, Daniel Mack <dan...@zonque.org> wrote:
>>>> On 04/15/2016 03:55 PM, Mike Gilbert wrote:
>>
>>>>> I'm happy to move it if others want to utilize it. I will need someone
>>>>> to set me up with access to push the code, however.
>>>>
>>>> Great, will do. What's your GitHub handle?
>>>
>>> I'm floppym on github.
>>>
>>
>> Thanks - you're now the admin of this new repository:
>>
>>   https://github.com/systemd/systemd-initctl/
>>
>> I'm happy to push the client code there once you migrated the project.
>>
>>
>> However, I'd still like to have an Ack from Michael Biebl on the
>> downstream integration of this new repository.
> 
> Well, I guess I already explained our situation. We still need
> /dev/initctl in Debian, so ripping that out means we have to provide
> that some other way.
> I'm not sure if a separate package (large overhead) or simply
> reverting the removal is the better option here.

Including the built results of systemd-initctl into your .deb packet is
not a solution? Making that an extra package causes too much trouble, I
totally agree.

> I can only reiterate what I said before: the code is pretty isolated
> so I don't see how that causes upstream any maintenance headaches and
> I would volunteer to take care of any issues that are caused by that
> code.
> Personally I would prefer it, if we added a configure switch. This
> would be off by default so we wouldn't advertise legacy cruft by
> default but it would make it easier for distros which need to maintain
> that level of compat support.

This is an exercise in making the code base smaller and dropping support
for some legacy, while still keeping support around via external
packages. And initctl is a low-hanging fruit, hence the idea.


Thanks,
Daniel

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

Re: [systemd-devel] Factoring out initctl support

[Daniel Mack]

On 04/15/2016 07:03 PM, Mike Gilbert wrote:
> On Fri, Apr 15, 2016 at 11:43 AM, Daniel Mack <dan...@zonque.org> wrote:
>> On 04/15/2016 03:55 PM, Mike Gilbert wrote:

>>> I'm happy to move it if others want to utilize it. I will need someone
>>> to set me up with access to push the code, however.
>>
>> Great, will do. What's your GitHub handle?
> 
> I'm floppym on github.
> 

Thanks - you're now the admin of this new repository:

  https://github.com/systemd/systemd-initctl/

I'm happy to push the client code there once you migrated the project.


However, I'd still like to have an Ack from Michael Biebl on the
downstream integration of this new repository.


Thanks,
Daniel

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

Re: [systemd-devel] Factoring out initctl support

[Daniel Mack]

On 04/15/2016 03:55 PM, Mike Gilbert wrote:
> On Fri, Apr 15, 2016 at 6:42 AM, Daniel Mack <dan...@zonque.org> wrote:
>> Nice, thanks for working on this! What's still missing in that is the
>> other side, the client that talks to the initctl socket. I have patches
>> to remove the initctl bits from the systemd repo, and add a callout from
>> systemctl to binaries in a directory. The initctl client would live in
>> that directory, and be automatically called as a fallback then.
> 
> I'm not sure what you mean by this; the de-facto "initctl client" is
> the telinit binary from sysvinit. There should be no need to
> re-implement that.
> 
> Are you referring to some other interface? Does upstart do something similar?

I'm referring to systemctl's own implementation, which is used when PID1
is not systemd. See talk_initctl() in systemctl.c. I'd move that out to
an own binary, and add a generic callout mechanism to systemctl (which I
already did).

What also missing in your repository is the manpage and a README.

>> Would you be okay with transferring this repository to the systemd
>> organization on GitHub?
> 
> I'm happy to move it if others want to utilize it. I will need someone
> to set me up with access to push the code, however.

Great, will do. What's your GitHub handle?


Thanks,
Daniel

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

[systemd-devel] Factoring out initctl support (was: Re: [RFC] the chopping block)

[Daniel Mack]

Hi Mike,

On 04/01/2016 10:11 PM, Mike Gilbert wrote:
> On Wed, Feb 24, 2016 at 10:42 PM, Mike Gilbert  wrote:

>> The existing systemd-initctl (/dev/initctl) interface works quite
>> nicely, so I will probably end up extracting it from systemd when you
>> drop it, or just building/installing it from an older systemd tarball.
>> No need to reinvent the wheel.
>>
>> Thanks for the response.
> 
> Ripping systemd-initctl out of the systemd source tree was more
> difficult than I anticipated. Instead, I rewrote a simpler version.
> The code is on bitbucket.
> 
> https://bitbucket.org/floppym/gentoo-systemd-initctl/src

Nice, thanks for working on this! What's still missing in that is the
other side, the client that talks to the initctl socket. I have patches
to remove the initctl bits from the systemd repo, and add a callout from
systemctl to binaries in a directory. The initctl client would live in
that directory, and be automatically called as a fallback then.

Would you be okay with transferring this repository to the systemd
organization on GitHub?

Michael, would you be fine with integrating this downstream to not lose
any compat?


Thanks,
Daniel

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

Re: [systemd-devel] centos-ci

[Daniel Mack]

On 04/12/2016 01:52 PM, Jóhann B. Guðmundsson wrote:
> Anyone know that centos is not running the latest version(s) of systemd 
> required for the upstream bug tracker so one has to ask what 
> notification spam is this
> "Can one of the admins verify this patch?"

Regarding that spam, I already took measures against that.

I wasn't aware the CentOS CI started commenting on PRs, and neither was
anyone else on their side. The GitHub integration in the CentOS Jenkins
is brand new, we're their first user, so such things can happen. Sorry
about that.


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

Re: [systemd-devel] nftables

[Daniel Mack]

Hi Daniel,

On 02/22/2016 11:04 AM, Daniel Wagner wrote:
> On 02/22/2016 09:54 AM, Tomasz Bursztyka wrote:

>> I haven't been following the recent (well... the last ~2 years ^^')
>> work on nftables but I believe there are still people using the
>> iptables format. The use the iptables- nftables compatible tool, and
>> it mimics iptables through nftables. Verify it, but if it's the
>> generic way, then it would be as usual in ConnMan.

It aims for that, yes, but in my tests there were quite some uncovered
corner cases when it comes to command line compatibility. But I wonder
why this is related to ConnMan - does it call out to the binary?

>> If not, then you will have to come with a strategy that fits all. And
>> that's when it
>> might become tricky. As you noticed, ConnMan will have to avoid conflicts.

I haven't followed the discussions. What kind of conflicts is this about?

>> I believe it will be a bit easier than with iptables though.
>> - you pull the current context:
>>   -> if there is nothing, it will be easy ConnMan will just push
>> whatever it will want.
>>   -> if something is there, integrating will have to play nice.
>> Basically: finding the
>> input entry point to jump on a custom ConnMan table (you'll probably
>> need that
>> for each IP version), get you rules applied or return if nothing.

IMO, ConnMan, or any other tool for that matter, should never mess with
rules it hasn't created itself. nftables makes this easy, as it allows
for namespaces in the rule sets, through custom tables. If any other
tool installs other tables with conflicting rules, I don't think ConnMan
should care really. With iptables, this is just a bit trickier due to
the custom jump label that you have to install in the INPUT and OUTPUT
chains.

Right now, there are two parts of systemd that touch packet filter
configurations, nspawn and networkd, and the code already takes care of
not touching any rule that it has no business with.

> Lennart posted the headsup on systemd moving from iptables to
> nftables [1]. I don't know how far those plans have gotten but I think
> it would be good idea to coordinate this with systemd-networkd.
> 
> @Tom do you happen to know what the status is on this?

It was me who worked on this, and I postponed the branch a while ago
until we know how the kernel APIs look like that we want to use for a
per-unit packet filtering mechanism. Back then, it looked like this
could only be achieved with nftables, which is why I reworked all the
code in systemd.

Now, things are not that clear anymore, so the decision was postponed. I
hope to catch up with this soon, but eventually, I think we should move
to nftables as well. Note, however, that iptables and nftables may
coexist on a system.

>> About coding around, it's a bit messy. There is one library,
>> libnftnl. It's not build on top of libnl. I am not entirely sure, but
>> I think you can hook your own netlink access functions to it. By
>> default it uses libmnl... You'll have to verify that. Ask Marcel what
>> he would prefer as well. Afaik, there is still the plan to move 
>> ConnMan to ell, so keeping it's custom netlink access would make
>> sense then, I guess.
> 
> I really like to avoid coding directly netlink. The libnftnl doesn't look
> too bad. 

You can have a look at the outdated branch of mine here:

  https://github.com/zonque/systemd/commits/nftnl



HTH,
Daniel

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

Re: [systemd-devel] New "ubuntu-ci" integration tests are being added to PRs

[Daniel Mack]

On 02/18/2016 12:19 PM, Jóhann B. Guðmundsson wrote:
> On 02/18/2016 10:22 AM, Daniel Mack wrote:
>> I disagree. All sorts of testing is good for us, and if a PR is breaking
>> downstream Ubuntu, and we recognize that before merging, that's really
>> great.
> 
> I'm all for more testing the better but due to downstream fragmentation 

Fragmentation? Martin does not apply any patches downstream for his
tests, so I don't see where this fear is coming from?

> all these have the same fundamental problem as are with multiple 
> downstream issue trackers.

But it's different for CI really.

> In this case you start slowing down integration if PR start failing in 

"if".

Let's see how things go, and assess the situation if we really face too
many false positives. As I said - we're running all our CI on Ubuntu so
far, and unrelated build breakages have rarely been a real issue. And
again - if things break, we should at least learn about the fact.


Thanks,
Daniel

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

Re: [systemd-devel] New "ubuntu-ci" integration tests are being added to PRs

[Daniel Mack]

On 02/18/2016 11:08 AM, Jóhann B. Guðmundsson wrote:
> On 02/18/2016 08:01 AM, Martin Pitt wrote:
>> So please don't put too much attention to these results yet. I want to
>> to enable them to see how the testing and communication holds up in
>> practice, but before this we definitively need to sort out [2] first.
> 
> Will failed tests or false positives start auto creating issues on github?

No.

> If so is that really the smart thing do to here?

No.

> The only test system that should be hooked into upstream should just be 
> upstreams own not some downstreams right.

I disagree. All sorts of testing is good for us, and if a PR is breaking
downstream Ubuntu, and we recognize that before merging, that's really
great.

Also note that Semaphore is already based on Ubuntu all the time, and
the trouble it saved us so far is priceless.

We have not (yet) configured the master branch so it requires all CI
test to succeed prior to merging, so maintainers can still ignore such
information, if they have good reasons.


Thanks,
Daniel

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

Re: [systemd-devel] Moving systemd-bootchart to a standalone repository

[Daniel Mack]

On 02/17/2016 06:03 PM, Jóhann B. Guðmundsson wrote:
> 
> 
> On 02/17/2016 04:51 PM, Daniel Mack wrote:
>> Hey,
>>
>> [I've put all people in Cc who have had more than one commit related to
>> systemd-bootchart in the past]
>>
>> As part of our spring cleaning, we've been thinking about giving
>> systemd-bootchart a new home, in a new repository of its own. I've been
>> working on this and put the result here:
> 
> What's the reason for splitting it out into it's own repository as 
> what's the criteria you used to determine that which may or may not be 
> applicable to other bits of systemd?+

Barely anyone of the people working on systemd uses that tool, so it
sees little testing. Also, the code works well in a non-systemd
environment, so an external repository seems like a better fit.

We don't have any other bits in mind so far to which this applies.


Thanks,
Daniel

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

[systemd-devel] Moving systemd-bootchart to a standalone repository

[Daniel Mack]

Hey,

[I've put all people in Cc who have had more than one commit related to
systemd-bootchart in the past]

As part of our spring cleaning, we've been thinking about giving
systemd-bootchart a new home, in a new repository of its own. I've been
working on this and put the result here:

  https://github.com/systemd/systemd-bootchart

This repository contains a stripped down set of the utility functions we
have in src/shared and src/basic in systemd, with most of those which
bootchart doesn't use removed. The man page and service file etc. are
all in the new repository. A new GitHub team was created for maintainers
of that code, and I'm willing to add more people to it, just let me
know. Auke, you are the official maintainer of the thing, so I'd put you
in that group anyway.

I have a local patch that removes the current sources from systemd, but
before I put that into a pull request, I'd appreciate some feedback, so
please let me know if the standalone version of that tool works for you.


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

Re: [systemd-devel] [PATCH] keymap: remap microphone mute keycode for Lenovo Thinkcentre M800z

[Daniel Mack]

On 01/06/2016 03:37 AM, Hui Wang wrote:
> This Lenovo machine use codec Line2 to implement a microphone mute
> button, it depends on the unsolicited interrupt to generate key event,
> the scan code for this button is assigned to 0x00 in the linux kernel
> driver, and the keycode is KEY_MICMUTE(248), we need to remap this
> keycode to KEY_F20 to make this hotkey work in X11.
> 
> BugLink: https://bugs.launchpad.net/bugs/1531362
> Signed-off-by: Hui Wang 

FTR: this is merged upstream as 03198122.


Thanks,
Daniel



> ---
>  hwdb/60-keyboard.hwdb | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/hwdb/60-keyboard.hwdb b/hwdb/60-keyboard.hwdb
> index 94906ab..69a1e8f 100644
> --- a/hwdb/60-keyboard.hwdb
> +++ b/hwdb/60-keyboard.hwdb
> @@ -652,6 +652,11 @@ 
> evdev:atkbd:dmi:bvn*:bvr*:svnLENOVO*:pn*IdeaPad*Z370*:pvr*
>  evdev:atkbd:dmi:bvn*:bvr*:bd*:svnLENOVO*:pn*Lenovo*V480*:pvr*
>   KEYBOARD_KEY_f1=f21
>  
> +# Lenovo Thinkcentre M800z AIO machine
> +# key_scancode 00 is KEY_MICMUTE
> +keyboard:name:Microphone Mute Button:dmi:bvn*:bvr*:bd*:svnLENOVO*:pn*
> + KEYBOARD_KEY_00=f20
> +
>  # enhanced USB keyboard
>  evdev:input:b0003v04B3p301B*
>   KEYBOARD_KEY_90001=prog1 # ThinkVantage
> 

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

Re: [systemd-devel] Unable to store fds with systemd and reterive it back again

[Daniel Mack]

Hi,

On 01/06/2016 12:07 AM, Pathangi Janardhanan wrote:
> Hi All,
> 
>  After trying a few things out, here are couple doubts that I have.
> 
> 1. I am able to get this to work, if I modify the way the sendmsg is
> being done, here is a temp. function that I wrote in my own service
> to mimic the actions of sd_pid_notify_with_pids and with this I am able
> to store the fds with systemd and reterive it back again on a
> service restart.
> 
>  The only real difference is that I do a connect on the socket before
> doing the sendmsg call, and searching through some stuff on google seems
> to indicate that you need to do connect for unix domain sockets, but not
> sure if that is the right thing to do?

It's only necessary to connect() sockets that are in connection mode
(SOCK_STREAM or SOCK_SEQPACKET), but this one is a SOCK_DGRAM socket.

The reason why this is failing is because your systemd version is too
old. All versions prior to v227 have a bug that causes a miscalculation
of the msg_controllen value of the message header, hence the syscall
rightfully fails. Any chance the Ubuntu people could backport a5bd3c32?
Martin?

As a workaround, you basically have to options:

a) open-code the routine as you did, but you can leave off the connect()
call, that's not needed.

b) Pass your own PID to sd_pid_notify_with_fds().

> 2. The other issue I now have, is that after my service is restarted, I
> am able to reterive this and continue to service the client. But I am
> not able to delete this from the systemd state.
> 
>  The sequence is,
> 1. Start the service, and handle some clients
> 2. On a trigger, store the client fds
> 3. Do a systemctl restart of the service, and the service gets these fds
> in the new invocation

This is intended. systemd holds a reference to the file descriptor you
passed, so it will have it ready for you on each start of the service.
This way, if the task just drops everything on idle, or even if it
crashes, all fds that have been passed over earlier will be restored.

> 4. it handles the client and the client closes the connection
> 5. Now I do another restart of the service, but I still get this fd

This shouldn't happen. If the client closes the connection, systemd
should get EPOLLHUP on the fd and remove it from the set of file
descriptors, hence dropping its reference. Are you sure the client
properly closes its side of the communication?


HTH,
Daniel

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

Re: [systemd-devel] Unable to store fds with systemd and reterive it back again

[Daniel Mack]

On 01/05/2016 06:33 PM, Pathangi Janardhanan wrote:
>  This is the output of the strace call on this section of the code in
> the sd_pid_notify_with_fds, when I try to save the fds.
> 
> socket(PF_LOCAL, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 8
> 
> sendmsg(8, {msg_name(21)={sa_family=AF_LOCAL,
> sun_path="/run/systemd/notify"}, msg_iov(1)=[{"FDSTORE=1\n", 10}],
> msg_controllen=40, {cmsg_len=20, cmsg_level=SOL_SOCKET,
> cmsg_type=SCM_RIGHTS, {7}}, msg_flags=0}, MSG_NOSIGNAL) = -1 EINVAL
> (Invalid argument)

Which version of systemd are you running? Does it contain a5bd3c32?


Thanks,
Daniel




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

Re: [systemd-devel] First steps with sd-bus

[Daniel Mack]

On 10/05/2015 12:59 PM, Iñigo Martínez wrote:
> In a home made daemon, I needed to change some variables while
> running, so I though about D-Bus as IPC and gived a chance to sd-bus.
> 
> Let's say that I'm trying it on a development system (currently a
> debian jessie) without any users on it, just root, and some basic
> libraries and configuration.
> 
> After reading Lennarts article[0] I tried to compile the bus-service.c
> example. Here came the first problem:
> 
>Failed to connect to system bus: No such file or directory
> 
> Obviously, as the system isn't executing a user bus, the service can't
> find it, so I fixed it by changing:
> 
>   r = sd_bus_open_user();
> 
> to:
> 
>   r = sd_bus_open_system();

Which is probably what you want to do anyway in case your daemon is
supposed to be accessible system-wide.

> This way it uses a new connection to the system bus instead of the
> nonexistent user bus, but it doesn't work either with a new problem
> when requesting the name:
> 
>   Failed to acquire service name: Permission denied

Owning a name is something the D-Bus daemon has to explicitly allow your
code to do, through an XML policy file. See /etc/dbus-1/system.d/* for
examples, and the dbus-daemon(1) man page for details.


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

Re: [systemd-devel] Multiple starts of a service, what am I doing wrong?

[Daniel Mack]

On 09/24/2015 03:27 PM, D.S. Ljungmark wrote:
> (re-send due to wrong email address)
> 
> On 24/09/15 14:38, Daniel Mack wrote:
>> On 09/24/2015 01:17 PM, D.S. Ljungmark wrote:
>>> I've got the following unit:
>>>
>>> [Unit]
>>> Description=Random Submitter
>>> Wants=network-online.target
>>> After=network-online.target other.service
>>> RequiresMountsFor=/data
>>>
>>> [Service]
>>> Type=simple
>>
>> Type=simple implies that the executable specified through ExecStart= is
>> the main process and that it does not fork but 'block'. Is that the
>> case? If it does fork, like most daemons do, Type= should be set to
>> 'forking'.
>>
>> Or do you actually want to run that binary just once, without systemd
>> restarting it after it died? That you should set Type= to 'oneshot'.
>>
>> See systemd.service(5) for more information.
> 
> 
> That is correct. ExecStartPre does some environment/Testing, while the
> actual submitter will run fpr ~20 hours, slowly doing network chatter,
> and abort in case of network error (trusting systemd to restart it)
> 
> So, it's a daemon that never forks.
> 
> The question I have isn't about this running or not (it runs
> beautifully, gets restarted when it should, and starts once it has a
> certificate available)

I see. So, that's just a cosmetic issue then, resulting in log messages
that shouldn't be there because the service is already started. We'll
look into that.

However, this can only happen when something modifies one of the
PathExists= files (/data/certificate.crt, /data/submitter.ini) on your
system. Does your daemon do that, or any other part of your setup? You
can also fix that by preventing those modifications.


Thanks,
Daniel

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

Re: [systemd-devel] Multiple starts of a service, what am I doing wrong?

[Daniel Mack]

On 09/24/2015 01:17 PM, D.S. Ljungmark wrote:
> I've got the following unit:
> 
> [Unit]
> Description=Random Submitter
> Wants=network-online.target
> After=network-online.target other.service
> RequiresMountsFor=/data
> 
> [Service]
> Type=simple

Type=simple implies that the executable specified through ExecStart= is
the main process and that it does not fork but 'block'. Is that the
case? If it does fork, like most daemons do, Type= should be set to
'forking'.

Or do you actually want to run that binary just once, without systemd
restarting it after it died? That you should set Type= to 'oneshot'.

See systemd.service(5) for more information.


HTH,
Daniel

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

Re: [systemd-devel] [PATCH 1/2] mising: add __NR_memfd_create syscall number for s390

[Daniel Mack]

Applied thanks!

Though I removed the S-o-b line, we don't use that in systemd.

On 09/23/2015 01:42 PM, Hendrik Brueckner wrote:
> Signed-off-by: Hendrik Brueckner 
> ---
>  src/basic/missing.h |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/src/basic/missing.h b/src/basic/missing.h
> index dc1f244..93a7cb9 100644
> --- a/src/basic/missing.h
> +++ b/src/basic/missing.h
> @@ -139,6 +139,8 @@ static inline int pivot_root(const char *new_root, const 
> char *put_old) {
>  #define __NR_memfd_create 385
>  #  elif defined __aarch64__
>  #define __NR_memfd_create 279
> +#  elif defined __s390__
> +#define __NR_memfd_create 350
>  #  elif defined _MIPS_SIM
>  #if _MIPS_SIM == _MIPS_SIM_ABI32
>  #  define __NR_memfd_create 4354
> 

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

Re: [systemd-devel] [PATCH] hwdb: Add Thinkpad X1 carbon 3rd gen to 70-pointingstick.hwdb

[Daniel Mack]

On 09/14/2015 02:16 PM, Hans de Goede wrote:
> Like many other recent thinkpads the factory default pointingstick
> sensitivity on these devices is quite low, making the pointingstick
> very slow in moving the cursor.
> 
> This extends the existing hwdb rules for tweaking the sensitivity to
> also apply to the X1 carbon 3rd gen model.
> 
> BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1200717

Care to open a GitHub PR for this?


Thanks,
Daniel



> ---
>  hwdb/70-pointingstick.hwdb | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/hwdb/70-pointingstick.hwdb b/hwdb/70-pointingstick.hwdb
> index 8e674b1..9d288e3 100644
> --- a/hwdb/70-pointingstick.hwdb
> +++ b/hwdb/70-pointingstick.hwdb
> @@ -100,6 +100,8 @@ evdev:name:TPPS/2 IBM 
> TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadT440
>  evdev:name:TPPS/2 IBM 
> TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadT540p:*
>  # Lenovo Thinkpad T550 / W550s
>  evdev:name:TPPS/2 IBM 
> TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadT550:*
> +# Lenovo Thinkpad X1 Carbon 3rd gen
> +evdev:name:TPPS/2 IBM 
> TrackPoint:dmi:bvn*:bvr*:bd*:svnLENOVO:pn*:pvrThinkPadX1Carbon3rd:*
>POINTINGSTICK_SENSITIVITY=200
>POINTINGSTICK_CONST_ACCEL=1.0
>  
> 

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

Re: [systemd-devel] httpd.service daemon failing to start on Manjaro Linux

[Daniel Mack]

On 08/18/2015 04:24 PM, Brenton Horne wrote:
 Aug 18 23:18:10 fusion809-vbox systemd[1]: Starting Apache Web Server...
 -- Subject: Unit httpd.service has begun start-up
 -- Defined-By: systemd
 -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
 -- 
 -- Unit httpd.service has begun starting up.
 Aug 18 23:18:10 fusion809-vbox apachectl[1083]: AH00526: Syntax
 error on line 2
 Aug 18 23:18:10 fusion809-vbox apachectl[1083]: Invalid command
 'php_admin_valu
 Aug 18 23:18:10 fusion809-vbox systemd[1]: httpd.service: Control
 process exite
 Aug 18 23:18:10 fusion809-vbox systemd[1]: Failed to start Apache
 Web Server.

That's a configuration problem of your Apache install and has nothing to
do with systemd.


Thanks,
Daniel

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

Re: [systemd-devel] systemd-journald crashes w/specific numbers of fields

[Daniel Mack]

On 08/05/2015 12:50 PM, Sebastian Schindler wrote:
 Hi,
 
 I have Systemd v216 on a VM, there I was able to reproduce this.
 I did use this tool https://github.com/carosio/jlog to create the logs:
 
 jlog 'MESSAGE=this will crash' 'SYSLOG_IDENTIFIER=foobar' 'SYSLOG_FACILITY=3' 
 'PRIORITY=5' 'KEY5=foobar' 'KEY6=foobar' 'KEY7=foobar' 'KEY8=foobar' 
 'KEY9=foobar' 'KEY10=foobar' 'KEY11=foobar' 'KEY12=foobar' 'KEY13=foobar' 
 'KEY14=foobar' 'KEY15=foobar' 'KEY16=foobar' 'KEY17=foobar' 'KEY18=foobar' 
 'KEY19=foobar'
 
 resulting in 37 Fields in verbose output and 40 fields with export output.
 
 I also tried to reproduce this on my normal system
 
  Kubuntu 15.04
  Systemd v219
 
 Unfortunately I wasn't able to trigger the assertion on this version.
 I tried everything between 1 and 500 numbers of Fields, 
 none triggered this (or any other) assertion.

This was already filed today:

  https://github.com/systemd/systemd/issues/866

And a fix was commited here:

  https://github.com/systemd/systemd/pull/871


Does this work for you?


Thanks,
Daniel

 
 
 - Original Message -
 Hello,
 
 Before filing a bug report, I wanted to run this by the group to make sure
 I'm not doing something dumb (it happens).  We're seeing systemd-journald
 crash with:
 
 Assertion 'n + 20 + (object_pid ? 11 : 0) = m' failed at
 /build/amd64-usr/var/tmp/portage/sys-apps/systemd-218-r5/work/systemd-218/src/journal/journald-server.c:576,
 function dispatch_message_real(). Aborting.
 
 Shortly after this occurs, the container crashes.  We cause this by
 creating journal entries with some very specific numbers of metadata
 fields.  22, 66, 154, 330 to be exact.  Any other number of fields, no
 problem, no crash.  Crazy, right?  The examples at the bottom of this
 message reliably produce a crash.
 
 PLEASE let me know if I've missed something obvious, but as far as I can
 tell, this is a bug in systemd-journald.  We've seen this exact failure
 mode with Erlang, Ruby, and Python.
 
 [...]
 ___
 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] systemd.conf 2015 Announcement and CfP

[Daniel Mack]

On 07/30/2015 03:53 PM, Umut Tezduyar Lindskog wrote:
 Fantastic! Tried to purchase a ticket but seems like PayPal is the
 only supported payment. Is this a glitch?

For now, only going with PayPal as checkout option was the easiest way
of get the sale going. If that turns out to be a major problem for
potential attendees, we need to think about alternatives. Please let us
know.

Note that PayPal should also work as credit card provider directly,
without an account.


Thanks,
Daniel

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

Re: [systemd-devel] Clarification around a segmentation fault from an udevd worker

[Daniel Mack]

On 07/29/2015 10:06 AM, SF Markus Elfring wrote:
 Program received signal SIGSEGV, Segmentation fault.
 0x76fefc78 in vfprintf () from /lib64/libc.so.6
 (gdb) bt full
 #0  0x76fefc78 in vfprintf () from /lib64/libc.so.6
 No symbol table info available.
 #1  0x77016f39 in vsnprintf () from /lib64/libc.so.6
 No symbol table info available.
 #2  0x5559ac64 in log_internalv (level=7, error=0, 
 file=0x556118a0 
 /home/elfring/Projekte/systemd/lokal/src/libsystemd/sd-device/device-private.c,
  
 line=1080, func=0x556124c0 __func__.9471 device_update_db,
 format=0x55611f40 %s:%s:%d: created %s file '%s' for '%s',
ap=0x7fffd760)
 ^

This is *very* strange. The 'format' parameter should not contain that
%s:%s:%d prefix at all, as this cannot work of course because the
argument list doesn't match. The source file and line are only added to
the journal entries via log_dispatch().

Also, %s:%s:%d does not appear anywhere in the source tree, and it
never did. (git log -p | grep %s:%s:%d | wc -l).

Which version of systemd are you based on? Do you have *any* local
modifications in your tree?

*confused*


Daniel

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

Re: [systemd-devel] Clarification around a segmentation fault from an udevd worker

[Daniel Mack]

On 07/29/2015 01:40 PM, SF Markus Elfring wrote:
 Do you have *any* local modifications in your tree?
 
 Yes. - It seems that I was bitten by a format string mismatch during
 an attempt to display a few more implementation details for my needs.
 
 
 diff --git a/src/libsystemd/sd-device/device-private.c 
 b/src/libsystemd/sd-device/device-private.c
 index 2e60433..b5a31ec 100644
 --- a/src/libsystemd/sd-device/device-private.c
 +++ b/src/libsystemd/sd-device/device-private.c
 @@ -1076,7 +1076,7 @@ int device_update_db(sd_device *device) {
  goto fail;
  }
  
 -log_debug(created %s file '%s' for '%s', has_info ? db : empty,
 +log_debug(%s:%s:%d: created %s file '%s' for '%s', has_info ? db 
 : empty, __FUNCTION__, __FILE__, __LINE__,
path, device-devpath);

Which is completely wrong, obviously.

 Should my compiler gcc 5.2.0 be able to detect and warn about misplaced
 parameters in such an use case?

I'm sure you got a warning on this.

Such reports really waste our time, which is annoying.


Daniel

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

Re: [systemd-devel] [PATCH] sd-bus: use isempty() consistently

[Daniel Mack]

On 07/19/2015 11:01 AM, Namhyung Kim wrote:
 Signed-off-by: Namhyung Kim namhy...@gmail.com

Looks good, thanks! However, it does not apply against current master.
Care to rebase? Also, we generally prefer GitHub pull requests these
days. And you can leave off the Signed-off-by line, we don't use that in
the systemd project.


Thanks,
Daniel


 ---
  src/libsystemd/sd-bus/bus-control.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/src/libsystemd/sd-bus/bus-control.c 
 b/src/libsystemd/sd-bus/bus-control.c
 index a38c5c5..80f4760 100644
 --- a/src/libsystemd/sd-bus/bus-control.c
 +++ b/src/libsystemd/sd-bus/bus-control.c
 @@ -1131,7 +1131,7 @@ static int add_name_change_match(sd_bus *bus,
  
  /* If the old name is unset or empty, then
   * this can match against added names */
 -if (!old_owner || old_owner[0] == 0) {
 +if (isempty(old_owner)) {
  item-type = KDBUS_ITEM_NAME_ADD;
  
  r = ioctl(bus-input_fd, KDBUS_CMD_MATCH_ADD, m);
 @@ -1141,7 +1141,7 @@ static int add_name_change_match(sd_bus *bus,
  
  /* If the new name is unset or empty, then
   * this can match against removed names */
 -if (!new_owner || new_owner[0] == 0) {
 +if (isempty(new_owner)) {
  item-type = KDBUS_ITEM_NAME_REMOVE;
  
  r = ioctl(bus-input_fd, KDBUS_CMD_MATCH_ADD, m);
 @@ -1185,7 +1185,7 @@ static int add_name_change_match(sd_bus *bus,
  
  /* If the old name is unset or empty, then this can
   * match against added ids */
 -if (!old_owner || old_owner[0] == 0) {
 +if (isempty(old_owner)) {
  item-type = KDBUS_ITEM_ID_ADD;
  
  r = ioctl(bus-input_fd, KDBUS_CMD_MATCH_ADD, m);
 @@ -1195,7 +1195,7 @@ static int add_name_change_match(sd_bus *bus,
  
  /* If thew new name is unset or empty, then this can
   * match against removed ids */
 -if (!new_owner || new_owner[0] == 0) {
 +if (isempty(new_owner)) {
  item-type = KDBUS_ITEM_ID_REMOVE;
  
  r = ioctl(bus-input_fd, KDBUS_CMD_MATCH_ADD, m);
 

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

Re: [systemd-devel] [PATCH] Typo fix in systemd.preset manpage

[Daniel Mack]

On 07/17/2015 02:12 PM, Vivenzio Pagliari wrote:
 ---
  man/systemd.preset.xml | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Now merged through

https://github.com/systemd/systemd/pull/626

Thanks!

Daniel




 
 diff --git a/man/systemd.preset.xml b/man/systemd.preset.xml
 index 2f9add8..b716401 100644
 --- a/man/systemd.preset.xml
 +++ b/man/systemd.preset.xml
 @@ -106,7 +106,7 @@
  one takes precedence over all others./para
  
  paraEach preset file shall be named in the style of
 -filenamelt;prioritygt;-lt;programgt;.conf/filename. Files
 +filenamelt;prioritygt;-lt;policy-namegt;.preset/filename. Files
  in filename/etc//filename override files with the same name in
  filename/usr/lib//filename and filename/run//filename.
  Files in filename/run//filename override files with the same
 

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

Re: [systemd-devel] [PATCH] sd-bus: use isempty() consistently

[Daniel Mack]

On 07/20/2015 02:06 PM, Mantas Mikulėnas wrote:
 On Mon, Jul 20, 2015 at 1:14 PM, Daniel Mack dan...@zonque.org
 mailto:dan...@zonque.org wrote:
 
 On 07/19/2015 11:01 AM, Namhyung Kim wrote:
  Signed-off-by: Namhyung Kim namhy...@gmail.com
 mailto:namhy...@gmail.com
 
 Looks good, thanks! However, it does not apply against current master.
 Care to rebase? Also, we generally prefer GitHub pull requests these
 days. And you can leave off the Signed-off-by line, we don't use that in
 the systemd project.
 
 
 Does including it hurt though?

We don't use them, so they shouldn't be there. Leaving them around in
some commits but not in others just causes confusion for people reading
the logs.

Everyone with push access usually removes those tags manually.


Thanks,
Daniel

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

Re: [systemd-devel] [--dmesg] 'kdbus': Function not implemented

[Daniel Mack]

On 07/14/2015 03:39 PM, RicΛrdo Bastos™ wrote:
 [Gentoo] I updated yesterday to version 'sys-apps/systemd-222-r1';
 Jul 14 16:18:27 ric-pc systemd[1]: *Failed to insert module 'kdbus':
 Function not implemented*

That's just a non-fatal warning message which is caused by a bug in
libkmod that has been fixed a while ago.


https://git.kernel.org/cgit/utils/kernel/kmod/kmod.git/commit/?id=114ec87c85

This will go away automatically once a new version of libkmod has been
released. Also see

  https://github.com/systemd/systemd/issues/203


Thanks,
Daniel

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

Re: [systemd-devel] Extlinux - GCC 5

[Daniel Mack]

On 07/10/2015 05:00 PM, poma wrote:
 What do you think, what is it about?

?

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

Re: [systemd-devel] [PATCH]fopen_temporary: close fd if fail

[Daniel Mack]

On 07/09/2015 01:52 AM, cee1 wrote:
 From 76a7f141d54428af3019732c0fce146f9a6f6394 Mon Sep 17 00:00:00 2001
 From: cee1 fykc...@gmail.com
 Date: Thu, 9 Jul 2015 12:06:59 +0800
 Subject: [PATCH] basic/util.c fopen_temporary(): close fd if failed
 
 ---
  src/basic/util.c | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/src/basic/util.c b/src/basic/util.c
 index e4e302a..c88cd1d 100644
 --- a/src/basic/util.c
 +++ b/src/basic/util.c
 @@ -2535,6 +2535,7 @@ int fopen_temporary(const char *path, FILE **_f, char 
 **_temp_path) {
  if (!f) {
  unlink(t);
  free(t);
 +safe_close(fd);
  return -errno;
  }
  

Applied, thanks!

Next time, please consider opening a GitHub pull request for patches.


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

Re: [systemd-devel] About github repo and release tarball change

[Daniel Mack]

On 07/09/2015 09:28 AM, Armin K. wrote:
 On 09.07.2015 12:32, Andrei Borzenkov wrote:

 I clicked on release link and it downloaded file with name
 systemd-222.tar.gz. I see that there could be an issue with dumb cli
 clients not following redirections probably.

 
 I suppose it's a github issue doing some black magic in the background.

That's actually well-defined web technology. The web server can tell the
client both the content type and the preferred file name, and that's
what all modern browser look at. You can inspect those headers with
wget -S:

  $ wget -S https://github.com/systemd/systemd/archive/v222.tar.gz
  [...]
  Content-Type: application/x-gzip
  Content-Disposition: attachment; filename=systemd-222.tar.gz
  [...]

Now, wget doesn't use that information by default, but can be told to do
so with the --content-disposition command line parameter. That works
fine here.


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

Re: [systemd-devel] About github repo and release tarball change

[Daniel Mack]

On 07/09/2015 06:32 AM, Andrei Borzenkov wrote:
 On Thu, Jul 9, 2015 at 12:43 PM, Armin K. kre...@email.com wrote:
  Now, this might be an issue with my limited git knowledge, but
  I don't think that's related to the web interface not showing
  the commits in the correct order between two release tags.
 
 Recently there was discussion about completely screwed up pull request
 commit order in web interface and github was contacted. I do not know
 of there is any response from them though.

Not yet, but that seems unrelated anyway, as that was only regarding the
commit order as shown in pull requests. AFAIK, the full commit log as
here, for instance:

  https://github.com/systemd/systemd/commits/master

… matches exactly what git show by default with git log --oneline: The
commits are shown in reverse chronological order.

What differences do you see, Armin?


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

Re: [systemd-devel] HEADS-UP: splitting python-systemd out

[Daniel Mack]

On 07/08/2015 03:43 PM, Michael Biebl wrote:
 2015-07-08 21:17 GMT+02:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl:
 On Tue, Jul 07, 2015 at 03:49:13PM +0200, Michael Biebl wrote:
 2015-07-07 2:51 GMT+02:00 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl:
 Comments, patches, pull requests — especially for documentation and tests —
 are very much welcome.

 Regarding the documentation: I failed to generate the documentation
 with sphinx since it didn't find the python modules.
 Do you have some instructions how this can be done.

 Hi,
 this is now fixed in git.

 make sphinx-html
 or
 make sphinx-html PYTHON=python3.4 SPHINX_BUILD=sphinx-build-3.4

 build the docs (although the result should be indistinguishable between
 python versions).
 
 Thanks a lot.
 
 FYI: https://packages.qa.debian.org/p/python-systemd.html

The PR that removes systemd-python from upstream is also merged now:

  https://github.com/systemd/systemd/commit/b9fd7bb60


Thanks,
Daniel

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

Re: [systemd-devel] [HEADSUP] systemd-222 around the corner

[Daniel Mack]

On 07/07/2015 04:42 PM, Michael Biebl wrote:
 2015-07-06 19:54 GMT+02:00 David Herrmann dh.herrm...@gmail.com:
 Hi

 We intend to release v222 tomorrow. If anyone has open issues that
 need to be in that release, please speak up. Right now, the release
 consists almost exclusively of bug-fixes, and we want to get those
 into distributions.
 
 I'm getting a make check failure with 9a50ce2
 
 
 $ ./test-path-util
 expected: ./aa/bb/..
 actual: ./aa/bb/..
 expected: /aa///
 actual: /aa
 expected: /aa///
 actual: /aa
 expected: error
 actual: error
 /bin/sh
 /home/michael/git/systemd/./test-path-util
 /bin/sh
 /bin/sh
 /home/michael/git/systemd/./test-path-util
 /bin/sh
 ---/a/b/c/d---
 ---/a/b/c---
 ---/a/b---
 ---/a---
 --
 ---/a/b/c---
 ---/a/b---
 ---/a---
 --
 Assertion 'fsck_exists(minix) == 0' failed at
 src/test/test-path-util.c:213, function test_fsck_exists(). Aborting.
 Aborted

That's due to a missing --enable-split-usr during configure I guess. How
exactly did you run invoke this?


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

Re: [systemd-devel] HEADS-UP: splitting python-systemd out

[Daniel Mack]

On 07/06/2015 08:51 PM, Zbigniew Jędrzejewski-Szmek wrote:
 I've been asked to split the python-systemd out of the main systemd tree.
 This is the set of python modules which wrap libsystemd. They were
 originally started as a separate project by David Strauss. By splitting
 them out we return to the origins. In systemd we also use python to
 build parts of documentation, and in tests. That use doesn't change.
 
 The new separated package is at https://github.com/systemd/python-systemd
 and the pull request for removal from systemd is at
 https://github.com/systemd/systemd/pull/501 .
 The removal should be merged after the next release, to give a bit
 of time for distributions to create the new package.

Nice. I added a paragraph to NEWS now to give packagers a heads-up.


Thanks,
Daniel

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

Re: [systemd-devel] amavis

[Daniel Mack]

On 07/02/2015 10:30 AM, Tomasz Torcz wrote:
 On Thu, Jul 02, 2015 at 02:04:08PM +, François Vocel wrote:
   Process: 29174 ExecStart=/usr/sbin/amavisd -c /etc/amavisd/amavisd.conf 
 (code=exited, status=227/NO_NEW_PRIVILEGES)
 
   prctl(PR_SET_NO_NEW_PRIVS, 1, 0, 0, 0) is failing.  I don't now why.
 

What does the unit file look like?


Daniel

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

Re: [systemd-devel] Getting boot progress and messages

[Daniel Mack]

On 06/24/2015 12:20 PM, Thomas Schmidt wrote:
 Hello, many thanks for your replies!
 
 Is there an advise what should be used instead ? SDBus/DBus is too
 late activated, private socket looks like a short term solution. Is
 there anything already there which would be the optimal way ?

No. That's one of the reasons why we want kdbus.

 or will
 something be introduced once the code handling private socket will be
 changed ?

With kdbus in place, the private socket is disabled, because we have one
unified IPC to rely on throughout the lifetime of the system.

So, basically, you have two options: use the private socket, and prepare
to touch your code again once it goes away. Or use kdbus in your
embedded project, but prepare to adopt some changes in the kernel code.

With sd-bus used as low-level library, both options are definitely
manageable and shouldn't cause too much pain. But at this point in time,
there is no fully future-proof solution yet, sorry.



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

Re: [systemd-devel] Getting boot progress and messages

[Daniel Mack]

On 06/24/2015 11:57 AM, Umut Tezduyar Lindskog wrote:
 On Wed, Jun 24, 2015 at 11:53 AM, Daniel Mack dan...@zonque.org wrote:
 On 06/24/2015 11:30 AM, Umut Tezduyar Lindskog wrote:
 IMPORTANT: Man page says This interface is private to systemd and
 should not be used in external projects. for /run/systemd/private. I
 am not sure if this is still the case.

 Yes it is. The private socket is a hack that will go away mid-term when
 kdbus is fully adopted. If you still use it from external projects,
 prepare to rework the affected bits in the future.
 
 Good to know Daniel. Thomas, you can always use systemctl to retrieve
 these values if you don't care about the overhead. It is systemctl
 connecting to the private socket.

Right, and you can also use the private socket from your own projects,
nothing can stop you from doing so. But if you do, consider it an
unsupported hack that might stop working at some point.


Thanks,
Daniel

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

Re: [systemd-devel] Getting boot progress and messages

[Daniel Mack]

On 06/24/2015 11:30 AM, Umut Tezduyar Lindskog wrote:
 IMPORTANT: Man page says This interface is private to systemd and
 should not be used in external projects. for /run/systemd/private. I
 am not sure if this is still the case.

Yes it is. The private socket is a hack that will go away mid-term when
kdbus is fully adopted. If you still use it from external projects,
prepare to rework the affected bits in the future.

 If not, we need to change the man page.

Nope, it should stay in. The private socket is not an API that is
guaranteed to remain available.


Thanks,
Daniel

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

Re: [systemd-devel] journalctl - Error was encountered while opening journal files: Invalid argument

[Daniel Mack]

On 06/19/2015 09:31 PM, Johannes Ernst wrote:
 After a reboot, root gets this:
 
 # journalctl 
 Error was encountered while opening journal files: Invalid argument
 
 No other output.

What does 'strace journalctl' say?


Thanks,
Daniel



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

Re: [systemd-devel] Improve boot-time of systemd-based device, revisited

[Daniel Mack]

On 06/19/2015 09:34 AM, Chaiken, Alison wrote:
 ceel, are you aware that readahead is deprecated in systemd and has not 
 been included since about release 216?   Some of us in automotive are 
 still working on it.   I have some patches here
 
 https://github.com/chaiken/systemd-hacks/tree/packfilelist
 
 against 215 that add various features.   We may soon be forward-porting 
 these, along with readahead itself, to the latest version.

FWIW, an approach that will probably save you a lot of rebasing work in
the future would be to rip out the readahead bits from that tree and put
it into a repository of it own. It's a standalone tool that just
happened to live in the systemd repo in the past. Some of the helper
functions would need to be copied over as well, but that should be
manageable.

That way, you can even accept patches from other people and roll your
own releases etc.


HTH,
Daniel

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

Re: [systemd-devel] [HEADSUP] Intend to release 221 by the end of the week

[Daniel Mack]

On 06/18/2015 10:08 AM, Michael Olbrich wrote:
 I have a pull request[1] that I think should be release-critical, but it
 seems I can't add labels to it. Either I'm doing something wrong, or I
 don't have the necessary permissions to add labels.
 
 Michael
 
 [1] https://github.com/systemd/systemd/pull/281

For the record: I merged this trivial one just now.


Daniel

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

[systemd-devel] Static test coverage

[Daniel Mack]

Hi,

Now that we're using Semaphore CI for building all pull requests and
pushes to the master branch, I've set up a second VM instance to also
use their service for static code analysis on a nightly base.

We've had the systemd project registered with Coverity for a while, and
so far, new builds were manually uploaded once in a while by Philippe de
Swert (thanks for that!). This is now done automatically every night.
The results can be seen here:

  https://scan.coverity.com/projects/350/

While at it, I also taught the build bot to use LLVM's scan-build, and
sync the output with a new repository:

  https://github.com/systemd/systemd-build-scan

The patches are pushed to the 'gh-pages' branch, hence the HTML files
are published here:

  https://systemd.github.io/systemd-build-scan/

Unfortunately, scan-build does not seem to understand the _cleanup_*
variable annotations, so it currently reports lots of false-positive
memory leaks.


Hope this helps getting those collections of possible issues more
exposure. If you want me to add more automated static testing, please
let me know.


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

Re: [systemd-devel] Messed up PR references on Github

[Daniel Mack]

On 06/10/2015 09:23 AM, Jan Synáček wrote:
 See https://github.com/systemd/systemd/pull/5. There are multiple
 references to this PR that say user referenced this pull request from
 a commit in commit, which is hilarious, as those clearly are not
 references to this PR. Their commit messages contain the string #5 and
 Github thinks it means a reference. I'm pretty sure this will mess up a
 lot of pull requests in the future. Is there a way to fix this?

No, unfortunately there isn't. I've already talked to GitHub support
about this, but their automatic interpretation of issue/pull references
in the # notation is not something that can be turned off.

Not sure what to do about that, but in pratice, this specific problem is
unlikely to bite us much in the future, because our issue numbers (at
least the one that are 'open') are now already higher than most stacks
are deep.


Daniel

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

Re: [systemd-devel] Messed up PR references on Github

[Daniel Mack]

On 06/10/2015 07:04 PM, Filipe Brandenburger wrote:
 On Wed, Jun 10, 2015 at 12:23 AM, Jan Synáček jsyna...@redhat.com wrote:
 See https://github.com/systemd/systemd/pull/5. There are multiple
 references to this PR that say user referenced this pull request from
 a commit in commit, which is hilarious, as those clearly are not
 references to this PR. Their commit messages contain the string #5 and
 Github thinks it means a reference. I'm pretty sure this will mess up a
 lot of pull requests in the future. Is there a way to fix this?
 
 If you learn one thing about Markdown (or GitHub Markdown), learn that
 a block delimited by ``` lines makes it a verbatim literal (think
 pre in HTML terms), so when pasting output the best is:
 
 ```
 #1 bla bla bla
 #2 yada yada
 ```
 
 That won't expand the #n references or any other GitHub syntax...
 
 There's always the Preview tab which is useful to look before
 submitting the comment as well...
 
 And I think you can always edit your comments after you posted them
 (not sure if that will undo the link between the two PRs though.)

The problem is that in this particular case, the # lines were in the
actual commit log, not in a fancy Markdown enabled input field that you
use for commenting. That commit was simply pushed to a forked repo
afterwards, and GitHub applied its magic to what it found in the history.

We can't ask people to take special care in their commit logs in order
to prevent that, because really, this is an implementation detail of GitHub.



Daniel

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

Re: [systemd-devel] Messed up PR references on Github

[Daniel Mack]

On 06/10/2015 07:04 PM, Filipe Brandenburger wrote:
 On Wed, Jun 10, 2015 at 12:23 AM, Jan Synáček jsyna...@redhat.com wrote:
 See https://github.com/systemd/systemd/pull/5. There are multiple
 references to this PR that say user referenced this pull request from
 a commit in commit, which is hilarious, as those clearly are not
 references to this PR. Their commit messages contain the string #5 and
 Github thinks it means a reference. I'm pretty sure this will mess up a
 lot of pull requests in the future. Is there a way to fix this?
 
 If you learn one thing about Markdown (or GitHub Markdown), learn that
 a block delimited by ``` lines makes it a verbatim literal (think
 pre in HTML terms), so when pasting output the best is:
 
 ```
 #1 bla bla bla
 #2 yada yada
 ```
 
 That won't expand the #n references or any other GitHub syntax...
 
 There's always the Preview tab which is useful to look before
 submitting the comment as well...
 
 And I think you can always edit your comments after you posted them
 (not sure if that will undo the link between the two PRs though.)

The problem is that in this particular case, the # lines were in the
actual commit log, not in a fancy Markdown enabled input field that you
use for commenting. That commit was simply pushed to a forked repo
afterwards, and GitHub applied its magic to what it found in the history.

We can't ask people to take special care in their commit logs in order
to prevent that, because really, this is an implementation detail of GitHub.



Daniel

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

Re: [systemd-devel] [PATCH 0/2] Using XML entities for paths in manpages

[Daniel Mack]

On 06/02/2015 03:50 PM, Filipe Brandenburger wrote:
 Hi Daniel,
 
 On Tue, Jun 2, 2015 at 3:04 AM, Daniel Mack dan...@zonque.org wrote:
 On 06/02/2015 11:25 AM, Martin Pitt wrote:
 FTR, this works fine here, using --with-rootprefix= (to avoid the
 extra slashes). This spawned a long thread and multiple followup
 patches, and TBH I lost track which patches got proposed and which are
 superseded; but this one looks good to me. Thank you!

 Michael came up with a nicer approach to sanitize all path arguments to
 configure and strip trailing slashes before the Makefile variables are
 substituted. I think we should go for that. I'll collect patches and
 prepare a pull request later.
 
 This is the one patch which does path AX_NORMALIZE_PATH that we're
 still missing:
 https://github.com/systemd/systemd/commit/d10b3a45b17403ce8a52680703b03888ebee0769
 
 I resent Michael's original patch but including the import of the
 latest ax_normalize_path.m4 from autoconf-archive.
 
 I also tested it with a few combinations including --with-rootpath=/
 and it worked fine.
 
 I could create a PR in systemd-devs GitHub if you'd like, otherwise
 feel free to just push it straight upstream if you prefer.

Nope, let's try to get used to the new workflow. Just create the PR :)


Thanks,
Daniel

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

Re: [systemd-devel] [ANNOUNCE] Git development moved to github

[Daniel Mack]

On 06/02/2015 02:19 PM, Jason A. Donenfeld wrote:
 On Tue, Jun 2, 2015 at 1:06 PM, David Herrmann dh.herrm...@gmail.com wrote:
 Regarding the final github address: David Strauss kindly offered the
 'systemd' user to us. Hence, we hope to move the repository to
 github.com/systemd/systemd this week. Sorry for the confusion, I hope
 we can settle all this this week.
 
 I recommend you get this sorted out as soon as possible and not wait
 another moment. People have already submitted pull requests to both
 repos, and things are going to get quite confusing if you don't move
 fast on this.

It's sorted out now. https://github.com/systemd/systemd is now the
official upstream. The old repo from systemd-devs was transferred
withing GitHub, which means that the old web and ssh URLs are currently
redirected automatically. However, we will remove the systemd-devs
organization any time soon to avoid further confusion.


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

Re: [systemd-devel] [PATCH 1/2] configure.ac: strip off trailing slashed from $rootprefix

[Daniel Mack]

On 05/30/2015 08:50 AM, Mike Gilbert wrote:
 On Fri, May 29, 2015 at 8:05 PM, Daniel Mack dan...@zonque.org wrote:
 Make sure the variable set via --with-rootprefix= does not contain a
 trailing slash, so man pages can use entities like rootprefix;/lib
 without ending up having double slashes.
 ---
  configure.ac | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/configure.ac b/configure.ac
 index 92654a6..55b73de 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -1396,7 +1396,8 @@ AC_ARG_WITH([zshcompletiondir],

  AC_ARG_WITH([rootprefix],
  AS_HELP_STRING([--with-rootprefix=DIR], [rootfs directory prefix 
 for config files and kernel modules]),
 -[], [with_rootprefix=${ac_default_prefix}])
 +[with_rootprefix=`echo ${withval} | sed -e s,/*$,,`],
 +[with_rootprefix=${ac_default_prefix}])
 
 Why do you pipe it through sed when a simple shell parameter expansion would 
 do?
 
 with_rootprefix=${withval%/}

Isn't that's a bash'ism which we try to avoid at other places? FWIW, we
use sed to strip off trailing dashes from $host for EFI_ARCH. Also, that
one only replaces one trailing slash, not all of them.

Anyway, Michael's AX_NORMALIZE_PATH approach seems to do the right
thing, so let's go for that.


Thanks,
Daniel

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

Re: [systemd-devel] systemctl as non-root

[Daniel Mack]

On 05/29/2015 05:26 AM, Andrei Borzenkov wrote:
 If you do not use D-Bus daemon systemd will be listening on private
 socket. In this case the only check it does is that peer runs as UID=0
 (note - not EUID, so suid does not really help).
 
 I wonder how access control is implemented in kdbus case.

kdbus implements its own policy logic to allow given UIDs to talk to,
see, or own well-known-names. See kdbus.policy(7) in the standalone
kdbus repository.

For individual method calls, kdbus can optionally pass a number of
metadata along, so services can in some cases make authorization
decisions based on them, without talking to polkit. This is similar to
SCM_CREDENTIALS on sockets but offers a lot more information.


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

Re: [systemd-devel] [PATCH 0/2] Using XML entities for paths in manpages

[Daniel Mack]

On 05/29/2015 05:18 AM, Michael Biebl wrote:
 2015-05-28 19:47 GMT+02:00 Filipe Brandenburger filbran...@google.com:
 We're actually still missing a small part of it (A sentence like
 Files in /etc have the highest priority, files in /run take
 precedence over files with the same name in */usr/lib*. in files like
 hwdb.xml, the last /usr/lib won't get fixed) but it requires new
 variables. I'm leaning towards introducing a rootsysconfdir=/etc and
 rootlibdir=$(rootprefix)/lib (we already have a rootbindir) so I'll
 follow up with a patch doing that.

 Though having the first patchset in certainly helps.
 
 Indeed. I just ran my small shell script which I used to generate the
 original diff over current git head.
 The only occurences which it still replaces can be found at [1].
 It's like you said, the override bits which are still missing.
 Otherwise it looks fine.

Could you try the attached patch?

I had to introduce a new entity in custom-entites.ent, because with
--with-rootprefix=/, rootprefix;/lib resolves to //lib, and with
the default behaviour of configure, rootprefix;lib becomes /usrlib.

That is solved with a subsitiution in Makefile.am now, which cleans up
all double slashes in custom-entites.ent.


Thanks,
Daniel

From f60d5707246d3a1ce8bcb11f3874ef696425a446 Mon Sep 17 00:00:00 2001
From: Daniel Mack dan...@zonque.org
Date: Fri, 29 May 2015 10:53:35 +0200
Subject: [PATCH] Makefile, man: replace hard-coded /usr/lib

Replace some /usr/lib occurences in man/ with a new rootprefixlibdir;
entity, and define it in Makefile.am.

Also make sure to avoid leading double slashes in path names in
custom-entities.ent, which otherwise occur with

  ./configure --enable-split-usr --with-rootprefix=/
---
 Makefile.am | 4 +++-
 man/hwdb.xml| 4 ++--
 man/systemd.link.xml| 4 ++--
 man/systemd.netdev.xml  | 4 ++--
 man/systemd.network.xml | 4 ++--
 man/udev.xml| 4 ++--
 6 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index e4a8616..cf3742c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -105,6 +105,7 @@ systemsleepdir=$(rootlibexecdir)/system-sleep
 systemunitdir=$(rootprefix)/lib/systemd/system
 systempresetdir=$(rootprefix)/lib/systemd/system-preset
 udevlibexecdir=$(rootprefix)/lib/udev
+rootprefixlibdir=$(rootprefix)/lib
 udevhomedir=$(udevlibexecdir)
 udevrulesdir=$(udevlibexecdir)/rules.d
 udevhwdbdir=$(udevlibexecdir)/hwdb.d
@@ -6500,6 +6501,7 @@ substitutions = \
'|includedir=$(includedir)|' \
'|VERSION=$(VERSION)|' \
'|rootprefix=$(rootprefix)|' \
+   '|rootprefixlibdir=$(rootprefixlibdir)|' \
'|udevlibexecdir=$(udevlibexecdir)|' \
'|SUSHELL=$(SUSHELL)|' \
'|SULOGIN=$(SULOGIN)|' \
@@ -6605,7 +6607,7 @@ if ENABLE_MANPAGES
 man/custom-entities.ent: configure.ac
 	$(AM_V_GEN)$(MKDIR_P) $(dir $@)
 	$(AM_V_GEN)(echo '?xml version=1.0 encoding=utf-8 ?'  \
-	 printf '$(subst '|,!ENTITY ,$(subst =, ,$(subst |',\n,$(substitutions') \
+	 printf '$(subst '|,!ENTITY ,$(subst =, ,$(subst |',\n,$(subst =//,=/,$(substitutions)') \
 	  $@ # '
 
 DISTCLEANFILES += \
diff --git a/man/hwdb.xml b/man/hwdb.xml
index b3602ac..60763e2 100644
--- a/man/hwdb.xml
+++ b/man/hwdb.xml
@@ -50,10 +50,10 @@
   regardless of the directories in which they live. However, files with
   identical filenames replace each other. Files in filename/etc/filename
   have the highest priority, files in filename/run/filename take precedence
-  over files with the same name in filename/usr/lib/filename. This can be
+  over files with the same name in filenamerootprefixlibdir;/filename. This can be
   used to override a system-supplied hwdb file with a local file if needed;
   a symlink in filename/etc/filename with the same name as a hwdb file in
-  filename/usr/lib/filename, pointing to filename/dev/null/filename,
+  filenamerootprefixlibdir;/filename, pointing to filename/dev/null/filename,
   disables the hwdb file entirely. hwdb files must have the extension
   filename.hwdb/filename; other extensions are ignored./para
 
diff --git a/man/systemd.link.xml b/man/systemd.link.xml
index 75cf6e1..001df38 100644
--- a/man/systemd.link.xml
+++ b/man/systemd.link.xml
@@ -70,10 +70,10 @@
 However, files with identical filenames replace each other. Files
 in filename/etc/filename have the highest priority, files in
 filename/run/filename take precedence over files with the same
-name in filename/usr/lib/filename. This can be used to
+name in filenamerootprefixlibdir;/filename. This can be used to
 override a system-supplied link file with a local file if needed;
 a symlink in filename/etc/filename with the same name as a
-link file in filename/usr/lib/filename, pointing to
+link file in filenamerootprefixlibdir;/filename, pointing to
 filename/dev/null/filename, disables the link file
 entirely./para
 
diff --git a/man

Re: [systemd-devel] [systemd-commits] Makefile.am

[Daniel Mack]

On 05/29/2015 12:07 PM, Lennart Poettering wrote:
 On Fri, 29.05.15 03:03, Daniel Mack (zon...@kemper.freedesktop.org) wrote:
 
  Makefile.am |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 New commits:
 commit 6096d9ccc3f0b963010a47febce7e44c8632c23b
 Author: Daniel Mack dan...@zonque.org
 Date:   Fri May 29 12:00:58 2015 +0200

 Makefile: make custom-entities.ent depend on Makefile.am
 
 When Makefile.am is modified, make sure custom-entities.ent is rebuilt.
 After all, $(substitutions) is defined there, so changes of that variable
 must be reflected in the resulting file.
 
 Hmm, so we used have a lot of rules like this that mathematically
 correctly rebuilt really everything touched by a change. However, this
 resulted in soo much wasted build time, that we removed parts of it
 again, even if this means that some man pages might be slightly out of
 date if the Makefile.am changes.
 
 hence: what is the impact of this change precisely? does this mean a
 slight change of the makefile will always result in all man pages to
 be rebuilt? we don#t do that for the C compilation logic when a
 Makefile.am changes, so should we do this in this case?

This came up during the hackery around the custom entity logic. With
changes to what $substitutions in Makefile.am contains, the resulting
file man/custom-entities.ent was never rebuilt, and hence went out of
date and had to be deleted manually.

But yes, that means the man pages will now be rebuilt every time
Makefile.am is touched of course.


Daniel

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

Re: [systemd-devel] [PATCH 0/2] Using XML entities for paths in manpages

[Daniel Mack]

On 05/29/2015 07:37 PM, Filipe Brandenburger wrote:
 I haven't tested it, but I do have a few comments.
 
 First, why not use rootlibdir instead of rootprefixlibdir?

Because $(rootlibdir) resolves to /usr/lib64 on my system.

[...]

 On Fri, May 29, 2015 at 2:05 AM, Daniel Mack dan...@zonque.org wrote:
 I had to introduce a new entity in custom-entites.ent, because with
 --with-rootprefix=/, rootprefix;/lib resolves to //lib, and with
 the default behaviour of configure, rootprefix;lib becomes /usrlib.
 
 Debian is already using --with-rootprefix= (an empty string) exactly
 for that reason.
 http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/rules#n16

Interesting, thanks for the pointer.

 If rootprefix=/, there would be also problems with rootbindir=//bin
 and other such definitions getting double slashes.
 
 Having said that, I do agree that it would be nice to handle
 --with-rootprefix=/ correctly without creating double slashes, but I
 think it would be preferrable to handle that in general and not for
 the specific case of /lib.

Yes, the subst logic I added replaces _all_ leading double slashes, and
hence avoids touching URLs with http://;.

 Perhaps just remove any trailing slashes from rootprefix in
 configure.ac instead before generating the Makefile? That would also
 handle cases like --with-rootprefix=/usr/ to still generate /usr/bin
 and /usr/lib correctly.

Yes, that's actually better, you're right. I'll post a patch for this.


Thanks,
Daniel

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

[systemd-devel] [PATCH 2/2] man: replace hard-coded /usr/lib

[Daniel Mack]

Replace some /usr/lib occurences in man/ with rootprefix;/lib.
---
 man/hwdb.xml| 4 ++--
 man/systemd.link.xml| 4 ++--
 man/systemd.netdev.xml  | 4 ++--
 man/systemd.network.xml | 4 ++--
 man/udev.xml| 4 ++--
 5 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/man/hwdb.xml b/man/hwdb.xml
index b3602ac..e6215df 100644
--- a/man/hwdb.xml
+++ b/man/hwdb.xml
@@ -50,10 +50,10 @@
   regardless of the directories in which they live. However, files with
   identical filenames replace each other. Files in 
filename/etc/filename
   have the highest priority, files in filename/run/filename take 
precedence
-  over files with the same name in filename/usr/lib/filename. This can 
be
+  over files with the same name in filenamerootprefix;/lib/filename. 
This can be
   used to override a system-supplied hwdb file with a local file if needed;
   a symlink in filename/etc/filename with the same name as a hwdb file 
in
-  filename/usr/lib/filename, pointing to 
filename/dev/null/filename,
+  filenamerootprefix;/lib/filename, pointing to 
filename/dev/null/filename,
   disables the hwdb file entirely. hwdb files must have the extension
   filename.hwdb/filename; other extensions are ignored./para
 
diff --git a/man/systemd.link.xml b/man/systemd.link.xml
index 75cf6e1..5db0684 100644
--- a/man/systemd.link.xml
+++ b/man/systemd.link.xml
@@ -70,10 +70,10 @@
 However, files with identical filenames replace each other. Files
 in filename/etc/filename have the highest priority, files in
 filename/run/filename take precedence over files with the same
-name in filename/usr/lib/filename. This can be used to
+name in filenamerootprefix;/lib/filename. This can be used to
 override a system-supplied link file with a local file if needed;
 a symlink in filename/etc/filename with the same name as a
-link file in filename/usr/lib/filename, pointing to
+link file in filenamerootprefix;/lib/filename, pointing to
 filename/dev/null/filename, disables the link file
 entirely./para
 
diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml
index 6cd77ab..786c7d4 100644
--- a/man/systemd.netdev.xml
+++ b/man/systemd.netdev.xml
@@ -81,10 +81,10 @@
 identical filenames replace each other. Files in
 filename/etc/filename have the highest priority, files in
 filename/run/filename take precedence over files with the same
-name in filename/usr/lib/filename. This can be used to
+name in filenamerootprefix;/lib/filename. This can be used to
 override a system-supplied configuration file with a local file if
 needed; a symlink in filename/etc/filename with the same name
-as a configuration file in filename/usr/lib/filename, pointing
+as a configuration file in filenamerootprefix;/lib/filename, pointing
 to filename/dev/null/filename, disables the configuration file
 entirely./para
 
diff --git a/man/systemd.network.xml b/man/systemd.network.xml
index 0b9781f..bd061c2 100644
--- a/man/systemd.network.xml
+++ b/man/systemd.network.xml
@@ -77,10 +77,10 @@
 identical filenames replace each other. Files in
 filename/etc/filename have the highest priority, files in
 filename/run/filename take precedence over files with the same
-name in filename/usr/lib/filename. This can be used to
+name in filenamerootprefix;/lib/filename. This can be used to
 override a system-supplied configuration file with a local file if
 needed; a symlink in filename/etc/filename with the same name
-as a configuration file in filename/usr/lib/filename, pointing
+as a configuration file in filenamerootprefix;/lib/filename, pointing
 to filename/dev/null/filename, disables the configuration file
 entirely./para
 
diff --git a/man/udev.xml b/man/udev.xml
index f7ebaad..d5d8a17 100644
--- a/man/udev.xml
+++ b/man/udev.xml
@@ -65,10 +65,10 @@
   regardless of the directories in which they live. However, files with
   identical filenames replace each other. Files in 
filename/etc/filename
   have the highest priority, files in filename/run/filename take 
precedence
-  over files with the same name in filename/usr/lib/filename. This can 
be
+  over files with the same name in filenamerootprefix;/lib/filename. 
This can be
   used to override a system-supplied rules file with a local file if 
needed;
   a symlink in filename/etc/filename with the same name as a rules 
file in
-  filename/usr/lib/filename, pointing to 
filename/dev/null/filename,
+  filenamerootprefix;/lib/filename, pointing to 
filename/dev/null/filename,
   disables the rules file entirely. Rule files must have the extension
   filename.rules/filename; other extensions are ignored./para
 
-- 
2.4.0

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org

[systemd-devel] [PATCH 1/2] configure.ac: strip off trailing slashed from $rootprefix

[Daniel Mack]

Make sure the variable set via --with-rootprefix= does not contain a
trailing slash, so man pages can use entities like rootprefix;/lib
without ending up having double slashes.
---
 configure.ac | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configure.ac b/configure.ac
index 92654a6..55b73de 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1396,7 +1396,8 @@ AC_ARG_WITH([zshcompletiondir],
 
 AC_ARG_WITH([rootprefix],
 AS_HELP_STRING([--with-rootprefix=DIR], [rootfs directory prefix for 
config files and kernel modules]),
-[], [with_rootprefix=${ac_default_prefix}])
+[with_rootprefix=`echo ${withval} | sed -e s,/*$,,`],
+[with_rootprefix=${ac_default_prefix}])
 
 AC_ARG_WITH([rootlibdir],
 AS_HELP_STRING([--with-rootlibdir=DIR], [Root directory for libraries 
necessary for boot]),
-- 
2.4.0

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

Re: [systemd-devel] [systemd-commits] Makefile.am

[Daniel Mack]

On 05/29/2015 06:53 PM, Lennart Poettering wrote:
 On Fri, 29.05.15 09:45, Filipe Brandenburger (filbran...@google.com) wrote:

 Atm, man/custom-entities.ent is only cleaned up on make distclean.
 I think we should move that from DISTCLEANFILES to CLEANFILES.

 Yes I think that's a good start and `make clean` will trigger a
 rebuild of most of what depends on custom-entities.ent anyways so I
 wouldn't expect a lot of spurious rebuilds due to that.
 
 Yeah, makes sense. Anyone cares to prep a patch for this?

Pushed now. I reverted the Makefile.am dependency again and move
custom-entities.ent from DISTCLEANFILES to CLEANFILES.


Thanks,
Daniel


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

Re: [systemd-devel] [PATCH 1/2] configure.ac: strip off trailing slashed from $rootprefix

[Daniel Mack]

On 05/30/2015 02:21 AM, Michael Biebl wrote:
 2015-05-30 2:05 GMT+02:00 Daniel Mack dan...@zonque.org:
 Make sure the variable set via --with-rootprefix= does not contain a
 trailing slash, so man pages can use entities like rootprefix;/lib
 without ending up having double slashes.
 ---
  configure.ac | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/configure.ac b/configure.ac
 index 92654a6..55b73de 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -1396,7 +1396,8 @@ AC_ARG_WITH([zshcompletiondir],

  AC_ARG_WITH([rootprefix],
  AS_HELP_STRING([--with-rootprefix=DIR], [rootfs directory prefix 
 for config files and kernel modules]),
 -[], [with_rootprefix=${ac_default_prefix}])
 +[with_rootprefix=`echo ${withval} | sed -e s,/*$,,`],
 +[with_rootprefix=${ac_default_prefix}])

  AC_ARG_WITH([rootlibdir],
  AS_HELP_STRING([--with-rootlibdir=DIR], [Root directory for 
 libraries necessary for boot]),
 
 autoconf already strips trailing slashes for all default directory
 variables [1].
 I think we should do the same for *all* our custom --with-$foo-dir
 variables, not just rootlibdir.
 
 Maybe provide a custom macro for that and apply that to
 
   --with-html-dir=PATHpath to installed docs
   --with-efi-libdir=PATH  Path to EFI lib directory
   --with-efi-ldsdir=PATH  Path to EFI lds directory
   --with-efi-includedir=PATH
   --with-dbuspolicydir=DIR
   --with-dbussessionservicedir=DIR
   --with-dbussystemservicedir=DIR
   --with-bashcompletiondir=DIR
   --with-zshcompletiondir=DIR
   --with-rootprefix=DIR   rootfs directory prefix for config files and kernel
   --with-rootlibdir=DIR   Root directory for libraries necessary for boot
   --with-pamlibdir=DIRDirectory for PAM modules
   --with-pamconfdir=DIR   Directory for PAM configuration
 
 WDYT?

Fine for me, just go ahead if you have an implementation in mind :)


Thanks,
Daniel

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

Re: [systemd-devel] [PATCH 0/2] Using XML entities for paths in manpages

[Daniel Mack]

On 05/27/2015 03:04 PM, Lennart Poettering wrote:
 Hmm, any chance we can somehow define those entities without having to
 add 
 
  !ENTITY % entities SYSTEM custom-entities.ent 
  %entities;
  ]
 
 To each file? Can't we tell xsltproc about this via some command line
 switch or so?
 
 This is in a way similar to how we use gcc's -include config.h
 switch rather than really write #include config.h in each source
 file...

I've looked for some way to do this, but haven't found a nice solution
yet. The problem is that the full XML tag is:

!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN
  http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd; [
   !ENTITY % entities SYSTEM custom-entities.ent 
   %entities;
]

So that !ENTITY tag needs to live inside the !DOCTYPE tag, which is not
something you can achieve with a command line switch AFAICS.

We could maybe add some hack to the xsl we feed xsltproc with, but
frankly, the above is the common way of including files to define own
entities, so it'd consider that more readable, even though it's a bit
more boilerplate.


Daniel

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

Re: [systemd-devel] [PATCH] sd-bus: fix memory leak in test-bus-chat

[Daniel Mack]

On 05/10/2015 03:14 AM, Cristian Rodríguez wrote:
 Building with address sanitizer enabled on GCC 5.1.x a memory leak
 is reported because we never close the bus, fix it by using
 cleanup variable attribute.
 ---
  src/libsystemd/sd-bus/test-bus-chat.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)
 
 diff --git a/src/libsystemd/sd-bus/test-bus-chat.c 
 b/src/libsystemd/sd-bus/test-bus-chat.c
 index 99261fa..1e50dfc 100644
 --- a/src/libsystemd/sd-bus/test-bus-chat.c
 +++ b/src/libsystemd/sd-bus/test-bus-chat.c
 @@ -262,7 +262,7 @@ fail:
  
  static void* client1(void*p) {
  _cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
 -sd_bus *bus = NULL;
 +_cleanup_bus_close_unref_ sd_bus *bus = NULL;
  sd_bus_error error = SD_BUS_ERROR_NULL;
  const char *hello;
  int r;
 @@ -345,8 +345,6 @@ finish:
  else
  sd_bus_send(bus, q, NULL);
  
 -sd_bus_flush(bus);

We should still keep this flush, right?

 -sd_bus_unref(bus);
  }
  
  sd_bus_error_free(error);
 

Thanks,
Daniel

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

Re: [systemd-devel] [PATCH] treewide: Correct typos and spell plural of bus consistent

[Daniel Mack]

On 05/11/2015 01:49 PM, Torstein Husebø wrote:
 ---
  man/hwdb.xml  | 2 +-
  man/nss-myhostname.xml| 2 +-
  man/sd_bus_creds_get_pid.xml  | 2 +-
  man/sd_bus_default.xml| 2 +-
  man/sd_bus_message_append.xml | 2 +-
  man/sd_bus_message_get_monotonic_usec.xml | 2 +-
  man/sd_event_wait.xml | 2 +-
  man/systemctl.xml | 2 +-
  man/systemd-activate.xml  | 4 ++--
  man/systemd-coredump.xml  | 2 +-
  man/systemd-delta.xml | 2 +-
  man/systemd-fstab-generator.xml   | 2 +-
  man/systemd-journal-remote.xml| 2 +-
  man/systemd-nspawn.xml| 4 ++--
  man/systemd.generator.xml | 2 +-
  man/systemd.journal-fields.xml| 2 +-
  man/systemd.mount.xml | 2 +-
  man/systemd.netdev.xml| 6 +++---
  man/systemd.service.xml   | 6 +++---
  src/analyze/analyze-verify.c  | 2 +-
  src/core/dbus.c   | 2 +-
  src/core/main.c   | 2 +-
  src/core/manager.c| 2 +-
  src/gudev/gudevdevice.c   | 2 +-
  src/libsystemd/libsystemd.sym.m4  | 2 +-
  src/libsystemd/sd-bus/bus-kernel.c| 2 +-
  src/libsystemd/sd-rtnl/rtnl-message.c | 2 +-
  src/locale/localectl.c| 4 ++--
  src/shared/barrier.c  | 2 +-
  src/systemctl/systemctl.c | 4 ++--
  src/test/test-sleep.c | 2 +-
  src/udev/udev-builtin-keyboard.c  | 2 +-
  32 files changed, 40 insertions(+), 40 deletions(-)

Nice catches, thanks a lot.

Busses is actually a valid plural form of bus, just like buses is,
but making it consistent is a good idea.


Applied, thanks.

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

[systemd-devel] [HEADSUP] Removal of shutdownd

[Daniel Mack]

The only purpose of the little helper daemon called shutdownd is to keep
track and execute a scheduled shutdown. It prints utmp wall
notifications to TTYs in periodic intervals, makes sure to create the
/run/nologin and /run/systemd/shutdown/scheduled files, and eventually,
once the timeout is reached, it executes systemctl again to really shut
down / reboot / halt the machine. It is socket activated and
communicates with systemctl via a proprietary protocol.

The current procedure for a scheduled shutdown looks like this:

 * shutdown (aka systemctl) is executed with a time argument
   (for instance, 'shutdown -h 18:00').

 * As an execution time for the command was given, systemctl
   communicates with shutdownd via its private socket,
   possibly activating it that way.

 * shutdownd waits for the timer to elapse

 * shutdownd executes 'shutdown' (aka systemctl)

 * This time, the action is immediate, hence systemctl
   directly communicates with PID1 in order to start the
   appropriate shutdown unit.


I have now reworked all this and moved the code from shutdownd into
logind, which already has the logic for inhibitors and other timers.

For this, logind learned two new methods on its DBus-interface:

  .ScheduleShutdown()
  .CancelScheduledShutdown()

and three more properties:

  .ScheduledShutdown()  [r]
  .EnableWallMessages() [rw]
  .WallMessage  [rw]


systemctl now talks to logind instead to shutdownd, and the procedure
looks like this:

 * shutdown (aka systemctl) is executed with a time argument
   (for instance, 'shutdown -h 18:00').

 * As an execution time for the command was given, systemctl
   communicates with logind via DBus in order to schedule the
   shutdown.

 * logind waits for the timer to elapse and, given that there
   are no inhibitors preventing it, directly communicates with
   PID1 in order to start the appropriate shutdown unit.

shutdownd was killed entirely. As a result, we have one less daemon
lurking around, a nice DBus-API for something that used to be
proprietary, and even less code:

 20 files changed, 727 insertions(+), 905 deletions(-)

However, this means that direct users of the shutdownd socket have to
migrate to the DBus interface. We are only aware of one such user, which
is Cockpit, and Stef Walter (Cc) already signaled his agreement on this
change.

The patches are now pushed. They have been reviewed by Lennart before
and I tested it for a while, but as always, we appreciate more testers
for such a rework :)


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

Re: [systemd-devel] [PATCH] util: fix typo

[Daniel Mack]

On 04/20/2015 07:27 AM, Raul Gutierrez S wrote:
 Signed-off-by: Raul Gutierrez S r...@itevenworks.net

This isn't needed in the systemd project, so I dropped it.

Applied, thanks!


 ---
  src/shared/util.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/src/shared/util.c b/src/shared/util.c
 index 53f8488..f14d9ee 100644
 --- a/src/shared/util.c
 +++ b/src/shared/util.c
 @@ -1700,7 +1700,7 @@ int parse_size(const char *t, off_t base, off_t *size) {
   * sometimes SI decimal suffixes. This function can parse
   * both. Which one is the right way depends on the
   * context. Wikipedia suggests that SI is customary for
 - * hardrware metrics and network speeds, while IEC is
 + * hardware metrics and network speeds, while IEC is
   * customary for most data sizes used by software and volatile
   * (RAM) memory. Hence be careful which one you pick!
   *
 

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

Re: [systemd-devel] Adopt processes spawned before /lib/systemd/systemd takes over as PID 1?

[Daniel Mack]

On 04/18/2015 05:29 AM, Matt Hoosier wrote:
 On Fri, Apr 17, 2015 at 3:52 PM, Cristian Rodríguez
 crrodrig...@opensuse.org mailto:crrodrig...@opensuse.org wrote:

 Did you watch this presentation ?
 
 https://www.youtube.com/watch?v=RFVlbaDqll8
 
 what part of systemd is taking 1.5 seconds to start, on what CPU and
 how much of RAM does the board has ?
 
 
 Thanks, I hadn't found that presentation before. My board is essentially
 a Panda ES, with gigabytes of RAM.
 
 A small point of clarification: when I say that systemd takes 1.5
 seconds, I'm referring to the time that elapses between the moment that
 /lib/systemd/systemd is exec'ed and the time that the first unit is
 shown in the 'systemd-analyze plot'. I haven't done an internal profile
 on the systemd binary to see what might be happening during that window yet.

Does it spend significant time in loading modules from kmod-setup.c
maybe? Maybe adding 'debug' to your kernel command line gives you a hint.

 Could you say a word more about the sys_accept4() and /sys/fs/cgroup
 issue? Was its only symptom that it caused systemd to run slower?

That was a udev issue which should not affect you anymore with recent
kernel versions (note the presentation is from 2011). It certainly has
nothing to do with the effect you're seeing.


Daniel

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

Re: [systemd-devel] issuing 'reboot' command does not print the familiar 'Restarting system.' message

[Daniel Mack]

On 04/12/2015 03:46 PM, Lennart Poettering wrote:
 On Fri, Apr 10, 2015 at 10:18 AM, Ani Sinha a...@arista.com wrote:

 OK I see it now. shutdownd.c eventually issues 'shutdown -r now'. This
  gets parsed by shutdown_parse_argv(). Eventually we end up calling
  halt_main() -halt_now() -reboot(RB_AUTOBOOT).
 Hmm?
 
 shutdownd's only raison d'etre is to support scheduled shutdowns. It's
 not used unless you actually use scheduled shutdowns. If you just use
 systemctl poweroff or so, then it will *not* be used at all, and is
 not involved at all in the shutdown logic.
 
 And no! shutdownd will never call halt_main(), nor halt_now(), nor
 reboot(RB_AUTOBOUT). If you use shutdownd, then this will result in
 the equiavlent of systemctl poweroff and so on, just delayed a bit.
 
 Please don't confuse shutdownd.c and shutdown.c. The former is just
 there for the scheduled shutdown bits, the latter is the always used
 last part of the shutdown logic.

Also note that shutdownd is one of the oldest pieces of code in the
systemd project. I'm currently working on patches to replace it entirely
with a DBus API in logind.


Thanks,
Daniel

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

Re: [systemd-devel] dbus-1/kdbus - question about 'queued owners'

[Daniel Mack]

Hi Lukasz,

[+dbus ML]

On 04/10/2015 04:20 PM, Lukasz Skalski wrote:
 Currently I'm working on some testsuite (let's call it dbus1-spec-test)
 for dbus-1 specification. My idea is to test dbus-1 specification
 coverage on systems with dbus-daemon and on systems without dbus-daemon
 (but with latest systemd, bus-proxyd and kdbus) which will allow us (and
 all userspace apps) to smoothly switch to kdbus. First results of tests
 are really good:

Nice, thanks a lot for doing this!

 My testsuite have found only one inconsistency between dbus-1 and
 kdbus-enabled system. Problematic testcase (this one tests rather some
 dbus-daemon/bus-proxyd behaviors than specification) is as follow:
 
 test_request_name_6 (void)
 {
   GDBusConnection *connection_a;
   GDBusConnection *connection_b;
 
   BusRequestNameFlagsReply request_reply;
   BusReleaseNameFlagsReply release_reply;
 
   /* connect and set up two D-Bus client connections */
   connection_a = connect_to_bus();
   connection_b = connect_to_bus();
 
   /* 'connection_a' - synchronously acquire name on the bus */
   request_reply = request_name (connection_a, org.my.busname,
 DBUS_NAME_FLAG_REPLACE_EXISTING |
 DBUS_NAME_FLAG_DO_NOT_QUEUE);
 
   /* 'connection_a' should be primary owner */
   CU_ASSERT (request_reply == DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER);
 
   /* 'connection_b' tries to own the same well-known name */
   request_reply = request_name (connection_b, org.my.busname,
 DBUS_NAME_FLAG_REPLACE_EXISTING);
 
   /* 'connection_b' should be appended to the queue */
   CU_ASSERT (request_reply == DBUS_REQUEST_NAME_REPLY_IN_QUEUE);
 
   /* once again 'connection_b' tries to own the same name */
   request_reply = request_name (connection_b, org.my.busname,
 DBUS_NAME_FLAG_REPLACE_EXISTING);
 
   /* and once again we should get the same return code */
   CU_ASSERT (request_reply == DBUS_REQUEST_NAME_REPLY_IN_QUEUE);

The D-Bus spec isn't totally clear about the return code here, but it is
about what should happen:

If replacement is not possible, *and the method caller is currently not
in the queue*, the method caller is appended to the queue.

dbus-daemon seems to return IN_QUEUE to inform the caller that the name
is in the queue, no matter if the call it replies to was responsible for
creating the queue entry or if that was already the case.

   /* 'connection_a' releases name */
   release_reply = release_name (connection_a, org.my.busname);
   CU_ASSERT (release_reply == DBUS_RELEASE_NAME_REPLY_RELEASED);
 
   /* 'connection_b' (now primary owner) also release name
   release_reply = release_name (connection_b, org.my.busname);
   CU_ASSERT (release_reply == DBUS_RELEASE_NAME_REPLY_RELEASED);
 
   /* 'connection_b' tries to release once again the same name */
   release_reply = release_name (connection_b, org.my.busname);
 
   /* This assert is source of failure - what we should get
  here: REPLY_RELEASED or NON_EXISTENT ? */
   CU_ASSERT (release_reply == DBUS_RELEASE_NAME_REPLY_NON_EXISTENT);

As per the spec, the same connection can only be queued up once for a
given well-known name, so the correct error code should be NON_EXISTENT.

 Which solution, kdbus or dbus-daemon, do it correctly?

kdbus is wrong here IMO. The kernel patch you sent me offlist looks
resonable. Care to rebase and post it to LKML?


Thanks,
Daniel

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

Re: [systemd-devel] [PATCH] bootchart: fix check for no fd

[Daniel Mack]

On 04/05/2015 07:03 PM, Shawn Landden wrote:
 found with coverty report

Applied, thanks!

 ---
  src/bootchart/store.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/src/bootchart/store.c b/src/bootchart/store.c
 index f19427e..f159cba 100644
 --- a/src/bootchart/store.c
 +++ b/src/bootchart/store.c
 @@ -476,7 +476,7 @@ catch_rename:
  
  /* re-fetch name */
  /* get name, start time */
 -if (!ps-sched) {
 +if (ps-sched  0) {
  sprintf(filename, %d/sched, pid);
  ps-sched = openat(procfd, filename, 
 O_RDONLY|O_CLOEXEC);
  if (ps-sched  0)
 

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

[systemd-devel] Bootchart rework

[Daniel Mack]

Hi,

With the help of Lennart and Alexander Sverdlin, I reworked major parts
of the bootchart code to make it more readable and maintainable. Most
importantly, I got rid a number of global variables that were used all
over the place, fixed tons of coding style issues and dead code. The
patches for that are now pushed.

If you encounter any problems, please speak up. The cleanup in that area
is also by far not finished - there are still many details left that
need attention.


Thanks,
Daniel

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

Re: [systemd-devel] [PATCH] systemd-bootchart: Repair Entropy Graph

[Daniel Mack]

On 03/29/2015 08:46 PM, Alexander Sverdlin wrote:
 Entropy Graph code doesn't handle the error condition if open() of /proc entry
 fails. Moreover, the file is only opened once and only first sample will 
 contain
 the correct value because the return value of pread() is also not handled
 properly and file is not re-opened. Fix both problems.

Applied, thanks!

 ---
  src/bootchart/store.c | 21 +
  1 file changed, 13 insertions(+), 8 deletions(-)
 
 diff --git a/src/bootchart/store.c b/src/bootchart/store.c
 index 8e9a62f..fb3dc9a 100644
 --- a/src/bootchart/store.c
 +++ b/src/bootchart/store.c
 @@ -119,7 +119,7 @@ void log_sample(int sample, struct list_sample_data 
 **ptr) {
  int c;
  int p;
  int mod;
 -static int e_fd;
 +static int e_fd = -1;
  ssize_t s;
  ssize_t n;
  struct dirent *ent;
 @@ -215,16 +215,21 @@ schedstat_next:
  }
 
  if (arg_entropy) {
 -if (!e_fd) {
 +if (e_fd  0) {
  e_fd = openat(procfd, 
 sys/kernel/random/entropy_avail, O_RDONLY);
 +if (e_fd == -1) {
 +log_error_errno(errno, Failed to open 
 /proc/sys/kernel/random/entropy_avail: %m);
 +exit(EXIT_FAILURE);
 +}
  }
 
 -if (e_fd) {
 -n = pread(e_fd, buf, sizeof(buf) - 1, 0);
 -if (n  0) {
 -buf[n] = '\0';
 -sampledata-entropy_avail = atoi(buf);
 -}
 +n = pread(e_fd, buf, sizeof(buf) - 1, 0);
 +if (n = 0) {
 +close(e_fd);
 +e_fd = -1;
 +} else {
 +buf[n] = '\0';
 +sampledata-entropy_avail = atoi(buf);
  }
  }
 
 

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

Re: [systemd-devel] [PATCH] systemd-bootchart: Prevent leaking file descriptors in open-fdopen combination

[Daniel Mack]

On 03/29/2015 08:44 PM, Alexander Sverdlin wrote:
 Correctly handle the potential failure of fdopen() (because of OOM, for 
 instance)
 after potentially successful open(). Prevent leaking open fd in such case.

Applied, thanks!

 ---
  src/bootchart/store.c | 12 ++--
  src/bootchart/svg.c   |  9 +
  2 files changed, 19 insertions(+), 2 deletions(-)
 
 diff --git a/src/bootchart/store.c b/src/bootchart/store.c
 index 3900936..8e9a62f 100644
 --- a/src/bootchart/store.c
 +++ b/src/bootchart/store.c
 @@ -330,9 +330,13 @@ schedstat_next:
  /* ppid */
  sprintf(filename, %d/stat, pid);
  fd = openat(procfd, filename, O_RDONLY);
 +if (fd == -1)
 +continue;
  st = fdopen(fd, r);
 -if (!st)
 +if (!st) {
 +close(fd);
  continue;
 +}
  if (!fscanf(st, %*s %*s %*s %i, p)) {
  continue;
  }
 @@ -432,9 +436,13 @@ schedstat_next:
  if (!ps-smaps) {
  sprintf(filename, %d/smaps, pid);
  fd = openat(procfd, filename, O_RDONLY);
 +if (fd == -1)
 +continue;
  ps-smaps = fdopen(fd, r);
 -if (!ps-smaps)
 +if (!ps-smaps) {
 +close(fd);
  continue;
 +}
  setvbuf(ps-smaps, smaps_buf, _IOFBF, 
 sizeof(smaps_buf));
  }
  else {
 diff --git a/src/bootchart/svg.c b/src/bootchart/svg.c
 index e1fc531..5412915 100644
 --- a/src/bootchart/svg.c
 +++ b/src/bootchart/svg.c
 @@ -170,6 +170,9 @@ static void svg_title(const char *build) {
  if (!fgets(cmdline, 255, f))
  sprintf(cmdline, Unknown);
  fclose(f);
 +} else {
 +if (fd = 0)
 +close(fd);
  }
 
  /* extract root fs so we can find disk model name in sysfs */
 @@ -185,6 +188,9 @@ static void svg_title(const char *build) {
  if (!fgets(model, 255, f))
  fprintf(stderr, Error reading disk model 
 for %s\n, rootbdev);
  fclose(f);
 +} else {
 +if (fd = 0)
 +close(fd);
  }
  }
 
 @@ -208,6 +214,9 @@ static void svg_title(const char *build) {
  }
  }
  fclose(f);
 +} else {
 +if (fd = 0)
 +close(fd);
  }
 
  svg(text class=\t1\ x=\0\ y=\30\Bootchart for %s - 
 %s/text\n,
 

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

Re: [systemd-devel] [PATCH] systemd-bootchart: Prevent closing random file descriptors

[Daniel Mack]

Hi Alexander,

On 03/29/2015 03:04 PM, Alexander Sverdlin wrote:
 On 29/03/15 13:44, Daniel Mack wrote:
 @@ -184,6 +185,7 @@ vmstat_next:
 n = pread(schedstat, buf, sizeof(buf) - 1, 0); if (n = 0) { 
 close(schedstat); +schedstat = 0;
 Note that 0 is a valid file descriptor number. You should really
 rather reset the variables to -1 and check for '= 0'. This applies
 to all hunks of this patch, which also needs a rebase onto the
 current git HEAD.
 
 I believe, it was HEAD as of time of patch submission, but I can of
 course rebase it once again. Regarding 0: everywhere in the program
 it relies on the fact that newly allocated memory is zeroed and files
 are only opened if the corresponding file descriptor field of a
 structure is 0. So do you propose to change the logic everywhere
 where the files are opened?

I see. As that code doesn't close stdin, 0 can't be returned by any
open*(), so that's not a real issues, but all code should still be
written in a way that it treats 0 as valid descriptor. So we need to
explicitly initialize fd variables to -1 after new0(), and refactor code
to where necessary.


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

Re: [systemd-devel] [PATCH] systemd-bootchart: Prevent closing random file descriptors

[Daniel Mack]

On 03/29/2015 03:13 AM, Alexander Sverdlin wrote:
 Fix it by zeroing all the closed descriptors immediately, this would repair
 existing caching of open files and clean-up strategy.
 
 The fix is important even with CONFIG_SCHED_DEBUG option enabled, because very
 first failure to open /proc/pid/* because process exited will result in some
 other victim descriptor being closed later and will therefore disturb the 
 whole
 collected statistics.
 ---
   src/bootchart/store.c | 13 +++--
   1 file changed, 11 insertions(+), 2 deletions(-)
 
 diff --git a/src/bootchart/store.c b/src/bootchart/store.c
 index dfa681f..8525f62 100644
 --- a/src/bootchart/store.c
 +++ b/src/bootchart/store.c
 @@ -152,6 +152,7 @@ void log_sample(int sample, struct list_sample_data 
 **ptr) {
   n = pread(vmstat, buf, sizeof(buf) - 1, 0);
   if (n = 0) {
   close(vmstat);
 +vmstat = 0;
   return;
   }
   buf[n] = '\0';
 @@ -184,6 +185,7 @@ vmstat_next:
   n = pread(schedstat, buf, sizeof(buf) - 1, 0);
   if (n = 0) {
   close(schedstat);
 +schedstat = 0;

Note that 0 is a valid file descriptor number. You should really rather
reset the variables to -1 and check for '= 0'. This applies to all
hunks of this patch, which also needs a rebase onto the current git HEAD.


Thanks,
Daniel

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

Re: [systemd-devel] [PATCH v2] systemd-bootchart: Prevent closing random file descriptors

[Daniel Mack]

On 03/29/2015 08:41 PM, Alexander Sverdlin wrote:
 If the kernel has no CONFIG_SCHED_DEBUG option set, systemd-bootchart produces
 empty .svg file. The reason for this is very fragile file descriptor logic in
 log_sample() and main() (/* do some cleanup, close fd's */ block). There are
 many places where file descriptors are closed on failure (missing SCHED_DEBUG
 provokes it), but there are several problems with it:
  - following iterations in the loop see that the descriptor is non zero and do
not open the corresponding file again;
  - some cleanup code closes already closed files and the descriptors are 
 reused
already, in particular for resulting .svg file;
  - static vmstat and schedstat variables in log_sample() made the 
 situation
even worse.

Looks good to me. Applied, thanks!


Daniel

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

Re: [systemd-devel] [PATCH] Fix typos

[Daniel Mack]

Applied, thanks!

On 03/09/2015 01:02 PM, Torstein Husebø wrote:
 ---
  man/systemd.network.xml | 2 +-
  src/systemd/sd-daemon.h | 2 +-
  2 files changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/man/systemd.network.xml b/man/systemd.network.xml
 index 3522551293..5d7518b348 100644
 --- a/man/systemd.network.xml
 +++ b/man/systemd.network.xml
 @@ -568,7 +568,7 @@
listitem
  paraDHCP client identifier to use. Either 
 literalmac/literal
  to use the MAC address of the link or literalduid/literal
 -(the default) to use a RFC4361-complient Client ID./para
 +(the default) to use a RFC4361-compliant Client ID./para
/listitem
  /varlistentry
  varlistentry
 diff --git a/src/systemd/sd-daemon.h b/src/systemd/sd-daemon.h
 index b878b4d8a6..861dc8f1f4 100644
 --- a/src/systemd/sd-daemon.h
 +++ b/src/systemd/sd-daemon.h
 @@ -168,7 +168,7 @@ int sd_is_mq(int fd, const char *path);
value daemons should send is READY=1.
  
   STATUS=...   Passes a single-line status string back to systemd
 -  that describes the daemon state. This is free-from
 +  that describes the daemon state. This is free-form
and can be used for various purposes: general state
feedback, fsck-like programs could pass completion
percentages and failing programs could pass a human
 

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

Re: [systemd-devel] [PATCH] fix build against v3.20-rc1

[Daniel Mack]

Hi Shawn,

On 02/19/2015 02:15 AM, Shawn Landden wrote:
 ---
  fs.c | 1 -
  1 file changed, 1 deletion(-)
 
 diff --git a/fs.c b/fs.c
 index 22ca62b..f751392 100644
 --- a/fs.c
 +++ b/fs.c
 @@ -208,7 +208,6 @@ static struct inode *fs_inode_get(struct super_block *sb,
  
   inode-i_private = kdbus_node_ref(node);
   inode-i_mapping-a_ops = empty_aops;
 - inode-i_mapping-backing_dev_info = noop_backing_dev_info;
   inode-i_mode = node-mode  S_IALLUGO;
   inode-i_atime = inode-i_ctime = inode-i_mtime = CURRENT_TIME;
   inode-i_uid = node-uid;

Thanks! I have a similar fix locally for mainline submission, but I'd
like to keep the standalone repository stable for 3.19 right now.
3.20-rc1 isn't out, hence I don't want to depend on it yet.


Best regards,
Daniel

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

Re: [systemd-devel] [PATCH] names: return EADDRINUSE if name is owned by a different connection and can't be released

[Daniel Mack]

On 02/09/2015 10:53 AM, Lukasz Skalski wrote:
 This patch fixes also problem with ReleaseName call in
 systemd-bus-proxyd.

Applied, thanks!


 
 diff --git a/names.c b/names.c
 index 5f57aa3..e85ba45 100644
 --- a/names.c
 +++ b/names.c
 @@ -266,6 +266,7 @@ static int kdbus_name_release(struct kdbus_name_registry 
 *reg,
* for items for connection.
*/
  
 + ret = -EADDRINUSE;
   list_for_each_entry_safe(q, tmp, e-queue_list, entry_entry) {
   if (q-conn != conn)
   continue;
 diff --git a/test/test-names.c b/test/test-names.c
 index 00c8ba0..66ebb47 100644
 --- a/test/test-names.c
 +++ b/test/test-names.c
 @@ -54,6 +54,7 @@ static int conn_is_name_owner(const struct kdbus_conn *conn,
  
  int kdbus_test_name_basic(struct kdbus_test_env *env)
  {
 + struct kdbus_conn *conn;
   char *name, *dot_name, *invalid_name, *wildcard_name;
   int ret;
  
 @@ -62,6 +63,14 @@ int kdbus_test_name_basic(struct kdbus_test_env *env)
   invalid_name = foo;
   wildcard_name = foo.bla.bl.*;
  
 + /* create a 2nd connection */
 + conn = kdbus_hello(env-buspath, 0, NULL, 0);
 + ASSERT_RETURN(conn != NULL);
 +
 + /* acquire name foo.bar.xxx name */
 + ret = kdbus_name_acquire(conn, foo.bar.xxx, NULL);
 + ASSERT_RETURN(ret == 0);
 +
   /* Name is not valid, must fail */
   ret = kdbus_name_acquire(env-conn, dot_name, NULL);
   ASSERT_RETURN(ret == -EINVAL);
 @@ -92,7 +101,7 @@ int kdbus_test_name_basic(struct kdbus_test_env *env)
  
   /* check that we can't release a name that we don't own */
   ret = kdbus_name_release(env-conn, foo.bar.xxx);
 - ASSERT_RETURN(ret == -ESRCH);
 + ASSERT_RETURN(ret == -EADDRINUSE);
  
   /* Name is not valid, must fail */
   ret = kdbus_name_release(env-conn, dot_name);
 @@ -104,6 +113,8 @@ int kdbus_test_name_basic(struct kdbus_test_env *env)
   ret = kdbus_name_release(env-conn, wildcard_name);
   ASSERT_RETURN(ret == -ESRCH);
  
 + kdbus_conn_free(conn);
 +
   return TEST_OK;
  }
  
 

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

Re: [systemd-devel] [PATCH] bus-proxyd: fix 'ListQueuedOwners' call

[Daniel Mack]

On 02/06/2015 05:08 PM, Lukasz Skalski wrote:
 Set proper kdbus_cmd_list object size, otherwise:

Applied, thanks!


 
 dbus-send --system --dest=org.freedesktop.DBus --type=method_call \
 print-reply / org.freedesktop.DBus.ListQueuedOwners 
 string:org.freedesktop.systemd1
 
 Error org.freedesktop.DBus.Error.InvalidArgs: Invalid argument
 
 diff --git a/src/bus-proxyd/driver.c b/src/bus-proxyd/driver.c
 index 23911c6..b275839 100644
 --- a/src/bus-proxyd/driver.c
 +++ b/src/bus-proxyd/driver.c
 @@ -350,6 +350,7 @@ int bus_proxy_process_driver(sd_bus *a, sd_bus *b, 
 sd_bus_message *m, SharedPoli
  return synthetic_reply_method_errno(m, r, NULL);
  
  cmd.flags = KDBUS_LIST_QUEUED;
 +cmd.size = sizeof(cmd);
  r = ioctl(a-input_fd, KDBUS_CMD_LIST, cmd);
  if (r  0)
  return synthetic_reply_method_errno(m, -errno, NULL);
 

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

Re: [systemd-devel] [PATCH] fs: switch to d_splice_alias()

[Daniel Mack]

On 01/29/2015 05:42 AM, Bryan Hundven wrote:
 During the 3.19 merge window, two commits in Linus's tree:
 b5ae6b15bd73e35b129408755a0804287a87e041
 =
 merge d_materialise_unique() into d_splice_alias()
 =
 and
 41d28bca2da4bd75a8915c1ccf2cacf7f4a2e531
 =
 switch d_materialise_unique() users to d_splice_alias()
 =
 
 ...requires us to switch to d_splice_alias().
 
 Signed-off-by: Bryan Hundven bryanhund...@gmail.com

Thanks! That's true, and I have the same patch locally as a fix-up the
kernel submission, after all, we did submit it as 3.19 material.

I'll wait for 3.19 to be released, and then apply your patch. There's
also another detail which uses a new API for kvec iterators. I'll add
that too.


Thanks,
Daniel



 ---
  fs.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/fs.c b/fs.c
 index 7fc5ede..33aff4b 100644
 --- a/fs.c
 +++ b/fs.c
 @@ -175,7 +175,7 @@ static struct dentry *fs_dir_iop_lookup(struct inode *dir,
   if (IS_ERR(inode))
   dnew = ERR_CAST(inode);
   else
 - dnew = d_materialise_unique(dentry, inode);
 + dnew = d_splice_alias(inode, dentry);
  
   kdbus_node_release(node);
   }
 

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

Re: [systemd-devel] [PATCH] networkd: fix a typo in networkd-wait-online-manager.

[Daniel Mack]

On 01/20/2015 12:56 PM, Rami Rosen wrote:
 subscibe-subscribe

Applied, thanks!

 
 ---
  src/network/networkd-wait-online-manager.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/src/network/networkd-wait-online-manager.c 
 b/src/network/networkd-wait-online-manager.c
 index 3f2b966..6f392fe 100644
 --- a/src/network/networkd-wait-online-manager.c
 +++ b/src/network/networkd-wait-online-manager.c
 @@ -159,7 +159,7 @@ static int manager_rtnl_listen(Manager *m) {
  
  assert(m);
  
 -/* First, subscibe to interfaces coming and going */
 +/* First, subscribe to interfaces coming and going */
  r = sd_rtnl_open(m-rtnl, 3, RTNLGRP_LINK, RTNLGRP_IPV4_IFADDR, 
 RTNLGRP_IPV6_IFADDR);
  if (r  0)
  return r;
 

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

Re: [systemd-devel] [PATCH] bus-proxyd: don't allow to acquire org.freedesktop.DBus name

[Daniel Mack]

On 01/05/2015 02:45 PM, Lukasz Skalski wrote:
 ---
  src/bus-proxyd/bus-proxyd.c | 4 
  1 file changed, 4 insertions(+)

Applied, thanks!

 
 diff --git a/src/bus-proxyd/bus-proxyd.c b/src/bus-proxyd/bus-proxyd.c
 index a7818f5..fc70cce 100644
 --- a/src/bus-proxyd/bus-proxyd.c
 +++ b/src/bus-proxyd/bus-proxyd.c
 @@ -829,6 +829,10 @@ static int process_driver(sd_bus *a, sd_bus *b, 
 sd_bus_message *m, Policy *polic
  if (r  0)
  return synthetic_reply_method_errno(m, r, NULL);
  
 +if (streq(name, org.freedesktop.DBus))
 +return synthetic_reply_method_error(m, 
 SD_BUS_ERROR_MAKE_CONST(SD_BUS_ERROR_INVALID_ARGS,
 +Connection is 
 not allowed to own the org.freedesktop.DBus service.));
 +
  if (policy  !policy_check_own(policy, ucred-uid, 
 ucred-gid, name))
  return synthetic_reply_method_errno(m, -EPERM, NULL);
  
 

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

Re: [systemd-devel] syntax error in master

[Daniel Mack]

On 11/11/2014 03:31 PM, Colin Walters wrote:
 See: 
 http://build.gnome.org/continuous/buildmaster/builds/2014/11/11/23/build/log-systemd.txt
 
 Perhaps something like this?

My bad, sorry. I had a hunk confusion due to rebasing.
It's already reverted in master.


Daniel


 
 diff --git a/src/bus-proxyd/bus-proxyd.c b/src/bus-proxyd/bus-proxyd.c
 index c5aeaac..afee131 100644
 --- a/src/bus-proxyd/bus-proxyd.c
 +++ b/src/bus-proxyd/bus-proxyd.c
 @@ -1466,11 +1466,11 @@ int main(int argc, char *argv[]) {
  if (k == -ECONNRESET)
  r = 0;
  else {
 -
 -k = process_policy(a, b, m, 
 p, ucred);
 -if (k  0) {
 -r = k;
 -log_error(Failed to 
 send message: %s, strerror(-r));
 +k = 
 process_policy(a, b, m, p, ucred);
 +if (k  0) {
 +r = k;
 +
 log_error(Failed to send message: %s, strerror(-r));
 +}
  }
  
  goto finish;
 

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

Re: [systemd-devel] [systemd-commits] man/pam_systemd.xml

[Daniel Mack]

On 10/24/2014 03:40 AM, Chris Bell wrote:
 On Thu, Oct 23, 2014 at 8:53 PM, Lennart Poettering
 -all processes of the session are terminated. If
 -the last concurrent session of a user ends, his
 -user systemd instance will be terminated too,
 -and so will the user's slice
 -unit./para/listitem
 +all processes of the session are terminated. If
 +the last concurrent session of a user ends,
 +that user's systemd instance and slice unit
 +will both be terminated./para/listitem
 ...
 -removed on his final logout. If a user
 + removed when the user logs out of
 + the last active session. If a user
 or
 + removed when the user has logged
 + out of all active sessions. If a user
 
 It's a bit more verbose, but I think it's more precise, and it
 completely sidesteps the 'singular they' debate (which I'll refrain
 from weighing in on).

Could you please send a patch that does that change?


Many thanks,
Daniel



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

Re: [systemd-devel] [PATCH] bus-proxyd: add missing flag translation for RequestName

[Daniel Mack]

On 10/14/2014 04:13 PM, Lukasz Skalski wrote:
 ---
  src/bus-proxyd/bus-proxyd.c | 12 ++--
  1 file changed, 10 insertions(+), 2 deletions(-)

Applied, thanks!


 diff --git a/src/bus-proxyd/bus-proxyd.c b/src/bus-proxyd/bus-proxyd.c
 index 52498f3..6ff0e8c 100644
 --- a/src/bus-proxyd/bus-proxyd.c
 +++ b/src/bus-proxyd/bus-proxyd.c
 @@ -845,7 +845,7 @@ static int process_driver(sd_bus *a, sd_bus *b, 
 sd_bus_message *m) {
  
  } else if (sd_bus_message_is_method_call(m, org.freedesktop.DBus, 
 RequestName)) {
  const char *name;
 -uint32_t flags;
 +uint32_t flags, param;
  
  r = sd_bus_message_read(m, su, name, flags);
  if (r  0)
 @@ -856,7 +856,15 @@ static int process_driver(sd_bus *a, sd_bus *b, 
 sd_bus_message *m) {
  if ((flags  
 ~(BUS_NAME_ALLOW_REPLACEMENT|BUS_NAME_REPLACE_EXISTING|BUS_NAME_DO_NOT_QUEUE))
  != 0)
  return synthetic_reply_method_errno(m, -EINVAL, 
 NULL);
  
 -r = sd_bus_request_name(a, name, flags);
 +param = 0;
 +if (flags  BUS_NAME_ALLOW_REPLACEMENT)
 +param |= SD_BUS_NAME_ALLOW_REPLACEMENT;
 +if (flags  BUS_NAME_REPLACE_EXISTING)
 +param |= SD_BUS_NAME_REPLACE_EXISTING;
 +if (!(flags  BUS_NAME_DO_NOT_QUEUE))
 +param |= SD_BUS_NAME_QUEUE;
 +
 +r = sd_bus_request_name(a, name, param);
  if (r  0) {
  if (r == -EEXIST)
  return synthetic_reply_method_return(m, u, 
 BUS_NAME_EXISTS);
 

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

Re: [systemd-devel] [PATCH] man: fix typos

[Daniel Mack]

On 10/15/2014 10:46 AM, Jan Synacek wrote:
 ---
  man/systemd.service.xml | 6 +++---
  man/systemd.socket.xml  | 2 +-
  man/systemd.swap.xml| 2 +-
  3 files changed, 5 insertions(+), 5 deletions(-)

Applied, thanks!

 
 diff --git a/man/systemd.service.xml b/man/systemd.service.xml
 index 50ff2f5..b9604b8 100644
 --- a/man/systemd.service.xml
 +++ b/man/systemd.service.xml
 @@ -365,7 +365,7 @@
  used, zero or more commands may be
  specified. This can be specified by
  providing multiple command lines in
 -the same directive , or alternatively,
 +the same directive, or alternatively,
  this directive may be specified more
  than once with the same effect. If the
  empty string is assigned to this
 @@ -548,7 +548,7 @@
  when varnameType=oneshot/varname is
  used, in which case the timeout
  is disabled by default
 -(see 
 citerefentryrefentrytitlesystemd-systemd.conf/refentrytitlemanvolnum5/manvolnum/citerefentry).
 +(see 
 citerefentryrefentrytitlesystemd-system.conf/refentrytitlemanvolnum5/manvolnum/citerefentry).
  /para/listitem
  /varlistentry
  
 @@ -569,7 +569,7 @@
  the timeout logic. Defaults to
  varnameDefaultTimeoutStopSec=/varname 
 from the
  manager configuration file
 -(see 
 citerefentryrefentrytitlesystemd-systemd.conf/refentrytitlemanvolnum5/manvolnum/citerefentry).
 +(see 
 citerefentryrefentrytitlesystemd-system.conf/refentrytitlemanvolnum5/manvolnum/citerefentry).
  /para/listitem
  /varlistentry
  
 diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
 index dad0267..ce04b0b 100644
 --- a/man/systemd.socket.xml
 +++ b/man/systemd.socket.xml
 @@ -846,7 +846,7 @@
  20s. Pass literal0/literal to disable 
 the timeout
  logic. Defaults to 
 varnameDefaultTimeoutStartSec=/varname from the
  manager configuration file
 -(see 
 citerefentryrefentrytitlesystemd-systemd.conf/refentrytitlemanvolnum5/manvolnum/citerefentry).
 +(see 
 citerefentryrefentrytitlesystemd-system.conf/refentrytitlemanvolnum5/manvolnum/citerefentry).
  /para/listitem
  /varlistentry
  
 diff --git a/man/systemd.swap.xml b/man/systemd.swap.xml
 index 481dc52..00fafdc 100644
 --- a/man/systemd.swap.xml
 +++ b/man/systemd.swap.xml
 @@ -202,7 +202,7 @@
  20s. Pass literal0/literal to disable 
 the timeout
  logic. Defaults to 
 varnameDefaultTimeoutStartSec=/varname from the
  manager configuration file
 -(see 
 citerefentryrefentrytitlesystemd-systemd.conf/refentrytitlemanvolnum5/manvolnum/citerefentry).
 +(see 
 citerefentryrefentrytitlesystemd-system.conf/refentrytitlemanvolnum5/manvolnum/citerefentry).
  /para/listitem
  /varlistentry
  /variablelist
 

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

Re: [systemd-devel] [PATCH] bus-proxyd: improve compatibility with dbus-1

[Daniel Mack]

On 10/13/2014 03:29 PM, Lukasz Skalski wrote:
 'GetConnectionUnixProcessID', 'GetConnectionUnixUser' and
 'GetConnectionSELinuxSecurityContext' methods should return
 'NameHasNoOwner' error (if chosen name is not available on bus)
 with more detailed description - like dbus-1:
 
 Could not get PID of name 'org.freedesktop.test': no such name.
 Could not get UID of name 'org.freedesktop.test': no such name.
 Could not get security context of name 'org.freedesktop.test': no such name.
 
 Otherwise we have only laconic message without proper dbus error:
 
 Error System.Error.ENXIO: No such device or address

Looks good to me.

Applied, thanks!




 
 ---
  src/bus-proxyd/bus-proxyd.c | 36 +---
  1 file changed, 33 insertions(+), 3 deletions(-)
 
 diff --git a/src/bus-proxyd/bus-proxyd.c b/src/bus-proxyd/bus-proxyd.c
 index 52498f3..1bd7fee 100644
 --- a/src/bus-proxyd/bus-proxyd.c
 +++ b/src/bus-proxyd/bus-proxyd.c
 @@ -643,27 +643,57 @@ static int process_driver(sd_bus *a, sd_bus *b, 
 sd_bus_message *m) {
  return synthetic_reply_method_return(m, NULL);
  
  } else if (sd_bus_message_is_method_call(m, org.freedesktop.DBus, 
 GetConnectionSELinuxSecurityContext)) {
 +const char *name;
  _cleanup_bus_creds_unref_ sd_bus_creds *creds = NULL;
 +_cleanup_bus_error_free_ sd_bus_error error = 
 SD_BUS_ERROR_NULL;
  
 -r = get_creds_by_message(a, m, SD_BUS_CREDS_SELINUX_CONTEXT, 
 creds, NULL);
 +r = sd_bus_message_read(m, s, name);
 +if (r  0)
 +return r;
 +
 +r = get_creds_by_name(a, name, SD_BUS_CREDS_SELINUX_CONTEXT, 
 creds, NULL);
 +if (r == -ESRCH || r == -ENXIO) {
 +sd_bus_error_setf(error, 
 SD_BUS_ERROR_NAME_HAS_NO_OWNER, Could not get security context of name '%s': 
 no such name., name);
 +return synthetic_reply_method_errno(m, r, error);
 +}
  if (r  0)
  return synthetic_reply_method_errno(m, r, NULL);
  
  return synthetic_reply_method_return(m, y, creds-label, 
 strlen(creds-label));
  
  } else if (sd_bus_message_is_method_call(m, org.freedesktop.DBus, 
 GetConnectionUnixProcessID)) {
 +const char *name;
  _cleanup_bus_creds_unref_ sd_bus_creds *creds = NULL;
 +_cleanup_bus_error_free_ sd_bus_error error = 
 SD_BUS_ERROR_NULL;
  
 -r = get_creds_by_message(a, m, SD_BUS_CREDS_PID, creds, 
 NULL);
 +r = sd_bus_message_read(m, s, name);
 +if (r  0)
 +return r;
 +
 +r = get_creds_by_name(a, name, SD_BUS_CREDS_PID, creds, 
 NULL);
 +if (r == -ESRCH || r == -ENXIO) {
 +sd_bus_error_setf(error, 
 SD_BUS_ERROR_NAME_HAS_NO_OWNER, Could not get PID of name '%s': no such 
 name., name);
 +return synthetic_reply_method_errno(m, r, error);
 +}
  if (r  0)
  return synthetic_reply_method_errno(m, r, NULL);
  
  return synthetic_reply_method_return(m, u, (uint32_t) 
 creds-pid);
  
  } else if (sd_bus_message_is_method_call(m, org.freedesktop.DBus, 
 GetConnectionUnixUser)) {
 +const char *name;
  _cleanup_bus_creds_unref_ sd_bus_creds *creds = NULL;
 +_cleanup_bus_error_free_ sd_bus_error error = 
 SD_BUS_ERROR_NULL;
  
 -r = get_creds_by_message(a, m, SD_BUS_CREDS_UID, creds, 
 NULL);
 +r = sd_bus_message_read(m, s, name);
 +if (r  0)
 +return r;
 +
 +r = get_creds_by_name(a, name, SD_BUS_CREDS_UID, creds, 
 NULL);
 +if (r == -ESRCH || r == -ENXIO) {
 +sd_bus_error_setf(error, 
 SD_BUS_ERROR_NAME_HAS_NO_OWNER, Could not get UID of name '%s': no such 
 name., name);
 +return synthetic_reply_method_errno(m, r, error);
 +}
  if (r  0)
  return synthetic_reply_method_errno(m, r, NULL);
  
 

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

Re: [systemd-devel] [PATCH] kdbus: fix buffer overflow in bus_get_owner_kdbus() function

[Daniel Mack]

On 10/10/2014 12:29 PM, Lukasz Skalski wrote:
 Commit 710fc9779b7c (kdbus repo) introduced attaching items[]
 instead of name[] in kdbus_cmd_conn_info struct. Commit 581fe6c81
 (systemd repo) caught up with this change, but item size was not
 properly calculated.

Thanks for spotting this!

Applied.


 
 ---
  src/libsystemd/sd-bus/bus-control.c | 11 +--
  1 file changed, 5 insertions(+), 6 deletions(-)
 
 diff --git a/src/libsystemd/sd-bus/bus-control.c 
 b/src/libsystemd/sd-bus/bus-control.c
 index dbd94fc..7b106a3 100644
 --- a/src/libsystemd/sd-bus/bus-control.c
 +++ b/src/libsystemd/sd-bus/bus-control.c
 @@ -398,7 +398,7 @@ static int bus_get_owner_kdbus(
  struct kdbus_cmd_conn_info *cmd;
  struct kdbus_conn_info *conn_info;
  struct kdbus_item *item;
 -size_t size;
 +size_t size, l;
  uint64_t m, id;
  int r;
  
 @@ -410,13 +410,12 @@ static int bus_get_owner_kdbus(
  cmd = alloca0_align(size, 8);
  cmd-id = id;
  } else {
 -size_t item_size = KDBUS_ITEM_HEADER_SIZE + strlen(name) + 1;
 -
 -size = offsetof(struct kdbus_cmd_conn_info, items) + 
 item_size;
 +l = strlen(name) + 1;
 +size = offsetof(struct kdbus_cmd_conn_info, items) + 
 KDBUS_ITEM_SIZE(l);
  cmd = alloca0_align(size, 8);
 -cmd-items[0].size = item_size;
 +cmd-items[0].size = KDBUS_ITEM_HEADER_SIZE + l;
  cmd-items[0].type = KDBUS_ITEM_NAME;
 -strcpy(cmd-items[0].str, name);
 +memcpy(cmd-items[0].str, name, l);
  }
  
  cmd-size = size;
 

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

Re: [systemd-devel] [PATCH] bus-proxyd: fix compatibility with old dbus-1

[Daniel Mack]

On 10/10/2014 04:42 PM, Lukasz Skalski wrote:
 'ListQueuedOwners' method should return 'NameHasNoOwner' error
 if chosen name is not available on bus.

Applied, thanks!

 
 ---
  src/bus-proxyd/bus-proxyd.c | 9 +
  1 file changed, 9 insertions(+)
 
 diff --git a/src/bus-proxyd/bus-proxyd.c b/src/bus-proxyd/bus-proxyd.c
 index 4f44825..52498f3 100644
 --- a/src/bus-proxyd/bus-proxyd.c
 +++ b/src/bus-proxyd/bus-proxyd.c
 @@ -733,6 +733,7 @@ static int process_driver(sd_bus *a, sd_bus *b, 
 sd_bus_message *m) {
  struct kdbus_cmd_free cmd_free;
  struct kdbus_cmd_name *name;
  _cleanup_strv_free_ char **owners = NULL;
 +_cleanup_bus_error_free_ sd_bus_error error = 
 SD_BUS_ERROR_NULL;
  char *arg0;
  int err = 0;
  
 @@ -743,6 +744,14 @@ static int process_driver(sd_bus *a, sd_bus *b, 
 sd_bus_message *m) {
  if (!service_name_is_valid(arg0))
  return synthetic_reply_method_errno(m, -EINVAL, 
 NULL);
  
 +r = sd_bus_get_owner(a, arg0, 0, NULL);
 +if (r == -ESRCH || r == -ENXIO) {
 +sd_bus_error_setf(error, 
 SD_BUS_ERROR_NAME_HAS_NO_OWNER, Could not get owners of name '%s': no such 
 name., arg0);
 +return synthetic_reply_method_errno(m, r, error);
 +}
 +if (r  0)
 +return synthetic_reply_method_errno(m, r, NULL);
 +
  cmd.flags = KDBUS_NAME_LIST_QUEUED;
  r = ioctl(a-input_fd, KDBUS_CMD_NAME_LIST, cmd);
  if (r  0)
 

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

Re: [systemd-devel] Compatibility between D-Bus and kdbus

[Daniel Mack]

Hi Simon,

On 10/01/2014 03:33 PM, Simon McVittie wrote:
 (Cc'd to the systemd mailing list because sd-bus is the reference
 implementation of the user-space side of kdbus, but please join the dbus
 list and follow-up there if you are interested in D-Bus.)
 
 I've recently been looking at kdbus as a transport for D-Bus messages,
 and how compatible or otherwise it is with traditional stream-based
 D-Bus (and in particular, dbus-daemon, the reference implementation of
 stream-based D-Bus). My intention here is to replace dbus-daemon on
 Linux with something that does not have dbus-daemon's limitations,
 but avoid making existing software non-functional or insecure in the
 process. See https://bugs.freedesktop.org/show_bug.cgi?id=84188 for my
 attempts to document the current state of kdbus in the D-Bus Specification.

Thanks a lot for doing this! Much appreciated.

 I have not reviewed quality-of-implementation except where I happened to
 notice things as I went past, and I have not yet looked at
 Samsung/Tizen's patches adding a kdbus transport to libdbus and GDBus;
 for now I'm using sd-bus as my only reference for the user-space parts.

Let me just state that we didn't post kernel patches to the D-Bus list
in the past, as we didn't intend to discuss the internals of the kernel
code on primarily user-space mailing lists. That, of course, doesn't
mean we didn't want to discuss the external userspace API. We absolutely
want to make sure that kdbus is capable of serving as transportation
level interface that allows us to implement the same set of features
that we have now, eventually, and it seems like a good time to get into
the details.

While in the past, we were saying that kdbus is not ready yet and people
should not yet look at it closely, we're now at a stage in which we
consider the interface more or less stable. Some internal details might
still change, however.

So, for everyone interested, please have a look at the following git
repository:

  https://code.google.com/p/d-bus/

There's a fairly comprehensive documentation in kdbus.txt on the public
kernel API, which is itself defined in kdbus.h.

If you have any questions that are not answered by the existing
documentation, please feel free to ask. We also accept patches, of course.

Since a long time, it's also possible to boot up machines with systemd
when --enable-kdbus is passed in configure, the module is built and
installed, and the verb 'kdbus' is added to the kernel command line.

 System bus access-control policy
 
 
 I think this is the biggest point of incompatibility. In dbus-daemon
 there is a needlessly elaborate access-control language; in kdbus, there
 is a much simpler and more realistic access-control language, which
 specifically does not look into message payloads.

Exactly. In contrast to the traditional dbus-daemon, the transport layer
in kdbus has no understanding of what it actually transports in its data
blobs. There's no code in the kernel that is able to marshal or
demarshal the payload, that's entirely left to the users and the
libraries they use.

 This is far easier to reason about than what dbus-daemon does, but it's
 a problem for any system service that assumes that its existing
 per-interface or per-method access-control will be applied, such as
 Avahi denying access to SetHostName. It is not acceptable for such
 services to get instant security flaws as a result of their D-Bus
 implementation being upgraded from a version that does not support kdbus
 to a version that does. Unfortunately, last time we discussed this, we
 didn't have a particularly good solution.

Yes, that needs to be addressed. However, we won't add support to kdbus
for method filtering or anything alike, so the kernel won't be able to
help enforce such policies.

 If I remember correctly, the least bad solution anyone could think of
 was to introduce a new pseudo-bus-type alongside DBUS_BUS_SYSTEM (and
 its equivalent in other libraries like GDBus), perhaps called
 DBUS_BUS_SYSTEM_UNTRUSTED or something (better names welcome), with
 its own shared connection: connections to that bus type are not assumed
 to filter messages by their payload, and method-call recipients are
 expected to use Polkit or similar, or do their own simplistic
 access-controls like must be uid 0 by calling GetConnectionUnixUser or
 GetConnectionCredentials on the sender's unique name.
 
 On non-kdbus systems, it would just be the same thing as
 DBUS_BUS_SYSTEM; on kdbus systems, DBUS_BUS_SYSTEM would refuse to use
 the kdbus transport, and fall back to stream-based D-Bus compatibility
 mechanisms like systemd-bus-proxyd. That would enable individual
 libraries and applications to opt-in to using this new shared connection
 when they have been audited for safety, with the goal being that
 everything eventually moved to it, and nothing connected to
 DBUS_BUS_SYSTEM any more.

Exactly, we would fall back to legacy translators for such client.

Re: [systemd-devel] [PATCH] shell-completion(zsh): journalctl's -b changes

[Daniel Mack]

On 09/27/2014 02:48 PM, Eric Cook wrote:
 removed pointless index sort of bootids.
 use `compadd -a' to add each array, instead of expanding possibly hundreds of 
 words needlessly.
 optional completion of -b

Applied, thanks.


 
 ---
  shell-completion/zsh/_journalctl | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/shell-completion/zsh/_journalctl 
 b/shell-completion/zsh/_journalctl
 index 0d16a26..a469bbc 100644
 --- a/shell-completion/zsh/_journalctl
 +++ b/shell-completion/zsh/_journalctl
 @@ -41,11 +41,11 @@ _journal_fields() {
  
  _journal_boots() {
local -a _bootid _previousboots
 -  _bootid=( ${(fao)$(_call_program bootid $service -F _BOOT_ID)}  )
 +  _bootid=( ${(f)$(_call_program bootid $service -F _BOOT_ID)}  )
_previousboots=( -{1..${#_bootid}} )
_alternative : \
 -offsets:boot offsets:(${_previousboots[1,-2]}) \
 -bootid:boot ids:(${_bootid[@]})
 +offsets:boot offsets:compadd -a '_previousboots[1,-2]' \
 +bootid:boot ids:compadd -a _bootid
  }
  
  _arguments -s \
 @@ -63,7 +63,7 @@ _arguments -s \
  {-x,--catalog}'[Show explanatory texts with each log line]' \
  {-q,--quiet}[Don't show privilege warning] \
  {-m,--merge}'[Show entries from all available journals]' \
 -{-b+,--boot=}'[Show data only from the specified boot or offset]:boot id 
 or offset:_journal_boots' \
 +{-b+,--boot=}'[Show data only from the specified boot or offset]::boot 
 id or offset:_journal_boots' \
  '--list-boots[List boots ordered by time]' \
  {-k,--dmesg}'[Show only kernel messages from the current boot]' \
  {-u+,--unit=}'[Show data only from the specified 
 unit]:units:_journal_fields _SYSTEMD_UNIT' \
 

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

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

[Daniel Mack]

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

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


Thanks,
Daniel

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

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

[Daniel Mack]

On 09/26/2014 01:16 PM, Zbigniew Jędrzejewski-Szmek wrote:
 On Fri, Sep 26, 2014 at 10:24:25AM +0200, Daniel Mack wrote:
 On 09/26/2014 05:05 AM, Zbigniew Jędrzejewski-Szmek wrote:
 Hi,
 test-bus-policy fails intermittently in 'make distcheck'

 FAIL: test-bus-policy
 =

 Assertion 'policy_check_own(p, ucred, org.test.test1) == true' failed 
 at ../src/bus-proxyd/test-bus-policy.c:58,
  function main(). Aborting.

 Hmm. I don't see this here. What kind of setup are you running this on?
 We make certain assumptions on existing users/groups on the target
 system, and I'm not sure whether we should do that. Are uid/gid 1 valid
 on your system?
 It only seems to fail inside distcheck, so it might be some race
 condition.

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

I'm working on a fix for this.


Thanks,
Daniel

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

Re: [systemd-devel] [PATCH] Fix resource leak (coverity CID 1237760)

[Daniel Mack]

On 09/17/2014 11:10 PM, Cristian Rodríguez wrote:
 ---
  src/libsystemd/sd-bus/bus-kernel.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)
 
 diff --git a/src/libsystemd/sd-bus/bus-kernel.c 
 b/src/libsystemd/sd-bus/bus-kernel.c
 index 505f335..b3cc996 100644
 --- a/src/libsystemd/sd-bus/bus-kernel.c
 +++ b/src/libsystemd/sd-bus/bus-kernel.c
 @@ -1446,9 +1446,11 @@ int bus_kernel_create_endpoint(const char *bus_name, 
 const char *ep_name, char *
  }
  
  if (ep_path) {
 -asprintf(ep_path, %s/%s, dirname(path), ep_name);
 -if (!*ep_path)
 +int r = asprintf(ep_path, %s/%s, dirname(path), ep_name);
 +if (r == -1 || !*ep_path) {
 +safe_close(fd);
  return -ENOMEM;
 +}
  }
  
  return fd;
 

Applied, thanks!

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

Re: [systemd-devel] [PATCH] systemctl: fix resource leak CID #1237747

[Daniel Mack]

On 09/18/2014 02:56 AM, Cristian Rodríguez wrote:
 ..by simply moving the declaration of unit into the STRV_FOREACH
 loop as suggested by Andreas.
 ---
  src/systemctl/systemctl.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
 diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
 index 88be871..9012128 100644
 --- a/src/systemctl/systemctl.c
 +++ b/src/systemctl/systemctl.c
 @@ -4449,7 +4449,6 @@ static int show(sd_bus *bus, char **args) {
  }
  
  static int cat(sd_bus *bus, char **args) {
 -_cleanup_free_ char *unit = NULL;
  _cleanup_strv_free_ char **names = NULL;
  char **name;
  bool first = true;
 @@ -4468,6 +4467,8 @@ static int cat(sd_bus *bus, char **args) {
  _cleanup_bus_error_free_ sd_bus_error error = 
 SD_BUS_ERROR_NULL;
  _cleanup_strv_free_ char **dropin_paths = NULL;
  _cleanup_free_ char *fragment_path = NULL;
 +_cleanup_free_ char *unit = NULL;
 +
  char **path;
  
  unit = unit_dbus_path_from_name(*name);
 

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

Re: [systemd-devel] [PATCH 2/2] test: Use 'CapBnd' string for capability bounding set

[Daniel Mack]

On 09/17/2014 04:12 AM, Djalal Harouni wrote:
 Signed-off-by: Djalal Harouni tix...@opendz.org
 ---
  test/kdbus-util.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/test/kdbus-util.c b/test/kdbus-util.c
 index fe4565c..b1c5864 100644
 --- a/test/kdbus-util.c
 +++ b/test/kdbus-util.c
 @@ -569,7 +569,7 @@ void kdbus_msg_dump(const struct kdbus_conn *conn, const 
 struct kdbus_msg *msg)
   for (i = 0; i  n; i++)
   kdbus_printf(%08x, cap[(2 * n) + (n - i - 
 1)]);
  
 - kdbus_printf( CapInh=);
 + kdbus_printf( CapBnd=);
   for (i = 0; i  n; i++)
   kdbus_printf(%08x, cap[(3 * n) + (n - i - 
 1)]);
   kdbus_printf(\n);
 

Appplied both, thanks!

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

Re: [systemd-devel] [PATCH] missing: memfd_create takes unsigned int flags in final version

[Daniel Mack]

On 09/16/2014 07:17 PM, Cristian Rodríguez wrote:
 ---
  src/shared/missing.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/src/shared/missing.h b/src/shared/missing.h
 index 023c680..b441149 100644
 --- a/src/shared/missing.h
 +++ b/src/shared/missing.h
 @@ -209,7 +209,7 @@ static inline int fanotify_mark(int fanotify_fd, unsigned 
 int flags, uint64_t ma
  #endif
  
  #ifndef HAVE_MEMFD_CREATE
 -static inline int memfd_create(const char *name, uint64_t flags) {
 +static inline int memfd_create(const char *name, unsigned int flags) {
  return syscall(__NR_memfd_create, name, flags);
  }
  #endif
 

Applied, thanks!

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

Re: [systemd-devel] [PATCH] core: fix resource leak in manager_environment_add

[Daniel Mack]

On 09/16/2014 09:11 PM, Andreas Henriksson wrote:
 Second error path must free the (potentially) allocated memory in the
 first code chunk before returning.
 
 Found by coverity. Fixes: CID#1237750
 ---
  src/core/manager.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/src/core/manager.c b/src/core/manager.c
 index 0770727..e0c1cd1 100644
 --- a/src/core/manager.c
 +++ b/src/core/manager.c
 @@ -2751,8 +2751,10 @@ int manager_environment_add(Manager *m, char **minus, 
 char **plus) {
  
  if (!strv_isempty(plus)) {
  b = strv_env_merge(2, l, plus);
 -if (!b)
 +if (!b) {
 +strv_free(a);
  return -ENOMEM;
 +}
  
  l = b;
  }
 

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

Re: [systemd-devel] [PATCH] shared: fix resource leak in config_parse_default_instance

[Daniel Mack]

On 09/16/2014 09:36 PM, Andreas Henriksson wrote:
 The recently allocated printed is not freed on error path.
 
 Found by coverity. Fixes: CID#1237745
 ---
  src/shared/install.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/src/shared/install.c b/src/shared/install.c
 index 5d3fcf5..61e572b 100644
 --- a/src/shared/install.c
 +++ b/src/shared/install.c
 @@ -1025,8 +1025,10 @@ static int config_parse_default_instance(
  if (r  0)
  return r;
  
 -if (!unit_instance_is_valid(printed))
 +if (!unit_instance_is_valid(printed)) {
 +free(printed);
  return -EINVAL;
 +}
  
  free(i-default_instance);
  i-default_instance = printed;
 

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

Re: [systemd-devel] [PATCH] sysv-generator: fix resource leak

[Daniel Mack]

On 09/16/2014 09:22 PM, Andreas Henriksson wrote:
 The unit string allocation is not freed on either error or success path.
 
 Found by coverity. Fixes: CID#1237755
 ---
  src/sysv-generator/sysv-generator.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/src/sysv-generator/sysv-generator.c 
 b/src/sysv-generator/sysv-generator.c
 index 6c3281f..e5902ab 100644
 --- a/src/sysv-generator/sysv-generator.c
 +++ b/src/sysv-generator/sysv-generator.c
 @@ -114,9 +114,9 @@ static int add_symlink(const char *service, const char 
 *where) {
  }
  
  static int generate_unit_file(SysvStub *s) {
 -char *unit;
  char **p;
  _cleanup_fclose_ FILE *f = NULL;
 +_cleanup_free_ char *unit = NULL;
  _cleanup_free_ char *before = NULL;
  _cleanup_free_ char *after = NULL;
  _cleanup_free_ char *wants = NULL;
 

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

Re: [systemd-devel] [PATCH] [RFC] [WIP] [kdbus] Attempt to recursively pass fd

[Daniel Mack]

Hi Alban,

Sorry for the long delay on this.

On 08/14/2014 01:21 PM, Alban Crequy wrote:
 Before Linux commit 25888e (from 2.6.37-rc4, Nov 2010), fd-passing on Unix
 sockets could recursively be stacked, allowing a process to exhaust the open
 files limit (/proc/sys/fs/file-max) on the system without restriction from
 ulimit -n.
 
 This DoS on Unix sockets was fixed by commit:
 
 commit 25888e30319f8896fc656fc68643e6a078263060
 Author: Eric Dumazet eric.duma...@gmail.com
 Date:   Thu Nov 25 04:11:39 2010 +

 af_unix: limit recursion level
 
 But that commit introduced a bug in dbus:
 https://bugs.freedesktop.org/show_bug.cgi?id=80163
 
 kdbus does not use fd-passing on Unix sockets so it is not affected by this.
 
 However, it allows fd-passing similarly. This patch shows it is possible to
 recursively pass file descriptors in kdbus and stack them without keeping them
 attached to the initial process. I could stack passed fds 256 times, probably
 because of the limit KDBUS_USER_MAX_CONN:

I finally found some time to look into this, and added a patch that
disallows passing kdbus handles over kdbus handles. Such an attempt now
returns -ELOOP.

We might eventually allow this once we have a generic GC implementation
for file descriptors (currently, there's only one, and that one only
works for unix domain sockets). For now, we'll also need something that
disallows passing kdbus handles over UDS.

I also added a test to the suite to check for this behaviour. I borrowed
some code from you test case for this. Care to check wheter that seems
alright to you?

Many thanks for the heads-up!


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

Re: [systemd-devel] [PATCH 2/2] policy: make policy checks work across user namespaces

[Daniel Mack]

On 09/08/2014 03:50 PM, Djalal Harouni wrote:
 Yes there are compile time checks, and it is perhaps easier/consistent
 to read this way! but yes a union is also good. OK I'll update it.

Nevermind - I amended the your patch accordingly and pushed it.


Thanks!

Daniel

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