Re: [systemd-devel] why does bootctl default to /boot and not to /boot/efi?

[Lennart Poettering]

On Mon, 30.05.16 10:51, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote:

> On 29/05/16 19:39, Barry Scott wrote:
> > I just came across the bootctl command. Atleast on Fedora 23 and 24
> > it errors out because /boot is not FAT EFI. I thought that if you are EFI
> > then the EFI was always in /boot/efi.
> 
> I think mounting the EFI System Partition on /boot/efi is likely to be
> very common in practice. The kernel images in /boot are managed by dpkg
> on Debian derivatives, and dpkg requires (or at least strongly
> recommends) a POSIX filesystem on the directories it manages, so that it
> can do standard POSIX filesystem robustness tricks like hard links and
> atomic-overwrite.

On Fedora kernels are generally stored in /usr/lib/ (next to the
kmods) and copied over to /boot at install time, so that package
managers only own the kernels in /usr/lib and leave their dirty
fingers out of /boot.

Lennart

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

Re: [systemd-devel] why does bootctl default to /boot and not to /boot/efi?

[Lennart Poettering]

On Sun, 29.05.16 19:39, Barry Scott (ba...@barrys-emacs.org) wrote:

> I just came across the bootctl command. Atleast on Fedora 23 and 24
> it errors out because /boot is not FAT EFI. I thought that if you are EFI
> then the EFI was always in /boot/efi.

/boot and the ESP exist for the same reasons really, and do the same
job. Hence, systemd by default mounts the ESP to /boot and installs
sd-boot there.

/boot/efi is a really crazy idea, as this means you always have to
mount /boot (and actually have it!) before you can mount the ESP, and
that's just off. After all in sd-boot the kernels are simply placed in
the ESP, and there's really no point in having /boot at all...

Some distros patch sd-boot/bootctl to use /boot/efi instead, and the
other's don't but don't mount the ESP to /boot either.  Given that it
is that way, it might make sense to revisit the idea of making /boot
and the ESP the same thing. But I am pretty sure /boot/efi is really
the worst idea, hence an acceptable alternatively might be to
introduce /efi and mount the esp there, and simply not have /boot on
legacy free systems.

Lennart

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

Re: [systemd-devel] Info about JoinsNamespaceOf, PrivateNetwork systemd directives

[george Karakou]

On 05/30/2016 06:04 PM, Lennart Poettering wrote:

On Mon, 30.05.16 16:24, george Karakou (mad-proffes...@hotmail.com) wrote:


Hi again, i am a bit curious about these two directives. Can somebody
explain in  a few words how are these implemented? Using linux network
namespaces? Or simply put somehow services using these 2 directives are
forbidden to bind to l3, l4 sockets and only allowed to communicate via unix
domain sockets? Its an interesting feature, i thought i should give it a
try.

PrivateNetwork= simply runs a service in a new network namespace, and
adds a loopback device to it, but nothing else.

JoinsNamespaceOf= then allows you to run multiple services within the
same namespace.

Note that network namespaces cover AF_INET and AF_INET6 sockets, as
well as abstract AF_UNIX socket, but not AF_UNIX sockets that are
stored in the file system, those are namespaced via the filesystem
namespaces logic.

Lennart


Thanks a lot, this clarifies it.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] shutdown delayed by failure to start a service

[Lennart Poettering]

On Sun, 29.05.16 13:28, Felix Miata (mrma...@earthlink.net) wrote:

> Lennart Poettering composed on 2016-05-29 18:40 (UTC+0200):
> 
> >Felix Miata wrote:
> 
> >>The message I see is equivalent in form as during boot, e.g. when a
> >>filesystem not noauto in fstab is to be mounted but cannot be found, so a
> >>delay of typically 90sec, but sometimes much longer, occurs. Mount
> >>specification mistyped or a subsequently changed volume label, or similarly
> >>a change of filesystem UUID should be an easy enough way to observe what
> >>I've not infrequently seen, though the cause(s) of the more irritating
> >>shutdown delays isn't coming to mind ATM. If this was something I had a
> >>reliable recreate scenario for I'd have filed a bug somewhere by now, likely
> >>at least a year ago.
> 
> >Well, we put a timeout of 90s on *everything* systemd starts or
> >stops. Hence, saying that you see some 90s timeout just means
> >*something* isn't finishing as quickly as it should, with exactly zero
> >information about what that something might be...
> 
> Now that I know this isn't something familiar to you, I'll be on the watch
> to collect specifics to report next time I encounter it. Will there be a
> specific journalctl option to use at that time, or will -b do it?

"journalctl -b" shows you everything that happened during your current
boot. If you are trying to find log data generated during shutdown
this probably won't give you what you want, as you probably want the
data from the previous boot, not the current one, i.e. "journalctl
-b-1" is what you want...

That said, the journal itself is also terminated at shutdown. It's
terminated quite late, but it might happen that something that also
runs pretty late isn't covered anymore. This is harder to debug, and
documented here:

https://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1

Lennart

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

Re: [systemd-devel] Info about JoinsNamespaceOf, PrivateNetwork systemd directives

[Lennart Poettering]

On Mon, 30.05.16 16:24, george Karakou (mad-proffes...@hotmail.com) wrote:

> Hi again, i am a bit curious about these two directives. Can somebody
> explain in  a few words how are these implemented? Using linux network
> namespaces? Or simply put somehow services using these 2 directives are
> forbidden to bind to l3, l4 sockets and only allowed to communicate via unix
> domain sockets? Its an interesting feature, i thought i should give it a
> try.

PrivateNetwork= simply runs a service in a new network namespace, and
adds a loopback device to it, but nothing else.

JoinsNamespaceOf= then allows you to run multiple services within the
same namespace.

Note that network namespaces cover AF_INET and AF_INET6 sockets, as
well as abstract AF_UNIX socket, but not AF_UNIX sockets that are
stored in the file system, those are namespaced via the filesystem
namespaces logic.

Lennart

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

Re: [systemd-devel] Info about JoinsNamespaceOf, PrivateNetwork systemd directives

[george Karakou]

On 05/30/2016 04:32 PM, Mantas Mikulėnas wrote:
On Mon, May 30, 2016 at 4:24 PM, george Karakou 
> wrote:


Hi again, i am a bit curious about these two directives. Can
somebody explain in  a few words how are these implemented? Using
linux network namespaces? Or simply put somehow services using
these 2 directives are forbidden to bind to l3, l4 sockets and
only allowed to communicate via unix domain sockets? Its an
interesting feature, i thought i should give it a try.


Yes, they use network namespaces, the same kind as `ip netns` or 
`unshare --net`. Compare /proc//ns/net of affected processes.


(RestrictAddressFamilies=, however, uses seccomp to forbid using 
certain types of sockets.)


--
Mantas Mikulėnas >
Well, thanks my use case was dbus and dbus activated services but i 
couldn't make udisks2 work using PrivateNetwork and dbus'es namespace.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Info about JoinsNamespaceOf, PrivateNetwork systemd directives

[Mantas Mikulėnas]

On Mon, May 30, 2016 at 4:24 PM, george Karakou 
wrote:

> Hi again, i am a bit curious about these two directives. Can somebody
> explain in  a few words how are these implemented? Using linux network
> namespaces? Or simply put somehow services using these 2 directives are
> forbidden to bind to l3, l4 sockets and only allowed to communicate via
> unix domain sockets? Its an interesting feature, i thought i should give it
> a try.
>

Yes, they use network namespaces, the same kind as `ip netns` or `unshare
--net`. Compare /proc//ns/net of affected processes.

(RestrictAddressFamilies=, however, uses seccomp to forbid using certain
types of sockets.)

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

[systemd-devel] Info about JoinsNamespaceOf, PrivateNetwork systemd directives

[george Karakou]

Hi again, i am a bit curious about these two directives. Can somebody 
explain in  a few words how are these implemented? Using linux network 
namespaces? Or simply put somehow services using these 2 directives are 
forbidden to bind to l3, l4 sockets and only allowed to communicate via 
unix domain sockets? Its an interesting feature, i thought i should give 
it a try.


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

Re: [systemd-devel] DBus's PropertiesChanged signal is not triggered when an Unit stop successfully

[Adrien Besnard]

Okay, thank you: now I see the purpose of systemd's jobs.

So, if I get it well: if I want to monitor any kind of service
(Type=oneshot, Type=simple, etc.), I need to catch UnitRemoved event and
invoke the LoadUnit to get the status of the stopped (either in failure or
in success) Unit, right?

The tricky part is that calling LoadUnit cause an UnitNew event (which I
also monitor) and I may be caught in an infinite loop, because the
UnitRemoved is also launched just after...

I will be easier if the PropertiesChanged event is also launched on a Unit
finishing in success!





Adrien BESNARD

2016-05-30 14:22 GMT+02:00 Jan Alexander Steffens :

> Any Start/Stop/Restart operation you issue creates a job that will
> eventually (almost immediately, when starting a Type=simple service) get
> completed (or fail) and trigger a JobRemoved signal containing the result.
>
> When StartUnit/StopUnit/etc return they give you the job's object path you
> need to check the incoming signals against to get the result of the job you
> issued.
>
> Type=simple services complete their Start job so quickly that you're
> extremely unlikely to catch them on list-jobs.
>
>
> On Mon, May 30, 2016 at 2:12 PM Adrien Besnard 
> wrote:
>
>> Thank you! I'll try that ASAP. Do I need to listen to JobRemoved because
>> I use the [type=oneshot] or is it the way to do for every kind of service
>> (like [type=simple], for example)?
>>
>> I'm asking that because I just dicovered that [systemctl list-jobs] lists
>> my [type=oneshot] service when I start it, but I have no idea if it's
>> related or not...
>>
>> Cheers,
>>
>> Adrien BESNARD
>>
>> 2016-05-26 11:59 GMT+02:00 Jan Alexander Steffens > >:
>>
>>> You need to listen to JobRemoved signals. All of them, before you start
>>> your job - trying to match on the specific job you get back from StopUnit
>>> might not complete before the job is already removed.
>>>
>>> On Thu, May 26, 2016 at 8:20 AM Adrien Besnard 
>>> wrote:
>>>
 I managed to do what I wanted to do using add_timeout with the GLib's
 MainLoop: I poll every second the state of the unit and manually call the
 callback connected to DBus to fake the event when the unit is stopped.

 It works but this is a dirty hack. So I'm still interested by a real
 solution :)

 Cheers!
 Le 23 mai 2016 11:55, "Adrien Besnard"  a
 écrit :

> Hello,
>
> I'm trying to make a small Python script which send an email when a 
> *Type=oneshot
> *service ends (either in success or in failure).
>
> To do that, I'm using the dbus binding for Python, and connecting to
> the *PropertiesChanged* signal on the unit I'm monitoring.
>
> It works great when the process fails (the signal is triggered and I
> see *ActiveState* and *SubState* refleting the failure) but not when
> the service end successully.
>
> All I see is an *UnitRemoved* signal triggered by the manager
> interface... Is that normal?
>
> Do you guys have an idea of what I'm missing here?
>
> Thanks!
> --
> Adrien BESNARD
>
 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

Re: [systemd-devel] DBus's PropertiesChanged signal is not triggered when an Unit stop successfully

[Jan Alexander Steffens]

Any Start/Stop/Restart operation you issue creates a job that will
eventually (almost immediately, when starting a Type=simple service) get
completed (or fail) and trigger a JobRemoved signal containing the result.

When StartUnit/StopUnit/etc return they give you the job's object path you
need to check the incoming signals against to get the result of the job you
issued.

Type=simple services complete their Start job so quickly that you're
extremely unlikely to catch them on list-jobs.

On Mon, May 30, 2016 at 2:12 PM Adrien Besnard 
wrote:

> Thank you! I'll try that ASAP. Do I need to listen to JobRemoved because I
> use the [type=oneshot] or is it the way to do for every kind of service
> (like [type=simple], for example)?
>
> I'm asking that because I just dicovered that [systemctl list-jobs] lists
> my [type=oneshot] service when I start it, but I have no idea if it's
> related or not...
>
> Cheers,
>
> Adrien BESNARD
>
> 2016-05-26 11:59 GMT+02:00 Jan Alexander Steffens 
> :
>
>> You need to listen to JobRemoved signals. All of them, before you start
>> your job - trying to match on the specific job you get back from StopUnit
>> might not complete before the job is already removed.
>>
>> On Thu, May 26, 2016 at 8:20 AM Adrien Besnard 
>> wrote:
>>
>>> I managed to do what I wanted to do using add_timeout with the GLib's
>>> MainLoop: I poll every second the state of the unit and manually call the
>>> callback connected to DBus to fake the event when the unit is stopped.
>>>
>>> It works but this is a dirty hack. So I'm still interested by a real
>>> solution :)
>>>
>>> Cheers!
>>> Le 23 mai 2016 11:55, "Adrien Besnard"  a
>>> écrit :
>>>
 Hello,

 I'm trying to make a small Python script which send an email when a 
 *Type=oneshot
 *service ends (either in success or in failure).

 To do that, I'm using the dbus binding for Python, and connecting to
 the *PropertiesChanged* signal on the unit I'm monitoring.

 It works great when the process fails (the signal is triggered and I
 see *ActiveState* and *SubState* refleting the failure) but not when
 the service end successully.

 All I see is an *UnitRemoved* signal triggered by the manager
 interface... Is that normal?

 Do you guys have an idea of what I'm missing here?

 Thanks!
 --
 Adrien BESNARD

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

Re: [systemd-devel] DBus's PropertiesChanged signal is not triggered when an Unit stop successfully

[Adrien Besnard]

Thank you! I'll try that ASAP. Do I need to listen to JobRemoved because I
use the [type=oneshot] or is it the way to do for every kind of service
(like [type=simple], for example)?

I'm asking that because I just dicovered that [systemctl list-jobs] lists
my [type=oneshot] service when I start it, but I have no idea if it's
related or not...

Cheers,

Adrien BESNARD

2016-05-26 11:59 GMT+02:00 Jan Alexander Steffens :

> You need to listen to JobRemoved signals. All of them, before you start
> your job - trying to match on the specific job you get back from StopUnit
> might not complete before the job is already removed.
>
> On Thu, May 26, 2016 at 8:20 AM Adrien Besnard 
> wrote:
>
>> I managed to do what I wanted to do using add_timeout with the GLib's
>> MainLoop: I poll every second the state of the unit and manually call the
>> callback connected to DBus to fake the event when the unit is stopped.
>>
>> It works but this is a dirty hack. So I'm still interested by a real
>> solution :)
>>
>> Cheers!
>> Le 23 mai 2016 11:55, "Adrien Besnard"  a
>> écrit :
>>
>>> Hello,
>>>
>>> I'm trying to make a small Python script which send an email when a 
>>> *Type=oneshot
>>> *service ends (either in success or in failure).
>>>
>>> To do that, I'm using the dbus binding for Python, and connecting to the
>>> *PropertiesChanged* signal on the unit I'm monitoring.
>>>
>>> It works great when the process fails (the signal is triggered and I see
>>> *ActiveState* and *SubState* refleting the failure) but not when the
>>> service end successully.
>>>
>>> All I see is an *UnitRemoved* signal triggered by the manager
>>> interface... Is that normal?
>>>
>>> Do you guys have an idea of what I'm missing here?
>>>
>>> Thanks!
>>> --
>>> Adrien BESNARD
>>>
>> ___
>> systemd-devel mailing list
>> systemd-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>>
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Erlang bindings for systemd-notify API

[Lennart Poettering]

On Sun, 29.05.16 22:24, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> On Sun, May 29, 2016 at 10:59:23AM +0200, Peter Lemenkov wrote:
> > Hello All!
> > I'd like to introduce another systemd-related project -
> > erlang-sd_notify. That's just a bindings for sd_notify API. Currently
> > it implements bindings just for two functions - sd_notify and
> > sd_notifyf, which is enough for using "Type=notify" as a service type.
> > 
> > https://github.com/lemenkov/erlang-sd_notify
> > 
> > Library is a very simple one. It has been in use in a production
> > environments for a couple of years already.
> > 
> > I wonder if it's possible to host it somewhere at github.com/systemd
> > among other bindings or it's too small to be promoted?
> 
> I think it'd be reasonable to move it under the systemd umbrella.
> We already have "Erlang" team in systemd, that has one "ejournald"
> repo: https://github.com/orgs/systemd/teams/erlang.

Yeah, I agree, it certainly makes sense to add this to the systemd
umbrella. Not entirely sure what the workflow is supposed to be though
to make this happen...

Lennart

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

Re: [systemd-devel] Impossible to add events to event loop without adding at least one event before calling sd_event_loop() on systemd 222

[Lennart Poettering]

On Sun, 29.05.16 20:45, Christian Lockley (clockl...@gmail.com) wrote:

> Hi,
>  Just wondering if it should be possible to add events the empty event loop.

222 is already pretty old. That said, adding events before running the
event loop is what we do pretty much everywhere, so this really *does* work.

Lennart

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

Re: [systemd-devel] Best way to ensure only registered clients can use certain methods.

[Lennart Poettering]

On Sun, 29.05.16 20:41, Christian Lockley (clockl...@gmail.com) wrote:

> Hi all,
>  I developing an app that returns an id after and init function, this id is
> to be passed the subsequent calls so the program can prevent clients from
> modifying the internal state of other clients. Right now I store the value
> returned by sd_bus_message_get_sender() in the init function then
> call sd_bus_message_get_sender() again in all the other functions,
> verifying the value matches what I expect. Is this the correct or best way
> to do this?

Yes, and yes. 

Lennart

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

Re: [systemd-devel] why does bootctl default to /boot and not to /boot/efi?

[Simon McVittie]

On 29/05/16 19:39, Barry Scott wrote:
> I just came across the bootctl command. Atleast on Fedora 23 and 24
> it errors out because /boot is not FAT EFI. I thought that if you are EFI
> then the EFI was always in /boot/efi.

I think mounting the EFI System Partition on /boot/efi is likely to be
very common in practice. The kernel images in /boot are managed by dpkg
on Debian derivatives, and dpkg requires (or at least strongly
recommends) a POSIX filesystem on the directories it manages, so that it
can do standard POSIX filesystem robustness tricks like hard links and
atomic-overwrite.

-- 
Simon McVittie
Collabora Ltd. 

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

Re: [systemd-devel] Best way to ensure only registered clients can use certain methods.

[Mantas Mikulėnas]

On Mon, May 30, 2016 at 3:41 AM, Christian Lockley 
wrote:

> Hi all,
>  I developing an app that returns an id after and init function, this id
> is to be passed the subsequent calls so the program can prevent clients
> from modifying the internal state of other clients. Right now I store the
> value returned by sd_bus_message_get_sender() in the init function then
> call sd_bus_message_get_sender() again in all the other functions,
> verifying the value matches what I expect. Is this the correct or best way
> to do this?
>

IIRC, get_sender() returns the connection's unique D-Bus name, so yeah, it
would be safe to use.

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

Re: [systemd-devel] OT: Which tool to use to restart service if check-script fails

[Thomas Güttler]

Am 27.05.2016 um 09:40 schrieb Reindl Harald:



Am 27.05.2016 um 06:48 schrieb Thomas Güttler:

OK, I understand that I need different tool to restart a service
if a check-script fails.

In my case the check script will be custom code. But the restart stuff
is very general and reusable:

 Step1: Call check-script
 Step2: If exit 0 (meaning service is working), then wait N seconds, got
to Step1
 Step3: Service is not working: Send process the signal TERM_SIGNAL
(should be configurable)
 Step4: Wait N seconds until process terminated.
 Step5: If process did terminate, restart the service. Wait, go to Step1
 Step6: Process did not terminate: Wait N seconds, Send signal KILL
 Step7: Wait until OS has cleaned up the service
 Step8: Restart the service, Wait, got to Step1

I could implement these steps myself, but I am lazy. I guess this
has already been done several times before.

Any tool recommendation?


that are just a few lines code in any programming language


Yes, but I nevertheless I prefer to reuse.


your logic is way too complex - just SIGTERM and SIGKILL the service and a 
proper configured systemd-unit with
"Restart=always" will automatically restarted when you shoot the main process 
in the head


That's a reason why I like to reuse. I am just a small sheep,
and more intelligent sheep already solved many edge cases I don't see
at the first sight.


also; if the service was *manually* stopped it will keep stopped because the 
kill-calls won't do anything
_

[root@testserver:~]$ cat /etc/systemd/system/monitor-dbmail-lmtpd.service

> ..

Thank you for the code snippet.

If I don't find anything I can install via package manager, then I will
take this as a start.


Regards,
  Thomas

--
Thomas Guettler http://www.thomas-guettler.de/
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel