[systemd-devel] Configuring wakeup-online at runtime with networkctl

[Francis Moreau]

Hello,

I would like to know if it's possible to configure an interface at
runtime to enable wol without rebooting my machine.

I tried to create a link file that has WakeOnLan=magic and did
'networkctl reconfigure ens0' but it doesn't work.

Also is it possible to display the status of wakeup online with
'networkctl status' ?

Thank you.
-- 
Francis

Re: [systemd-devel] network config breaks when starting a nspawn container

[Francis Moreau]

On Thu, Jan 27, 2022 at 7:26 AM Francis Moreau  wrote:
>
> Hi,
>
> systemd-networkd creates a bridge 'br0':
>
> $ cat /etc/systemd/network/30-br0.network
> [Match]
> Name=br0
>
> [Network]
> DHCP=ipv4
> Domains=~.
>
> The bridge has one slave 'bond0' by default. The bond device is used
> to
> aggregate my ethernet card and my wifi card (configured by NM).
>
> systemd-resolved is also used.
>
> Every thing works until I start a container 'c1' which should connect
> to br0:
>

Interestingly this only happens when the active interface in the bond
device is the wifi interface.

[systemd-devel] network config breaks when starting a nspawn container

[Francis Moreau]

Hi,

systemd-networkd creates a bridge 'br0':

$ cat /etc/systemd/network/30-br0.network
[Match]
Name=br0

[Network]
DHCP=ipv4
Domains=~.

The bridge has one slave 'bond0' by default. The bond device is used
to
aggregate my ethernet card and my wifi card (configured by NM).

systemd-resolved is also used.

Every thing works until I start a container 'c1' which should connect
to br0:

$ cat /etc/systemd/nspawn/c1.nspawn
[Exec]
PrivateUsers=off

[Network]
Bridge=br0

A few seconds later, the bridge lost its IP, no more route.

I can see this in the journal:

Jan 27 06:44:40 h200 systemd[1]: Starting Container c1...
Jan 27 06:44:40 h200 systemd-udevd[8148]: ethtool: autonegotiation is
unset or enabled, the speed and duplex are not writable.
Jan 27 06:44:40 h200 systemd-networkd[568]: vb-c1: Link UP
Jan 27 06:44:40 h200 kernel: br0: port 2(vb-c1) entered blocking state
Jan 27 06:44:40 h200 kernel: br0: port 2(vb-c1) entered disabled state
Jan 27 06:44:40 h200 kernel: device vb-c1 entered promiscuous mode
Jan 27 06:44:40 h200 kernel: br0: port 2(vb-c1) entered blocking state
Jan 27 06:44:40 h200 kernel: br0: port 2(vb-c1) entered forwarding
state
Jan 27 06:44:40 h200 kernel: br0: port 2(vb-c1) entered disabled state
Jan 27 06:44:40 h200 systemd-udevd[8148]: Using default interface
naming scheme 'v238'.
Jan 27 06:44:40 h200 systemd-networkd[568]: br0: DHCP lease lost
Jan 27 06:44:40 h200 NetworkManager[8437]:   [1643262280.6795]
manager: (vb-c1): new Veth device
(/org/freedesktop/NetworkManager/Devices/11)
Jan 27 06:44:40 h200 systemd-machined[28861]: New machine c1.
Jan 27 06:44:40 h200 systemd[1]: Started Container c1.
[...]
Jan 27 06:44:42 h200 systemd-networkd[568]: vb-c1: Gained IPv6LL
Jan 27 06:44:44 h200 systemd-resolved[913]: Using degraded feature set
UDP instead of UDP+EDNS0 for DNS server fd0f:ee:b0::1.
Jan 27 06:44:47 h200 systemd-resolved[913]: Using degraded feature set
TCP instead of UDP for DNS server fd0f:ee:b0::1.
Jan 27 06:44:57 h200 systemd-resolved[913]: Using degraded feature set
UDP instead of TCP for DNS server fd0f:ee:b0::1.
Jan 27 06:45:00 h200 systemd-resolved[913]: Using degraded feature set
TCP instead of UDP for DNS server fd0f:ee:b0::1.

If I stop the container then network is back.

This happens with systemd v246.

Could anyody help me fixing this issue ?

Thank you.
-- 
Francis

[systemd-devel] Why does sd_path_lookup(SD_PATH_TMPFILES, ..) return one path ?

[Francis Moreau]

Hello,

I was expecting that this function returns all paths where tmpfiles
can be stored but it returns only "/usr/lib/tmpfiles.d".

Why doesn't it return also "/etc/tmpfiles.d" ?

Thanks you
-- 
Francis

Re: [systemd-devel] How to restart my socket activated service safely ?

[Francis Moreau]

On Tue, Jul 27, 2021 at 11:12 AM Mantas Mikulėnas  wrote:
>
> On Tue, Jul 27, 2021 at 10:10 AM Francis Moreau  
> wrote:
> >
> > Hello,
> >
> > During my application update, I want to restart my service which is
> > activated by a socket but want to be sure that no request sent to my
> > service will be missed. I also want to restart the socket too so
> > systemd uses the latest version of the socket unit file.
> >
> > If I restart the socket when the service is still running then I get
> > an error message: "rotor.socket: Socket service rotor.service already
> > active, refusing."
> >
> > If I stop the service first and restart the socket then there's a
> > short time frame where requests can be lost.
>
> The old socket has to be unbound before a new one can be put in its
> place. Trying to keep the service alive (holding the old listener fd)
> would just result in systemd not being able to bind a new socket with
> the same address... (And even if that was possible, the old service
> wouldn't be able to handle requests arriving on the new socket
> anyway.)
>
> So whenever you restart a socket, there will *always* be a short time
> frame where the old socket is closed but the new one is not yet
> bound/listening. But as soon as the new one is listening, it'll start
> queuing the requests even if the service isn't yet running (since it's
> a socket-activated service after all) and the number of lost requests
> should be minimal.

Thank you for response.

If the service only is restarted, will be there also requests that can be lost ?

If the service is restarted then it's first stopped but in the
meantime the socket unit should be listening for new requests...

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

[systemd-devel] How to restart my socket activated service safely ?

[Francis Moreau]

Hello,

During my application update, I want to restart my service which is
activated by a socket but want to be sure that no request sent to my
service will be missed. I also want to restart the socket too so
systemd uses the latest version of the socket unit file.

If I restart the socket when the service is still running then I get
an error message: "rotor.socket: Socket service rotor.service already
active, refusing."

If I stop the service first and restart the socket then there's a
short time frame where requests can be lost.

What is the recommended way to restart my service ?

Thank you in advance.
-- 
Francis
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How can I simply check that a service has been restarted ?

[Francis Moreau]

On Tue, Nov 10, 2020 at 6:35 PM Luca Boccassi  wrote:
>
> On Tue, 2020-11-10 at 17:22 +, Luca Boccassi wrote:
> > On Tue, 2020-11-10 at 18:12 +0100, Francis Moreau wrote:
> > > On Tue, Nov 10, 2020 at 2:43 PM Luca Boccassi  wrote:
> > > > On Tue, 2020-11-10 at 11:50 +0100, Francis Moreau wrote:
> > > > > On Tue, Nov 10, 2020 at 11:30 AM Lennart Poettering
> > > > >  wrote:
> > > > > > On Di, 10.11.20 10:28, Francis Moreau (francis.m...@gmail.com) 
> > > > > > wrote:
> > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > After restarting a service with "systemctl try-restart ..." I 
> > > > > > > want to
> > > > > > > verify that the service has been restarted.
> > > > > > >
> > > > > > > How can I reliably do this without using the dbus API ?
> > > > > >
> > > > > > D-Bus is how systemd exposes its state. If you don't want to use 
> > > > > > that,
> > > > > > you won't get the state information.
> > > > > >
> > > > >
> > > > > dbus is overkill for my little bash script.
> > > >
> > > > It's pretty simple, and a one-liner, to get the value of a property
> > > > from a bash script with busctl. Eg:
> > > >
> > > > $ busctl get-property org.freedesktop.systemd1 
> > > > /org/freedesktop/systemd1/unit/gdm_2eservice 
> > > > org.freedesktop.systemd1.Service Restart
> > > > s "always"
> > > >
> > >
> > > Thank you but I'm not interested in the Restart property of a service,
> > > I want to know if a service as been restarted.
> >
> > It's just an example on how to get D-Bus data on units easily from a
> > bash script.
>
> Eg:
>
> $ busctl get-property org.freedesktop.systemd1 
> /org/freedesktop/systemd1/unit/gdm_2eservice org.freedesktop.systemd1.Service 
> NRestarts
> u 0
>

I didn't know NRestart property, thanks. But it only counts automatic
restart, not manual one.

And also there's no need to use busctl, for getting service properties
I can use 'systemctl show -p'

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

Re: [systemd-devel] How can I simply check that a service has been restarted ?

[Francis Moreau]

On Tue, Nov 10, 2020 at 2:43 PM Luca Boccassi  wrote:
>
> On Tue, 2020-11-10 at 11:50 +0100, Francis Moreau wrote:
> > On Tue, Nov 10, 2020 at 11:30 AM Lennart Poettering
> >  wrote:
> > > On Di, 10.11.20 10:28, Francis Moreau (francis.m...@gmail.com) wrote:
> > >
> > > > Hello,
> > > >
> > > > After restarting a service with "systemctl try-restart ..." I want to
> > > > verify that the service has been restarted.
> > > >
> > > > How can I reliably do this without using the dbus API ?
> > >
> > > D-Bus is how systemd exposes its state. If you don't want to use that,
> > > you won't get the state information.
> > >
> >
> > dbus is overkill for my little bash script.
>
> It's pretty simple, and a one-liner, to get the value of a property
> from a bash script with busctl. Eg:
>
> $ busctl get-property org.freedesktop.systemd1 
> /org/freedesktop/systemd1/unit/gdm_2eservice org.freedesktop.systemd1.Service 
> Restart
> s "always"
>

Thank you but I'm not interested in the Restart property of a service,
I want to know if a service as been restarted.

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

Re: [systemd-devel] How can I simply check that a service has been restarted ?

[Francis Moreau]

On Tue, Nov 10, 2020 at 12:47 PM Arian Van Putten  wrote:
>
> I think what you might want is `Type=exec` instead of `Type=simple` in your 
> unit file.  It was recently added to systemd.
>
> then `systemctl restart` will return a failure when the main process fails to 
> start. I hope that helps.

Thank you however I don't control the type of the restarted units, it
can be anything,

>
>
> On Tue, Nov 10, 2020 at 11:50 AM Francis Moreau  
> wrote:
>>
>> On Tue, Nov 10, 2020 at 11:30 AM Lennart Poettering
>>  wrote:
>> >
>> > On Di, 10.11.20 10:28, Francis Moreau (francis.m...@gmail.com) wrote:
>> >
>> > > Hello,
>> > >
>> > > After restarting a service with "systemctl try-restart ..." I want to
>> > > verify that the service has been restarted.
>> > >
>> > > How can I reliably do this without using the dbus API ?
>> >
>> > D-Bus is how systemd exposes its state. If you don't want to use that,
>> > you won't get the state information.
>> >
>>
>> dbus is overkill for my little bash script.
>>
>> --
>> Francis
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
>
>
> --
>
> Arian van Putten  l  Software Engineer
>
> @arian_wire on Wire
>
> Wire - Secure team messaging.
>
>  Zeta Project Germany GmbH  l  Rosenthaler Straße 40, 10178 Berlin, Germany
>
> Geschäftsführer/Managing Director: Morten J. Broegger
>
> HRB 149847 beim Handelsregister Charlottenburg, Berlin
>
> VAT-ID DE288748675



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

Re: [systemd-devel] How can I simply check that a service has been restarted ?

[Francis Moreau]

On Tue, Nov 10, 2020 at 11:30 AM Lennart Poettering
 wrote:
>
> On Di, 10.11.20 10:28, Francis Moreau (francis.m...@gmail.com) wrote:
>
> > Hello,
> >
> > After restarting a service with "systemctl try-restart ..." I want to
> > verify that the service has been restarted.
> >
> > How can I reliably do this without using the dbus API ?
>
> D-Bus is how systemd exposes its state. If you don't want to use that,
> you won't get the state information.
>

dbus is overkill for my little bash script.

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

[systemd-devel] How can I simply check that a service has been restarted ?

[Francis Moreau]

Hello,

After restarting a service with "systemctl try-restart ..." I want to
verify that the service has been restarted.

How can I reliably do this without using the dbus API ?

Thank you
-- 
Francis
___
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 ?

[Francis Moreau]

On Fri, Sep 25, 2020 at 4:59 PM Mantas Mikulėnas  wrote:
>
> On Fri, Sep 25, 2020, 17:46 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.
>
>
> It depends on whether the _first_ matching file is used, or whether the 
> _last_ matching file is used – different programs choose differently. (If the 
> program merges all files, it still depends on whether the first value of a 
> particular setting is used, or whether the last one is used.)
>
> As mentioned in systemd.link(5), udev only chooses one .link file per 
> interface – just the first one that matched – therefore 00 is the highest 
> priority.

I see, thank you.

-- 
Francis
___
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 ?

[Francis Moreau]

On Fri, Sep 25, 2020 at 4:59 PM Mike Gilbert  wrote:
>
> 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.

Oh thank you I missed this part.

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

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

[Francis Moreau]

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

Re: [systemd-devel] Why systemd keeps references on passed sockets ?

[Francis Moreau]

On Tue, Sep 8, 2020 at 5:41 PM Lennart Poettering
 wrote:
>
> On Di, 08.09.20 17:35, Francis Moreau (francis.m...@gmail.com) wrote:
>
> > On Mon, Sep 7, 2020 at 4:38 PM Lennart Poettering
> >  wrote:
> > >
> > > "React on the socket close?" — What do you mean by that?
> > >
> >
> > I mean if my service explicitly calls close() then systemd could stop
> > the socket on its side so its are freed until the service is
> > restarted. I think it is what you described below.
>
> close() just drops a ref to the socket. Only when close() drops the
> last ref something actually happens on the socket and it is
> destroyed. This means: systemd doesn't get notified about your code
> invoking close(), because all you did is drop one ref of many.
>
> > > Note that on Linux you can invoke shutdown() on a listening socket
> > > (i.e. not just on the connection socket, but on a listening
> > > socket). iirc in that case systemd actually notices and will put the
> > > .socket unit in failure mode...
> > >
> >
> > I looked at the code and there is:
> >
> > if (state != SOCKET_LISTENING)
> > socket_unwatch_fds(s);
> >
> > So I'm not sure how systemd can react on shutdown(). And I tried to
> > call shutdown() in my service but it has no effects.
>
> Hmm, that suggests we'd have to slightly update our logic then for
> this to work: keep the listening fds in the poll, but turn off all
> the EPOLLIN bit we listen on.
>
> > > Would that work for you? (Maybe we could even tweak this a bit in
> > > systemd, so that when you invoke shutdown() on the socket systemd
> > > holds for you we do not consider that a failure anymore, but a clean
> > > way to tell systemd to stop the socket).
> >
> > That is a good idea especially if systemd doesn't consider an error
> > when the service closes or shutdown the socket.
> >
> > But again in the code I can see:
> >
> >   sd_event_add_io(UNIT(s)->manager->event, >event_source, p->fd,
> > EPOLLIN, socket_dispatch_io, p);
> >
> > It seems that it only listens to "EPOLLIN" events. So it doesn't
> > listen to "EPOLLUP".
>
> EPOLLHUP is always implied, you don't have to specify it. if you
> specifiy zero as mask you will still get notified about EPOLLHUP +
> EPOLLERR.
>

Thank you for the info

> But you are right we currently remove the fd from polling while the
> socket's service is running. We'd have to change that (as mentioned
> above). happy to review a PR for that.

I'm afraid I'm not skilled enough in systemd internals to work on this, sorry.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Why systemd keeps references on passed sockets ?

[Francis Moreau]

On Mon, Sep 7, 2020 at 4:38 PM Lennart Poettering
 wrote:
>
> "React on the socket close?" — What do you mean by that?
>

I mean if my service explicitly calls close() then systemd could stop
the socket on its side so its are freed until the service is
restarted. I think it is what you described below.

> Note that on Linux you can invoke shutdown() on a listening socket
> (i.e. not just on the connection socket, but on a listening
> socket). iirc in that case systemd actually notices and will put the
> .socket unit in failure mode...
>

I looked at the code and there is:

if (state != SOCKET_LISTENING)
socket_unwatch_fds(s);

So I'm not sure how systemd can react on shutdown(). And I tried to
call shutdown() in my service but it has no effects.

> Would that work for you? (Maybe we could even tweak this a bit in
> systemd, so that when you invoke shutdown() on the socket systemd
> holds for you we do not consider that a failure anymore, but a clean
> way to tell systemd to stop the socket).

That is a good idea especially if systemd doesn't consider an error
when the service closes or shutdown the socket.

But again in the code I can see:

  sd_event_add_io(UNIT(s)->manager->event, >event_source, p->fd,
EPOLLIN, socket_dispatch_io, p);

It seems that it only listens to "EPOLLIN" events. So it doesn't
listen to "EPOLLUP".

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

Re: [systemd-devel] Why systemd keeps references on passed sockets ?

[Francis Moreau]

On Sat, Sep 5, 2020 at 12:18 AM Lennart Poettering
 wrote:
>
> On Fr, 04.09.20 21:53, Francis Moreau (francis.m...@gmail.com) wrote:
>
> > Hi,
> >
> > I have a service which is activated by a socket unit. When systemd
> > passes the (netlink) socket to my service it seems that it still keeps
> > a reference on the socket, at least ss(8) showed this.
> >
> > Is this expected ? If yes can this be prevented ?
> >
> > I'm asking because my service may not need the socket in some cases
> > hence it closes it but systemd keeps it open and the socket keeps
> > receiving messages and consuming memory for nothing.
>
> It's how socket activation works really (at least with Accept=no): pid
> 1 allocate the socket and activates your service every time something
> happens on it, except if your service is already running. Thus a
> service can auto-start, process one or more events on it, can exit
> when idle, or even crash, it doesn't matter, no traffic is lost
> (except the very datagram it was processing or the connection that it
> was handling when it crashed), and as soon as POLLIN is seen on the
> socket again the service is started again can continue where it left
> off.
>
> You are apparently looking for a different model? i.e. where automatic
> restart and exit-on-idle do not exist? A model like that is currently
> not implemented. Can you elaborate on the usecase?
>

My service is listening several sockets (which are all pased by
systemd) but depending on user configuration my service may not need
to use all sockets and in this case it would be great if the sockets
not needed stop receiving messages and theirs resources are released.

 I tried to close the socket but nothing seems to happen.

Couldn't systemd react on the socket close and if the service still
runs then it closes the socket until it detects the service is stopped
?

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

[systemd-devel] Why systemd keeps references on passed sockets ?

[Francis Moreau]

Hi,

I have a service which is activated by a socket unit. When systemd
passes the (netlink) socket to my service it seems that it still keeps
a reference on the socket, at least ss(8) showed this.

Is this expected ? If yes can this be prevented ?

I'm asking because my service may not need the socket in some cases
hence it closes it but systemd keeps it open and the socket keeps
receiving messages and consuming memory for nothing.

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

Re: [systemd-devel] No DHCP server is started with DHCPServer=yes

[Francis Moreau]

On Wed, May 6, 2020 at 11:47 PM Lennart Poettering
 wrote:
>
> On Mi, 06.05.20 23:43, Francis Moreau (francis.m...@gmail.com) wrote:
>
> > Hi,
> >
> > I'm running systemd v245 (in the host and in the containers) and I
> > have 2 containers whose veth link is connected to a bridge.
> >
> > One container named "c1" uses "DHCPServer=yes" and is supposed to
> > provide an ipv4 address to the second container "c2" but for some
> > reasons it seems that no DHCP server is started in "c1". At least
> > "journalctl -u systemd-networkd | grep DHCP" doesn't show anything
> > interesting although the debug logs have been enabled.
> >
> > I monitored the DHCP traffic in "c1" andI could see the DISCOVER
> > requests sent by "c2" but no answer from "c1". So it really seems that
> > no DHCP server is running in "c1".
> >
> > Could anybody tell me how I could make sure that no DHCP server has
> > been started and help me understanding why ?
>
> Are you sure your .network files match on the iface properly? What
> does "networkctl status" say about the interface?
>

Yes I am pretty sure because the rest of the setting in my .network
file has been taken into account, For example, it also defines a
static address for "c1" which is correctly set.

# networkctl status host0
● 2: host0
 Link File: n/a
  Network File: /etc/systemd/network/50-dhcp-server.network
  Type: ether
 State: routable (configured)
HW Address: 36:1a:18:6b:19:52
   MTU: 1500 (min: 68, max: 65535)
  Queue Length (Tx/Rx): 1/1
  Auto negotiation: no
 Speed: 10Gbps
Duplex: full
  Port: tp
   Address: 44.0.0.1
fe80::341a:18ff:fe6b:1952
   Gateway: 44.0.0.1

May 07 01:56:00 node1 systemd-networkd[20]: host0: Addresses set
May 07 01:56:00 node1 systemd-networkd[20]: host0: Configuring route:
dst: n/a, src: n/a, gw: 44.0.0.1, p>
May 07 01:56:00 node1 systemd-networkd[20]: host0: Setting routes
May 07 01:56:00 node1 systemd-networkd[20]: host0: Received remembered
route: dst: n/a, src: n/a, gw: 44.>
May 07 01:56:00 node1 systemd-networkd[20]: host0: Routes set
May 07 01:56:02 node1 systemd-networkd[20]: host0: Remembering foreign
address: fe80::341a:18ff:fe6b:1952>
May 07 01:56:02 node1 systemd-networkd[20]: host0: Gained IPv6LL
May 07 01:56:02 node1 systemd-networkd[20]: host0: Discovering IPv6 routers
May 07 01:56:02 node1 systemd-networkd[20]: host0: Remembering route:
dst: fe80::341a:18ff:fe6b:1952/128,>
May 07 01:56:14 node1 systemd-networkd[20]: host0: State changed:
configuring -> configured

I also tried to remove
/usr/lib/systemd/network/80-container-host0.network because it's
unclear to me if it's completely overriden by my .network file or not.
According to the output of 'networkctl status' it seems so becuase
only my network file is listed but after reading systemd.network man
page, I'm really not sure. But without 80-container-host0.network it
doesn't work.

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

[systemd-devel] No DHCP server is started with DHCPServer=yes

[Francis Moreau]

Hi,

I'm running systemd v245 (in the host and in the containers) and I
have 2 containers whose veth link is connected to a bridge.

One container named "c1" uses "DHCPServer=yes" and is supposed to
provide an ipv4 address to the second container "c2" but for some
reasons it seems that no DHCP server is started in "c1". At least
"journalctl -u systemd-networkd | grep DHCP" doesn't show anything
interesting although the debug logs have been enabled.

I monitored the DHCP traffic in "c1" andI could see the DISCOVER
requests sent by "c2" but no answer from "c1". So it really seems that
no DHCP server is running in "c1".

Could anybody tell me how I could make sure that no DHCP server has
been started and help me understanding why ?

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

Re: [systemd-devel] Backup the current boot logs in raw format

[Francis Moreau]

On Thu, Aug 1, 2019 at 10:36 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Thu, Aug 01, 2019 at 10:26:50AM +0200, Francis Moreau wrote:
> > On Thu, Aug 1, 2019 at 9:45 AM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > >
> > > On Thu, Aug 01, 2019 at 09:11:19AM +0200, Francis Moreau wrote:
> > > > On Wed, Jul 24, 2019 at 4:08 PM Zbigniew Jędrzejewski-Szmek
> > > >  wrote:
> > > > > you can export and write to a journal file with:
> > > > >   journalctl -o export ... | /usr/lib/systemd/systemd-journal-remote 
> > > > > -o /tmp/foo.journal -
> > > > > This has the advantage that you can apply any journalctl filter where
> > > > > the dots are, e.g. '-b'.
> > > >
> > > > This doesn't look to work correctly:
> > > >
> > > > $ journalctl -b | head
> > > > -- Logs begin at Thu 2017-04-13 14:05:51 CEST, end at Thu 2019-08-01
> > > > 08:51:39 CEST. --
> > > > Mar 25 06:51:35 crapovo kernel: microcode: microcode updated early to
> > > > revision 0x25, date = 2018-04-02
> > > >
> > > > $ journalctl -o export -b | /usr/lib/systemd/systemd-journal-remote -o
> > > > /tmp/foo.journal -
> > > > $ journalctl -b --file=/tmp/foo.journal | head
> > > > -- Logs begin at Sat 2019-06-22 18:32:31 CEST, end at Thu 2019-08-01
> > > > 08:45:45 CEST. --
> > > > Jun 22 18:32:31 crapovo polkitd[1278]: Unregistered Authentication
> > > > Agent for unix-process:7300:772806437 (system bus name :1.4562, object
> > > > path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale
> > > > en_US.UTF-8) (disconnected from bus)
> > > >
> > > > As you can see, the start is not the same.
> > > >
> > > > Also are foo.journal data compressed ?
> > >
> > > What does "ls /tmp/foo*" say?
> > >
> >
> > /tmp/foo@4e9f5da4aaac4433bc8744fe49e25b5a-0001-000584e4cc1ef61f.journal
> >  /tmp/foo.journal
>
> systemd-journal-remote will "rotate" files when they grow above certain size.
> (The same as systemd-journald). 'journalctl --file=/tmp/foo*.journal' should
> do the trick.

Indeed that did the trick, thanks !

It's a bit counterintuitive because I asked the journal to be saved in
/tmp/foo.journal only. Can this "rotation" be disabled somehow ?

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

Re: [systemd-devel] Backup the current boot logs in raw format

[Francis Moreau]

On Thu, Aug 1, 2019 at 9:45 AM Zbigniew Jędrzejewski-Szmek
 wrote:
>
> On Thu, Aug 01, 2019 at 09:11:19AM +0200, Francis Moreau wrote:
> > On Wed, Jul 24, 2019 at 4:08 PM Zbigniew Jędrzejewski-Szmek
> >  wrote:
> > > you can export and write to a journal file with:
> > >   journalctl -o export ... | /usr/lib/systemd/systemd-journal-remote -o 
> > > /tmp/foo.journal -
> > > This has the advantage that you can apply any journalctl filter where
> > > the dots are, e.g. '-b'.
> >
> > This doesn't look to work correctly:
> >
> > $ journalctl -b | head
> > -- Logs begin at Thu 2017-04-13 14:05:51 CEST, end at Thu 2019-08-01
> > 08:51:39 CEST. --
> > Mar 25 06:51:35 crapovo kernel: microcode: microcode updated early to
> > revision 0x25, date = 2018-04-02
> >
> > $ journalctl -o export -b | /usr/lib/systemd/systemd-journal-remote -o
> > /tmp/foo.journal -
> > $ journalctl -b --file=/tmp/foo.journal | head
> > -- Logs begin at Sat 2019-06-22 18:32:31 CEST, end at Thu 2019-08-01
> > 08:45:45 CEST. --
> > Jun 22 18:32:31 crapovo polkitd[1278]: Unregistered Authentication
> > Agent for unix-process:7300:772806437 (system bus name :1.4562, object
> > path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale
> > en_US.UTF-8) (disconnected from bus)
> >
> > As you can see, the start is not the same.
> >
> > Also are foo.journal data compressed ?
>
> What does "ls /tmp/foo*" say?
>

/tmp/foo@4e9f5da4aaac4433bc8744fe49e25b5a-0001-000584e4cc1ef61f.journal
 /tmp/foo.journal

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

Re: [systemd-devel] Backup the current boot logs in raw format

[Francis Moreau]

On Wed, Jul 24, 2019 at 4:08 PM Zbigniew Jędrzejewski-Szmek
 wrote:
> you can export and write to a journal file with:
>   journalctl -o export ... | /usr/lib/systemd/systemd-journal-remote -o 
> /tmp/foo.journal -
> This has the advantage that you can apply any journalctl filter where
> the dots are, e.g. '-b'.

This doesn't look to work correctly:

$ journalctl -b | head
-- Logs begin at Thu 2017-04-13 14:05:51 CEST, end at Thu 2019-08-01
08:51:39 CEST. --
Mar 25 06:51:35 crapovo kernel: microcode: microcode updated early to
revision 0x25, date = 2018-04-02

$ journalctl -o export -b | /usr/lib/systemd/systemd-journal-remote -o
/tmp/foo.journal -
$ journalctl -b --file=/tmp/foo.journal | head
-- Logs begin at Sat 2019-06-22 18:32:31 CEST, end at Thu 2019-08-01
08:45:45 CEST. --
Jun 22 18:32:31 crapovo polkitd[1278]: Unregistered Authentication
Agent for unix-process:7300:772806437 (system bus name :1.4562, object
path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale
en_US.UTF-8) (disconnected from bus)

As you can see, the start is not the same.

Also are foo.journal data compressed ?

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

Re: [systemd-devel] Backup the current boot logs in raw format

[Francis Moreau]

On Wed, Jul 24, 2019 at 4:08 PM Zbigniew Jędrzejewski-Szmek
 wrote:
>   journalctl -o export ... | /usr/lib/systemd/systemd-journal-remote -o 
> /tmp/foo.journal -
> This has the advantage that you can apply any journalctl filter where
> the dots are, e.g. '-b'.

Thanks !

It's documented in man page but I wasn't sure that I didn't miss
somthing else because it is a bit strange to use an additional tool
(systemd-journal-remote) to do that.

Something like: journalctl -o raw -b >/tmp/foo.journal

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

[systemd-devel] Backup the current boot logs in raw format

[Francis Moreau]

Hi,

I would like to backup the journal logs for the current boot in a
"raw" format so I can reuse it later with "journalctl
--file=my-backup".

But looking at the different values for "-o" option I can't find the answer.

Could anybody give me some clues ?

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

Re: [systemd-devel] Question about the default value of NamePolicy=

[Francis Moreau]

Hello,

On Wed, Aug 1, 2018 at 7:36 PM, Mantas Mikulėnas  wrote:
>
> AFAIK, "onboard" and (hotplug) "slot" names are mutually exclusive, so their
> relative ordering isn't that important... but if the firmware marks a device
> as on-board *and* also provides a slot number, then it's more likely that
> the slot# is garbage.
>

Thanks for the info.

> Both "onboard" and "slot" are preferred over "path" because they're shorter
> and more descriptive (as long as the firmware provides correct values). The
> path, being based on PCI bus addressing, doesn't say much to most people --
> at best, it's just a stable identifier. (For example, my server's integrated
> NIC port #1 is better named "eno1", not "enp3s0f0".)
>

"path" can also run onto problem when adapters are replaced by new
ones with multiple ports for example.

Would "onboard" or "slot" be a better alternative for such case ?

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

[systemd-devel] Question about the default value of NamePolicy=

[Francis Moreau]

Hello,

I have a question regarding the default value of NamePolicy= defined
in 99-default.link.

The value is "NamePolicy=kernel database onboard slot path"

Could someone explain me why "onbard" is preferred over "slot" which
is preferred over "path" ?

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

[systemd-devel] .network has [Link] and there's already .link

[Francis Moreau]

Hello,

I dont understand .network has [Link] section whereas network device
configuration can also done with .link file.

It seems that there's a overlap... what is the rational here ?

Thank you in advance.
-- 
Francis
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Why "systemctl -H " instead of "ssh -- systemctl"

[Francis Moreau]

Hello,

I'm wondering why systemctl has the -H option whereas one can achieve
the same by calling "ssh  -- systemctl ...".

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

Re: [systemd-devel] What is the recommended way to setup the compose key ?

[Francis Moreau]

On Tue, Nov 28, 2017 at 9:57 AM, Mantas Mikulėnas  wrote:

>
> And where would it get the actual compose definitions from? They have to be
> defined in the keymap itself.
>

on my distro (opensuse Tumbleweed) compose tables and the definition
of the compose key can be found here:

$ ls /usr/share/kbd/keymaps/legacy/include/
compose.8859_7  compose.latin   compose.latin1.cedilla
compose.latin4 compose.winkeys
compose.8859_8  compose.latin1  compose.latin2
compose.shiftctrl  disable.capslock
compose.ctrlperiod  compose.latin1.add  compose.latin3
compose.utf8   vim-compose.latin1

So one can configure the compose key by running "loadkeys
compose.shiftctrl" for example and the same can be done to pick up a
compose table.

It doesn't seem a bad idea to extend /etc/vconsole.conf so it's done
automatically at boot.
-- 
Francis
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] What is the recommended way to setup the compose key ?

[Francis Moreau]

On Tue, Nov 28, 2017 at 9:46 AM, Mantas Mikulėnas <graw...@gmail.com> wrote:
> On Tue, Nov 28, 2017 at 10:35 AM, Francis Moreau <francis.m...@gmail.com>
> wrote:
>>
>> Hello,
>>
>> I'm trying to figure out how I can configure a compose key for the
>> consoles.
>>
>> I looked at man localectl and vconsole.conf but haven't found an answer.
>
>
> You'd need to edit the actual keyboard layout in /usr/share/kbd/keymaps. See
> i386/include/compose.inc and i386/qwerty/{cz,lv}.map.gz for examples.

Do you mean I need to edit my preferred map in /usr/share to include
compose.inc ?

If so I don't think I'm supposed to change any files in /usr/share/kbd...

Wouldn't it be simpler to add the compose key in vconsole.conf so it's
loaded automatically ?

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

[systemd-devel] What is the recommended way to setup the compose key ?

[Francis Moreau]

Hello,

I'm trying to figure out how I can configure a compose key for the consoles.

I looked at man localectl and vconsole.conf but haven't found an answer.

Could anybody give me some hints ?

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

Re: [systemd-devel] Question about systemd-firstboot

[Francis Moreau]

On Thu, Mar 9, 2017 at 5:49 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
>> So if 'ro' is used, systemd-firstboot is not working. If it's expected
>> I think it would worth a note in the documentation.
> It's supposed to work, I think. Please open an issue, it'll be better
> tracked there.
>

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

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

Re: [systemd-devel] Question about systemd-firstboot

[Francis Moreau]

On Thu, Mar 9, 2017 at 5:19 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> It depends on the command-line parameters: 'ro' and 'rw' both work.
> 'rw' is actually recommended if you're using an initramfs.
>

who is recommending 'rw' ?

do you have any pointers ?

> Otherwise, an empty /etc/machine-id may be present, if /etc is read-only
> at boot, in which case systemd will do a temporary mount.
>
> So 'ro' is supported, but you either need an /etc/machine-id file or
> a place to mount one temporarily.

So if 'ro' is used, systemd-firstboot is not working. If it's expected
I think it would worth a note in the documentation.

On my setup, neither 'rw' nor 'ro' is passed so I assume 'ro' is the default.

Thanks for your help
-- 
Francis
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Question about systemd-firstboot

[Francis Moreau]

On Thu, Mar 9, 2017 at 3:10 PM, Zbigniew Jędrzejewski-Szmek
<zbys...@in.waw.pl> wrote:
> On Thu, Mar 09, 2017 at 10:48:03AM +0100, Francis Moreau wrote:
>> Hello,
>>
>> I'm puzzled about systemd-firstboot service.
>>
>> In my understanding this service is ran only during the firstboot. The
>> firstboot condition is detected with the presence of /etc/machine-id
>> file.
>>
>> If this file is not present then it's assumed to be a first boot and
>> systemd-firstboot.service is ran and will create the machine-id file.
>>
>> Now the thing is that I dont see how systemd-firstboot.service can
>> have a chance to be started because if /etc/machine-id is missing the
>> whole boot is failing due to journald requiring /etc/machine-id.
>>
>> Could anybody give me some clues ?
>
> machine_id_setup() is called from main(). So pid1 should set up
> /etc/machine-id if possible (/etc is wriable) before it starts the
> firstboot services.
>

For regular boots /etc is always RO when systemd is started, at least
in my understanding.

Just give it a try, remove /etc/machine-id and reboots, you'll see
that journald will fail.

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

[systemd-devel] Question about systemd-firstboot

[Francis Moreau]

Hello,

I'm puzzled about systemd-firstboot service.

In my understanding this service is ran only during the firstboot. The
firstboot condition is detected with the presence of /etc/machine-id
file.

If this file is not present then it's assumed to be a first boot and
systemd-firstboot.service is ran and will create the machine-id file.

Now the thing is that I dont see how systemd-firstboot.service can
have a chance to be started because if /etc/machine-id is missing the
whole boot is failing due to journald requiring /etc/machine-id.

Could anybody give me some clues ?

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

Re: [systemd-devel] sysv-generator weirdness for shutdown runlevels

[Francis Moreau]

On Thu, May 26, 2016 at 8:15 AM, Andrei Borzenkov <arvidj...@gmail.com> wrote:
> On Thu, May 26, 2016 at 8:49 AM, Francis Moreau <francis.m...@gmail.com> 
> wrote:
>>
>> So let's take an example. Please note that I'm really not sure what's
>> the expected behavior of sysvinit itself, and finding some
>> documentation/specifications about that is pretty hard.
>>
>> I want my "foo" sysv service to be executed at shutdown. So I install
>> the following symlink:
>>
>>   /etc/init.d/rc0.d/S50foo
>>
>> The sysv-generator will add a "WantedBy/Before=poweroff.target" to the foo 
>> stub.
>>
>> The chunk of code in my initial post adds support of the following symlink:
>>
>>  /etc/init.d/rc0.d/K50foo
>>
>> It adds "Conflicts/Before=shutdown.target" to foo stub.
>>
>> So if both symlinks are installed (I don't see why this is useful and
>> hence why the generator has some code to handle that), foo stub has
>> the following constraints:
>>
>> WantedBy/Before=poweroff.target
>> Conflicts/Before=shutdown.target
>>
>> and to me that's not useful since in my understand it's equivalent to a nop.
>>
>
> This is classical garbage in - garbage out, unless you can demonstrate
> valid use case for something that has to be both started *and* stopped
> at the same time.

Well yes that's not usefull, so I'm wondering why systemd has code to
deal with this weid case specially since by default all stubs will
have a Conflicts/Before=shutdown.target.

So even if /etc/init.d/rc0.d/K50foo is not installed,
/etc/init.d/rc0.d/S50foo will have no effect.

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

Re: [systemd-devel] sysv-generator weirdness for shutdown runlevels

[Francis Moreau]

Hello Michael,

On Wed, May 25, 2016 at 11:08 PM, Michael Biebl  wrote:
> Hm, I've already given you the answer on IRC, so I'm not sure why you
> ask them again.
>

Indee and thank you for that.

But you also told me that /etc/init.d/rc0.d isn't supported by Debian,
and my question is about this runlevel in particular.

> The K symlinks determine whether a service needs an explicit stop
> request on shutdown (i.e. Conflicts/Before: shutdown.target).
>
> That's exactly how sysvinit also worked. If there was a K symlink in
> rc0 and rc6, the service is stopped via /etc/init.d/foo stop.
>
> Not sure what's unclear about that.
>

So let's take an example. Please note that I'm really not sure what's
the expected behavior of sysvinit itself, and finding some
documentation/specifications about that is pretty hard.

I want my "foo" sysv service to be executed at shutdown. So I install
the following symlink:

  /etc/init.d/rc0.d/S50foo

The sysv-generator will add a "WantedBy/Before=poweroff.target" to the foo stub.

The chunk of code in my initial post adds support of the following symlink:

 /etc/init.d/rc0.d/K50foo

It adds "Conflicts/Before=shutdown.target" to foo stub.

So if both symlinks are installed (I don't see why this is useful and
hence why the generator has some code to handle that), foo stub has
the following constraints:

WantedBy/Before=poweroff.target
Conflicts/Before=shutdown.target

and to me that's not useful since in my understand it's equivalent to a nop.

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

[systemd-devel] sysv-generator weirdness for shutdown runlevels

[Francis Moreau]

Hello,

I'm starring at a chunk of code of the sysv-generator (shown below)
for some while now and I still can't see its purpose.

Here's the code taken from src/sysv-generator/sysv-generator.c:

static int set_dependencies_from_rcnd(const LookupPaths *lp, Hashmap
*all_services) {

[...]

} else if (de->d_name[0] == 'K' &&
   (rcnd_table[i].type ==
RUNLEVEL_DOWN)) {


set_ensure_allocated(_services, NULL);
set_put(shutdown_services, service);
}
[...]

For simplicity sake, I removed the sanity checkings.

If I parsed it correctly, it handles symlinks in rc[06].d/ such as:
/etc/init.d/rc0.d/K50foo.

In this case this adds a "Conflicts=shutdown.target" and
"Before=shutdown.target" to the foo stub service.

What exactly the point to do that specially ? which sysvinit behavior
systemd is try to mimic ?

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

Re: [systemd-devel] Why does sysv generator translate Required-Start keyword into an After= ordering dep only ?

[Francis Moreau]

On Tue, Mar 8, 2016 at 10:19 AM, Andrei Borzenkov <arvidj...@gmail.com> wrote:
> 08.03.2016 11:33, Francis Moreau пишет:
>> On Tue, Mar 8, 2016 at 9:23 AM, Andrei Borzenkov <arvidj...@gmail.com> wrote:
>>> 08.03.2016 11:07, Francis Moreau пишет:
>>>> On Tue, Mar 8, 2016 at 7:51 AM, Andrei Borzenkov <arvidj...@gmail.com> 
>>>> wrote:
>>>>> 07.03.2016 10:04, Francis Moreau пишет:
>>>>>> Hello,
>>>>>>
>>>>>> Sorry for the long delay.
>>>>>>
>>>>>> On Fri, Feb 26, 2016 at 5:05 AM, Andrei Borzenkov <arvidj...@gmail.com> 
>>>>>> wrote:
>>>>>>> 26.02.2016 00:55, Francis Moreau пишет:
>>>>>>>>
>>>>>>>> But now I'm wondering how the following case is handled: a sysinit
>>>>>>>> script "a" has "Required-Start: b". But "b" is a native systemd
>>>>>>>> service. I don't think the tool that enable/disable sysv services can
>>>>>>>> enable and order correctly the native service.
>>>>>>>>
>>>>>>>
>>>>>>> What difference does it make?
>>>>>>
>>>>>> The difference is that in my current understanding nothing will pull "b" 
>>>>>> in.
>>>>>
>>>>> That was answered in part you trimmed off. sysvinit never actively
>>>>> pulled "b" in either so nothing really changed here.
>>>>>
>>>>
>>>> In my understanding insserv is part of the sysvinit implementation.
>>>>
>>>> Therefore to enable a service with sysvinit, we do:
>>>>
>>>>  - insserv a (this will create Sa *and* Sb" with yy < xx)
>>>
>>> That would be new to me. insserv creates links ("enables") exactly those
>>> services that you specify. So if you say "insserv a" you will get only
>>> "a" enabled; this /may/ rearrange other services including "b" if they
>>> are already enabled but this will not enable "b".
>>>
>>
>> That's how I understood Lennart's excerpt I was referring to previously.
>>
>
> Hmm ... I tested on SLES11 and indeed, while "insserv a" will not enable
> "b" it will refuse to enable "a" if "b" is not enabled. And conversely
> it will not disable "b" if "a" is enabled.
>
> So at least it tries to ensure that set of enabled services is consistent.

Is this system uses systemd ?

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

Re: [systemd-devel] Why does sysv generator translate Required-Start keyword into an After= ordering dep only ?

[Francis Moreau]

On Tue, Mar 8, 2016 at 9:23 AM, Andrei Borzenkov <arvidj...@gmail.com> wrote:
> 08.03.2016 11:07, Francis Moreau пишет:
>> On Tue, Mar 8, 2016 at 7:51 AM, Andrei Borzenkov <arvidj...@gmail.com> wrote:
>>> 07.03.2016 10:04, Francis Moreau пишет:
>>>> Hello,
>>>>
>>>> Sorry for the long delay.
>>>>
>>>> On Fri, Feb 26, 2016 at 5:05 AM, Andrei Borzenkov <arvidj...@gmail.com> 
>>>> wrote:
>>>>> 26.02.2016 00:55, Francis Moreau пишет:
>>>>>>
>>>>>> But now I'm wondering how the following case is handled: a sysinit
>>>>>> script "a" has "Required-Start: b". But "b" is a native systemd
>>>>>> service. I don't think the tool that enable/disable sysv services can
>>>>>> enable and order correctly the native service.
>>>>>>
>>>>>
>>>>> What difference does it make?
>>>>
>>>> The difference is that in my current understanding nothing will pull "b" 
>>>> in.
>>>
>>> That was answered in part you trimmed off. sysvinit never actively
>>> pulled "b" in either so nothing really changed here.
>>>
>>
>> In my understanding insserv is part of the sysvinit implementation.
>>
>> Therefore to enable a service with sysvinit, we do:
>>
>>  - insserv a (this will create Sa *and* Sb" with yy < xx)
>
> That would be new to me. insserv creates links ("enables") exactly those
> services that you specify. So if you say "insserv a" you will get only
> "a" enabled; this /may/ rearrange other services including "b" if they
> are already enabled but this will not enable "b".
>

That's how I understood Lennart's excerpt I was referring to previously.

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

Re: [systemd-devel] Why does sysv generator translate Required-Start keyword into an After= ordering dep only ?

[Francis Moreau]

On Tue, Mar 8, 2016 at 7:51 AM, Andrei Borzenkov <arvidj...@gmail.com> wrote:
> 07.03.2016 10:04, Francis Moreau пишет:
>> Hello,
>>
>> Sorry for the long delay.
>>
>> On Fri, Feb 26, 2016 at 5:05 AM, Andrei Borzenkov <arvidj...@gmail.com> 
>> wrote:
>>> 26.02.2016 00:55, Francis Moreau пишет:
>>>>
>>>> But now I'm wondering how the following case is handled: a sysinit
>>>> script "a" has "Required-Start: b". But "b" is a native systemd
>>>> service. I don't think the tool that enable/disable sysv services can
>>>> enable and order correctly the native service.
>>>>
>>>
>>> What difference does it make?
>>
>> The difference is that in my current understanding nothing will pull "b" in.
>
> That was answered in part you trimmed off. sysvinit never actively
> pulled "b" in either so nothing really changed here.
>

In my understanding insserv is part of the sysvinit implementation.

Therefore to enable a service with sysvinit, we do:

 - insserv a (this will create Sa *and* Sb" with yy < xx)
 - init will start *both* a and b

However with systemd and 'b' being a native unit:

 - insserv a (this will create Sa only)
 - systemd will only start a

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

Re: [systemd-devel] Why does sysv generator translate Required-Start keyword into an After= ordering dep only ?

[Francis Moreau]

On Mon, Mar 7, 2016 at 2:13 PM, Lukáš Nykrýn <lnyk...@redhat.com> wrote:
> Francis Moreau píše v Po 07. 03. 2016 v 08:04 +0100:
>> Hello,
>>
>> Sorry for the long delay.
>>
>> On Fri, Feb 26, 2016 at 5:05 AM, Andrei Borzenkov <
>> arvidj...@gmail.com> wrote:
>> > 26.02.2016 00:55, Francis Moreau пишет:
>> > >
>> > > But now I'm wondering how the following case is handled: a
>> > > sysinit
>> > > script "a" has "Required-Start: b". But "b" is a native systemd
>> > > service. I don't think the tool that enable/disable sysv services
>> > > can
>> > > enable and order correctly the native service.
>> > >
>> >
>> > What difference does it make?
>>
>> The difference is that in my current understanding nothing will pull
>> "b" in.
>>
>> Indeed "a" will have "After=b" ordering dep but that's not sufficient
>> to start "b". And since "b" is native it will not have a "SXXb"
>> installed by insserv.
>
> IIRC the behavior is still the same as it always was. Chkconfig on (at
> least rhel-based systems) did not enable the dependencies for the
> service. It only assured that the services will be started in the
> correct order.

That doesnt seem to match what Lennart said previously:

"""
Well, on SysV the requirement in the "Required-Start:" concept is
actually a request to the tool that enables/disables a service
(i.e. the chkconfig or update-rcd tool, depending on the distro). It
means that it shall enable another service "b" if "a" is to be
enabled.
"""

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

Re: [systemd-devel] Why does sysv generator translate Required-Start keyword into an After= ordering dep only ?

[Francis Moreau]

Hello,

Sorry for the long delay.

On Fri, Feb 26, 2016 at 5:05 AM, Andrei Borzenkov <arvidj...@gmail.com> wrote:
> 26.02.2016 00:55, Francis Moreau пишет:
>>
>> But now I'm wondering how the following case is handled: a sysinit
>> script "a" has "Required-Start: b". But "b" is a native systemd
>> service. I don't think the tool that enable/disable sysv services can
>> enable and order correctly the native service.
>>
>
> What difference does it make?

The difference is that in my current understanding nothing will pull "b" in.

Indeed "a" will have "After=b" ordering dep but that's not sufficient
to start "b". And since "b" is native it will not have a "SXXb"
installed by insserv.


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

Re: [systemd-devel] Why does sysv generator translate Required-Start keyword into an After= ordering dep only ?

[Francis Moreau]

On Wed, Feb 24, 2016 at 6:12 PM, Lennart Poettering
<lenn...@poettering.net> wrote:
> On Wed, 24.02.16 17:40, Francis Moreau (francis.m...@gmail.com) wrote:
>
>> Hello,
>>
>> It seems that the unit generator for sysv init scripts translate
>> "Required-Start: X" into "After=X" native ordering deps only.
>>
>> I would also have expected it to add the following dependency "Requires=X" 
>> too.
>>
>> What am I missing ?
>
> Well, on SysV the requirement in the "Required-Start:" concept is
> actually a request to the tool that enables/disables a service
> (i.e. the chkconfig or update-rcd tool, depending on the distro). It
> means that it shall enable another service "b" if "a" is to be
> enabled.

"mbiebl" on #debian-systemd gave me the same explanation (thanks to him).

However beside enabling service "b", the tool will also enable it so
that "b" will be started by sysvinit before service "a"

>
> Requires= in systemd otoh is something that applies to the actual
> activation time of a service. The counterpart of "Required-Start:" in
> systemd concepts would actually be the Also= line in [Install], if you
> follow what I mean.

hmm but Also= doesn't have the notion of ordering, I think.

>
> systemd leaves enabling/disabling of sysv services to
> chkconfig/update-rcd hence it will not act on that line regarding
> requirement. It will however act on the ordering, since that's
> inherently something systemd itself cares about.
>
> Hope that makes sense?
>

Yes Thanks.

But now I'm wondering how the following case is handled: a sysinit
script "a" has "Required-Start: b". But "b" is a native systemd
service. I don't think the tool that enable/disable sysv services can
enable and order correctly the native service.
-- 
Francis
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Why does sysv generator translate Required-Start keyword into an After= ordering dep only ?

[Francis Moreau]

Hello,

It seems that the unit generator for sysv init scripts translate
"Required-Start: X" into "After=X" native ordering deps only.

I would also have expected it to add the following dependency "Requires=X" too.

What am I missing ?

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

Re: [systemd-devel] umounting FS happens to be at the same time as shutting down services

[Francis Moreau]

On Sun, Nov 22, 2015 at 4:04 PM, Lennart Poettering
<lenn...@poettering.net> wrote:
> On Sun, 22.11.15 15:26, Francis Moreau (francis.m...@gmail.com) wrote:
>
>> Hi,
>>
>> While rebooting, It seems to me that shutting down services while
>> unmounting some FS at the same time in an unordered fashion is not a
>> good idea since unmounting a FS can happen before a service using this
>> FS is stopped.
>>
>> Is this expected ?
>
> No, and it's not really what happends. Mounts from /etc/fstab are
> usually ordered with a Before= depdendency against local-fs.target,
> which is ordered Before= basic.target, which is the target that normal
> services are ordered After=. Hence, at startup you get the strict
> order:
>
>Mounts from /etc/fstab → local-fs.target → basic.target → normal services
>
> Now, in systemd the shutdown order is always the strict reverse of the
> start-up order, hence this results in this shutdown order:
>
>normal services → basic.target → local-fs.target → Mounts from /etc/fstab
>
> Thus, file systems are unmounted only *after* normal services have been
> terminated.
>
> Now, there are some services that set DefaultDependencies=no, and some
> mount units too. For those these automatic dependencies are not in
> effect, and they basically explicitly ask for the right to be ordered
> manually against whatever they want to be ordered against, and thus
> possibly are started or stopped in parallel. However, that's explicit
> configuration that way, and the exception.
>

Thank you very much for your detailed answer, it's clear now.
-- 
Francis
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] umounting FS happens to be at the same time as shutting down services

[Francis Moreau]

Hi,

While rebooting, It seems to me that shutting down services while
unmounting some FS at the same time in an unordered fashion is not a
good idea since unmounting a FS can happen before a service using this
FS is stopped.

Is this expected ?

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

Re: [systemd-devel] Property 'MemoryLimit' is RO when using the D-Bus API

[Francis Moreau]

On Sun, Nov 8, 2015 at 9:38 PM, Lennart Poettering
<lenn...@poettering.net> wrote:
> On Fri, 06.11.15 18:38, Francis Moreau (francis.m...@gmail.com) wrote:
>
>> Hi,
>>
>> I'm trying to change the MemoryLimit property of one the service unit
>> running on my system by using 'busctl set-property ...' but getting
>> the following error :
>>
>>Property 'MemoryLimit' is not writable.
>>
>> However using 'systemctl set-property' works as expected.
>>
>> I thought that 'systemctl set-property' was basically doing the same
>> D-Bus thing like my former test did but apparently not.
>>
>> Could anybody enlight me why I can't use busctl to set the MemoryLimit
>> property  and why 'systemctl set-property' gives a different result ?
>
> We never hooked that up, that's all..
>
> So, in systemd we have an explicit call SetUnitProperties() that is
> independent of the dbus-mandated Set() calls for the Properties
> interface. We do this mostly to allow atomic changes to multiple
> properties but also to be a step closer to unit file behaviour
> regarding assigning lists of settings to a property, so that it's easy
> to extend ratehr than reset properties that take lists.
>
> In all our tools we use SetUnitProperties() exclusively, since it has
> nicer behaviour. We never thought of hooking up Set() too... but if
> figure it might make sense to do that too, so i'd be happy to take a patch...
>

I see.

It's just from the point of view of a (dumb) user, this behaviour
looked inconsistent. But I can use SetUnitProperties().

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

[systemd-devel] Property 'MemoryLimit' is RO when using the D-Bus API

[Francis Moreau]

Hi,

I'm trying to change the MemoryLimit property of one the service unit
running on my system by using 'busctl set-property ...' but getting
the following error :

   Property 'MemoryLimit' is not writable.

However using 'systemctl set-property' works as expected.

I thought that 'systemctl set-property' was basically doing the same
D-Bus thing like my former test did but apparently not.

Could anybody enlight me why I can't use busctl to set the MemoryLimit
property  and why 'systemctl set-property' gives a different result ?

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

Re: [systemd-devel] Showing a more accurate version of systemd with the git sha1

[Francis Moreau]

On Fri, Oct 2, 2015 at 7:17 PM, Andrei Borzenkov <arvidj...@gmail.com> wrote:
> 02.10.2015 19:27, Francis Moreau пишет:
>>
>> Hello,
>>
>> I'd like to know if it would be possible to show the git version (the
>> one given by git-describe) when using the systemd binaries with
>> --version option.
>>
>> That would be specially usefull when the systemd tree used to build
>> the binary was not a released one.
>>
>
> This was already rejected. If you have convincing arguments ...
>
> https://github.com/systemd/systemd/pull/1164
>

Well not sure I need to some convincing arguments since it's usefull
obviously otherwise others tools such as git or the kernel wouldn't do
that.

And as someone pointed at, git already implements this in a simple way.

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

[systemd-devel] Showing a more accurate version of systemd with the git sha1

[Francis Moreau]

Hello,

I'd like to know if it would be possible to show the git version (the
one given by git-describe) when using the systemd binaries with
--version option.

That would be specially usefull when the systemd tree used to build
the binary was not a released one.

I'm really not an automake stuff expert, so it might be already
possible to do that but I couldn't find it.

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 ?

[Francis Moreau]

On Wed, Sep 30, 2015 at 11:06 PM, Lennart Poettering
<lenn...@poettering.net> wrote:
> On Tue, 22.09.15 15:52, Lennart Poettering (lenn...@poettering.net) wrote:
>
>> 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.
>
> This has been changed now, with 8c8da0e0cb498245c765732cf9caa081a70c560f
>

Thanks for the update.


-- 
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 ?

[Francis Moreau]

On 09/22/2015 03:52 PM, Lennart Poettering wrote:
> 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.
> 

One thing I noted is that even if the slice failed to start, the slice
is still created by starting the unit belonging to that slice, and the
resource controls are still correctly applied to the slice.

Is that expected that units create slice that they belong to ?

I would have expected the unit fails to start because it couldn't find
the slice.

Thanks.

___
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 <dh.herrm...@gmail.com> wrote:
> Hi
>
> On Mon, Sep 21, 2015 at 4:50 PM, 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 ?
>
> 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] 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 <dh.herrm...@gmail.com> wrote:
> Hi
>
> On Fri, Sep 18, 2015 at 6:31 PM, Francis Moreau <francis.m...@gmail.com> 
> 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 ?

[Francis Moreau]

On Tue, Sep 22, 2015 at 2:18 PM, Zbigniew Jędrzejewski-Szmek
<zbys...@in.waw.pl> 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 <dh.herrm...@gmail.com> 
>> wrote:
>> > Hi
>> >
>> > On Tue, Sep 22, 2015 at 10:58 AM, Francis Moreau <francis.m...@gmail.com> 
>> > 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<myslice.slice<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 <dh.herrm...@gmail.com> wrote:
> Hi
>
> On Tue, Sep 22, 2015 at 11:07 AM, Francis Moreau <francis.m...@gmail.com> 
> wrote:
>> Hello,
>>
>> On Mon, Sep 21, 2015 at 7:45 PM, David Herrmann <dh.herrm...@gmail.com> 
>> wrote:
>>> Hi
>>>
>>> On Fri, Sep 18, 2015 at 6:31 PM, Francis Moreau <francis.m...@gmail.com> 
>>> 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] Implicit unit dependency on slice might be too weak ?

[Francis Moreau]

On Tue, Sep 22, 2015 at 11:14 AM, David Herrmann <dh.herrm...@gmail.com> wrote:
> Hi
>
> On Tue, Sep 22, 2015 at 10:58 AM, Francis Moreau <francis.m...@gmail.com> 
> 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] systemd-firstboot skip root password initialisation if /etc/shadow is present

[Francis Moreau]

On Tue, Sep 22, 2015 at 12:19 PM, David Herrmann <dh.herrm...@gmail.com> wrote:
> On Tue, Sep 22, 2015 at 11:59 AM, Francis Moreau <francis.m...@gmail.com> 
> 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] systemd-firstboot skip root password initialisation if /etc/shadow is present

[Francis Moreau]

On Tue, Sep 22, 2015 at 2:35 PM, David Herrmann <dh.herrm...@gmail.com> wrote:
> Hi
>
> On Tue, Sep 22, 2015 at 2:26 PM, Francis Moreau <francis.m...@gmail.com> 
> wrote:
>> On Tue, Sep 22, 2015 at 12:19 PM, David Herrmann <dh.herrm...@gmail.com> 
>> wrote:
>>> On Tue, Sep 22, 2015 at 11:59 AM, Francis Moreau <francis.m...@gmail.com> 
>>> 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

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

[Francis Moreau]

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 ?

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

Re: [systemd-devel] Question related to cgroup and systemd

[Francis Moreau]

Hello Lennart,

On Fri, Sep 18, 2015 at 2:24 PM, Lennart Poettering
<lenn...@poettering.net> wrote:
> B1;4002;0cOn Fri, 18.09.15 14:11, Francis Moreau (francis.m...@gmail.com) 
> wrote:
>
>> Hi,
>>
>> I'm trying to understand how cgroup is used by systemd and having the
>> following behaviour that I don't understand.
>>
>> I've created a slice "myslice.slice" with this resource constraint
>> "MemoryLimit=1024" and started it.
>>
>> I was expecting to find a trace of myslice in /sys/fs/cgroup/memory
>> folder but I can't find anything.
>
> systemd realizes croups only when we add processes to it.
>
>> I  put a process inside the slice (with the help of systemd-run
>> --slice=myslice), but nothing was created under /sys/fs/cgroup/memory
>> either.
>
> So, this works fine for me:
>
> # systemd-run --slice=my-deep-slice.slice -p MemoryLimit=3G /bin/sleep 9
>
> It creates the specified slice, and places the new service in it, then
> adds the process in it and sets the memory.limit_in_bytes= attribute
> on the services' cgroup.
>
> Does this not work for you?

I dont think so:

$ cat ~/.config/systemd/user/myslice.slice
[Slice]
MemoryLimit=1024
$ systemctl --user start myslice.slice
$ systemctl --user status myslice.slice
● myslice.slice
   Loaded: loaded (/home/fmoreau/.config/systemd/user/myslice.slice;
static; vendor preset: enabled)
  Active: active since Fri 2015-09-18 14:35:59 CEST; 4s ago

Sep 18 14:35:59 cyclone systemd[752]: Created slice myslice.slice.

$ systemd-run --user --slice=myslice.slice /bin/sleep 9
Running as unit run-793.service.
$ systemctl --user status myslice.slice
● myslice.slice
   Loaded: loaded (/home/fmoreau/.config/systemd/user/myslice.slice;
static; vendor preset: enabled)
  Active: active since Fri 2015-09-18 14:35:59 CEST; 1min 29s ago
 CGroup: /user.slice/user-1000.slice/user@1000.service/myslice.slice
└─run-793.service
 └─794 /bin/sleep 9

Sep 18 14:35:59 cyclone systemd[752]: Created slice myslice.slice.

$ find /sys/fs/cgroup/memory/ -name myslice\*
$
$ find /sys/fs/cgroup/systemd/ -name myslice\*
/sys/fs/cgroup/systemd/user.slice/user-1000.slice/user@1000.service/myslice.slice

> Which systemd version are you using?

systemd 225-1 (Archlinux).

>> I was expecting that "myslice.slice" would have its own directory
>> inside /sys/fs/cgroup/memory directory (ie inside the memory
>> controller) and the memory constraint applied to that directory and
>> hence all its children.
>
> Correct. But again, we only realize groups when we really need to.
>

Ok understood.

>> But it seems I'm missing something.
>>
>> Could anybody enlight me please ?
>>
>> Also I'm a bit lost regarding kernel cgroup and its reworked API. Does
>> systemd already use this new API or is it still using the old/broken
>> one ?
>
> Yes, the concept of scopes, services and slices and how they are
> mapped to cgroupfs is fully implemented. We currently don't expose all
> controllers and all settings, but that's mostly because the
> controllers are awful and in progress of being fixed, and we only want
> to expose them as soon as they are cleaned up and here to stay with
> their new settings.
>
> In the most recent systemd release we even support the new kernel
> unified hierarchy now, but you have to select at boot time which one
> you want: the legacy one as before, or the unified one.
>

Which kernel version starts to support the new unified hierarchy ? Is
there a doc which explain it ?

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

[systemd-devel] Question related to cgroup and systemd

[Francis Moreau]

Hi,

I'm trying to understand how cgroup is used by systemd and having the
following behaviour that I don't understand.

I've created a slice "myslice.slice" with this resource constraint
"MemoryLimit=1024" and started it.

I was expecting to find a trace of myslice in /sys/fs/cgroup/memory
folder but I can't find anything.

I  put a process inside the slice (with the help of systemd-run
--slice=myslice), but nothing was created under /sys/fs/cgroup/memory
either.

I was expecting that "myslice.slice" would have its own directory
inside /sys/fs/cgroup/memory directory (ie inside the memory
controller) and the memory constraint applied to that directory and
hence all its children.

But it seems I'm missing something.

Could anybody enlight me please ?

Also I'm a bit lost regarding kernel cgroup and its reworked API. Does
systemd already use this new API or is it still using the old/broken
one ?

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

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

[Francis Moreau]

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.

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

Re: [systemd-devel] Possible confusion with socket activation and daemon own configuration

[Francis Moreau]

On 09/08/2015 07:48 PM, Simon McVittie wrote:
> On 08/09/15 13:55, Francis Moreau wrote:
>> On 09/08/2015 12:09 PM, Richard Maw wrote:
>>> I understood that the common configuration for socket activated sshd was to
>>> have a sshd.service for if you want it to always be running, and a pair of
>>> sshd@.service and sshd.socket.
>>
>> Ah no, with this design starting sshd.service should do the right thing
>> but that's because there're 2 different service unit files:
>> sshd@.service and sshd.service.
> 
> As far as I understand it, this duplication is present to give the
> sysadmin a choice between two ways to run sshd, depending on this
> particular ssh server's requirements.
> 
> If ssh access is frequently used or needs to work quickly (for instance
> as the primary way to log in and fix things), enabling sshd.service
> means it will start "eagerly", on boot. Debian and its derivatives
> enable this by default (if sshd is installed).
> 
> If ssh access is infrequently used, a sysadmin can disable sshd.service
> and enable sshd.socket instead. That means sshd will be started
> on-demand, which will take a bit longer (particularly if the reason to
> log in is that the server has hit performance problems), but reduces
> resource consumption until then. This would be appropriate if the reason
> for providing ssh access is as a rarely-used "developer console"
> analogous to Android's adb, for instance.
> 

Yes that's my understanding too.

But I guess that some services can't be instanciated for each request
and in this case, there can be only one service unit, I think. And if
it's the case starting the service in on-demand mode will prevent to
start the service unit file by its own (ie. not using the socket unit file).

Thanks.

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

Re: [systemd-devel] Possible confusion with socket activation and daemon own configuration

[Francis Moreau]

On 09/07/2015 11:28 AM, Richard Maw wrote:
> On Sun, Sep 06, 2015 at 12:43:51PM +0200, Francis Moreau wrote:
>> How is this handled ? Should we put a big warning in sshd_config to hint
>> user to configure ListenAddress in sshd.socket in the case socket
>> activation is used ?
> 
>> Or should sshd simply ignore all listening addresses defined in sshd_config
>> when in socket activation mode ?
> 
> That would be my preferred solution. I may be missing something important 
> here,
> but I'd always assumed that sshd wouldn't need to worry about the listen
> address if something else was accepting the connections on the socket.
> 

The downside of this would be that starting the service directly (ie not
the socket unit) won't work anymore

> As another alternative though, you could consider the sshd_config file the
> canonical location for the listen address, and have a generator parse
> sshd_config, and write a drop-in snippet for sshd.socket to set the
> ListenAddress.

Indeed that would work and would solve the problem, however not sure
that sshd_config file will be available at the time when the generator
will need it.

Also the generator would have to be generic enough to parse and support
several config file syntax. And regarding the number of different config
file syntax (can even be xml !), I'm not sure it will be a good idea.

Do you think that would be something that systemd upstream would be
interested in ? Maybe there were already some discussions/works around
that ?

Thanks.

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

Re: [systemd-devel] Possible confusion with socket activation and daemon own configuration

[Francis Moreau]

On 09/08/2015 12:09 PM, Richard Maw wrote:
> On Tue, Sep 08, 2015 at 10:05:05AM +0200, Francis Moreau wrote:
>> On 09/07/2015 11:28 AM, Richard Maw wrote:
>>> On Sun, Sep 06, 2015 at 12:43:51PM +0200, Francis Moreau wrote:
>>>> How is this handled ? Should we put a big warning in sshd_config to hint
>>>> user to configure ListenAddress in sshd.socket in the case socket
>>>> activation is used ?
>>>
>>>> Or should sshd simply ignore all listening addresses defined in sshd_config
>>>> when in socket activation mode ?
>>>
>>> That would be my preferred solution. I may be missing something important 
>>> here,
>>> but I'd always assumed that sshd wouldn't need to worry about the listen
>>> address if something else was accepting the connections on the socket.
>>>
>>
>> The downside of this would be that starting the service directly (ie not
>> the socket unit) won't work anymore
> 
> Does it?
> 
> I understood that the common configuration for socket activated sshd was to
> have a sshd.service for if you want it to always be running, and a pair of
> sshd@.service and sshd.socket.
> 
> The former runs with -D, and the latter runs with -i.
> 

Ah no, with this design starting sshd.service should do the right thing
but that's because there're 2 different service unit files:
sshd@.service and sshd.service.

I suppose that was done because sshd wasn't modified to use systemd's
native socket passing interface (sd_listen_fds). If it was the case then
only one service unit file would be used I think. And in this case, the
service unit would start sshd in 'OnDemand' mode always. In this case we
can't start directly sshd.service, but have to use socket activation.

> Presumably this would be sufficient information that sshd could be made to
> ignore the listen address in the sshd_config if it's being run with -i.
> 

I'm not sure I'm understanding...

[...]
> 
> For parsing config files of other configuration systems, no, sysvinit and
> /etc/fstab are mostly the only foreign configuration formats systemd cares
> about.
> 
> These are also split out into the generator mechanism rather than parsed by
> systemd directly.
> 
> Systemd tends not to carry service configuration for other software,
> though the openssh upstream, or their distribution downstreams could
> carry the code for a listen address configuration generator.
> 
> See http://www.freedesktop.org/software/systemd/man/systemd.generator.html for
> how generators work and
> https://github.com/systemd/systemd/blob/master/src/debug-generator/debug-generator.c
> for an example.
> 

Thanks for the pointer. That makes sense although I'm not sure that
service projects are willing to include a systemd generator in their repo.

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

Re: [systemd-devel] Delaying device service creation

[Francis Moreau]

On 07/03/2015 01:22 PM, Lennart Poettering wrote:
 B1;4002;0cOn Fri, 03.07.15 13:09, Francis Moreau (francis.m...@gmail.com) 
 wrote:
 
 That's not an issue really. Since the device will not have any disk
 label initially, and thus nothing will make use of it, until the
 mke2fs is finished, and an ext2 label applied. When mke2fs then closes
 the device, udev notices this (via inotify), will retrigger the
 device.


 Does that mean that a mount service (having Where=device-node) waiting
 for that device is not waiting for the device to appear but is waiting
 for a valid FS on this device ?
 
 Well, depends. 
 
 Basically, if you reference the device by the raw device node name
 then, no it will not wait. But if you reference the device by a
 higher-level name, involving bits from the disk label (such as using
 /dev/disks/by-label/xyz symlinks), then yes, it will wait, since that
 symlink doesn't exist until the mke2fs is done.

Smart, I didn't think about using /dev/disks/by-label.

 
 But in the case of cryptsetup with 'tmp' option, the device can have a
 disk label initially, since it's reformatted at each boot.
 
 hmm, usually tmp is combined with a /dev/urandom key, and hence is
 effectively empty initially...
 
 This might be broken if you indeed use a fixed key each time, so that
 the old disk label is still visible initially.
 
 Systemd can't do little with the HW event but it can choose the moment
 when the device unit is created or is marked with an 'active' state and
 also choose when all the device deps are started.
 
 well, but it doesn't work that way... we do not delay device
 state changes until all the deps are fulfilled, and I am not convinced
 we should. It's the general logic we follow: ordering deps control
 only the state changes systemd itself triggers, but do not affect
 systemd's view of external events. They only affect the order in which
 we process the job queue, but they are irrelevant for the actual
 states of the units. 

Ok. Maybe an error or a warning for services that have ordering
dependencies on device such as Before=device would be useful.

Thanks for your clarification.

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

Re: [systemd-devel] Delaying device service creation

[Francis Moreau]

On 07/03/2015 11:08 AM, Lennart Poettering wrote:
 On Tue, 30.06.15 17:37, Francis Moreau (francis.m...@gmail.com) wrote:
 
 Hi,

 I have a service 'A' which creates a device 'X' and does some
 configuring of the device. The device is created in a 'ExecStart='
 directive whereas its configuration happens during 'ExecStartPost='.

 But it seems that as soon as the device is seen by systemd, it creates
 the corresponding device service and starts all services that depeneds
 on this device.
 
 What kind of a device is this? block device?

Yes, it's a block device which needs some initialization before being
mounted.

Actually I found a similar case with cryptsetup:

$ cat systemd-cryptsetup\@cr_tmp.service
...
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/lib/systemd/systemd-cryptsetup attach 'cr_tmp' '/dev/vdb'
'none' 'tmp'
ExecStartPost=/sbin/mke2fs '/dev/mapper/cr_tmp'
...

Basically command in ExecStart will create the device and systemd will
create the corresponding device unit file and will start all deps which
are waiting for this device. Mount service can be one of them. Note that
this happens while the device creation service is still not finished.

Then systemd will execute ExecStarPost command while device's deps are
running which is incorrect since you can end up with mount trying to
operate on a fsck'ed FS.


 
 You should mark your device with SYSTEMD_READY=0 in udev, as
 long as it is not ready to be exposed. Check 99-systemd.rules for a
 few examples where we do this for loopback or mdadm devices as long as
 they are not fully set up.
 

Noted, I'm going to have a look at how this works.

That said it's still not clear to me if a service can delay the device
service availability. IOW does something like below is supposed to work:

$ cat my-device-creation.service:
...
Before=my-device.device
...

From my basic testing, it doesn't seem supported.

Thanks.


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

Re: [systemd-devel] Delaying device service creation

[Francis Moreau]

On 07/03/2015 12:18 PM, Lennart Poettering wrote:
 On Fri, 03.07.15 11:53, Francis Moreau (francis.m...@gmail.com) wrote:
 
 On 07/03/2015 11:08 AM, Lennart Poettering wrote:
 On Tue, 30.06.15 17:37, Francis Moreau (francis.m...@gmail.com) wrote:

 Hi,

 I have a service 'A' which creates a device 'X' and does some
 configuring of the device. The device is created in a 'ExecStart='
 directive whereas its configuration happens during 'ExecStartPost='.

 But it seems that as soon as the device is seen by systemd, it creates
 the corresponding device service and starts all services that depeneds
 on this device.

 What kind of a device is this? block device?

 Yes, it's a block device which needs some initialization before being
 mounted.

 Actually I found a similar case with cryptsetup:

 $ cat systemd-cryptsetup\@cr_tmp.service
 ...
 [Service]
 Type=oneshot
 RemainAfterExit=yes
 ExecStart=/usr/lib/systemd/systemd-cryptsetup attach 'cr_tmp' '/dev/vdb'
 'none' 'tmp'
 ExecStartPost=/sbin/mke2fs '/dev/mapper/cr_tmp'
 ...

 Basically command in ExecStart will create the device and systemd will
 create the corresponding device unit file and will start all deps which
 are waiting for this device. Mount service can be one of them. Note that
 this happens while the device creation service is still not finished.

 Then systemd will execute ExecStarPost command while device's deps are
 running which is incorrect since you can end up with mount trying to
 operate on a fsck'ed FS.
 
 You mean trying to operate on an FS that is currently being created?
 
 That's not an issue really. Since the device will not have any disk
 label initially, and thus nothing will make use of it, until the
 mke2fs is finished, and an ext2 label applied. When mke2fs then closes
 the device, udev notices this (via inotify), will retrigger the
 device.
 

Does that mean that a mount service (having Where=device-node) waiting
for that device is not waiting for the device to appear but is waiting
for a valid FS on this device ?

But in the case of cryptsetup with 'tmp' option, the device can have a
disk label initially, since it's reformatted at each boot.

This is what I'm getting when trying to mount a crypted device with
'tmp' option and fsck enabled in fstab (I must admit that running fsck
is useless in that case but:

systemd[1]: Found device /dev/mapper/cr_tmp.
systemd[1]: Starting File System Check on /dev/mapper/cr_tmp...
systemd-fsck[366]: /dev/mapper/cr_tmp: clean, 11/25688 files,
4800/102400 blocks
systemd[1]: Started File System Check on /dev/mapper/cr_tmp.
systemd[1]: Mounting /mnt/cr_tmp...
systemd[1]: Mounted /mnt/cr_tmp.
systemd[1]: Starting Local File Systems.
systemd[1]: Reached target Local File Systems.
systemd[1]: Starting Trigger Flushing of Journal to Persistent Storage...
kernel: EXT4-fs (dm-1): mounting ext2 file system using the ext4 subsystem
kernel: EXT4-fs (dm-1): mounted filesystem without journal. Opts: (null)
systemd[1]: Starting Recreate Volatile Files and Directories...
mke2fs[364]: mke2fs 1.42.8 (20-Jun-2013)
mke2fs[364]: /dev/mapper/cr_tmp is mounted; will not make a filesystem here!
systemd[1]: systemd-cryptsetup@cr_tmp.service: control process exited,
code=exited status=1
systemd-journal[185]: Runtime journal is using 524.0K (max 49.8M,
leaving 74.7M of free 497.
systemd[1]: Started Trigger Flushing of Journal to Persistent Storage.
systemd[1]: Started Recreate Volatile Files and Directories.
systemd[1]: Starting Update UTMP about System Reboot/Shutdown...
systemd[1]: Started Update UTMP about System Reboot/Shutdown.
systemd-cryptsetup[378]: Failed to deactivate: Device or resource busy
systemd[1]: systemd-cryptsetup@cr_tmp.service: control process exited,
code=exited status=1
systemd[1]: Failed to start Cryptography Setup for cr_tmp.
systemd[1]: Dependency failed for Encrypted Volumes.
systemd[1]: Unit systemd-cryptsetup@cr_tmp.service entered failed state.

In this case the device is mounted before mke2fs had a chance to run.


 You should mark your device with SYSTEMD_READY=0 in udev, as
 long as it is not ready to be exposed. Check 99-systemd.rules for a
 few examples where we do this for loopback or mdadm devices as long as
 they are not fully set up.


 Noted, I'm going to have a look at how this works.

 That said it's still not clear to me if a service can delay the device
 service availability. IOW does something like below is supposed to work:

 $ cat my-device-creation.service:
 ...
 Before=my-device.device
 ...

 From my basic testing, it doesn't seem supported.
 
 No it's not. Devices appear and disappear independently of
 dependencies... I mean, if you plug in a USB pen drive, then you
 plugged it in, and that fact won't change because you actually want a
 service to run first. it just happened anyway... and systemd accepts
 that, basically.
 
 If you have ordering deps between a device and a service unit, then
 this has little effect on the device unit, but a lot of effect on the
 service

Re: [systemd-devel] Delaying device service creation

[Francis Moreau]

On 06/30/2015 07:47 PM, Mantas Mikulėnas wrote:
 Options:
 
 - Configure it as part of ExecStart if possible.

I don't see how is this going to help, sorry.

 
 - Configure it using a second .service unit (oneshot), and depend on
 that one.

You meant all services that were depending on the device should depend
on that second .service ?

I so, I would rather avoid that: it seems much cleaner to me to have the
device service started once the configuration has been done, ie when the
device really ready.

Actually my question is rather : does adding dependencies on device
services is supported, so I can make it 'appear' only when the service
which creates and configures it is completely finished ?

 
 - Do something with udev to mark unconfigured devices with
 SYSTEMD_READY=0? Not sure how. But if you can do this, it'll directly
 affect the readiness of the corresponding .device unit.

I have to see how to do that and how to set SYSTEMD_READY=1 once configured.

Thanks

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

[systemd-devel] Delaying device service creation

[Francis Moreau]

Hi,

I have a service 'A' which creates a device 'X' and does some
configuring of the device. The device is created in a 'ExecStart='
directive whereas its configuration happens during 'ExecStartPost='.

But it seems that as soon as the device is seen by systemd, it creates
the corresponding device service and starts all services that depeneds
on this device.

However this happens even if service 'A' hasn't finished to configure
the device yet.

I tried to add 'Before=X.device' in 'A' service file, but it doesn't
seem to have any effects.

Could anybody help me ?

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

Re: [systemd-devel] Question about ExecStartPost= and startup process

[Francis Moreau]

On 06/29/2015 10:05 AM, Andrei Borzenkov wrote:
[...]

 service_sigchld_event() {
 ...
 } else if (s-control_pid == pid) {
 ...
 if (s-control_command 
 s-control_command-command_next 
 f == SERVICE_SUCCESS) {
 service_run_next_control(s);
 }

 this looks like that forking type services could had several commands
 queued in ExecStart directive...

 
 IIRC this is checked when unit definition is parsed.
 

I don't think so, service_sigchld_event() is called when a child process
of systemd has just died and the condition is testing if  the died
process is the process defined by ExecStart=.

Well it's my understanding, hence my confusion.

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

Re: [systemd-devel] Question about ExecStartPost= and startup process

[Francis Moreau]

On 06/28/2015 07:21 PM, Reindl Harald wrote:
 
 
 Am 28.06.2015 um 19:02 schrieb Francis Moreau:
 On 06/28/2015 01:01 PM, Reindl Harald wrote:

 Am 28.06.2015 um 12:00 schrieb Francis Moreau:
 Hello,

 For services with Type=Forking, I'm wondering if systemd  proceeds
 starting follow-up units when the command described by ExecStart= exits
 or when the one described by ExecStartPost= exits ?

 I tried to read the source code to figure this out and it *seems* that
 the latter is true but I'm really not sure.

 after ExecStartPost because anything else would make no sense, a unit is
 started when *all* if is st started - see the recent mariadb units on
 Fedora - if systemd would fire up deaemons which depend on mariadb the
 whole wait-ready-stuff won't work

 Ok, then the next naive question would be: then what the purpose of the
 ExecStartPost= directive since several commands can already be 'queued'
 with the ExecStart= one?
 
 no, they can't, not for every service type
 When Type is not oneshot, only one command may and must be given
 
 read http://www.freedesktop.org/software/systemd/man/systemd.service.html
 

correct, I was actually confused by what I read from the source code:

service_sigchld_event() {
...
} else if (s-control_pid == pid) {
...
if (s-control_command 
s-control_command-command_next 
f == SERVICE_SUCCESS) {
service_run_next_control(s);
}

this looks like that forking type services could had several commands
queued in ExecStart directive...

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

Re: [systemd-devel] Question about ExecStartPost= and startup process

[Francis Moreau]

On 06/28/2015 07:35 PM, Andrei Borzenkov wrote:
 В Sun, 28 Jun 2015 19:02:57 +0200
 Francis Moreau francis.m...@gmail.com пишет:
 
 On 06/28/2015 01:01 PM, Reindl Harald wrote:


 Am 28.06.2015 um 12:00 schrieb Francis Moreau:
 Hello,

 For services with Type=Forking, I'm wondering if systemd  proceeds
 starting follow-up units when the command described by ExecStart= exits
 or when the one described by ExecStartPost= exits ?

 I tried to read the source code to figure this out and it *seems* that
 the latter is true but I'm really not sure.

 after ExecStartPost because anything else would make no sense, a unit is 
 started when *all* if is st started - see the recent mariadb units on 
 Fedora - if systemd would fire up deaemons which depend on mariadb the 
 whole wait-ready-stuff won't work


 Ok, then the next naive question would be: then what the purpose of the
 ExecStartPost= directive since several commands can already be 'queued'
 with the ExecStart= one ?

 
 Long running services (i.e. daemons) are represented by systemd with
 PID of main process (which is *the* service for systemd). With multiple
 ExecStart commands there is no obvious way to know which of started
 processes is the main one. That's the reason to allow just one command
 there. Once main process is known, it is possible to have any number of
 followup ExecStartPost commands.
 

I see, thanks.

So basically for type=Forking service, ExecStart= is used to find out
the PID of the main process, and additionnal commands can be passed
through ExecStartPost= and systemd will wait for the latter to be
finished before starting follow-up units.

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

[systemd-devel] Question about ExecStartPost= and startup process

[Francis Moreau]

Hello,

For services with Type=Forking, I'm wondering if systemd  proceeds
starting follow-up units when the command described by ExecStart= exits
or when the one described by ExecStartPost= exits ?

I tried to read the source code to figure this out and it *seems* that
the latter is true but I'm really not sure.

What about for services with other type (simple, oneshot) ?

Also the documentation says that only one command can be given to
ExecStart if the type of the service is Forking. However I don't see
this when reading the code:

service_sigchld_event() {
...
} else if (s-control_pid == pid) {

...
if (s-control_command 
s-control_command-command_next 
f == SERVICE_SUCCESS) {
service_run_next_control(s);
}

In my understand this code is specific to service with Type=Forking

Could anybody clarfify ?

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

Re: [systemd-devel] Question about ExecStartPost= and startup process

[Francis Moreau]

On 06/28/2015 01:01 PM, Reindl Harald wrote:
 
 
 Am 28.06.2015 um 12:00 schrieb Francis Moreau:
 Hello,

 For services with Type=Forking, I'm wondering if systemd  proceeds
 starting follow-up units when the command described by ExecStart= exits
 or when the one described by ExecStartPost= exits ?

 I tried to read the source code to figure this out and it *seems* that
 the latter is true but I'm really not sure.
 
 after ExecStartPost because anything else would make no sense, a unit is 
 started when *all* if is st started - see the recent mariadb units on 
 Fedora - if systemd would fire up deaemons which depend on mariadb the 
 whole wait-ready-stuff won't work
 

Ok, then the next naive question would be: then what the purpose of the
ExecStartPost= directive since several commands can already be 'queued'
with the ExecStart= one ?

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

[systemd-devel] Failed to mount a crypted device with 'tmp' option

[Francis Moreau]

Hi,

I'm setting up an encrypted device at boot using cryptsetup. This device
is formatted at each boot (I'm using 'tmp' option in /etc/crypttab).

Also this device is mounted at boot time (a corresponding entry in
/etc/fstab has been made) and is also fsck'ed (fs_passno=2).

However it seems that the mount happens at the same time cryptsetup lib
is formatting the disk which causes trouble.

Here is part of the boot log:
-
...
systemd-cryptsetup[230]: Set cipher aes, mode cbc-essiv:sha256, key size
256 bits for device
kernel: sha256_ssse3: Using SSSE3 optimized SHA-256 implementation
modprobe[309]: FATAL: Error inserting padlock_sha
(/lib/modules/3.11.10-29-default/kernel/dr
kernel: bio: create slab bio-1 at 1
systemd[1]: Found device /dev/mapper/cr_tmp.
systemd[1]: Starting File System Check on /dev/mapper/cr_tmp...
mke2fs[318]: mke2fs 1.42.8 (20-Jun-2013)
mke2fs[318]: Filesystem label=
mke2fs[318]: OS type: Linux
mke2fs[318]: Block size=1024 (log=0)
mke2fs[318]: Fragment size=1024 (log=0)
mke2fs[318]: Stride=0 blocks, Stripe width=0 blocks
mke2fs[318]: 25688 inodes, 102400 blocks
mke2fs[318]: 5120 blocks (5.00%) reserved for the super user
mke2fs[318]: First data block=1
mke2fs[318]: Maximum filesystem blocks=67371008
mke2fs[318]: 13 block groups
mke2fs[318]: 8192 blocks per group, 8192 fragments per group
mke2fs[318]: 1976 inodes per group
mke2fs[318]: Superblock backups stored on blocks:
mke2fs[318]: 8193, 24577, 40961, 57345, 73729
mke2fs[318]: [49B blob data]
mke2fs[318]: [46B blob data]
systemd-fsck[320]: /dev/mapper/cr_tmp is in use.
systemd-fsck[320]: e2fsck: Cannot continue, aborting.
systemd-fsck[320]: fsck failed with error code 8.
systemd-fsck[320]: Ignoring error.
systemd[1]: Started File System Check on /dev/mapper/cr_tmp.
systemd[1]: Mounting /mnt/cr_tmp...
mount[324]: mount: /dev/mapper/cr_tmp is already mounted or /mnt/cr_tmp busy
systemd[1]: mnt-cr_tmp.mount mount process exited, code=exited status=32
systemd[1]: Failed to mount /mnt/cr_tmp.
systemd[1]: Dependency failed for Local File Systems.
systemd[1]: Triggering OnFailure= dependencies of local-fs.target.
systemd[1]: Unit mnt-cr_tmp.mount entered failed state.

-

So my question, is this a known bug or am I doing something wrong ?

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

Re: [systemd-devel] Help needed for optimizing my boot time

[Francis Moreau]

On 06/11/2015 06:23 PM, Dan Williams wrote:
 On Thu, 2015-06-11 at 15:15 +0200, Francis Moreau wrote:
[...]

 Does ntpd service really need 'After=network.target', not sure.
 
 The 'network online' targets are really just there for ignorant services
 that don't respond to network events themselves, that expect the network
 to be up and running before they start.  Of course, those services don't
 have any way to say *which* network interface they care about, so if you
 have more than one interface in your system they still get it wrong.

Do such services exist actually ?

I can't see how such service can work if they can't handle the offline
case properly...

BTW 'network online' target doesn't seem to mean the network is up
because if I boot my computer offline, this target is still reached and
passed.

 
 But anyway, if ntpd or autofs can respond to network events using
 netlink or listening on D-Bus to NetworkManager/connman/etc or getting
 triggered by eg NetworkManager dispatcher scripts, then they probably
 don't need to block on network-online.  But if they can't, and they
 expect the network to be up and running before they start, then yes they
 will block startup until some kind of networking is running.

Well I must be missing something but I can't see why ntpd or autofs
would rely and have any deps on NM whereas they need to deal with the
generic case, i.e. the one where NM is not installed and used.

In my understanding, they would either use netlink or simply retry later.

I just checked ntpd source code and it seems to use netlink. I can't
find any ntpd script installed in /etc/NetworkManager/dispatcher.d but
ntpd get informed when an network interface is added/removed.

IOW, any services having After: network-online.target look odd to me.

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

Re: [systemd-devel] Help needed for optimizing my boot time

[Francis Moreau]

On 06/12/2015 06:26 PM, Andrei Borzenkov wrote:
 В Fri, 12 Jun 2015 16:56:08 +0200
 Francis Moreau francis.m...@gmail.com пишет:
 
 On 06/11/2015 06:23 PM, Dan Williams wrote:
 On Thu, 2015-06-11 at 15:15 +0200, Francis Moreau wrote:
 [...]

 Does ntpd service really need 'After=network.target', not sure.

 The 'network online' targets are really just there for ignorant services
 that don't respond to network events themselves, that expect the network
 to be up and running before they start.  Of course, those services don't
 have any way to say *which* network interface they care about, so if you
 have more than one interface in your system they still get it wrong.

 Do such services exist actually ?

 
 Until recently ntpd required working name resolution (i.e. often DNS)
 to find its peers. If you mount something over network on boot you want
 to have reasonable confidence that network is up.
 
 I can't see how such service can work if they can't handle the offline
 case properly...

 
 Please explain how filesystem on iSCSI target is supposed to handle
 offline case properly. 
 

I was talking about ntpd, I dont know for you specific case.

 BTW 'network online' target doesn't seem to mean the network is up
 because if I boot my computer offline, this target is still reached and
 passed.

 
 Yes, network-online.target is not there to make boot impossible; it is
 there to delay boot until network is considered to be up. It makes
 little sense in pure dynamic environment; it is quite useful in static
 server environment where network is expected to be always present but
 may take some time to be configured.


Then if it's not reliable in some cases how can it be used by some
generic services such as ntpd if ntpd is not prepared to handle the
offline case ?


 But anyway, if ntpd or autofs can respond to network events using
 netlink or listening on D-Bus to NetworkManager/connman/etc or getting
 triggered by eg NetworkManager dispatcher scripts, then they probably
 don't need to block on network-online.  But if they can't, and they
 expect the network to be up and running before they start, then yes they
 will block startup until some kind of networking is running.

 Well I must be missing something but I can't see why ntpd or autofs
 would rely and have any deps on NM whereas they need to deal with the
 generic case, i.e. the one where NM is not installed and used.

 
 Where do you see any deps on NM? network-online.target is generic
 target which will be used with any underlying networking implementation.

I was refering to if ntpd or autofs can respond to network events using
netlink or listening on D-Bus to NetworkManager/connman/etc


 IOW, any services having After: network-online.target look odd to me.

 
 Welcome to real world :)
 

No, real world is not wait for ntpd, autofs to be activated before I
can login or at least not in my world ;)

I don't really understand your opinion, are you saying that ntpd should
used After: network-online.target ?

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

[systemd-devel] Help needed for optimizing my boot time

[Francis Moreau]

Hello,

I'm interested in optimizing my boot time on my laptop.

So I looked at the big picture first:

   $ systemd-analyze
   Startup finished in 3.994s (firmware) + 7.866s (loader) + 8.226s
(kernel) + 7.921s (userspace) = 28.007s

and noticed that the boot time spent in userspace is quite high.

I looked at the details:

   $ systemd-analyze critical-chain

   graphical.target @7.921s
 multi-user.target @7.921s
   autofs.service @7.787s +132ms
 network-online.target @7.786s
   network.target @7.786s
 NetworkManager.service @675ms +184ms
   basic.target @674ms
 ...

If I understand that correctly, NetworkManager takes more than 7 seconds
to start and seems to be the culprit.

However, I'm not sure to understand why the service following NM
(autofs) and thus multi-user.target need to wait for the network to be
available.

Specially since:

 - nothing requires a network connection in order to boot and setup my
system, including mounting /home partition

 - autofs should still be working if there's no network connection and
detect if the network becomes ready later

So my question is: in this case, is autofs wrongly waiting for the
network to be started or is NM taking too much time to start ?

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

Re: [systemd-devel] Help needed for optimizing my boot time

[Francis Moreau]

Hi,

On 06/11/2015 12:44 PM, Andrei Borzenkov wrote:
 On Thu, Jun 11, 2015 at 1:08 PM, Francis Moreau francis.m...@gmail.com 
 wrote:
 Hello,

 I'm interested in optimizing my boot time on my laptop.

 So I looked at the big picture first:

$ systemd-analyze
Startup finished in 3.994s (firmware) + 7.866s (loader) + 8.226s
 (kernel) + 7.921s (userspace) = 28.007s

 and noticed that the boot time spent in userspace is quite high.

 I looked at the details:

$ systemd-analyze critical-chain

graphical.target @7.921s
  multi-user.target @7.921s
autofs.service @7.787s +132ms
  network-online.target @7.786s
network.target @7.786s
  NetworkManager.service @675ms +184ms
basic.target @674ms
  ...

 If I understand that correctly, NetworkManager takes more than 7 seconds
 to start and seems to be the culprit.

 However, I'm not sure to understand why the service following NM
 (autofs) and thus multi-user.target need to wait for the network to be
 available.

 Specially since:

  - nothing requires a network connection in order to boot and setup my
 system, including mounting /home partition

  - autofs should still be working if there's no network connection and
 detect if the network becomes ready later

 So my question is: in this case, is autofs wrongly waiting for the
 network to be started or is NM taking too much time to start ?

 
 Is NetworkManager-wait-online.service enabled and active?
 

It seems it's enabled but no more active:

$ systemctl status NetworkManager-wait-online.service
● NetworkManager-wait-online.service - Network Manager Wait Online
   Loaded: loaded
(/usr/lib/systemd/system/NetworkManager-wait-online.service; disabled;
vendor preset: disabled)
   Active: inactive (dead) since Thu 2015-06-11 11:54:37 CEST; 1h 4min ago
  Process: 583 ExecStart=/usr/bin/nm-online -s -q --timeout=30
(code=exited, status=0/SUCCESS)
 Main PID: 583 (code=exited, status=0/SUCCESS)

Jun 11 11:54:30 cyclone systemd[1]: Starting Network Manager Wait Online...
Jun 11 11:54:37 cyclone systemd[1]: Started Network Manager Wait Online.

This seems correct to me, doesn't it ?

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

Re: [systemd-devel] Help needed for optimizing my boot time

[Francis Moreau]

On 06/11/2015 01:40 PM, Andrei Borzenkov wrote:
 On Thu, Jun 11, 2015 at 2:26 PM, Francis Moreau francis.m...@gmail.com 
 wrote:

$ systemd-analyze critical-chain

graphical.target @7.921s
  multi-user.target @7.921s
autofs.service @7.787s +132ms
  network-online.target @7.786s
network.target @7.786s
  NetworkManager.service @675ms +184ms
basic.target @674ms
  ...

 ...
 Is NetworkManager-wait-online.service enabled and active?


 It seems it's enabled but no more active:

 $ systemctl status NetworkManager-wait-online.service
 ● NetworkManager-wait-online.service - Network Manager Wait Online
Loaded: loaded
 (/usr/lib/systemd/system/NetworkManager-wait-online.service; disabled;
 vendor preset: disabled)
Active: inactive (dead) since Thu 2015-06-11 11:54:37 CEST; 1h 4min ago
   Process: 583 ExecStart=/usr/bin/nm-online -s -q --timeout=30
 (code=exited, status=0/SUCCESS)
  Main PID: 583 (code=exited, status=0/SUCCESS)

 Jun 11 11:54:30 cyclone systemd[1]: Starting Network Manager Wait Online...
 Jun 11 11:54:37 cyclone systemd[1]: Started Network Manager Wait Online.

 This seems correct to me, doesn't it ?

 
 Actually it says disabled which makes me wonder why it run. But this
 is the service that is likely responsible for long time you observe.
 If disabling it does ot help, you can try masking it (systemctl mask)
 for a test.
 

Masking this service helps:

$ systemd-analyze
Startup finished in 3.323s (firmware) + 6.795s (loader) + 8.342s
(kernel) + 1.470s (userspace) = 19.932s

$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the @
character.
The time the unit takes to start is printed after the + character.

graphical.target @1.470s
  multi-user.target @1.470s
autofs.service @1.024s +445ms
  network-online.target @1.023s
network.target @1.021s
  NetworkManager.service @731ms +289ms
   basic.target @731ms

and the system seems to run fine (specially autofs, ntpd).

But I think the time given by systemd-analyze (1.470s) is not correct.
When booting I can see that the userspace is doing a fsck on root which
takes more than 2s. And the login screen takes at least 5s to appear
once the fsck is starting.

Is the time spent in initrd is included in userspace ?

Thanks


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

Re: [systemd-devel] Help needed for optimizing my boot time

[Francis Moreau]

On 06/11/2015 02:22 PM, Andrei Borzenkov wrote:
 On Thu, Jun 11, 2015 at 3:10 PM, Francis Moreau francis.m...@gmail.com 
 wrote:
 On 06/11/2015 01:40 PM, Andrei Borzenkov wrote:
 On Thu, Jun 11, 2015 at 2:26 PM, Francis Moreau francis.m...@gmail.com 
 wrote:

$ systemd-analyze critical-chain

graphical.target @7.921s
  multi-user.target @7.921s
autofs.service @7.787s +132ms
  network-online.target @7.786s
network.target @7.786s
  NetworkManager.service @675ms +184ms
basic.target @674ms
  ...

 ...
 Is NetworkManager-wait-online.service enabled and active?


 It seems it's enabled but no more active:

 $ systemctl status NetworkManager-wait-online.service
 ● NetworkManager-wait-online.service - Network Manager Wait Online
Loaded: loaded
 (/usr/lib/systemd/system/NetworkManager-wait-online.service; disabled;
 vendor preset: disabled)
Active: inactive (dead) since Thu 2015-06-11 11:54:37 CEST; 1h 4min ago
   Process: 583 ExecStart=/usr/bin/nm-online -s -q --timeout=30
 (code=exited, status=0/SUCCESS)
  Main PID: 583 (code=exited, status=0/SUCCESS)

 Jun 11 11:54:30 cyclone systemd[1]: Starting Network Manager Wait Online...
 Jun 11 11:54:37 cyclone systemd[1]: Started Network Manager Wait Online.

 This seems correct to me, doesn't it ?


 Actually it says disabled which makes me wonder why it run. But this
 is the service that is likely responsible for long time you observe.

 I think it runs because of this:

 $ ls /usr/lib/systemd/system/network-online.target.wants/
 NetworkManager-wait-online.service

 BTW, why isn't it showed by 'systemd-analyze critical-chain' ?

 
 My best guess is that it has no direct dependency on NetworkManager so
 it is not counted as part of chain. You could try adding
 
 After=NetworkManager.service
 
 to see if it changes anything in systemd-analyze output.
 
 If disabling it does ot help, you can try masking it (systemctl mask)
 for a test.

 Actually, I'm still not sure why autofs.service is waiting for
 network-online.target to be activated, IOW why this service has
 'After=network-online.target'.

 
 You can discuss it on autofs list; systemd is just a messenger here :)
 

Well it's more a systemd configuration question. I think the
'After=network-online.target' in its service file is not really needed.

I tried to disable autofs service and got a similar issue with ntpd one
(except network-online.target is not involved here):

  $ systemd-analyze critical-chain
  graphical.target @7.921s
multi-user.target @7.921s
  ntpd.service @7.790s +20ms
network.target @7.786s
  NetworkManager.service @675ms +184ms
basic.target @674ms

  $ systemctl show ntpd -p After
  After=network.target...

Does ntpd service really need 'After=network.target', not sure.

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

Re: [systemd-devel] Help needed for optimizing my boot time

[Francis Moreau]

On 06/11/2015 01:40 PM, Andrei Borzenkov wrote:
 On Thu, Jun 11, 2015 at 2:26 PM, Francis Moreau francis.m...@gmail.com 
 wrote:

$ systemd-analyze critical-chain

graphical.target @7.921s
  multi-user.target @7.921s
autofs.service @7.787s +132ms
  network-online.target @7.786s
network.target @7.786s
  NetworkManager.service @675ms +184ms
basic.target @674ms
  ...

 ...
 Is NetworkManager-wait-online.service enabled and active?


 It seems it's enabled but no more active:

 $ systemctl status NetworkManager-wait-online.service
 ● NetworkManager-wait-online.service - Network Manager Wait Online
Loaded: loaded
 (/usr/lib/systemd/system/NetworkManager-wait-online.service; disabled;
 vendor preset: disabled)
Active: inactive (dead) since Thu 2015-06-11 11:54:37 CEST; 1h 4min ago
   Process: 583 ExecStart=/usr/bin/nm-online -s -q --timeout=30
 (code=exited, status=0/SUCCESS)
  Main PID: 583 (code=exited, status=0/SUCCESS)

 Jun 11 11:54:30 cyclone systemd[1]: Starting Network Manager Wait Online...
 Jun 11 11:54:37 cyclone systemd[1]: Started Network Manager Wait Online.

 This seems correct to me, doesn't it ?

 
 Actually it says disabled which makes me wonder why it run. But this
 is the service that is likely responsible for long time you observe.

I think it runs because of this:

$ ls /usr/lib/systemd/system/network-online.target.wants/
NetworkManager-wait-online.service

BTW, why isn't it showed by 'systemd-analyze critical-chain' ?

 If disabling it does ot help, you can try masking it (systemctl mask)
 for a test.

Actually, I'm still not sure why autofs.service is waiting for
network-online.target to be activated, IOW why this service has
'After=network-online.target'.

 
 OTOH disabled here just means links in [Install] section are not
 present.

   $ cat /usr/lib/systemd/system/NetworkManager-wait-online.service
 ...
 [Install]
 WantedBy=multi-user.target

and I can't find the corresponding symlink in
/usr/lib/systemd/system/multi-user.target.wants/ or
/etc/systemd/system/multi-user.target.wants/

So you seem right, and disabled seems a bit mis-leading here.

 Could you show
 sysmectl show NetworkManager-wait-online.service -p WantedBy -p RequiredBy
 

$ systemctl show NetworkManager-wait-online.service -p WantedBy -p
RequiredBy
RequiredBy=
WantedBy=network-online.target

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

Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'

[Francis Moreau]

On 12/10/2014 10:19 AM, Francis Moreau wrote:
 Hello,
 
 On 12/10/2014 07:23 AM, Ivan Shapovalov wrote:
 On Tuesday 09 December 2014 at 17:25:48, Francis Moreau wrote:   
 Hello Lennart,

 Thanks for answering !

 On 12/09/2014 02:10 PM, Lennart Poettering wrote:
 On Tue, 09.12.14 11:19, Francis Moreau (francis.m...@gmail.com) wrote:

 Hello,

 I've a very weird behaviour with systemd 217:

 # systemctl show -p Wants multi-user.target | grep network.service
 # systemctl show -p Wants runlevel3.target | grep network.service
 Wants= ... network.service ...
 # systemctl show -p Wants multi-user.target | grep network.service
 Wants=... network.service ...

 So basically the network.service is not part of the multi-user target
 dependencies. But if I'm showing the state of the runlevel3 target, the
 network service magically becomes a dep of multi-user.target.

 The network.service is an sysv service which is started by rc[345].d and
 has in its LSB:

 Provide: $network

 Could anybody clarify what I'm facing ?

 systemd lazy loads services from the file system as they are
 referenced. This includes symlinked aliases, which are only loaded when
 a unit is referenced by that specific name.


 Sorry but I don't really understand.

 Do you mean that the network.service wasn't loaded although the
 runlevel3.target, which is an alias for multi-user target (default
 target) wants it ?

 I would be glad if you could enlight me because I'm confused.

 Apparently, network.service gets pulled in only via runlevel3.target, i. e.
 there is a symlink of kind

 /{etc,usr/lib,run}/systemd/system/runlevel3.target.wants/network.service - 
 network.service

 That is, the Wants= dependency is generated for runlevel3.target only, not 
 for
 multi-user.target.

 And, because systemd loads units lazily, systemd does not know about 
 runlevel3.target
 (and its dependencies) before anything forces systemd to load that unit.

 After you issue `systemctl show runlevel3.target`, systemd loads that unit,
 loads its dependencies and merges them to multi-user.target (because 
 runlevel3.target
 is an alias for multi-user.target).
 
 That helps, thanks !
 
 However that seems a bit weird to have a target with 'hidden'
 dependencies that can appears magically when poking another one, at
 least from my point of (user) view.
 
 Was the lazy load mechanism integrated recently ? I'm asking because
 systemd 208 doesn't show the same behaviour.
 
 What's the recommanded way to make sure that the Wants= dependencies
 generated for runlevel3 target get pplied as soon as possible to its
 alias target 'multi-user' ?
 

Could anybody enlight me because I actually don't know how I'm supposed
to start all services that runlevel3 would start otherwise. Should I add
manually a Wants=/etc/rd.d/rc3/S* dependency in the multi-user target ?

Thanks.

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

Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'

[Francis Moreau]

Hello,

On 12/10/2014 07:23 AM, Ivan Shapovalov wrote:
 On Tuesday 09 December 2014 at 17:25:48, Francis Moreau wrote:
 Hello Lennart,

 Thanks for answering !

 On 12/09/2014 02:10 PM, Lennart Poettering wrote:
 On Tue, 09.12.14 11:19, Francis Moreau (francis.m...@gmail.com) wrote:

 Hello,

 I've a very weird behaviour with systemd 217:

 # systemctl show -p Wants multi-user.target | grep network.service
 # systemctl show -p Wants runlevel3.target | grep network.service
 Wants= ... network.service ...
 # systemctl show -p Wants multi-user.target | grep network.service
 Wants=... network.service ...

 So basically the network.service is not part of the multi-user target
 dependencies. But if I'm showing the state of the runlevel3 target, the
 network service magically becomes a dep of multi-user.target.

 The network.service is an sysv service which is started by rc[345].d and
 has in its LSB:

 Provide: $network

 Could anybody clarify what I'm facing ?

 systemd lazy loads services from the file system as they are
 referenced. This includes symlinked aliases, which are only loaded when
 a unit is referenced by that specific name.


 Sorry but I don't really understand.

 Do you mean that the network.service wasn't loaded although the
 runlevel3.target, which is an alias for multi-user target (default
 target) wants it ?

 I would be glad if you could enlight me because I'm confused.
 
 Apparently, network.service gets pulled in only via runlevel3.target, i. e.
 there is a symlink of kind
 
 /{etc,usr/lib,run}/systemd/system/runlevel3.target.wants/network.service - 
 network.service
 
 That is, the Wants= dependency is generated for runlevel3.target only, not for
 multi-user.target.
 
 And, because systemd loads units lazily, systemd does not know about 
 runlevel3.target
 (and its dependencies) before anything forces systemd to load that unit.
 
 After you issue `systemctl show runlevel3.target`, systemd loads that unit,
 loads its dependencies and merges them to multi-user.target (because 
 runlevel3.target
 is an alias for multi-user.target).

That helps, thanks !

However that seems a bit weird to have a target with 'hidden'
dependencies that can appears magically when poking another one, at
least from my point of (user) view.

Was the lazy load mechanism integrated recently ? I'm asking because
systemd 208 doesn't show the same behaviour.

What's the recommanded way to make sure that the Wants= dependencies
generated for runlevel3 target get pplied as soon as possible to its
alias target 'multi-user' ?

Thanks for your help.

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

[systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'

[Francis Moreau]

Hello,

I've a very weird behaviour with systemd 217:

# systemctl show -p Wants multi-user.target | grep network.service
# systemctl show -p Wants runlevel3.target | grep network.service
Wants= ... network.service ...
# systemctl show -p Wants multi-user.target | grep network.service
Wants=... network.service ...

So basically the network.service is not part of the multi-user target
dependencies. But if I'm showing the state of the runlevel3 target, the
network service magically becomes a dep of multi-user.target.

The network.service is an sysv service which is started by rc[345].d and
has in its LSB:

Provide: $network

Could anybody clarify what I'm facing ?

Also it appears that runlevel3 target is an alias for multi-user one.
Could anybody where this alias is done ? If that's in the source code of
systemd I would be curious to see where exactly.

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

Re: [systemd-devel] multi-user.target only wants network.service if I'm doing 'systemct show runlevel3.target'

[Francis Moreau]

Hello Lennart,

Thanks for answering !

On 12/09/2014 02:10 PM, Lennart Poettering wrote:
 On Tue, 09.12.14 11:19, Francis Moreau (francis.m...@gmail.com) wrote:
 
 Hello,

 I've a very weird behaviour with systemd 217:

 # systemctl show -p Wants multi-user.target | grep network.service
 # systemctl show -p Wants runlevel3.target | grep network.service
 Wants= ... network.service ...
 # systemctl show -p Wants multi-user.target | grep network.service
 Wants=... network.service ...

 So basically the network.service is not part of the multi-user target
 dependencies. But if I'm showing the state of the runlevel3 target, the
 network service magically becomes a dep of multi-user.target.

 The network.service is an sysv service which is started by rc[345].d and
 has in its LSB:

 Provide: $network

 Could anybody clarify what I'm facing ?
 
 systemd lazy loads services from the file system as they are
 referenced. This includes symlinked aliases, which are only loaded when
 a unit is referenced by that specific name.
 

Sorry but I don't really understand.

Do you mean that the network.service wasn't loaded although the
runlevel3.target, which is an alias for multi-user target (default
target) wants it ?

I would be glad if you could enlight me because I'm confused.

 Also it appears that runlevel3 target is an alias for multi-user one.
 Could anybody where this alias is done ? If that's in the source code of
 systemd I would be curious to see where exactly.
 
 The /usr/lib/systemd/system/runlevel[0-5].target symlinks create these
 alias names.
 

I see now.

Thanks.

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

[systemd-devel] gummiboot can't be installed on ESP which is soft RAID1 metadata=0.9 partition

[Francis Moreau]

Hello,

gummiboot install fails when ESP is MD RAID1 device using metadata 0.9
or 1.0.

I don't think using such RAID for ESP would lead to issue.

Is there any reason gummiboot doesn't want to be installed on such
partition ?

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

Re: [systemd-devel] gummiboot can't be installed on ESP which is soft RAID1 metadata=0.9 partition

[Francis Moreau]

On 04/14/2014 06:16 PM, Lennart Poettering wrote:
 On Mon, 14.04.14 18:01, Francis Moreau (francis.m...@gmail.com) wrote:
 
 Hello,

 gummiboot install fails when ESP is MD RAID1 device using metadata 0.9
 or 1.0.

 I don't think using such RAID for ESP would lead to issue.

 Is there any reason gummiboot doesn't want to be installed on such
 partition ?
 
 The installer will make sure that the ESP is on GPT and carries the right
 type UUID. We do that for safety reasons, since that's the requirement
 made by UEFI, and how the bootloader is found.
 
 You cannot place the ESP on sw RAID, since the firmware might want to
 write to the ESP (most won't do that, but could, and the tianocore
 implemenation you use in qemu certainly does). 

Does UEFI allow firmware to write to ESP ?

If so that would indeed prevent ESP to be on soft RAID.

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

Re: [systemd-devel] gummiboot can't be installed on ESP which is soft RAID1 metadata=0.9 partition

[Francis Moreau]

On 04/14/2014 06:38 PM, Kay Sievers wrote:
 On Mon, Apr 14, 2014 at 9:22 AM, Francis Moreau francis.m...@gmail.com 
 wrote:
 On 04/14/2014 06:16 PM, Lennart Poettering wrote:
 On Mon, 14.04.14 18:01, Francis Moreau (francis.m...@gmail.com) wrote:

 gummiboot install fails when ESP is MD RAID1 device using metadata 0.9
 or 1.0.

 I don't think using such RAID for ESP would lead to issue.

 Is there any reason gummiboot doesn't want to be installed on such
 partition ?

 The installer will make sure that the ESP is on GPT and carries the right
 type UUID. We do that for safety reasons, since that's the requirement
 made by UEFI, and how the bootloader is found.

 You cannot place the ESP on sw RAID, since the firmware might want to
 write to the ESP (most won't do that, but could, and the tianocore
 implemenation you use in qemu certainly does).

 Does UEFI allow firmware to write to ESP ?

 If so that would indeed prevent ESP to be on soft RAID.
 
 Sure, it does. You can just start an EFI Shell and edit any file in the ESP.
 

yes but I would be deliberately asking to the firmware to write to ESP
in that case.

 The only safe (at least in theory) thing is to have a bios raid
 driver included in the EFI firmware itself, which sets up the ESP to
 be the mirrored disks. With that, writes from the firmware will end up
 on both disks without any operating system involved.

Indeed, that gives one (and only one) reason to use fake raid over soft
one unfortunately.

 
 Setting up the ESP as a raid without explicit firmware support does
 not sound like a good idea.
 

Sad because I'm currently finding the gain to be able to write to ESP
through the EFI shell very tiny compare to be able to have ESP mirrored.

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

Re: [systemd-devel] gummiboot can't be installed on ESP which is soft RAID1 metadata=0.9 partition

[Francis Moreau]

On 04/14/2014 08:11 PM, Thomas Bächler wrote:
 Am 14.04.2014 18:16, schrieb Lennart Poettering:
 On Mon, 14.04.14 18:01, Francis Moreau (francis.m...@gmail.com) wrote:

 Hello,

 gummiboot install fails when ESP is MD RAID1 device using metadata 0.9
 or 1.0.

 I don't think using such RAID for ESP would lead to issue.

 Is there any reason gummiboot doesn't want to be installed on such
 partition ?

 The installer will make sure that the ESP is on GPT and carries the right
 type UUID. We do that for safety reasons, since that's the requirement
 made by UEFI, and how the bootloader is found.

 You cannot place the ESP on sw RAID, since the firmware might want to
 write to the ESP (most won't do that, but could, and the tianocore
 implemenation you use in qemu certainly does). 
 
 While this is unsafe, the firmware doesn't write to the ESP during
 normal operation (i.e. bootup and efivar configuration).
 

Unfortunately it seesms that nothing in UEFI will prevent futur firmares
to change that.

Actually adding a flag somehow to instruct the firmware that ESP is a
read only partition would do the trick.

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