Re: [systemd-devel] When System is Degraded

[Martin Pitt]

Hey Aaron,

aaron_wri...@selinc.com [2016-06-06 10:27 -0700]:
> I'm using systemd in an embedded device that some some LEDs. I'd like to 
> make an LED red when the system starts up degraded, and green when 
> everything is working normally.
> I'm having a hard time figuring out where to fit this in.
> I tried using a service that runs "systemctl is-system-running" after I've 
> reached my target, but that command returns "starting", obviously.
> What's a better way to run a command when the system is "running" vs 
> "degraded"?

Try adding a .service with "Type=idle" and add it to your default
target (usually multi-user.target). This should run the unit after the
system is booted (i. e. running or degraded).

(Tested here with systemd 230)

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] CentOS 7 system using abstract namespace socket for notifications

[Lennart Poettering]

On Sun, 05.06.16 04:49, Dennis Jacobfeuerborn (denni...@conversis.de) wrote:

> Hi,
> I'm trying to make my javascript application compatible with the systemd
> service notification mechanism but currently have the problem that while
> everything works fine on my Fedora 22 system this is not the case when I
> run the same code on a CentOS 7 system.
> 
> I tracked this down to the fact that on the Fedora system a filesystem
> socket is used but on the CentOS 7 an abstract namespace socket with the
> name "@/org/freedesktop/systemd1/notify" is used which requires
> different handling.
> 
> I have two questions:
> 1) Why are the two systems using different types of sockets?

We used the abstract namespace socket in older systemd
versions. However, it's problematic in containers that do not use
network namespacing, as that socket on the host will conflict with the
same socket in any container, if systemd is running there too. (This
is because abstract namespace sockets are subject to network
namespacing, while file system sockets are subject to file system
namespacing. And all container managers apply the latter, but only
some the former.)

> 2) Is this configurable? If so how and if not what other way is there to
> test my service with abstract namespace notification sockets on my
> development machine?

No. This is not configurable, and it shouldn't be hardcoded anyway, as
it might be completely random, and subject to change. In fact, it's
not only different in various systemd versions but also depending on
whether you are run as --user or --system instance. Use $NOTIFY_SOCKET
to figure out what the socket for you is. And when putting together
the sockaddr_un simply replace an "@" as first char of the value by a
NUL byte, which tells Linux that this is an abstract namespace socket.

Lennart

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

[systemd-devel] When System is Degraded

[Aaron_Wright]

I'm using systemd in an embedded device that some some LEDs. I'd like to 
make an LED red when the system starts up degraded, and green when 
everything is working normally.
I'm having a hard time figuring out where to fit this in.
I tried using a service that runs "systemctl is-system-running" after I've 
reached my target, but that command returns "starting", obviously.
What's a better way to run a command when the system is "running" vs 
"degraded"?___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /usr/lib/systemd/*.wants vs. Wants in unit definition

[Simon McVittie]

On 06/06/16 15:17, Martin Pitt wrote:
> Of course it could also just do the usual WantedBy= in the unit and
> call systemctl enable on installation (that's what the Debian package
> does)

Most Debian packages with systemd services do this, but there are
exceptions.

> but there are cases where you don't really want to make the
> enablement configurable by the admin.

One example of this is dbus.service, which is statically enabled by
shipping symlinks in /lib/systemd/system in the .deb (as befits its "OS
infrastructure" status, in particular as something that is used by other
systemd components).

Conversely, polkitd.service is statically *disabled* (it doesn't ship
symlinks in the .deb and doesn't have a WantedBy), so it can be started
on-demand via D-Bus activation, but is never started "eagerly" during
boot (there would be no point).

-- 
Simon McVittie
Collabora Ltd. 

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

Re: [systemd-devel] /usr/lib/systemd/*.wants vs. Wants in unit definition

[Martin Pitt]

Andrei Borzenkov [2016-06-06 14:56 +0300]:
> Sorry I had to be more clear. What is advantage of shipping them in
> systemd? Systemd has well defined early boot services that are always
> needed. Why they are shipped as links instead of actually expressing
> those mandatory dependencies in unit definitions themselves?

I didn't mean links in the systemd package itself, but other packages
which want to hook into targets or services. E. g. the network-manager
package could ship a
network-online.target.wants/network-manager.service symlink.

Of course it could also just do the usual WantedBy= in the unit and
call systemctl enable on installation (that's what the Debian package
does), but there are cases where you don't really want to make the
enablement configurable by the admin.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /usr/lib/systemd/*.wants vs. Wants in unit definition

[Andrei Borzenkov]

On Mon, Jun 6, 2016 at 2:26 PM, Martin Pitt  wrote:
> Andrei Borzenkov [2016-06-06 13:55 +0300]:
>> What is advantage in having static *.wants etc directories in
>> /usr/lib/systemd vs. Wants etc directives directly in unit definition?
>> They complicate troubleshooting (you no more have complete definition
>> by looking just at unit source), they complicate building (extra steps
>> to install them); what are they good for?
>
> These are much simpler to ship in packages than shipping a
> foo.service.d/mywants.conf with "Wants=".


Sorry I had to be more clear. What is advantage of shipping them in
systemd? Systemd has well defined early boot services that are always
needed. Why they are shipped as links instead of actually expressing
those mandatory dependencies in unit definitions themselves?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /usr/lib/systemd/*.wants vs. Wants in unit definition

[Jan Alexander Steffens]

On Mon, Jun 6, 2016 at 1:27 PM Martin Pitt  wrote:

> Andrei Borzenkov [2016-06-06 13:55 +0300]:
> > What is advantage in having static *.wants etc directories in
> > /usr/lib/systemd vs. Wants etc directives directly in unit definition?
> > They complicate troubleshooting (you no more have complete definition
> > by looking just at unit source), they complicate building (extra steps
> > to install them); what are they good for?
>
> These are much simpler to ship in packages than shipping a
> foo.service.d/mywants.conf with "Wants=". In both cases the .service
> isn't completely self-contained but extended with an external file,
> but the symlinks are structurally simpler.
>

 Also, the conf snippets were introduced later. That said, the way symlinks
in these directories are handled is a bit weird. IIRC only the name of the
link matters, unless a unit by that name isn't known already, in which case
it's loaded through the link.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] /usr/lib/systemd/*.wants vs. Wants in unit definition

[Martin Pitt]

Andrei Borzenkov [2016-06-06 13:55 +0300]:
> What is advantage in having static *.wants etc directories in
> /usr/lib/systemd vs. Wants etc directives directly in unit definition?
> They complicate troubleshooting (you no more have complete definition
> by looking just at unit source), they complicate building (extra steps
> to install them); what are they good for?

These are much simpler to ship in packages than shipping a
foo.service.d/mywants.conf with "Wants=". In both cases the .service
isn't completely self-contained but extended with an external file,
but the symlinks are structurally simpler.

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] /usr/lib/systemd/*.wants vs. Wants in unit definition

[Andrei Borzenkov]

What is advantage in having static *.wants etc directories in
/usr/lib/systemd vs. Wants etc directives directly in unit definition?
They complicate troubleshooting (you no more have complete definition
by looking just at unit source), they complicate building (extra steps
to install them); what are they good for?

This is precisely about static links in /usr/lib, not about admin
overrides in /etc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel