[systemd-devel] xorg uses 100% CPU after upgrading to 226

[Jin Liu]

After upgrading to 226, the Xorg process keeps using 100% CPU. Also, the
"xrandr --dpi 168" command in my .xinitrc no longer works.

My startx.service and .xinitrc:

$ systemctl cat startx.service
# /etc/systemd/system/startx.service
[Unit]
Description=Direct X login
After=systemd-user-sessions.service
Conflicts=getty@tty1.service

[Service]
User=jin
TTYPath=/dev/tty1
PAMName=login
Environment=DISPLAY=:0
ExecStart=/usr/bin/bash --login -c "cd; (/usr/lib/xorg-server/Xorg
-nolisten tcp vt1 &); source .xinitrc"

[Install]
WantedBy=graphical.target
$ cat .xinitrc
#!/bin/sh

#

# ~/.xinitrc

#

# Executed by startx (run your window manager from here)

export DESKTOP_SESSION="plasma"

if [ -d /etc/X11/xinit/xinitrc.d ]; then
 for f in /etc/X11/xinit/xinitrc.d/*; do
   [ -x "$f" ] && . "$f"
 done
 unset f
fi

xrandr --dpi 168

exec /usr/bin/startkde

$

BTW, if I move the "xrandr --dpi 168" line into /usr/bin/startkde, it works
again (only DPI setting. Xorg still uses 100% CPU).

What change in version 226 could cause the above problem, and how should I
change the above files to fix it? Thanks.

Regards,

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

[systemd-devel] [ANNOUNCE] systemd-227 around the corner

[David Herrmann]

Hi

Continuing with our triweekly release schedule, we plan to release
version 227 the next few days. There are a couple of bugs pinned on
github, which should get fixed beforehand. Other than that, we should
be good to go. Please give it a spin and make sure there is no major
breakage before the release.

Thanks
David
___
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] RFC: removing initctl support

[Michael Biebl]

What we could add is a --disable switch which makes
units/systemd-initctl.{socket,service} and src/initctl/ conditional so
distros that don't need it anymore can disable it (or make it disabled
by default and let distros which need it enable it).

Would that work for you, Lennart?

2015-09-23 1:17 GMT+02:00 Michael Biebl :
> 2015-09-23 0:45 GMT+02:00 Lennart Poettering :
>> On Wed, 23.09.15 00:38, Michael Biebl (mbi...@gmail.com) wrote:
>>
>>> Hi,
>>>
>>> yes, in Debian we'll need /dev/initctl support for at least another
>>> release cycle so users can switch between the init system and safely
>>> reboot (in both directions).
>>
>> How does Debian switch between the init systems? Couldn't you just use
>> the right client for the right init system?
>
> Well, you can't replace the running sysvinit instance with systemd
> (and vice versa).
> That's why we need the sysvinit tools to talk to systemd via
> /dev/initctl and the systemd tools to talk to sysvinit.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Michael Biebl]

2015-09-23 0:45 GMT+02:00 Lennart Poettering :
> On Wed, 23.09.15 00:38, Michael Biebl (mbi...@gmail.com) wrote:
>
>> Hi,
>>
>> yes, in Debian we'll need /dev/initctl support for at least another
>> release cycle so users can switch between the init system and safely
>> reboot (in both directions).
>
> How does Debian switch between the init systems? Couldn't you just use
> the right client for the right init system?

Well, you can't replace the running sysvinit instance with systemd
(and vice versa).
That's why we need the sysvinit tools to talk to systemd via
/dev/initctl and the systemd tools to talk to sysvinit.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Michael Biebl]

Hi,

yes, in Debian we'll need /dev/initctl support for at least another
release cycle so users can switch between the init system and safely
reboot (in both directions).
If it's not too much of a nuisance, it would be great if it could
still be provided a bit longer upstream, otherwise we'll have to carry
it as a downstream patch.
It don't really think the code is bit-rotting, it's simply mature code
which does what it needs to do.
That said, since we will need in Debian anyway, we can just as well
maintain it upstream.

Lennart, do you have any open issues regarding /dev/initctl? We
(myself and I guess Martin as well), can have a look then.

In summary: Please consider keeping the code and if you need someone
to look after it, then I volunteer.

Michael

2015-09-22 13:49 GMT+02:00 Zbigniew Jędrzejewski-Szmek :
> On Tue, Sep 22, 2015 at 02:31:25AM +0200, 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:
> I'd guess that debian might care, as they are trying to keep
> bidirectional compat. Apart from that, meh, probably nobody.
> Let's see what they say.
>
> Zbyszek
>
>> a) there's support in systemctl to reboot the system by sending the
>>right bytes to /dev/initctl as fallback, so that you can reboot a
>>sysvinit system with "systemctl reboot".
>>
>> b) There's a mini-daemon "systemd-initctl.service" that is
>>fifo-activated on /dev/initctl, and forwards reboot requests from
>>old sysvinit clients to systemd.



-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] xorg uses 100% CPU after upgrading to 226

[David Herrmann]

Hi

On Tue, Sep 22, 2015 at 9:23 PM, Jin Liu  wrote:
> After upgrading to 226, the Xorg process keeps using 100% CPU. Also, the
> "xrandr --dpi 168" command in my .xinitrc no longer works.
>
> My startx.service and .xinitrc:
>
> $ systemctl cat startx.service
> # /etc/systemd/system/startx.service
> [Unit]
> Description=Direct X login
> After=systemd-user-sessions.service
> Conflicts=getty@tty1.service
>
> [Service]
> User=jin
> TTYPath=/dev/tty1
> PAMName=login
> Environment=DISPLAY=:0
> ExecStart=/usr/bin/bash --login -c "cd; (/usr/lib/xorg-server/Xorg -nolisten
> tcp vt1 &); source .xinitrc"
>
> [Install]
> WantedBy=graphical.target
> $ cat .xinitrc
> #!/bin/sh
> #
> # ~/.xinitrc
> #
> # Executed by startx (run your window manager from here)
>
> export DESKTOP_SESSION="plasma"
>
> if [ -d /etc/X11/xinit/xinitrc.d ]; then
>  for f in /etc/X11/xinit/xinitrc.d/*; do
>[ -x "$f" ] && . "$f"
>  done
>  unset f
> fi
>
> xrandr --dpi 168
>
> exec /usr/bin/startkde
>
> $
>
> BTW, if I move the "xrandr --dpi 168" line into /usr/bin/startkde, it works
> again (only DPI setting. Xorg still uses 100% CPU).
>
> What change in version 226 could cause the above problem, and how should I
> change the above files to fix it? Thanks.

Please run "strace -p " on the offending process or "perf top".
Then try to figure out which function is spinning.

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

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

[Lennart Poettering]

On Wed, 23.09.15 00:38, Michael Biebl (mbi...@gmail.com) wrote:

> Hi,
> 
> yes, in Debian we'll need /dev/initctl support for at least another
> release cycle so users can switch between the init system and safely
> reboot (in both directions).

How does Debian switch between the init systems? Couldn't you just use
the right client for the right init system?

Lennart

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

Re: [systemd-devel] Implicit unit dependency on slice might be too weak ?

[Francis Moreau]

Hello,

On Mon, Sep 21, 2015 at 7:43 PM, David Herrmann  wrote:
> Hi
>
> On Mon, Sep 21, 2015 at 4:50 PM, Francis Moreau  
> wrote:
>> Hi,
>>
>> If a unit depends on a slice, a Wants=machine.slice is automatically
>> added to the unit constraints.
>>
>> Why is "Requires=machine.slice" not prefered instead ?
>
> Usually "Wants=" is preferred as it makes the units more fail-safe.
> Especially for slices, I cannot see why "Requires=" would be
> beneficial. If a specific unit needs this, a simple
> "Requires=foobar.slice" gets you what you want.
>

But what if the slice fails to start ?

Will the unit asking for a specific slice (which fails to start) be
moved into another slice ? It seems that whatever the final
destination used by systemd, the constraints used by the "fallback"
slice won't be correct, no ?

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

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

[Daniel P. Berrange]

On Tue, Sep 22, 2015 at 02:31:25AM +0200, 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:
> 
> a) there's support in systemctl to reboot the system by sending the
>right bytes to /dev/initctl as fallback, so that you can reboot a
>sysvinit system with "systemctl reboot".
> 
> b) There's a mini-daemon "systemd-initctl.service" that is
>fifo-activated on /dev/initctl, and forwards reboot requests from
>old sysvinit clients to systemd.
> 
> Both of this was supposed to help transition between sysvinit and
> systemd systems: if you mix sysvinit clients with a systemd init
> system and vice versa, you can still use the the tools to reboot the
> other system.
> 
> I'd claim the interface is borderline useless: the only operation you
> can actually readlly properly dispatch with it is rebooting, and
> reloading PID1. And that's pretty much it.
> 
> We never even really used this stuff on Fedora properly (since we
> actually transitioned from Upstart, not sysvinit, and we never had the
> same level of compat for that...).
> 
> This code has been bitrotting for a while, and nobody really cared.
> 
> And most importantly: the entire protocol use by sysvinit via
> /dev/initctl is deeply flawed, since it sends messages over
> /dev/initctl that are not a divisor of PIPE_SIZE in length. Thus, if
> PID 1 didn't read messages quick enough the messages queued could be
> half-written and be partially interleaved with another client's
> messages, and there is no way the system can ever recover from that.
> 
> Thus, I'd really like to kill this. Does anybody care about it, and
> can give me a strong enough reason to keep this anyway?

The libvirt virDomainShutdown|Reboot APIs for triggering controlled
shutdown/reboots of guest OS have support for using /dev/initctl with
containers, as it was the lowest common denominator that easily worked
across systemd, sysvinit & upstart.

We could add further code to use a systemd specific interface if
needed, so it wouldn't be the end of the world of /dev/initctl was
removed, but it'd be nice to not have todo that.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-firstboot skip root password initialisation if /etc/shadow is present

[David Herrmann]

Hi

On Tue, Sep 22, 2015 at 11:07 AM, Francis Moreau  wrote:
> Hello,
>
> On Mon, Sep 21, 2015 at 7:45 PM, David Herrmann  wrote:
>> Hi
>>
>> On Fri, Sep 18, 2015 at 6:31 PM, Francis Moreau  
>> wrote:
>>> Hi,
>>>
>>> I find odd that systemd-firstboot skips root password init if
>>> /etc/shadow exists because AFAICS this file is always part of a
>>> minimal rootfs after being setup by an installer. Indeed it's
>>> populated during package installation.
>>>
>>> So I can't see a case where systemd-firstboot would prompt for a root 
>>> password.
>>
>> If an installer ships a shadow file, then we expect the installer to
>> populate it. The firstboot tool will recover situations where you
>> deleted /etc entirely (eg., factory reset).
>
> From the man page " systemd-firstboot initializes the most basic
> system settings interactively on the first boot, or optionally
> non-interactively when a system image is created."
>
> And when a system image is created, usually root password won't be set
> but it's *very* unlikely that /etc/shadow will be missing. That's the
> reason why I don't think its going to work in real life.

Why would an installer create an empty shadow file?

> BTW, I don't know if recovering when /etc/ has been deleted is
> possible even if systemd-firstboot will restore a couple of conf
> files...

Depending on your distribution, it is.

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

Re: [systemd-devel] systemd-firstboot skip root password initialisation if /etc/shadow is present

[Francis Moreau]

Hello,

On Mon, Sep 21, 2015 at 7:45 PM, David Herrmann  wrote:
> Hi
>
> On Fri, Sep 18, 2015 at 6:31 PM, Francis Moreau  
> wrote:
>> Hi,
>>
>> I find odd that systemd-firstboot skips root password init if
>> /etc/shadow exists because AFAICS this file is always part of a
>> minimal rootfs after being setup by an installer. Indeed it's
>> populated during package installation.
>>
>> So I can't see a case where systemd-firstboot would prompt for a root 
>> password.
>
> If an installer ships a shadow file, then we expect the installer to
> populate it. The firstboot tool will recover situations where you
> deleted /etc entirely (eg., factory reset).

From the man page " systemd-firstboot initializes the most basic
system settings interactively on the first boot, or optionally
non-interactively when a system image is created."

And when a system image is created, usually root password won't be set
but it's *very* unlikely that /etc/shadow will be missing. That's the
reason why I don't think its going to work in real life.

BTW, I don't know if recovering when /etc/ has been deleted is
possible even if systemd-firstboot will restore a couple of conf
files...

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

Re: [systemd-devel] Implicit unit dependency on slice might be too weak ?

[David Herrmann]

Hi

On Tue, Sep 22, 2015 at 10:58 AM, Francis Moreau  wrote:
> Hello,
>
> On Mon, Sep 21, 2015 at 7:43 PM, David Herrmann  wrote:
>> Hi
>>
>> On Mon, Sep 21, 2015 at 4:50 PM, Francis Moreau  
>> wrote:
>>> Hi,
>>>
>>> If a unit depends on a slice, a Wants=machine.slice is automatically
>>> added to the unit constraints.
>>>
>>> Why is "Requires=machine.slice" not prefered instead ?
>>
>> Usually "Wants=" is preferred as it makes the units more fail-safe.
>> Especially for slices, I cannot see why "Requires=" would be
>> beneficial. If a specific unit needs this, a simple
>> "Requires=foobar.slice" gets you what you want.
>>
>
> But what if the slice fails to start ?
>
> Will the unit asking for a specific slice (which fails to start) be
> moved into another slice ? It seems that whatever the final
> destination used by systemd, the constraints used by the "fallback"
> slice won't be correct, no ?

Correct.

You still get a big fat error on your screen and you should fix your
setup. Again, if that's no suitable, you better use "Requires=".

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

Re: [systemd-devel] Implicit unit dependency on slice might be too weak ?

[Francis Moreau]

On Tue, Sep 22, 2015 at 2:18 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Tue, Sep 22, 2015 at 11:52:05AM +0200, Francis Moreau wrote:
>> On Tue, Sep 22, 2015 at 11:14 AM, David Herrmann  
>> wrote:
>> > Hi
>> >
>> > On Tue, Sep 22, 2015 at 10:58 AM, Francis Moreau  
>> > wrote:
>> [...]
>> >>>
>> >>
>> >> But what if the slice fails to start ?
>> >>
>> >> Will the unit asking for a specific slice (which fails to start) be
>> >> moved into another slice ? It seems that whatever the final
>> >> destination used by systemd, the constraints used by the "fallback"
>> >> slice won't be correct, no ?
>> >
>> > Correct.
>> >
>> > You still get a big fat error on your screen and you should fix your
>> > setup. Again, if that's no suitable, you better use "Requires=".
>> >
>>
>> To put a unit in a slice, one uses by default
>>
>>Slice=myslice.slice
>>
>> and the default behaviour is to add Wants=myslice.slice to the unit.
>>
>> If the unit will always fail to start if myslice.slice fails then I
>> would say the default  behaviour should be Requires=myslice.slice.
>
> Does it actually fail? If yes, then Requires= would be better. If not,
> then Wants= should stay.
>

Well that simply means Requires= is more appropriate IMHO.

> (I tried to test this:
> - with a slice with ConditionPathExists= that is false, the
>   slice is not started and the unit is started.

The strange thing is that even if the condition is not met, the slice
is created in the cgroupfs and is used:

# cat >myservice.service

Re: [systemd-devel] Implicit unit dependency on slice might be too weak ?

[Lennart Poettering]

On Mon, 21.09.15 16:50, Francis Moreau (francis.m...@gmail.com) wrote:

> Hi,
> 
> If a unit depends on a slice, a Wants=machine.slice is automatically
> added to the unit constraints.
> 
> Why is "Requires=machine.slice" not prefered instead ?

I think I agree, we should really make this a requires.

Lennart

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

Re: [systemd-devel] systemd-firstboot skip root password initialisation if /etc/shadow is present

[Francis Moreau]

On Tue, Sep 22, 2015 at 11:16 AM, David Herrmann  wrote:
> Hi
>
> On Tue, Sep 22, 2015 at 11:07 AM, Francis Moreau  
> wrote:
>> Hello,
>>
>> On Mon, Sep 21, 2015 at 7:45 PM, David Herrmann  
>> wrote:
>>> Hi
>>>
>>> On Fri, Sep 18, 2015 at 6:31 PM, Francis Moreau  
>>> wrote:
 Hi,

 I find odd that systemd-firstboot skips root password init if
 /etc/shadow exists because AFAICS this file is always part of a
 minimal rootfs after being setup by an installer. Indeed it's
 populated during package installation.

 So I can't see a case where systemd-firstboot would prompt for a root 
 password.
>>>
>>> If an installer ships a shadow file, then we expect the installer to
>>> populate it. The firstboot tool will recover situations where you
>>> deleted /etc entirely (eg., factory reset).
>>
>> From the man page " systemd-firstboot initializes the most basic
>> system settings interactively on the first boot, or optionally
>> non-interactively when a system image is created."
>>
>> And when a system image is created, usually root password won't be set
>> but it's *very* unlikely that /etc/shadow will be missing. That's the
>> reason why I don't think its going to work in real life.
>
> Why would an installer create an empty shadow file?

Well during package installation done by the installer, some packages,
usually the ones that installs daemons/services, populates
/etc/shadow.

On Archlinux, after creating a minimal rootfs, shadow file is containing:

bin:x:14871::
daemon:x:14871::
mail:x:14871::
ftp:x:14871::
http:x:14871::
uuidd:x:14871::
dbus:x:14871::
nobody:x:14871::
systemd-journal-gateway:x:14871::
systemd-timesync:x:14871::
systemd-network:x:14871::
systemd-bus-proxy:x:14871::


>
>> BTW, I don't know if recovering when /etc/ has been deleted is
>> possible even if systemd-firstboot will restore a couple of conf
>> files...
>
> Depending on your distribution, it is.

Just out of curiosity, which distros are supposed to support that ?

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

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

[Lennart Poettering]

On Tue, 22.09.15 10:11, Daniel P. Berrange (berra...@redhat.com) wrote:

> > And most importantly: the entire protocol use by sysvinit via
> > /dev/initctl is deeply flawed, since it sends messages over
> > /dev/initctl that are not a divisor of PIPE_SIZE in length. Thus, if
> > PID 1 didn't read messages quick enough the messages queued could be
> > half-written and be partially interleaved with another client's
> > messages, and there is no way the system can ever recover from that.
> > 
> > Thus, I'd really like to kill this. Does anybody care about it, and
> > can give me a strong enough reason to keep this anyway?
> 
> The libvirt virDomainShutdown|Reboot APIs for triggering controlled
> shutdown/reboots of guest OS have support for using /dev/initctl with
> containers, as it was the lowest common denominator that easily worked
> across systemd, sysvinit & upstart.

Ah, I see... But I wasn't aware Upstart even implemented that...

> We could add further code to use a systemd specific interface if
> needed, so it wouldn't be the end of the world of /dev/initctl was
> removed, but it'd be nice to not have todo that.

A simple fall back could be to send SIGRTMIN+4 to PID 1, if
/dev/initctl is not around.

One more addendum to the original mail:

We already declared the interface "obsolete" in the docs, which makes
me particularly keen on dropping it...

Lennart

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

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

[Daniel P. Berrange]

On Tue, Sep 22, 2015 at 12:48:21PM +0200, Lennart Poettering wrote:
> On Tue, 22.09.15 11:41, Daniel P. Berrange (berra...@redhat.com) wrote:
> 
> > > One more addendum to the original mail:
> > > 
> > > We already declared the interface "obsolete" in the docs, which makes
> > > me particularly keen on dropping it...
> > 
> > I guess one thing is that even if support for /dev/intctl in systemd,
> > it is an optional unit file, so libvirt probably needs to deal with
> > the SIGRTMIN+4 stuff anyway, for case where the person building
> > the container has that unit file disabled. So from that POV, deleting
> > it won't make current situation that much worse.
> 
> Also, we support builds with all legacy cruft disabled, which is
> something where inictl currently is not disabled, but if we kept it
> should really be disable under... So I figure even if we keep the
> general support in this is not an interface you can rely on...
> 
> To make the SIGRTMIN+4 reliable all you need to do is check first if
> /run/systemd/system/ exists.

Ok, that's easy enough. So no objection from libvirt if you remove
/dev/initctl in future releases


Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Implicit unit dependency on slice might be too weak ?

[Francis Moreau]

On Tue, Sep 22, 2015 at 11:14 AM, David Herrmann  wrote:
> Hi
>
> On Tue, Sep 22, 2015 at 10:58 AM, Francis Moreau  
> wrote:
[...]
>>>
>>
>> But what if the slice fails to start ?
>>
>> Will the unit asking for a specific slice (which fails to start) be
>> moved into another slice ? It seems that whatever the final
>> destination used by systemd, the constraints used by the "fallback"
>> slice won't be correct, no ?
>
> Correct.
>
> You still get a big fat error on your screen and you should fix your
> setup. Again, if that's no suitable, you better use "Requires=".
>

To put a unit in a slice, one uses by default

   Slice=myslice.slice

and the default behaviour is to add Wants=myslice.slice to the unit.

If the unit will always fail to start if myslice.slice fails then I
would say the default  behaviour should be Requires=myslice.slice.

I think getting an clean error to inform that the slice can't be
started at first and not trying to start the unit (which will crash
anyway) is more appropriate than getting a big fat obscure warning
because my unit will fail to start.

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

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

[Daniel P. Berrange]

On Tue, Sep 22, 2015 at 12:32:25PM +0200, Lennart Poettering wrote:
> On Tue, 22.09.15 10:11, Daniel P. Berrange (berra...@redhat.com) wrote:
> 
> > > And most importantly: the entire protocol use by sysvinit via
> > > /dev/initctl is deeply flawed, since it sends messages over
> > > /dev/initctl that are not a divisor of PIPE_SIZE in length. Thus, if
> > > PID 1 didn't read messages quick enough the messages queued could be
> > > half-written and be partially interleaved with another client's
> > > messages, and there is no way the system can ever recover from that.
> > > 
> > > Thus, I'd really like to kill this. Does anybody care about it, and
> > > can give me a strong enough reason to keep this anyway?
> > 
> > The libvirt virDomainShutdown|Reboot APIs for triggering controlled
> > shutdown/reboots of guest OS have support for using /dev/initctl with
> > containers, as it was the lowest common denominator that easily worked
> > across systemd, sysvinit & upstart.
> 
> Ah, I see... But I wasn't aware Upstart even implemented that...

Maybe it wasn't actually upstart, but one of the other init systems.
I just recall getting a patch from Debian folks to support it via
the /run/initctl path, rather than /dev, and assumed that was upstart
related.

> > We could add further code to use a systemd specific interface if
> > needed, so it wouldn't be the end of the world of /dev/initctl was
> > removed, but it'd be nice to not have todo that.
> 
> A simple fall back could be to send SIGRTMIN+4 to PID 1, if
> /dev/initctl is not around.

Yep, though we'd have to actually check that PID 1 is systemd, since
if you run a container with a non-init program as PID 1, we don't
want to be sending it SIGRTMIN+4 :-)

> One more addendum to the original mail:
> 
> We already declared the interface "obsolete" in the docs, which makes
> me particularly keen on dropping it...

I guess one thing is that even if support for /dev/intctl in systemd,
it is an optional unit file, so libvirt probably needs to deal with
the SIGRTMIN+4 stuff anyway, for case where the person building
the container has that unit file disabled. So from that POV, deleting
it won't make current situation that much worse.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Lennart Poettering]

On Tue, 22.09.15 11:41, Daniel P. Berrange (berra...@redhat.com) wrote:

> > One more addendum to the original mail:
> > 
> > We already declared the interface "obsolete" in the docs, which makes
> > me particularly keen on dropping it...
> 
> I guess one thing is that even if support for /dev/intctl in systemd,
> it is an optional unit file, so libvirt probably needs to deal with
> the SIGRTMIN+4 stuff anyway, for case where the person building
> the container has that unit file disabled. So from that POV, deleting
> it won't make current situation that much worse.

Also, we support builds with all legacy cruft disabled, which is
something where inictl currently is not disabled, but if we kept it
should really be disable under... So I figure even if we keep the
general support in this is not an interface you can rely on...

To make the SIGRTMIN+4 reliable all you need to do is check first if
/run/systemd/system/ exists.

Lennart

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

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

[Zbigniew Jędrzejewski-Szmek]

On Tue, Sep 22, 2015 at 02:31:25AM +0200, 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:
I'd guess that debian might care, as they are trying to keep
bidirectional compat. Apart from that, meh, probably nobody.
Let's see what they say.

Zbyszek

> a) there's support in systemctl to reboot the system by sending the
>right bytes to /dev/initctl as fallback, so that you can reboot a
>sysvinit system with "systemctl reboot".
> 
> b) There's a mini-daemon "systemd-initctl.service" that is
>fifo-activated on /dev/initctl, and forwards reboot requests from
>old sysvinit clients to systemd.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-firstboot skip root password initialisation if /etc/shadow is present

[David Herrmann]

Hi

On Tue, Sep 22, 2015 at 11:59 AM, Francis Moreau  wrote:
> On Tue, Sep 22, 2015 at 11:16 AM, David Herrmann  
> wrote:
>> Hi
>>
>> On Tue, Sep 22, 2015 at 11:07 AM, Francis Moreau  
>> wrote:
>>> Hello,
>>>
>>> On Mon, Sep 21, 2015 at 7:45 PM, David Herrmann  
>>> wrote:
 Hi

 On Fri, Sep 18, 2015 at 6:31 PM, Francis Moreau  
 wrote:
> Hi,
>
> I find odd that systemd-firstboot skips root password init if
> /etc/shadow exists because AFAICS this file is always part of a
> minimal rootfs after being setup by an installer. Indeed it's
> populated during package installation.
>
> So I can't see a case where systemd-firstboot would prompt for a root 
> password.

 If an installer ships a shadow file, then we expect the installer to
 populate it. The firstboot tool will recover situations where you
 deleted /etc entirely (eg., factory reset).
>>>
>>> From the man page " systemd-firstboot initializes the most basic
>>> system settings interactively on the first boot, or optionally
>>> non-interactively when a system image is created."
>>>
>>> And when a system image is created, usually root password won't be set
>>> but it's *very* unlikely that /etc/shadow will be missing. That's the
>>> reason why I don't think its going to work in real life.
>>
>> Why would an installer create an empty shadow file?
>
> Well during package installation done by the installer, some packages,
> usually the ones that installs daemons/services, populates
> /etc/shadow.
>
> On Archlinux, after creating a minimal rootfs, shadow file is containing:
>
> bin:x:14871::
> daemon:x:14871::
> mail:x:14871::
> ftp:x:14871::
> http:x:14871::
> uuidd:x:14871::
> dbus:x:14871::
> nobody:x:14871::
> systemd-journal-gateway:x:14871::
> systemd-timesync:x:14871::
> systemd-network:x:14871::
> systemd-bus-proxy:x:14871::

Then "fix" the installer? These entries look like no-ops to me. We
assume that if the installer touches /etc, then it can as well prompt
for a root-password. If you want to make use of firstboot, we
recommend to adopt an "empty /etc" installer.

If we support looking for "root" in shadow files and prompt if
non-present, we start supporting legacy setups where /etc is
half-populated. We don't want that. Either go full legacy and make
your installer prompt for everything, or go "empty /etc" and firstboot
will take over.

>>
>>> BTW, I don't know if recovering when /etc/ has been deleted is
>>> possible even if systemd-firstboot will restore a couple of conf
>>> files...
>>
>> Depending on your distribution, it is.
>
> Just out of curiosity, which distros are supposed to support that ?

I can trash /etc on Archlinux and boot it as a container just fine. It
doesn't work as a full system, yet. Not all packages have adopted
empty /etc support.

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

Re: [systemd-devel] systemd-firstboot skip root password initialisation if /etc/shadow is present

[Francis Moreau]

On Tue, Sep 22, 2015 at 12:19 PM, David Herrmann  wrote:
> On Tue, Sep 22, 2015 at 11:59 AM, Francis Moreau  
> wrote:
[...]
>>
>> Well during package installation done by the installer, some packages,
>> usually the ones that installs daemons/services, populates
>> /etc/shadow.
>>
>> On Archlinux, after creating a minimal rootfs, shadow file is containing:
>>
>> bin:x:14871::
>> daemon:x:14871::
>> mail:x:14871::
>> ftp:x:14871::
>> http:x:14871::
>> uuidd:x:14871::
>> dbus:x:14871::
>> nobody:x:14871::
>> systemd-journal-gateway:x:14871::
>> systemd-timesync:x:14871::
>> systemd-network:x:14871::
>> systemd-bus-proxy:x:14871::
>
> Then "fix" the installer? These entries look like no-ops to me. We
> assume that if the installer touches /etc, then it can as well prompt
> for a root-password. If you want to make use of firstboot, we
> recommend to adopt an "empty /etc" installer.

That's not about the installer, it's about packages and I suspect that
very few are ready to run without /etc.

And then if it's really the case, I think the man page of
systemd-firstboot should be fixed because it never mentions the words
"stateless" or "empty", which is quite fundamental in the design of
firstboot then.

>
> If we support looking for "root" in shadow files and prompt if
> non-present, we start supporting legacy setups where /etc is
> half-populated. We don't want that. Either go full legacy and make
> your installer prompt for everything, or go "empty /etc" and firstboot
> will take over.
>

What you're calling legacy systems are actually *all* systems
available out there: I don't think there's a actually a lot of
packages which are prepared to do that.

>>>
 BTW, I don't know if recovering when /etc/ has been deleted is
 possible even if systemd-firstboot will restore a couple of conf
 files...
>>>
>>> Depending on your distribution, it is.
>>
>> Just out of curiosity, which distros are supposed to support that ?
>
> I can trash /etc on Archlinux and boot it as a container just fine. It
> doesn't work as a full system, yet.

Sure but what's your point ? your container is running no service at
all, so it's pretty useless.

> Not all packages have adopted empty /etc support.

You meant almost none of them ?

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

Re: [systemd-devel] Implicit unit dependency on slice might be too weak ?

[Zbigniew Jędrzejewski-Szmek]

On Tue, Sep 22, 2015 at 11:52:05AM +0200, Francis Moreau wrote:
> On Tue, Sep 22, 2015 at 11:14 AM, David Herrmann  
> wrote:
> > Hi
> >
> > On Tue, Sep 22, 2015 at 10:58 AM, Francis Moreau  
> > wrote:
> [...]
> >>>
> >>
> >> But what if the slice fails to start ?
> >>
> >> Will the unit asking for a specific slice (which fails to start) be
> >> moved into another slice ? It seems that whatever the final
> >> destination used by systemd, the constraints used by the "fallback"
> >> slice won't be correct, no ?
> >
> > Correct.
> >
> > You still get a big fat error on your screen and you should fix your
> > setup. Again, if that's no suitable, you better use "Requires=".
> >
> 
> To put a unit in a slice, one uses by default
> 
>Slice=myslice.slice
> 
> and the default behaviour is to add Wants=myslice.slice to the unit.
> 
> If the unit will always fail to start if myslice.slice fails then I
> would say the default  behaviour should be Requires=myslice.slice.
Does it actually fail? If yes, then Requires= would be better. If not,
then Wants= should stay.

(I tried to test this:
- with a slice with ConditionPathExists= that is false, the
  slice is not started and the unit is started.
- with a slice that has [Slice] Slice=, the unit is neither started
  nor errors out:

Sep 22 08:09:27 yy systemd[1]: xxx.slice located outside its parent slice. 
Refusing.
Sep 22 08:09:27 yy systemd[1]: Cannot add dependency job for unit xxx.slice, 
ignoring: Unit xxx.slice failed to load: Invalid argument. See system logs and 
'systemctl status xxx.slice' for details.

systemd becomes unresponsive... This looks like a bug. This was
with systemd-219-23.fc22.x86_64, I'll test with something more modern
later.)

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

[systemd-devel] Disabled event sources / errors on sd-bus break the event loop (Looping too fast)

[Krzysztof Kotlenga]

Hi.

There were many reports of "Looping too fast. Throttling execution a
little" behavior but they never got anywhere. Not this time. At least
for this particular case.

Initially I was able to reproduce this issue just by calling `systemctl
restart some_specific_service` - then most of further `systemctl`
actions (except status) caused systemd to enter an infinite event loop.

Long story short, I found out that entering some garbage
on /run/systemd/private with netcat breaks systemd equally well.
`systemctl daemon-reexec` fixes it. But before you decide to break
yours PID 1 event loop, I recommend the following gdb script, because
it provides some possibly interesting output:

#v+
b event_prepare
commands 1
set $size = e->prepare->n_items
set $enabled_after_disabled = 0
set $i = 0
while $i < $size
set $s = (sd_event_source*)e->prepare->items[$i].data
if $s->type == SOURCE_IO
printf "%s e=%d pri=%d pi=%u fd=%d\n", \
$s->description, $s->enabled, $s->priority, \
$s->pending_iteration, $s->io.fd
else
printf "%s e=%d\n", $s->description, $s->enabled
end

if $i++ > 0
if $s->enabled == SD_EVENT_ON && $previous->enabled == SD_EVENT_OFF
set $enabled_after_disabled = 1
end
end

set $previous = $s
end

if $enabled_after_disabled
print "XXX shouldn't happen?"
else
continue
end
end
#v-

Now let's follow this. Output shortened for brevity.

1. Attach to systemd and let it run. You will most likely see some
event source, not of particular interest, like this:

bus-input e=1 pri=0 pi=0 fd=12

2.  All is good. Run `nc -U /run/systemd/private`

bus-input e=1 pri=0 pi=0 fd=18
bus-input e=1 pri=0 pi=0 fd=12

3. We are here too. Enter a newline.

bus-input e=1 pri=0 pi=0 fd=12
bus-input e=0 pri=0 pi=15 fd=18

4. This bus-input event source got disabled by source_dispatch, because
bus_socket_auth_verify_server returned -EIO. Now wait, hit Ctrl+C,
generate some events with systemctl - whatever.

bus-input e=0 pri=0 pi=15 fd=18
bus-input e=1 pri=0 pi=0 fd=12
$1 = "XXX shouldn't happen?"

5. The event loop is broken now. It haven't entered an infinite loop
*yet* but calls like `systemctl restart whatever` will cause it. The
reason is that prepare callbacks in event_prepare (sd-event.c) aren't
called anymore - the for loop there breaks on the first disabled source.

The prepare callback of the bus that systemctl talks on (most
importantly sd_bus_get_events) is called only once and sets
POLLIN|POLLOUT flags. That POLLOUT is left there as long as the client
is on the bus and causes an infinite event loop.

When we exit that hanging systemctl, systemd quits looping but the
event loop is still broken. That disabled bus-input from point 4 is
left there forever and prevents prepare callbacks of the enabled event
sources to run.

So, how many bugs are here?

It seems that there are other errors than can happen in sd-bus /
bus-socket, which bus_process_internal (sd-bus.c) doesn't handle and
leaves the disabled event source sitting there forever. Those disabled
event sources are:
- a memory leak?
- very good at breaking event_prepare (sd-event.c).

What's going on with order in that "prepare" Prioq?

This has been debugged on v225, but AFAICS master has the same issues.

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

Re: [systemd-devel] systemd-firstboot skip root password initialisation if /etc/shadow is present

[David Herrmann]

Hi

On Tue, Sep 22, 2015 at 2:26 PM, Francis Moreau  wrote:
> On Tue, Sep 22, 2015 at 12:19 PM, David Herrmann  
> wrote:
>> On Tue, Sep 22, 2015 at 11:59 AM, Francis Moreau  
>> wrote:
> [...]
>>>
>>> Well during package installation done by the installer, some packages,
>>> usually the ones that installs daemons/services, populates
>>> /etc/shadow.
>>>
>>> On Archlinux, after creating a minimal rootfs, shadow file is containing:
>>>
>>> bin:x:14871::
>>> daemon:x:14871::
>>> mail:x:14871::
>>> ftp:x:14871::
>>> http:x:14871::
>>> uuidd:x:14871::
>>> dbus:x:14871::
>>> nobody:x:14871::
>>> systemd-journal-gateway:x:14871::
>>> systemd-timesync:x:14871::
>>> systemd-network:x:14871::
>>> systemd-bus-proxy:x:14871::
>>
>> Then "fix" the installer? These entries look like no-ops to me. We
>> assume that if the installer touches /etc, then it can as well prompt
>> for a root-password. If you want to make use of firstboot, we
>> recommend to adopt an "empty /etc" installer.
>
> That's not about the installer, it's about packages and I suspect that
> very few are ready to run without /etc.

Ok, then fix those packages.

> And then if it's really the case, I think the man page of
> systemd-firstboot should be fixed because it never mentions the words
> "stateless" or "empty", which is quite fundamental in the design of
> firstboot then.
>
>>
>> If we support looking for "root" in shadow files and prompt if
>> non-present, we start supporting legacy setups where /etc is
>> half-populated. We don't want that. Either go full legacy and make
>> your installer prompt for everything, or go "empty /etc" and firstboot
>> will take over.
>>
>
> What you're calling legacy systems are actually *all* systems
> available out there: I don't think there's a actually a lot of
> packages which are prepared to do that.

We fix the packages we care about. I encourage everyone to do the
same. All upstream systemd can do is provide a guideline.


> BTW, I don't know if recovering when /etc/ has been deleted is
> possible even if systemd-firstboot will restore a couple of conf
> files...

 Depending on your distribution, it is.
>>>
>>> Just out of curiosity, which distros are supposed to support that ?
>>
>> I can trash /etc on Archlinux and boot it as a container just fine. It
>> doesn't work as a full system, yet.
>
> Sure but what's your point ? your container is running no service at
> all, so it's pretty useless.

Why? You can store static configuration in /usr just fine. The point
is to get rid of _runtime_ configuration in /etc that can be modified.
Instead, you should ship vendor configuration via /usr (or
/usr/factory if packages are broken), and make it *read-only*.

>> Not all packages have adopted empty /etc support.
>
> You meant almost none of them ?

No.

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

Re: [systemd-devel] systemd-firstboot skip root password initialisation if /etc/shadow is present

[Francis Moreau]

On Tue, Sep 22, 2015 at 2:35 PM, David Herrmann  wrote:
> Hi
>
> On Tue, Sep 22, 2015 at 2:26 PM, Francis Moreau  
> wrote:
>> On Tue, Sep 22, 2015 at 12:19 PM, David Herrmann  
>> wrote:
>>> On Tue, Sep 22, 2015 at 11:59 AM, Francis Moreau  
>>> wrote:
>> [...]

 Well during package installation done by the installer, some packages,
 usually the ones that installs daemons/services, populates
 /etc/shadow.

 On Archlinux, after creating a minimal rootfs, shadow file is containing:

 bin:x:14871::
 daemon:x:14871::
 mail:x:14871::
 ftp:x:14871::
 http:x:14871::
 uuidd:x:14871::
 dbus:x:14871::
 nobody:x:14871::
 systemd-journal-gateway:x:14871::
 systemd-timesync:x:14871::
 systemd-network:x:14871::
 systemd-bus-proxy:x:14871::
>>>
>>> Then "fix" the installer? These entries look like no-ops to me. We
>>> assume that if the installer touches /etc, then it can as well prompt
>>> for a root-password. If you want to make use of firstboot, we
>>> recommend to adopt an "empty /etc" installer.
>>
>> That's not about the installer, it's about packages and I suspect that
>> very few are ready to run without /etc.
>
> Ok, then fix those packages.
>
>> And then if it's really the case, I think the man page of
>> systemd-firstboot should be fixed because it never mentions the words
>> "stateless" or "empty", which is quite fundamental in the design of
>> firstboot then.
>>
>>>
>>> If we support looking for "root" in shadow files and prompt if
>>> non-present, we start supporting legacy setups where /etc is
>>> half-populated. We don't want that. Either go full legacy and make
>>> your installer prompt for everything, or go "empty /etc" and firstboot
>>> will take over.
>>>
>>
>> What you're calling legacy systems are actually *all* systems
>> available out there: I don't think there's a actually a lot of
>> packages which are prepared to do that.
>
> We fix the packages we care about. I encourage everyone to do the
> same. All upstream systemd can do is provide a guideline.
>
>
>> BTW, I don't know if recovering when /etc/ has been deleted is
>> possible even if systemd-firstboot will restore a couple of conf
>> files...
>
> Depending on your distribution, it is.

 Just out of curiosity, which distros are supposed to support that ?
>>>
>>> I can trash /etc on Archlinux and boot it as a container just fine. It
>>> doesn't work as a full system, yet.
>>
>> Sure but what's your point ? your container is running no service at
>> all, so it's pretty useless.
>
> Why? You can store static configuration in /usr just fine. The point
> is to get rid of _runtime_ configuration in /etc that can be modified.

You mean here put runtime configuration in /etc. don't you ?

> Instead, you should ship vendor configuration via /usr (or
> /usr/factory if packages are broken), and make it *read-only*.
>

The condition to run systemd-firstboot.service is
ConditionFirstBoot=yes which means /etc/machine-id should not exist.
But that's different from /etc/ should be empty.

Also the man page doesnt mention the need of an emtpy /etc or a
stateless system.

I can understand your point of systemd-firstboot is for stateless
systems, but again this should be documented.

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