Re: [systemd-devel] Bugfix release(s)

[Dave Reisner]

On Mon, Jan 14, 2019 at 04:48:22PM +0100, Lennart Poettering wrote:
> On Mo, 14.01.19 08:43, Dave Reisner (d...@falconindy.com) wrote:
> 
> > On Mon, Jan 14, 2019 at 10:59:06AM +0100, Jan Synacek wrote:
> > > Hi,
> > >
> > > since v240 didn't go too well, I would like to suggest that the next one
> > > (preferably two) release(s) are bugfix only. Please, consider it.
> >
> > systemd needs better release hygiene, not just a smattering of bugfix
> > releases. As a rolling release distro, we regularly find release-day
> > blockers. That's bad for everyone. v240 was particularly bad as 6 months
> > had elapsed since v239 (and over 3100 commits). That's the longest
> > timespan and most commits in any systemd release in its nearly 9 year
> > history.
> 
> Well, that sounds as if you want to volunteer as release engineer? ;-)
> 
> Thing is, we are understaffed. I too have a wishlist of things I'd
> like to see done, but with only two paid full-time upstream engineers
> there's only so much we can do.

Then, IMO, you have a fundamental misalignment. You're prioritizing
feature work over stability, to the detriment of your customers. I
really don't think this would be a full time job. There's already a
pretty good effort around tagging open issues which provides visibility
to someone who might be in charge of cutting releases. And, much of what
I'm suggesting is about *not* merging things after a certain point.

> If you (or anyone else in the community) would like to step up and
> maybe take a position of release engineer, working towards a clearer
> release cadence I think everybody would love you for that! I know I
> certainly would.
> 
> But additional work is not going to be done without anyone doing it...

Like I said, it's a tradeoff. You currently have someone maintaining a
stable branch in lieu of making your release snapshots more stable.

> > It's my understanding that there were known problems that prevented
> > tagging the release of v240 sooner. If that's the case, most other
> > development should have *stopped* with focus on fixing those problems.
> > However, that doesn't appear to be the case. Looking at commit
> > timestamps over time, nearly half the commits were made in the last 2
> > months:
> >
> >   Jun: 86
> >   Jul: 276
> >   Aug: 241
> >   Sep: 317
> >   Oct: 812
> >   Nov: 882
> >   Dec: 560
> 
> That it slightly misleading though, as a good chunk of those PRs that
> good merged late where posted much earlier on, but only entered the
> master branch late. So, most development work is definitely done at
> the beginning of the cycle than in the end, but it's hard to see that
> due to rebases/merges...

This is all based on commit date, not merge date. It's not misleading.

> > Please bring back a regular release process (as dvdhrm attempted to do)
> > like curl which has a 2 month release cycle. They're actually *beating*
> > this 2 month period substantially, averaging 40 days between releases
> > over the last 30 releases (2+ years). They follow a 30 day period of
> > feature work with a 30 day period of bugfixes.
> >
> > Yes, this is probably more work. But maintaining the systemd-stable repo
> > is work, too. Effort put into making releases cut from master more
> > stable is ideally offset by the lack of work that will need to go into
> > maintaining systemd-stable branches.
> >
> > Please, let's make all future systemd release better, not just the next
> > 1 or 2.
> 
> I certainly see the problem, but quite frankly, I don't see the
> additional workforce for implementing a tighter cadence appear
> anywhere... :-(

It's really unfortunate that you're not willing to make any tradeoffs
here.

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

Re: [systemd-devel] Bugfix release(s)

[Dave Reisner]

On Mon, Jan 14, 2019 at 10:59:06AM +0100, Jan Synacek wrote:
> Hi,
> 
> since v240 didn't go too well, I would like to suggest that the next one
> (preferably two) release(s) are bugfix only. Please, consider it.

systemd needs better release hygiene, not just a smattering of bugfix
releases. As a rolling release distro, we regularly find release-day
blockers. That's bad for everyone. v240 was particularly bad as 6 months
had elapsed since v239 (and over 3100 commits). That's the longest
timespan and most commits in any systemd release in its nearly 9 year
history.

It's my understanding that there were known problems that prevented
tagging the release of v240 sooner. If that's the case, most other
development should have *stopped* with focus on fixing those problems.
However, that doesn't appear to be the case. Looking at commit
timestamps over time, nearly half the commits were made in the last 2
months:

  Jun: 86
  Jul: 276
  Aug: 241
  Sep: 317
  Oct: 812
  Nov: 882
  Dec: 560

That doesn't seem right to me. Looking at this by week is pretty bad,
too:

  25: 4
  26: 82
  27: 31
  28: 23
  29: 84
  30: 104
  31: 85
  32: 85
  33: 8
  34: 66
  35: 40
  36: 35
  37: 121
  38: 61
  39: 91
  40: 91
  41: 255
  42: 240
  43: 179
  44: 94
  45: 181
  46: 255
  47: 209
  48: 271
  49: 209
  50: 164
  51: 105
  52: 1

Please bring back a regular release process (as dvdhrm attempted to do)
like curl which has a 2 month release cycle. They're actually *beating*
this 2 month period substantially, averaging 40 days between releases
over the last 30 releases (2+ years). They follow a 30 day period of
feature work with a 30 day period of bugfixes.

Yes, this is probably more work. But maintaining the systemd-stable repo
is work, too. Effort put into making releases cut from master more
stable is ideally offset by the lack of work that will need to go into
maintaining systemd-stable branches.

Please, let's make all future systemd release better, not just the next
1 or 2.

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

Re: [systemd-devel] Question about WATCHDOG

[Dave Reisner]

On Fri, Jan 11, 2019 at 08:03:45AM +, Sietse van Zanen wrote:
> Hi,
> 
>  
> 
> I am writing a daemon script which uses sd_notify watchdog. This works fine,
> system will kill the if the process doesn’t notify.
> 
>  
> 
> However, I have seen in 1 occasion where, due to a programming error, the
> script got stuck in a read and was not killed where it should have been.
> 
> So my question is, what does systemd actually do when the watchdog expires,
> which signal does it send?
> 

It's well documented in the manpages. From systemd.service(5) under the
description of WatchdogSec=:

  If the time between two such calls is larger than the configured time,
  then the service is placed in a failed state and it will be terminated
  with SIGABRT (or the signal specified by WatchdogSignal=)

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

Re: [systemd-devel] Return codes of systemctl (status)

[Dave Reisner]

On Thu, Aug 16, 2018 at 01:27:12PM +0200, Cecil Westerhof wrote:
> The man page of systemctl says:
>     On success, 0 is returned, a non-zero failure code otherwise.
> 
> When I do a systemctl status on a service that is not running I get a 3.
> What other values can be returned and where do I find those?

I believe exit codes are meant to conform to LSB specs:

http://refspecs.linuxbase.org/LSB_3.0.0/LSB-PDA/LSB-PDA/iniscrptact.html

In general, I'd suggest not depending on the specific values, but
instead using a more appropriate verb. For example, if you want to
know that a service is running, is 'systemctl is-active'.

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

Re: [systemd-devel] Stable interface names even when hardware is added or removed, not true

[Dave Reisner]

On Wed, Nov 16, 2016 at 4:19 PM, Pekka Sarnila  wrote:

>
>
> On 11/16/16 18:11, Greg KH wrote:
>
>> On Wed, Nov 16, 2016 at 03:33:42PM +0200, Pekka Sarnila wrote:
>>
>>> On 'Predictable Network Interface Names' it states as a benefit of the
>>> new
>>> policy:
>>>
>>>   Stable interface names even when hardware is added or removed, i.e.
>>>   no re-enumeration takes place
>>>
>>> Unfortunately this is not true.
>>>
>>> I'm running a mail server, kernel 4.8.6. Graphics card started to fail.
>>> Replaced it with new one (newer model). Booted the system.
>>>
>>> All seemed to be fine, network seemed to work. But after some time got
>>> angry
>>> cries: 'can't read the mail !!!'. A big headache.
>>>
>>> Although the new card was in the same slot as the old one kernel had
>>> changed
>>> the name enp6s0 -> enp3s0 (no firmware/BIOS index available and kernel
>>> policy was used as default). Since enp6s0 was not found our server
>>> instead
>>> of fixed ip address used our dhcp-server to get a random temp address.
>>> Thus
>>> network worked, but not in the mail-servers correct address.
>>>
>>> To figure this out took some nervous time.
>>>
>>> Now, I don't know why kernel driver got a different name for this network
>>> interface (ethernet hardware is on the motherboard, and it is the only
>>> net
>>> hardware on the system). But obviously it can happen.
>>>
>>
>> That is because your PCI devices renumbered themselves, which is quite
>> common when changing PCI devices around (or adding/removing them).  Not
>> much systemd can do about this, sorry.
>>
>> greg k-h
>>
>>
> Well my first point was that the web page should not say
>
> >>   Stable interface names even when hardware is added or removed, i.e.
> >>   no re-enumeration takes place
>
> But second was that in principle persistent naming would be possible for
> systems with only one interface. And it should possible to implement it in
> systemd-network, and make it systemd package default for such case.


No, it's not. It sounds more like you want to disable the naming policy,
which means you get "eth0" for the first device that shows up.


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

Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

[Dave Reisner]

On Mon, Sep 26, 2016 at 11:35:51AM +1300, Sergei Franco wrote:
> Thank you for your quick reply.
> 
> I just tested this scenario on Ubuntu 12.04LTS (with upstart) and it
> present the following message:
> 
> The disk drive for /data is not ready yet or not present.
> keys:Continue to wait, or Press S to skip mounting or M for manual recovery
> 
> So it is not as big difference as I initially thought, except it is much
> easier to deal with by simply pressing S, while I believe there is no
> such option for systemd (it would be nice).

Making bootup potentially interactive in this manner is strictly worse
than dumping you into emergency mode. At least with emergency mode, you
might be able to add dependencies to emergency.target such that, for
example, an sshd comes up and an admin can login to the remote box.
How's this supposed to work with a random prompt which must be accessed
on /dev/console?  Enforce that everyone has some sort of out of band
console?

Unclear why you consider this a superior design decision...

> So in future for non crucial disks I will use nofail.
> 
> Best regards.
> 
> Sergei.
> 
> P.S. As advised I have replied to correct address.
> 
> On 26 September 2016 at 11:30, Reindl Harald  wrote:
> 
> if you post somehting to a mailing-list and you get a response on the list
> POST REPLIES TO THE LIST - *period*
> 
> Am 26.09.2016 um 00:28 schrieb Sergei Franco:
>
> Thank you for your quick reply.
> 
> I just tested this scenario on Ubuntu 12.04LTS (with upstart) and it
> present the following message:
> 
> The disk drive for /data is not ready yet or not present.
> keys:Continue to wait, or Press S to skip mounting or M for manual
> recovery
> 
> So it is not as big difference as I initially thought, except it is
> much
> easier to deal with by simply pressing S, while I believe there is no
> such option for systemd (it would be nice).
> 
> So in future for non crucial disks I will use nofail.
> 
> Best regards.
> 
> Sergei.
> 
> On 26 September 2016 at 10:57, Reindl Harald  > wrote:
> 
> 
> 
>     Am 25.09.2016 um 23:52 schrieb Sergei Franco:
> 
>         I am looking at correct way to disable the "feature" of
>         emergency mode
>         when systemd encounters missing block device entires in fstab.
> 
>         For example:
> 
>         the following entry is in /etc/fstab:
>         UUID=d4a23034-8cbe-44b3-92a5-3d38e1816eff /data             
>  xfs
>         defaults        0       0
> 
>         If the drive (d4a23034-8cbe-44b3-92a5-3d38e1816eff) has been
>         detached
>         and machine rebooted it stops booting with Emergency mode, 
> even
>         though
>         the /data is not crucial for boot
> 
> 
>     RTFM - when you don't say "nofail" it's ecpected to be crucial
> 
>     your entry says it's crucial
> 
>     http://unix.stackexchange.com/questions/53456/what-is-the-di
> fference-between-nobootwait-and-nofail-in-fstab
>      difference-between-nobootwait-and-nofail-in-fstab>
> 
> 
> 
> 

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

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

Re: [systemd-devel] Emergency mode if non-critical /etc/fstab entries are missing

[Dave Reisner]

On Mon, Sep 26, 2016 at 10:52:50AM +1300, Sergei Franco wrote:
> Hi,
> 
> I am looking at correct way to disable the "feature" of emergency mode when
> systemd encounters missing block device entires in fstab.
> 
> For example:
> 
> the following entry is in /etc/fstab:
> UUID=d4a23034-8cbe-44b3-92a5-3d38e1816eff /data   xfs
> defaults    0   0
> 
> If the drive (d4a23034-8cbe-44b3-92a5-3d38e1816eff) has been detached and
> machine rebooted it stops booting with Emergency mode, even though the /data 
> is
> not crucial for boot.
>
> In past (eg. with upstart) it would simply generate a warning and continue to
> boot.
>
> The emergency mode assumes console access, which requires physical access,
> which is quiet difficult if the machine is remote.
> 
> I believe the boot should be best effort, give warning and continue to boot,
> giving at least partial working system.
> 
> Actually further thinking about it, this behaviour is bad even for desktop
> scenario.

What you seem to want is "nofail", potentially coupled with
"noauto,x-systemd.automount".

> The correct behaviour should be following: drop in emergency mode only when
> crucial to boot files are not available otherwise warn about missing drives 
> and
> continue to boot.

Critical filesystems are those listed in /etc/fstab without the "nofail"
option.

> Regards.
> 
> Sergei.
> 
> 
> 

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

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

Re: [systemd-devel] Timer: time format

[Dave Reisner]

On Tue, Aug 23, 2016 at 11:38:57AM +0200, arnaud gaboury wrote:
> I am really sorry for this post as this may sound like a trivial one,
> but honestly the timer topic is difficult to understand for me (at
> least the time format).
> 
> I am looking to run a service twice a day, never mind the time. I
> understand I must use OnCalendar, but I have no idea for the rest.
> 
> I was thinking of OnCalendar=*:12:00   for running every 12 hours. Is
> it right (or will it run every day at noon) ?

This runs every hour on the 12 minute mark. You want '0,12:00' to run on
the 0 hour and 1200. Alternatively, you can always use multiple
OnCalendar= entries if that's easier for you to grok.

With less than 100 lines of code, one could write a tool which parses
calendar specs and spits out nice human-readable times for the next N
occurrences. Something like:

$ systemd-timespec-parse --next=5 0,12:00
Showing next 5 runs for: *-*-* 00,12:00:00
1:  Tue 2016-08-23 12:00:00 EDT
2:  Wed 2016-08-24 00:00:00 EDT
3:  Wed 2016-08-24 12:00:00 EDT
4:  Thu 2016-08-25 00:00:00 EDT
5:  Thu 2016-08-25 12:00:00 EDT

Maybe this would save people some time... I know I'd make use of this.

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

Re: [systemd-devel] [ANNOUNCE] systemd v230

[Dave Reisner]

On Sat, May 21, 2016 at 10:51:13PM +, Zbigniew Jędrzejewski-Szmek wrote:
> Hi,
> 
> systemd v230 has been tagged. Enjoy!
> 
> CHANGES WITH 230:

Hi,

One important change missing from this list is 7163e1ca1108d7 -- if you
use systemd in your initramfs and do not add initrd-root-device.target,
bootup may fail due to races.

> 
> * DNSSEC is now turned on by default in systemd-resolved (in
>   "allow-downgrade" mode), but may be turned off during compile time 
> by
>   passing "--with-default-dnssec=no" to "configure" (and of course,
>   during runtime with DNSSEC= in resolved.conf). We recommend
>   downstreams to leave this on at least during development cycles and
>   report any issues with the DNSSEC logic upstream. We are very
>   interested in collecting feedback about the DNSSEC validator and its
>   limitations in the wild. Note however, that DNSSEC support is
>   probably nothing downstreams should turn on in stable distros just
>   yet, as it might create incompatibilities with a few DNS servers and
>   networks. We tried hard to make sure we downgrade to non-DNSSEC mode
>   automatically whenever we detect such incompatible setups, but there
>   might be systems we do not cover yet. Hence: please help us testing
>   the DNSSEC code, leave this on where you can, report back, but then
>   again don't consider turning this on in your stable, LTS or
>   production release just yet. (Note that you have to enable
>   nss-resolve in /etc/nsswitch.conf, to actually use systemd-resolved
>   and its DNSSEC mode for host name resolution from local
>   applications.)
> 
> * systemd-resolve conveniently resolves DANE records with the --tlsa
>   option and OPENPGPKEY records with the --openpgp option. It also
>   supports dumping raw DNS record data via the new --raw= switch.
> 
> * systemd-logind will now by default terminate user processes that are
>   part of the user session scope unit (session-XX.scope) when the user
>   logs out. This behavior is controlled by the KillUserProcesses=
>   setting in logind.conf, and the previous default of "no" is now
>   changed to "yes". This means that user sessions will be properly
>   cleaned up after, but additional steps are necessary to allow
>   intentionally long-running processes to survive logout.
> 
>   While the user is logged in at least once, user@.service is running,
>   and any service that should survive the end of any individual login
>   session can be started at a user service or scope using systemd-run.
>   systemd-run(1) man page has been extended with an example which 
> shows
>   how to run screen in a scope unit underneath user@.service. The same
>   command works for tmux.
> 
>   After the user logs out of all sessions, user@.service will be
>   terminated too, by default, unless the user has "lingering" enabled.
>   To effectively allow users to run long-term tasks even if they are
>   logged out, lingering must be enabled for them. See loginctl(1) for
>   details. The default polkit policy was modified to allow users to
>   set lingering for themselves without authentication.
> 
>   Previous defaults can be restored at compile time by the
>   --without-kill-user-processes option to "configure".
> 
> * systemd-logind gained new configuration settings SessionsMax= and
>   InhibitorsMax=, both with a default of 8192. It will not register 
> new
>   user sessions or inhibitors above this limit.
> 
> * systemd-logind will now reload configuration on SIGHUP.
> 
> * The unified cgroup hierarchy added in Linux 4.5 is now supported.
>   Use systemd.unified_cgroup_hierarchy=1 on the kernel command line to
>   enable. Also, support for the "io" cgroup controller in the unified
>   hierarchy has been added, so that the "memory", "pids" and "io" are
>   now the controllers that are supported on the unified hierarchy.
> 
>   WARNING: it is not possible to use previous systemd versions with
>   systemd.unified_cgroup_hierarchy=1 and the new kernel. Therefore it
>   is necessary to also update systemd in the initramfs if using the
>   unified hierarchy. An updated SELinux policy is also required.
> 
> * LLDP support has been extended, and both passive (receive-only) and
>   active (sender) modes are supported. Passive mode ("routers-only") 
> is
>   enabled by default in systemd-networkd. Active LLDP mode is enabled
>   by default for containers on the internal network. The "networkctl
>   lldp" command may be used to list information gathered. "networkctl
>   status" 

Re: [systemd-devel] [ANNOUNCE] systemd v229

[Dave Reisner]

On Fri, Feb 12, 2016 at 10:56:29AM +0100, Armin K. wrote:
> On 12.02.2016 10:54, Colin Guthrie wrote:
> > Dave Reisner wrote on 12/02/16 01:09:
> >> On Thu, Feb 11, 2016 at 10:26:51PM +0100, Reindl Harald wrote:
> >>>
> >>> Am 11.02.2016 um 22:19 schrieb Dave Reisner:
> >>>> On Thu, Feb 11, 2016 at 05:50:08PM +0100, Lennart Poettering wrote:
> >>>>> I just tagged the v229 release of systemd. Enjoy!
> >>>>>
> >>>>> CHANGES WITH 229:
> >>>>>
> >>>>> 
> >>>>>
> >>>>> * When the stacktrace is extracted from processes of system 
> >>>>> users, this
> >>>>>   is now done as "systemd-coredump" user, in order to sandbox 
> >>>>> this
> >>>>>   potentially security sensitive parsing operation. (Note that 
> >>>>> when
> >>>>>   processing coredumps of normal users this is done under the 
> >>>>> user ID
> >>>>>   of process that crashed, as before.) Packagers should take 
> >>>>> notice
> >>>>>   that it is now necessary to create the "systemd-coredump" 
> >>>>> system user
> >>>>>   and group at package installation time.
> >>>>>
> >>>>
> >>>> Why is it left to downstream to create this user? What makes it
> >>>> different from the other 4 users which systemd already creates?
> >>>
> >>> systemd don't create any user. nowhere, rpm-scritrs downstream does
> >>
> >> You're mistaken. See 
> >> /usr/lib/sysusers.d/{basic,systemd,systemd-remote}.conf and
> >> systemd-sysusers(8). The curious absence of systemd-coredump from
> >> sysusers.d/systemd.conf is what I'm asking about here.
> > 
> > Seems odd indeed. It's perhaps because the user needs to own directories
> > that are packaged (e.g. in /var) which is somewhat tricky with sysusers
> > - you need to have the user available before the package is installed -
> > i.e. an RPM %pre script.  Just a guess at why it was left out.
> > 
> > Personally, I'd just make such folders ghosts and them have them created
> > by tmpfiles after package install (and thus after sysusers has run to
> > create the user who will own the folders)
> > 
> > This is something that I think should be automated in RPM packaging
> > (i.e. the creation of ghosts automatically by parsing packaged tmpfiles
> > snippets), but this is off-topic.
> > 
> > Col
> > 
> > 
> > 
> > 
> 
> I don't see the problem. The user is already in sysusers.d/systemd.conf.m4
> 
> https://github.com/systemd/systemd/blob/master/sysusers.d/systemd.conf.m4
> 
> I do appreciate that he mentioned a new user had to be created, because,
> you know, not everyone uses systemd-sysusers.
> 

Ah, this is all I was looking for. Sorry, should have looked a bit more
closely.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd v229

[Dave Reisner]

On Thu, Feb 11, 2016 at 05:50:08PM +0100, Lennart Poettering wrote:
> Heya!
> 
> I just tagged the v229 release of systemd. Enjoy!
> 
> CHANGES WITH 229:
> 
> 
> 
> * When the stacktrace is extracted from processes of system users, 
> this
>   is now done as "systemd-coredump" user, in order to sandbox this
>   potentially security sensitive parsing operation. (Note that when
>   processing coredumps of normal users this is done under the user ID
>   of process that crashed, as before.) Packagers should take notice
>   that it is now necessary to create the "systemd-coredump" system 
> user
>   and group at package installation time.
> 

Why is it left to downstream to create this user? What makes it
different from the other 4 users which systemd already creates?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd v229

[Dave Reisner]

On Thu, Feb 11, 2016 at 10:26:51PM +0100, Reindl Harald wrote:
> 
> Am 11.02.2016 um 22:19 schrieb Dave Reisner:
> >On Thu, Feb 11, 2016 at 05:50:08PM +0100, Lennart Poettering wrote:
> >>I just tagged the v229 release of systemd. Enjoy!
> >>
> >>CHANGES WITH 229:
> >>
> >>
> >>
> >> * When the stacktrace is extracted from processes of system users, 
> >> this
> >>   is now done as "systemd-coredump" user, in order to sandbox this
> >>   potentially security sensitive parsing operation. (Note that when
> >>   processing coredumps of normal users this is done under the user 
> >> ID
> >>   of process that crashed, as before.) Packagers should take notice
> >>   that it is now necessary to create the "systemd-coredump" system 
> >> user
> >>   and group at package installation time.
> >>
> >
> >Why is it left to downstream to create this user? What makes it
> >different from the other 4 users which systemd already creates?
> 
> systemd don't create any user. nowhere, rpm-scritrs downstream does

You're mistaken. See /usr/lib/sysusers.d/{basic,systemd,systemd-remote}.conf and
systemd-sysusers(8). The curious absence of systemd-coredump from
sysusers.d/systemd.conf is what I'm asking about here.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] no tar balls at release time

[Dave Reisner]

On Tue, Jun 23, 2015 at 01:19:54PM +0200, Kay Sievers wrote:
 On Tue, Jun 23, 2015 at 4:02 AM, Dave Reisner d...@falconindy.com wrote:
  On Tue, Jun 23, 2015 at 01:21:36AM +0200, Kay Sievers wrote:
  We currently considering to stop creating release tar balls.
 
  What's the motivation for this change?
 
 We focus on git, and git only. We do not want to sign tar balls to
 distribute, but rely on signed git tags only.
 
 Pre-building stuff to put into tar balls creates too many
 restrictions. It is just plain wrong to pre-build and ship things like
 man pages, which depend on common configure options.
 
  I suspect that with this, 'make
  distcheck' will never again be run and it will eventually break
  build configurations which don't align with what the CI tests.
 
 We synced the make dist and git archive tar balls as much as
 possible now. Even the autotools created one will not contain any
 pre-built stuff anymore besides the autofoo itself.
 
 We might continue to run distcheck in the CI, but we don't know
 anything for sure at that point in time, only that tar balls are not
 part of the release anymore.

To reiterate -- Arch doesn't care about tarballs going away. I'm
concerned that 'distcheck' provided some amount of pre-release sanity
checking, and I'd prefer that we don't lose that for a project which
already lacks a large amount of in-tree test coverage.

Everyone involved would benefit from something such as the following:
implement the equivalent of the kernels 'make allconfig' and use this
for the CI builds, rather than a bare ./configure (which won't pull in
much based on the deps being installed). I realize this can't be 100% of
the options since there's conflicting and legacy switches (like
split-usr). However, you'll at least be giving build system more
thorough testing, and decreasing the likelihood that release day is when
broken builds are reported on the mailing list.

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

Re: [systemd-devel] no tar balls at release time

[Dave Reisner]

On Tue, Jun 23, 2015 at 01:21:36AM +0200, Kay Sievers wrote:
 We currently considering to stop creating release tar balls.

What's the motivation for this change? I suspect that with this, 'make
distcheck' will never again be run and it will eventually break
build configurations which don't align with what the CI tests.

 For build systems which still require them, they can be created
 locally from the upstream git repository with:
   git archive --format=tar --prefix=systemd-$(VERSION)/ $(VERSION) | \
 xz  systemd-$(VERSION).tar.xz
 
 These tar balls will not include the 500k of shell scripts added by
 autotools. These files need to be added to the extracted tarball by
 running ./autogen.sh.
 
 These tar balls will also not include any generated content like
 fonts, man, html pages. This is intentional.
 
 Please test these setups locally if that model will work in your
 setups, and what would possibly need to be fixed in the git tree to
 make that easier for you.

Arch switched over to the git repo directly when it was discovered that
the v220 tarball wasn't useful. We didn't bother going back to the
tarballs with v221, either. Seems fine.

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

Re: [systemd-devel] 220 tarball erroneously ships keyboard-keys-from-name.gperf

[Dave Reisner]

On Tue, May 26, 2015 at 04:17:07PM +0200, Lennart Poettering wrote:
 On Tue, 26.05.15 15:12, Dimitri John Ledkov (dimitri.j.led...@intel.com) 
 wrote:
 
  Or will there be a v220.1 release shortly with releasy fix-ups?
 
 Well, we don't do point releases in systemd. 

 In systemd git we already have now the change that makes sd-bus and
 sd-event public APIs, hence v221 is going to be more than just
 bugfixes. 

Is git revert not an option? Does someone depend on this already, making
a rollback impossible (and why would you allow that)? You say that
versions are just a label, but a project which adopts semver would be
able to create a branch in git and produce a dot release with backported
bugfixes. Surely you're familiar with this concept -- your colleague
Karel does this routinely with util-linux.

The fact of the matter is, the last 2 releases of systemd have been
brown bag releases. Neither 219 nor 220 are useable as the tarballs are
provided. v220 doesn't even build in a large number of configurations.
v218 wasn't quite as bad, but landed 18 patches in Arch's packaging
before v219 was released. For the average Arch package, this is unheard
of, let alone being a *necessity* in order to make software useable.

Please, let's figure out a way to lower the amount of work that gets
sharded out and duplicated by downstream packagers.

 Also, next week I'll be travelling and I doubt I will be able to
 finish a new release by then. Maybe in the middle of June we can get
 out a new release.

 Sorry,

I'm sorry to hear this too. Please find someone else who's paid to work
on systemd and teach them how to package releases. The current state of
affairs absolutely sucks for downstreams. Currently, packaging systemd
takes more of my time than all of my other packaging responsibilities
combined.

At LPC in New Orleans, you asked me how you could make systemd easier to
work with on the downstream side. I told you that I wanted more frequent
releases. You seemed amenable to this, but it really never happened.
I'm asking again: can we have more frequent releases? Can you take the
steps to actually make this happen and not gate releases on your own
personal availability?

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

Re: [systemd-devel] [PATCH] [PATCH v3] nspawn: fallback on bind mount when mknod fails

[Dave Reisner]

On Tue, Mar 31, 2015 at 05:14:48PM +0200, Alban Crequy wrote:
 From: Alban Crequy al...@endocode.com
 
 Some systems abusively restrict mknod, even when the device node already
 exists in /dev. This is unfortunate because it prevents systemd-nspawn
 from creating the basic devices in /dev in the container.
 
 This patch implements a workaround: when mknod fails, fallback on bind
 mounts.
 
 Additionally, /dev/console was created with a mknod with the same
 major/minor as /dev/null before bind mounting a pts on it. This patch
 removes the mknod and creates an empty regular file instead.
 
 In order to test this patch, I used the following configuration, which I
 think should replicate the system with the abusive restriction on mknod:
 
   # grep devices /proc/self/cgroup
   4:devices:/user.slice/restrict
   # cat /sys/fs/cgroup/devices/user.slice/restrict/devices.list
   c 1:9 r
   c 5:2 rw
   c 136:* rw
   # systemd-nspawn --register=false -D .
 
 v2:
  - remove bind, it is not needed since there is already MS_BIND
 v3:
  - fix error management when calling touch()
  - fix lowercase in error message
 ---
  src/nspawn/nspawn.c | 29 -
  1 file changed, 16 insertions(+), 13 deletions(-)
 
 diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
 index b830141..7e56cf2 100644
 --- a/src/nspawn/nspawn.c
 +++ b/src/nspawn/nspawn.c
 @@ -1449,8 +1449,18 @@ static int copy_devnodes(const char *dest) {
  return -r;
  }
  
 -if (mknod(to, st.st_mode, st.st_rdev)  0)
 -return log_error_errno(errno, mknod(%s) 
 failed: %m, to);
 +if (mknod(to, st.st_mode, st.st_rdev)  0) {
 +if (errno != EPERM)
 +return log_error_errno(errno, 
 mknod(%s) failed: %m, to);
 +
 +/* Some systems abusively restrict mknod but
 + * allow bind mounts. */
 +r = touch(to);
 +if (r  0)
 +return log_error_errno(r, touch 
 (%s) failed: %m, to);

Is this really what you wanted? It's not obvious that errno will have
the correct value when %m is evaluated. I would have used strerror(-r)
here.

 +if (mount(from, to, NULL, MS_BIND, NULL)  0)
 +return log_error_errno(errno, Both 
 mknod and bind mount (%s) failed: %m, to);
 +}
  
  if (arg_userns  arg_uid_shift != UID_INVALID)
  if (lchown(to, arg_uid_shift, arg_uid_shift) 
  0)
 @@ -1481,7 +1491,6 @@ static int setup_ptmx(const char *dest) {
  static int setup_dev_console(const char *dest, const char *console) {
  _cleanup_umask_ mode_t u;
  const char *to;
 -struct stat st;
  int r;
  
  assert(dest);
 @@ -1489,24 +1498,18 @@ static int setup_dev_console(const char *dest, const 
 char *console) {
  
  u = umask();
  
 -if (stat(/dev/null, st)  0)
 -return log_error_errno(errno, Failed to stat /dev/null: 
 %m);
 -
  r = chmod_and_chown(console, 0600, 0, 0);
  if (r  0)
  return log_error_errno(r, Failed to correct access mode for 
 TTY: %m);
  
  /* We need to bind mount the right tty to /dev/console since
   * ptys can only exist on pts file systems. To have something
 - * to bind mount things on we create a device node first, and
 - * use /dev/null for that since we the cgroups device policy
 - * allows us to create that freely, while we cannot create
 - * /dev/console. (Note that the major minor doesn't actually
 - * matter here, since we mount it over anyway). */
 + * to bind mount things on we create a empty regular file. */
  
  to = strjoina(dest, /dev/console);
 -if (mknod(to, (st.st_mode  ~0) | 0600, st.st_rdev)  0)
 -return log_error_errno(errno, mknod() for /dev/console 
 failed: %m);
 +r = touch(to);
 +if (r  0)
 +return log_error_errno(r, touch() for /dev/console failed: 
 %m);
  
  if (mount(console, to, NULL, MS_BIND, NULL)  0)
  return log_error_errno(errno, Bind mount for /dev/console 
 failed: %m);
 -- 
 2.1.4
 
 ___
 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] [PATCH] [PATCH v3] nspawn: fallback on bind mount when mknod fails

[Dave Reisner]

On Tue, Mar 31, 2015 at 07:14:26PM +0200, Lennart Poettering wrote:
 On Tue, 31.03.15 11:35, Dave Reisner (d...@falconindy.com) wrote:
 
   +/* Some systems abusively restrict mknod 
   but
   + * allow bind mounts. */
   +r = touch(to);
   +if (r  0)
   +return log_error_errno(r, touch 
   (%s) failed: %m, to);
  
  Is this really what you wanted? It's not obvious that errno will have
  the correct value when %m is evaluated. I would have used strerror(-r)
  here.
 
 No. The log_error_errno() macro will set errno explicitly before
 invoking sprintf() to resolve %m, so that %m actually maps to the
 passed error instead of the original errno.
 
 In fact, I really recommend against strerror() since it is not
 thread-safe. Whenever possible we should use the %m thing like in
 Alban's patch. And if that's not appropriate then we should use
 strerror_r() instead of strerror().
 
 Lennart

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

Re: [systemd-devel] [PATCH] adjust for time spent in timedated even without dbus timestamp

[Dave Reisner]

On Fri, Mar 06, 2015 at 05:22:22PM -0800, Shawn Landden wrote:
 it is trivial to fall back to our own timestamp
 
 v2: use now()
 ---
  src/timedate/timedated.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)
 
 diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
 index 88d57e9..75b1f1b 100644
 --- a/src/timedate/timedated.c
 +++ b/src/timedate/timedated.c
 @@ -551,6 +551,9 @@ static int method_set_time(sd_bus *bus, sd_bus_message 
 *m, void *userdata, sd_bu
  if (c-use_ntp)
  return sd_bus_error_setf(error, 
 BUS_ERROR_AUTOMATIC_TIME_SYNC_ENABLED, Automatic time synchronization is 
 enabled);
  
 +/* this only gets used if dbus does not provide a timestamp */
 +start = now(CLOCK_MONOTONIC);
 +
  r = sd_bus_message_read(m, xbb, utc, relative, interactive);
  if (r  0)
  return r;
 @@ -592,7 +595,7 @@ static int method_set_time(sd_bus *bus, sd_bus_message 
 *m, void *userdata, sd_bu
  r = sd_bus_message_get_monotonic_usec(m, start);
  if (r  0  r != -ENODATA)
  return r;
 -if (r = 0)
 +if (r = 0 || r == -ENODATA)

Isn't this condition always true if reached?

  timespec_store(ts, timespec_load(ts) + 
 (now(CLOCK_MONOTONIC) - start));
  
  /* Set system clock */
 -- 
 2.2.1.209.g41e5f3a
 
 ___
 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] [PATCH] systemd-udevd.service: restore mount propagation

[Dave Reisner]

On Tue, Jan 27, 2015 at 05:33:06PM +0100, Martin Pitt wrote:
 Lennart Poettering [2015-01-27 17:22 +0100]:
  The .mount units of device nodes already have a BindsTo= dependency on
  their respective backing .device units. This should have the effect
  that systemd will take the .mount units down if the .device units are
  removed. Are you saying that doesn't work?
 
 It's been ages since I've had a CD drive with an eject button, so I
 can't say myself. But given the recent reports on the list from Robert
 Milasan and Dave Reiser it seems that *something* here is still
 broken?

Well, my test case was flawed and the mount namespacing in udevd isn't
actually relevant to the problem. I've since found myself uninterested
in solving this particular problem.

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

[systemd-devel] [PATCH] systemd-udevd.service: restore mount propagation

[Dave Reisner]

This reverts part of c2c13f2df42e0, which introduced this with no
explanation as to *why*. Enslaving the mount namespace breaks default
behavior included in rules/60-cdrom_id.rules. Specifically, filesystems
on optical media will not be properly unmounted when the physical eject
button is used in the absence of a helper tool like udisks2.

This was discussed here:

http://lists.freedesktop.org/archives/systemd-devel/2015-January/026948.html

And has been reported to several bug trackers:

https://bugs.archlinux.org/task/42071
http://bugzilla.opensuse.org/show_bug.cgi?id=909418
https://bugs.freedesktop.org/bugzilla/show_bug.cgi?id=72206
---
I'm guessing that the rationale for the breaking commit was dissuading users
from calling mount(8) from udev rules, but I don't think that's a good enough
reason to break users who don't use udisks and still rely on optical media.
More to the point, do we really need to patch around bad users? Other than
mount(8) hanging and tying up a udevd worker (which will eventually be killed
by the cgroup cleanup logic), what's the actual harm that comes from mounting
via a udev rule?

 units/systemd-udevd.service.in | 1 -
 1 file changed, 1 deletion(-)

diff --git a/units/systemd-udevd.service.in b/units/systemd-udevd.service.in
index f6acd6f..57ea5f7 100644
--- a/units/systemd-udevd.service.in
+++ b/units/systemd-udevd.service.in
@@ -21,4 +21,3 @@ Sockets=systemd-udevd-control.socket 
systemd-udevd-kernel.socket
 Restart=always
 RestartSec=0
 ExecStart=@rootlibexecdir@/systemd-udevd
-MountFlags=slave
-- 
2.2.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Second (erroneous) check of rootfs?

[Dave Reisner]

On Sun, Jan 11, 2015 at 10:09:08AM +0300, Andrei Borzenkov wrote:
 В Sat, 10 Jan 2015 16:51:24 +0300
 Nikolai Zhubr n-a-zh...@yandex.ru пишет:
 
  Hi,
  09.01.2015 23:48, Chris Murphy:
  [...]
   I might be missing something, but what's wrong with the existing 
   root=...
   rootfstype=... rootflags=... rw options? Why is the remount even 
   necessary?
  
   Seems to be distro specific. I see rw for opensuse or Ubuntu, and ro for 
   Fedora.
  
   The ro seems antiquated to me, meant for interactive fsck on an ro
   mounted filesystem when booting single user. 'btrfs check' refuses to
   run on mounted file systems, even if ro. And xfs_repair requires the
   use of -d repair dangerously to do so.
  
   Both XFS and Btrfs have placeholder fsck's, if you man fsck.xfs or
   fsck.btrfs you'll see. These filesystems are designed to fix most
  
  Ok. I've invented a quick-and-dirty fix. I'll modify systemd-fsck so 
  that when run with no argument it does nothing and exit successfully. 
  This way I'll still have rootfs fsck'ed every boot, but never twice.
  
 
 Uh. Why not simply mount rootfs rw in initrd then?
 
  I'll soon need this box for work anyway, reverting to some 12.x does not 
  seem very attractive, and living with this bug every day won't give me a 
  good feeling either. (Just a week ago I had one single erroneous fsck 
  rendering my rootfs essentially to a complete trash)
  
  Hope someone will come up with a better solution though :)
 
 The more I think about it the more I find it non-issue. As was already
 mentioned, systemd-fsck checks whether rootfs is mounted read-write and
 will skip check in this case. Could someone give a compelling reason why
 initrd would want to mount rootfs read-only after having fsck'ed it?
 
 Otherwise the only way to prevent second fsck is to pass some flag from
 initrd to real root, like /run/systemd/fsck-root-done. There is no

This flag file used to exist (though differently named). As soon as
dracut started using systemd, the flag file was deemed unnecessary for
everyone. See commit 956eaf2b8d6 for its removal. See /dev/null for the
discussion which took place before removing it.

 feasible way to reuse the same systemd-fsck-root.service without
 introducing hard dependency on initrd implementation. I hoped to get
 away by just symlinking systemd-fsck-root.service to
 systemd-fsck@root-dev.service, but it's not possible. 
 ___
 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] [PATCH 1/2] systemd-helpers

[Dave Reisner]

On Sat, Jan 10, 2015 at 01:33:05PM +0100, Carlos Morata Castillo wrote:
 Hi,
 
 As stated here, we should use a library for bash autocompletions (maybe even 
 with include guards).
 http://cgit.freedesktop.org/systemd/systemd/commit/shell-completion/bash/localectl?id=a72d698d0d9ff9c158155b44cdc77376df31a317
 
 Explanation:
 
 Using autotools make the autocompletions to 
 /usr/share/bash-completions/completions (as the exit from pkg-config 
 --variable=completionsdir
 bash-completion).
 We ended up having multiple function definitions and even messing around with 
 the global bash function namespace, as the functions are called
 __get_something being possible to redefine other binary bash function. 

Why the exception for busctl and systemctl?

You aren't actually solving any problems with redefinition in this
patch. You're actually making the problem worse. Instead of redefining
*some* common functions on completion load, you're forcing *all* common
functions in systemd-helpers to be redefined (even if only 1 is used). I
don't really see this as a problem, though, and you don't explain why
you seem to think it is.

How is sourcing this library supposed to work? Each file contains:

  #Common functions
  . ./systemd-helpers

But that file won't be in $PWD when completions are loaded. Sourcing
works like any other command -- relative paths will be relative to the
current process's $PWD, not relative to the disk file calling source.
Without cd'ing into /usr/share/bash-completions/completions, this
doesn't work (and please don't cd from completions).

I'm not against deduplicating this common code, but you'd be better off
using m4_include to preprocess the completions at build time.

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

Re: [systemd-devel] [PATCH 1/2] test-verbs: add unit tests for verbs minilib

[Dave Reisner]

On Thu, Jan 08, 2015 at 09:40:07PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
 On Sat, Dec 20, 2014 at 03:31:21PM -0800, Filipe Brandenburger wrote:
  Hi,
  
  On Sat, Dec 20, 2014 at 8:19 AM, Dave Reisner dreis...@archlinux.org 
  wrote:
   ---
Makefile.am   |  9 +-
src/test/test-verbs.c | 78 
   +++
2 files changed, 86 insertions(+), 1 deletion(-)
create mode 100644 src/test/test-verbs.c
  
   diff --git a/Makefile.am b/Makefile.am
   index baa1398..db7dd46 100644
   --- a/Makefile.am
   +++ b/Makefile.am
   @@ -1384,7 +1384,8 @@ tests += \
   test-locale-util \
   test-execute \
   test-copy \
   -   test-cap-list
   +   test-cap-list \
   +   test-verbs
  
  Make sure you also add /test-verbs to the top level .gitignore.
 Please push this anyway, even if the other part does not go in.
 
 Zbyszek

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

Re: [systemd-devel] systemd coredumps

[Dave Reisner]

On Thu, Jan 01, 2015 at 07:05:04PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
 On Thu, Jan 01, 2015 at 05:57:43PM -, Markus Moeller wrote:
  Hi,
  
   How can I find out why systemd core dumps  and requires system
  reboot :-( ?
  
  I just did
  
  # systemctl status sockd-1.5.0
  Failed to issue method call: Did not receive a reply. Possible
  causes include: the remote application did not send a reply, the
  message bus security policy blocked the reply, the reply timeout
  expired, or the network connection was broken.
  # systemctl status sockd-1.5.0
  Failed to get D-Bus connection: Failed to connect to socket
  /run/systemd/private: Connection refused
  
  2015-01-01T17:52:01.625495+00:00 opensuse12 systemd[1]: Accepted
  connection on private bus.
  2015-01-01T17:52:01.626333+00:00 opensuse12 systemd[1]: Running GC...
  2015-01-01T17:52:01.627976+00:00 opensuse12 systemd[1]: Got D-Bus
  request: org.freedesktop.DBus.Properties.GetAll() on
  /org/freedesktop/systemd1/unit/sockd_2d1_2e5_2e0
  2015-01-01T17:52:01.636546+00:00 opensuse12 systemd[1]: Assertion
  'endswith(path, .service)' failed at src/core/service.c:1077,
  function service_load_sysv_name(). Aborting.
 The reason is given right here. A failed assertion, i.e. a programming
 error.
 
 Please open a bug on bugs.freedesktop.org and attach the core if you can
 and describe the steps to trigger this.

Hrmm? The OP is using a build of systemd v195. It's unlikely this is
reproducible at HEAD, or any recent release. The referenced function was
removed in v214 (see commit 817e224bbce3ed) when sysv unit handling was
moved off to a generator.

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

Re: [systemd-devel] [PATCH] Do not clear parent mount flags when setting up namespaces

[Dave Reisner]

On Thu, Jan 01, 2015 at 04:49:04PM +0200, Topi Miettinen wrote:
 Copy parent directory mount flags when setting up a namespace and
 don't accidentally clear mount flags later.
 
 Signed-off-by: Topi Miettinen toiwo...@gmail.com
 ---
  src/core/namespace.c |  4 ++--
  src/shared/util.c| 20 ++--
  src/shared/util.h|  2 ++
  3 files changed, 22 insertions(+), 4 deletions(-)
 
 diff --git a/src/core/namespace.c b/src/core/namespace.c
 index 5b408e0..400bc50 100644
 --- a/src/core/namespace.c
 +++ b/src/core/namespace.c
 @@ -159,7 +159,7 @@ static int mount_dev(BindMount *m) {
  
  dev = strappenda(temporary_mount, /dev);
  (void)mkdir(dev, 0755);
 -if (mount(tmpfs, dev, tmpfs, MS_NOSUID|MS_STRICTATIME, 
 mode=755)  0) {
 +if (mount(tmpfs, dev, tmpfs, 
 get_mount_flags(/dev)|MS_NOSUID|MS_STRICTATIME, mode=755)  0) {
  r = -errno;
  goto fail;
  }
 @@ -282,7 +282,7 @@ static int mount_kdbus(BindMount *m) {
  
  root = strappenda(temporary_mount, /kdbus);
  (void)mkdir(root, 0755);
 -if (mount(tmpfs, root, tmpfs, MS_NOSUID|MS_STRICTATIME, 
 mode=777)  0) {
 +if (mount(tmpfs, root, tmpfs, 
 get_mount_flags(/kdbus)|MS_NOSUID|MS_STRICTATIME, mode=777)  0) {

Shouldn't this be /sys/fs/bus/kdbus? We certainly don't mount kdbusfs in
the root...

  r = -errno;
  goto fail;
  }
 diff --git a/src/shared/util.c b/src/shared/util.c
 index dfaf7f7..31fbb68 100644
 --- a/src/shared/util.c
 +++ b/src/shared/util.c
 @@ -61,6 +61,7 @@
  #include sys/personality.h
  #include sys/xattr.h
  #include libgen.h
 +#include sys/statvfs.h
  #undef basename
  
  #ifdef HAVE_SYS_AUXV_H
 @@ -6858,6 +6859,16 @@ int umount_recursive(const char *prefix, int flags) {
  return r ? r : n;
  }
  
 +unsigned long get_mount_flags(const char *path)
 +{

Reigning style says to put the opening { at the end of the first line.

 +struct statvfs buf;
 +
 +if (statvfs(path, buf)  0)
 +return 0;
 +
 +return buf.f_flag;
 +}
 +
  int bind_remount_recursive(const char *prefix, bool ro) {
  _cleanup_set_free_free_ Set *done = NULL;
  _cleanup_free_ char *cleaned = NULL;
 @@ -6892,6 +6903,7 @@ int bind_remount_recursive(const char *prefix, bool ro) 
 {
  _cleanup_set_free_free_ Set *todo = NULL;
  bool top_autofs = false;
  char *x;
 +unsigned long orig_flags;
  
  todo = set_new(string_hash_ops);
  if (!todo)
 @@ -6969,7 +6981,9 @@ int bind_remount_recursive(const char *prefix, bool ro) 
 {
  if (mount(cleaned, cleaned, NULL, MS_BIND|MS_REC, 
 NULL)  0)
  return -errno;
  
 -if (mount(NULL, prefix, NULL, MS_BIND|MS_REMOUNT|(ro 
 ? MS_RDONLY : 0), NULL)  0)
 +orig_flags = get_mount_flags(prefix);
 +orig_flags = ~MS_RDONLY;
 +if (mount(NULL, prefix, NULL, 
 orig_flags|MS_BIND|MS_REMOUNT|(ro ? MS_RDONLY : 0), NULL)  0)
  return -errno;
  
  x = strdup(cleaned);
 @@ -6989,7 +7003,9 @@ int bind_remount_recursive(const char *prefix, bool ro) 
 {
  if (r  0)
  return r;
  
 -if (mount(NULL, x, NULL, MS_BIND|MS_REMOUNT|(ro ? 
 MS_RDONLY : 0), NULL)  0) {
 +orig_flags = get_mount_flags(x);
 +orig_flags = ~MS_RDONLY;
 +if (mount(NULL, x, NULL, 
 orig_flags|MS_BIND|MS_REMOUNT|(ro ? MS_RDONLY : 0), NULL)  0) {
  
  /* Deal with mount points that are
   * obstructed by a later mount */
 diff --git a/src/shared/util.h b/src/shared/util.h
 index a131a3c..4b3070a 100644
 --- a/src/shared/util.h
 +++ b/src/shared/util.h
 @@ -1021,6 +1021,8 @@ union file_handle_union {
  
  int update_reboot_param_file(const char *param);
  
 +unsigned long get_mount_flags(const char *path);
 +
  int umount_recursive(const char *target, int flags);
  
  int bind_remount_recursive(const char *prefix, bool ro);
 -- 
 2.1.4
 
 ___
 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

[systemd-devel] [PATCH 2/2] verbs: allow matching by prefix

[Dave Reisner]

Be nice to command line users and allow matching prefixes of verbs,
similar to the way getopt_long operates. If the prefix cannot be
resolved to a singular verb, log the ambiguity and return an error.
---
I'm not thrilled about adding this to every manpage out of concern that it
might get out of sync, but I don't really see a better way.

 man/bootctl.xml|  3 ++-
 man/busctl.xml |  3 ++-
 man/coredumpctl.xml|  3 ++-
 man/hostnamectl.xml|  3 ++-
 man/kernel-install.xml |  3 ++-
 man/localectl.xml  |  3 ++-
 man/loginctl.xml   |  3 ++-
 man/systemctl.xml  |  3 ++-
 man/telinit.xml|  3 ++-
 src/shared/verbs.c | 58 ++
 src/test/test-verbs.c  |  9 
 11 files changed, 71 insertions(+), 23 deletions(-)

diff --git a/man/bootctl.xml b/man/bootctl.xml
index 5254022..93363bd 100644
--- a/man/bootctl.xml
+++ b/man/bootctl.xml
@@ -79,7 +79,8 @@
 xi:include href=standard-options.xml 
xpointer=version /
 /variablelist
 
-paraThe following commands are understood:/para
+paraCommands can be specified by exact match or unambiguous 
prefix match.
+The following commands are understood:/para
 
 variablelist
 varlistentry
diff --git a/man/busctl.xml b/man/busctl.xml
index 285725e..a215a7e 100644
--- a/man/busctl.xml
+++ b/man/busctl.xml
@@ -260,7 +260,8 @@ along with systemd; If not, see 
http://www.gnu.org/licenses/.
   refsect1
 titleCommands/title
 
-paraThe following commands are understood:/para
+paraCommands can be specified by exact match or unambiguous prefix match.
+The following commands are understood:/para
 
 variablelist
   varlistentry
diff --git a/man/coredumpctl.xml b/man/coredumpctl.xml
index ed84621..28cce85 100644
--- a/man/coredumpctl.xml
+++ b/man/coredumpctl.xml
@@ -111,7 +111,8 @@
 
 /variablelist
 
-paraThe following commands are understood:/para
+paraCommands can be specified by exact match or unambiguous 
prefix match.
+The following commands are understood:/para
 
 variablelist
 varlistentry
diff --git a/man/hostnamectl.xml b/man/hostnamectl.xml
index de15402..51cb995 100644
--- a/man/hostnamectl.xml
+++ b/man/hostnamectl.xml
@@ -135,7 +135,8 @@
 xi:include href=standard-options.xml 
xpointer=version /
 /variablelist
 
-paraThe following commands are understood:/para
+paraCommands can be specified by exact match or unambiguous 
prefix match.
+The following commands are understood:/para
 
 variablelist
 varlistentry
diff --git a/man/kernel-install.xml b/man/kernel-install.xml
index d4d0180..aa6aca2 100644
--- a/man/kernel-install.xml
+++ b/man/kernel-install.xml
@@ -79,7 +79,8 @@ along with systemd; If not, see 
http://www.gnu.org/licenses/.
 
   refsect1
 titleCommands/title
-paraThe following commands are understood:/para
+paraCommands can be specified by exact match or unambiguous prefix match.
+The following commands are understood:/para
 variablelist
   varlistentry
 termcommandadd replaceableKERNEL-VERSION/replaceable 
replaceableKERNEL-IMAGE/replaceable/command/term
diff --git a/man/localectl.xml b/man/localectl.xml
index b472b6b..8f5b442 100644
--- a/man/localectl.xml
+++ b/man/localectl.xml
@@ -113,7 +113,8 @@
 xi:include href=standard-options.xml 
xpointer=no-pager /
 /variablelist
 
-paraThe following commands are understood:/para
+paraCommands can be specified by exact match or unambiguous 
prefix match.
+The following commands are understood:/para
 
 variablelist
 varlistentry
diff --git a/man/loginctl.xml b/man/loginctl.xml
index 749db92..f2162ac 100644
--- a/man/loginctl.xml
+++ b/man/loginctl.xml
@@ -165,7 +165,8 @@
 xi:include href=standard-options.xml 
xpointer=no-pager /
 /variablelist
 
-paraThe following commands are understood:/para
+paraCommands can be specified by exact match or unambiguous 
prefix match.
+The following commands are understood:/para
 
 variablelist
 varlistentry
diff --git a/man/systemctl.xml b/man/systemctl.xml
index d1991e0..91fcba3 100644
--- a/man/systemctl.xml
+++ b/man/systemctl.xml
@@ -557,7 +557,8 @@ along with systemd; If not, see 
http://www.gnu.org/licenses/.
   refsect1
 titleCommands/title
 
-paraThe following commands are understood:/para
+paraCommands can be specified by exact match or unambiguous prefix match.
+The following commands are understood:/para
 
 

[systemd-devel] [PATCH 1/2] test-verbs: add unit tests for verbs minilib

[Dave Reisner]

---
 Makefile.am   |  9 +-
 src/test/test-verbs.c | 78 +++
 2 files changed, 86 insertions(+), 1 deletion(-)
 create mode 100644 src/test/test-verbs.c

diff --git a/Makefile.am b/Makefile.am
index baa1398..db7dd46 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1384,7 +1384,8 @@ tests += \
test-locale-util \
test-execute \
test-copy \
-   test-cap-list
+   test-cap-list \
+   test-verbs
 
 EXTRA_DIST += \
test/a.service \
@@ -1651,6 +1652,12 @@ test_tmpfiles_LDADD = \
 test_namespace_SOURCES = \
src/test/test-namespace.c
 
+test_verbs_SOURCES = \
+   src/test/test-verbs.c
+
+test_verbs_LDADD = \
+   libsystemd-shared.la
+
 test_namespace_LDADD = \
libsystemd-core.la
 
diff --git a/src/test/test-verbs.c b/src/test/test-verbs.c
new file mode 100644
index 000..0fcdd9e
--- /dev/null
+++ b/src/test/test-verbs.c
@@ -0,0 +1,78 @@
+/***
+  This file is part of systemd.
+
+  Copyright 2014 systemd developers
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see http://www.gnu.org/licenses/.
+***/
+
+#include macro.h
+#include strv.h
+#include verbs.h
+
+static int noop_dispatcher(int argc, char *argv[], void *userdata) {
+return 0;
+}
+
+#define test_dispatch_one(argv, verbs, expected) \
+optind = 0; \
+assert_se(dispatch_verb(strv_length(argv), argv, verbs, NULL) == 
expected);
+
+static void test_verbs(void) {
+static const Verb verbs[] = {
+{ help,VERB_ANY, VERB_ANY, 0,
noop_dispatcher },
+{ list-images, VERB_ANY, 1,0,
noop_dispatcher },
+{ list,VERB_ANY, 2,VERB_DEFAULT, 
noop_dispatcher },
+{ status,  2,VERB_ANY, 0,
noop_dispatcher },
+{ show,VERB_ANY, VERB_ANY, 0,
noop_dispatcher },
+{ terminate,   2,VERB_ANY, 0,
noop_dispatcher },
+{ login,   2,2,0,
noop_dispatcher },
+{ copy-to, 3,4,0,
noop_dispatcher },
+{}
+};
+
+/* not found */
+test_dispatch_one(STRV_MAKE(command-not-found), verbs, -EINVAL);
+
+/* found */
+test_dispatch_one(STRV_MAKE(show), verbs, 0);
+
+/* found, too few args */
+test_dispatch_one(STRV_MAKE(copy-to, foo), verbs, -EINVAL);
+
+/* found, meets min args */
+test_dispatch_one(STRV_MAKE(status, foo, bar), verbs, 0);
+
+/* found, too many args */
+test_dispatch_one(STRV_MAKE(copy-to, foo, bar, baz, quux, 
qaax), verbs, -EINVAL);
+
+/* no verb, but a default is set */
+test_dispatch_one(STRV_MAKE_EMPTY, verbs, 0);
+}
+
+static void test_verbs_no_default(void) {
+static const Verb verbs[] = {
+{ help, VERB_ANY, VERB_ANY, 0, noop_dispatcher },
+{},
+};
+
+test_dispatch_one(STRV_MAKE(NULL), verbs, -EINVAL);
+}
+
+int main(int argc, char *argv[]) {
+test_verbs();
+test_verbs_no_default();
+
+return 0;
+}
-- 
2.2.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [ANNOUNCE] systemd v218

[Dave Reisner]

On Sun, Dec 14, 2014 at 10:32:42AM -0500, Mike Gilbert wrote:
 On Wed, Dec 10, 2014 at 7:16 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  Heya!
 
  Here's the next version of systemd, v218:
 
  http://www.freedesktop.org/software/systemd/systemd-218.tar.xz
 
 Hi Lennart,
 
 It looks like the tarball is missing units/user/systemd-consoled.service.
 
 make[2]: *** No rule to make target
 'units/user/systemd-consoled.service.in', needed by
 'units/user/systemd-consoled.service'.  Stop.
 
 Please make sure you configure with --enable-terminal when creating the 
 tarball.

Thanks for the report. Should be fixed in git.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] shared/install: avoid prematurely rejecting missing units

[Dave Reisner]

On Fri, Oct 31, 2014 at 04:04:53AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
 On Thu, Oct 30, 2014 at 08:28:14PM -0400, Dave Reisner wrote:
  f7101b7368df copied some logic to prevent enabling masked units, but
  also added a check which causes attempts to enable templated units to
  fail. Since we know the logic beyond this check will properly handle
  units which truly do not exist, we can rely on the unit file state
  comparison to suffice for expressing the intent of f7101b7368df.
  
  ref: https://bugs.archlinux.org/task/42616
  ---
  This seems to me like the right thing to do, but I'm not so familiar with
  this code...
 
 I verified that your fix works. Can you add a comment in the code which
 explains why state is not checked though? It should help with future
 modifications.
 
 Zbyszek
 

Thanks! Added a comment and pushed.

  
   src/shared/install.c | 5 -
   1 file changed, 5 deletions(-)
  
  diff --git a/src/shared/install.c b/src/shared/install.c
  index 035b44c..3ad5362 100644
  --- a/src/shared/install.c
  +++ b/src/shared/install.c
  @@ -1621,11 +1621,6 @@ int unit_file_enable(
   UnitFileState state;
   
   state = unit_file_get_state(scope, root_dir, *i);
  -if (state  0) {
  -log_error(Failed to get unit file state for %s: 
  %s, *i, strerror(-state));
  -return state;
  -}
  -
   if (state == UNIT_FILE_MASKED || state == 
  UNIT_FILE_MASKED_RUNTIME) {
   log_error(Failed to enable unit: Unit %s is 
  masked, *i);
   return -ENOTSUP;
  -- 
  2.1.3
  ___
  systemd-devel mailing list
  systemd-devel@lists.freedesktop.org
  http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] missing: Correct and extend getrandom syscall defines

[Dave Reisner]

On Thu, Oct 30, 2014 at 12:39:53PM +0100, Lennart Poettering wrote:
 On Wed, 29.10.14 21:02, Dave Reisner (d...@falconindy.com) wrote:
 
  On Wed, Oct 29, 2014 at 11:55:29PM +0100, Lennart Poettering wrote:
   On Wed, 29.10.14 14:29, Cristian Rodríguez (crrodrig...@opensuse.org) 
   wrote:
   
Add syscall numbers for 32 bit x86 and arm and Correct
the system call number for x86_64 (it is 318 not 278)
   
   Hmm? I did my testing on x86_64 3.18rc2, 278 is what worked
   here... Did you test 318? Where does that number come from?
  
  I didn't see Cristian's patch and committed this:
  
  http://cgit.freedesktop.org/systemd/systemd/commit/?id=74a550c
 
 Humm? Did you test it with that? I tested it on my 3.18 with 278, and
 it worked fine. 
 

Sure did. A value of 278 leads me to a unusuable nspawn binary and an
unbootable system. After my change to 318, nspawn works again, and I can
boot.

Where did you get this value from? How did you test it? My hypothesis:
your kernel API headers are from 3.17 and provide a definition of
__NR_getrandom. Therefore, this fallback was never picked up from
configure.ac in your test build.

  Is there a reason to avoid the syscall on i386?
 
 No, I just didn't have any system to test it with. The other numebrs
 should of course be added...

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

Re: [systemd-devel] Switch root slowness

[Dave Reisner]

On Thu, Oct 30, 2014 at 01:18:24PM +0100, Jan Synáček wrote:
 Hello,
 
 commit 539618a0ddc2dc7f0fbe28de2ae0e07b34c81e60
 Author: Lennart Poettering lenn...@poettering.net
 Date:   Wed Oct 29 17:06:32 2014 +0100
 
 util: make use of the new getrandom() syscall if it is available when 
 needing entropy
 
 Doesn't require an fd, and could be a bit faster, so let's make use of
 it, if it is available.
 
 Beginning from this commit, switch root takes about a minute on my machine.
 
 Excerpts from the journal:
 Oct 30 13:08:37 fedora-rawhide-systemd-virt kernel: random: systemd urandom 
 read with 10 bits of entropy available
 Oct 30 13:08:37 fedora-rawhide-systemd-virt systemd-journal[109]: Journal 
 started
 Oct 30 13:08:37 fedora-rawhide-systemd-virt dracut-cmdline[105]: dracut-22 
 (Rawhide) dracut-038-36.git20140815.fc22
 Oct 30 13:08:37 fedora-rawhide-systemd-virt dracut-cmdline[105]: Using kernel 
 command line parameters:
 Oct 30 13:08:37 fedora-rawhide-systemd-virt systemd-udevd[158]: starting 
 version 216
 
 This line is pretty weird too, this commit is after v217 had been tagged.
 

Not that weird, it just means you didn't update your initrd after
updating to 217.

 ...

 Oct 30 13:08:38 fedora-rawhide-systemd-virt systemd[1]: Switching root.
 Oct 30 13:08:38 fedora-rawhide-systemd-virt systemd-journal[109]: Journal 
 stopped
 
 Hangs here for a while with no output.
 
 Oct 30 13:09:44 fedora-rawhide-systemd-virt systemd-journal[279]: Runtime 
 journal is using 8.0M (max allowed 100.0M, trying to leave 150.1M free of 
 992.7M available → current limit 100.0M).
 Oct 30 13:09:44 fedora-rawhide-systemd-virt systemd-journal[279]: Runtime 
 journal is using 8.0M (max allowed 100.0M, trying to leave 150.1M free of 
 992.7M available → current limit 100.0M).
 Oct 30 13:09:44 fedora-rawhide-systemd-virt systemd-journald[109]: Received 
 SIGTERM from PID 1 (systemd).
 snip a lot of selinux related stuff
 Oct 30 13:09:44 fedora-rawhide-systemd-virt kernel: random: nonblocking pool 
 is initialized
 
 Is anyone else running into this?

Probably fixed by:

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

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

[systemd-devel] [PATCH] shared/install: avoid prematurely rejecting missing units

[Dave Reisner]

f7101b7368df copied some logic to prevent enabling masked units, but
also added a check which causes attempts to enable templated units to
fail. Since we know the logic beyond this check will properly handle
units which truly do not exist, we can rely on the unit file state
comparison to suffice for expressing the intent of f7101b7368df.

ref: https://bugs.archlinux.org/task/42616
---
This seems to me like the right thing to do, but I'm not so familiar with
this code...

 src/shared/install.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/src/shared/install.c b/src/shared/install.c
index 035b44c..3ad5362 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -1621,11 +1621,6 @@ int unit_file_enable(
 UnitFileState state;
 
 state = unit_file_get_state(scope, root_dir, *i);
-if (state  0) {
-log_error(Failed to get unit file state for %s: %s, 
*i, strerror(-state));
-return state;
-}
-
 if (state == UNIT_FILE_MASKED || state == 
UNIT_FILE_MASKED_RUNTIME) {
 log_error(Failed to enable unit: Unit %s is masked, 
*i);
 return -ENOTSUP;
-- 
2.1.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] sd-dhcp-client: clean up raw socket sd_event_source when creating new UDP socket

[Dave Reisner]

On Thu, Oct 30, 2014 at 09:39:40PM +0100, Tom Gundersen wrote:
 Applied. Thanks!
 

But not pushed?

 On Thu, Oct 30, 2014 at 8:23 PM, Dan Williams d...@redhat.com wrote:
  The raw socket sd_event_source used for DHCP server solicitations
  was simply dropped on the floor when creating the new UDP socket
  after a lease has been acquired.  Clean it up properly so we're
  not still listening and responding to events on it.
 
  ---
  ...
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] missing: Correct and extend getrandom syscall defines

[Dave Reisner]

On Wed, Oct 29, 2014 at 11:55:29PM +0100, Lennart Poettering wrote:
 On Wed, 29.10.14 14:29, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:
 
  Add syscall numbers for 32 bit x86 and arm and Correct
  the system call number for x86_64 (it is 318 not 278)
 
 Hmm? I did my testing on x86_64 3.18rc2, 278 is what worked
 here... Did you test 318? Where does that number come from?

I didn't see Cristian's patch and committed this:

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

Is there a reason to avoid the syscall on i386?

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

Re: [systemd-devel] transforming Iptables bash script to systemd service file -help

[Dave Reisner]

On Wed, Oct 22, 2014 at 12:37:36PM +0100, Simon McVittie wrote:
 On 21/10/14 20:30, Lennart Poettering wrote:
  But in cases like the iptables tool (which
  is written in a style that kinda requires the usage of shell scripts
  to invoke it, since it is more a programming language and is seldom
  called just once at boot)
 
 If your ruleset is static (e.g. does not depend on the local IP
 address), it's very close to not needing a shell: all it would need is
 for systemd to support StandardInput=/a/file/path, or for
 iptables-restore to support --file /a/file/path, or something similar.
 
 iptables-save | sudo tee /etc/my-firewall
 ip6tables-save | sudo tee /etc/my-firewall6
 
 ExecStart=/bin/sh -c 'iptables-restore  /etc/my-firewall'
 
 ExecStart=/bin/sh -c 'ip6tables-restore  /etc/my-firewall6'

While it isn't documented in the manpage, the iptables-restore code
documents that if a single non-option argument is passed, it will try to
use that as the rule source to restore:

  if (optind == argc - 1) {
  in = fopen(argv[optind], re);
  if (!in) {
  fprintf(stderr, Can't open %s: %s\n, argv[optind],
  strerror(errno));
  exit(1);
  }
  }
  else if (optind  argc) {
  fprintf(stderr, Unknown arguments found on commandline\n);
  exit(1);
  }
  else in = stdin;

So, no need for any redirects here. Arch ships this for an iptables
service:

  [Unit]
  Description=Packet Filtering Framework

  [Service]
  Type=oneshot
  ExecStart=/usr/bin/iptables-restore /etc/iptables/iptables.rules
  ExecReload=/usr/bin/iptables-restore /etc/iptables/iptables.rules
  ExecStop=/usr/lib/systemd/scripts/iptables-flush
  RemainAfterExit=yes

  [Install]
  WantedBy=multi-user.target

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

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

[Dave Reisner]

On Mon, Oct 13, 2014 at 03:47:59AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
 On Sun, Oct 12, 2014 at 06:42:36PM -0700, Dave Reisner wrote:
   src/tmpfiles/tmpfiles.c |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
  
  New commits:
  commit e7aab5412829ed6b50d109f670bd0b1b365838a7
  Author: Dave Reisner dreis...@archlinux.org
  Date:   Sat Oct 11 20:35:06 2014 -0400
  
  tmpfiles: compare return against correct errno
  
  name_to_handle_at returns -EOPNOTSUPP, not -ENOTSUP.
  
  diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
  index dafb9ae..8108b43 100644
  --- a/src/tmpfiles/tmpfiles.c
  +++ b/src/tmpfiles/tmpfiles.c
  @@ -259,7 +259,7 @@ static int dir_is_mount_point(DIR *d, const char 
  *subdir) {
   
   /* got only one handle; assume different mount points if one
* of both queries was not supported by the filesystem */
  -if (r_p == -ENOSYS || r_p == -ENOTSUP || r == -ENOSYS || r == 
  -ENOTSUP)
  +if (r_p == -ENOSYS || r_p == -EOPNOTSUPP || r == -ENOSYS || r == 
  -EOPNOTSUPP)
   return true;
 They are aliases.
 
 Zbyszek

Hrmm, I had no idea. Thanks for pointing that out.

Anyways, this makes error handling consistent with the other
name_to_handle_at() call in src/shared/path-util.c, which is what
prompted me to be look into this...

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

Re: [systemd-devel] [RFC 24/25] units: order options before other arguments

[Dave Reisner]

On Thu, Sep 18, 2014 at 06:10:06PM +0200, Tom Gundersen wrote:
 For kmod and systemctl this is fine (so I'd be happy to take a patch
 to make that change), but for udevadm it feels weird as the
 documentation there says the format should be udevadm trigger. Maybe
 something to fix in the libc (assuming the problem is that it enforces
 an order).

It's not just the documentation. This patch wasn't tested at all:

$ udevadm --type=devices --action=add trigger
udevadm: unrecognized option '--type=devices'

udevadm makes 2 option parsing rounds with the first round stopping as
soon as it encounters a non-option argument. So, the rationale behind
this patch is bogus, as is the change.

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

Re: [systemd-devel] help with systemd socket file for programs in the quagga suite

[Dave Reisner]

On Fri, Sep 12, 2014 at 06:15:32PM +0100, lux-integ wrote:
 Greetings,
 
 I am attempting to learn how to use systemd.  I decided to try synthesising a 
 'socket file'

I'll stop you here. You can't simply synthesize a socket unit for any
arbitrary program that uses a socket (regardless of the address family).
Socket units are specific to socket-activated services (which requires
code changes in the daemon itself) and per-connection spawning.

Based on a perusal of the manpage and source, Zebra appears to be
neither of these. So, you shouldn't be writing a socket unit for this
service.

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

[systemd-devel] [PATCH] firstboot: remove extra paranoia in --root checking

[Dave Reisner]

Some package managers will chroot before running post-install and
post-upgrade scripts. Doing this prevents systemd-firstboot from being
used piecemeal at installation or upgrade time, as the --root=/ will be
cleverly ignored.

There's already enough sanity checks in this tool that we don't also
need add intelligence on top of the --root parameter. If a sys-admin
wants to run this tool with --root=/, I see no reason why we should
actively stop them.
---
Hi.

It's currently far more difficult than it needs to be to perform the seemingly
simple task of creating a *unique* machine ID for new installations. The
systemd-machine-id-setup tool almost accomplishes this, but fails to create
something unique when generating IDs for nspawn containers in VMs[1]. A recent
change[2] tried to address this, but it's still negated by the fact that most
package managers will chroot before running install scriptlets.

systemd-firstboot is too smart for its own good. The tool has a --root
parameter, but this is made useless by the fact that it silently ignores any
root value which is equivalent to /. And, without a --root specified, the
--setup-machine-id feature of firstboot will be a no-op. This makes
systemd-firstboot unsuitable for usage in a post-install script, again, because
of the chroot.

systemd is the only software on most machines which will read and use the
machine ID. It therefore makes sense that systemd is responsible for creating
this. The installation bootstrap scripts shouldn't have to rely on systemd
being installed in the host environment in order to generate this data. This
really is a dead simple task that's entirely feasible to do as part of the
package's post-installation work. But yet... it currently isn't.

philosoraptor
Why does a tool called firstboot have a feature which refuses to run on first
boot?
/philosoraptor

[1] https://bugs.archlinux.org/task/40131
[2] http://cgit.freedesktop.org/systemd/systemd/commit/?id=5dd6d0f8ff1

 src/firstboot/firstboot.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/src/firstboot/firstboot.c b/src/firstboot/firstboot.c
index fd73adb..a17c18a 100644
--- a/src/firstboot/firstboot.c
+++ b/src/firstboot/firstboot.c
@@ -747,11 +747,6 @@ static int parse_argv(int argc, char *argv[]) {
 
 path_kill_slashes(arg_root);
 
-if (path_equal(arg_root, /)) {
-free(arg_root);
-arg_root = NULL;
-}
-
 break;
 
 case ARG_LOCALE:
-- 
2.1.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCHv4 3/3] resume-generator: add a generator for instantiating the resume unit.

[Dave Reisner]

On Tue, Aug 26, 2014 at 04:11:05PM +0400, Ivan Shapovalov wrote:
 resume-generator understands resume= kernel command line parameter and
 instantiates the systemd-resume@.service accordingly if it is passed.
 
 This enables resume from hibernation using device specified on the kernel
 command line, where the device path may point to an arbitrary udev-created
 symlink, not only /dev/sdXY which is understood by the in-kernel
 implementation.
 ---

...

 diff --git a/src/resume-generator/resume-generator.c 
 b/src/resume-generator/resume-generator.c
 new file mode 100644
 index 000..38179ff
 --- /dev/null
 +++ b/src/resume-generator/resume-generator.c
 @@ -0,0 +1,95 @@

...

 +
 +static int parse_proc_cmdline_item(const char *key, const char *value) {
 +if (streq(key, resume)  value) {
 +free(arg_resume_dev);
 +arg_resume_dev = strdup(value);

Shouldn't this be fstab_node_to_udev_node() so that we can support
things like resume=LABEL=myawesomedevice ?

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

Re: [systemd-devel] [ANNOUNCE] systemd 216

[Dave Reisner]

On Wed, Aug 20, 2014 at 01:52:51PM +0200, Lennart Poettering wrote:
 On Tue, 19.08.14 22:25, Dave Reisner (d...@falconindy.com) wrote:
 
  The sysusers.d file shipped with this has:
  
u systemd-journal-remote-   systemd Journal Remote
  
  But the tmpfiles.d fragment has:
  
z /var/log/journal/remote 2755 root systemd-journal-remote - -
z /run/log/journal/remote 2755 root systemd-journal-remote - -
  
  There's no systemd-journal-remote group created...
 
 In sysusers, each system user will always implicitly get a group of the
 same name too.
 

Ok, I see that now. Digging into the logic of how this works, sysusers
will probably never run after an online update. Is the expectation that
distros just run systemd-sysusers in their post_upgrade scripts?

   * A new component systemd-firstboot has been added that
 queries the most basic systemd information (timezone,
 hostname, root password) interactively on first
 boot. Alternatively it may also be used to provision these
 things offline on OS images installed into directories.
  
  This tool offers a --setup-machine-id flag, but it has very different
  semantics from systemd-machine-id-setup. Both will call sd128_randomize,
  but systemd-machine-id-setup will always prefer hardcoded UUIDs passed
  into the host. For example, launching a qemu kvm with the -uuid flag
  will cause the machine-id to mirror this -- though, this alone can be
  problematic[1]
  
  Is this behavior intentional? Does firstboot need to learn the same
  rules? Do we just retire systemd-machine-id-setup?
 
 The behaviour of s-f-b here is intentional. systemd-first-boot's
 --setup-machine-id flag is only available if you use it for
 offline-provisioning of new machine images. But in that case you
 definitely *don't* want any VM/container UUID of the host you do this on
 to leak into the new image.
 
 Note that if you bootup PID 1 and /etc/machine-id is missing it will
 initialize things from the VM/container if there is one, and otherwise
 randomize the ID and write it to disk, hence doing online-provisioning
 in systemd-first-boot is unnecessary (and too late).
 
 The old s-m-i-s tool (which is not too useful anymore, now that s-f-b
 exists), should follow the same behaviour here. I have now changed it to
 ignore the VM/container UUID if it operates on a root directory.

SGTM -- this fixes an older bug:

http://lists.freedesktop.org/archives/systemd-devel/2014-April/018934.html

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

Re: [systemd-devel] [ANNOUNCE] systemd 216

[Dave Reisner]

Hi,

On Wed, Aug 20, 2014 at 02:59:52AM +0200, Lennart Poettering wrote:
 Heya!
 
 This is a major new release. Among many other changes systemd-resolved
 is now a pretty complete caching DNS and LLMNR stub resolver.
 
 http://www.freedesktop.org/software/systemd/systemd-216.tar.xz
 
 CHANGES WITH 216:

 * A new tool systemd-journal-upload has been added to push
   journal data to a remote system running
   systemd-journal-remote.

The sysusers.d file shipped with this has:

  u systemd-journal-remote-   systemd Journal Remote

But the tmpfiles.d fragment has:

  z /var/log/journal/remote 2755 root systemd-journal-remote - -
  z /run/log/journal/remote 2755 root systemd-journal-remote - -

There's no systemd-journal-remote group created...

 * A new component systemd-firstboot has been added that
   queries the most basic systemd information (timezone,
   hostname, root password) interactively on first
   boot. Alternatively it may also be used to provision these
   things offline on OS images installed into directories.

This tool offers a --setup-machine-id flag, but it has very different
semantics from systemd-machine-id-setup. Both will call sd128_randomize,
but systemd-machine-id-setup will always prefer hardcoded UUIDs passed
into the host. For example, launching a qemu kvm with the -uuid flag
will cause the machine-id to mirror this -- though, this alone can be
problematic[1]

Is this behavior intentional? Does firstboot need to learn the same
rules? Do we just retire systemd-machine-id-setup?

Cheers,
d

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

Re: [systemd-devel] [RFC] Integrate export mount command in code

[Dave Reisner]

On Mon, Aug 18, 2014 at 12:25:00AM +0300, Timofey Titovets wrote:
 Good time of day, i just want to ask:
 Systemd depend on util-linux mount command and in code we call him,
 may have a sense to import and cleanup code to systemd base, and just
 call function in systemd, instead of using mount command?
 
 But only benefit what i see:
 it faster, when call external command, but i can miss something

tl;dr: this simply isn't a good idea, as it would require reimplementing
a substantial amount of code to retain feature parity.

systemd already uses mount(2) where it's reasonable: kernel filesystems
like /sys, /dev, and /proc.

Some reasons not to do this for all filesystems:

1) You have to fork, anyways, because you don't want to call mount(2)
from PID 1 -- the syscall may not return for a relatively long period of
time.  During this time, systemd will be entirely non-responsive.
2) Mounting filesystems is sometimes complex, and involves an external
helper, regardless. fuse, cifs, and nfs immediately come to mind, but
there's others. mount(8) knows how to find and execute these when
necessary.
3) mount(8) takes care of cleaning the option string from /etc/fstab --
not all options are meant to be passed to the kernel (or the external
mount helpers), such as any option which starts with x- (like
x-systemd.automount).

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

Re: [systemd-devel] [PATCH] socket: add support for TCP fast Open

[Dave Reisner]

On Thu, Aug 14, 2014 at 02:31:47PM +0530, Susant Sahani wrote:
 TCP Fast Open (TFO) speeds up the opening of successiveTCP)
 connections between two endpoints.It works by using a TFO cookie
 in the initial SYN packet to authenticate a previously connected
 client. It starts sending data to the client before the receipt
 of the final ACK packet of the three way handshake is received,
 skipping a round trip and lowering the latency in the start of
 transmission of data.
 ---

Why does this default to false? The kernel enables this by default as of
3.13 and exposes /proc/sys/net/ipv4/tcp_fastopen. Are there really
cases where one might want this conditionally enabled/disabled?

  man/systemd.socket.xml| 15 +++
  src/core/dbus-socket.c|  1 +
  src/core/load-fragment-gperf.gperf.m4 |  1 +
  src/core/socket.c |  8 
  src/core/socket.h |  1 +
  5 files changed, 26 insertions(+)
 
 diff --git a/man/systemd.socket.xml b/man/systemd.socket.xml
 index 352825f..170d010 100644
 --- a/man/systemd.socket.xml
 +++ b/man/systemd.socket.xml
 @@ -499,6 +499,21 @@
  /varlistentry
  
  varlistentry
 +termvarnameFastOpen=/varname/term
 +listitemparaTakes a boolean
 +argument. It works by using a TFO cookie (a 
 TCP option) in the initial
 +SYN packet to authenticate a previously 
 connected client. If successful,
 +it may start sending data to the client 
 before the receipt of the final
 +ACK packet of the three way handshake is 
 received, skipping a round trip
 +and lowering the latency in the start of 
 transmission of data.
 +This controls the TCP_FASTOPEN socket option 
 (see
 +the ulink 
 url=http://lwn.net/Articles/508865/;TCP
 +Fast Open: expediting web services/ulink 
 for details.)
 +Defaults to
 +optionfalse/option./para/listitem
 +/varlistentry
 +
 +varlistentry
  termvarnamePriority=/varname/term
  listitemparaTakes an integer
  argument controlling the priority for
 diff --git a/src/core/dbus-socket.c b/src/core/dbus-socket.c
 index ad135a1..71c0115 100644
 --- a/src/core/dbus-socket.c
 +++ b/src/core/dbus-socket.c
 @@ -97,6 +97,7 @@ const sd_bus_vtable bus_socket_vtable[] = {
  SD_BUS_PROPERTY(DirectoryMode, u, bus_property_get_mode, 
 offsetof(Socket, directory_mode), SD_BUS_VTABLE_PROPERTY_CONST),
  SD_BUS_PROPERTY(Accept, b, bus_property_get_bool, 
 offsetof(Socket, accept), SD_BUS_VTABLE_PROPERTY_CONST),
  SD_BUS_PROPERTY(KeepAlive, b, bus_property_get_bool, 
 offsetof(Socket, keep_alive), SD_BUS_VTABLE_PROPERTY_CONST),
 +SD_BUS_PROPERTY(FastOpen , b, bus_property_get_bool, 
 offsetof(Socket, fast_open), SD_BUS_VTABLE_PROPERTY_CONST),
  SD_BUS_PROPERTY(Priority, i, bus_property_get_int, 
 offsetof(Socket, priority), SD_BUS_VTABLE_PROPERTY_CONST),
  SD_BUS_PROPERTY(ReceiveBuffer, t, bus_property_get_size, 
 offsetof(Socket, receive_buffer), SD_BUS_VTABLE_PROPERTY_CONST),
  SD_BUS_PROPERTY(SendBuffer, t, bus_property_get_size, 
 offsetof(Socket, send_buffer), SD_BUS_VTABLE_PROPERTY_CONST),
 diff --git a/src/core/load-fragment-gperf.gperf.m4 
 b/src/core/load-fragment-gperf.gperf.m4
 index f4acdda..08d0593 100644
 --- a/src/core/load-fragment-gperf.gperf.m4
 +++ b/src/core/load-fragment-gperf.gperf.m4
 @@ -232,6 +232,7 @@ Socket.Accept,   config_parse_bool,   
0,
  Socket.MaxConnections,   config_parse_unsigned,  0,  
offsetof(Socket, max_connections)
  Socket.KeepAlive,config_parse_bool,  0,  
offsetof(Socket, keep_alive)
  Socket.NoDelay,  config_parse_bool,  0,  
offsetof(Socket, no_delay)
 +Socket.FastOpen, config_parse_bool,  0,  
offsetof(Socket, fast_open)
  Socket.Priority, config_parse_int,   0,  
offsetof(Socket, priority)
  Socket.ReceiveBuffer,config_parse_iec_size,  0,  
offsetof(Socket, receive_buffer)
  Socket.SendBuffer,   config_parse_iec_size,  0,  
offsetof(Socket, send_buffer)
 diff --git a/src/core/socket.c b/src/core/socket.c
 index 5af1596..44827ad 100644
 --- 

Re: [systemd-devel] Missing forked processes in 'systemctl status'

[Dave Reisner]

On Wed, Aug 13, 2014 at 12:56:19PM -0400, Leonid Isaev wrote:
 This still doesn't explain why systemctl misses the cgroup information...

Isn't this the same misfeature that causes other fields like _COMM to be
lost as well? The process goes away before journald can async read that
information from /proc. IIRC, this is supposed to be fixed in the kernel
via SO_PASSPROC[0].

d

[0] http://lwn.net/Articles/600564/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] util: allow strappenda to take any number of args

[Dave Reisner]

This makes strappenda3 redundant, so we remove its usage and definition.
---
Cleaning out some old branches I had laying around, found this...

 src/dbus1-generator/dbus1-generator.c |  2 +-
 src/fstab-generator/fstab-generator.c |  2 +-
 src/getty-generator/getty-generator.c |  2 +-
 src/shared/install.c  |  2 +-
 src/shared/util.h | 36 +--
 src/systemctl/systemctl.c |  2 +-
 src/test/test-util.c  |  7 +++
 7 files changed, 25 insertions(+), 28 deletions(-)

diff --git a/src/dbus1-generator/dbus1-generator.c 
b/src/dbus1-generator/dbus1-generator.c
index dcfceec..e1ffc55 100644
--- a/src/dbus1-generator/dbus1-generator.c
+++ b/src/dbus1-generator/dbus1-generator.c
@@ -169,7 +169,7 @@ static int add_dbus(const char *path, const char *fname, 
const char *type) {
 assert(path);
 assert(fname);
 
-p = strappenda3(path, /, fname);
+p = strappenda(path, /, fname);
 r = config_parse(NULL, p, NULL,
  D-BUS Service\0,
  config_item_table_lookup, table,
diff --git a/src/fstab-generator/fstab-generator.c 
b/src/fstab-generator/fstab-generator.c
index 418e8b1..2c38ab9 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -432,7 +432,7 @@ static int add_root_mount(void) {
 else if (arg_root_rw = 0 ||
  (!mount_test_option(arg_root_options, ro) 
   !mount_test_option(arg_root_options, rw)))
-opts = strappenda3(arg_root_options, ,, arg_root_rw  0 ? 
rw : ro);
+opts = strappenda(arg_root_options, ,, arg_root_rw  0 ? 
rw : ro);
 else
 opts = arg_root_options;
 
diff --git a/src/getty-generator/getty-generator.c 
b/src/getty-generator/getty-generator.c
index c78a511..06ca9b9 100644
--- a/src/getty-generator/getty-generator.c
+++ b/src/getty-generator/getty-generator.c
@@ -42,7 +42,7 @@ static int add_symlink(const char *fservice, const char 
*tservice) {
 assert(tservice);
 
 from = strappenda(SYSTEM_DATA_UNIT_PATH /, fservice);
-to = strappenda3(arg_dest, /getty.target.wants/, tservice);
+to = strappenda(arg_dest, /getty.target.wants/, tservice);
 
 mkdir_parents_label(to, 0755);
 
diff --git a/src/shared/install.c b/src/shared/install.c
index 276ca3e..0fe1371 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -1061,7 +1061,7 @@ static int unit_file_load(
 assert(path);
 
 if (!isempty(root_dir))
-path = strappenda3(root_dir, /, path);
+path = strappenda(root_dir, /, path);
 
 fd = open(path, O_RDONLY|O_CLOEXEC|O_NOCTTY|(allow_symlink ? 0 : 
O_NOFOLLOW));
 if (fd  0)
diff --git a/src/shared/util.h b/src/shared/util.h
index 8231cf2..101d2df 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -845,29 +845,19 @@ int unlink_noerrno(const char *path);
 (void *) memset(_new_, 0, _len_);   \
 })
 
-#define strappenda(a, b)\
-({  \
-const char *_a_ = (a), *_b_ = (b);  \
-char *_c_;  \
-size_t _x_, _y_;\
-_x_ = strlen(_a_);  \
-_y_ = strlen(_b_);  \
-_c_ = alloca(_x_ + _y_ + 1);\
-strcpy(stpcpy(_c_, _a_), _b_);  \
-_c_;\
-})
-
-#define strappenda3(a, b, c)\
-({  \
-const char *_a_ = (a), *_b_ = (b), *_c_ = (c);  \
-char *_d_;  \
-size_t _x_, _y_, _z_;   \
-_x_ = strlen(_a_);  \
-_y_ = strlen(_b_);  \
-_z_ = strlen(_c_);  \
-_d_ = alloca(_x_ + _y_ + _z_ + 1);  \
-strcpy(stpcpy(stpcpy(_d_, _a_), _b_), _c_); \
-_d_;\
+#define strappenda(a, ...)   \
+({   \
+int _len = strlen(a);\
+unsigned _i; \
+char *_d_, *_p_; \
+const char *_appendees_[] = { __VA_ARGS__ }; \
+for (_i = 0; _i  ELEMENTSOF(_appendees_); _i++) \
+_len += strlen(_appendees_[_i]); \
+ 

Re: [systemd-devel] [PATCH] util: allow strappenda to take any number of args

[Dave Reisner]

On Thu, Aug 14, 2014 at 01:28:15AM +0200, Lennart Poettering wrote:
 On Wed, 13.08.14 16:35, Dave Reisner (dreis...@archlinux.org) wrote:
 
 Looks good. The code is certainly not any more complicated than the
 current strapenda3(), so it sounds like something to apply.
 
   /* If the passed init is actually the same as the
* systemd binary, then let's suppress it. */
  diff --git a/src/test/test-util.c b/src/test/test-util.c
  index 16f89b4..8776899 100644
  --- a/src/test/test-util.c
  +++ b/src/test/test-util.c
  @@ -907,6 +907,12 @@ static void test_strshorten(void) {
   assert_se(strlen(strshorten(s, 0)) == 0);
   }
   
  +static void test_strappenda(void) {
  +assert_se(streq(strappenda(, foo, bar), foobar));
  +assert_se(streq(strappenda(foo, bar, baz), foobarbaz));
  +assert_se(streq(strappenda(foo, , bar, baz), foobarbaz));
  +}
 
 it's not portable to avoid alloca() when invoking a function (which the
 strlen() in streq() is). This is documented in the alloca(3) man page,
 see section BUGS.

Ah, thanks!

 Can you change the test to first place the result of strappenda() in a
 variable, and then pass that on to streq()? 
 
 Please commit then! 

Fixed up and pushed, thanks for the quick review!

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

Re: [systemd-devel] documentation and required version

[Dave Reisner]

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

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

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

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

Re: [systemd-devel] [PATCH] tmpfiles: only execute chmod()/chown() when needed

[Dave Reisner]

On Fri, Jul 11, 2014 at 02:26:13PM -0700, Colin Walters wrote:
 
 
 On Fri, Jul 11, 2014, at 06:05 AM, Michael Olbrich wrote:
  This avoids errors like this, when the paths are already there with the
  correct permissions and owner:
  
  chmod(/var/spool) failed: Read-only file system
 
 I'd say we should avoid running systemd-tmpfiles if the filesystem is
 read only.  In your case is / read-write even?  What do you think about
 e.g.:

No way. This precludes tmpfiles from creating directories in /run.

 diff --git a/units/systemd-tmpfiles-setup.service.in
 b/units/systemd-tmpfiles-setup.service.in
 index 72ab083..c5b6416 100644
 --- a/units/systemd-tmpfiles-setup.service.in
 +++ b/units/systemd-tmpfiles-setup.service.in
 @@ -13,6 +13,7 @@ Conflicts=shutdown.target
  After=systemd-readahead-collect.service
  systemd-readahead-replay.service local-fs.target
  systemd-sysusers.service
  Before=sysinit.target shutdown.target
  RefuseManualStop=yes
 +ConditionPathIsReadWrite=/
  
  [Service]
  Type=oneshot
 
 See also
 https://git.gnome.org/browse/ostree/commit/?id=ff6883ca0655ac8844cd783caf6a7d8815515ba3
 
  +if (stat(path, st) = 0) {
 
 I don't think we want to follow symlinks here, right?
 ___
 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] [PATCH] [RFCv7] Optionally save core dumps as plain files

[Dave Reisner]

On Fri, Jun 20, 2014 at 08:02:54PM +0200, Lennart Poettering wrote:
 On Tue, 14.05.13 19:09, Oleksii Shevchuk (alx...@gmail.com) wrote:
 
 Heya!
 
 Sorry for resurrecting this thread from last year. I never found the
 time to merge this, but I finally had a closer look and then sat down
 and tried to isolate out of it what I liked and what I didn't. I
 commited different patches for this though. Sorry for the long
 delay!
 
 So here's what is implemented in git now:
 
 a) There's a configuration file /etc/systemd/coredump.conf with some of
the options you proposed.
 
 b) We will now store coredumps outside of the journal by default, but
you can also place them in the journal only, or at both places.
 
 c) I hooked this thing up with elfutils' libdw, which gives us pretty,
native backtraces in the journal now, without involving gdb or
anything like that. Only a minimal (optional) dependency on libdw to
get them. And the best thing is that elfutils is actually maintained
and can read debuginfo files,  unlike some other options for stuff
like this (like libunwind).
 
 d) I hooked this up with ACLs so that a user can read but not change his
own coredumps stored in /var.

This all sounds great.

 What I didn't take: 
 
 1) the API to specify external programs for compressing or processing
the coredumps. I am really not too fond of doing things with invokign
external programs. THat's always chickening out in my eyes, avoiding
to solve the problems properly. By using elfutils' libdw we get the
backtrace feature nicely integrated now without invoking external
programs, I guess the need for PreprocessJournal= is hence redundant
with that. There's no support for compression though, but I'd be fine
with taking a simple patch for that that directly speaks to the xz
APIs. After all we link against the xz already. Of course this would
need support in both the coredump hook to transparently compress the
coredumps and in coredumpctl on the client side so that coredumpctl
gdb just works without manual decompression.
 
 2) I change the paths to store this in. I drop the coredumps in
/var/lib/systemd/coredump/ now. While the journal logs appear to be
something worth sharing across the network as logs; I am not
convinced that the coredumps would fit that category. 

The fact that this path is hardcoded is kind of lousy. See below...

 Anyway, I hope this makes sense.
 
 With these changes coredumpctl actually is now really useful and just
 works. I have thus dropped the systemd- prefix. We should probably
 start advertising it more.

Are there plans to limit the size of the directory in any way? As is,
the default setup is prone to a simple DoS attack as a non-root user:

  while true; do bash -c 'kill -SEGV $$'; done

Cheers,
Dave

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

[systemd-devel] [PATCH] ease installation on non-running kernels

[Dave Reisner]

This lets KERNELDIR apply to the install target as well so that you can
do something such as the following will Just Work™:

  make KERNELDIR=/lib/modules/3.15.0-foo install
---
 Makefile | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/Makefile b/Makefile
index c593b51..fe4dd58 100644
--- a/Makefile
+++ b/Makefile
@@ -17,7 +17,7 @@ kdbus$(EXT)-y := \
 
 obj-m += kdbus$(EXT).o
 
-KERNELDIR  ?= /lib/modules/$(shell uname -r)/build
+KERNELDIR  ?= /lib/modules/$(shell uname -r)
 PWD:= $(shell pwd)
 
 all: module test
@@ -26,7 +26,7 @@ test::
$(MAKE) -C test KBUILD_MODNAME=kdbus$(EXT)
 
 module:
-   $(MAKE) -C $(KERNELDIR) M=$(PWD)
+   $(MAKE) -C $(KERNELDIR)/build M=$(PWD)
 
 clean:
rm -f *.o *~ core .depend .*.cmd *.ko *.mod.c
@@ -38,15 +38,15 @@ check:
test/test-kdbus
 
 install: module
-   mkdir -p /lib/modules/$(shell uname -r)/kernel/drivers/kdbus$(EXT)/
-   cp -f kdbus$(EXT).ko /lib/modules/$(shell uname 
-r)/kernel/drivers/kdbus$(EXT)/
-   depmod $(shell uname -r)
+   mkdir -p $(KERNELDIR)/kernel/drivers/kdbus$(EXT)/
+   cp -f kdbus$(EXT).ko $(KERNELDIR)/kernel/drivers/kdbus$(EXT)/
+   depmod $(notdir $(patsubst %/, %, $(KERNELDIR)))
 
 uninstall:
-   rm -f /lib/modules/$(shell uname -r)/kernel/drivers/kdbus/kdbus$(EXT).ko
+   rm -f $(KERNELDIR)/kernel/drivers/kdbus/kdbus$(EXT).ko
 
 coccicheck:
-   $(MAKE) -C $(KERNELDIR) M=$(PWD) coccicheck
+   $(MAKE) -C $(KERNELDIR)/build M=$(PWD) coccicheck
 
 tt: all
sudo sh -c 'dmesg -c  /dev/null'
-- 
2.0.0

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

Re: [systemd-devel] [PATCH] ease installation on non-running kernels

[Dave Reisner]

On Tue, Jun 17, 2014 at 12:28:27PM -0700, Greg KH wrote:
 On Tue, Jun 17, 2014 at 02:52:43PM -0400, Dave Reisner wrote:
  This lets KERNELDIR apply to the install target as well so that you can
  do something such as the following will Just Work™:
  
make KERNELDIR=/lib/modules/3.15.0-foo install
  ---
   Makefile | 14 +++---
   1 file changed, 7 insertions(+), 7 deletions(-)
  
  diff --git a/Makefile b/Makefile
  index c593b51..fe4dd58 100644
  --- a/Makefile
  +++ b/Makefile
  @@ -17,7 +17,7 @@ kdbus$(EXT)-y := \
   
   obj-m += kdbus$(EXT).o
   
  -KERNELDIR  ?= /lib/modules/$(shell uname -r)/build
  +KERNELDIR  ?= /lib/modules/$(shell uname -r)
   PWD:= $(shell pwd)
   
   all: module test
  @@ -26,7 +26,7 @@ test::
  $(MAKE) -C test KBUILD_MODNAME=kdbus$(EXT)
   
   module:
  -   $(MAKE) -C $(KERNELDIR) M=$(PWD)
  +   $(MAKE) -C $(KERNELDIR)/build M=$(PWD)
 
 Nope, you just broke the build on my machine when I wanted to build
 against the kernel source tree in /home/gregkh/linux/ that does not have
 a build/ subdirectory in it.

Fair enough. I figured this would be the response I get [0].

 What is wrong with putting the build/ trailing subdir in your build
 command line?  What is currently broken today with the build system?

As the commit message implies, make install doesn't work for non-running
kernels -- it will always install to the current kernel. So, after a
kernel upgrade, I have to make the subdirectories myself, copy over the
module, and run depmod before I can build an initramfs for the new
kernel (and subsequently reboot).

 And long-term, this will not be an issue at all as the code will be
 merged into the kernel tree.

Sure, but unless I'm missing something, the status quo makes things a
bit tedious for rebuilds. Most other out of tree modules I've come in
contact with make this a trivial operation.

Cheers,
Dave

[0] http://xkcd.com/1172/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] ease installation on non-running kernels

[Dave Reisner]

On Tue, Jun 17, 2014 at 10:43:39PM +0200, Simon Peeters wrote:
 2014-06-17 22:16 GMT+02:00 Greg KH g...@kroah.com:
  On Tue, Jun 17, 2014 at 03:53:15PM -0400, Dave Reisner wrote:
  On Tue, Jun 17, 2014 at 12:28:27PM -0700, Greg KH wrote:
   On Tue, Jun 17, 2014 at 02:52:43PM -0400, Dave Reisner wrote:
This lets KERNELDIR apply to the install target as well so that you can
do something such as the following will Just Work™:
   
  make KERNELDIR=/lib/modules/3.15.0-foo install
---
 Makefile | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)
   
diff --git a/Makefile b/Makefile
index c593b51..fe4dd58 100644
--- a/Makefile
+++ b/Makefile
@@ -17,7 +17,7 @@ kdbus$(EXT)-y := \
   
 obj-m += kdbus$(EXT).o
   
-KERNELDIR?= /lib/modules/$(shell uname -r)/build
+KERNELDIR?= /lib/modules/$(shell uname -r)
 PWD  := $(shell pwd)
   
 all: module test
@@ -26,7 +26,7 @@ test::
  $(MAKE) -C test KBUILD_MODNAME=kdbus$(EXT)
   
 module:
- $(MAKE) -C $(KERNELDIR) M=$(PWD)
+ $(MAKE) -C $(KERNELDIR)/build M=$(PWD)
  
   Nope, you just broke the build on my machine when I wanted to build
   against the kernel source tree in /home/gregkh/linux/ that does not have
   a build/ subdirectory in it.
 
  Fair enough. I figured this would be the response I get [0].
 
  Um, that should be the workflow of _any_ kernel developer, we all build
  against local kernel directories, not one that is installed in /lib/.
  Some of us don't ever boot kernels installed in /lib :)
 
 
 Hej all,
 
 I have (locally) a patch that acomplishesh almost the same, but in a
 way that does not break gregs setup.
 
 What I did was:
  - Add a KERNELVER variable defaulting to $(shell uname -r)
  - replace all occurences of $(shell uname -r) with $(KERNELVER)
 
 maybe this is a viable solution?

I just wrote the same patch, except I used KVER instead of KERNELVER to
make it more visually distinct from KERNELDIR.

 It allows people to use the default paths (/lib/modules/*/build) but
 for a different kernel version, while still allowing users to set
 KERNELDIR to whatever they want.

There's an opportunity to do weird things if you were to set KERNELDIR
instead of KVER for the install target. I don't think this is anything
to worry about, though.

 I hope this is usefull

Works for me...

 
 
 Simon Peeters
 
 PS: if you want me to sent this as a decent patch, let me know and I
 do it once I am on my dev machine.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] arch linux container filesystems

[Dave Reisner]

On Mon, Jun 16, 2014 at 01:01:31PM +0100, Robin Becker wrote:
 I asked about this at the arch linux forum, but got no response.
 
 I run an up to date arch linux X64 system with systemd-213-9. I built a
 simple container using the wiki article
https://wiki.archlinux.org/index.php/Systemd-nspawn
 
 after systemd-nspawn -bD ~/MyContainer and root login I see this in my df 
 output
 
 root@MyContainer ~]# df
 df: '/run/user/1000': No such file or directory
 df: '/run/user/1000/gvfs': No such file or directory
 df: '/proc/kmsg (deleted)': No such file or directory
 df: '/proc/sys/kernel/random/boot_id (deleted)': No such file or directory
 Filesystem 1K-blocks Used Available Use% Mounted on
 /dev/sda1  147418744 85779872  54127364  62% /
 dev  14139004   1413896   1% /dev
 tmpfs14139000   1413900   0% /dev/shm
 tmpfs14139000   1413900   0% /sys/fs/cgroup
 run  1413900   44   1413856   1% /run
 tmpfs14139000   1413900   0% /tmp
 tmpfs14139004   1413896   1% /dev
 tmpfs14139000   1413900   0% /dev/shm
 tmpfs1413900   44   1413856   1% /run
 tmpfs14139000   1413900   0% /sys/fs/cgroup
 tmpfs14139000   1413900   0% /tmp
 tmpfs 2827840282784   0% /run/user/0
 [root@MyContainer ~]#
 
 
 Is this what is expected? Not sure why my user id (1000) is being used.
 
 I can imagine containers might not have /proc/kmsg 
 /proc/sys/kernel/random/boot_id; is that an error in df?
 
 Why do I have all the file system duplicates?

You don't -- df doesn't understand namespaces. You should use a tool
which reads from /proc/self/mountinfo instead of /etc/mtab, e.g.
findmnt. If you want df-like output from findmnt, use 'findmnt -vD'.

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

Re: [systemd-devel] systemd-network-wait-online symlinks to systemd-networkd

[Dave Reisner]

On Tue, Jun 10, 2014 at 06:26:47PM +0200, Lennart Poettering wrote:
 On Sun, 08.06.14 09:37, Dave Reisner (d...@falconindy.com) wrote:
 
  On a related topic, could we please stop shipping hardcoded symlinks in
  /etc in favor of documented reccomendations for downstream packagers?
 
 Hmm, well. The way automake currently works is that all config files are
 overwritten on make install. WHich is probably the right thing to do I
 think. People who use make install without DESTDIR= should be prepared
 to get their configured reset in one way or another...

I guess I've been under the assumption that this was more of a you're
on your own situation -- that the build sys was tailored towards the
folks who are going to be doing the packaging for downstream. It sounds
like this isn't really the case; that's fine with me.

Perhaps there's a middle ground we can find. Tom mentioned the idea of
a package mode during configuration. How about a simpler idea -- if
DESTDIR is empty, add the symlinks. Otherwise, don't.

 Creating a couple of symlinks in /etc, and dropping a number of
 configuration files in, doesn't appear to be so much of a difference to
 me. Can you explain to me why we should depart from automake's
 traditional behaviour here, and wh symlinks should be something
 different from configuration files?

Traditional configuration files have their own content. They can be
hashed and tracked by your package manager. On upgrade, you can make an
intelligent decision about what to do with the new file (replace,
ignore, merge) based on the original and current hash of the existing
file, and the has of the incoming file.

Symlinks are more of a binary decision -- either they exist, or they
don't. But, they're still configuration in this context. There's no way
to track this on/off bit, so distros (well, speaking of Arch) simply
nuke the symlinks and add back what they see as sane defaults during
installation (explicitly leaving the symlinks untracked).

 I mean, ideally we'd just invoke systemctl preset for these things,
 but for the sake of cross-compilation we can avoid this easily. 

 We probably should ship make sure to ship the very same symlinks we
 create with make install with a preset file though...

Yeah, this sounds prone to drift unless it could be generated from some
master list.

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

Re: [systemd-devel] systemd-network-wait-online symlinks to systemd-networkd

[Dave Reisner]

On Tue, Jun 10, 2014 at 07:32:56PM +0200, Lennart Poettering wrote:
 Symlinks should probably just be considered different type of file, that
 have a contents and stuff. The contents is usually a file name, and
 there's a size limit, but other than that it's just a magic kind of
 file, where the symlink destination is the conents. That's how git
 handles this, for example.
 
 I have the suspicion that this is really something to fix in your
 package manager. It should learn to handle symlink upgrades the same way
 as configuration file upgrades

Does rpm handle this exact case? Can anyone comment on dpkg handling of
this case?

   I mean, ideally we'd just invoke systemctl preset for these things,
   but for the sake of cross-compilation we can avoid this easily. 
  
   We probably should ship make sure to ship the very same symlinks we
   create with make install with a preset file though...
  
  Yeah, this sounds prone to drift unless it could be generated from some
  master list.
 
 Well, given that it's not a hundred symlinks, but just a few, I think
 having a list in the preset files and one in the makefile isn't too
 error-prone...

But it still involves humans.

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

Re: [systemd-devel] systemd-network-wait-online symlinks to systemd-networkd

[Dave Reisner]

On Mon, Jun 09, 2014 at 10:12:35AM +0200, Tom Gundersen wrote:
 Hi Dave,
 
 On Sun, Jun 8, 2014 at 3:37 PM, Dave Reisner d...@falconindy.com wrote:
  Commit 2dcf7ec6ec added the following to Makefile.am:
 
  +GENERAL_ALIASES += \
  +   $(systemunitdir)/systemd-networkd.service 
  $(pkgsysconfdir)/system/multi-user.target.wants/systemd-networkd.service \
  +   $(systemunitdir)/systemd-networkd.service 
  $(pkgsysconfdir)/system/network-online.target.wants/systemd-networkd-wait-online.service
 
  Which, of course, results in systemd-networkd-wait-online being a
  symlink to systemd-networkd.  This doesn't seem correct at all.
  Shouldn't it link to systemd-networkd-wait-online.service?
 
 Indeed, that's a copy-paste error. Feel free to fix up, or I'll do it
 when I get home tonight.
 

Thanks for confirming -- pushed.

  On a related topic, could we please stop shipping hardcoded symlinks in
  /etc in favor of documented reccomendations for downstream packagers?
 
 I believe the aim here is to make ./autogen.sh c  make  sudo make
 install give the recommended installation. I suppose one
 alternative would be to ship some preset instead (and hook into that
 from make install) which should be simpler to drop from the package?

Well, hooking into 'make install' doesn't really change the end result
if there's no way to disable the hook. I strongly believe that the
overbearing majority of systemd users are installing systemd from their
distro's package manager, and not 'make install'. Since writes to /etc
in this case are likely discouraged (as they override the site admin),
it'd be really nice to separate out these additions somehow.

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

[systemd-devel] systemd-network-wait-online symlinks to systemd-networkd

[Dave Reisner]

Hi,

Commit 2dcf7ec6ec added the following to Makefile.am:

+GENERAL_ALIASES += \
+   $(systemunitdir)/systemd-networkd.service 
$(pkgsysconfdir)/system/multi-user.target.wants/systemd-networkd.service \
+   $(systemunitdir)/systemd-networkd.service 
$(pkgsysconfdir)/system/network-online.target.wants/systemd-networkd-wait-online.service

Which, of course, results in systemd-networkd-wait-online being a
symlink to systemd-networkd.  This doesn't seem correct at all.
Shouldn't it link to systemd-networkd-wait-online.service?

On a related topic, could we please stop shipping hardcoded symlinks in
/etc in favor of documented reccomendations for downstream packagers?

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

[systemd-devel] [PATCH] Set mac address in link initialization

[Dave Reisner]

505f8da7325 left link-mac uninitialized, causing MACAddress based
[Match] sections to fail to match anything.

https://bugs.freedesktop.org/show_bug.cgi?id=79638
---
 src/network/networkd-link.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
index 6e6fb83..f3bab9f 100644
--- a/src/network/networkd-link.c
+++ b/src/network/networkd-link.c
@@ -1683,8 +1683,18 @@ int link_initialized(Link *link, struct udev_device 
*device) {
 if (link-state != LINK_STATE_INITIALIZING)
 return 0;
 
-if (device)
+if (device) {
+const char *mac_address = udev_device_get_sysattr_value(
+device, address);
+
+if (mac_address) {
+struct ether_addr *hwaddr = ether_aton(mac_address);
+if (hwaddr)
+memcpy(link-mac, hwaddr, sizeof(struct 
ether_addr));
+}
+
 link-udev_device = udev_device_ref(device);
+}
 
 log_debug_link(link, udev initialized link);
 
-- 
2.0.0

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

Re: [systemd-devel] [PATCH] Set mac address in link initialization

[Dave Reisner]

On Wed, Jun 04, 2014 at 08:22:11PM +0200, Lennart Poettering wrote:
 On Wed, 04.06.14 13:48, Dave Reisner (dreis...@archlinux.org) wrote:
 
  505f8da7325 left link-mac uninitialized, causing MACAddress based
  [Match] sections to fail to match anything.
  
  https://bugs.freedesktop.org/show_bug.cgi?id=79638
  ---
   src/network/networkd-link.c | 12 +++-
   1 file changed, 11 insertions(+), 1 deletion(-)
  
  diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
  index 6e6fb83..f3bab9f 100644
  --- a/src/network/networkd-link.c
  +++ b/src/network/networkd-link.c
  @@ -1683,8 +1683,18 @@ int link_initialized(Link *link, struct udev_device 
  *device) {
   if (link-state != LINK_STATE_INITIALIZING)
   return 0;
   
  -if (device)
  +if (device) {
  +const char *mac_address = udev_device_get_sysattr_value(
  +device, address);
 
 Please avoid declaring a variable and invoking a function within the
 same expression.
 
 It's fine to initialize a variable while declaring it, but please only
 whith a constant value or macro or something, but don't mix variable
 declarations with function invocations so much. It doesn't help
 readability...
 

Sure, done.

  +
  +if (mac_address) {
  +struct ether_addr *hwaddr = 
  ether_aton(mac_address);

Fixed this, too.

  +if (hwaddr)
  +memcpy(link-mac, hwaddr, sizeof(struct 
  ether_addr));
  +}
  +
   link-udev_device = udev_device_ref(device);
  +}
   
   log_debug_link(link, udev initialized link);
   
 
 
 Lennart
 
 -- 
 Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Set mac address in link initialization

[Dave Reisner]

On Wed, Jun 04, 2014 at 09:33:12PM +0200, Tom Gundersen wrote:
 On Wed, Jun 4, 2014 at 7:48 PM, Dave Reisner dreis...@archlinux.org wrote:
  505f8da7325 left link-mac uninitialized, causing MACAddress based
  [Match] sections to fail to match anything.
 
  https://bugs.freedesktop.org/show_bug.cgi?id=79638
 
 Thanks for the report and the patch.
 
 I'd much prefer if we got these potentially dynamic properties only
 from one source though (i.e., from rtnl), as we are not guaranteed any
 ordering between udev and rtnl events. In this particular case it
 seems like there can not be a problem, but I'd rather be consistent.

Fair enough.

 I pushed an alternative fix. Could you have a look to see if it looks ok to 
 you?
 

Works for me. Thanks!

  ---
   src/network/networkd-link.c | 12 +++-
   1 file changed, 11 insertions(+), 1 deletion(-)
 
  diff --git a/src/network/networkd-link.c b/src/network/networkd-link.c
  index 6e6fb83..f3bab9f 100644
  --- a/src/network/networkd-link.c
  +++ b/src/network/networkd-link.c
  @@ -1683,8 +1683,18 @@ int link_initialized(Link *link, struct udev_device 
  *device) {
   if (link-state != LINK_STATE_INITIALIZING)
   return 0;
 
  -if (device)
  +if (device) {
  +const char *mac_address = udev_device_get_sysattr_value(
  +device, address);
  +
  +if (mac_address) {
  +struct ether_addr *hwaddr = 
  ether_aton(mac_address);
  +if (hwaddr)
  +memcpy(link-mac, hwaddr, sizeof(struct 
  ether_addr));
  +}
  +
   link-udev_device = udev_device_ref(device);
  +}
 
   log_debug_link(link, udev initialized link);
 
  --
  2.0.0
 
  ___
  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] [PATCH] build: Honour SUID_CFLAGS and SUID_LDFLAGS

[Dave Reisner]

On Sat, May 17, 2014 at 12:39:47PM -0400, Cristian Rodríguez wrote:
 This is the standard* way used to pass special linker/compiler
 flags such as -fPIE and -pie
 
 * Standard in the sense it is understood by many other
 packages  and commonly used by distributions.

This doesn't really make sense to me. I infer from the names of the
variables that these are flags passed to the compiler for binaries which
will eventually be setuid root. Why then, are you adding them to the
global flags, particularly when systemd doesn't even build any SUID
binaries? If you want to compile everything with -fPIE and -pie, why not
just append these to your flags locally in the build script?

 ---
  configure.ac | 7 +--
  1 file changed, 5 insertions(+), 2 deletions(-)
 
 diff --git a/configure.ac b/configure.ac
 index 30ef33d..c798674 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -48,6 +48,9 @@ LT_INIT([disable-static])
  AS_IF([test x$enable_static = xyes], [AC_MSG_ERROR([--enable-static is 
 not supported by systemd])])
  AS_IF([test x$enable_largefile = xno], 
 [AC_MSG_ERROR([--disable-largefile is not supported by systemd])])
  
 +AC_ARG_VAR([SUID_CFLAGS], [CFLAGS used for binaries which are usually with 
 the suid bit])
 +AC_ARG_VAR([SUID_LDFLAGS], [LDFLAGS used for binaries which are usually with 
 the suid bit])
 +
  # i18n stuff for the PolicyKit policy files
  IT_PROG_INTLTOOL([0.40.0])
  
 @@ -181,7 +184,7 @@ AS_CASE([$CFLAGS], [*-O[[12345\ ]]*],
  [CC_CHECK_FLAGS_APPEND([with_cflags], [CFLAGS], [\
 -flto])],
  [AC_MSG_RESULT([skipping -flto, optimization not enabled])])
 -AC_SUBST([OUR_CFLAGS], $with_cflags $sanitizer_cflags)
 +AC_SUBST([OUR_CFLAGS], $SUID_CFLAGS $with_cflags $sanitizer_cflags)
  
  AS_CASE([$CFLAGS], [*-O[[12345\ ]]*],
  [CC_CHECK_FLAGS_APPEND([with_cppflags], [CPPFLAGS], [\
 @@ -196,7 +199,7 @@ CC_CHECK_FLAGS_APPEND([with_ldflags], [LDFLAGS], [\
  -Wl,-z,relro \
  -Wl,-z,now \
  -Wl,-fuse-ld=gold])
 -AC_SUBST([OUR_LDFLAGS], $with_ldflags $sanitizer_ldflags)
 +AC_SUBST([OUR_LDFLAGS], $SUID_LDFLAGS $with_ldflags $sanitizer_ldflags)
  
  AC_CHECK_SIZEOF(pid_t)
  AC_CHECK_SIZEOF(uid_t)
 -- 
 1.8.4.5
 
 ___
 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] [PATCH] timer: allow user to control activation time of cron-like timers

[Dave Reisner]

On Sun, May 11, 2014 at 07:53:55PM +0400, Alexander Bashmakov wrote:
 Issue was rised in this thread:
 https://mailman.archlinux.org/pipermail/arch-general/2014-May/036162.html
 
 Disclaimer:
 I almost have no expereince in C.
 So this patch can contain some silly mistakes. But it 'works for me'.
 Please consider it as RFC.
 
 -8---
 Cron-like timers are useful for maintenance tasks
 and already used in some distros by default.
 But midnight is not best time for this.
 Just add a new option allowing user to specify
 activation time (and date) for such timers globally.

daily is just syntactic sugar for *-*-* 00:00:00. If you don't want
to run at midnight, modify the normalized form to run at the time you
want.

 Signed-off-by: Alexander Bashmakov pkunk...@gmail.com
 ---
  man/systemd-system.conf.xml  | 19 +
  man/systemd.time.xml |  6 -
  src/core/load-fragment.c |  2 +-
  src/core/main.c  |  7 +
  src/core/manager.c   | 42 +
  src/core/manager.h   |  4 +++
  src/core/system.conf |  1 +
  src/core/user.conf   |  1 +
  src/shared/calendarspec.c| 64 
 +++-
  src/shared/calendarspec.h|  4 ++-
  src/test/test-calendarspec.c | 20 +-
  11 files changed, 141 insertions(+), 29 deletions(-)
 
 diff --git a/man/systemd-system.conf.xml b/man/systemd-system.conf.xml
 index 3814bd2..e38e70a 100644
 --- a/man/systemd-system.conf.xml
 +++ b/man/systemd-system.conf.xml
 @@ -302,6 +302,25 @@
  /varlistentry
  
  varlistentry
 +
 termvarnameDefaultTimerEventTime=/varname/term
 +
 +listitemparaSets the default
 +elapsing time for cron-like timer units.
 +This controls
 +the global default for
 +timer units with
 +varnameOnCalendar=/varname
 +set on
 +literalhourly/literal, 
 literaldaily/literal,
 +literalmonthly/literal, 
 literalyearly/literal
 +or literalweekly/literal.
 +Only relevant fields are used.
 +See
 +
 citerefentryrefentrytitlesystemd.time/refentrytitlemanvolnum5/manvolnum/citerefentry
 +for details./para/listitem
 +/varlistentry
 +
 +varlistentry
  
 termvarnameDefaultCPUQuotaPeriodSec=/varname/term
  
  listitemparaSets the default CPU
 diff --git a/man/systemd.time.xml b/man/systemd.time.xml
 index 0706cdf..776b6bf 100644
 --- a/man/systemd.time.xml
 +++ b/man/systemd.time.xml
 @@ -248,7 +248,11 @@
  literal*-*-* *:00:00/literal, literal*-*-*
  00:00:00/literal, literal*-*-01 00:00:00/literal and
  literalMon *-*-* 00:00:00/literal,
 -respectively./para
 +respectively.
 +Note that exact time for these expressions depends on
 +varnameDefaultTimerEventTime=/varname
 +setting.
 +/para
  
  paraExamples for valid timestamps and their
  normalized form:/para
 diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c
 index 14c194b..7f9d71f 100644
 --- a/src/core/load-fragment.c
 +++ b/src/core/load-fragment.c
 @@ -1273,7 +1273,7 @@ int config_parse_timer(const char *unit,
  }
  
  if (b == TIMER_CALENDAR) {
 -if (calendar_spec_from_string(rvalue, c)  0) {
 +if (calendar_spec_from_string(rvalue, c, 
 t-meta.manager-default_timer_event_time)  0) {
  log_syntax(unit, LOG_ERR, filename, line, EINVAL,
 Failed to parse calendar specification, 
 ignoring: %s,
 rvalue);
 diff --git a/src/core/main.c b/src/core/main.c
 index c1b0ffd..78c9711 100644
 --- a/src/core/main.c
 +++ b/src/core/main.c
 @@ -109,6 +109,7 @@ static struct rlimit *arg_default_rlimit[_RLIMIT_MAX] = 
 {};
  static uint64_t arg_capability_bounding_set_drop = 0;
  static nsec_t arg_timer_slack_nsec = (nsec_t) -1;
  static usec_t arg_default_timer_accuracy_usec = 1 * USEC_PER_MINUTE;
 +static char* arg_default_timer_event_time = NULL;
  static usec_t arg_default_cpu_quota_period_usec = 100 * USEC_PER_MSEC;
  static Set* arg_syscall_archs = NULL;
  static FILE* arg_serialization = NULL;
 @@ -684,6 +685,7 @@ static int parse_config_file(void) {
  #endif
  { Manager, TimerSlackNSec,config_parse_nsec, 
 0, 

[systemd-devel] [PATCH 2/2] implement a union to pad out file_handle

[Dave Reisner]

Cases where name_to_handle_at is used allocated the full struct to be
MAX_HANDLE_SZ, and assigned this size to handle_bytes. This is wrong
since handle_bytes should describe the length of the flexible array
member and not the whole struct.

Define a union type which includes sufficient padding to allow
assignment of MAX_HANDLE_SZ to be correct.
---
 src/libudev/libudev-monitor.c|  6 ++
 src/readahead/readahead-common.c |  6 ++
 src/shared/util.h|  6 ++
 src/tmpfiles/tmpfiles.c  | 11 ---
 4 files changed, 14 insertions(+), 15 deletions(-)

diff --git a/src/libudev/libudev-monitor.c b/src/libudev/libudev-monitor.c
index 3f7436b..0a2ab82 100644
--- a/src/libudev/libudev-monitor.c
+++ b/src/libudev/libudev-monitor.c
@@ -108,15 +108,13 @@ static struct udev_monitor *udev_monitor_new(struct udev 
*udev)
 
 /* we consider udev running when /dev is on devtmpfs */
 static bool udev_has_devtmpfs(struct udev *udev) {
-struct file_handle *h;
+union file_handle_union h = { .handle.handle_bytes = MAX_HANDLE_SZ, };
 int mount_id;
 _cleanup_fclose_ FILE *f = NULL;
 char line[LINE_MAX], *e;
 int r;
 
-h = alloca(MAX_HANDLE_SZ);
-h-handle_bytes = MAX_HANDLE_SZ;
-r = name_to_handle_at(AT_FDCWD, /dev, h, mount_id, 0);
+r = name_to_handle_at(AT_FDCWD, /dev, h.handle, mount_id, 0);
 if (r  0)
 return false;
 
diff --git a/src/readahead/readahead-common.c b/src/readahead/readahead-common.c
index 5ffa88b..49679fc 100644
--- a/src/readahead/readahead-common.c
+++ b/src/readahead/readahead-common.c
@@ -75,7 +75,7 @@ int fs_on_ssd(const char *p) {
 if (major(st.st_dev) == 0) {
 _cleanup_fclose_ FILE *f = NULL;
 int mount_id;
-struct file_handle *h;
+union file_handle_union h = { .handle.handle_bytes = 
MAX_HANDLE_SZ, };
 
 /* Might be btrfs, which exposes ssd as mount flag if it is 
on ssd.
  *
@@ -83,9 +83,7 @@ int fs_on_ssd(const char *p) {
  * and then lookup the mount ID in mountinfo to find
  * the mount options. */
 
-h = alloca(MAX_HANDLE_SZ);
-h-handle_bytes = MAX_HANDLE_SZ;
-r = name_to_handle_at(AT_FDCWD, p, h, mount_id, 
AT_SYMLINK_FOLLOW);
+r = name_to_handle_at(AT_FDCWD, p, h.handle, mount_id, 
AT_SYMLINK_FOLLOW);
 if (r  0)
 return false;
 
diff --git a/src/shared/util.h b/src/shared/util.h
index 900f1cf..891848a 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -22,6 +22,7 @@
 ***/
 
 #include alloca.h
+#include fcntl.h
 #include inttypes.h
 #include time.h
 #include sys/time.h
@@ -914,3 +915,8 @@ uint64_t physical_memory(void);
 char* mount_test_option(const char *haystack, const char *needle);
 
 void hexdump(FILE *f, const void *p, size_t s);
+
+union file_handle_union {
+  struct file_handle handle;
+  char padding[sizeof(struct file_handle) + MAX_HANDLE_SZ];
+};
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 33e7cbc..04b472d 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -217,19 +217,16 @@ static bool unix_socket_alive(const char *fn) {
 }
 
 static int dir_is_mount_point(DIR *d, const char *subdir) {
-struct file_handle *h;
+union file_handle_union h = { .handle.handle_bytes = MAX_HANDLE_SZ };
 int mount_id_parent, mount_id;
 int r_p, r;
 
-h = alloca(MAX_HANDLE_SZ);
-
-h-handle_bytes = MAX_HANDLE_SZ;
-r_p = name_to_handle_at(dirfd(d), ., h, mount_id_parent, 0);
+r_p = name_to_handle_at(dirfd(d), ., h.handle, mount_id_parent, 0);
 if (r_p  0)
 r_p = -errno;
 
-h-handle_bytes = MAX_HANDLE_SZ;
-r = name_to_handle_at(dirfd(d), subdir, h, mount_id, 0);
+h.handle.handle_bytes = MAX_HANDLE_SZ;
+r = name_to_handle_at(dirfd(d), subdir, h.handle, mount_id, 0);
 if (r  0)
 r = -errno;
 
-- 
1.9.2

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

Re: [systemd-devel] systemd-networkd: setting the MAC address for a .netdev unit?

[Dave Reisner]

On Thu, Apr 17, 2014 at 11:02:11PM +0200, Matthias Schiffer wrote:
 Hi,
 I'd like to configure the MAC address of a bridge device statically (as
 bridges tend to change their MAC address depending on the order the
 ports are added on Linux otherwise), but there doesn't seem to be a way
 to match for a bridge in a .link unit. This would be very useful for
 macvlans as well.

Link files can match bridges generally with Type=bridge or Driver=bridge
in the [Match] section, or more specifically by just matching on name.
In the [Link] section, MACAddressPolicy=persistent should give you
persistent hw addresses in the general case, or you can use
MACAddress=fe:ed:fa:ce:be:ef to set whatever you like for more specific
matches.

Does this not work for you?

 Am I missing something? If not, it would be great if such a feature
 could be added, either by providing a way to match for such netdevs in a
 .link unit, or just by allowing a [Link] section in the .netdev unit
 (which would be more concise in my opinion).
 
 Thanks,
 Matthias
 



 ___
 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] [PATCH] use systemd.debug on the kernel command line, not debug

[Dave Reisner]

On Wed, Apr 02, 2014 at 03:27:52PM -0700, Greg KH wrote:
 If the kernel is started with debug, that's for the kernel to switch
 into debug mode.  We should rely on a namespace for our options, like
 everything else (with the exception of quiet).  Some people want to
 only debug the kernel, not systemd, and the opposite as well so make
 everyone happy.
 
 
 diff --git a/src/core/main.c b/src/core/main.c
 index 41605ee8d5cd..291b18519388 100644
 --- a/src/core/main.c
 +++ b/src/core/main.c
 @@ -416,7 +416,7 @@ static int parse_proc_cmdline_item(const char *key, const 
 char *value) {
  if (arg_show_status == _SHOW_STATUS_UNSET)
  arg_show_status = SHOW_STATUS_AUTO;
  
 -} else if (streq(key, debug)  !value) {
 +} else if (streq(key, systemd.debug)  !value) {

I think kernel-command-line(7) will need an update to go with this.

  
  /* Log to kmsg, the journal socket will fill up before the
   * journal is started and tools running during that time
 ___
 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] [212] systemd-networkd crashes with simple network config

[Dave Reisner]

On Sun, Mar 30, 2014 at 04:47:22PM +0200, Kai Krakow wrote:
 Hello list!
 
 I've tried switching from NetworkManager to systemd-networkd on Gentoo. 
 These were the steps I did:
 
 # systemctl enable systemd-networkd.service
 # cat /etc/systemd/network/80-dhcp.network
 [Match]
 Name=en*
 
 [Network]
 DHCP=yes

Works for me...

 # cat /etc/systemd/network/wired.network
 [Match]
 Name=en*

 [Network]
 DHCP=yes

 # /usr/lib/systemd/systemd-networkd
 ens3: link is up
 ens3: carrier on
 ens3: DHCPv4 address 10.0.2.144/24 via 10.0.2.1
 ens3: link configured

 After starting systemd-networkd.service, it crashes with the following 
 backtrace:

This backtrace isn't useful at all. You need to include debug symbols.

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

Re: [systemd-devel] [PATCH] sd-rtnl: fix off-by-one

[Dave Reisner]

On Sun, Mar 30, 2014 at 05:34:54PM -0700, Steven Siloti wrote:
 ---
  src/libsystemd/sd-rtnl/rtnl-message.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/src/libsystemd/sd-rtnl/rtnl-message.c 
 b/src/libsystemd/sd-rtnl/rtnl-message.c
 index 5265184..a31f6ba 100644
 --- a/src/libsystemd/sd-rtnl/rtnl-message.c
 +++ b/src/libsystemd/sd-rtnl/rtnl-message.c
 @@ -911,11 +911,11 @@ int rtnl_message_parse(sd_rtnl_message *m,
  unsigned short type;
  size_t *tb;
  
 -tb = (size_t *) new0(size_t *, max);
 +tb = (size_t *) new0(size_t *, max + 1);

Not your code, but this should be size_t, not size_t*. The need for the
cast should have been an indicator for whomever added this that it
wasn't right.

  if(!tb)
  return -ENOMEM;
  
 -*rta_tb_size = max;
 +*rta_tb_size = max + 1;
  
  for (; RTA_OK(rta, rt_len); rta = RTA_NEXT(rta, rt_len)) {
  type = rta-rta_type;
 -- 
 1.9.1
 
 ___
 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] [PATCH] Fix permissions on new journal files

[Dave Reisner]

On Tue, Mar 25, 2014 at 04:54:34PM +0100, Thomas Bächler wrote:
 Am 25.03.2014 01:40, schrieb Lennart Poettering:
  This is just a kludge... Why is system.journal to be treated differently?
  It seems that the proper fix is to set the mode on the directory properly
  during installation.
  
  Precisely, packaging script are expected to properly chown and setfacl
  the directory on install. From the .spec file in Fedora:
 
 This completely ignores the problem Dave mentions in his earlier post:
 Volatile journals are owned by root:root.

I talked to Lennart about this last night on IRC -- we agreed that the
solution here is to introduce an 'M' action in the tmpfiles language
which is a recursive version of 'm'.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Fix permissions on new journal files

[Dave Reisner]

On Tue, Mar 25, 2014 at 09:09:57AM -0700, Greg KH wrote:
 On Tue, Mar 25, 2014 at 12:01:01PM -0400, Dave Reisner wrote:
  On Tue, Mar 25, 2014 at 04:54:34PM +0100, Thomas Bächler wrote:
   Am 25.03.2014 01:40, schrieb Lennart Poettering:
This is just a kludge... Why is system.journal to be treated 
differently?
It seems that the proper fix is to set the mode on the directory 
properly
during installation.

Precisely, packaging script are expected to properly chown and setfacl
the directory on install. From the .spec file in Fedora:
   
   This completely ignores the problem Dave mentions in his earlier post:
   Volatile journals are owned by root:root.
  
  I talked to Lennart about this last night on IRC -- we agreed that the
  solution here is to introduce an 'M' action in the tmpfiles language
  which is a recursive version of 'm'.
 
 Cool, want me to code this up?

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

Re: [systemd-devel] [PATCH] time-util: accept epoch timetamps prefixed with @

[Dave Reisner]

On Sun, Mar 23, 2014 at 05:27:08PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
 On Sun, Mar 23, 2014 at 11:06:47AM -0400, Dave Reisner wrote:
  Also adds a few tests for the absolute cases of parse_timestamp.
 Yeah, that looks useful.
 
 You don't test negative values. Maybe you could an example with a negative
 value to the documentation and tests?

Negative epoch values? What would this represent?

 Zbyszek
 
 
  Suggested by: Mantas Mikulėnas graw...@gmail.com
  ---
   src/shared/time-util.c | 10 ++
   src/test/test-time.c   | 21 +
   2 files changed, 31 insertions(+)
  
  diff --git a/src/shared/time-util.c b/src/shared/time-util.c
  index faa3418..fe43404 100644
  --- a/src/shared/time-util.c
  +++ b/src/shared/time-util.c
  @@ -432,6 +432,7 @@ int parse_timestamp(const char *t, usec_t *usec) {
*   tomorrow (time is set to 00:00:00)
*   +5min
*   -5days
  + *   @1395584178  (seconds from the epoch)
*
*/
   
  @@ -473,7 +474,16 @@ int parse_timestamp(const char *t, usec_t *usec) {
   return r;
   
   goto finish;
  +} else if (t[0] == '@') {
  +time_t epoch;
   
  +r = safe_atoli(t+1, epoch);
  +if (r  0)
  +return r;
  +
  +assert_se(localtime_r(epoch, tm));
  +
  +goto finish;
   } else if (endswith(t,  ago)) {
   _cleanup_free_ char *z;
   
  diff --git a/src/test/test-time.c b/src/test/test-time.c
  index 36a3304..396111d 100644
  --- a/src/test/test-time.c
  +++ b/src/test/test-time.c
  @@ -126,9 +126,30 @@ static void test_format_timespan(usec_t accuracy) {
   test_format_timespan_one(9*USEC_PER_YEAR/5 - 23, accuracy);
   }
   
  +static void test_parse_timestamp_one(const char *timestamp, usec_t 
  expected) {
  +usec_t result = 0;
  +
  +parse_timestamp(timestamp, result);
  +printf(timestamp=%s, result=% PRIu64 \n, timestamp, result);
  +
  +assert_se(expected == result);
  +}
  +
  +static void test_parse_timestamp(void) {
  +test_parse_timestamp_one(2012-09-22 16:34:22, 134834606200);
  +test_parse_timestamp_one(2012-09-22 16:34, 134834604000);
  +test_parse_timestamp_one(2012-09-22, 13482864);
  +test_parse_timestamp_one(2012-09, 0);
  +test_parse_timestamp_one(@1234567890, 123456789000);
  +test_parse_timestamp_one(@1234567890 sec, 0);
  +test_parse_timestamp_one(1234567890 sec, 0);
  +test_parse_timestamp_one(1234567890, 0);
  +}
  +
   int main(int argc, char *argv[]) {
   test_parse_sec();
   test_parse_nsec();
  +test_parse_timestamp();
   test_format_timespan(1);
   test_format_timespan(USEC_PER_MSEC);
   test_format_timespan(USEC_PER_SEC);
  -- 
  1.9.1
  
  ___
  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] [PATCH] time-util: accept epoch timetamps prefixed with @

[Dave Reisner]

On Sun, Mar 23, 2014 at 06:30:02PM +0100, Tollef Fog Heen wrote:
 ]] Dave Reisner 
 
  On Sun, Mar 23, 2014 at 05:27:08PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
   On Sun, Mar 23, 2014 at 11:06:47AM -0400, Dave Reisner wrote:
Also adds a few tests for the absolute cases of parse_timestamp.
   Yeah, that looks useful.
   
   You don't test negative values. Maybe you could an example with a negative
   value to the documentation and tests?
  
  Negative epoch values? What would this represent?
 
 Time before the epoch?
 
 $ LANG=C date -d @-1
 Wed Dec 31 22:13:20 CET 1969
 
 So date(1) already understands this.

Uggh, do we really need to document this? I don't see why/where it would
actually be useful. FWIW, parse_timestamp sort of already handles
negative values with the exception of anything that results in a
timestamp of -1 -- mktime can't distinguish between a real timestamp of
-1 and an invalid struct tm which it can't convert.

  $ journalctl --since='1969-12-31 18:59:59'
  Failed to parse timestamp: 1969-12-31 18:59:59

But then there's also some inconsistent behavior which parse_timestamp
already exposes when dealing with absolutes:

  $ journalctl --since='1969-12-31 18:59:58'
  -- Logs begin at Fri 2013-11-15 18:11:44 EST, end at Sun 2014-03-23 14:01:01 
EDT. --
  EOF

  $ journalctl --since='-100 years'
  -- Logs begin at Fri 2013-11-15 18:11:44 EST, end at Sun 2014-03-23 14:01:01 
EDT. --
  logs follow

I don't think this is going to work out so well when the return type
involed (usec_t) is unsigned...

 -- 
 Tollef Fog Heen
 UNIX is user friendly, it's just picky about who its friends are
 ___
 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] [PATCH] time-util: accept epoch timetamps prefixed with @

[Dave Reisner]

On Sun, Mar 23, 2014 at 10:04:00PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
 On Sun, Mar 23, 2014 at 02:27:04PM -0400, Dave Reisner wrote:
  On Sun, Mar 23, 2014 at 06:30:02PM +0100, Tollef Fog Heen wrote:
   ]] Dave Reisner 
   
On Sun, Mar 23, 2014 at 05:27:08PM +0100, Zbigniew Jędrzejewski-Szmek 
wrote:
 On Sun, Mar 23, 2014 at 11:06:47AM -0400, Dave Reisner wrote:
  Also adds a few tests for the absolute cases of parse_timestamp.
 Yeah, that looks useful.
 
 You don't test negative values. Maybe you could an example with a 
 negative
 value to the documentation and tests?

Negative epoch values? What would this represent?
   
   Time before the epoch?
   
   $ LANG=C date -d @-1
   Wed Dec 31 22:13:20 CET 1969
   
   So date(1) already understands this.
  
  Uggh, do we really need to document this? I don't see why/where it would
  actually be useful.
 Well, you don't need to document this explictly, i.e. there's no need to
 talk about negative values, since they're not really useful, but I think
 it should be mentioned that the '@' is followed by a signed integer.

Ah, I guess you're pointing me at systemd.time(7).

  FWIW, parse_timestamp sort of already handles
  negative values with the exception of anything that results in a
  timestamp of -1 -- mktime can't distinguish between a real timestamp of
  -1 and an invalid struct tm which it can't convert.
  
$ journalctl --since='1969-12-31 18:59:59'
Failed to parse timestamp: 1969-12-31 18:59:59
  
  But then there's also some inconsistent behavior which parse_timestamp
  already exposes when dealing with absolutes:
  
$ journalctl --since='1969-12-31 18:59:58'
-- Logs begin at Fri 2013-11-15 18:11:44 EST, end at Sun 2014-03-23 
  14:01:01 EDT. --
EOF
  
$ journalctl --since='-100 years'
-- Logs begin at Fri 2013-11-15 18:11:44 EST, end at Sun 2014-03-23 
  14:01:01 EDT. --
logs follow
  
  I don't think this is going to work out so well when the return type
  involed (usec_t) is unsigned...
 Are you sure? In your patch you use safe_atoi (not safe_atou). And on my
 machine, time_t is defined as __time_t, which is __TIME_T_TYPE, 
 __SYSCALL_SLONG_TYPE,
 which looks signed to me. Actually, it seems that this safe_atoi should
 be replaced by assert_cc(sizeof(time_t)==sizeof(long)) and safe_atoli.

This isn't relevant to the problem I'm demonstrating. I agree that
time_t is a signed type. The trouble is with the outvalue from
parse_timestamps which is usec_t -- a systemd typedef which is uint64_t.

 Zbyszek
 ___
 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] [PATCH] build: change tcpwrappers support to disabled by default

[Dave Reisner]

On Thu, Mar 20, 2014 at 08:29:07PM +0100, Lennart Poettering wrote:
 On Thu, 20.03.14 12:49, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:
 
  The underlying components have not seen any upstream activity
  since 1997 and are not particulary nice either.
  
  Those interested in computer archeology can explicitly use --enable-tcpwrap
 
 Is suse intending to drop tcpwrap from its core os?
 
 I am all for getting rid of tcpwrap, but just disabling it in
 configure.ac by default looks like the wrong option to me...
 
 So far our policy was to enable evertyhing that exists in systemd by
 default when you build it with the default options, so that everything
 gets at least regularly compile tested, if not actually tested in
 real-life. 
 
 So, if this shall stay in systemd, then it should be enabled by
 default. The only other option I see is to remove it entirely, but i'd
 really like to keep the bigger picture in view there. Or in other words,
 if we get rid of it in systemd, we should do so knowing that this is in
 sync with what the big distros intend to do in general too.
 
 TO figure out what we can do in Fedora I have now started a discussion
 on fedora-devel, about getting rid of tcpwrap system-wide. Let's see
 where this goes. Would be interested in feedback about this from other
 distros too.

Arch removed tcpwrap from our repositories almost 3 years ago:

https://www.archlinux.org/news/dropping-tcp_wrappers-support/

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

Re: [systemd-devel] Mount options for $XDG_RUNTIME_DIR

[Dave Reisner]

On Mar 18, 2014 12:59 PM, Leonid Isaev lis...@umail.iu.edu wrote:

 [Sorry, forgot to CC the mailing list]

 Hi Lennart,

 On Tue, 18 Mar 2014 02:33:50 +0100
 Lennart Poettering lenn...@poettering.net wrote:

  On Mon, 17.03.14 19:04, Leonid Isaev (lis...@umail.iu.edu) wrote:
 
   Hi,
  
   Currently, XDG_RUNTIME_DIR=/run/user/UID is mounted with rather
   permissive, hardcoded mount options (or at least I couldn't find a
   documented way of changing them). Specifically, a user is allowed to
   execute things from his $XDG_RUNTIME_DIR. This effectively negates
admin's
   ability to constrain users, e.g. by mounting /home as noexec (I have
seen
   this done in some environments).
   Is there a need to allow execution from $XDG_RUNTIME_DIR? And how
   should one configure its mount options?
 
  Yes, this is hardcoded in 211, that's true. We could make this
  configurable but I am not really convinced that we really want that?

 I agree that a complete, fstab-like configuration may be too much.

 
  I mean, the XDG_RUNTIME_DIR spec says the dir must be fully-featured by
  the standards of the operating system. More specifically, ... proper
  permissions ... must be supported. I'd read that as if the x bit should
  do what it is supposed to do. So, in order to stay compatible with the
  spec allowing to mount it with noexec sounds undesirable.

 Well, regardless of what the XDG specification says, the fact is that
currently
 each user has 2 /home's: one under the admin control, another -- not.

 Of course, one could hook into PAM and remount each user's XDG_RUNTIME_DIR
 upon login, but this is hacking around the init system... What about
making
 XDG_RUNTIME_DIR inherit mount options from /home if the latter is a
separate
 partition and fall back to the current default otherwise?

 
  Moreover noexec is mostly snake-oil, isn't it? You can invoke the
  executables with an interpreter still, and you can copy the files
  elsewhere...

 True for the interpreted code.

And compiled code. The linker is your ELF interpreter.

 However regarding other places, if an admin
 cares about noexec at all, /var/tmp, /tmp and /dev/shm should be also
 constrained (I am not saying that this should be the default, just
 configurable).

 Thanks,
 Leonid.

 
  Note that setting noexec on an fs means you cannot maps its files
  PROT_EXEC anymore, which breaks a number of things. In the past people
  attempted to mount /dev/shm as noexec, and dosemu broke because it made
  use of this. Then people wanted to mount /dev as noexec, which broke X11
  which wanted to map some device nodes PROT_EXEC. Given that we consider
  XDG_RUNTIME_DIR as a private version of /dev/shm among other things it
  really sounds wrong to break this right from the start.

 
  So, I am not really convinced I must say...
 
  Lennart
 



 --
 Leonid Isaev
 GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D

 ___
 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] [PATCH] Fix permissions on new journal files

[Dave Reisner]

On Fri, Mar 14, 2014 at 03:28:27AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
 On Fri, Mar 14, 2014 at 12:07:35AM +, Greg KH wrote:
  When starting up journald on a new system, set the proper permissions on
  the system.journal file, not only on the journal directory.
  
  diff --git a/tmpfiles.d/systemd.conf b/tmpfiles.d/systemd.conf
  index 7c6d6b9099b9..1aeb5e40f1ee 100644
  --- a/tmpfiles.d/systemd.conf
  +++ b/tmpfiles.d/systemd.conf
  @@ -24,5 +24,7 @@ d /run/systemd/shutdown 0755 root root -
   
   m /var/log/journal 2755 root systemd-journal - -
   m /var/log/journal/%m 2755 root systemd-journal - -
  +m /var/log/journal/%m/system.journal 2755 root systemd-journal - -
   m /run/log/journal 2755 root systemd-journal - -
   m /run/log/journal/%m 2755 root systemd-journal - -
  +m /run/log/journal/%m/system.journal 2755 root systemd-journal - -
 This is just a kludge... Why is system.journal to be treated differently?
 It seems that the proper fix is to set the mode on the directory properly
 during installation.

FWIW, this would also solve a problem with users who set
Storage=volatile in journald.conf. I'm not saying this is the correct
solution, but currently non-root users are unable to read from volatile
journals because the journal files are created as root:root before
tmpfiles runs.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Unmentioned 209 change: 80-net-name-slot.rules is gone

[Dave Reisner]

On Fri, Feb 21, 2014 at 05:12:56PM +0100, Jason A. Donenfeld wrote:
 To clarify things:
 
 1. Arch's script deals with 80-net-setup-link.rules

We (Arch) made a decision back when the persistent naming was added to
make it opt-in by masking 80-net-name-slot.rules in /etc. Now, if the
209 upgrade comes around and 80-net-name-slot.rules still exists in
/etc, we just rename it. We make no assumptions about the contents of
that file. If the user added their own naming rules to that file, we
have absolutely no surefire way of determining what the net effect of
those rules are, and what they might translate to, functionally, in
99-default.link.

 2. freedesktop.org wiki followed suit and added that suggestion
 3. Others have said elsewhere that the proper way to do this is
 actually to override 99-default.link instead.
 4. Gentoo went with number 3.
 
 Now:
 
 5. Can numbers 1 and 2 update to the suggestion of 3?

So, no, 1 won't be changed. Comparing a post_upgrade action to a wiki
page is an odd choice, anyways.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Cannot boot after upgrading to latest git version

[Dave Reisner]

On Sat, Feb 22, 2014 at 04:05:31PM +0100, Armin K. wrote:
 Hi, I just finished upgrading to latest git master and I can't boot anymore.

Without knowing what version you upgraded *from*, this is incomplete
information.

 Partitions are failing to mount, even though I can confirm that correct
 device nodes exist in /dev when I enter the rescue mode shell. I don't
 use initramfs on this system, so all drivers are mostly built into
 kernel and devtmpfs is mounted even before systemd is started, so at
 least /dev/sda7 should be detected, but it isn't as you can see.
 
 Attached is the journalctl -xb log from rescue console.

There's been a number posts like this on the list recently, all of
which point to the kernel not having CONFIG_FHANDLE=y.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] journald: ignore failure to watch hostname_fd on older kernels

[Dave Reisner]

Prior to 3.2, /proc/sys/kernel/hostname isn't a pollable file and
sd_event_add_io will return EPERM. Ignore this failure, since it isn't
critical to journald operation.
---
Reported and tested by user sraue on IRC.

 src/journal/journald-server.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
index 5872e91..add6cf5 100644
--- a/src/journal/journald-server.c
+++ b/src/journal/journald-server.c
@@ -1430,6 +1430,14 @@ static int server_open_hostname(Server *s) {
 
 r = sd_event_add_io(s-event, s-hostname_event_source, 
s-hostname_fd, 0, dispatch_hostname_change, s);
 if (r  0) {
+/* kernels prior to 3.2 don't support polling this file.
+ * quietly ignore the failure. */
+if (r == -EPERM) {
+close_nointr_nofail(s-hostname_fd);
+s-hostname_fd = -1;
+return 0;
+}
+
 log_error(Failed to register hostname fd in event loop: %s, 
strerror(-r));
 return r;
 }
-- 
1.9.0

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

Re: [systemd-devel] [PATCH] journald: ignore failure to watch hostname_fd on older kernels

[Dave Reisner]

On Fri, Feb 21, 2014 at 06:00:46PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
 On Fri, Feb 21, 2014 at 11:22:50AM -0500, Dave Reisner wrote:
  Prior to 3.2, /proc/sys/kernel/hostname isn't a pollable file and
  sd_event_add_io will return EPERM. Ignore this failure, since it isn't
  critical to journald operation.
  ---
  Reported and tested by user sraue on IRC.
 This should probably go above ---, to give credit in the changelog.
  
   src/journal/journald-server.c | 8 
   1 file changed, 8 insertions(+)
  
  diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
  index 5872e91..add6cf5 100644
  --- a/src/journal/journald-server.c
  +++ b/src/journal/journald-server.c
  @@ -1430,6 +1430,14 @@ static int server_open_hostname(Server *s) {
   
   r = sd_event_add_io(s-event, s-hostname_event_source, 
  s-hostname_fd, 0, dispatch_hostname_change, s);
   if (r  0) {
  +/* kernels prior to 3.2 don't support polling this file.
  + * quietly ignore the failure. */
  +if (r == -EPERM) {
  +close_nointr_nofail(s-hostname_fd);
  +s-hostname_fd = -1;
  +return 0;
  +}
 Critical not, but certainly worth a warning.
 
 Zbyszek

Thanks, I'll push with these 2 changes.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] nspawn: allow 32-bit chroots from 64-bit hosts

[Dave Reisner]

Arch Linux uses nspawn as a container for building packages and needs
to be able to start a 32bit chroot from a 64bit host. 24fb11120756
disrupted this feature when seccomp handling was added.
---
Lennart suggested this approach, and it works nicely.

 src/nspawn/nspawn.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
index 089af07..5a2467d 100644
--- a/src/nspawn/nspawn.c
+++ b/src/nspawn/nspawn.c
@@ -1539,6 +1539,14 @@ static int audit_still_doesnt_work_in_containers(void) {
 goto finish;
 }
 
+#ifdef __x86_64__
+r = seccomp_arch_add(seccomp, SCMP_ARCH_X86);
+if (r  0  r != -EEXIST) {
+log_error(Failed to add x86 to seccomp filter: %s, 
strerror(-r));
+goto finish;
+}
+#endif
+
 r = seccomp_load(seccomp);
 if (r  0)
 log_error(Failed to install seccomp audit filter: %s, 
strerror(-r));
-- 
1.9.0

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

Re: [systemd-devel] [PATCH] nspawn: allow 32-bit chroots from 64-bit hosts

[Dave Reisner]

On Tue, Feb 18, 2014 at 02:44:14PM -0500, Dave Reisner wrote:
 Arch Linux uses nspawn as a container for building packages and needs
 to be able to start a 32bit chroot from a 64bit host. 24fb11120756
 disrupted this feature when seccomp handling was added.
 ---
 Lennart suggested this approach, and it works nicely.

I suppose it's also possible to run an x32 chroot from an x86_64 host,
so we might want to allow that. Alternatively, it seems we can just
change the default action to allow (instead of kill) when a bad
architecture is encountered. I don't know if there's side effects with
that change that we'd want to avoid.

 
  src/nspawn/nspawn.c | 8 
  1 file changed, 8 insertions(+)
 
 diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
 index 089af07..5a2467d 100644
 --- a/src/nspawn/nspawn.c
 +++ b/src/nspawn/nspawn.c
 @@ -1539,6 +1539,14 @@ static int audit_still_doesnt_work_in_containers(void) 
 {
  goto finish;
  }
  
 +#ifdef __x86_64__
 +r = seccomp_arch_add(seccomp, SCMP_ARCH_X86);
 +if (r  0  r != -EEXIST) {
 +log_error(Failed to add x86 to seccomp filter: %s, 
 strerror(-r));
 +goto finish;
 +}
 +#endif
 +
  r = seccomp_load(seccomp);
  if (r  0)
  log_error(Failed to install seccomp audit filter: %s, 
 strerror(-r));
 -- 
 1.9.0
 
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] linux container started with systemd-nspawn

[Dave Reisner]

On Mon, Feb 17, 2014 at 07:35:20PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
 On Mon, Feb 17, 2014 at 06:38:04PM +0100, arnaud gaboury wrote:
   At least in systemd git nspawn places its machines in machines.slice.
  
   Lennart
  
   --
   Lennart Poettering, Red Hat
  
  I can not build from git.
  
  ..
  GPERFsrc/core/load-fragment-gperf.c
  Empty input keyword is not allowed.
  To recognize an empty input keyword, your code should check for
  len == 0 before calling the gperf generated lookup function.
  Makefile:15823: recipe for target 'src/core/load-fragment-gperf.c' failed
  make[2]: *** [src/core/load-fragment-gperf.c] Error 1
 What configure options did you use? Can you show the output from configure 
 where
 it says what is enabled and what is disabled.
 
 What gperf version do you have?
 
 Zbyszek
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Doesn't build for me with the suggested ./configure options, using gperf
3.0.4. I applied this patch locally fix it:

https://paste.xinu.at/Ffu/

The problem seems to be the empty lines in the generated .gperf file.

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

Re: [systemd-devel] [PATCH 1/2] test: add basic seccomp tests

[Dave Reisner]

On Thu, Feb 13, 2014 at 09:58:53AM +0100, Ronny Chevalier wrote:
 2014-02-13 3:34 GMT+01:00 Dave Reisner d...@falconindy.com:
  On Thu, Jan 23, 2014 at 01:34:57AM +0100, Ronny Chevalier wrote:
  ---
   test/TEST-04-SECCOMP/Makefile   |  1 +
   test/TEST-04-SECCOMP/test-seccomp.sh| 11 
   test/TEST-04-SECCOMP/test.sh| 79 
  +
   test/TEST-04-SECCOMP/will-fail.service  |  6 +++
   test/TEST-04-SECCOMP/will-not-fail.service  |  6 +++
   test/TEST-04-SECCOMP/will-not-fail2.service |  6 +++
   6 files changed, 109 insertions(+)
   create mode 12 test/TEST-04-SECCOMP/Makefile
   create mode 100755 test/TEST-04-SECCOMP/test-seccomp.sh
   create mode 100755 test/TEST-04-SECCOMP/test.sh
   create mode 100644 test/TEST-04-SECCOMP/will-fail.service
   create mode 100644 test/TEST-04-SECCOMP/will-not-fail.service
   create mode 100644 test/TEST-04-SECCOMP/will-not-fail2.service
 
  diff --git a/test/TEST-04-SECCOMP/Makefile b/test/TEST-04-SECCOMP/Makefile
  new file mode 12
  index 000..e9f93b1
  --- /dev/null
  +++ b/test/TEST-04-SECCOMP/Makefile
  @@ -0,0 +1 @@
  +../TEST-01-BASIC/Makefile
  \ No newline at end of file
  diff --git a/test/TEST-04-SECCOMP/test-seccomp.sh 
  b/test/TEST-04-SECCOMP/test-seccomp.sh
  new file mode 100755
  index 000..fef334e
  --- /dev/null
  +++ b/test/TEST-04-SECCOMP/test-seccomp.sh
  @@ -0,0 +1,11 @@
  +#!/bin/bash -x
  +
  +systemctl start will-fail.service
  +systemctl start will-not-fail.service
  +systemctl start will-not-fail2.service
  +systemctl is-failed will-fail.service | grep failed || exit 1
  +systemctl is-failed will-not-fail.service | grep failed  exit 1
  +systemctl is-failed will-not-fail2.service | grep failed  exit 1
 
  This is weird. You should be able to rely on the exit code rather than
  parsing the output, but it seems this was broken in e3e0314b.
 
 Yes, this is why I did this.

Should be fixed by 5a1aece58.

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

Re: [systemd-devel] [PATCH 1/2] test: add basic seccomp tests

[Dave Reisner]

On Thu, Jan 23, 2014 at 01:34:57AM +0100, Ronny Chevalier wrote:
 ---
  test/TEST-04-SECCOMP/Makefile   |  1 +
  test/TEST-04-SECCOMP/test-seccomp.sh| 11 
  test/TEST-04-SECCOMP/test.sh| 79 
 +
  test/TEST-04-SECCOMP/will-fail.service  |  6 +++
  test/TEST-04-SECCOMP/will-not-fail.service  |  6 +++
  test/TEST-04-SECCOMP/will-not-fail2.service |  6 +++
  6 files changed, 109 insertions(+)
  create mode 12 test/TEST-04-SECCOMP/Makefile
  create mode 100755 test/TEST-04-SECCOMP/test-seccomp.sh
  create mode 100755 test/TEST-04-SECCOMP/test.sh
  create mode 100644 test/TEST-04-SECCOMP/will-fail.service
  create mode 100644 test/TEST-04-SECCOMP/will-not-fail.service
  create mode 100644 test/TEST-04-SECCOMP/will-not-fail2.service
 
 diff --git a/test/TEST-04-SECCOMP/Makefile b/test/TEST-04-SECCOMP/Makefile
 new file mode 12
 index 000..e9f93b1
 --- /dev/null
 +++ b/test/TEST-04-SECCOMP/Makefile
 @@ -0,0 +1 @@
 +../TEST-01-BASIC/Makefile
 \ No newline at end of file
 diff --git a/test/TEST-04-SECCOMP/test-seccomp.sh 
 b/test/TEST-04-SECCOMP/test-seccomp.sh
 new file mode 100755
 index 000..fef334e
 --- /dev/null
 +++ b/test/TEST-04-SECCOMP/test-seccomp.sh
 @@ -0,0 +1,11 @@
 +#!/bin/bash -x
 +
 +systemctl start will-fail.service
 +systemctl start will-not-fail.service
 +systemctl start will-not-fail2.service
 +systemctl is-failed will-fail.service | grep failed || exit 1
 +systemctl is-failed will-not-fail.service | grep failed  exit 1
 +systemctl is-failed will-not-fail2.service | grep failed  exit 1

This is weird. You should be able to rely on the exit code rather than
parsing the output, but it seems this was broken in e3e0314b.

 +
 +touch /testok
 +exit 0
 diff --git a/test/TEST-04-SECCOMP/test.sh b/test/TEST-04-SECCOMP/test.sh
 new file mode 100755
 index 000..c29192e
 --- /dev/null
 +++ b/test/TEST-04-SECCOMP/test.sh
 @@ -0,0 +1,79 @@
 +#!/bin/bash
 +# -*- mode: shell-script; indent-tabs-mode: nil; sh-basic-offset: 4; -*-
 +# ex: ts=8 sw=4 sts=4 et filetype=sh
 +TEST_DESCRIPTION=seccomp tests
 +
 +. $TEST_BASE_DIR/test-functions
 +
 +check_result_qemu() {
 +ret=1
 +mkdir -p $TESTDIR/root
 +mount ${LOOPDEV}p1 $TESTDIR/root
 +[[ -e $TESTDIR/root/testok ]]  ret=0
 +[[ -f $TESTDIR/root/failed ]]  cp -a $TESTDIR/root/failed $TESTDIR
 +cp -a $TESTDIR/root/var/log/journal $TESTDIR
 +umount $TESTDIR/root
 +[[ -f $TESTDIR/failed ]]  cat $TESTDIR/failed
 +ls -l $TESTDIR/journal/*/*.journal
 +test -s $TESTDIR/failed  ret=$(($ret+1))
 +return $ret
 +}
 +
 +test_run() {
 +if run_qemu; then
 +check_result_qemu || return 1
 +else
 +dwarn can't run QEMU, skipping
 +fi
 +if check_nspawn; then
 +run_nspawn
 +check_result_nspawn || return 1
 +else
 +dwarn can't run systemd-nspawn, skipping
 +fi
 +return 0
 +}
 +
 +test_setup() {
 +create_empty_image
 +mkdir -p $TESTDIR/root
 +mount ${LOOPDEV}p1 $TESTDIR/root
 +
 +# Create what will eventually be our root filesystem onto an overlay
 +(
 +LOG_LEVEL=5
 +eval $(udevadm info --export --query=env --name=${LOOPDEV}p2)
 +
 +setup_basic_environment
 +
 +# setup the testsuite service
 +cat $initdir/etc/systemd/system/testsuite.service EOF
 +[Unit]
 +Description=Testsuite service
 +After=multi-user.target
 +
 +[Service]
 +ExecStart=/test-seccomp.sh
 +Type=oneshot
 +EOF
 +
 +# copy the units used by this test
 +cp {will-fail,will-not-fail,will-not-fail2}.service \
 +$initdir/etc/systemd/system
 +cp test-seccomp.sh $initdir/
 +
 +setup_testsuite
 +)
 +setup_nspawn_root
 +
 +ddebug umount $TESTDIR/root
 +umount $TESTDIR/root
 +}
 +
 +test_cleanup() {
 +umount $TESTDIR/root 2/dev/null
 +[[ $LOOPDEV ]]  losetup -d $LOOPDEV
 +return 0
 +}
 +
 +do_test $@
 diff --git a/test/TEST-04-SECCOMP/will-fail.service 
 b/test/TEST-04-SECCOMP/will-fail.service
 new file mode 100644
 index 000..18e034e
 --- /dev/null
 +++ b/test/TEST-04-SECCOMP/will-fail.service
 @@ -0,0 +1,6 @@
 +[Unit]
 +Description=Will fail
 +
 +[Service]
 +ExecStart=/bin/echo This should not be seen
 +SystemCallFilter=ioperm
 diff --git a/test/TEST-04-SECCOMP/will-not-fail.service 
 b/test/TEST-04-SECCOMP/will-not-fail.service
 new file mode 100644
 index 000..c56797f
 --- /dev/null
 +++ b/test/TEST-04-SECCOMP/will-not-fail.service
 @@ -0,0 +1,6 @@
 +[Unit]
 +Description=Will not fail
 +
 +[Service]
 +ExecStart=/bin/echo Foo bar
 +SystemCallFilter=~ioctl
 diff --git a/test/TEST-04-SECCOMP/will-not-fail2.service 
 b/test/TEST-04-SECCOMP/will-not-fail2.service
 new file mode 100644
 index 000..2df05e3
 --- /dev/null
 +++ b/test/TEST-04-SECCOMP/will-not-fail2.service
 @@ -0,0 +1,6 @@
 +[Unit]
 +Description=Reset SystemCallFilter
 +
 +[Service]
 +ExecStart=/bin/echo Foo bar
 

Re: [systemd-devel] /run needs to be mounted? ugh.

[Dave Reisner]

On Tue, Feb 11, 2014 at 04:32:56PM +0100, Jason A. Donenfeld wrote:
 Hey folks,
 
 I'm using better-initramfs [1], a very small and minimal initrd that
 has been working very well for me. In switching to systemd, I found it
 necessary to have the initrd mount /run as tmpfs, according to the
 specs [2]. I made a little patch for better-initramfs, and now I'm
 talking to the maintainer about merging that.

Strange name. I can't find one thing which I find better about this
project compared to the more well-known initramfs creation tools.

 But really... I don't want to do this. Why is systemd itself not
 capable of setting up /run? Why does the initrd need to do it? My
 experience booting without /run is that systemd then fails to start
 completely. Is this what's supposed to happen? What's going on?
 Preferably, I don't desire to place any additional systemd-specific
 burden on better-initramfs.

systemd is already capable of setting up /run on its own:

http://cgit.freedesktop.org/systemd/systemd/tree/src/core/mount-setup.c#n69

I have machines which boot systemd without an initramfs, so whatever
you're running into seems to be specific to your setup.

The existence of /run solves problems that existed even before systemd.
Among other uses, it stores runtime state which might need to be written
in order to setup the root storage stack. The fact that systemd was the
impetus to introduce this as a standard is really doing a favor to
early userspace maintainers everywhere.

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

Re: [systemd-devel] /run needs to be mounted? ugh.

[Dave Reisner]

On Tue, Feb 11, 2014 at 05:09:49PM +0100, Jason A. Donenfeld wrote:
 On Tue, Feb 11, 2014 at 5:01 PM, Dave Reisner d...@falconindy.com wrote:
  systemd is already capable of setting up /run on its own:
 
  http://cgit.freedesktop.org/systemd/systemd/tree/src/core/mount-setup.c#n69
 
 You appear to be right.
 
 In that case should the spec [1] be amended to remove this requirement?
 
 [1] http://www.freedesktop.org/wiki/Software/systemd/InitrdInterface/

I don't think there's any change needed here. The interface states:

  The initrd should mount /run as a tmpfs.

Consider the definition of should from RFC2119

  SHOULD: This word, or the adjective RECOMMENDED, mean that there
  may exist valid reasons in particular circumstances to ignore a
  particular item, but the full implications must be understood and
  carefully weighed before choosing a different course.

And sure enough, this isn't a requirement, but there's many valid
reasons to do this.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /run needs to be mounted? ugh.

[Dave Reisner]

On Tue, Feb 11, 2014 at 08:32:29PM +0400, Andrey Borzenkov wrote:
 В Tue, 11 Feb 2014 17:25:29 +0100
 Lennart Poettering lenn...@poettering.net пишет:
 
  
  An initrd without /run is mostly pointless, no? Either you have storage
  daemons and hence need /run around, or you don't have storage daemons,
  in which case you can just boot without involving any initrd?
  
 
 You still need something to resolve LABEL, UUID, /dev/disk/by-* or any
 other fancy root names.

Though, thanks to the chromium folks, the kernel has no problems
resolving PARTUUID on its own.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /run needs to be mounted? ugh.

[Dave Reisner]

On Tue, Feb 11, 2014 at 05:25:19PM +, Colin Guthrie wrote:
 'Twas brillig, and Reindl Harald at 11/02/14 16:34 did gyre and gimble:
  
  
  Am 11.02.2014 17:29, schrieb Andrey Borzenkov:
  В Tue, 11 Feb 2014 17:20:15 +0100
  Jason A. Donenfeld ja...@zx2c4.com пишет:
 
  On Tue, Feb 11, 2014 at 5:15 PM, Dave Reisner d...@falconindy.com wrote:
  I don't think there's any change needed here. The interface states:
 
The initrd should mount /run as a tmpfs.
 
  And sure enough, this isn't a requirement, but there's many valid
  reasons to do this.
 
 
  Ahh, okay. I suppose what I'm wondering is what the advantages are to
  mounting /run (if the remaining interfaces in the list aren't used)?
  It looks like mounting /run occurs pretty soon in core/main.c. Could
  it be that the only advantages of mounting /run early on are for using
  the more advanced systemd initrd interfaces, such as giving control
  back during shutdown? Or are there benefits in doing this even for the
  most minimal of initrd?
 
  /run is used to pass state between initrd and system for such
  components as udev or mdadm. I do not know how your initramfs
  implementation works and whether it is using udev, but if you support
  root on MD, you likely will need /run
  
  in context systemd maybe, in context MD not
  
  the machine in front of me running F20 with systemd has root
  on RAID10 originally installed with F14 before /run and systemd
  existed in the setup
 
 Yeah for various values of works.
 
 Without /run in such a setup, there is no way to pass udev db
 information to the running system.

This isn't really wanted. dracut, mkinitcpio, and systemd itself will
all clean out the udev DB before switching to the real root filesystem
by calling udevadm info --cleanup-db. Unfortunately, certain storage
stacks (looking at you, DM) require that some of the data stored in the
udev DB survive the switch root. This leads to udev rules like:

SUBSYSTEM==block, KERNEL==dm-[0-9]*, ACTION==add|change, 
OPTIONS=db_persist

 If this pre-dates using udev in the initrd, then the initrd will have
 bring up the h/w by itself and udev still misses important metadata when
 it finally kicks in and will thus give an incomplete picture to the rest
 of userspace.

In an ideal world, calling 'udevadm trigger ...' should be sufficient to
completely recreate the udev DB with no help from early userspace.

 As has been mentioned elsewhere on this thread, there are a number of
 gotchas and corner cases, that this mechanism solved, even in the
 cases of things working.
 
 Col
 
 
 
 -- 
 
 Colin Guthrie
 gmane(at)colin.guthr.ie
 http://colin.guthr.ie/
 
 Day Job:
   Tribalogic Limited http://www.tribalogic.net/
 Open Source:
   Mageia Contributor http://www.mageia.org/
   PulseAudio Hacker http://www.pulseaudio.org/
   Trac Hacker http://trac.edgewall.org/
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] cryptsetup-generator: auto add deps for device as password

[Dave Reisner]

If the password is a device file, we can add Requires/After dependencies
on the device rather than requiring the user to do so.
---
This is based on a bug filed to Arch:

https://bugs.archlinux.org/task/38842

Assuming I'm correct about the race condition, this should be an easy way
of closing it without user involvement.

 src/cryptsetup/cryptsetup-generator.c | 25 -
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/src/cryptsetup/cryptsetup-generator.c 
b/src/cryptsetup/cryptsetup-generator.c
index 9c98f0b..4542757 100644
--- a/src/cryptsetup/cryptsetup-generator.c
+++ b/src/cryptsetup/cryptsetup-generator.c
@@ -130,11 +130,26 @@ static int create_disk(
 streq(password, /dev/random) ||
 streq(password, /dev/hw_random))
 fputs(After=systemd-random-seed.service\n, f);
-else if (!streq(password, -) 
- !streq(password, none))
-fprintf(f,
-RequiresMountsFor=%s\n,
-password);
+else {
+_cleanup_free_ char *uu = 
fstab_node_to_udev_node(password);
+if (uu == NULL)
+return log_oom();
+
+if (is_device_path(uu)) {
+_cleanup_free_ char *dd = 
unit_name_from_path(uu, .device);
+if (dd == NULL)
+return log_oom();
+
+fprintf(f,
+After=%s\n
+Requires=%s\n,
+dd, dd);
+} else if (!streq(password, -) 
+ !streq(password, none))
+fprintf(f,
+RequiresMountsFor=%s\n,
+password);
+}
 }
 
 if (is_device_path(u))
-- 
1.8.5.4

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

Re: [systemd-devel] [PATCH] cryptsetup-generator: auto add deps for device as password

[Dave Reisner]

On Sat, Feb 08, 2014 at 07:31:28PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
 On Sat, Feb 08, 2014 at 01:12:14PM -0500, Dave Reisner wrote:
  If the password is a device file, we can add Requires/After dependencies
  on the device rather than requiring the user to do so.
  ---
  This is based on a bug filed to Arch:
  
  https://bugs.archlinux.org/task/38842
  
  Assuming I'm correct about the race condition, this should be an easy way
  of closing it without user involvement.
  
   src/cryptsetup/cryptsetup-generator.c | 25 -
   1 file changed, 20 insertions(+), 5 deletions(-)
  
  diff --git a/src/cryptsetup/cryptsetup-generator.c 
  b/src/cryptsetup/cryptsetup-generator.c
  index 9c98f0b..4542757 100644
  --- a/src/cryptsetup/cryptsetup-generator.c
  +++ b/src/cryptsetup/cryptsetup-generator.c
  @@ -130,11 +130,26 @@ static int create_disk(
   streq(password, /dev/random) ||
   streq(password, /dev/hw_random))
   fputs(After=systemd-random-seed.service\n, f);
  -else if (!streq(password, -) 
  - !streq(password, none))
  -fprintf(f,
  -RequiresMountsFor=%s\n,
  -password);
  +else {
  +_cleanup_free_ char *uu = 
  fstab_node_to_udev_node(password);
  +if (uu == NULL)
  +return log_oom();
  +
  +if (is_device_path(uu)) {
  +_cleanup_free_ char *dd = 
  unit_name_from_path(uu, .device);
  +if (dd == NULL)
  +return log_oom();
  +
  +fprintf(f,
  +After=%s\n
  +Requires=%s\n,
  +dd, dd);
  +} else if (!streq(password, -) 
  + !streq(password, none))
  +fprintf(f,
  +RequiresMountsFor=%s\n,
  +password);
  +}
 Patch looks fine, but I don't really understand why you invert the order of 
 conditions.
 Something like this feels more natural:

Yeah, not sure what I was thinking here. Thanks for the suggestion --
will push with this change.

 else if (!streq(password, -) 
  !streq(password, none)) {
 
 _cleanup_free_ char *uu = 
 fstab_node_to_udev_node(password);
 if (uu == NULL)
 return log_oom();
 
 if (is_device_path(uu)) {
 _cleanup_free_ char *dd = 
 unit_name_from_path(uu, .device);
 if (dd == NULL)
 return log_oom();
 
 fprintf(f, After=%1$s\nRequires=%1$s\n, dd);
 } else
   fprintf(f, RequiresMountsFor=%s\n, password);
 }
 
 Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] SocketUser and SocketGroup?

[Dave Reisner]

On Sat, Jan 25, 2014 at 12:58:55PM -0800, Josh Triplett wrote:
 Some daemons provide an access-controlled service via UNIX domain
 sockets that have a specified user or group, and a mode like 0660.  For
 instance, clamd does this.  systemd .socket units don't support setting
 the user or group; systemd always creates sockets as root:root.  This
 prevents replacing the socket setup code in such daemons with socket
 activation, or requires workarounds such as shelling out to chown.
 
 Commit aea54018a5e66a41318afb6c6be745b6aef48d9e
 (http://cgit.freedesktop.org/systemd/systemd/commit/?id=aea54018a5e66a41318afb6c6be745b6aef48d9e)
 added support for SocketUser and SocketGroup options, to set the
 user and group for a UNIX domain socket or FIFO.  However, commit
 e4f44e734c4f397ee5e7ba3270e014a8ae0043dd
 (http://cgit.freedesktop.org/systemd/systemd/commit/?id=e4f44e734c4f397ee5e7ba3270e014a8ae0043dd)
 shortly afterward reverted that, removing the new options.
 
 Is this due to the issues with touching NSS from PID 1?

Yep.

 What might it take to add those options back?

There was a recent discussion about joining namespaces from PID 1 which
brought up the idea of forking off a small process from PID 1 to do that
job instead. The same sort of logic would allow doing NSS calls from PID 1.

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

Re: [systemd-devel] network-online.target and manual mounts

[Dave Reisner]

On Wed, Jan 01, 2014 at 11:43:15PM +0400, Andrey Borzenkov wrote:
 systemd.special(7) suggests that network-online.target should be pulled
 in by consumer. Unfortunately, that means that when booting without
 active consumer (let's say no NFS mounts in fstab) network-online.target
 is not started at all. If NFS is mounted manually later, no
 synchronization point exists on shutdown, so network may be stopped
 before NFS is unmounted. This leads to prolonged timeout.
 
 Is there any mechanism to start it when NFS (or other network) mount
 appears? The very existence of network mount could be considered as
 indication that network *is* online?

I think tihs is a post-v208 change, but if you manually mount a network
share manually after booting, network-online.target is pulled in as
Wants= and After=. This should make for correct ordering on shutdown.

# mount.cifs //10.0.2.1/pkgs pkg -o defaults,guest,rw
# systemctl show -p After -p Wants $PWD/pkg
Wants=network-online.target system.slice
After=systemd-journald.socket remote-fs-pre.target network.target 
network-online.target system.slice -.mount

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

[systemd-devel] [PATCH] systemd.service(5): clarify behavior of SuccessExitStatus

[Dave Reisner]

The behavior of this is a little cryptic in that $MAINPID must exit as
a direct result of receiving a signal in order for a listed signal to
be considered a success condition.
---
 man/systemd.service.xml | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/man/systemd.service.xml b/man/systemd.service.xml
index 27f069f..c3a9307 100644
--- a/man/systemd.service.xml
+++ b/man/systemd.service.xml
@@ -737,7 +737,10 @@ ExecStart=/bin/echo $ONE $TWO ${TWO}
 constantSIGTERM/constant and 
constantSIGPIPE/constant. Exit status
 definitions can either be numeric exit
 codes or termination signal names,
-separated by spaces. Example:
+separated by spaces. Signals will only
+be considered if the service does not implement
+a signal handler and exits as a direct result
+of receiving the signal. Example:
 literalSuccessExitStatus=1 2 8
 constantSIGKILL/constant/literal, 
ensures that exit
 codes 1, 2, 8 and the termination
-- 
1.8.5.2

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

Re: [systemd-devel] [PATCH] systemd.service(5): clarify behavior of SuccessExitStatus

[Dave Reisner]

On Fri, Dec 27, 2013 at 09:09:21PM +0100, Lennart Poettering wrote:
 On Fri, 27.12.13 17:00, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
 
  
  On Fri, Dec 27, 2013 at 10:46:48AM -0500, Dave Reisner wrote:
   The behavior of this is a little cryptic in that $MAINPID must exit as
   a direct result of receiving a signal in order for a listed signal to
   be considered a success condition.
   ---
man/systemd.service.xml | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
   
   diff --git a/man/systemd.service.xml b/man/systemd.service.xml
   index 27f069f..c3a9307 100644
   --- a/man/systemd.service.xml
   +++ b/man/systemd.service.xml
   @@ -737,7 +737,10 @@ ExecStart=/bin/echo $ONE $TWO ${TWO}
constantSIGTERM/constant and 
   constantSIGPIPE/constant. Exit status
definitions can either be numeric exit
codes or termination signal names,
   -separated by spaces. Example:
   +separated by spaces. Signals will only
   +be considered if the service does not 
   implement
   +a signal handler and exits as a direct 
   result
   +of receiving the signal. Example:
literalSuccessExitStatus=1 2 8
constantSIGKILL/constant/literal, 
   ensures that exit
codes 1, 2, 8 and the termination
  This is incorrect/misleading too. Normally you're supposed to have a
  signal handler, do cleanup, uninstall the handler, and then signal
  yourself again.
 
 We certainly don't do that in systemd... I never heard of that
 suggestion, I must say. (Any link where this is suggested?) I must say
 that Dave's addition sounded correct to me, even though you do have a
 point that one can uninstall the signal handler and trigger the signal
 again...

I suppose a9a305332b addresses both sides of this. Thanks!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] fstab-generator: Do not try to fsck non-devices

[Dave Reisner]

On Sat, Dec 21, 2013 at 12:49:07PM +0100, Tom Gundersen wrote:
 On Sat, Dec 21, 2013 at 11:22 AM, Thomas Bächler tho...@archlinux.org wrote:
  This fixes a regression introduced in 64e70e4 where the mount fails
  when fstab is misconfigured with fs_passno  0 on a virtual file
  system like tmpfs.
  ---
   src/fstab-generator/fstab-generator.c | 8 +---
   1 file changed, 5 insertions(+), 3 deletions(-)
 
  diff --git a/src/fstab-generator/fstab-generator.c 
  b/src/fstab-generator/fstab-generator.c
  index 1227f08..709a1c3 100644
  --- a/src/fstab-generator/fstab-generator.c
  +++ b/src/fstab-generator/fstab-generator.c
  @@ -255,9 +255,11 @@ static int add_mount(
   Before=%s\n,
   post);
 
  -r = add_fsck(f, what, where, type, passno);
  -if (r  0)
  -return r;
  +if(is_device_path(what)) {
  +r = add_fsck(f, what, where, type, passno);
  +if (r  0)
  +return r;
  +}
 
   fprintf(f,
   \n
 
 How does fsck -A deal with these cases?

tmpfs falls into the category of pseudofs, which fsck -A will
intentionally ignore, regardless of the passno.

 Also, how does your patch deal with LABEL= and UUDI=?

At this point, what has been filtered through fstab_node_to_udev_node,
so LABEL=foo will be /dev/disk/by-label/foo.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] reexec fails in latest git

[Dave Reisner]

'systemctl daemon-reexec' fails on recent builds at HEAD. A second
reexec successfully reconnects to the bus. Relevant bits from the
journal:

 first reexec
Dec 10 12:01:04 rampage systemd[1]: Reexecuting.
Dec 10 12:01:04 rampage systemd[1]: systemd 208 running in system mode
Dec 10 12:01:04 rampage systemd[1]: Failed to register name: File exists
Dec 10 12:01:04 rampage systemd[1]: Failed to set up API bus: File exists
Dec 10 12:01:04 rampage systemd[1]: Failed to register Manager vtable: File 
exists
Dec 10 12:01:04 rampage systemd[1]: Failed to set up API bus: File exists
 second reexec
Dec 10 12:01:08 rampage systemd[1]: Reexecuting.
Dec 10 12:01:08 rampage systemd[1]: systemd 208 running in system mode

Perhaps some sort of serialization issue on the teardown side of the
re-exec?

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

Re: [systemd-devel] [PATCH] util: don't consider trailing whitespaces as an empty string in split_quoted

[Dave Reisner]

On Wed, Nov 27, 2013 at 06:45:06PM +0100, Tom Gundersen wrote:
 On Wed, Nov 27, 2013 at 6:00 PM, Lukas Nykryn lnyk...@redhat.com wrote:
  ---
   src/shared/util.c | 4 +++-
   1 file changed, 3 insertions(+), 1 deletion(-)
 
  diff --git a/src/shared/util.c b/src/shared/util.c
  index 3a4d196..c68ab09 100644
  --- a/src/shared/util.c
  +++ b/src/shared/util.c
  @@ -383,7 +383,9 @@ char *split_quoted(const char *c, size_t *l, char 
  **state) {
 
   current += strspn(current, WHITESPACE);
 
  -if (*current == '\'') {
  +if (*current == 0)
  +return NULL;
  +else if (*current == '\'') {
   current ++;
 
   for (e = current; *e; e++) {
  --
  1.8.3.1
 
 Dave,
 
 Is this the proper fix to the /proc/cmdline bug you told me about some
 time ago? What happened to that in the end?
 
 -t

Oh, interesting... Yeah, this looks like it would. I suppose da66338e1
could be reverted if this is merged.

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

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

[Dave Reisner]

On Tue, Nov 26, 2013 at 12:40:05AM +0100, Lennart Poettering wrote:
 On Mon, 25.11.13 15:20, Dave Reisner (dreis...@kemper.freedesktop.org) wrote:
 
  uint64_t can be formatted correctly with %ju, rather than casting to
  unsigned and potentially losing accuracy.
 
 Oh, shouldn't we be careful with that? %j is for intmax_t. Which might
 or might not be int64_t. Given that int128_t is already on the horizon
 (newer gcc already support __int128 on 64bit machines...), I wouldn't be
 surprised if intmax_t is growing to 128bit eventually.

How do you change sizeof(uintmax_t) without breaking ABI?

 Format strings don't really have a nice way to print fixed-size
 integers I fear... the only stuff that is correct is the PRIu64 macro,
 but that's fricking ugly...
 
 I think PRIu64 is still a better, more future-proof option than %j though...

Assuming uintmax_t really does increase in size, no type promotion, and
someone actually manages to conjure up a system with 4 billion
interfaces...
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] build: lookup for the mount binary

[Dave Reisner]

On Wed, Oct 30, 2013 at 03:27:06PM -0300, Cristian Rodríguez wrote:
 El mié 30 oct 2013 15:18:48 CLST, Tom Gundersen escribió:
  On Wed, Oct 30, 2013 at 7:12 PM, Cristian Rodríguez
  crrodrig...@opensuse.org wrote:
  Real executable might be in /usr and not in /bin
 
  I'm not against the patch, but the justification seems lacking... Does
  anyone actually do this? I.e., have a mount that is not symlinked to
  by /bin/mount?
 
 I am not aware of anyone not having a symlink to /bin/mount.. however, 
 when creating an initrd with dracut the symlink is not included (only 
 the real binary is at /usr/bin/mount) and mounting stuff breaks.

I think Tom meant that /bin would be a symlink to /usr/bin, which
implicitly links /bin/mount to /usr/bin/mount.

 It is either this patch or I should send a patch to dracut instead :-)

If Dracut doesn't create the above symlink, it really needs to. Or, it
needs to install mount in the right place. I'm curious why you'd be
the first person to report such a failure.

 In any case, from my perspective this is the right thing to do anyway.
 
 --
 Any real systematist (or scientist in general) has to be ready to 
 heave all that he or she has believed in, consider it crap, and move 
 on, in the face of new evidence. That is how we differ from clerics.
 
 ___
 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