Re: [systemd-devel] Starting ssh from a systemd service

[Mike Gilbert]

On Tue, Feb 14, 2023 at 5:31 PM Thomas Köller  wrote:
>
> I cannot start the 'ssh' command from a systemd service. A very simple
> service file demonstrates the problem:

Your test service works fine for me on Gentoo Linux.

I would guess execution is being blocked by something like AppArmor or SELinux.

Re: [systemd-devel] networkd: Link local static IP address behind NAT

[Mike Gilbert]

On Wed, Jan 18, 2023 at 9:12 AM Thomas Burghout
 wrote:
>
> On 18.01.20233 04:06, Andrei Borzenkov wrote:
> > On 17.01.2023 18:28, Thomas Burghout wrote:
> > >  inet 169.254.146.171/16 brd 169.254.255.255 scope link eth0
> >
> > Is it output from the correct system? Because address is different. I do
> > not see how "ping -I 169.254.1.2" can work with this.
>
> That is unfortunate, I copied the wrong notes indeed. Apologies. The
> following output should completely describe the configuration of the
> system:
>
>
> $ cat /usr/lib/systemd/network/10-lan.network
> [Match]
> Name=eth0
>
> [Network]
> Address=169.254.1.2/16
> DNS=169.254.1.1
> Gateway=169.254.1.1

Maybe move Address=169.254.1.2/16 to an Address section with
Scope=global. For example:

[Address]
Address=169.254.1.2/16
Scope=global

Re: [systemd-devel] systemd-networkd not sending periodic router advertisements

[Mike Gilbert]

On Sat, Oct 8, 2022 at 10:55 AM Marcel Menzel  wrote:
>
> Hello List,
>
> after switching from radvd to systemd-networkd for router advertisements, I 
> noticed my Android device losing IPv6 connection after a while and not 
> displaying any IPv6 Addresses anymore in the network overview.
>
> I am aware with IPv6 issues on Android on certain vendors / ROMs, but after 
> trying to troubleshoot it, I noticed systemd-networkd not sending periodic 
> router advertisements into my network compared to radvd.
>
> In radvd, there's the MinRtrAdvInterval and MaxRtrAdvInterval config option, 
> whileas for systemd-networkd I wasn't able to find any of these options. 
> Trying to adjust timers for PreferredLifetimeSec, ValidLifetimeSec or 
> RouterLifetimeSec I still wasn't able to get networkd to send out periodic 
> RAs (either with the defaults or my own values).
>
> There will only be sent a router advertisement for client initiated router 
> solicitations, like with the rdisc6 tool. I confirmed this with radvdump and 
> tcpdump. As soon as I re-start radvd, IPv6 Adresses re-appear on my Android 
> device. Multicast snooping has been disabled on all of my bridges. My 
> sd-networkd .network config file for one bridge looks like this:
>
> [Match]
> Name=br0
>
> [Network]
> Address=fe80::1/64
> Address=2a0f:85c1:beef:2031::/64
> IPv6AcceptRA=false
> IPv6SendRA=yes
> IPv6PrivacyExtensions=no
>
> [IPv6SendRA]
> RouterLifetimeSec = 60
> EmitDNS = yes
> DNS = fd00:0:0:10::4
> EmitDomains = no
>
> [IPv6Prefix]
> Prefix=2a0f:85c1:beef:2031::/64
> PreferredLifetimeSec=60
> ValidLifetimeSec=300
>
> Did I miss an option for enabling periodic RAs or isn't there simply a way to 
> achieve this?`

systemd-networkd sends periodic RAs on my home network. I am running
systemd-251.5.

The period is not directly configurable. It basically picks a random
number between 200 and 600 seconds by default. However, this time can
be reduced to as little as 4 seconds by setting RouterLifetimeSec to
some low value.

I have IPv6SendRA enabled directly on an ethernet interface; I wonder
if there is some conflict with trying to enable it on a bridge.
Perhaps you need to set the proper scope for your manually assigned
link-local address? Something like:

[Address]
Address=fe80::1/64
Scope=link

Re: [systemd-devel] Dropping split-usr/unmerged-usr support

[Mike Gilbert]

On Thu, Jul 7, 2022 at 9:41 AM Luca Boccassi  wrote:
>
> On Fri, 2022-04-08 at 00:48 +0200, Jason A. Donenfeld wrote:
> > Hi Wol,
> >
> > On Fri, Apr 8, 2022 at 12:02 AM Wol  wrote:
> > >
> > > On 07/04/2022 17:47, Mike Gilbert wrote:
> > > > > So, my guess would be that the people who dislike merged-/usr are also
> > > > > the ones who dislike systemd, no? i.e. do they really matter if we are
> > > > > talking about what to support in systemd? They'd not use our stuff
> > > > > anyway, so why bother?
> > >
> > > There's probably also a big minority of users (like me) who may be
> > > pro-systemd, but run a systemd-hostile distro for reasons that are
> > > nothing to do with systemd ...
> > >
> > > > There's probably a large overlap between users who don't like systemd
> > > > and users who don't like merged-/usr. I would guess we don't have a
> > > > critical mass of users/developers running systemd.
> > > >
> > > > I could probably force the users who do run systemd to migrate to
> > > > merged-/usr, but I don't really see much benefit from that if all
> > > > other packages in Gentoo still need to support both configurations.
> > >
> > > And I'm sorry if I upset Mike, but I class gentoo as systemd-hostile.
> > > It's MUCH easier to install/run Gentoo with OpenRC, systemd isn't that
> > > well documented (it's better than it was). There are people who support
> > > systemd, but I get the impression it's seen as an unwanted rival to 
> > > OpenRC.
> >
> > I was actually just talking about merged usr with some people in
> > #gentoo-dev the other day. I was at first wondering, "hey have we done
> > this? what's the hold up?" And the answer seemed to be that nobody has
> > really got around to it, and there's not currently a huge champion of
> > the project moving it forward. Somebody piped up kind of mildly
> > opposed, and then I explained what the general vision for merged usr
> > is (hermetic OS in /usr and such), and felt like the reception to that
> > was actually somewhat welcoming. Later I posted a link to Lennart's
> > latest blog post, and people seemed to think it was cool. Somebody
> > mentioned they were going to try out merged usr on Gentoo to see what
> > happened, and another person mentioned they were the author of a blog
> > post tutorial on how to do it.
> >
> > A few conversations over the course of the day in an IRC channel isn't
> > necessarily representative of the whole project, but the impression I
> > got was way less so about hostility and more so just that nobody has
> > gotten around to doing the work and tracking whatever bugs come out of
> > it that need to be fixed. It's been started, but seems to have
> > fizzled. Maybe the recent discussion here and funny happenings over in
> > Debian will inject some life into it. So maybe we'll wind up with
> > merged usr after all. No promises, but I think it's much more a matter
> > of "when" than "if".
> >
> > (My personal 2¢ is that I'd be happy to see systemd help corral us
> > stragglers into merged usr, and in the process, drop some complexity
> > of its own for supporting unmerged usr.)
> >
> > Jason
>
> Any update on this topic? The changes to move to usr-merged have been
> merged for OpenMandriva 5.0:
> https://github.com/OpenMandrivaAssociation/distribution/issues/2792
>
> This means Gentoo is the last holdout where this isn't possible, even
> just optionally. Is it possible to find a Gentoo developer who would
> like to take this on? It doesn't have to be universal, having it merged
> only for installations running systemd would be perfectly fine. As
> mentioned in the thread, the scripts to move an installation forward
> and back exist and should be pretty generalistic, and require some
> adaptations but no major overhaul.

I'll work on a migration path for Gentoo systems running systemd. I
think we could get it done before the end of the year.

Re: [systemd-devel] killmode

[Mike Gilbert]

On Fri, May 20, 2022 at 1:34 PM Mike Gilbert  wrote:
>
> On Fri, May 20, 2022 at 12:54 PM Pascal  wrote:
> >
> > not really in the sense that qemu-nbd launches and immediately gives the 
> > hand back to the script that called it.
> > the script ends positively and qemu-nbd is killed by systemd because it is 
> > considered to be garbage left behind by the script.
> > this is not quite the case of a timeout that systemd terminates, but the 
> > result is the same.
> > in this case, qemu-nbd looks more like a daemon.
> >
> > I was wondering if there was a way to propagate the killmode through a udev 
> > rule that starts a script (like a service)... but it seems from the 
> > documentation that the answer is no :-(
> >
> > """In order to activate long-running processes from udev rules, provide a 
> > service unit and pull it in from a udev device using the SYSTEMD_WANTS 
> > device property. See systemd.device(5) for details."""
> > I would appreciate (and maybe I won't be the only one) a concrete example 
> > based, for example,  on my problem ;-)
> >
> > let's just say that my rule is :
> >
> > KERNEL=="sdb", RUN+="/usr/local/sbin/myscript"
> >
> > and my script is :
> >
> > #!/usr/bin/bash
> > qemu-nbd -r -s -f raw -c /dev/nbd0 /dev/sdb
>
> The most direct translation would be something like this:
>
> qemu-nbd0-sdb.service:
> [Service]
> ExecStart=qemu-nbd -r -s -f raw -c /dev/nbd0 /dev/sdb
>
> udev rule:
> KERNEL=="sdb", ENV{SYSTEMD_WANTS}+="qemu-nbd0-sdb.service"

Oh, you'll want to add Type=forking to the .service file if it always
forks a child and exits.

Re: [systemd-devel] killmode

[Mike Gilbert]

On Fri, May 20, 2022 at 12:54 PM Pascal  wrote:
>
> not really in the sense that qemu-nbd launches and immediately gives the hand 
> back to the script that called it.
> the script ends positively and qemu-nbd is killed by systemd because it is 
> considered to be garbage left behind by the script.
> this is not quite the case of a timeout that systemd terminates, but the 
> result is the same.
> in this case, qemu-nbd looks more like a daemon.
>
> I was wondering if there was a way to propagate the killmode through a udev 
> rule that starts a script (like a service)... but it seems from the 
> documentation that the answer is no :-(
>
> """In order to activate long-running processes from udev rules, provide a 
> service unit and pull it in from a udev device using the SYSTEMD_WANTS device 
> property. See systemd.device(5) for details."""
> I would appreciate (and maybe I won't be the only one) a concrete example 
> based, for example,  on my problem ;-)
>
> let's just say that my rule is :
>
> KERNEL=="sdb", RUN+="/usr/local/sbin/myscript"
>
> and my script is :
>
> #!/usr/bin/bash
> qemu-nbd -r -s -f raw -c /dev/nbd0 /dev/sdb

The most direct translation would be something like this:

qemu-nbd0-sdb.service:
[Service]
ExecStart=qemu-nbd -r -s -f raw -c /dev/nbd0 /dev/sdb

udev rule:
KERNEL=="sdb", ENV{SYSTEMD_WANTS}+="qemu-nbd0-sdb.service"

Re: [systemd-devel] killmode

[Mike Gilbert]

On Fri, May 20, 2022 at 10:51 AM Pascal  wrote:
> it is not strictly speaking a long-running process but it is a child who 
> survives his father and who is killed when his father stops living 
> successfully ! what a strange world these children live in... ;-)

Sorry, I missed this last line. Are you sure it isn't long-running? It
really makes no sense for it to fork this way.

Re: [systemd-devel] killmode

[Mike Gilbert]

On Fri, May 20, 2022 at 10:51 AM Pascal  wrote:
>
> hi,
>
> is it possible to influence the killmode of a script launched by an udev rule 
> ?
>
> I have a udev rule that starts a script that itself starts qemu-nbd that gets 
> killed once the script is finished (qemu-nbd links a block device to an nbd 
> node).
>
> it is not strictly speaking a long-running process but it is a child who 
> survives his father and who is killed when his father stops living 
> successfully ! what a strange world these children live in... ;-)

Quoting the udev(7) man page:

https://www.freedesktop.org/software/systemd/man/udev.html#RUN%7Btype%7D

"Starting daemons or other long-running processes is not allowed; the
forked processes, detached or not, will be unconditionally killed
after the event handling has finished. In order to activate
long-running processes from udev rules, provide a service unit and
pull it in from a udev device using the SYSTEMD_WANTS device property.
See systemd.device(5) for details."

Re: [systemd-devel] [RFC] Switching to OpenSSL 3?

[Mike Gilbert]

On Tue, May 17, 2022 at 2:53 PM Luca Boccassi  wrote:
>
> On Sat, 9 Oct 2021 at 19:11, Luca Boccassi  wrote:
> >
> > On Wed, 2021-09-29 at 18:11 +0100, Luca Boccassi wrote:
> > > On Wed, 2021-09-15 at 16:06 +0100, Luca Boccassi wrote:
> > > > On Tue, 2021-09-14 at 13:36 +0200, Lennart Poettering wrote:
> > > > > Heya!
> > > > >
> > > > > Some of the systemd developers have been discussing switching
> > > > > systemd's crypto libraries to be exclusively OpenSSL 3.0, and
> > > > > drop
> > > > > support for older OpenSSL versions, as well as any
> > > > > GNUTLS/libgcrypt
> > > > > support. As you might have noticed OpenSSL 3.0 has been released
> > > > > recently, and for the first time resolves the GPL2 license
> > > > > incompatibility mess comprehensively, which opens this door to
> > > > > us.
> > > > >
> > > > > I personally care a lot about reducing the combinatorial
> > > > > explosion of
> > > > > deps a bit, and keeping our tree as maintainable as we can, with
> > > > > a
> > > > > single implementation of everything, not multiple, and no
> > > > > abstraction
> > > > > layers and such, and thus removing any compat kludges for other
> > > > > libraries or other library versions.
> > > > >
> > > > > Now, before we make a decision on this, I'd like to collect
> > > > > feedback
> > > > > on such a move. I know that there are some people who backpart
> > > > > new
> > > > > systemd onto old distros. How big would the pain be require
> > > > > porting
> > > > > OpenSSL 3, too, at the same time?
> > > > >
> > > > > (What's not up for discussion: for new additions to systemd we'll
> > > > > do
> > > > > only OpenSSL, and won't accept anything else. My question is
> > > > > really
> > > > > just about the stuff we aleady have, where we currently support
> > > > > GNUTLS/libcgrypt.).
> > > > >
> > > > > Anyway, I'd be interested in your thoughts about this. i.e. hear
> > > > > multiple takes, opinions, from differently people and positions?
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Lennart
> > > >
> > > > To summarize in public what we discussed elsewhere:
> > > >
> > > > - OpenSSL 3 is licensed under Apache2 which is compatible with
> > > > GPLv3
> > > > but believed by many to be incompatible with GPLv2
> > > > - systemd is mostly (L)GPLv2+, with no specific OpenSSL exception
> > > > clauses
> > > > - distributors of the built and linked binaries can safely and
> > > > without
> > > > any reasonable doubt get over the perceived incompatibility by
> > > > declaring that the  GPLv2+ binaries linked to OpenSSL are
> > > > distributed
> > > > under GPLv3
> > > >
> > > > The issue of course is with the "mostly" keyword. There are many
> > > > compat-headers backported from Linux UAPI headers, but they are
> > > > covered
> > > > by the Linux syscall-note exception so they explicitly do not
> > > > affect
> > > > the license of the binaries built with them.
> > > > There are however three GPLv2-only headers with no exceptions
> > > > currently
> > > > included in all builds:
> > > >
> > > > - src/basic/ioprio.h which is in the process of being removed via
> > > > https://github.com/systemd/systemd/pull/20736
> > > > - src/basic/linux/loadavg.h which is copied from
> > > > https://github.com/torvalds/linux/blob/master/include/linux/sched/loadavg.h
> > > > - src/shared/linux/bpf_insn.h which is copied from
> > > > https://github.com/torvalds/linux/blob/master/samples/bpf/bpf_insn.h
> > > >
> > > > The third one to me seems the most problematic one, as it's fairly
> > > > complex and thus is unlikely to be perceived universally as exempt
> > > > from
> > > > copyright. It is very annoying as it is clearly a "sample" source
> > > > file,
> > > > which usually is intended to be reused liberally, and originally it
> > > > was
> > > > without a license and was given GPLv2-only when the big SPDX
> > > > refactor
> > > > happened. There are 5 companies or so holding copyright on that
> > > > file,
> > > > so perhaps a quick avenue would be to seek their permission to dual
> > > > license it? BPF support in systemd is of course optional, so it
> > > > could
> > > > instead be disabled everywhere so that the header is excluded at
> > > > build
> > > > time, but it would be quite unfortunate
> > >
> > > Status update: all these issues have been solved. The first two
> > > headers
> > > have been removed, and the third one has been dual-licensed upstream.
> > >
> > > https://github.com/systemd/systemd/pull/20736
> > > https://github.com/systemd/systemd/pull/20839
> > > https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=d75fe9cb1dd062684c9fb8a4581738170365dc06
> > >
> > > Therefore, we can say with certainty and no doubt whatsoever that
> > > systemd binaries can be distributed under (L)GPL-2-or-later and thus
> > > be
> > > compatible with Apache2, enabling linking with OpenSSL 3.
> > >
> > > The current plan is to avoid linking libsystemd.so to OpenSSL, so
> > > that
> > > the license of this 

Re: [systemd-devel] Dropping split-usr/unmerged-usr support

[Mike Gilbert]

On Thu, Apr 7, 2022 at 5:18 AM Luca Boccassi  wrote:
>
> On Thu, 2022-04-07 at 10:59 +0200, Lennart Poettering wrote:
> > On Mi, 06.04.22 11:24, Mike Gilbert (flop...@gentoo.org) wrote:
> >
> > > We are not likely to require merging of / and /usr for the foreseeable
> > > future. We are a "rolling release" distro and basically never require
> > > our users to re-install, which makes large file system migrations
> > > difficult. Also, many of our users would resist any attempt to force
> > > merged-/usr on them.
> >
> > So, my guess would be that the people who dislike merged-/usr are also
> > the ones who dislike systemd, no? i.e. do they really matter if we are
> > talking about what to support in systemd? They'd not use our stuff
> > anyway, so why bother?
> >
> > > I think it would be ok if systemd drops support for installing itself
> > > in /lib/systemd; we would just move everything under /usr/lib/systemd,
> > > and possibly set up some symlinks in /lib/systemd for the
> > > transition.
> >
> > You guys are making your life hell, because you are afraid if making
> > it difficult...
> >
> > Lennart
>
> And regarding re-installing, Ubuntu and Debian are doing the transition
> on the live filesystem, no reinstall required (I think other distros
> did the same). You can find the script that does it in this repository:
> https://salsa.debian.org/md/usrmerge apart from details about multi-
> arch lib directories, it should be adaptable to other distributions.

Thanks for the link!

Re: [systemd-devel] Dropping split-usr/unmerged-usr support

[Mike Gilbert]

On Thu, Apr 7, 2022 at 4:59 AM Lennart Poettering  wrote:
>
> On Mi, 06.04.22 11:24, Mike Gilbert (flop...@gentoo.org) wrote:
>
> > We are not likely to require merging of / and /usr for the foreseeable
> > future. We are a "rolling release" distro and basically never require
> > our users to re-install, which makes large file system migrations
> > difficult. Also, many of our users would resist any attempt to force
> > merged-/usr on them.
>
> So, my guess would be that the people who dislike merged-/usr are also
> the ones who dislike systemd, no? i.e. do they really matter if we are
> talking about what to support in systemd? They'd not use our stuff
> anyway, so why bother?

There's probably a large overlap between users who don't like systemd
and users who don't like merged-/usr. I would guess we don't have a
critical mass of users/developers running systemd.

I could probably force the users who do run systemd to migrate to
merged-/usr, but I don't really see much benefit from that if all
other packages in Gentoo still need to support both configurations.

Re: [systemd-devel] Dropping split-usr/unmerged-usr support

[Mike Gilbert]

On Tue, Apr 5, 2022 at 4:07 PM Luca Boccassi  wrote:
>
> Hi,
>
> As part of our spring cleaning effort, we are considering when to drop
> support for split/unmerged-usr filesystem layouts.
>
> A build-time warning was added last year:
>
> https://github.com/systemd/systemd/commit/9afd5e7b975e8051c011ff9c07c95e80bd954469
>
> We are now adding a runtime taint as well.
>
> Which distributions are left running with systemd on a split/unmerged-
> usr system?

Gentoo still supports having /{bin,sbin,lib} and /usr/{bin,sbin,lib}
as separate directories. We do not support officially booting without
/usr mounted (via initramfs), but some users do it anyway.

We are not likely to require merging of / and /usr for the foreseeable
future. We are a "rolling release" distro and basically never require
our users to re-install, which makes large file system migrations
difficult. Also, many of our users would resist any attempt to force
merged-/usr on them.

I think it would be ok if systemd drops support for installing itself
in /lib/systemd; we would just move everything under /usr/lib/systemd,
and possibly set up some symlinks in /lib/systemd for the transition.

We will still need to keep /bin and /sbin in PATH, and we can't assume
that all binaries reside in /usr/bin.

Re: [systemd-devel] asset failure that looks like it's coming from systemd/

[Mike Gilbert]

On Thu, Dec 23, 2021 at 8:54 PM Jonathan Kelly  wrote:
>
> Hi,
>
> in trying to compile unicon programming language - I'm on arch linux ...
>
> Linux arch 5.15.10-arch1-1 #1 SMP PREEMPT Fri, 17 Dec 2021 11:17:37
> + x86_64 GNU/Linux
>
>   ... I'm getting this error
>
> make[2]: Entering directory '/usr/local/src/unicon/uni/lib'
> ../../bin/unicon -s -c gui.icn
> Assertion '(size_t) r < n' failed at src/basic/random-util.c:232,
> function genuine_random_bytes(). Aborting.
> make[2]: *** [../../Makedefs.uni:48: gui.u] Aborted (core dumped)
>
>
> does anyone have any clues as to what is going on, and/or how to resolve
> the issue?

I would suggest running "../../bin/unicon -s -c gui.icn" in gdb to get
a backtrace. That will help determine exactly what code is calling
this function.

Re: [systemd-devel] [RFC] Switching to OpenSSL 3?

[Mike Gilbert]

On Tue, Sep 14, 2021 at 7:36 AM Lennart Poettering
 wrote:
>
> Heya!
>
> Some of the systemd developers have been discussing switching
> systemd's crypto libraries to be exclusively OpenSSL 3.0, and drop
> support for older OpenSSL versions, as well as any GNUTLS/libgcrypt
> support. As you might have noticed OpenSSL 3.0 has been released
> recently, and for the first time resolves the GPL2 license
> incompatibility mess comprehensively, which opens this door to us.
>
> I personally care a lot about reducing the combinatorial explosion of
> deps a bit, and keeping our tree as maintainable as we can, with a
> single implementation of everything, not multiple, and no abstraction
> layers and such, and thus removing any compat kludges for other
> libraries or other library versions.
>
> Now, before we make a decision on this, I'd like to collect feedback
> on such a move. I know that there are some people who backpart new
> systemd onto old distros. How big would the pain be require porting
> OpenSSL 3, too, at the same time?
>
> (What's not up for discussion: for new additions to systemd we'll do
> only OpenSSL, and won't accept anything else. My question is really
> just about the stuff we aleady have, where we currently support
> GNUTLS/libcgrypt.).
>
> Anyway, I'd be interested in your thoughts about this. i.e. hear
> multiple takes, opinions, from differently people and positions?

I would definitely like to be able to depend on one crypto/TLS
implementation that would cover all features in systemd, instead of
having to depend on OpenSSL for some features, and GnuTLS for other
features. The current situation is quite messy.

Settling on OpenSSL sounds fine to me.

It will probably take a few months for Gentoo to get fully upgraded to
OpenSSL 3.0. Here is our tracker for that:

https://bugs.gentoo.org/797325

Do you have a target date/milestone in mind for introducing this
dependency in systemd?

Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked

[Mike Gilbert]

On Tue, Feb 9, 2021 at 7:19 PM Mike Gilbert  wrote:
>
> On Tue, Feb 9, 2021 at 7:05 PM Reindl Harald  wrote:
> >
> >
> >
> > Am 09.02.21 um 23:18 schrieb Mike Gilbert:
> > > On Tue, Feb 9, 2021 at 11:47 AM Reindl Harald  
> > > wrote:
> > >>
> > >>
> > >>
> > >> Am 09.02.21 um 17:13 schrieb Mike Gilbert:
> > >>> On Tue, Feb 9, 2021 at 6:17 AM Reindl Harald  
> > >>> wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>> Am 08.02.21 um 23:42 schrieb Mike Gilbert:
> > >>>>> On Mon, Feb 8, 2021 at 2:31 PM Reindl Harald  
> > >>>>> wrote:
> > >>>>>>> I think removing this symlink would prevent /sys/fs/fuse/connections
> > >>>>>>> from being mounted and the fuse module from being loaded
> > >>>>>>> unconditionally on boot
> > >>>>>>
> > >>>>>> no
> > >>>>>>
> > >>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1909805#c6
> > >>>>>
> > >>>>> It almost works for me on Gentoo Linux.
> > >>>>> To test, I first had to reconfigure my kernel to build FUSE as a
> > >>>>> module (I normally have it built-in).
> > >>>>> I then removed the sys-fs-fuse-connections.mount symlink from
> > >>>>> sysinit.target.wants.
> > >>>>> After rebooting with the new kernel, the FUSE module is not loaded and
> > >>>>> /sys/fs/fuse/connections is not mounted.
> > >>>>>
> > >>>>> Unfortunately, mounting FUSE-based file systems does not work until I
> > >>>>> manually run "modprobe fuse".
> > >>>>> It seems that my kernel does not auto-load the module, despite the
> > >>>>> static /dev/fuse node. The kernel is probably missing a call to
> > >>>>> __request_module().
> > >>>>>
> > >>>>> Given that the kernel doesn't auto-load the module on demand, leaving
> > >>>>> the sysinit.target.wants symlink in place seems like the safe thing to
> > >>>>> do.
> > >>>>
> > >>>> but for sure not on a stripped down machine running a iptables-nft
> > >>>> ruleset, a socket-activated sshd and nohting else
> > >>>>
> > >>>> if it's me for server setups the "fuse" kernel-module could be in
> > >>>> "kernel-modules" which is not installed and needed for virtualized 
> > >>>> guests
> > >>>>
> > >>>> the point is that all this setups where happy without fuse loaded from
> > >>>> 2008 to 2021 and you can't even avoid it with F33 at all, no matter 
> > >>>> what
> > >>>> you delete or mask
> > >>>>
> > >>>> a active masked unit - seriously? :-)
> > >>>>
> > >>>> [root@rawhide ~]# systemctl status sys-module-fuse.device
> > >>>> sys-fs-fuse-connections.mount
> > >>>> ● sys-module-fuse.device - /sys/module/fuse
> > >>>> Loaded: masked (Reason: Unit sys-module-fuse.device is masked.)
> > >>>> Active: active (plugged) since Mon 2021-02-08 19:33:18 CET; 
> > >>>> 1min
> > >>>> 42s ago
> > >>>> Device: /sys/module/fuse
> > >>>
> > >>> I think something else on your system is loading the fuse kernel
> > >>> module, which activates sys-module-fuse.device, and tries to start
> > >>> sys-fs-fuse-connections.mount. It appears systemd doesn't really
> > >>> support masking device units, which are generated by udev events.
> > >>>
> > >>> You should probably try to track down exactly what else is loading the
> > >>> fuse module, and disable that.
> > >>
> > >> this is a bare setup with *nothing* enabled at all
> > >
> > > Off the top of my head, maybe fuse is getting loaded by an entry in
> > > modules-load.d.
> >
> > no
> >
> > [root@rawhide ~]# ls /etc/modules-load.d/
> > total 0
> >
> > > Also, vmware tools might utilize FUSE in some way.
> >
> > no
> >
> > [root@rawhide ~]# system-errors.sh
> > Fe

Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked

[Mike Gilbert]

On Tue, Feb 9, 2021 at 7:05 PM Reindl Harald  wrote:
>
>
>
> Am 09.02.21 um 23:18 schrieb Mike Gilbert:
> > On Tue, Feb 9, 2021 at 11:47 AM Reindl Harald  
> > wrote:
> >>
> >>
> >>
> >> Am 09.02.21 um 17:13 schrieb Mike Gilbert:
> >>> On Tue, Feb 9, 2021 at 6:17 AM Reindl Harald  
> >>> wrote:
> >>>>
> >>>>
> >>>>
> >>>> Am 08.02.21 um 23:42 schrieb Mike Gilbert:
> >>>>> On Mon, Feb 8, 2021 at 2:31 PM Reindl Harald  
> >>>>> wrote:
> >>>>>>> I think removing this symlink would prevent /sys/fs/fuse/connections
> >>>>>>> from being mounted and the fuse module from being loaded
> >>>>>>> unconditionally on boot
> >>>>>>
> >>>>>> no
> >>>>>>
> >>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1909805#c6
> >>>>>
> >>>>> It almost works for me on Gentoo Linux.
> >>>>> To test, I first had to reconfigure my kernel to build FUSE as a
> >>>>> module (I normally have it built-in).
> >>>>> I then removed the sys-fs-fuse-connections.mount symlink from
> >>>>> sysinit.target.wants.
> >>>>> After rebooting with the new kernel, the FUSE module is not loaded and
> >>>>> /sys/fs/fuse/connections is not mounted.
> >>>>>
> >>>>> Unfortunately, mounting FUSE-based file systems does not work until I
> >>>>> manually run "modprobe fuse".
> >>>>> It seems that my kernel does not auto-load the module, despite the
> >>>>> static /dev/fuse node. The kernel is probably missing a call to
> >>>>> __request_module().
> >>>>>
> >>>>> Given that the kernel doesn't auto-load the module on demand, leaving
> >>>>> the sysinit.target.wants symlink in place seems like the safe thing to
> >>>>> do.
> >>>>
> >>>> but for sure not on a stripped down machine running a iptables-nft
> >>>> ruleset, a socket-activated sshd and nohting else
> >>>>
> >>>> if it's me for server setups the "fuse" kernel-module could be in
> >>>> "kernel-modules" which is not installed and needed for virtualized guests
> >>>>
> >>>> the point is that all this setups where happy without fuse loaded from
> >>>> 2008 to 2021 and you can't even avoid it with F33 at all, no matter what
> >>>> you delete or mask
> >>>>
> >>>> a active masked unit - seriously? :-)
> >>>>
> >>>> [root@rawhide ~]# systemctl status sys-module-fuse.device
> >>>> sys-fs-fuse-connections.mount
> >>>> ● sys-module-fuse.device - /sys/module/fuse
> >>>> Loaded: masked (Reason: Unit sys-module-fuse.device is masked.)
> >>>> Active: active (plugged) since Mon 2021-02-08 19:33:18 CET; 1min
> >>>> 42s ago
> >>>> Device: /sys/module/fuse
> >>>
> >>> I think something else on your system is loading the fuse kernel
> >>> module, which activates sys-module-fuse.device, and tries to start
> >>> sys-fs-fuse-connections.mount. It appears systemd doesn't really
> >>> support masking device units, which are generated by udev events.
> >>>
> >>> You should probably try to track down exactly what else is loading the
> >>> fuse module, and disable that.
> >>
> >> this is a bare setup with *nothing* enabled at all
> >
> > Off the top of my head, maybe fuse is getting loaded by an entry in
> > modules-load.d.
>
> no
>
> [root@rawhide ~]# ls /etc/modules-load.d/
> total 0
>
> > Also, vmware tools might utilize FUSE in some way.
>
> no
>
> [root@rawhide ~]# system-errors.sh
> Feb 10 00:59:22 rawhide systemd[1]: sys-module-fuse.device: Failed to
> enqueue SYSTEMD_WANTS= job, ignoring: Unit sys-fs-fuse-connections.mount
> is masked.
> [root@rawhide ~]# systemctl status vmtoolsd.service
> ● vmtoolsd.service - VMware Tools
>   Loaded: loaded (/etc/systemd/system/vmtoolsd.service; disabled;
> vendor preset: enabled)
>   Active: inactive (dead)
>
> even that file from the vmtools package was deleted long before my
> initial post of this thread
>
> [root@rawhide ~]# cat /usr/lib/systemd/system/run-vmblock\x2dfuse.mount
> cat: /usr/lib/systemd/system/run-vmblockx2dfuse.mount: No such file or
> directory
>
> > If you're unable to figure out what is loading it, you might replace
> > /sbin/modprobe with a wrapper script to log all processes that call
> > it
> there is nothing left but systemd which also don't go the normal way
> otherwise this below would prevent loading the kernel module
>
> modprobe won't load it in that case
>
> [root@rawhide ~]# cat /etc/modprobe.d/blacklist-lounge-vm.conf | grep fuse
> blacklist fuse
> install fuse /usr/bin/true
>

The blacklist is only applied if you call "modprobe -b". Possibly
something else is calling modprobe without the -b option.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked

[Mike Gilbert]

On Tue, Feb 9, 2021 at 11:47 AM Reindl Harald  wrote:
>
>
>
> Am 09.02.21 um 17:13 schrieb Mike Gilbert:
> > On Tue, Feb 9, 2021 at 6:17 AM Reindl Harald  wrote:
> >>
> >>
> >>
> >> Am 08.02.21 um 23:42 schrieb Mike Gilbert:
> >>> On Mon, Feb 8, 2021 at 2:31 PM Reindl Harald  
> >>> wrote:
> >>>>> I think removing this symlink would prevent /sys/fs/fuse/connections
> >>>>> from being mounted and the fuse module from being loaded
> >>>>> unconditionally on boot
> >>>>
> >>>> no
> >>>>
> >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1909805#c6
> >>>
> >>> It almost works for me on Gentoo Linux.
> >>> To test, I first had to reconfigure my kernel to build FUSE as a
> >>> module (I normally have it built-in).
> >>> I then removed the sys-fs-fuse-connections.mount symlink from
> >>> sysinit.target.wants.
> >>> After rebooting with the new kernel, the FUSE module is not loaded and
> >>> /sys/fs/fuse/connections is not mounted.
> >>>
> >>> Unfortunately, mounting FUSE-based file systems does not work until I
> >>> manually run "modprobe fuse".
> >>> It seems that my kernel does not auto-load the module, despite the
> >>> static /dev/fuse node. The kernel is probably missing a call to
> >>> __request_module().
> >>>
> >>> Given that the kernel doesn't auto-load the module on demand, leaving
> >>> the sysinit.target.wants symlink in place seems like the safe thing to
> >>> do.
> >>
> >> but for sure not on a stripped down machine running a iptables-nft
> >> ruleset, a socket-activated sshd and nohting else
> >>
> >> if it's me for server setups the "fuse" kernel-module could be in
> >> "kernel-modules" which is not installed and needed for virtualized guests
> >>
> >> the point is that all this setups where happy without fuse loaded from
> >> 2008 to 2021 and you can't even avoid it with F33 at all, no matter what
> >> you delete or mask
> >>
> >> a active masked unit - seriously? :-)
> >>
> >> [root@rawhide ~]# systemctl status sys-module-fuse.device
> >> sys-fs-fuse-connections.mount
> >> ● sys-module-fuse.device - /sys/module/fuse
> >>Loaded: masked (Reason: Unit sys-module-fuse.device is masked.)
> >>Active: active (plugged) since Mon 2021-02-08 19:33:18 CET; 1min
> >> 42s ago
> >>Device: /sys/module/fuse
> >
> > I think something else on your system is loading the fuse kernel
> > module, which activates sys-module-fuse.device, and tries to start
> > sys-fs-fuse-connections.mount. It appears systemd doesn't really
> > support masking device units, which are generated by udev events.
> >
> > You should probably try to track down exactly what else is loading the
> > fuse module, and disable that.
>
> this is a bare setup with *nothing* enabled at all

Off the top of my head, maybe fuse is getting loaded by an entry in
modules-load.d.

Also, vmware tools might utilize FUSE in some way.

If you're unable to figure out what is loading it, you might replace
/sbin/modprobe with a wrapper script to log all processes that call
it.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked

[Mike Gilbert]

On Tue, Feb 9, 2021 at 6:17 AM Reindl Harald  wrote:
>
>
>
> Am 08.02.21 um 23:42 schrieb Mike Gilbert:
> > On Mon, Feb 8, 2021 at 2:31 PM Reindl Harald  wrote:
> >>> I think removing this symlink would prevent /sys/fs/fuse/connections
> >>> from being mounted and the fuse module from being loaded
> >>> unconditionally on boot
> >>
> >> no
> >>
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1909805#c6
> >
> > It almost works for me on Gentoo Linux.
> > To test, I first had to reconfigure my kernel to build FUSE as a
> > module (I normally have it built-in).
> > I then removed the sys-fs-fuse-connections.mount symlink from
> > sysinit.target.wants.
> > After rebooting with the new kernel, the FUSE module is not loaded and
> > /sys/fs/fuse/connections is not mounted.
> >
> > Unfortunately, mounting FUSE-based file systems does not work until I
> > manually run "modprobe fuse".
> > It seems that my kernel does not auto-load the module, despite the
> > static /dev/fuse node. The kernel is probably missing a call to
> > __request_module().
> >
> > Given that the kernel doesn't auto-load the module on demand, leaving
> > the sysinit.target.wants symlink in place seems like the safe thing to
> > do.
>
> but for sure not on a stripped down machine running a iptables-nft
> ruleset, a socket-activated sshd and nohting else
>
> if it's me for server setups the "fuse" kernel-module could be in
> "kernel-modules" which is not installed and needed for virtualized guests
>
> the point is that all this setups where happy without fuse loaded from
> 2008 to 2021 and you can't even avoid it with F33 at all, no matter what
> you delete or mask
>
> a active masked unit - seriously? :-)
>
> [root@rawhide ~]# systemctl status sys-module-fuse.device
> sys-fs-fuse-connections.mount
> ● sys-module-fuse.device - /sys/module/fuse
>   Loaded: masked (Reason: Unit sys-module-fuse.device is masked.)
>   Active: active (plugged) since Mon 2021-02-08 19:33:18 CET; 1min
> 42s ago
>   Device: /sys/module/fuse

I think something else on your system is loading the fuse kernel
module, which activates sys-module-fuse.device, and tries to start
sys-fs-fuse-connections.mount. It appears systemd doesn't really
support masking device units, which are generated by udev events.

You should probably try to track down exactly what else is loading the
fuse module, and disable that.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked

[Mike Gilbert]

On Mon, Feb 8, 2021 at 2:31 PM Reindl Harald  wrote:
> > I think removing this symlink would prevent /sys/fs/fuse/connections
> > from being mounted and the fuse module from being loaded
> > unconditionally on boot
>
> no
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1909805#c6

It almost works for me on Gentoo Linux.
To test, I first had to reconfigure my kernel to build FUSE as a
module (I normally have it built-in).
I then removed the sys-fs-fuse-connections.mount symlink from
sysinit.target.wants.
After rebooting with the new kernel, the FUSE module is not loaded and
/sys/fs/fuse/connections is not mounted.

Unfortunately, mounting FUSE-based file systems does not work until I
manually run "modprobe fuse".
It seems that my kernel does not auto-load the module, despite the
static /dev/fuse node. The kernel is probably missing a call to
__request_module().

Given that the kernel doesn't auto-load the module on demand, leaving
the sysinit.target.wants symlink in place seems like the safe thing to
do.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sys-module-fuse.device: Failed to enqueue SYSTEMD_WANTS= job, ignoring: Unit modprobe@fuse.service is masked

[Mike Gilbert]

On Mon, Feb 8, 2021 at 1:01 PM Reindl Harald  wrote:
>
>
>
> Am 08.02.21 um 18:27 schrieb Lennart Poettering:
> > On So, 07.02.21 22:43, Reindl Harald (h.rei...@thelounge.net) wrote:
> >
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1909805
> >
> > In response to your actual issue, ignoring all the nasty wording:
> >
> > Masking is a last resort thing, you really want to use that only after
> > having investigated everything. You use it here anyway to mask out a
> > really low-level system thing, hence you might get warnings about
> > this.
> >
> > You can of course mask sys-fs-fuse-connections.mount too
> who needs anything related to fuse at every boot?
> fuse is nothing in common used
> fuse is not used unconditional
>
> directly after boot on a server-vm with no fuse business
>
> [root@testserver:~]$ lsmod | grep fuse
> fuse  163840  1
>
> my only usecase on 50 machines is every few weeks fuse.sshfs abd what
> makes people nasty is that for months nobody responds to systemd related
> issues in the Fedora bugracker
>
> if something is usiong fuse it happily loads the kernel module on-demand
> for years

Looking into this a bit closer, it looks like systemd installs a symlink:

/usr/lib/systemd/system/sysinit.target.wants/sys-fs-fuse-connections.mount
-> ../sys-fs-fuse-connections.mount

I think removing this symlink would prevent /sys/fs/fuse/connections
from being mounted and the fuse module from being loaded
unconditionally on boot.

As well, udev installs a couple of relevant rules (50-default.rules,
99-systemd.rules):

KERNEL=="fuse", MODE="0666", OPTIONS+="static_node=fuse"

# Asynchronously mount file systems implemented by these modules as
soon as they are loaded.
SUBSYSTEM=="module", KERNEL=="fuse", TAG+="systemd",
ENV{SYSTEMD_WANTS}+="sys-fs-fuse-connections.mount"

I think these rules should take care of providing a static /dev/fuse
node to allow module auto-loading, and should cause
/sys/fs/fuse/connections to be mounted on-demand.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] 99-default.link which such a high number ?

[Mike Gilbert]

On Fri, Sep 25, 2020 at 10:46 AM Francis Moreau  wrote:
>
> Hello,
>
> I want to override /usr/lib/systemd/network/99-default.link so I need
> to create a file starting with "99-" prefix.
>
> This doesn't seem logical to me because the numbers are supposed to
> encode the priority however nothing is left to the user if the
> defaults used is 99.
>
> I find more logical for the defaults to use a small number such as 10.
>
> What am I missing ?

To quote systemd.link(5):

"The first (in lexical order) of the link files that matches a given
device is applied."

So, lower numbered files take priority over higher numbered files,
assuming the device is matched.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Upstreaming systemd patch

[Mike Gilbert]

On Fri, Jul 10, 2020 at 10:43 AM Amit anand  wrote:
>
> Hi systemd-devel group,
>
>
> I need to upstream systemd git patch for fixing systemd static code analysis 
> warnings.
>
> Can you please suggest me the correct mailgroup to send the git patch or 
> relevant web url which have information to upstream git patch.

Fork this github repository and submit a pull request.

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

Re: [systemd-devel] systemctl restart changes permission.

[Mike Gilbert]

On Thu, Apr 30, 2020 at 12:05 AM Kaushal Shriyan
 wrote:
>
> Hi,
>
> I am running CentOS Linux release 7.8.2003 (Core) with 
> php72u-fpm-7.2.30-1.el7.ius.x86_64 version. I am facing the below permission 
> denied issue. I also did the below steps
> #cd /run
> #chown -Rc nginx.nginx php-fpm
> changed ownership of ‘php-fpm/php-fpm.pid’ from root:root to nginx:nginx
> changed ownership of ‘php-fpm’ from root:root to nginx:nginx
> #systemctl restart php-fpm again changes it from nginx.nginx to root.root 
> user.
>
>
>> nginx error logs
>> 2020/04/30 03:09:28 [crit] 17175#0: *154570 connect() to 
>> unix:/run/php-fpm/www.sock failed (13: Permission denied) while connecting 
>> to upstream, client: 49.207.54.161, server: _, request: "GET / HTTP/1.1", 
>> upstream: "fastcgi://unix:/run/php-fpm/www.sock:", host: "35.128.212.112"
>> 2020/04/30 03:09:28 [error] 17175#0: *154570 open() 
>> "/var/www/drupal/web/50x.html" failed (2: No such file or directory), 
>> client: 49.207.54.161, server: _, request: "GET / HTTP/1.1", upstream: 
>> "fastcgi://unix:/run/php-fpm/www.sock", host: "35.128.212.112"
>> 2020/04/30 03:09:35 [crit] 17176#0: *154573 connect() to 
>> unix:/run/php-fpm/www.sock failed (13: Permission denied) while connecting 
>> to upstream, client: 49.207.54.161, server: _, request: "GET / HTTP/1.1", 
>> upstream: "fastcgi://unix:/run/php-fpm/www.sock:", host: "35.128.212.112"
>> 2020/04/30 03:09:35 [error] 17176#0: *154573 open() 
>> "/var/www/drupal/web/50x.html" failed (2: No such file or directory), 
>> client: 49.207.54.161, server: _, request: "GET / HTTP/1.1", upstream: 
>> "fastcgi://unix:/run/php-fpm/www.sock", host: "35.128.212.112"
>> 2020/04/30 03:09:49 [crit] 17175#0: *154575 connect() to 
>> unix:/run/php-fpm/www.sock failed (13: Permission denied) while connecting 
>> to upstream, client: 14.98.153.6, server: _, request: "GET / HTTP/1.1", 
>> upstream: "fastcgi://unix:/run/php-fpm/www.sock:", host: "35.128.212.112"
>> 2020/04/30 03:09:49 [error] 17175#0: *154575 open() 
>> "/var/www/drupal/web/50x.html" failed (2: No such file or directory), 
>> client: 14.98.153.6, server: _, request: "GET / HTTP/1.1", upstream: 
>> "fastcgi://unix:/run/php-fpm/www.sock", host: "35.128.212.112"
>> 2020/04/30 03:09:50 [crit] 17175#0: *154575 connect() to 
>> unix:/run/php-fpm/www.sock failed (13: Permission denied) while connecting 
>> to upstream, client: 14.98.153.6, server: _, request: "GET / HTTP/1.1", 
>> upstream: "fastcgi://unix:/run/php-fpm/www.sock:", host: "35.128.212.112"
>> 2020/04/30 03:09:50 [error] 17175#0: *154575 open() 
>> "/var/www/drupal/web/50x.html" failed (2: No such file or directory), 
>> client: 14.98.153.6, server: _, request: "GET / HTTP/1.1", upstream: 
>> "fastcgi://unix:/run/php-fpm/www.sock", host: "35.128.212.112"
>> 2020/04/30 03:10:46 [crit] 17176#0: *154578 connect() to 
>> unix:/run/php-fpm/www.sock failed (13: Permission denied) while connecting 
>> to upstream, client: 184.22.107.148, server: _, request: "GET / HTTP/1.1", 
>> upstream: "fastcgi://unix:/run/php-fpm/www.sock:", host: "35.128.212.112"
>> 2020/04/30 03:10:46 [error] 17176#0: *154578 open() 
>> "/var/www/drupal/web/50x.html" failed (2: No such file or directory), 
>> client: 184.22.107.148, server: _, request: "GET / HTTP/1.1", upstream: 
>> "fastcgi://unix:/run/php-fpm/www.sock", host: "35.128.212.112"
>
>
> Please let me know if you need any additional information. Thanks in Advance.

This is probably an issue with the systemd units shipped with php-fpm.
This would not be an issue for this upstream systemd mailing list.
Please seek support from whoever packages php-fpm for you.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemctl restart changes permission.

[Mike Gilbert]

On Sun, May 3, 2020 at 3:00 PM Mike Gilbert  wrote:
> > Please let me know if you need any additional information. Thanks in 
> > Advance.
>
> This is probably an issue with the systemd units shipped with php-fpm.
> This would not be an issue for this upstream systemd mailing list.
> Please seek support from whoever packages php-fpm for you.

Sorry, I missed Lennart's reply (it was flagged as spam!). Please disregard.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Cannot find a way to get time read from RTC during boot

[Mike Gilbert]

On Thu, Mar 12, 2020 at 7:13 AM Kevin P. Fleming  wrote:
> Prior to systemd, with the 'hwclock' package installed, a udev rule
> would trigger reading of the RTC and setting the system clock when
> /dev/rtc0 appeared. With systemd running, the script run by that udev
> rule is suppressed, it doesn't do anything.
>
> With a system using solely systemd-provided services, what's the
> proper mechanism to get the time read from an RTC whose driver is
> loaded by systemd-modules-load.service?

Your use case is likely not covered by "systemd-provided" services.

I think your best bet would be to "un-supress" that hwclock udev rule.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Random branch in github.com/systemd/systemd

[Mike Gilbert]

On Thu, Jan 2, 2020 at 9:08 AM Lennart Poettering
 wrote:
> > If possible, it would probably be wise to restrict access for pushing
> > new branches like this.
>
> Hmm, how would we do that? Any suggestion? Happy to restrict that, but
> not sure how to do that...

I thought maybe there was a setting in github for it, or maybe
something to do with permissions?

I don't manage any multi-user github repos myself, so I don't have any
tangible advice.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Random branch in github.com/systemd/systemd

[Mike Gilbert]

It looks like a branch called "msekletar-security-list-process" was
pushed to the official systemd github repo earlier this month. This
branch probably belongs in msekletar's personal fork instead.

https://github.com/systemd/systemd/branches

If possible, it would probably be wise to restrict access for pushing
new branches like this.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: Unexpected behaviour not noticed by systemctl command

[Mike Gilbert]

On Thu, Oct 10, 2019 at 4:46 AM Colin Guthrie  wrote:
>
> Andy Pieters wrote on 08/10/2019 11:41:
> > forget about the stop.  that was the context into which I discovered it.
> >
> > I am not saying stop should disable I am saying stop should not accept
> > now and silently ignore it
>
>
> FWIW I'd tend to agree with you.
>
>
> [colin@jimmy Channel (master)]$ sudo systemctl stop --fodslkjsf httpd
>
> systemctl: unrecognized option '--fodslkjsf'

I think this error checking happens automatically with getopt_long(3).

> [colin@jimmy Channel (master)]$ sudo systemctl stop --now httpd
>
> [colin@jimmy Channel (master)]$
>
>
> If --now is irrelevant to the verb, then it should be the equiv of an
> unrecognized option.
>
> Bonus points if it issued a git-style "did you mean systemctl disable
> --now ..." error response.

This would not be caught by getopt_long(3) because it has no way of
knowing about "verbs" or the options that are valid for them.

This kind of error checking would require special-case coding in the
systemctl code. This is more likely to happen if someone submits a PR
for it.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Schedule reboot in *.service file

[Mike Gilbert]

On Fri, Jun 7, 2019 at 6:14 AM Jeffrey Walton  wrote:
>
> On Thu, May 16, 2019 at 11:02 AM Mike Gilbert  wrote:
> >
> > On Thu, May 16, 2019 at 4:50 AM Lennart Poettering
> >  wrote:
> > >
> > > On Mi, 15.05.19 15:53, Jeffrey Walton (noloa...@gmail.com) wrote:
> > >
> > > > if [[ "$NEEDS_REBOOT" -eq 1 ]]
> > > > then
> > > > echo "Scheduling reboot in 10 minutes"
> > > > reboot -r 10
> > >
> > > This syntax is not understood by systemd:
> > >
> > > https://www.freedesktop.org/software/systemd/man/reboot.html#
> > >
> > > If you want to schedule some command to be invoked at some future time, 
> > > use:
> > >
> > > systemd-run --on-active=10s echo "Hello World"
> >
> > Another option would be to use "shutdown -r +10", which systemctl does
> > understand. This will schedule a reboot via systemd-logind.
>
> Thanks Mike.
>
> I was missing the +10, doh...
>
> But fixing it resulted in a new issue:
>
> systemd[1]: Starting Update the system once a day without
> system-update[7454]: Updated package list
> systemd[1]: [/etc/systemd/system/system-update.service:7]
> systemd[1]: [/etc/systemd/system/system-update.service:7]
> system-update[7454]: Upgraded system
> system-update[7454]: Purging old packages
> system-update[7454]: Scheduling reboot in 10 minutes
> system-update[7454]: reboot: invalid option -- 'r'

Did you replace "reboot" with "shutdown -r"? They are separate
commands, and only "shutdown -r" supports the "+10" syntax.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Schedule reboot in *.service file

[Mike Gilbert]

On Thu, May 16, 2019 at 4:50 AM Lennart Poettering
 wrote:
>
> On Mi, 15.05.19 15:53, Jeffrey Walton (noloa...@gmail.com) wrote:
>
> > if [[ "$NEEDS_REBOOT" -eq 1 ]]
> > then
> > echo "Scheduling reboot in 10 minutes"
> > reboot -r 10
>
> This syntax is not understood by systemd:
>
> https://www.freedesktop.org/software/systemd/man/reboot.html#
>
> If you want to schedule some command to be invoked at some future time, use:
>
> systemd-run --on-active=10s echo "Hello World"

Another option would be to use "shutdown -r +10", which systemctl does
understand. This will schedule a reboot via systemd-logind.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] rdrand generated with march=winchip-c6 in systemd-241

[Mike Gilbert]

On Sat, May 11, 2019 at 1:19 PM tedheadster  wrote:
>
> On Sat, May 11, 2019 at 12:30 PM Florian Weimer  wrote:
> > Can you capture register contents at the point of the crash?
> >
> > Does this reproduce in a chroot?  Maybe you can trace the whole thing
> > with a debugger.  Does the crash reproduce if you single-step through
> > the whole function?
>
> Florian,
>   I figured out the problem, I just haven't written code to fix it.
> The documentation I can find is silent about what is returned in %ecx
> and %ebx when calling cpuid function 0x0001 on IDT Winchip-C6 and
> Winchip2.
>
> I think %ecx  should properly contain 0x, but it instead puts
> the 'auls' characters from cpuid function 0x (vendor string
> 'CentaurHauls') in %ecx:

Just a guess: I wonder if that 'auls' value is left over from the
previous CPUID result. If that's the case, a simple solution might be
to zero-out ebx, ecx, and edx in __cpuid().
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Build only libsystemd as a shared library

[Mike Gilbert]

On Tue, Apr 23, 2019 at 11:51 AM Stanislav Angelovič
 wrote:
>
> Hi systemd-ers,
>
> Having recent systemd sources, how can I build libsystemd.so only?
>
> I was able to build the static version with this:
> meson build/
> ninja -C build version.h
> ninja -C build libsystemd.a
>
> But how can I build the shared one? Is there a configuration flag? (I'm not 
> familiar with meson.)

You first need to determine the full soname of the library. You can
figure that out like so:

meson build
readlink build/libsystemd.so.0 # this is a symlink created by meson

Then, pass the full soname to ninja.

ninja -C build libsystemd.so.0.26.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd prerelease 242-rc2

[Mike Gilbert]

On Thu, Apr 4, 2019 at 3:38 PM Mike Gilbert  wrote:
>
> On Thu, Apr 4, 2019 at 11:23 AM Lennart Poettering
>  wrote:
> >
> > On Do, 04.04.19 10:06, Mike Gilbert (flop...@gentoo.org) wrote:
> >
> > > I pushed this out to our unstable testers yesterday, and received a
> > > couple bug reports this morning. I have requested that they be
> > > forwarded upstream, but wanted to point them out in case that doesn't
> > > happen promptly.
> > >
> > > https://bugs.gentoo.org/682492
> > > sys-apps/systemd-242_rc2 boot fails: sd-passwd takes no arguments
> >
> > Most likely fixed by
> > https://github.com/systemd/systemd/commit/65e5d6934ec85febb6eb64e18ce829ddc9dee497
> > already.
> >
> > > https://bugs.gentoo.org/682488
> > > sys-apps/systemd-242_rc2: systemd-timesyncd.service: Failed to set up
> > > special execution directory in /var/lib: Not a directory
> >
> > Smells like a belated result of us dropping DynamicUser=1 from
> > timesyncd.
> >
> > Right now, systemd will automatically migrate the state directory for
> > services that have DynamicUser=0 to a newer version that has
> > DynamicUser=1, but not back. We should probably add that too.
> >
> > Anyway, it was systemd v240 where we dropped the DynamicUser=1 thing
> > already, hence not precisely a v242 regression...
>
> These users probably upgraded from v239 to v241 to v242-rc2 over the
> course of a few months. We never shipped v240.

Sorry, I am mistaken; we did ship v240, but never marked it "stable".
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd prerelease 242-rc2

[Mike Gilbert]

On Thu, Apr 4, 2019 at 11:23 AM Lennart Poettering
 wrote:
>
> On Do, 04.04.19 10:06, Mike Gilbert (flop...@gentoo.org) wrote:
>
> > I pushed this out to our unstable testers yesterday, and received a
> > couple bug reports this morning. I have requested that they be
> > forwarded upstream, but wanted to point them out in case that doesn't
> > happen promptly.
> >
> > https://bugs.gentoo.org/682492
> > sys-apps/systemd-242_rc2 boot fails: sd-passwd takes no arguments
>
> Most likely fixed by
> https://github.com/systemd/systemd/commit/65e5d6934ec85febb6eb64e18ce829ddc9dee497
> already.
>
> > https://bugs.gentoo.org/682488
> > sys-apps/systemd-242_rc2: systemd-timesyncd.service: Failed to set up
> > special execution directory in /var/lib: Not a directory
>
> Smells like a belated result of us dropping DynamicUser=1 from
> timesyncd.
>
> Right now, systemd will automatically migrate the state directory for
> services that have DynamicUser=0 to a newer version that has
> DynamicUser=1, but not back. We should probably add that too.
>
> Anyway, it was systemd v240 where we dropped the DynamicUser=1 thing
> already, hence not precisely a v242 regression...

These users probably upgraded from v239 to v241 to v242-rc2 over the
course of a few months. We never shipped v240.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd prerelease 242-rc2

[Mike Gilbert]

I pushed this out to our unstable testers yesterday, and received a
couple bug reports this morning. I have requested that they be
forwarded upstream, but wanted to point them out in case that doesn't
happen promptly.

https://bugs.gentoo.org/682492
sys-apps/systemd-242_rc2 boot fails: sd-passwd takes no arguments

https://bugs.gentoo.org/682488
sys-apps/systemd-242_rc2: systemd-timesyncd.service: Failed to set up
special execution directory in /var/lib: Not a directory
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] journald cves on 239

[Mike Gilbert]

On Thu, Jan 24, 2019 at 9:34 AM Umut Tezduyar Lindskog
 wrote:
>
> Hello,
>
> We are on systemd 239 and we would like to patch following CVEs
> without jumping to 240.
>
> CVE-2018-16864
> CVE-2018-16865
> CVE-2018-16866
>
> Can someone please help us out and point the commits that we need to
> back-port since 239 was tagged?

Have a look at the v239-stable branch here. You want the commits
starting with 88947d7cae785c9aefe2083feb22b4ad93060e9e.

https://github.com/systemd/systemd-stable/commits/v239-stable
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] At wits end... need to execute a script prior to anything getting killed/changed on reboot/shutdown

[Mike Gilbert]

On Thu, Jan 17, 2019 at 12:54 PM Reindl Harald  wrote:
>
>
>
> Am 17.01.19 um 18:51 schrieb Christopher Cox:
> > On 1/17/19 11:21 AM, Reindl Harald wrote:
> >>
> >> Am 17.01.19 um 18:17 schrieb Christopher Cox:
> >>> On 1/17/19 11:01 AM, Lennart Poettering wrote:
>  Hmm, what kind of processes are you missing? user session stuff? How
>  do you shut down? Note that display managers are likely to terminate
>  the user sessions first, and only initiate system shutdown then...
> >>> These are nohup'd background processes not tied to any tty.
> >> give that a try!
> >>
> >> [root@srv-rhsoft:~]$ cat /etc/systemd//logind.conf.d/logind.conf
> >> [Login]
> >> KillUserProcesses=no
> >
> > It's default, that is, already set to "no" (shouldn't matter anyway,
> > again the processes are nohup'd)
>
> it is NOT default
>
> it defaults to YES and the whole discussions as that changed where about
> nohup'd processes long ago

Unless he is compiling systemd himself, the default is determined by
the distro he is using. Several distros default it to "no" via the
default-kill-user-processes meson option.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Mike Gilbert]

On Mon, Jan 14, 2019 at 10:36 AM Lennart Poettering
 wrote:
>
> On Mo, 14.01.19 10:59, Jan Synacek (jsyna...@redhat.com) 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.
>
> Well, one thing I'd really like to see happen is a bit more feedback
> *before* the release from downstreams. Much of the breakage in v240 was
> totally avoidable, if downstreams would let us know in advance if
> things break.

I would be happy to publish release candidates on Gentoo ahead of the
official release. I'm much less likely to push out randomly selected
snapshots from the master branch.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] fchmod_opath() - why is this not in the kernel?

[Mike Gilbert]

The fchmod_opath() function in systemd seems like a hacky workaround
for a limitation in the kernel -- you can't call fchmod() on an fd
opened with O_PATH, and fchmodat() doesn't support the AT_EMPTY_PATH
flag.

Has any attempt been made to add this functionality in the kernel? If
someone has already tried and failed, I will refrain from making an
attempt myself.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] specialized user sessions for running large processes

[Mike Gilbert]

On Tue, Oct 2, 2018 at 2:24 PM Andrei Borzenkov  wrote:
> Please do not start telling that it can be done differently. Until SAP
> implements *SUPPORTED* different solution (startup files are maintained
> by SAP installer automatically among other things) using login shell is
> the only supported way to use SAP.

This is just not the way system services work with systemd.

If you want a supported solution from SAP, perhaps you should contact SAP.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Revert "meson: use the host architecture compiler/linker for src/boot/efi" #10217

[Mike Gilbert]

On Sun, Sep 30, 2018 at 1:57 PM Helmut Grohne  wrote:
>
> Hi,
>
> > This reverts commit df7caca.
>
> If you reverts df7caca, please also revert b710072 as that breaks cross
> builds.
>
> > The patch df7caca breaks normal build. Let's revert this, as I do not want 
> > to revert this every time when setting up a new build directory to test 
> > some branch.
>
> No, it doesn't. It only breaks the normal build if you supply a cc that
> consists of multiple words (such as "ccache gcc"). As a workaround, you
> can simply prepend /usr/lib/ccache to $PATH on most distributions.

meson automatically sets the C compiler ['ccache', 'cc'] if ccache is
in PATH. This happens by default unless CC is set in the environment.

Anyway, I submitted a pull request that fixes the issue, so no revert
will be necessary here.

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

Also, it would be much nicer if you would keep the discussion in one
place (github) instead of spreading it onto the mailing list. I did
not see this thread for several hours after having already fixed the
problem myself.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to build only udev

[Mike Gilbert]

On Tue, Jul 3, 2018 at 7:55 PM, Kevin Greene  wrote:
> I am building libusb, and I want to build it with udev support. I don't need
> to build anything in systemd except udev. Is there a good way to do that?
>
> I'm deploying to machines running Ubuntu 16.04, so I'm targeting systemd
> v229 (which was pre-meson).

Why not just install the libudev-dev package on a Ubuntu dev
system/chroot? That would be much simpler than building libudev from
scratch, and would ensure you build against the actual library Ubuntu
uses.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd kills user process (apache) when logout by sftp is initiated

[Mike Gilbert]

On Thu, Feb 1, 2018 at 1:42 PM, Andrei Borzenkov  wrote:
> 01.02.2018 15:08, Mantas Mikulėnas пишет:
>>>
>>
>> For users outside the "system account" UID range (usually 1–999), a logout
>> will cause systemd to clean up remaining "junk" such as SysV IPC resources.
>
>
> Where is it documented?

In logind.conf(5).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Again, why this strange behavior implied by "auto" in fstab ?

[Mike Gilbert]

On Tue, Jan 23, 2018 at 10:54 AM, Reindl Harald  wrote:
>
>
> Am 23.01.2018 um 16:49 schrieb Simon McVittie:
>>
>> On Tue, 23 Jan 2018 at 15:47:21 +0100, Franck Bui wrote:
>>>
>>> Basically, systemd mounts all filesystems listed in /etc/fstab (unless
>>> "noauto" is used) which is good since that's how fstab was used when
>>> SysV was the init system.
>>>
>>> However it also introduced another "feature" which basically
>>> automagically mounts a filesystem (listed in fstab) every time its
>>> backend device re-appears.
>>
>>
>> Am I right in thinking this is only done if the filesystem is not declared
>> as noauto in fstab?
>
>
> with Fedora 27 (yesterday upgraded) systemd even don't leave "noauto"
> mount-point in peace and spits the "Failed to read symlink target for
> /mnt/arrakis: Permission denied" for fuse-mountpoints multiple times each
> day into the systemlogs (systemd-234-9.fc27.x86_64)
>
> [root@srv-rhsoft:~]$ systemctl daemon-reload
>
> [root@srv-rhsoft:~]$ cat messages
> Jan 23 16:52:16 srv-rhsoft systemd-fstab-generator[27644]: Failed to read
> symlink target for /mnt/arrakis: Permission denied
>
> [root@srv-rhsoft:~]$ cat /etc/fstab | grep /mnt/arrakis
> sshfs#reindl@arrakis:/ /mnt/arrakis   fuse
> noauto,user,rw,noexec,nosuid,nodev,noatime,uid=harry

Sounds like you have a broken symlink at /mnt or /mnt/arrakis. systemd
is trying to deference said symlink when it generates the mount unit
for that fstab entry.

There's an explanation for this in the commit that introduced the behavior.

https://github.com/systemd/systemd/commit/634735b56b82bdde3c67193ba7b470bab80fdcbd
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Illegal CPUID instruction causes systemd core dump

[Mike Gilbert]

On Thu, Dec 28, 2017 at 3:18 PM, Lennart Poettering
 wrote:
> On Do, 28.12.17 14:07, tedheadster (tedheads...@gmail.com) wrote:
>
>> I am doing regression testing on old hardware. systemd-233 just
>> generated the following error on startup:
>>
>> traps:systemd[1] trap invalid opcode ip:b7d97361 sp:bfa2f6bc error:0
>> in libsystemd-shared-233.so[b7d3e000+1cc000]
>> systemd[1]: Caught , dumped core as pid 78.
>> systemd[1]: Freezing execution
>>
>> I believe it is getting an illegal instruction trap on this first
>> generation 486 because it is calling "cpuid" in detect_vm_cpuid()
>> without first checking if the hardware supports it; it doesn't in this
>> case.
>>
>> The gcc compiler provides a workaround in the cpuid.h header file. You
>> can call __get_cpuid_max() first and check the return value > 0.
>>
>> https://stackoverflow.com/questions/14266772/how-do-i-call-cpuid-in-linux#14266932
>>
>> The Linux kernel still supports the 486 so we have to code around this
>> case, even if it is ancient hardware.
>
> Please send a patch for this. We lack the relevant hardware and
> can't test this. In fact, for most such portability support for
> less-than-mainsrtream systems we rely on external patches.

I created a PR for this. I have not tested it on a VM, or on an i486.
Hopefully one of the CI systems can cover the former case. ;-)

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

Re: [systemd-devel] udev

[Mike Gilbert]

On Wed, Nov 1, 2017 at 10:49 AM, David Henderson
 wrote:
> On 11/1/17, Greg KH  wrote:
>> On Wed, Nov 01, 2017 at 10:36:16AM -0400, David Henderson wrote:
>>> Is there a place to just get the udev code instead of all of systemD?
>>
>> No.
>>
>>> I tried looking online, but it appears that the only solo versions are
>>> old.  I guess this got merged into systemD for some reason?
>>
>> Yes, it all got merged many many years ago for the obvious reasons that
>> you will find out if you try to tear them apart :)
>
> lol Thanks Greg, I will give it another shot later today to see if I
> can get things resolved with some of the suggestions provided!

On the topic of ripping udev out of systemd:

Some Gentoo people actually forked udev out of systemd a while ago.
You might consider using their "eudev" fork if it meets your needs. We
use this as the default udev implementation for Gentoo systems that do
not use systemd. Just don't ask for support for it on this mailing
list. ;-)

https://wiki.gentoo.org/wiki/Project:Eudev

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

Re: [systemd-devel] udev

[Mike Gilbert]

On Thu, Oct 26, 2017 at 11:45 AM, Mantas Mikulėnas  wrote:
> On Thu, Oct 26, 2017, 18:26 David Henderson 
> wrote:
>>
>> Good afternoon all!  I have been looking for the udev source code to
>> compile the library and utilities and it appears it is bundled in the
>> systemd software.  I have run autoreconf to generate a configure
>> script (using version 233 since I don't have meson), but could not see
>> a way to just compile this software.  How do I accomplish this?
>
>
> You could run `make systemd-udevd libudev.so`.
>
> I'm not sure how to package just udevd. Maybe take a look at how distros
> like Gentoo achieve this.

For reference:

https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-fs/udev/udev-233.ebuild?id=2f9f0fbb62866409b8ae0252a2b280d148dd9d73

It's pretty ugly. We build around a dozen targets, and (ab)use
automake install targets to selectively install bits and pieces. See
the multilib_src_compile and multilib_src_install functions.

Here's the meson version, for comparison. It's still pretty ugly, and
we have to install things manually since there are no partial install
targets.

https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-fs/udev/udev-235.ebuild?id=2f9f0fbb62866409b8ae0252a2b280d148dd9d73

Anyway, if you have any questions, feel free to ping me (floppym) on Freenode.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] container /proc/filesystems owned by nobody:can't upgrade

[Mike Gilbert]

On Tue, Oct 3, 2017 at 11:38 AM, arnaud gaboury
<arnaud.gabo...@gmail.com> wrote:
> On 10/03/2017 05:19 PM, Mike Gilbert wrote:
>
> On Tue, Oct 3, 2017 at 4:01 AM, arnaud gaboury <arnaud.gabo...@gmail.com>
> wrote:
>
> My host is Archlinux, nspawn container is Fedora 26. Kernel is 4.13.3
>
> I can't fully upgrade my container as some files are owned by
> nobody:nobody and can't change to root. An example is filesystems. When
> upgrading, it returns error:
> < error: unpacking of archive failed on file /proc: cpio: chown >
> $ ls -a /proc:
> /proc/filesystems-r--r--r--   1 nobody  nobody 0
> Oct  3 09:53 filesystems
>
> # chown root:root /proc/filesystems
> chown: changing ownership of '/proc/filesystems': Operation not permitted
>
> Same kind of error with a few other packages.
>
> Can someone please help me to find a solution? Thank you
>
> I find it strange that a package upgrade would be trying to install
> the /proc directory on a running system. That's a directory that
> should only really be touched when performing an initial install; any
> other time, /proc will be mounted already and packages should not
> touch it.
>
> I would report this as a bug to Arch.
>
> If it is a bug, it shall be reported on Fedora, which is the OS running in
> the container, and not Arch which is the host.

Ah, I misread that. Yes, this would be a Fedora bug.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] container /proc/filesystems owned by nobody:can't upgrade

[Mike Gilbert]

On Tue, Oct 3, 2017 at 4:01 AM, arnaud gaboury  wrote:
> My host is Archlinux, nspawn container is Fedora 26. Kernel is 4.13.3
>
> I can't fully upgrade my container as some files are owned by
> nobody:nobody and can't change to root. An example is filesystems. When
> upgrading, it returns error:
> < error: unpacking of archive failed on file /proc: cpio: chown >
> $ ls -a /proc:
> /proc/filesystems-r--r--r--   1 nobody  nobody 0
> Oct  3 09:53 filesystems
>
> # chown root:root /proc/filesystems
> chown: changing ownership of '/proc/filesystems': Operation not permitted
>
> Same kind of error with a few other packages.
>
> Can someone please help me to find a solution? Thank you

I find it strange that a package upgrade would be trying to install
the /proc directory on a running system. That's a directory that
should only really be touched when performing an initial install; any
other time, /proc will be mounted already and packages should not
touch it.

I would report this as a bug to Arch.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Factoring out initctl support

[Mike Gilbert]

On Fri, Apr 15, 2016 at 1:33 PM, Daniel Mack <dan...@zonque.org> wrote:
> On 04/15/2016 07:03 PM, Mike Gilbert wrote:
>> On Fri, Apr 15, 2016 at 11:43 AM, Daniel Mack <dan...@zonque.org> wrote:
>>> On 04/15/2016 03:55 PM, Mike Gilbert wrote:
>
>>>> I'm happy to move it if others want to utilize it. I will need someone
>>>> to set me up with access to push the code, however.
>>>
>>> Great, will do. What's your GitHub handle?
>>
>> I'm floppym on github.
>>
>
> Thanks - you're now the admin of this new repository:
>
>   https://github.com/systemd/systemd-initctl/
>
> I'm happy to push the client code there once you migrated the project.

The project has been migrated.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Factoring out initctl support

[Mike Gilbert]

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

Oh, I see. I had no idea systemctl has such code.

> What also missing in your repository is the manpage and a README.
>
>>> Would you be okay with transferring this repository to the systemd
>>> organization on GitHub?
>>
>> I'm happy to move it if others want to utilize it. I will need someone
>> to set me up with access to push the code, however.
>
> Great, will do. What's your GitHub handle?

I'm floppym on github.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Mike Gilbert]

On Fri, Apr 15, 2016 at 6:42 AM, Daniel Mack  wrote:
> Nice, thanks for working on this! What's still missing in that is the
> other side, the client that talks to the initctl socket. I have patches
> to remove the initctl bits from the systemd repo, and add a callout from
> systemctl to binaries in a directory. The initctl client would live in
> that directory, and be automatically called as a fallback then.

I'm not sure what you mean by this; the de-facto "initctl client" is
the telinit binary from sysvinit. There should be no need to
re-implement that.

Are you referring to some other interface? Does upstart do something similar?

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

I'm happy to move it if others want to utilize it. I will need someone
to set me up with access to push the code, however.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Mike Gilbert]

On Wed, Feb 24, 2016 at 10:42 PM, Mike Gilbert <flop...@gentoo.org> wrote:
> On Fri, Feb 19, 2016 at 7:22 AM, Lennart Poettering
> <lenn...@poettering.net> wrote:
>> On Thu, 18.02.16 20:33, Mike Gilbert (flop...@gentoo.org) wrote:
>>
>>> On Thu, Feb 11, 2016 at 12:06 PM, Lennart Poettering
>>> <lenn...@poettering.net> wrote:
>>> > 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
>>> >time Debian was still using that, maybe this changed now?
>>>
>>> Gentoo allows switching between systemd and openrc (sysvinit) at boot
>>> time, and will continue to do so for the foreseeable future.
>>>
>>> By default, sysvinit owns /sbin/initctl, /sbin/halt, etc. Users may
>>> swap these to symlinks to systemd and systemctl by setting a USE flag,
>>> but if they do so they knowingly lose the ability to switch back to
>>> openrc without a rebuild of the affected packages.
>>>
>>> I would like to selfishly request that you keep this interface around
>>> as long as possible; if you remove it I will have to come up with some
>>> replacement.
>>
>> So here's probably what is going to happen.
>>
>> The initctl support in systemctl will be dropped and replaced by some
>> callout script support. i.e. when you want to use systemctl to reboot
>> a sysvinit system, then systemctl won't do that anymore, but it will
>> invoke some shell script as a fallback, where distros can place the
>> necessary commands if they care about this. This follows how we do
>> sysv script enable/disable handling (i.e. the chkconfig hookup).
>>
>> We'll eventually kill /dev/initctl support. Distros should really find
>> their own replacement for this. They can either take the current code,
>> build it externally, or write some new code. You might be able to
>> implement this in a carefully prepared shell script that invokes
>> busctl to do the reboot. You could use "dd" to read the initreq
>> structure from STDIN with the precise size, then figure out which kind
>> of request it is (again, by using dd to extract the four bytes
>> starting at index 4 of that request structure) and then simply execute
>> the right busctl command to poweroff/reboot/...
>>
>> I'll not drop this right-away, but let's say in 6month or so this will
>> go away. This should be an ample heads-up to find a replacement and
>> prepare for this.
>
> The existing systemd-initctl (/dev/initctl) interface works quite
> nicely, so I will probably end up extracting it from systemd when you
> drop it, or just building/installing it from an older systemd tarball.
> No need to reinvent the wheel.
>
> Thanks for the response.

Ripping systemd-initctl out of the systemd source tree was more
difficult than I anticipated. Instead, I rewrote a simpler version.
The code is on bitbucket.

https://bitbucket.org/floppym/gentoo-systemd-initctl/src
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [RFC] the chopping block

[Mike Gilbert]

On Fri, Feb 19, 2016 at 7:22 AM, Lennart Poettering
<lenn...@poettering.net> wrote:
> On Thu, 18.02.16 20:33, Mike Gilbert (flop...@gentoo.org) wrote:
>
>> On Thu, Feb 11, 2016 at 12:06 PM, Lennart Poettering
>> <lenn...@poettering.net> wrote:
>> > 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
>> >time Debian was still using that, maybe this changed now?
>>
>> Gentoo allows switching between systemd and openrc (sysvinit) at boot
>> time, and will continue to do so for the foreseeable future.
>>
>> By default, sysvinit owns /sbin/initctl, /sbin/halt, etc. Users may
>> swap these to symlinks to systemd and systemctl by setting a USE flag,
>> but if they do so they knowingly lose the ability to switch back to
>> openrc without a rebuild of the affected packages.
>>
>> I would like to selfishly request that you keep this interface around
>> as long as possible; if you remove it I will have to come up with some
>> replacement.
>
> So here's probably what is going to happen.
>
> The initctl support in systemctl will be dropped and replaced by some
> callout script support. i.e. when you want to use systemctl to reboot
> a sysvinit system, then systemctl won't do that anymore, but it will
> invoke some shell script as a fallback, where distros can place the
> necessary commands if they care about this. This follows how we do
> sysv script enable/disable handling (i.e. the chkconfig hookup).
>
> We'll eventually kill /dev/initctl support. Distros should really find
> their own replacement for this. They can either take the current code,
> build it externally, or write some new code. You might be able to
> implement this in a carefully prepared shell script that invokes
> busctl to do the reboot. You could use "dd" to read the initreq
> structure from STDIN with the precise size, then figure out which kind
> of request it is (again, by using dd to extract the four bytes
> starting at index 4 of that request structure) and then simply execute
> the right busctl command to poweroff/reboot/...
>
> I'll not drop this right-away, but let's say in 6month or so this will
> go away. This should be an ample heads-up to find a replacement and
> prepare for this.

The existing systemd-initctl (/dev/initctl) interface works quite
nicely, so I will probably end up extracting it from systemd when you
drop it, or just building/installing it from an older systemd tarball.
No need to reinvent the wheel.

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

Re: [systemd-devel] [RFC] the chopping block

[Mike Gilbert]

On Thu, Feb 11, 2016 at 12:06 PM, Lennart Poettering
 wrote:
> 1) systemd-initctl (i.e. the /dev/initctl SysV compat support). Last
>time Debian was still using that, maybe this changed now?

Gentoo allows switching between systemd and openrc (sysvinit) at boot
time, and will continue to do so for the foreseeable future.

By default, sysvinit owns /sbin/initctl, /sbin/halt, etc. Users may
swap these to symlinks to systemd and systemctl by setting a USE flag,
but if they do so they knowingly lose the ability to switch back to
openrc without a rebuild of the affected packages.

I would like to selfishly request that you keep this interface around
as long as possible; if you remove it I will have to come up with some
replacement.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd (user) and (sd-pam) (user) processes in login shell

[Mike Gilbert]

On Mon, Dec 21, 2015 at 9:54 PM, Kai Krakow <hurikha...@gmail.com> wrote:
> Am Mon, 21 Dec 2015 21:43:24 -0500
> schrieb Mike Gilbert <flop...@gentoo.org>:
>
>> On Mon, Dec 21, 2015 at 7:36 PM, Kai Krakow <hurikha...@gmail.com>
>> wrote:
>> > Am Tue, 8 Dec 2015 01:36:01 +0200
>> > schrieb Mantas Mikulėnas <graw...@gmail.com>:
>> >
>> >> What uid does "oracle" have – is it within the system account range
>> >> (usually 1–999) or user account (1000–)? I wonder if it's the
>> >> latter, which would mean systemd-logind would clean up various
>> >> things like IPC on logout... (see logind.conf)
>> >
>> > Is this hard-coded in systemd (uid 0..999 and 1000+) or is it read
>> > from login.defs?
>> >
>> > Because I cannot find anything related to it in logind.conf which
>> > leads me to the assumption your reference was about RemoveIPC and
>> > friends only...
>>
>> I rather doubt the numeric value of the oracle UID has anything to do
>> with the problem you are having.
>>
>> With systemd, you really cannot start daemons from an interactive
>> shell. Rather, you need to define a service unit, and call "systemctl
>> start" to start long-running daemons.
>
> I think we are talking different here. My question is a spin-off of the
> OP.

Sorry for the mis-reply.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd (user) and (sd-pam) (user) processes in login shell

[Mike Gilbert]

On Mon, Dec 21, 2015 at 7:36 PM, Kai Krakow  wrote:
> Am Tue, 8 Dec 2015 01:36:01 +0200
> schrieb Mantas Mikulėnas :
>
>> What uid does "oracle" have – is it within the system account range
>> (usually 1–999) or user account (1000–)? I wonder if it's the latter,
>> which would mean systemd-logind would clean up various things like
>> IPC on logout... (see logind.conf)
>
> Is this hard-coded in systemd (uid 0..999 and 1000+) or is it read from
> login.defs?
>
> Because I cannot find anything related to it in logind.conf which leads
> me to the assumption your reference was about RemoveIPC and friends
> only...

I rather doubt the numeric value of the oracle UID has anything to do
with the problem you are having.

With systemd, you really cannot start daemons from an interactive
shell. Rather, you need to define a service unit, and call "systemctl
start" to start long-running daemons.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] RFC: removing initctl support

[Mike Gilbert]

On Mon, Sep 21, 2015 at 8:31 PM, Lennart Poettering
 wrote:
> Heya!
>
> Since a long time systemd has been shipping with two-way compat
> support for /dev/initctl, and I am tempted to remove it. Before I do
> so, I'd like some input on the relevance of this interface:

Gentoo currently utilizes this interface by default; our sysvinit
package is installed by default to support OpenRC, and provides the
reboot/poweroff commands.

We do optionally support replacing those commands with symlinks to
systemctl, but there are a few blockers which prevent us from enabling
that configuration by default. We are working on resolving that, but
it may be another year or so at the rate it is currently going.

I would appreciate it if you kept this around for a while longer.
___
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

[Mike Gilbert]

On Mon, Jun 22, 2015 at 7:30 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Tue, 23.06.15 01:21, Kay Sievers (k...@vrfy.org) wrote:

 We currently considering to stop creating release tar balls.

 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.

 Which of course means the build tools for all of these need to be
 around on the build machines, as *everything* will be rebuilt from
 scratch now. Specifically you need
 autoconf/automake/python/perl/m4/xsltproc/... on every build machine.

 Hence the question to ask is: is anyone downstream relying on the
 pre-built stuff, and has a very good reason why he couldn't just
 install the build tools on his build machine and build things with
 that?

On Gentoo, most users build from source, so this means additional
dependencies on most users' systems. We would appreciate having the
autotools-generated tarballs, but we can certainly live without them.

FYI, having to run autoreconf introduces the following dependencies for us:

app-text/docbook-xml-dtd:4.2
app-text/docbook-xml-dtd:4.5
app-text/docbook-xsl-stylesheets
dev-libs/libxslt:0
=dev-libs/libgcrypt-1.4.5:0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Mike Gilbert]

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

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

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

Why do you pipe it through sed when a simple shell parameter expansion would do?

with_rootprefix=${withval%/}
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Correct path to systemd-fsck in generated systemd-fsck-root.service

[Mike Gilbert]

This should also be flagged for backports since the hard-coded
/usr/lib/systemd path will break any initramfs if rootprefix != /usr.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] Correct path to systemd-fsck in generated systemd-fsck-root.service

[Mike Gilbert]

---
 Makefile.am| 1 +
 src/shared/generator.c | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index f84a28d..70d4dc0 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -188,6 +188,7 @@ AM_CPPFLAGS = \
-DCATALOG_DATABASE=\$(catalogstatedir)/database\ \
-DSYSTEMD_CGROUP_AGENT_PATH=\$(rootlibexecdir)/systemd-cgroups-agent\ 
\
-DSYSTEMD_BINARY_PATH=\$(rootlibexecdir)/systemd\ \
+   -DSYSTEMD_FSCK_PATH=\$(rootlibexecdir)/systemd-fsck\ \
-DSYSTEMD_SHUTDOWN_BINARY_PATH=\$(rootlibexecdir)/systemd-shutdown\ \
-DSYSTEMD_SLEEP_BINARY_PATH=\$(rootlibexecdir)/systemd-sleep\ \
-DSYSTEMCTL_BINARY_PATH=\$(rootbindir)/systemctl\ \
diff --git a/src/shared/generator.c b/src/shared/generator.c
index 8128499..807569a 100644
--- a/src/shared/generator.c
+++ b/src/shared/generator.c
@@ -61,7 +61,7 @@ static int write_fsck_sysroot_service(const char *dir, const 
char *what) {
 [Service]\n
 Type=oneshot\n
 RemainAfterExit=yes\n
-ExecStart=/usr/lib/systemd/systemd-fsck %2$s\n
+ExecStart= SYSTEMD_FSCK_PATH  %2$s\n
 TimeoutSec=0\n,
 program_invocation_short_name,
 what,
-- 
2.4.1

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

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

[Mike Gilbert]

On Wed, Apr 8, 2015 at 4:08 PM, Marc-Antoine Perennou
marc-anto...@perennou.com wrote:
 Signed-off-by: Marc-Antoine Perennou marc-anto...@perennou.com
 ---
  Makefile.am  | 4 ++--
  configure.ac | 3 +++
  2 files changed, 5 insertions(+), 2 deletions(-)

 diff --git a/Makefile.am b/Makefile.am
 index 9b769ee..397a71c 100644
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -2596,7 +2596,7 @@ $(systemd_boot_solib): $(systemd_boot_objects)
 nm -D -u $@ | grep ' U '  exit 1 || :

  $(systemd_boot): $(systemd_boot_solib)
 -   $(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \
 +   $(AM_V_GEN)$(OBJCOPY) -j .text -j .sdata -j .data -j .dynamic \
   -j .dynsym -j .rel -j .rela -j .reloc \
   --target=efi-app-$(EFI_ARCH) $ $@

 @@ -2634,7 +2634,7 @@ $(stub_solib): $(stub_objects)
 nm -D -u $@ | grep ' U '  exit 1 || :

  $(stub): $(stub_solib)
 -   $(AM_V_GEN) objcopy -j .text -j .sdata -j .data -j .dynamic \
 +   $(AM_V_GEN)$(OBJCOPY) -j .text -j .sdata -j .data -j .dynamic \
   -j .dynsym -j .rel -j .rela -j .reloc \
   --target=efi-app-$(EFI_ARCH) $ $@

 diff --git a/configure.ac b/configure.ac
 index 0722841..faf1596 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -83,6 +83,9 @@ AC_PROG_AWK

  AC_PROG_CC_C99

 +AC_ARG_VAR(OBJCOPY, [The objcopy binary])
 +test -z $ac_cv_env_OBJCOPY_value  OBJCOPY=objcopy

Why not use AC_CHECK_TOOL here?

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

Re: [systemd-devel] Enable port forwarding via upnp

[Mike Gilbert]

On Wed, Feb 25, 2015 at 2:16 AM, Kai Krakow hurikha...@gmail.com wrote:
 Hello!

 Is it possible to somehow create a service which enables port forwardings on
 my router using upnp? Currently, I guess it is not possible (except maybe
 using ExecPost or ExecPre and the upnpc program). But when my client IP
 changes via DHCP, it should be reapplied. Also, it needs to be maintained as
 the programmed port forwardings would timeout and be cleared from the router
 after a while. So it needs to be hooked up to systemd-networkd somehow (at
 least that is what I am using).

 Please advice and tell your thoughts. Maybe it is just plain insane...

It seems like it would be easy to do this using dhcpcd or dhclient via
a hook/script, assuming your DHCP lease times are shorter than the
UPnP timeout period.

I'm not sure if/how it would be possible when using networkd to
configure the interface.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] make install busted in git

[Mike Gilbert]

On Tue, Jan 13, 2015 at 4:48 AM, Jan Engelhardt jeng...@inai.de wrote:

 On Tuesday 2015-01-13 00:25, Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Jan 12, 2015 at 11:42:38PM +0100, Jan Engelhardt wrote:

 Happens with top-of-line 720e0be0f00f4a7fee808d1cf60db43970900588.

 == Summary ==
 + make install DESTDIR=/home/abuild/rpmbuild/BUILDROOT/systemd-218a-0.x86_64
 make --no-print-directory install-recursive
 Making install in .
 [...]
   XSLT man/busctl.1
 [...]
  /usr/bin/mkdir -p 
 '/home/abuild/rpmbuild/BUILDROOT/systemd-218a-0.x86_64/usr/share/man/man1'
  /usr/bin/install -c -m 644 ./man/busctl.1 [...] 
 '/home/abuild/rpmbuild/BUILDROOT/systemd-218a-0.x86_64/usr/share/man/man1'
 /usr/bin/install: cannot stat './man/busctl.1': No such file or directory

No idea. It works fine here (Debian/sid).

 /usr/bin/xsltproc -o man/bootup.7 --nonet --xinclude --stringparam
  man.output.quietly 1 --stringparam funcsynopsis.style ansi
  --stringparam man.authors.section.enabled 0 --stringparam
  man.copyright.section.enabled 0 --stringparam systemd.version 210
  --path './man:./man' ./man/custom-man.xsl man/bootup.xml

 would always create the file man/man7/bootup.7 (libxslt-tools-1.2.28)
 and not man/bootup.7.

 The only reason the install-man target succeeds in systemd-210.tar.xz
 is because the manpages are pre-provided in the tarball (but not in
 git):
   ls -l man/*.[0-9]

 How do things look on your end?

No problems from git here. Using your little test:

floppym@naomi systemd % pwd
/home/floppym/src/systemd

floppym@naomi systemd % ls -l man/bootup.*
-rw-r--r-- 1 floppym floppym 17807 Jan 11 19:59 man/bootup.xml

floppym@naomi systemd % /usr/bin/xsltproc -o man/bootup.7 --nonet
--xinclude --stringparam man.output.quietly 1 --stringparam
funcsynopsis.style ansi --stringparam man.authors.section.enabled 0
--stringparam man.copyright.section.enabled 0 --stringparam
systemd.version 210 --path './man:./man' ./man/custom-man.xsl
man/bootup.xml

floppym@naomi systemd % ls -l man/bootup.*
-rw-r--r-- 1 floppym floppym 13378 Jan 13 09:05 man/bootup.7
-rw-r--r-- 1 floppym floppym 17807 Jan 11 19:59 man/bootup.xml
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] bootchart: ship a configuration that will boot without sysvinit compat

[Mike Gilbert]

On Sat, Dec 27, 2014 at 8:57 AM, Gabriel de Perthuis g2p.c...@gmail.com wrote:
 bootchart defaults to chaining to /sbin/init, which is sensible,
 but in a pure systemd environment (without systemd-sysvinit)
 will make the machine unbootable.

 Change the default through /etc/systemd/bootchart.conf.
 Keep the /sbin/init default in the source code, in case
 some users rely on that.
 ---
  src/bootchart/bootchart.conf | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/src/bootchart/bootchart.conf b/src/bootchart/bootchart.conf
 index c73328f..61ba0c1 100644
 --- a/src/bootchart/bootchart.conf
 +++ b/src/bootchart/bootchart.conf
 @@ -14,11 +14,11 @@
  #Samples=500
  #Frequency=25
  #Relative=no
  #Filter=yes
  #Output=folder name, defaults to /run/log
 -#Init=/path/to/init-binary
 +Init=/usr/lib/systemd/systemd
  #PlotMemoryUsage=no
  #PlotEntropyGraph=no
  #ScaleX=100
  #ScaleY=20
  #ControlGroup=no

Please do not hard-code the path to systemd; it gets installed under
$(rootprefix)/lib/systemd, and rootprefix is a configure option.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Fix install location of systemd.pc

[Mike Gilbert]

On Sun, Dec 28, 2014 at 6:20 AM, Martin Pitt martin.p...@ubuntu.com wrote:
 Hello all,

 systemd.pc is currently installed into /usr/share/pkgconfig/, but this
 isn't correct: It contains libdir whose value is (possibly)
 architecture specific. E. g. if you configure with
 --libdir=/usr/lib/x86_64-linux-gnu (we do that in Debian for
 multi-arch support) systemd.pc contains

   libdir=/usr/lib/x86_64-linux-gnu

 which isn't architecture agnostic and thus not suitable for
 /usr/share/.

From Lennart's commit message, it seems like this was done intentionally.

http://cgit.freedesktop.org/systemd/systemd/commit/?id=eb39a6239c631873db62f6a942e6cb3dab0a2db4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Mike Gilbert]

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.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Is there a reason to forcefully create /etc/mtab?

[Mike Gilbert]

On Sun, Jul 6, 2014 at 1:08 PM, Ivan Shapovalov intelfx...@gmail.com wrote:
 On Sunday 06 July 2014 at 13:01:22, Leonid Isaev wrote:
 Hi,

   I have a read-only / filesystem and /etc/mtab points to
 /proc/self/mounts as it should.
   So, in systemd-215 tmpfile.d fails to create a symbolic link /etc/mtab
 because /usr/lib/tmpfiles.d/etc.conf contains is a line L+ /etc/mtab - - - -
 ../proc/self/mounts.
   Is this intentional? Besides failing on ro /, it is also confusing
 because /etc/mtab can be supplied by a package (in archlinux, the 
 'filesystem'
 package), so why tmpfiles instead of including this symlink with systemd?
   The same question applies to the entire etc.conf: why does tmpfiles
 touch /etc at all, especially if /etc is already properly set up?

 Thanks,


 L+ (as well as any other + directives) only force-overwrite files if this is
 needed, e. g. if a symlink points to the wrong desination.


Right.

I think the path matching is a little naive; Using a simple string
comparison, /proc/self/mounts != ../proc/self/mounts even though
both paths refer to the same object.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] Revert build-sys: include PolicyKit files as part of distribution

[Mike Gilbert]

This reverts commit 0c26bfc3d21fdb3963f1248c237e2f1a33b5566d.

src/core/org.freedesktop.systemd1.policy.in.in depends on values which
are specified at configure time, so we cannot ship the corresponding
policy file in the tarball.

Since we need to regenerate one policy file, we might as well generate
them all.
---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index e238cde..32dc1fd 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5216,7 +5216,7 @@ units/user/%: units/%.m4
$(AM_V_M4)$(M4) -P $(M4_DEFINES) -DFOR_USER=1  $  $@
 
 if ENABLE_POLKIT
-dist_polkitpolicy_DATA = \
+nodist_polkitpolicy_DATA = \
$(polkitpolicy_files) \
$(polkitpolicy_in_in_files:.policy.in.in=.policy)
 endif
-- 
2.0.0

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

[systemd-devel] Inconsistent processing of 'debug' and 'systemd.log_level' options from kernel command line

[Mike Gilbert]

I have noticed that when the 'debug' option is passed on the kernel
command line, it is impossible to override this using the
'systemd.log_level' option.

I also note that passing SYSTEMD_LOG_LEVEL on the kernel command line
DOES work; the kernel copies this to the environment block for init.

Looking through the code, it looks like the 'debug' option is
processed twice by systemd[1] in src/core/main.c:

1. In parse_proc_cmdline(), 'debug' processed along with all other
kernel command line options including 'systemd.log_level'.

2. In log_parse_environment(), 'debug' is processed, but
systemd.log_level is ignored.

Is this a bug? It seems quite strange.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev-212 and up on Sparc v8

[Mike Gilbert]

On Mon, Jun 23, 2014 at 9:25 AM, Lennart Poettering
lenn...@poettering.net wrote:
 On Mon, 23.06.14 16:11, Samuli Suominen (ssuomi...@gentoo.org) wrote:

  Thanks, but please work with the gcc developers to solve this
  generically for all gcc users, instead of work around this limitation in
  every individual project independently. It's certainly time much better
  spent.

 IIRC, he told me when we discussed at IRC that systemd-udevd was the
 showstopper, and rest of the 'core' system
 built fine.

 Sure. Again. It's sounds like time much better spend if you solve this
 atomic ops problems for all users of it (and believe me there are a
 number, especially outside of the 'core' system. PulseAudio for example
 being one which hwoever has ugly fallbacks to libatomic_ops, which are
 much slower and uglier, and pull in a dep).


I just want to point out that the GCC manual labels the __sync_*
functions as being legacy functions, which would imply that a more
modern alternative exists.

Are they referring to atomic variables in C11, or something else?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] no fsck at boot

[Mike Gilbert]

On Mon, Jun 23, 2014 at 6:15 PM, Chris Murphy li...@colorremedies.com wrote:
 But in any case, is there a better way to trigger fsck for ext3/4, and not 
 for XFS and Btrfs, based on some information other than fstab fs_passno? If 
 systemd knew the root file system type before mounting, it could always issue 
 fsck for ext3/4 and never do it for XFS and Btrfs. Maybe it's fs_passno 
 that's become antiquated? Although this may not be generic enough so early in 
 the boot process for systemd to determine file system type without a mount 
 attempt?


The btrfs wiki recommends not installing btrfsck as /sbin/fsck.btrfs.
Instead, it advises to copy/link a no-op command like /bin/true.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev-212 and up on Sparc v8

[Mike Gilbert]

On Sat, Jun 21, 2014 at 10:04 AM, Cristian Rodríguez
crrodrig...@opensuse.org wrote:
 El 21/06/14 01:38, Chase Rayfield escribió:

 udev up to version 208 builds correctly on Sparc v8. However 212 and
 greater does not.

 Complete build logs of 208 and 214 can be found here:
 https://bugs.gentoo.org/show_bug.cgi?id=514016

 Any suggestions or alternatives to how we can fix this would be
 appreciated.

 This affects old Sun hardware, Leon Sparc, and the sparc implementation
 being developed at temlib.org  it may also affect other
 architectures that I am not aware of.

 Thanks,
 Chase Rayfield


 Not a systemd problem. please ix your tool-chain. systemd does not even use
 __sync_sub_and_fetch_4(), this is a function that ought to be proviided by
 the compiler or libgcc .


systemd does use __sync_sub_and_fetch, which probably gets mapped to
__sync_sub_and_fetch_4 somewhere.

src/shared/refcnt.h:#define REFCNT_DEC(r) (__sync_sub_and_fetch((r)._value, 1))
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] udev-212 and up on Sparc v8

[Mike Gilbert]

On Sat, Jun 21, 2014 at 11:31 AM, Mike Gilbert flop...@gentoo.org wrote:
 On Sat, Jun 21, 2014 at 10:04 AM, Cristian Rodríguez
 crrodrig...@opensuse.org wrote:
 El 21/06/14 01:38, Chase Rayfield escribió:

 udev up to version 208 builds correctly on Sparc v8. However 212 and
 greater does not.

 Complete build logs of 208 and 214 can be found here:
 https://bugs.gentoo.org/show_bug.cgi?id=514016

 Any suggestions or alternatives to how we can fix this would be
 appreciated.

 This affects old Sun hardware, Leon Sparc, and the sparc implementation
 being developed at temlib.org  it may also affect other
 architectures that I am not aware of.

 Thanks,
 Chase Rayfield


 Not a systemd problem. please ix your tool-chain. systemd does not even use
 __sync_sub_and_fetch_4(), this is a function that ought to be proviided by
 the compiler or libgcc .


 systemd does use __sync_sub_and_fetch, which probably gets mapped to
 __sync_sub_and_fetch_4 somewhere.

 src/shared/refcnt.h:#define REFCNT_DEC(r) (__sync_sub_and_fetch((r)._value, 
 1))

Also, from the gcc manual:

https://gcc.gnu.org/onlinedocs/gcc-4.7.4/gcc/_005f_005fsync-Builtins.html

 Not all operations are supported by all target processors. If a particular 
 operation cannot be implemented on the target processor, a warning will be 
 generated and a call an external function will be generated. The external 
 function will carry the same name as the builtin, with an additional suffix 
 ‘_n’ where n is the size of the data type.

If I interpret that correctly, systemd would need to define
_sync_sub_and_fetch_4 when building for 32-bit processors which do not
support the __sync_sub_and_fetch operation natively.
___
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

[Mike Gilbert]

On Wed, Jun 11, 2014 at 12:15 PM, Kirill Elagin kirela...@gmail.com wrote:
 On Wed, Jun 11, 2014 at 3:24 AM, Mike Gilbert flop...@gentoo.org wrote:

 On Tue, Jun 10, 2014 at 5:50 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Tue, 10.06.14 13:58, Mike Gilbert (flop...@gentoo.org) 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
 
  The problem with installing these symlinks as part of a package is
  that the user may have removed them from /etc/systemd using systemctl
  disable. The next time they install systemd, the package puts the
  symlinks right back.
 
  Again, that's exactly what happens for configuration files too if you
  use automake: on make install they are replaced by the original,
  upstream versions. Why is recreating the symlinks bad, if overriding the
  config files isn't?
 

 People don't generally remove config files; they just make changes.

 On the other hand, removing the symlinks would be a very typical
 action due to the way systemctl disable works. There is some ambiguity
 as to what a missing symlink means: did the sysadmin remove it, or did
 it never exist in the first place?


 But there is `equery f`, so it shouldn't be too hard to figure this out,
 right?


It is one thing to query the package database with a tool designed for
users. It is quite another to modify our package manager to use the
information in an intelligent way. Patches are welcome, as always.
___
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

[Mike Gilbert]

On Wed, Jun 11, 2014 at 4:56 PM, Mike Gilbert flop...@gentoo.org wrote:
 On Wed, Jun 11, 2014 at 12:15 PM, Kirill Elagin kirela...@gmail.com wrote:
 On Wed, Jun 11, 2014 at 3:24 AM, Mike Gilbert flop...@gentoo.org wrote:

 On Tue, Jun 10, 2014 at 5:50 PM, Lennart Poettering
 lenn...@poettering.net wrote:
  On Tue, 10.06.14 13:58, Mike Gilbert (flop...@gentoo.org) 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
 
  The problem with installing these symlinks as part of a package is
  that the user may have removed them from /etc/systemd using systemctl
  disable. The next time they install systemd, the package puts the
  symlinks right back.
 
  Again, that's exactly what happens for configuration files too if you
  use automake: on make install they are replaced by the original,
  upstream versions. Why is recreating the symlinks bad, if overriding the
  config files isn't?
 

 People don't generally remove config files; they just make changes.

 On the other hand, removing the symlinks would be a very typical
 action due to the way systemctl disable works. There is some ambiguity
 as to what a missing symlink means: did the sysadmin remove it, or did
 it never exist in the first place?


 But there is `equery f`, so it shouldn't be too hard to figure this out,
 right?


 It is one thing to query the package database with a tool designed for
 users. It is quite another to modify our package manager to use the
 information in an intelligent way. Patches are welcome, as always.

Actually, I think I have talked myself into working on such an
enhancement myself. Thanks.
___
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

[Mike Gilbert]

On Tue, Jun 10, 2014 at 1:32 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Tue, 10.06.14 13:10, Dave Reisner (d...@falconindy.com) wrote:

 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.

 This sounds fragile... people should get the same results if they avoid
 DESTDIR= or if they use it and then copy the result to /... I mean,
 that's how DESTDIR has been traditionally defined, and I don't think we
 should add any magic to that...

  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).

 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


The problem with installing these symlinks as part of a package is
that the user may have removed them from /etc/systemd using systemctl
disable. The next time they install systemd, the package puts the
symlinks right back.

Gentoo's Portage package manager has functionality to protect modified
config files under /etc from being overwritten during reinstalls and
upgrades. However, this protection does not apply to files which have
been removed entirely by the sysadmin.

We can implement post-install logic to avoid this problem, but that
means we either need to remove the symlinks from DESTDIR manually or
we need the build system to not create them in the first place.

If rpm or dpkg have a way to detect when the sysadmin has removed a
file and will not replace that file, that's news to me.
___
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

[Mike Gilbert]

On Tue, Jun 10, 2014 at 5:50 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Tue, 10.06.14 13:58, Mike Gilbert (flop...@gentoo.org) 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

 The problem with installing these symlinks as part of a package is
 that the user may have removed them from /etc/systemd using systemctl
 disable. The next time they install systemd, the package puts the
 symlinks right back.

 Again, that's exactly what happens for configuration files too if you
 use automake: on make install they are replaced by the original,
 upstream versions. Why is recreating the symlinks bad, if overriding the
 config files isn't?


People don't generally remove config files; they just make changes.

On the other hand, removing the symlinks would be a very typical
action due to the way systemctl disable works. There is some ambiguity
as to what a missing symlink means: did the sysadmin remove it, or did
it never exist in the first place?

If systemctl disable would do something like create a symlink to
/dev/null, that would be easier to detect.

I suppose we should implement something like Debian's conffiles to
protect file removals, but that's probably not going to be a very high
priority given the small number of packages for which it really
matters.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to quiet cron sessions logging with systemd-212?

[Mike Gilbert]

On Mon, Jun 9, 2014 at 4:42 PM, Reindl Harald h.rei...@thelounge.net wrote:

 Am 09.06.2014 22:32, schrieb Leonid Isaev:
 On Mon, Jun 09, 2014 at 09:19:20PM +0200, Reindl Harald wrote:
 [...]

 on our production infrastrcuture these messages would be
 *a lot* more than all other logs summarized

 *and* they are spitted to /var/log/messages to make things worst

 But why can't you write a syslog filter which uses facility as well as 
 program
 name? So if you believe that systemd-generated messages are useless, drop 
 them

 because you *can not* distinguish between *that* user messages
 and system message sbecause they have systemd as program name
 common, the PID changes and you don't want to drop *system
 messages* from systemd

 So, systemd starts certain things on _any_ user login: be it a real user, 
 or
 a daemon. However

 * why do it need to do that much stuff
 * why can't it keep that stuff long-running

 you have already /usr/lib/systemd/systemd --user and (sd-pam)
 processes for every userid ever started a cronjob running all
 the time - so why flood the logs every minute again?


Now that you mention it, you can cut down on a lot of the log spam by
enabling linger for root and other users which run cron jobs.

loginctl enable-linger user

This will keep a systemd user instance running so that a new one is
not spawned every time cron wakes up.
___
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

[Mike Gilbert]

On Sat, May 17, 2014 at 4:02 PM, Cristian Rodríguez
crrodrig...@opensuse.org wrote:
 El 17/05/14 14:56, Dave Reisner escribió:
 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.

 That was the initial purpose of this variable, yes. Currently is just
 to provide a separate variable for hardened builds.

 Note that I did not came up with this idea, It is just the way things
 are done elsewhere, where elsewhere is util-linux, policykit, various
 gnome components,enlightment,samba etc..


Looking through the source of a few of these packages:

util-linux-2.24.1: SUID_CFLAGS is utilized in Makefile.am for specific binaries.
polkit-0.112: SUID_CFLAGS is utilized in Makefile.am for specific binaries.
samba-3.6.19: SUID_CFLAGS does not appear in the source tarball.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH v2] fsck: Search for fsck.type in PATH

[Mike Gilbert]

Modifies find_binary() to accept NULL in the second argument.

fsck.type lookup logic moved to new fsck_exists() function, with a test.
---
 src/fsck/fsck.c|  9 -
 src/shared/generator.c | 11 ---
 src/shared/path-util.c | 11 ---
 src/shared/util.c  |  8 
 src/shared/util.h  |  2 ++
 src/test/test-util.c   | 11 +++
 6 files changed, 37 insertions(+), 15 deletions(-)

diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
index 18f2aca..520b1a6 100644
--- a/src/fsck/fsck.c
+++ b/src/fsck/fsck.c
@@ -285,14 +285,13 @@ int main(int argc, char *argv[]) {
 
 type = udev_device_get_property_value(udev_device, ID_FS_TYPE);
 if (type) {
-const char *checker = strappenda(/sbin/fsck., type);
-r = access(checker, X_OK);
+r = fsck_exists(type);
 if (r  0) {
-if (errno == ENOENT) {
-log_info(%s doesn't exist, not checking file 
system., checker);
+if (r == -ENOENT) {
+log_info(fsck.%s doesn't exist, not checking 
file system., type);
 return EXIT_SUCCESS;
 } else
-log_warning(%s cannot be used: %m, checker);
+log_warning(fsck.%s cannot be used: %s, 
type, strerror(-r));
 }
 }
 
diff --git a/src/shared/generator.c b/src/shared/generator.c
index 6110303..86d30e7 100644
--- a/src/shared/generator.c
+++ b/src/shared/generator.c
@@ -19,6 +19,7 @@
   along with systemd; If not, see http://www.gnu.org/licenses/.
 ***/
 
+#include string.h
 #include unistd.h
 
 #include util.h
@@ -45,16 +46,12 @@ int generator_write_fsck_deps(
 }
 
 if (!isempty(fstype)  !streq(fstype, auto)) {
-const char *checker;
 int r;
-
-checker = strappenda(/sbin/fsck., fstype);
-r = access(checker, X_OK);
+r = fsck_exists(fstype);
 if (r  0) {
-log_warning(Checking was requested for %s, but %s 
cannot be used: %m, what, checker);
-
+log_warning(Checking was requested for %s, but 
fsck.%s cannot be used: %s, what, what, strerror(-r));
 /* treat missing check as essentially OK */
-return errno == ENOENT ? 0 : -errno;
+return r == -ENOENT ? 0 : r;
 }
 }
 
diff --git a/src/shared/path-util.c b/src/shared/path-util.c
index bdc54a9..a530dbe 100644
--- a/src/shared/path-util.c
+++ b/src/shared/path-util.c
@@ -425,7 +425,6 @@ int path_is_os_tree(const char *path) {
 
 int find_binary(const char *name, char **filename) {
 assert(name);
-assert(filename);
 
 if (strchr(name, '/')) {
 char *p;
@@ -437,7 +436,10 @@ int find_binary(const char *name, char **filename) {
 if (!p)
 return -ENOMEM;
 
-*filename = p;
+if (filename)
+*filename = p;
+else
+free(p);
 return 0;
 } else {
 const char *path;
@@ -464,7 +466,10 @@ int find_binary(const char *name, char **filename) {
 }
 
 path_kill_slashes(p);
-*filename = p;
+if (filename)
+*filename = p;
+else
+free(p);
 
 return 0;
 }
diff --git a/src/shared/util.c b/src/shared/util.c
index ffe6624..4cdb561 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -6391,3 +6391,11 @@ void hexdump(FILE *f, const void *p, size_t s) {
 s -= 16;
 }
 }
+
+int fsck_exists(const char *fstype)
+{
+const char *checker;
+
+checker = strappenda(fsck., fstype);
+return find_binary(checker, NULL);
+}
diff --git a/src/shared/util.h b/src/shared/util.h
index 90464c9..45a6f26 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -922,3 +922,5 @@ 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);
+
+int fsck_exists(const char *fstype);
diff --git a/src/test/test-util.c b/src/test/test-util.c
index 93929cd..148e54c 100644
--- a/src/test/test-util.c
+++ b/src/test/test-util.c
@@ -675,6 +675,16 @@ static void test_foreach_string(void) {
 assert_se(streq(x, zzz));
 }
 
+static void test_fsck_exists(void) {
+/* Ensure we use a sane default for PATH. */
+unsetenv(PATH);
+
+/* fsck.minix is provided by util-linux and will probably exist. */
+assert(fsck_exists(minix) == 0);
+
+

Re: [systemd-devel] [PATCH v2] fsck: Search for fsck.type in PATH

[Mike Gilbert]

On Sat, Apr 12, 2014 at 1:40 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 On Sat, Apr 12, 2014 at 12:07:04PM -0400, Mike Gilbert wrote:
 Modifies find_binary() to accept NULL in the second argument.

 fsck.type lookup logic moved to new fsck_exists() function, with a test.
 ---
  src/fsck/fsck.c|  9 -
  src/shared/generator.c | 11 ---
  src/shared/path-util.c | 11 ---
  src/shared/util.c  |  8 
  src/shared/util.h  |  2 ++
  src/test/test-util.c   | 11 +++
  6 files changed, 37 insertions(+), 15 deletions(-)

 diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
 index 18f2aca..520b1a6 100644
 --- a/src/fsck/fsck.c
 +++ b/src/fsck/fsck.c
 @@ -285,14 +285,13 @@ int main(int argc, char *argv[]) {

  type = udev_device_get_property_value(udev_device, ID_FS_TYPE);
  if (type) {
 -const char *checker = strappenda(/sbin/fsck., type);
 -r = access(checker, X_OK);
 +r = fsck_exists(type);
  if (r  0) {
 -if (errno == ENOENT) {
 -log_info(%s doesn't exist, not checking 
 file system., checker);
 +if (r == -ENOENT) {
 +log_info(fsck.%s doesn't exist, not 
 checking file system., type);
  return EXIT_SUCCESS;
  } else
 -log_warning(%s cannot be used: %m, 
 checker);
 +log_warning(fsck.%s cannot be used: %s, 
 type, strerror(-r));
  }
  }

 diff --git a/src/shared/generator.c b/src/shared/generator.c
 index 6110303..86d30e7 100644
 --- a/src/shared/generator.c
 +++ b/src/shared/generator.c
 @@ -19,6 +19,7 @@
along with systemd; If not, see http://www.gnu.org/licenses/.
  ***/

 +#include string.h
  #include unistd.h

  #include util.h
 @@ -45,16 +46,12 @@ int generator_write_fsck_deps(
  }

  if (!isempty(fstype)  !streq(fstype, auto)) {
 -const char *checker;
  int r;
 -
 -checker = strappenda(/sbin/fsck., fstype);
 -r = access(checker, X_OK);
 +r = fsck_exists(fstype);
  if (r  0) {
 -log_warning(Checking was requested for %s, but %s 
 cannot be used: %m, what, checker);
 -
 +log_warning(Checking was requested for %s, but 
 fsck.%s cannot be used: %s, what, what, strerror(-r));

 The second arg should probably be fstype not what.


Right, I'll fix that.

  /* treat missing check as essentially OK */
 -return errno == ENOENT ? 0 : -errno;
 +return r == -ENOENT ? 0 : r;
  }
  }

 diff --git a/src/shared/path-util.c b/src/shared/path-util.c
 index bdc54a9..a530dbe 100644
 --- a/src/shared/path-util.c
 +++ b/src/shared/path-util.c
 @@ -425,7 +425,6 @@ int path_is_os_tree(const char *path) {

  int find_binary(const char *name, char **filename) {
  assert(name);
 -assert(filename);

  if (strchr(name, '/')) {
  char *p;
 @@ -437,7 +436,10 @@ int find_binary(const char *name, char **filename) {
  if (!p)
  return -ENOMEM;

 -*filename = p;
 +if (filename)
 +*filename = p;
 +else
 +free(p);
 Allocating a string just to free it in the next line doesn't make sense.


Yeah, this one could probably be adjusted not to do that. I was trying
to change as little as possible.

  return 0;
  } else {
  const char *path;
 @@ -464,7 +466,10 @@ int find_binary(const char *name, char **filename) {
  }

  path_kill_slashes(p);
 -*filename = p;
 +if (filename)
 +*filename = p;
 +else
 +free(p);
 Likewise, no need to mangle the string just to free it.


Ah, yeah. I guess this would work:

if (filename)
path_kill_slashes(p);
*filename = p;
else
free(p);


  return 0;
  }
 diff --git a/src/shared/util.c b/src/shared/util.c
 index ffe6624..4cdb561 100644
 --- a/src/shared/util.c
 +++ b/src/shared/util.c
 @@ -6391,3 +6391,11 @@ void hexdump(FILE *f, const void *p, size_t s) {
  s -= 16;
  }
  }
 +
 +int fsck_exists(const char *fstype)
 +{
 Brace should go on the end of previous line.

 +const char *checker;
 +
 +checker = strappenda(fsck., fstype);
 +return find_binary(checker, NULL);
 +}
 diff --git a/src/shared/util.h b/src/shared/util.h
 index 90464c9..45a6f26 100644
 --- a/src/shared/util.h

Re: [systemd-devel] [PATCH v2] fsck: Search for fsck.type in PATH

[Mike Gilbert]

On Sat, Apr 12, 2014 at 3:10 PM, Mike Gilbert flop...@gentoo.org wrote:
 On Sat, Apr 12, 2014 at 1:40 PM, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl wrote:
 +static void test_fsck_exists(void) {
 +/* Ensure we use a sane default for PATH. */
 +unsetenv(PATH);
 +
 +/* fsck.minix is provided by util-linux and will probably exist. */
 +assert(fsck_exists(minix) == 0);
 +
 +assert(fsck_exists(AbCdE) == -ENOENT);
 +}
 assert_se().


 We are comparing integers, not strings. This matches the other integer
 comparisons in this source file.


I guess I have misinterpreted what assert_se means... is that
documented somewhere?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH v3] fsck: Search for fsck.type in PATH

[Mike Gilbert]

Modifies find_binary() to accept NULL in the second argument.

fsck.type lookup logic moved to new fsck_exists() function, with a test.
---
 src/fsck/fsck.c   | 10 +-
 src/shared/generator.c| 12 +---
 src/shared/path-util.c| 33 ++---
 src/shared/path-util.h|  2 ++
 src/test/test-path-util.c | 11 +++
 5 files changed, 45 insertions(+), 23 deletions(-)

diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
index 18f2aca..5ed837d 100644
--- a/src/fsck/fsck.c
+++ b/src/fsck/fsck.c
@@ -37,6 +37,7 @@
 #include bus-errors.h
 #include fileio.h
 #include udev-util.h
+#include path-util.h
 
 static bool arg_skip = false;
 static bool arg_force = false;
@@ -285,14 +286,13 @@ int main(int argc, char *argv[]) {
 
 type = udev_device_get_property_value(udev_device, ID_FS_TYPE);
 if (type) {
-const char *checker = strappenda(/sbin/fsck., type);
-r = access(checker, X_OK);
+r = fsck_exists(type);
 if (r  0) {
-if (errno == ENOENT) {
-log_info(%s doesn't exist, not checking file 
system., checker);
+if (r == -ENOENT) {
+log_info(fsck.%s doesn't exist, not checking 
file system., type);
 return EXIT_SUCCESS;
 } else
-log_warning(%s cannot be used: %m, checker);
+log_warning(fsck.%s cannot be used: %s, 
type, strerror(-r));
 }
 }
 
diff --git a/src/shared/generator.c b/src/shared/generator.c
index 6110303..5ac7b5f 100644
--- a/src/shared/generator.c
+++ b/src/shared/generator.c
@@ -19,6 +19,7 @@
   along with systemd; If not, see http://www.gnu.org/licenses/.
 ***/
 
+#include string.h
 #include unistd.h
 
 #include util.h
@@ -26,6 +27,7 @@
 #include mkdir.h
 #include unit-name.h
 #include generator.h
+#include path-util.h
 
 int generator_write_fsck_deps(
 FILE *f,
@@ -45,16 +47,12 @@ int generator_write_fsck_deps(
 }
 
 if (!isempty(fstype)  !streq(fstype, auto)) {
-const char *checker;
 int r;
-
-checker = strappenda(/sbin/fsck., fstype);
-r = access(checker, X_OK);
+r = fsck_exists(fstype);
 if (r  0) {
-log_warning(Checking was requested for %s, but %s 
cannot be used: %m, what, checker);
-
+log_warning(Checking was requested for %s, but 
fsck.%s cannot be used: %s, what, fstype, strerror(-r));
 /* treat missing check as essentially OK */
-return errno == ENOENT ? 0 : -errno;
+return r == -ENOENT ? 0 : r;
 }
 }
 
diff --git a/src/shared/path-util.c b/src/shared/path-util.c
index bdc54a9..8ac96f9 100644
--- a/src/shared/path-util.c
+++ b/src/shared/path-util.c
@@ -425,19 +425,20 @@ int path_is_os_tree(const char *path) {
 
 int find_binary(const char *name, char **filename) {
 assert(name);
-assert(filename);
 
 if (strchr(name, '/')) {
-char *p;
+if (filename) {
+char *p;
 
-if (path_is_absolute(name))
-p = strdup(name);
-else
-p = path_make_absolute_cwd(name);
-if (!p)
-return -ENOMEM;
+if (path_is_absolute(name))
+p = strdup(name);
+else
+p = path_make_absolute_cwd(name);
+if (!p)
+return -ENOMEM;
+*filename = p;
+}
 
-*filename = p;
 return 0;
 } else {
 const char *path;
@@ -463,8 +464,11 @@ int find_binary(const char *name, char **filename) {
 continue;
 }
 
-path_kill_slashes(p);
-*filename = p;
+if (filename) {
+path_kill_slashes(p);
+*filename = p;
+} else
+free(p);
 
 return 0;
 }
@@ -507,3 +511,10 @@ bool paths_check_timestamp(const char* const* paths, 
usec_t *timestamp, bool upd
 
 return changed;
 }
+
+int fsck_exists(const char *fstype) {
+const char *checker;
+
+checker = strappenda(fsck., fstype);
+return find_binary(checker, NULL);
+}
diff --git a/src/shared/path-util.h b/src/shared/path-util.h
index 2b8ea02..fdf1f6b 100644
--- a/src/shared/path-util.h
+++ 

Re: [systemd-devel] [PATCH] fsck: Search for fsck.type in PATH

[Mike Gilbert]

On Fri, Apr 11, 2014 at 11:48 AM, Lennart Poettering
lenn...@poettering.net wrote:
 On Wed, 09.04.14 10:07, Mike Gilbert (flop...@gentoo.org) wrote:

 Matches default behavior in recent util-linux.

 Quite frankly, this is really really broken in Gentoo. Randomly moving
 packages from /sbin to /usr/sbin that are required during early boot is
 just wrong. Either you keep the distinction between the two dirs, and
 then fsck clearly belongs in /sbin, and not /usr/sbin, or you remove the
 distinction, and then /sbin should be a symlink to /usr/sbin so that the
 distinction doesn't matter.

 But this scheme that Gentoo is following there, is just a recipe for
 breaking almost every possible package.

 The /usr merge is about increasing compatibility by providing everything
 in both dirs. But Gentoo is really decreasing compatibility with itself
 here by randomly moving things around and not providing things under the
 old location. Really, you should rethink this, it's bogus! Entirely and
 completely bogus!


As I said before, I don't maintain the dosfsprogs package, so I
personally have no control over this. I'm not a fan of randomly moving
things around either.

I will pass along your comments to our base-system team.

 Anyway, even though I strongl disagree with how Gentoo is handling the
 transition here, the patch looks OK and should probably go in.


Thank you for reviewing. I will make another pass on this over the weekend.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] fsck: Search for fsck.type in PATH

[Mike Gilbert]

Matches default behavior in recent util-linux.
---
 src/fsck/fsck.c| 6 --
 src/shared/generator.c | 6 --
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/src/fsck/fsck.c b/src/fsck/fsck.c
index 18f2aca..24c8890 100644
--- a/src/fsck/fsck.c
+++ b/src/fsck/fsck.c
@@ -36,6 +36,7 @@
 #include bus-error.h
 #include bus-errors.h
 #include fileio.h
+#include path-util.h
 #include udev-util.h
 
 static bool arg_skip = false;
@@ -285,8 +286,9 @@ int main(int argc, char *argv[]) {
 
 type = udev_device_get_property_value(udev_device, ID_FS_TYPE);
 if (type) {
-const char *checker = strappenda(/sbin/fsck., type);
-r = access(checker, X_OK);
+const char *checker = strappenda(fsck., type);
+_cleanup_free_ char *command = NULL;
+r = find_binary(checker, command);
 if (r  0) {
 if (errno == ENOENT) {
 log_info(%s doesn't exist, not checking file 
system., checker);
diff --git a/src/shared/generator.c b/src/shared/generator.c
index 6110303..6f4eaae 100644
--- a/src/shared/generator.c
+++ b/src/shared/generator.c
@@ -24,6 +24,7 @@
 #include util.h
 #include special.h
 #include mkdir.h
+#include path-util.h
 #include unit-name.h
 #include generator.h
 
@@ -46,10 +47,11 @@ int generator_write_fsck_deps(
 
 if (!isempty(fstype)  !streq(fstype, auto)) {
 const char *checker;
+_cleanup_free_ char *command = NULL;
 int r;
 
-checker = strappenda(/sbin/fsck., fstype);
-r = access(checker, X_OK);
+checker = strappenda(fsck., fstype);
+r = find_binary(checker, command);
 if (r  0) {
 log_warning(Checking was requested for %s, but %s 
cannot be used: %m, what, checker);
 
-- 
1.9.1

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

[systemd-devel] fsck.vfat in /usr/sbin

[Mike Gilbert]

Over at Gentoo, we have started installing fsck.vfat in /usr/sbin rather
than /sbin. Don't ask me why; I don't maintain our dosfstools package. ^_^

This works ok with the fsck binary from util-linux since we have it
configured to search in /usr/sbin via the --enable-fs-paths-extra configure
option. It also searches $PATH as a fallback.

However, systemd-fsck only looks in /sbin. Can we change this to match
util-linux? I could probably hack together a patch if necessary.

Gentoo bug report: https://bugs.gentoo.org/show_bug.cgi?id=506654
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] Document CONFIG_NET_NS as a required kernel option

[Mike Gilbert]

Several units now utilize the PrivateNetwork parameter, which requires
network namespace support.
---
 README | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/README b/README
index fc13e10..cecbcbf 100644
--- a/README
+++ b/README
@@ -70,6 +70,9 @@ REQUIREMENTS:
 create additional symlinks in /dev/disk/ and /dev/tape:
   CONFIG_BLK_DEV_BSG
 
+Required for PrivateNetwork in service units:
+  CONFIG_NET_NS
+
 Optional but strongly recommended:
   CONFIG_IPV6
   CONFIG_AUTOFS4_FS
-- 
1.9.1

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

[systemd-devel] [PATCH] build-sys: Fix move-to-rootlibdir

[Mike Gilbert]

Since we now use ln -s --relative, using this sed statement is redundant
and causes broken symlinks to be installed.
---
 Makefile.am | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 182eca6..bd78f44 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -207,9 +207,8 @@ define move-to-rootlibdir
if test $(libdir) != $(rootlibdir); then \
$(MKDIR_P) $(DESTDIR)$(rootlibdir)  \
so_img_name=$$(readlink $(DESTDIR)$(libdir)/$$libname)  \
-   so_img_rel_target_prefix=$$(echo $(libdir) | sed 
's,\(^/\|\)[^/][^/]*,..,g')  \
rm -f $(DESTDIR)$(libdir)/$$libname  \
-   $(LN_S) --relative -f 
$$so_img_rel_target_prefix$(rootlibdir)/$$so_img_name 
$(DESTDIR)$(libdir)/$$libname  \
+   $(LN_S) --relative -f $(DESTDIR)$(rootlibdir)/$$so_img_name 
$(DESTDIR)$(libdir)/$$libname  \
mv $(DESTDIR)$(libdir)/$$libname.* $(DESTDIR)$(rootlibdir); \
fi
 endef
-- 
1.9.0

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

Re: [systemd-devel] [PATCH] build-sys: Fix move-to-rootlibdir

[Mike Gilbert]

On Tue, Mar 11, 2014 at 6:14 PM, Mike Gilbert flop...@gentoo.org wrote:
 Since we now use ln -s --relative, using this sed statement is redundant
 and causes broken symlinks to be installed.

Actually, I think the the symlinks are not broken under normal
circumstances (rootlibdir = /lib). However, they end up with a
duplicate prefix, like this:

/usr/lib64/libsystemd.so - ../../../../lib64/libsystemd.so.0.0.2

This seems to trigger a quirk in Gentoo's package manger (Portage)
when the symlink points outside of DESTDIR.

Either way, this code should get cleaned up, and I would like to see
it tagged as a bugfix if possible.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] build-sys: Fix move-to-rootlibdir

[Mike Gilbert]

On Tue, Mar 11, 2014 at 6:42 PM, Lennart Poettering
lenn...@poettering.net wrote:
 On Tue, 11.03.14 18:14, Mike Gilbert (flop...@gentoo.org) wrote:

 Since we now use ln -s --relative, using this sed statement is redundant
 and causes broken symlinks to be installed.

 Hmm, wouldn't it be nicer to just drop the --relative here?

 Quite honestly, I don't grok the code, neither the old nor the new one...


I'm having a hard time understanding the original code myself, but I
think it is supposed to create a relative symlink without using ln
--relative. It would probably break if rootlibdir is not a directory
immediately under the root directory (/).

I think the newer method is probably more robust, but obviously
requires newer coreutils.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] build-sys: Fix move-to-rootlibdir

[Mike Gilbert]

On Tue, Mar 11, 2014 at 6:53 PM, Mike Gilbert flop...@gentoo.org wrote:
 On Tue, Mar 11, 2014 at 6:42 PM, Lennart Poettering
 lenn...@poettering.net wrote:
 On Tue, 11.03.14 18:14, Mike Gilbert (flop...@gentoo.org) wrote:

 Since we now use ln -s --relative, using this sed statement is redundant
 and causes broken symlinks to be installed.

 Hmm, wouldn't it be nicer to just drop the --relative here?

 Quite honestly, I don't grok the code, neither the old nor the new one...


 I'm having a hard time understanding the original code myself, but I
 think it is supposed to create a relative symlink without using ln
 --relative. It would probably break if rootlibdir is not a directory
 immediately under the root directory (/).


Scratch that last sentence; it should work fine so long as rootlibdir
begins with a slash.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink

[Mike Gilbert]

On Mon, Mar 3, 2014 at 11:57 AM, Lennart Poettering
lenn...@poettering.net wrote:
 On Mon, 03.03.14 16:12, Michael Biebl (mbi...@gmail.com) wrote:

 The patch looked ok to me as is, but I can certainly add a --relative
 if you prefer.

 Should
 dbus1-generator-install-hook:
$(AM_V_at)$(MKDIR_P) $(DESTDIR)$(usergeneratordir)
$(AM_V_LN)$(LN_S) -f
 $(systemgeneratordir)/systemd-dbus1-generator
 $(DESTDIR)$(usergeneratordir)/systemd-dbus1-generator

 be updated then as well?

 I now changed the makefile to only generate relative symlinks. THis
 makes use of ln --relative -s everywhere, which has been supported in
 coreutils for 2y or so, hence I figure this should be OK. If this breaks
 for people we can consider making use of this only after an autoconf check.


Would someone mind adding a Backport note for at least my original
commit? I'm not so sure about tagging Lennart's more extensive change.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] Fix systemd-stdio-bridge symlink

[Mike Gilbert]

The symlink is created in bindir (/usr/bin), and points to a binary
which lives in rootlibexecdir (/lib/systemd or /usr/lib/systemd). A
relative symlink does not work here.
---
 Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 38445fb..e7134a2 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -1978,7 +1978,7 @@ systemd_bus_proxyd_LDADD = \
 
 bus-proxyd-install-hook:
$(AM_V_at)$(MKDIR_P) $(DESTDIR)$(bindir)
-   $(AM_V_LN)$(LN_S) -f ../lib/systemd/systemd-bus-proxyd 
$(DESTDIR)$(bindir)/systemd-stdio-bridge
+   $(AM_V_LN)$(LN_S) -f $(rootlibexecdir)/systemd-bus-proxyd 
$(DESTDIR)$(bindir)/systemd-stdio-bridge
 
 bus-proxyd-uninstall-hook:
rm -f $(DESTDIR)$(bindir)/systemd-stdio-bridge
-- 
1.9.0

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

[systemd-devel] [PATCH] configure: Do not require xsltproc for installation of man pages

[Mike Gilbert]

The release tarballs ship with pre-generated man pages, so we do not
need xsltproc for a typical end-user build.

Developers will probably have xsltproc anyway, but if not they will now
encounter a build-time failure instead of an error in configure.
---
 configure.ac | 7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/configure.ac b/configure.ac
index 8943c96..10ef0f5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -972,12 +972,7 @@ AS_IF([test x$enable_gudev = xyes], [ 
AC_DEFINE(HAVE_GLIB, 1, [Define if gli
 # 
--
 have_manpages=no
 AC_ARG_ENABLE(manpages, AS_HELP_STRING([--disable-manpages], [disable 
manpages]))
-AS_IF([test x$enable_manpages != xno], [
-AS_IF([test x$enable_manpages = xyes -a x$XSLTPROC = x], [
-AC_MSG_ERROR([*** Manpages requested but xsltproc not found])
-])
-AS_IF([test x$XSLTPROC != x], [have_manpages=yes])
-])
+AS_IF([test x$enable_manpages != xno], [have_manpages=yes])
 AM_CONDITIONAL(ENABLE_MANPAGES, [test x$have_manpages = xyes])
 
 # 
--
-- 
1.9.0

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

[systemd-devel] [PATCH] main: Set umask before creating any files

[Mike Gilbert]

This avoids a problem when we inherit a non-zero umask from the
initramfs. This would cause /run/systemd to be created with the wrong
mode.
---
 src/core/main.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/src/core/main.c b/src/core/main.c
index 72bd542..f532dca 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1276,6 +1276,9 @@ int main(int argc, char *argv[]) {
 if (in_initrd())
 initrd_timestamp = userspace_timestamp;
 
+/* Set umask before creating any files. */
+umask(0);
+
 if (!skip_setup) {
 mount_setup_early();
 if (selinux_setup(loaded_policy)  0)
@@ -1339,6 +1342,9 @@ int main(int argc, char *argv[]) {
 kernel_timestamp.monotonic = 0ULL;
 kernel_timestamp.realtime = 0ULL;
 
+/* Set umask before creating any files. */
+umask(0);
+
 } else {
 /* Running as user instance */
 arg_running_as = SYSTEMD_USER;
@@ -1441,9 +1447,6 @@ int main(int argc, char *argv[]) {
 if (arg_running_as == SYSTEMD_SYSTEM) {
 /* Become a session leader if we aren't one yet. */
 setsid();
-
-/* Disable the umask logic */
-umask(0);
 }
 
 /* Move out of the way, so that we won't block unmounts */
-- 
1.8.3.2

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