Re: [systemd-devel] Is systemd-cryptsetup binary internal?

[Dimitri John Ledkov]

On Mon, 18 Sept 2023, 17:43 Nils Kattenbeck,  wrote:

> > Why was the decision taken to put these into /usr/lib/systemd instead of
>> > /usr/libexec/systemd/?
>>
>> That's a Fedoraism. Why would one put something there?
>>
>> /usr/lib/ is where private arch-dependent package stuff goes. What's
>> the rationale for /usr/libexec/ though?
>>
>
> I am not aware of it being a Fedoraism. It is at least also used/populated
> on an Ubuntu server I use and documented as part of the filesystem
> hierarchy (hier(7)):
> https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html#ftn.idm236091914528
>


On Ubuntu we mostly use multiarch locations for shared libraries i.e.
/usr/lib/(arch triplet) and /usr/libexec/(native only binaries). To allow
us to have additional places for native only and cross only tools. But it
is not set in stone. Many gnome, KDE, dbus things ship their binaries or
daemons or plugins under /usr/libexec. It sort of makes sense as /usr/lib
is confusing when it mixes public libraries, with private libraries and
binaries.

We can move things around in systemd as well, but on grand scheme of things
it is fairly minor tidy up, as neither locations are in default executable
paths. /usr/lib is in library search path, which was recently abused to
attack remote hosts to load unintended libraries at runtime and clear nx
(the recent ssh attack is hallarious and did use systemd to show really fun
stuff). So keeping only public libraries in /usr/lib going forward might be
a good idea.

>

Re: [systemd-devel] [PATCH 0/1] x86/kexec: UKI support

[Dimitri John Ledkov]

On Tue, 12 Sept 2023 at 11:38, Jarkko Sakkinen  wrote:
>
> On Tue Sep 12, 2023 at 2:20 AM EEST, Neal Gompa wrote: > On Mon, Sep 11, 2023 
> at 7:15 PM Jarkko Sakkinen  wrote:
> > > On Sat Sep 9, 2023 at 7:18 PM EEST, Jan Hendrik Farr wrote:
> > > > Hello,
> > > >
> > > > this patch implements UKI support for kexec_file_load. It will require 
> > > > support
> > > > in the kexec-tools userspace utility. For testing purposes the 
> > > > following can be used:
> > > > https://github.com/Cydox/kexec-test/
> > > >
> > > > There has been discussion on this topic in an issue on GitHub that is 
> > > > linked below
> > > > for reference.
> > > >
> > > >
> > > > Some links:
> > > > - Related discussion: https://github.com/systemd/systemd/issues/28538
> > > > - Documentation of UKIs: 
> > > > https://uapi-group.org/specifications/specs/unified_kernel_image/
> > > >
> > > > Jan Hendrik Farr (1):
> > > >   x86/kexec: UKI support
> > > >
> > > >  arch/x86/include/asm/kexec-uki.h   |   7 ++
> > > >  arch/x86/include/asm/parse_pefile.h|  32 +++
> > > >  arch/x86/kernel/Makefile   |   2 +
> > > >  arch/x86/kernel/kexec-uki.c| 113 +
> > > >  arch/x86/kernel/machine_kexec_64.c |   2 +
> > > >  arch/x86/kernel/parse_pefile.c | 110 
> > > >  crypto/asymmetric_keys/mscode_parser.c |   2 +-
> > > >  crypto/asymmetric_keys/verify_pefile.c | 110 +++-
> > > >  crypto/asymmetric_keys/verify_pefile.h |  16 
> > > >  9 files changed, 278 insertions(+), 116 deletions(-)
> > > >  create mode 100644 arch/x86/include/asm/kexec-uki.h
> > > >  create mode 100644 arch/x86/include/asm/parse_pefile.h
> > > >  create mode 100644 arch/x86/kernel/kexec-uki.c
> > > >  create mode 100644 arch/x86/kernel/parse_pefile.c
> > > >
> > > > --
> > > > 2.40.1
> > >
> > > What the heck is UKI?
> >
> > Unified Kernel Images. More details available here:
> > https://uapi-group.org/specifications/specs/unified_kernel_image/
> >
> > It's a way of creating initramfs-style images as fully generic,
> > reproducible images that can be built server-side.
>
> You can build today a kernel with these compiled in:
>
> 1. EFI stub
> 2. initeramfs
> 3. cmdline
>
> Why another way (and label 'UKI') for a pre-existing feature?
>

In Ubuntu, we have considered to use the existing kernel features
before going off to use UKI. Here are some of the reasons why we
didn't opt to use the kernel builtin things:
1) we wanted to have ability to have TPM measured kernel commandline
performed before kernel is being executed, which is what sd-stub
provides us
2) we wanted to have ability to update / regenerate initrd, without
rebuilding kernel. Thus whenever userspace in the initrd needs
updating, we can generate new initrd for existing kernel build, create
new kernel.efi, whilst using existing .linux / vmlinuz build. I don't
believe it is currently trivial to relink vmlinuz with builtin initrd.
3) licensing wise it was not clear if initrd has to be GPLv2
compatible when linked inside vmlinuz, or if it can contain GPLv3 /
LGPLv3 userspace code - with UKI it is believed unambigiously true,
because vmlinuz boots by itself standalone and is compiled separately
of the UKI.
4) we wanted to have ability to override cmdline via kernel args
without secureboot, and use stock cmdline args under secureboot, to
allow debugging & production behaviour from a single signed kernel.efi
(that was custom development, and could be done in the stock vmlinuz
too).
5) obvious mention, the intention here is to have TPM PCR measurements
and Secureboot signature for vmlinuz and initrd and cmdline and dtb.
There is otherwise no support for standalone signed initrd, cmdline,
dtb today. Nor does vendoring it into vmlinuz achieves this to the
same extent (and ease of predicting for sealing / resealing purposes).
6) in Ubuntu kernel.efi also has sbat section for targeted revocations
(discussed separately elsewhere)

Overall, it is mostly about flexibility to be able to reuse the same
initrd against multiple kernel builds, or update use multiple initrd
against the same kernel build. This is imho the biggest issue with
using initrd built-into the vmlinuz itself.
Resource wise, the initrd passed in via kernel.efi can be freed, as
far as I understand. I don't know if the one built-into the vmlinuz is
freeable.

Improving design to do something else instead of UKI would be
welcomed. Or for example improving the zimg linus upstream format to
be a partial or a valid UKI would help as well. For example, building
the kernel built-in initrd as a .initrd section that is replacable
would be nice, or allowing to preload zimg with .dtb or .cmdline
sections would help, and appropriately improve the linux efi stab to
do measurements and loading of .dtb / .initrd from itself would be
nice. Because then all the benefits / requirements described above
could be made available out of the box and be trivially updatable.

Re: [systemd-devel] Feedback sought: can we drop cgroupv1 support soon?

[Dimitri John Ledkov]

On Mon, 7 Aug 2023 at 17:26, Lennart Poettering  wrote:
>
> On Do, 20.07.23 01:59, Dimitri John Ledkov (dimitri.led...@canonical.com) 
> wrote:
>
> > Some deployments that switch back their modern v2 host to hybrid or v1, are
> > the ones that need to run old workloads that contain old systemd. Said old
> > systemd only has experimental incomplete v2 support that doesn't work with
> > v2-only (the one before current stable magick mount value).
>
> What's stopping you from mounting a private "named" cgroup v1
> hierarchy to such containers (i.e. no controllers). systemd will then
> use that when taking over and not bother with mounting anything on its
> own, such as a cgroupv2 tree.
>
> that should be enough to make old systemd happy.
>

Let me see if I can create all the right config files to attempt that.
I have some other constraints which may prevent this, but hopefully i
can provide sufficient workarounds to get this over the barrier.


--
okurrr,

Dimitri

Re: [systemd-devel] Feedback sought: can we drop cgroupv1 support soon?

[Dimitri John Ledkov]

Some deployments that switch back their modern v2 host to hybrid or v1, are
the ones that need to run old workloads that contain old systemd. Said old
systemd only has experimental incomplete v2 support that doesn't work with
v2-only (the one before current stable magick mount value).

Specifically that is trying to run sustemd v229 in a container:

https://bugs.launchpad.net/ubuntu/xenial/+source/systemd/+bug/1962332

When cgroupsv2 got added in the kernel doesn't matter, as much as, when
systemd started to correctly support cgroupsv2.
https://github.com/systemd/systemd/commit/099619957a0/

This shipped in v230 in May 2016, and I failed to backport this to v229 and
make it work in a container on an otherwise v2-only host - it still failed
to start for me.

230 was one month too late, and hence v229 shipped in Xenial Ubuntu 16.04
LTS, which will be supported through to 2026, including as a container on
newer hosts. Which for now only works if host is in hybrid or v1 modes.

To me, 6 years support is too short for the case of old container on a new
host.

And I wish to resolve inability for v229 to start as a container on v2-only
host and open to ship any minimal backport fix to unblock this.

The inverse problem of running newer containers on older systems also
exists, but usually such deployments find a way to also get newer hosts
easily.

Has anyone else managed to run v229 in a container on a v2-only host?



On Thu, 21 Jul 2022, 10:04 Lennart Poettering, 
wrote:

> Heya!
>
> It's currently a terrible mess having to support both cgroupsv1 and
> cgroupsv2 in our codebase.
>
> cgroupsv2 first entered the kernel in 2014, i.e. *eight* years ago
> (kernel 3.16). We soon intend to raise the baseline for systemd to
> kernel 4.3 (because we want to be able to rely on the existance of
> ambient capabilities), but that also means, that all kernels we intend
> to support have a well-enough working cgroupv2 implementation.
>
> hence, i'd love to drop the cgroupv1 support from our tree entirely,
> and simplify and modernize our codebase to go cgroupv2-only. Before we
> do that I'd like to seek feedback on this though, given this is not
> purely a thing between the kernel and systemd — this does leak into
> some userspace, that operates on cgroups directly.
>
> Specifically, legacy container infra (i.e. docker/moby) for the
> longest time was cgroupsv1-only. But as I understand it has since been
> updated, to cgroupsv2 too.
>
> Hence my question: is there a strong community of people who insist on
> using newest systemd while using legacy container infra? Anyone else
> has a good reason to stick with cgroupsv1 but really wants newest
> systemd?
>
> The time where we'll drop cgroupv1 support *will* come eventually
> either way, but what's still up for discussion is to determine
> precisely when. hence, please let us know!
>
> Thanks,
>
> Lennart
>
> --
> Lennart Poettering, Berlin
>

Re: [systemd-devel] Support for unmerged-usr systems will be REMOVED in the second half of 2023

[Dimitri John Ledkov]

Hi,

On Tue, 13 Jun 2023 at 16:01, Richard Purdie
 wrote:
>
> On Tue, 2023-06-13 at 15:56 +0100, Dimitri John Ledkov wrote:
> > Nobody is retroactively changing existing systemd releases.
> >
> > Stay on a previously released systemd version which will continue to
> > have features it used to have.
>
> I've seen the responses to bug reports with "not latest" releases of
> systemd so I doubt that is really to be recommended.
>

I don't believe Yocto is a blocker to land this change in the new
systemd upstream release, given the sufficient notice previously
issued.

If Yocto is so out of date, affected users can also migrate to other
embedded immutable distributions available out there: Ubuntu Core,
Fedora IOT, openSUSE MicroOS and similar.

-- 
okurrr,

Dimitri

Re: [systemd-devel] Support for unmerged-usr systems will be REMOVED in the second half of 2023

[Dimitri John Ledkov]

Nobody is retroactively changing existing systemd releases.

Stay on a previously released systemd version which will continue to have
features it used to have.


On Tue, 13 Jun 2023, 15:53 Richard Purdie, <
richard.pur...@linuxfoundation.org> wrote:

> On Tue, 2023-06-13 at 15:31 +0100, Luca Boccassi wrote:
> > On Tue, 13 Jun 2023 at 15:15, Richard Purdie
> >  wrote:
> > >
> > > On Tue, 2023-06-13 at 11:29 +0100, Luca Boccassi wrote:
> > > > On Tue, 20 Sept 2022 at 20:18, Luca Boccassi 
> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > Following this thread started back in April:
> > > > >
> > > > >
> https://lists.freedesktop.org/archives/systemd-devel/2022-April/047673.html
> > > > >
> > > > > As far as we understand there are no distributions running or
> > > > > optionally supporting systemd that have not either completed, or at
> > > > > least started, the transition to merged-usr systems.
> > > > >
> > > > > So, we are planning to drop support for unmerged-usr systems in the
> > > > > first release that will happen in the second half of next year,
> I.E.:
> > > > > any time starting from July 2023 (while we tend to release somewhat
> > > > > regularly we do not have strict dates and deadlines, so right now
> it's
> > > > > not possible to tell the exact version, but it will be of course
> > > > > communicated once it becomes clear).
> > > >
> > > > As previously announced, this is being prepared now and will be part
> of v254:
> > > >
> > > > https://github.com/systemd/systemd/pull/27999
> > >
> > > I'd note that nobody did resolve the issues for Yocto Project yet so
> > > our CI will break if we try and upgrade :(.
> >
> > Those issues are purely internal to Yocto's custom CI and completely
> > unrelated to systemd, as they manifest without systemd being even
> > enabled. The 'usrmerge' distro feature was added six years ago, in
> > 2017, by Yocto developers:
> >
> >
> https://git.yoctoproject.org/poky/commit/?id=178e983cf745fe32b199e0cbfe9777270124b186
> >
> > If even Yocto developers cannot manage to fix internal CI issues
> > created by internal features added by Yocto developers in 6 years,
> > there's hardly anything outsiders could possibly do, I'm afraid.
>
> The issue is that Yocto Project supports a variety of configurations
> and systemd has decided to drop support for some of them.
>
> Nobody has done the work to migrate the configuration combinations
> being dropped in Yocto Project.
>
> Distro features are optional in Yocto Project, we don't force people to
> use them. There are plenty of people with products shipping in the wild
> which do not use the "usrmerge" feature. Our own test matrix hasn't
> been adjusted to force usrmerge for systemd, nor is the documentation
> or migration information present for that change.
>
> This is not an issue caused by our "internal features" and to claim
> that is farcical.
>
> Richard
>
>
>
>
>
>
>
>
>

Re: [systemd-devel] What is wrong with my .path setup?

[John Ioannidis]

On Sun, Mar 20, 2022 at 5:26 PM John Ioannidis 
wrote:

> Here are my .path and .service files:
>
> $ *cat /etc/systemd/system/trigg.path *
> [Path]
> DirectoryNotEmpty=/root/trigger
> MakeDirectory=true
>
> $ *cat /etc/systemd/system/trigg.service *
> [Unit]
> Description=Trigger Service
>
> [Service]
> ExecStart=/usr/bin/touch /root/wastriggered
> Type=oneshot
>
>
I forgot to add:

$ *sudo systemctl status trigg.path *
● trigg.path
 Loaded: loaded (/etc/systemd/system/trigg.path; static; vendor preset:
enabled)
 Active: inactive (dead)
   Triggers: ● trigg.service
$ *sudo systemctl status trigg.service *
● trigg.service - Trigger Service
 Loaded: loaded (/etc/systemd/system/trigg.service; static; vendor
preset: enabled)
 Active: inactive (dead)


Thanks!

/ji

>
> Now, after robooting, I would have expected that /root/trigger would
> exist; it does not. And, of course, creating it manually and touching a
> file in there does not trigger the path.
>
> What am I missing? I have successfully used .path units in the past, and
> what I'm doing here looks right; unfortunately I do not have access to
> those old machines any more (previous employer).
>
> This is all on a fully-patched Ubuntu 20.04LTS machine:
> $ systemd --version
> systemd 245 (245.4-4ubuntu3.15)
> +PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP
> +GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN
> +PCRE2 default-hierarchy=hybrid
>

[systemd-devel] What is wrong with my .path setup?

[John Ioannidis]

Here are my .path and .service files:

$ *cat /etc/systemd/system/trigg.path *
[Path]
DirectoryNotEmpty=/root/trigger
MakeDirectory=true

$ *cat /etc/systemd/system/trigg.service *
[Unit]
Description=Trigger Service

[Service]
ExecStart=/usr/bin/touch /root/wastriggered
Type=oneshot


Now, after robooting, I would have expected that /root/trigger would exist;
it does not. And, of course, creating it manually and touching a file in
there does not trigger the path.

What am I missing? I have successfully used .path units in the past, and
what I'm doing here looks right; unfortunately I do not have access to
those old machines any more (previous employer).

This is all on a fully-patched Ubuntu 20.04LTS machine:
$ systemd --version
systemd 245 (245.4-4ubuntu3.15)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP
+GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN
+PCRE2 default-hierarchy=hybrid

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

[Dimitri John Ledkov]

On Tue, Nov 23, 2021 at 12:09 PM Lennart Poettering
 wrote:
>
> On Di, 23.11.21 11:53, Dimitri John Ledkov (dimitri.led...@canonical.com) 
> wrote:
>
> > Just an update from Ubuntu - for the upcoming release of Jammy (22.04
> > LTS targeting release in April 2022) we have started transition to
> > OpenSSL 3 and currently upgrading to systemd v249.
>
> Did Ubuntu adopt Debian's stance of accepting OpenSSL as system
> component? i.e. is OpenSSL 3 compatible with both (L)GPL 2.x code
> *and* GPL3 code in Ubuntu's eyes? Or only the latter?

I cannot possibly comment on or answer the above questions.

You might find some related comments from Ubuntu Archive team at
https://lists.ubuntu.com/archives/technical-board/2021-October/002587.html

Jammy will ship OpenSSL v3. Once it migrates, I will enable Jammy CI
against systemd pull requests, to ensure that the next systemd release
works on Jammy.

Regards,

Dimitri.

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

[Dimitri John Ledkov]

Just an update from Ubuntu - for the upcoming release of Jammy (22.04
LTS targeting release in April 2022) we have started transition to
OpenSSL 3 and currently upgrading to systemd v249.

W.r.t. library choice usually GnuTLS APIs are nicer to use; however
OpenSSL library tends to be the more performant one with more HW
optimizations, and easier to certify. These two properties alone make
me prefer OpenSSL whenever possible.

Regards,

Dimitri.

[systemd-devel] Proc protection of services and TemporaryFileSystem=/

[John]

TemporaryFileSystem=/ can be used to limit the file system with just some 
necessary paths set by BindReadOnlyPaths/BindPaths to some files, depending on 
what the service needs. This does not mount /proc and /sys.

There are some [service] settings regarding proc such as: ProtectProc, 
ProtectKernelTunables, ProtectControlGroups, ProcSubset which re-introduce 
/proc. My question is if their most protective functions are active just 
because /proc is not present. If so, systemd-analyze security could be improved 
by recognizing that /proc isn't available.

Examples:
ProtectProc=invisible
ProtectKernelTunables=true
ProtectControlGroups=true
ProcSubset=pid

On another note, ProtectHostname=true seems to cause a systemd error in a 
limited file system.

Any insights are appreciated.

[systemd-devel] Tracing source of "Message has the same reply serial as a currently-outstanding existing method call" with sd-bus based client

[John Ernberg]

Hi,

(systemd v243.2 - but did not see any changes to sd-bus between 243 and 
HEAD that could affect this)

I have developed a D-Bus service based on sd-bus that is a client to 2 
services. When service A sends a signal, service B writes a journald 
config file and then restarts journald using the systemd1 Manager D-Bus 
API RestartUnit method.

Both services share bus connection as they both are on the system bus.

On rare occasions this results in the callback getting the following 
D-Bus error back instead of restarting journald:
Message has the same reply serial as a currently-outstanding existing 
method call

The service doing all this is not threaded.

I'm struggling to determine the source of this problem, which may very 
well be in my code in the end, but I have no idea of what to look for in 
terms of possibly incorrect usage of sd-bus or in case of a bug in 
sd-bus, what values to check (and when) to find the root cause, and I'm 
seeking advice with this part.

Below follows a description of the client implementation, how it's 
called, and some things I found in a coredump that I thought was curious.

Please advice on how I shall move forward with my investigation of this 
problem. If more information is necessary, please let me know which 
information and I will do my best to provide it.

Thank you very much in advance.

Best regards // John Ernberg




The client code for restarting journald looks like this:

void org_freedesktop_systemd1_Manager_RestartUnit_callback(const char 
*error, const char* job) {
 if (error) {
 fprintf(stderr, "systemd1 could not restart the unit: %s\n", 
error);
 } else {
 printf("systemd1 has queued restarting the unit with this job 
path: %s\n", job);
 }
}

static int RestartUnit_internal_cbk(sd_bus_message *msg, void *userdata, 
sd_bus_error *error) {
 int ret = 1;
 const sd_bus_error *e = sd_bus_message_get_error(msg);
 const char* job = NULL;

 if (sd_bus_error_is_set(e)) {

org_freedesktop_systemd1_Manager_RestartUnit_callback(e->message, job);
 goto cleanup;
 }

 ret = sd_bus_message_read(msg, "o", &job);
 if (ret < 0) {
 goto cleanup;
 }

 org_freedesktop_systemd1_Manager_RestartUnit_callback(NULL, job);

cleanup:

 return ret;
}

int org_freedesktop_systemd1_Manager_RestartUnit(const char* name, const 
char* mode)
{
 int ret = 0;
 sd_bus_message *msg = NULL;

 ret = sd_bus_message_new_method_call(bus,
  &msg,
  "org.freedesktop.systemd1",
  "/org/freedesktop/systemd1",

"org.freedesktop.systemd1.Manager",
  "RestartUnit");
 if (ret < 0) {
 return ret;
 }


 ret = sd_bus_message_append(msg, "s", name);
 if (ret < 0) {
 goto cleanup;
 }

 ret = sd_bus_message_append(msg, "s", mode);
 if (ret < 0) {
 goto cleanup;
 }


 ret = sd_bus_call_async(bus, NULL, msg, &RestartUnit_internal_cbk,
 NULL, 0);
 if (ret < 0) {
 goto cleanup;
 }

cleanup:
 sd_bus_message_unref(msg);
 return ret;
}

The org_freedesktop_systemd1_Manager_RestartUnit function is called from 
the callback of the signal from service A.

I added an abort() to the RestartUnit callback if there was an error, 
and managed to catch a core of that state.

The only thing I managed to conclude of that so far is that there was 0 
entries in the reply_callbacks list at the time of invoking the 
RestartUnit callback, meaning there was only 1 entry in the hashmap and 
there were 2 slots allocated to RestartUnit_internal_cbk.

 From gdb in this coredump:

(gdb) print *bus->slots
$48 = {n_ref = 1, type = BUS_REPLY_CALLBACK, floating = true, 
match_added = false, bus = 0xaaab1fc647d0, userdata = 0x0, 
destroy_callback = 0x0, description = 0x0, slots_next = 0xaaab1fc6bcf0, 
slots_prev = 0x0, {reply_callback = {
   callback = 0xe64d8320 , 
timeout_usec = 52303930, cookie = 6, prioq_idx = 0}, filter_callback = 
{callback = 0xe64d8320 , last_iteration = 
52303930, callbacks_next = 0x6,
   callbacks_prev = 0x0}, match_callback = {callback = 
0xe64d8320 , install_callback = 0x31e183a, 
install_slot = 0x6, last_iteration = 0, after = 4673, match_string = 
0xa080 "\360\066",
   match_node = 0xa080}, node_callback = {node = 
0xe64d8320 , is_fallback = false, 
last_iteration = 0, callback = 0x6, callbacks_next = 0x0, callbacks_prev 
= 0x1241}, node_enumerator = {
   node = 0xe64d8320 , callback = 
0x31e183a, last_iteration = 6, enumerators_next = 0x0, enumerators_prev 
= 0x1241}, node_object_manager = {node = 0xe64d8320 
,
  

Re: [systemd-devel] What is the recommended way of announcing a TCP port?

[John Ioannidis]

On Tue, Jun 15, 2021 at 1:45 AM Mantas Mikulėnas  wrote:

> If you only care about processes on the same system – why not put the
> actual socket in /run, as an AF_UNIX socket? That's mostly what /run is for.
>

I thought of that, but Prometheus cannot scrape AF_UNIX addresses.

Thanks though,

/ji


> On Tue, Jun 15, 2021, 04:18 John Ioannidis  wrote:
>
>> I have an instanced service that gets started and stopped by another
>> service: *alice.service *runs the equivalent of *systemsctl start
>> alice@foo.service, systemctl start alice@bar.service, systemctl stop
>> alice@cat.service*, and so on.
>> Each of the instanced services runs a little http service so its status
>> can be monitored, metrics scraped, etc. The tcp port on which that service
>> runs is just whatever the kernel allocated. I want to export that port
>> number so other processes can find it and use it, for example, by doing the
>> equivalent of *systemctl list-units | grep alice@ *so they find which
>> instances are actually running, and then going about finding the
>> corresponding ports.
>>
>> I can think of a number of ad hoc ways:
>>
>> * they can write the port number in a file like /run/alice/foo.port,
>> /run/alice/bar.port, and whoever is interested can go read those files, in
>> the same way that we use .pid files.
>> * They can use systemd-notify to export it as "Status"
>> * Using a service discovery mechanism would be an overkill, especially
>> since whatever is actually talking to those ports is on the same host as
>> the services themselves, but that's also a possibility.
>>
>> Is there a systemd-native way of accomplishing this? It would be nice if
>> it were possible to have user-defined properties that could be set with 
>> *systemctl
>> set-property*, but that is not the case.
>>
>> Thanks
>>
>> /ji
>> ___
>> 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] What is the recommended way of announcing a TCP port?

[John Ioannidis]

On Mon, Jun 14, 2021 at 9:29 PM Kevin P. Fleming  wrote:

> You might consider having systemd itself create the listening sockets
> and then pass them into the service; if you did that, then systemd
> would already know the port number that was allocated for the socket.
>
>
I can't; a .socket unit gets activated, and subsequently starts its
corresponding service, when the first connection is made. The primary
purpose of the service is not to serve data over that socket; the socket is
there for scraping metrics.

Thanks though,

/ji

> On Mon, Jun 14, 2021 at 9:17 PM John Ioannidis 
> wrote:
> >
> > I have an instanced service that gets started and stopped by another
> service: alice.service runs the equivalent of systemsctl start
> alice@foo.service, systemctl start alice@bar.service, systemctl stop
> alice@cat.service, and so on.
> > Each of the instanced services runs a little http service so its status
> can be monitored, metrics scraped, etc. The tcp port on which that service
> runs is just whatever the kernel allocated. I want to export that port
> number so other processes can find it and use it, for example, by doing the
> equivalent of systemctl list-units | grep alice@ so they find which
> instances are actually running, and then going about finding the
> corresponding ports.
> >
> > I can think of a number of ad hoc ways:
> >
> > * they can write the port number in a file like /run/alice/foo.port,
> /run/alice/bar.port, and whoever is interested can go read those files, in
> the same way that we use .pid files.
> > * They can use systemd-notify to export it as "Status"
> > * Using a service discovery mechanism would be an overkill, especially
> since whatever is actually talking to those ports is on the same host as
> the services themselves, but that's also a possibility.
> >
> > Is there a systemd-native way of accomplishing this? It would be nice if
> it were possible to have user-defined properties that could be set with
> systemctl set-property, but that is not the case.
> >
> > Thanks
> >
> > /ji
> > ___
> > 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

[systemd-devel] What is the recommended way of announcing a TCP port?

[John Ioannidis]

I have an instanced service that gets started and stopped by another
service: *alice.service *runs the equivalent of *systemsctl start
alice@foo.service, systemctl start alice@bar.service, systemctl stop
alice@cat.service*, and so on.
Each of the instanced services runs a little http service so its status can
be monitored, metrics scraped, etc. The tcp port on which that service runs
is just whatever the kernel allocated. I want to export that port number so
other processes can find it and use it, for example, by doing the
equivalent of *systemctl list-units | grep alice@ *so they find which
instances are actually running, and then going about finding the
corresponding ports.

I can think of a number of ad hoc ways:

* they can write the port number in a file like /run/alice/foo.port,
/run/alice/bar.port, and whoever is interested can go read those files, in
the same way that we use .pid files.
* They can use systemd-notify to export it as "Status"
* Using a service discovery mechanism would be an overkill, especially
since whatever is actually talking to those ports is on the same host as
the services themselves, but that's also a possibility.

Is there a systemd-native way of accomplishing this? It would be nice if it
were possible to have user-defined properties that could be set with *systemctl
set-property*, but that is not the case.

Thanks

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

[systemd-devel] Ordering of oneshot services and path units?

[John Ioannidis]

tl;dr: a .path unit does not appear to be waiting for the After= unit to
run first.

I am still trying to understand why some services occasionally do not start
at boot time. It is a very intermittent behavior, but I caught another
instance. Everything is running in Google Compute Engine or Amazon EC2.

I have a one-shot service, *mktags.service*, a long-running job of type
*notify*, *ccistated.service*, and a path unit with its corresponding
service, *workdir.path* and *workdir.service*. Here are the relevant parts
of the unit files:


*mktags.service*

[Unit]
Description=Populate /run/metadata/tags
After=network.target
[Service]
ExecStart=/usr/local/sbin/mktags.py
Type=oneshot
[Install]
WantedBy=multi-user.target



*ccistated.service*

[Unit]
Description=State Machine Manager
After=mktags.service
ConditionPathExists=/run/metadata/tags/resource_class
[Service]
ExecStart=/usr/local/sbin/ccistated.py
Type=notify
NotifyAccess=all
[Install]
WantedBy = multi-user.target



*workdir.path *

[Unit]
Description=Trigger workdir.service when a job starts, creating a directory
in /opt/circleci/workdir
After=ccistated.service
ConditionPathExists=/run/metadata/tags/resource_class
[Path]
PathChanged=/opt/circleci/workdir
[Install]
WantedBy=multi-user.target


What *mktags* does is extract the metadata tags from the metadata service,
and populate /run/metadata/tags/.

$ systemctl status mktags.service
* mktags.service - Populate /run/metadata/tags
Loaded: loaded (/etc/systemd/system/mktags.service; enabled; vendor
preset: enabled)
Active: inactive (dead) since Sat 2021-03-27 05:34:00 UTC; 10min ago
   Process: 454 ExecStart=/usr/local/sbin/mktags.py (code=exited,
status=0/SUCCESS)
  Main PID: 454 (code=exited, status=0/SUCCESS)

Sure enough, it ran:

$ cat /run/metadata/tags/resource_class
waw

As did the next service:

$ systemctl status ccistated.service
* ccistated.service - State Machine Manager
Loaded: loaded (/etc/systemd/system/ccistated.service; enabled; vendor
preset: enabled)
Active: active (running) since Sat 2021-03-27 05:36:00 UTC; 8min ago
  Main PID: 1420 (python3)
 Tasks: 1 (limit: 9544)
Memory: 8.5M
CGroup: /system.slice/ccistated.service
`-1420 python3 /usr/local/sbin/ccistated.py

It's OK that it took a couple of minutes for ccistated to start up, it does
a few things before sending out the Notify.

But look at the old workdir.path:

$ systemctl status workdir.path
* workdir.path - Trigger workdir.service when a job starts, creating a
directory in /opt/circleci/workdir
Loaded: loaded (/etc/systemd/system/workdir.path; enabled; vendor
preset: enabled)
Active: inactive (dead)
  Triggers: * workdir.service
 Condition: start condition failed at Sat 2021-03-27 05:33:59 UTC; 22min
ago
`- ConditionPathExists=/run/metadata/tags/resource_class was
not met

Huh?!?!?! It's supposed to run after ccistated, and of course after mktags
(highlighted in cyan above). It appears to be running anyway, and of course
mktags has not gotten a chance to finish, and the ConditionExists file has
not been created yet.

Do .path units not obey the same startup rules?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Fwd: What could be causing a oneshot unit not to be run when a machine reboots?

[John Ioannidis]

I have the following service file:

[Unit]
Description=D
After=network.target

[Service]
ExecStart=/usr/local/sbin/mktags.py
Type=oneshot
User=root

[Install]
WantedBy=multi-user.target


Occasionally, when the machine reboots, it does not run. Here is the
evidence:

# uptime
05:50:11 up 20 min,  1 user,  load average: 0.14, 0.03, 0.01

The machine has been up for 20 minutes, so it rebooted at 05:30

# systemctl status mktags.service
* mktags.service - D
Loaded: loaded (/etc/systemd/system/mktags.service; enabled; vendor
preset: enabled)
Active: inactive (dead)

Weird... no indication of what the last process was... let's check
journalctl:

# journalctl -u mktags.service | tail -4
-- Reboot --
Mar 14 05:25:22 sll9 systemd[1]: Starting D...
Mar 14 05:25:22 sll9 systemd[1]: mktags.service: Succeeded.
Mar 14 05:25:22 sll9 systemd[1]: Finished D.

The last time the service ran was five minutes *before* I rebooted. Other
times the service runs fine. On the same machine, a bit later:

# uptime
05:57:31 up 2 min,  1 user,  load average: 0.31, 0.33, 0.14


# systemctl status mktags.service
* mktags.service - D
Loaded: loaded (/etc/systemd/system/mktags.service; enabled; vendor
preset: enabled)
Active: inactive (dead) since Sun 2021-03-14 05:55:14 UTC; 2min 24s ago
   Process: 468 ExecStart=/usr/local/sbin/mktags.py (code=exited,
status=0/SUCCESS)
  Main PID: 468 (code=exited, status=0/SUCCESS)
(more output indicated that the process indeed ran).



How do I even debug something like this? I have added code in mktags.py to
print stuff to stderr, so that journalctl picks it up. When the service
runs, the expected output is there. Where it does not run, it is not there
of course.

I cannot detect any other errors elsewhere; if the service fails to start,
and I reboot, it invariably runs then. Obviously this is not a solution;
these are unattended machines running on GCE!
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Suppressing spam error messages in the system journal

[Dimitri John Ledkov]

I agree that i should have had much lower log level.

This is now fixed properly upstream via
https://github.com/systemd/systemd/pull/18638/files

I will try to backport that to stable series or at least drop the log
level to debug.


On Mon, 19 Oct 2020 at 15:05, Michael Biebl  wrote:
>
> Am Mo., 19. Okt. 2020 um 15:56 Uhr schrieb Lennart Poettering
> :
> >
> > >   2) Could resolved be changed so that this message is only emitted
> > > (say) once for every 100 or 500 times that the condition is
> > > detected.
> >
> > We actually try hard to suppress unnecessary log lines, but I think
> > this one is a downstream change.
> >
>
>
> https://git.launchpad.net/ubuntu/+source/systemd/tree/debian/patches/resolved-Mitigate-DVE-2018-0001-by-retrying-NXDOMAIN-with.patch?h=ubuntu/focal-updates
>
> Bringing Dimitri into the loop here.
>
> Michael



-- 
Regards,

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

[systemd-devel] Debugging sd_notify / tracing notifications?

[John Ioannidis]

How can I trace what sd_notify(3) calls a program makes?

Obviously, I don't have the source, and running *strings* on it does reveal
a *READY=1* line, but it is unclear whether the code makes it to the point
where that gets sent.

Here is what I am *really* trying to accomplish; maybe I am going about it
the wrong way:

I have some vendor code that is invoked by the following service file:







*[Service]ExecStart=/opt/vendor/bin/fooRestart=alwaysUser=rootType=notifyNotifyAccess=execTimeoutStopSec=86400*

I occasionally need to send a SIGINT to the process, but finding it with
the equivalent of ps ax | grep foo is annoying and maybe not terribly
reliable. My first workaround was to create this script:





*#!/bin/sh/opt/vendor/bin/foo &pid=$!echo $pid > /run/foo.pidwait*

and change the [Service] part of the service file to:




*[Service]ExecStart=/usr/local/sbin/run-foo.shRestart=alwaysUser=root*


*Type=notifyNotifyAccess=allTimeoutStopSec=86400*


the idea being that the original program will still send the *sd_notify(),* and
I would have its pid.

However, this is not happening; *systemctl start foo.service *hangs for
about 30s, and then exits with:

Job for foo.service failed because a timeout was exceeded.
See "systemctl status foo.service" and "journalctl -xe" for details.

The relevant lines are:
systemd[1]: foo.service: start operation timed out. Terminating.
systemd[1]: foo.service: Main process exited, code=exited, status=143/n/a
systemd[1]: foo.service: Failed with result 'timeout'.
systemd[1]: Failed to start Foo.

Clearly I'm misunderstanding something about how sdnotify is supposed to
work. It would also help if I could *see* what is actually being sent.

Help?

Thanks,

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

Re: [systemd-devel] Journalctl reading incorrect file

[John Lane]

> 
> Is it possible you are playing some weird games with your machine ID
> or boot ID?
> 

Maybe. Yes. I have a oneshot service that writes /etc/machine-id using
constant hardware-based info. But I've been using that for over two
years without any issues.

I did notice this when trying to investigate machine and boot ids:

$ # systemd-id128 machine-id
Failed to get machine-ID: Invalid argument

whereas on my other machines this returns the expected value.

So I looked at the source for systemd-id128, eventually in
./libsystemd/sd-id128/id128-util.c I discovered that the machine id
value is parsed and must contain enough digits for a uuid with/without
the hyphens. I know... as `man machine-id` says ;)

My oneshot service uses enough of
/sys/devices/virtual/dmi/id/board_serial to set a 32-character
hexadecimal lowercase machine id. On my other machines this returned
enough data to form a 32-character id but it didn't on the new one, so
the machine id had insufficient characters in it. I modified that
service to ensure the machine id has the required number of characters.

Problem solved!

Thanks for the pointer which helped me locate and resolve my issue.

The reason for settting machine id to a predictable value is because of
a need to refer to it in scripts etc meant it needed to be known
up-front, before the first install, but be somehow tied to the machine's
hardware. So that's what we did.

As an aside... Changing the machine id after the machine has booted,
like my oneshot service does, doesn't affect the current journal. Either
a restart of the journal or a reboot is required. This isn't a massive
problem as, after that first boot, the machine id is already in
/etc/machine-id and doesn't actually change.

But I'd like to do it properly so it works on the first boot also... is
there a pointer to the correct way to use a script to set the machine id
during boot?

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

Re: [systemd-devel] Journalctl reading incorrect file

[John Lane]

> journalctl reads from both dirs, always. What makes you think it reads
> from the wrong dir only?
> 

when I do `journalctl` I only get output up to the switch-root:


Jan 28 08:33:31 archlinux systemd[1]: Reached target Switch Root.
Jan 28 08:33:31 archlinux systemd[1]: Starting Switch Root...
Jan 28 08:33:31 archlinux systemd[1]: Switching root.
Jan 28 08:33:31 archlinux audit: BPF prog-id=8 op=UNLOAD
Jan 28 08:33:31 archlinux audit: BPF prog-id=7 op=UNLOAD
Jan 28 08:33:31 archlinux audit: BPF prog-id=10 op=UNLOAD
Jan 28 08:33:31 archlinux audit: BPF prog-id=9 op=UNLOAD
Jan 28 08:33:31 archlinux systemd-journald[235]: Journal stopped

If I use -D to select the newest subdir of /var/log/journal then
I see live messages.

So I think it's reading from /run and not from /var but I could of
course be wrong. I'm just going on the fact that the "live" data is
definitely on /var and the /run file ends with the output above.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Journalctl reading incorrect file

[John Lane]

I'm still stuck on this one, if anyone can offer any advice I'd really
appreciate it as I'm not sure how to troubleshoot it.

On 15/01/2021 09:17, John Lane wrote:
> Hello,
> 
> I've just set up a new system and have noticed a problem with journalctl
> where it appears to be reading from the incorrect journal. The journal
> is running and I can direct it at the correct file using -D, but I don't
> understand what is happening.
> 
> There is a journal in /run/log/journal which contains events up to the
> switch root. There is a journal in /var/log/journal which contains those
> same events plus the events following the switch root. Events appear to
> be written correctly to /var but journalctl appears to read from /run.
> 
> # ls -ld /{var,run}/log/journal
> drwxr-sr-x+  3 root systemd-journal 80 Jan 14 13:50 /run/log/journal
> drwxr-sr-x+ 18 root systemd-journal 19 Jan 14 13:25 /var/log/journal
> 
> $ journalctl > /tmp/journal
> $ journalctl -D /run/log/journal/e4a4799a826d44d9a6887e24025d54ae >
> /tmp/run_journal
> $ journalctl -D /var/log/journal/9c29e192f536402e9565718f3bb04983 >
> /tmp/log_journal
> 
> $ diff /tmp/journal /tmp/run_journal # same
> $ sdiff /tmp/run_journal /tmp/var_journal # latter is superset
> 
> I have not customised /etc/systemd/journald.conf (it only contains
> commented out settings). I have not done anything different on this
> install vs others except it being on a different device.
> 
> I tried to fix it by restarting systemd-journald but it fails to restart
> (and I can't get a log message to report why). I then have no journal
> until I reboot.
> 
> Not sure what to do to fix this, pointers appreciated...
> 
> Some details:
> 
> # systemctl --version && uname -a
> systemd 247 (247.2-1-arch)
> +PAM +AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP
> +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID
> +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid
> Linux xx 5.10.6-arch1-1 #1 SMP PREEMPT Sat, 09 Jan 2021 18:22:35
> + x86_64 GNU/Linux
> (Arch Linux)
> 
> 
> 
> ___
> 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

[systemd-devel] Journalctl reading incorrect file

[John Lane]

Hello,

I've just set up a new system and have noticed a problem with journalctl
where it appears to be reading from the incorrect journal. The journal
is running and I can direct it at the correct file using -D, but I don't
understand what is happening.

There is a journal in /run/log/journal which contains events up to the
switch root. There is a journal in /var/log/journal which contains those
same events plus the events following the switch root. Events appear to
be written correctly to /var but journalctl appears to read from /run.

# ls -ld /{var,run}/log/journal
drwxr-sr-x+  3 root systemd-journal 80 Jan 14 13:50 /run/log/journal
drwxr-sr-x+ 18 root systemd-journal 19 Jan 14 13:25 /var/log/journal

$ journalctl > /tmp/journal
$ journalctl -D /run/log/journal/e4a4799a826d44d9a6887e24025d54ae >
/tmp/run_journal
$ journalctl -D /var/log/journal/9c29e192f536402e9565718f3bb04983 >
/tmp/log_journal

$ diff /tmp/journal /tmp/run_journal # same
$ sdiff /tmp/run_journal /tmp/var_journal # latter is superset

I have not customised /etc/systemd/journald.conf (it only contains
commented out settings). I have not done anything different on this
install vs others except it being on a different device.

I tried to fix it by restarting systemd-journald but it fails to restart
(and I can't get a log message to report why). I then have no journal
until I reboot.

Not sure what to do to fix this, pointers appreciated...

Some details:

# systemctl --version && uname -a
systemd 247 (247.2-1-arch)
+PAM +AUDIT -SELINUX -IMA -APPARMOR +SMACK -SYSVINIT +UTMP
+LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID
+ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid
Linux xx 5.10.6-arch1-1 #1 SMP PREEMPT Sat, 09 Jan 2021 18:22:35
+ x86_64 GNU/Linux
(Arch Linux)



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

Re: [systemd-devel] require a system service unit to start a user service as a dependency

[John]

On Thu, Dec 24, 2020 at 3:29 AM Andrei Borzenkov  wrote:
>
> On Thu, Dec 24, 2020 at 5:48 AM John  wrote:
> >
> > I need to have the following start
> > /usr/lib/systemd/user/pulseaudio.service so it can make use of
> > pulseaudio.  Using a After= or Wants= does not work.  What is the
> > correct way to have a system service like this run a user service
> > unit?
> >
>
> No, that's not possible. PA also supports system service, if this is a
> kiosk system, maybe you can use it instead.

Thank you for the reply.  There are security risks running pulseaudio
in system mode[1].  I can append use PAMName=login and
After=systemd-user-sessions.service, but doing so moves the service
out of the system slice into the user slice.  Once in the user slice,
when called to reboot or shutdown, systemd brutally kills it before it
can gracefully stop which causes data loss as documented in my
previous thread[2].

Is there solution that keeps the service under the user slice and
allows systemd to wait for it to shutdown before killing on on a
system reboot/shutdown?

1. 
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/WhatIsWrongWithSystemWide/
2. 
https://lists.freedesktop.org/archives/systemd-devel/2020-December/045713.html
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] require a system service unit to start a user service as a dependency

[John]

I need to have the following start
/usr/lib/systemd/user/pulseaudio.service so it can make use of
pulseaudio.  Using a After= or Wants= does not work.  What is the
correct way to have a system service like this run a user service
unit?

% cat /usr/lib/systemd/system/kodi.service
[Unit]
Description=Kodi standalone (GBM)
After=remote-fs.target network-online.target nss-lookup.target
sound.target bluetooth.target polkit.service upower.service
mysqld.service
Wants=network-online.target polkit.service upower.service
Conflicts=getty@tty1.service

[Service]
User=kodi
Group=kodi
EnvironmentFile=-/etc/conf.d/kodi-standalone
TTYPath=/dev/tty1
Environment=WINDOWING=gbm
ExecStart=/usr/bin/kodi-standalone
ExecStop=/usr/bin/killall --user kodi --exact --wait kodi-gbm
Restart=on-abort
StandardInput=tty
StandardOutput=journal

[Install]
Alias=display-manager.service
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] service kills application differently on shutdown vs on stop

[John]

Thank you for the reply, Colin.  I found that to be the case[1].  I
think everything is working as expected now.  I still have quirks with
the kodi-x11.service since it has to call xinit as well as the kodi
binary but I do not know of a cleaner way to do it unless there is a
multiple unit solution to be had (one for xserver and another for
kodi).

1. 
https://github.com/graysky2/kodi-standalone-service/commit/909f274d6eaf011add6326b28b42fecb9123c7df

On Mon, Dec 14, 2020 at 11:12 AM Colin Guthrie  wrote:
>
> John wrote on 14/12/2020 12:52:
> > Note that it looks
> > like I will need to add some udev rules to allow the kodi user to
> > shutdown the system which it could do when the PAMName=login was
> > present.
>
> Just a small hint, but it might be policykit rules you need to add
> rather than udev rules.
>
> Col
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] service kills application differently on shutdown vs on stop

[John]

On Mon, Dec 14, 2020 at 12:39 AM Andrei Borzenkov  wrote:
> If your application creates user session, on shutdown systemd will stop
> existing sessions and it happens independently of your service.

Andrei - Thank you for this info.  It caused me to search 'systemd
wait for user session on shutdown.'  It seems that in order to avoid
systemd killing my processes running as the kodi user without waiting,
I need to make certain that they aren't in the user.slice (traceable
by running `systemd-cgls`).  Removing the PAMName=login seems to
achieve this (as well removing systemd-user-sessions.service from
After=).

I need to do some testing before I call this solved but I plan to push
a commit to my github repo:
https://github.com/graysky2/kodi-standalone-service should others
reading this want to see the modified service.  Note that it looks
like I will need to add some udev rules to allow the kodi user to
shutdown the system which it could do when the PAMName=login was
present.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] service kills application differently on shutdown vs on stop

[John]

If I call systemctl to shutdown or reboot, the effect is that it does
not honor kodi-x11.service's ExecStop= line which results in an
unclean exit of kodi and of data loss since kodi writes out some data
when it exits.  By contrast, calling systemctl to stop the service
works as expected.

Does anyone with more knowledge that I understand the differences with
respect to this aspect of stopping a service as it relates to:

1) systemctl stop kodi-x11 (which behaves as expected)
2) systemctl reboot (which does not behave as expected)

Here is kodi-x11.service:

[Unit]
Description=Kodi standalone (X11)
After=remote-fs.target systemd-user-sessions.service
network-online.target nss-lookup.target sound.target bluetooth.target
polkit.service upower.service mysqld.service
Wants=network-online.target polkit.service upower.service
Conflicts=getty@tty1.service

[Service]
User=kodi
Group=kodi
EnvironmentFile=-/etc/conf.d/kodi-standalone
PAMName=login
TTYPath=/dev/tty1
Environment=WINDOWING=x11
ExecStart=/usr/bin/xinit /usr/bin/kodi-standalone -- :0 -quiet -nolisten tcp vt1
ExecStop=/usr/bin/killall --user kodi --exact --wait kodi-x11
Restart=on-abort
StandardInput=tty
StandardOutput=journal

[Install]
Alias=display-manager.service
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Running scripts after networkd has done its things

[John Ioannidis]

I'm trying to be a good boy and migrate as much functionality as I can to
networkd.

I'm happy with how networkd manages "internal" and "external" interfaces
and vlans for just setting up IPv4 addresses, but I still find support for
IPv6 to be woefully inadequate, at least for my environment;
netfilter/ipfilter support is also too rudimentary. What would be the
"correct" (whatever that means!) way to run scripts after networkd has
finished coming up, and before it has started going down? Essentially, I
want to emulate the up/down feature of ifupdown.

Adding a service with
[Unit]
After=systemd-networkd-wait-online.service
Before=network.target
#more stuff

seems to do the trick, but maybe it's affecting the rest of the networking
systemd dependencies in ways that will come and bite me later.


FWIW, this is on Debian Buster (10) on intel hardware, with:
$ systemd --version
systemd 241 (241)
+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP
+GCRYPT +GNUTLS +ACL +XZ +LZ4 +SECCOMP +BLKID +ELFUTILS
+KMOD -IDN2 +IDN -PCRE2 default-hierarchy=hybrid

Thanks,

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

Re: [systemd-devel] howto switch from grub2-bios to systemd-boot

[Dimitri John Ledkov]

On Mon, 22 Jun 2020 at 18:03, Reindl Harald  wrote:
>
>
>
> Am 22.06.20 um 17:21 schrieb Mantas Mikulėnas:
> > On Mon, Jun 22, 2020 at 5:01 PM Reindl Harald  > > wrote:
> >
> > what is the best way to get a Fedora using legacy-boot to UEFI and at
> > the same time switch from grub2 to systemd-boot?
> >
> >
> > This isn't a Fedora mailing list?
>
> but a systemd-list, sorry for mention the distribution instead as others
> only throw "how can i get systemd-bott working" into the ring
>
> > can /boot holding the kernel itself still be a Linux RAID1 or classical
> > ext4 partition or is it required that the kernel and initrd live on the
> > EFI partition too?
> >
> > For systemd-boot, the kernel is required to be on the same EFI partition
> ok, so it will become grub in uefi mode, no way that i store my kernel
> on vfat

You can enroll your own PK, KEK, DB keys, and sign & install your own
UEFI drivers which implement other file systems see
https://github.com/pbatard/efifs/tree/master/EfiFsPkg

-- 
Regards,

Dimitri.

-- 
Regards,

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

Re: [systemd-devel] What is the point of making timesyncd bus-activatible?

[Dimitri John Ledkov]

On Tue, 19 May 2020 at 10:31, Arian Van Putten  wrote:
>
> Hey list,
>
> systemd-timesyncd has an Alias=dbus-org.freedesktop.timesync1.service and an 
> accompanying dbus service file too.
>
>  It is started in early boot; `Before=sysinit.target`  so why would making it 
> dubs-activatible ever make sense? It is always started way before 
> dbus.service itself is started.
>
> It also seems that the unit type is not Type=dbus (and doesn't set a BusName) 
> which confuses me a bit. So maybe I'm misunderstanding how dbus integration 
> works here. Ist that because we want to consider the services "ready" before 
> they even register a name on the bus?
>
> Similarly systemd-resolved.service and systemd-networkd.service have such 
> aliases whilst they're both pulled in by `multi-user.target` and also do not 
> have `Type=dbus` and `BusName=` set.
>
> What are the reasons for that?   For resolve1 i guess it makes sense as you 
> dont have to think about ordering when making dns calls in services. But I am 
> still confused why it is not of Type=dbus. Is that because it not only gives 
> a dbus API but also a DNS api?
>

it serves requests on 127.0.0.53 and provides dynamic files generated
in /run/systemd/resolve/ which can be targets of /etc/resolv.conf
symlink. Hence even without anything talking to it over dbus or lo
interface, it can be serving information to the system. I.e. it
populates both /run/systemd/resolve/resolv.conf and
/run/systemd/resolve/stub-resolv.conf either of which can be symlinked
to /etc/resolv.conf for nss modules to use.

-- 
Regards,

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

[systemd-devel] IPv6 dhcp-acquired prefix delegation?

[John Ioannidis]

I am running systemd v241, the one that comes with debian-10.

Is the following scenario possible natively (that is, without using a
standalone dhcpv6 client)?


   - My residential ISP will normally hand me a /64, but will give me a /56
   if I ask for it. While technically not a statically-allocated prefix, it
   changes very rarely: I had had the same prefix for over three years until I
   started experimenting with systemd-networkd and killed my old lease files.
   - I have several local vlans, and I want to give a different /64 to each
   one of them, but if the prefix I get from upstream changes, I want them to
   automatically renumber.
   - I'm perfectly happy relying on SLAAC for the local vlans, but I'm not
   against having to also run a dhcpv6 server to hand out addresses and things.

My previous solution, using ifupdown instead of systemd was this:

   1. dhcpv6 client with -P --prefix-len-hint 56, which gets the /56 and
   the default route.
   2. A script in /etc/dhcp/dhclient-exit-hooks.d/ that builds an
   /etc/radvd.conf file with bits 56-63 appropriately numbered, and then
   restarts radvd.

I have been totally unable to reproduce this behavior with pure networkd;
in fact, I cannot even get a dhcpv6 session going. I do not want to rely on
RAs from upstream, just DHCPv6. Here is a minimal .network file for the
external interface ("ethwan")

[Match]
Name=ethwan

[Network]
DHCP=yes
IPForward=yes
IPMasquerade=no
IPv6PrivacyExtensions=no
IPv6AcceptRA=no

[DHCP]
UseDNS=no
UseNTP=yes
UseRoutes=yes
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd.network vs. ifupdown vs. netplan?

[John Ioannidis]

Is there a document somewhere that details what the
interactions/conflicts/etc are between systemd.{link,netdev,network} and
the ifupdown mechanisms? I have read the manual pages, of course, but I
feel I'm missing something fundamental. I finally got around to moving to
Debian 10, and in the process modernizing some of my configurations.

Then there is netplan, which Canonical is pushing with Ubuntu; it does not
have feature parity with ifupdown, so it is not under consideration right
now, but if the comparison includes that, so much the better.

Cheers,

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

Re: [systemd-devel] If systemd service fails how to get a dependency service to fail also

[John]

On Sat, Apr 25, 2020 at 2:19 AM Andrei Borzenkov  wrote:
>
> ps.service does not call any script on startup.
> >
> > 1) psd.service remains in an active state
> > 2) psd-resync.timer remains active
> >
> > I'd like:
> > 1) both psd.service and psd-resync.service to both end in an error state.
> > 2) psd-resync.timer to get deactivated
> >
>
> Assuming service that fails is psd-resync.service, as far as I can tell
> the only way is to add BindsTo=psd-resync.service to both psd.service
> and psd-resync.timer.

Thank you for the review and for the reply.  Since posting, I changed
psd.service  to have an ExecStart and I also modified the units with a
BindsTo per your suggestion.

1. Now psd.service calls the script in a new check mode.  If no error
code is returned, psd-resync.timer calls psd-resync.service and I get
the desired effect.
2. If the script ends in an error, psd.service fails and
psd-resync.service and timer also fail.

Please take a look at the units now.  Is everything sane?
https://github.com/graysky2/profile-sync-daemon/tree/e002b321acff67fcbe41e1bd2ee2563776729813/init
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] If systemd service fails how to get a dependency service to fail also

[John]

I'd like to have systemd (user mode) call a bash script with different
tokens under two conditions:
1) When the user starts/stops a service (token would be either "sync"
or "unsync")
2) When a timer tells it to run (token would be "sync")

Thus far, I have been accomplishing these with 1 service and 1
service/timer combo:

All three files can be found here for reference:
https://github.com/graysky2/profile-sync-daemon/tree/ce290b54069b015879f53d631f82ed97bfe73d47/init

So the user starts psd.service and both psd-resync.{service,timer} get
activated and run as expected.  The problem is when the script that
psd.service calls ends in an error state...

1) psd.service remains in an active state
2) psd-resync.timer remains active

I'd like:
1) both psd.service and psd-resync.service to both end in an error state.
2) psd-resync.timer to get deactivated

I've been through the man pages for systemd.service and systemd.timer
to the point where I am confused who to achieve this.  What is the
right strategy using services and a timer to deliver on this?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] initrd.target indirection no longer available

[Dimitri John Ledkov]

Hi,

In v245 systemd started to default to `initrd.target`, instead of
`default.target` in the initrd. However, unlike `default.target` in
the running system, `initrd.target` is not an indirection symlink.

Specifically, default.target is a symlink to like graphical.target or
like multi-user.target and nothing depends on it. Thus one can bake
images that that make default.target to be a symlink to something
else, which can divert boot to a different transaction (reach it,
start a few other transactions) and then isolate to regular
graphical.target/multi-user.target etc.

initrd.target however, is not an indirection symlink, but it s a real
one. So in my case, I do want to subvert initrd boot, reach the
transaction, run a few more transactions, and then start initrd.target
to complete the initrd stage of the boot and pivot to real root.

However it is not trivial to do so, because initrd.target semantics
are those closer to "multi-user.target" or "graphical.target", rather
than default.target (which is strictly only a symlink).

Solution 1 - Would people be open to creating:
1) default-initrd.target which is a symlink to initrd.target
2) changing main.c initrd special target to be default-initrd.target

This way, in the initrd "out of the box" things boot to
default-initrd.target -> initrd.target, but also allow to subvert
default-initrd.target to something else, and later start initrd.target
without modifying any third party that already integrates with
initrd.target (ie. dracut etc).

This also fixes regression from v244, where initrd used to boot to
default.target symlink, and one used to be able to point that symlink
to something else, instead of initrd.target, whilst preserving the
out-of-the-box correct behaviour.

Or in a closer spirit to v244 can we do something like:
Solution 2:
1) if rd.systemd.unit / --unit args passed use those
2) if default.target exists use that
3) else use initrd.target ?

Because v245 has lost sensitivity to
/etc/systemd/system/default.target symlink pointing at something else
but initrd.target.

-- 
Regards,

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

Re: [systemd-devel] Read-only /etc, machine-id with an overlay - journald failing

[Dimitri John Ledkov]

On Wed, 26 Feb 2020 at 09:59, Andreas Kempe  wrote:
>
> Hello everyone,
>
> I'm working in a project with an embedded Linux system based on
> Openembedded using Systemd version 241 as our init process. We're
> using a read-only /etc. To facilitate development, we want to use a
> writeable overlay on /etc, but we ran into an issue.
>
> When we start, Systemd detects that there is no machine-id file
> present in /etc so it generates and mounts a /etc/machine-id. When our
> mount unit then applies the overlay on /etc, it hides the mounted
> file. Journald later fails to start because /etc/machine-id isn't
> visible through the overlay.
>

I would expect the /etc/machine-id to exist, and be an empty file on
the RO underlay, then systemd should setup machine-id in /run, and
then after the overlay of /etc is setup to use and is RW, fire the
systemd-machine-id-commit.service unit which will transfer the
machine-id from /run into the RW /etc overlay, after that everything
else should operate "normal".

We do this in Ubuntu live installer images, which use overlayfs across
all of / on top of read-only squashfs rootfs.


> At this point we're considering a number of workarounds, but I thought
> it worthwhile asking the experts before we go patching Systemd or
> similar.

I think didrocks or pitti introduced above for all the cases we had in
ubuntu where we have RO rootfs with a writable overlay which "appears"
later.

No idea if above is suitable for you at all, and/or need tweaking.
I.e. self-transfer machine-id from /run to /etc with like adding
wants=/before= systemd-machine-id-commit.service or some such?

-- 
Regards,

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

[systemd-devel] How does systemd (pid1) connect to system DBus?

[Dimitri John Ledkov]

I see that systemd pid1 manager is available on the system DBus.

But when/how does it connect to it?

I'm failing to trace it in both systemd & dbus code. I assume that
systemd starts, eventually starts dbus.socket/service, dbus starts,
and then something causes systemd to connect to the system bus.

I see that there is USR1 signal handler, but I'm failing to find
anything that sends it to PID1.

Please send links to source code line numbers / functions. Somehow I'm
failing to trace this stuff.

-- 
Regards,

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

Re: [systemd-devel] systemd-nspawn isolation potentially causing issues with distccmon-text

[John]

I made some progress... I modified the script to start the container like this:
exec ${CARCH:+setarch "$CARCH"} systemd-nspawn -q \
  -D "$working_dir" \
  -E "PATH=/usr/local/sbin:/usr/local/bin:/usr/bin" \
  --register=yes --as-pid2 --machine=test \
  "${mount_args[@]}" \
  "$@"

Now when the script is called, machinectl can see the container, but I
cannot connect to it:

# systemd-run --pipe -M test /usr/bin/distccmon-text
Failed to create bus connection: Protocol error

# machinectl
MACHINE CLASS SERVICEOS   VERSION ADDRESSES
test   container systemd-nspawn arch -   -

1 machines listed.

On Tue, Nov 19, 2019 at 4:14 AM Lennart Poettering
 wrote:
>
> On Fr, 15.11.19 17:17, John (gray...@archlinux.us) wrote:
>
> > The container is created by one of the Arch Linux build scripts
> > (https://git.archlinux.org/devtools.git/tree/arch-nspawn.in).  I do
> > not believe it runs with its own systemd/dbus.  When I am compiling
> > (https://git.archlinux.org/devtools.git/tree/makechrootpkg.in) in the
> > container, is there a way I can run distccmon-text from within the
> > same container to get it to read the same PID values?
>
> No this doesn't work. PID namespacing is kinda at the core of what a
> container is, making them match in the host and container's view isn't
> really feasible.
>
> (You should be able to run your distcc tool inside the container
> though, with systemd-run --pipe -M  …)
>
> Sorry!
>
> Lennart
>
> --
> Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-nspawn isolation potentially causing issues with distccmon-text

[John]

Thank you for the reply. I believe the container is being invoked from
a user session.  I am unclear how to set the containername.  The Arch
tools are invoking systemd-nspawn like this:

exec ${CARCH:+setarch "$CARCH"} systemd-nspawn -q \
 -D "$working_dir" \
 -E "PATH=/usr/local/sbin:/usr/local/bin:/usr/bin" \
 --register=no --keep-unit --as-pid2 \
"${mount_args[@]}" \
"$@"

I tried appending a -M name into that mix but got these errors.  Can
you recommend a workaround for either the script or the systemd-run
command?

"--keep-unit --register=yes may not be used when invoked from a user session."

On Tue, Nov 19, 2019 at 4:14 AM Lennart Poettering
 wrote:
>
> On Fr, 15.11.19 17:17, John (gray...@archlinux.us) wrote:
>
> > The container is created by one of the Arch Linux build scripts
> > (https://git.archlinux.org/devtools.git/tree/arch-nspawn.in).  I do
> > not believe it runs with its own systemd/dbus.  When I am compiling
> > (https://git.archlinux.org/devtools.git/tree/makechrootpkg.in) in the
> > container, is there a way I can run distccmon-text from within the
> > same container to get it to read the same PID values?
>
> No this doesn't work. PID namespacing is kinda at the core of what a
> container is, making them match in the host and container's view isn't
> really feasible.
>
> (You should be able to run your distcc tool inside the container
> though, with systemd-run --pipe -M  …)
>
> Sorry!
>
> Lennart
>
> --
> Lennart Poettering, Berlin
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-nspawn isolation potentially causing issues with distccmon-text

[John]

On Wed, Nov 13, 2019 at 7:03 PM Uoti Urpala  wrote:
>
> On Wed, 2019-11-13 at 10:24 -0500, John wrote:
> > I am using systemd-nspawn to compile in a clean environment.  My
> > distcc cluster happily accepts requests from the container's build,
> > but the monitoring utility, distccmon-text, shows no output. I invoked
> > it defining the DISTCC_DIR variable to the correct directory in the
> > container.
>
> > Link to strace from the container:
> > https://gist.github.com/graysky2/0886025b60335de4c0b19ddf11f7aafb
>
> Your description is somewhat unclear. I'm assuming that this is
> actually a strace from OUTSIDE the container (as in, you are not
> running the distcc-mon program inside the container, but running it on
> the host system and only giving it a path to a filesystem location used
> by the in-container compilation process), and that this is the case you
> are trying to get working.

Correct.  I provided the 2nd strace (distcc outside and monitor
outside) as a positive control.

> I believe the problem is that the program reads PID values from the
> filesystem, but PIDs are not the same inside the container and outside.
> Thus recording a PID value inside the container and then trying to use
> that PID to find the same process from the host system will not work.
>
> If your container runs as a full enough machine with its own systemd
> and dbus, then the simplest solution is likely to run the monitoring
> utility in the container, for example with:
> machinectl shell  

The container is created by one of the Arch Linux build scripts
(https://git.archlinux.org/devtools.git/tree/arch-nspawn.in).  I do
not believe it runs with its own systemd/dbus.  When I am compiling
(https://git.archlinux.org/devtools.git/tree/makechrootpkg.in) in the
container, is there a way I can run distccmon-text from within the
same container to get it to read the same PID values?

I tried the following syntax but was met with a busy error:

# systemd-nspawn --directory /scratch/.chroot64/facade
DISTCC_DIR=/build/.distcc distccmon-text
Directory tree /scratch/.chroot64/facade is currently busy.

Appending the --ephemeral switch does not help:

# systemd-nspawn --directory /scratch/.chroot64/facade --ephemeral
DISTCC_DIR=/build/.distcc distccmon-text
Spawning container facade-8237d3321ae02886 on
/scratch/.chroot64/.#machine.facade197913f7d7ed5442.
Press ^] three times within 1s to kill container.
execv(DISTCC_DIR=/build/.distcc) failed: No such file or directory
Container facade-8237d3321ae02886 failed with error code 1.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd-nspawn isolation potentially causing issues with distccmon-text

[John]

I am using systemd-nspawn to compile in a clean environment.  My
distcc cluster happily accepts requests from the container's build,
but the monitoring utility, distccmon-text, shows no output. I invoked
it defining the DISTCC_DIR variable to the correct directory in the
container.

I collected an strace of distccmon-text (linked below).  When I
compare it to an strace of distccmon-text running without the
container at all I see the following line as a key difference repeated
quite a bit:

kill(9307, 0)   = -1 ESRCH (No such process)

I am wondering if some of the isolation used by systemd-nspawn is
causing the null output and am seeking advice to get it working if
possible.

Link to strace from the container:
https://gist.github.com/graysky2/0886025b60335de4c0b19ddf11f7aafb

Link to strace from the native system (no container):
https://gist.github.com/graysky2/ac54092625f0b67fc5c50cc5b10fc538
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [SPAM]Re: Mount units with After=autofs.service cause ordering cycles

[John Florian]

On 10/31/19 2:59 PM, Lennart Poettering wrote:

On Do, 31.10.19 14:09, John Florian (jflor...@doubledog.org) wrote:


# /etc/systemd/system/var-www-pub.mount
[Unit]
Description=mount /pub served via httpd
Requires=autofs.service
After=autofs.service

[Mount]
What=/mnt/pub
Where=/var/www/pub
Options=bind,context=system_u:object_r:httpd_sys_content_t

[Install]
WantedBy=multi-user.target

~~~

The above worked for a long time, but once again a `dnf upgrade` seems to
have broken things because now I have a ordering cycle that systemd must
break.  Since I haven't changed my mount units, my ability to mesh with
those shipped by the OS proves fragile. I'm deliberately avoiding too much
detail here because it would seem that there should be a relatively simple
solution to this general sort of task -- I just can't seem to discover it.
Any recommendations that don't involve an entirely different approach?

What precisely is the ordering cycle you are seeing? It's usually
dumped along with the log message.

systemd[1]: local-fs.target: Found ordering cycle on var-www-pub.mount/start
systemd[1]: local-fs.target: Found dependency on autofs.service/start
systemd[1]: local-fs.target: Found dependency on rpc-statd.service/start
systemd[1]: local-fs.target: Found dependency on network-online.target/start
systemd[1]: local-fs.target: Found dependency on network.target/start
systemd[1]: local-fs.target: Found dependency on
NetworkManager.service/start
systemd[1]: local-fs.target: Found dependency on sysinit.target/start
systemd[1]: local-fs.target: Found dependency on
systemd-update-done.service/start
systemd[1]: local-fs.target: Found dependency on local-fs.target/start
systemd[1]: local-fs.target: Job var-www-pub.mount/start deleted to break
ordering cycle starting with local-fs.target/start

The ordering dep between local-fs.target and var-ww-pub.mount is what
you have to get rid of to remove the cycle. Set:

…
[Unit]
DefaultDependencies=no
Conflicts=umount.target
Before=umount.target
…
[Install]
WantedBy=remote-fs.target
…

i.e. make this a dep of remote-fs.target, not the implicit
local-fs.target, so that we don#t pull it in early boot, but only
during late boot, before remote-fs.target.


Thanks Lennart!  That did the trick.  I and others I know have knocked 
heads on this one several times and somehow never came to this 
conclusion.  It makes sense now that I see it, however.   Maybe 
local-fs.target should have stood out to me, but I think it was mostly 
accepted since if you follow all deps far enough, you'll eventually 
cover (most?) everything.


I think this just means I need to use `systemctl show` more even though 
`systemctl cat` is so much easier to digest for what I think I need to 
know.  Abstracting the default deps is both good in expression but also 
difficult in comprehension.  I wish there was something "in between", 
but I don't even know how to define what that means.  Maybe just 
grouping all the settings from `show` somehow, e.g.: ordering, deps, 
etc. or maybe by unit type: unit, exec, mount, etc.


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

Re: [systemd-devel] [SPAM]Re: Mount units with After=autofs.service cause ordering cycles

[John Florian]

On 10/31/19 1:08 PM, Lennart Poettering wrote:

On Mo, 14.10.19 16:23, John Florian (j...@doubledog.org) wrote:


So, I much prefer the expressiveness of systemd's mount units to the naive
era of /etc/fstab, but I've found one situation where I seem to always get
stuck and am never able to find a reliable solution that survives OS (Fedora
& CentOS) updates.  I have a NFS filesystem mounted by autofs at /pub that
needs to be bind mounted in various places such as /var/www/pub and
/var/ftp/pub. So I create a unit that looks like:

~~~

# /etc/systemd/system/var-www-pub.mount
[Unit]
Description=mount /pub served via httpd
Requires=autofs.service
After=autofs.service

[Mount]
What=/mnt/pub
Where=/var/www/pub
Options=bind,context=system_u:object_r:httpd_sys_content_t

[Install]
WantedBy=multi-user.target

~~~

The above worked for a long time, but once again a `dnf upgrade` seems to
have broken things because now I have a ordering cycle that systemd must
break.  Since I haven't changed my mount units, my ability to mesh with
those shipped by the OS proves fragile. I'm deliberately avoiding too much
detail here because it would seem that there should be a relatively simple
solution to this general sort of task -- I just can't seem to discover it.
Any recommendations that don't involve an entirely different approach?

What precisely is the ordering cycle you are seeing? It's usually
dumped along with the log message.


systemd[1]: local-fs.target: Found ordering cycle on var-www-pub.mount/start
systemd[1]: local-fs.target: Found dependency on autofs.service/start
systemd[1]: local-fs.target: Found dependency on rpc-statd.service/start
systemd[1]: local-fs.target: Found dependency on network-online.target/start
systemd[1]: local-fs.target: Found dependency on network.target/start
systemd[1]: local-fs.target: Found dependency on 
NetworkManager.service/start

systemd[1]: local-fs.target: Found dependency on sysinit.target/start
systemd[1]: local-fs.target: Found dependency on 
systemd-update-done.service/start

systemd[1]: local-fs.target: Found dependency on local-fs.target/start
systemd[1]: local-fs.target: Job var-www-pub.mount/start deleted to 
break ordering cycle starting with local-fs.target/start


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

[systemd-devel] Mount units with After=autofs.service cause ordering cycles

[John Florian]

So, I much prefer the expressiveness of systemd's mount units to the 
naive era of /etc/fstab, but I've found one situation where I seem to 
always get stuck and am never able to find a reliable solution that 
survives OS (Fedora & CentOS) updates.  I have a NFS filesystem mounted 
by autofs at /pub that needs to be bind mounted in various places such 
as /var/www/pub and /var/ftp/pub. So I create a unit that looks like:


~~~

# /etc/systemd/system/var-www-pub.mount
[Unit]
Description=mount /pub served via httpd
Requires=autofs.service
After=autofs.service

[Mount]
What=/mnt/pub
Where=/var/www/pub
Options=bind,context=system_u:object_r:httpd_sys_content_t

[Install]
WantedBy=multi-user.target

~~~

The above worked for a long time, but once again a `dnf upgrade` seems 
to have broken things because now I have a ordering cycle that systemd 
must break.  Since I haven't changed my mount units, my ability to mesh 
with those shipped by the OS proves fragile. I'm deliberately avoiding 
too much detail here because it would seem that there should be a 
relatively simple solution to this general sort of task -- I just can't 
seem to discover it.  Any recommendations that don't involve an entirely 
different approach?


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

Re: [systemd-devel] RFC: luksSuspend support in sleep/sleep.c

[Dimitri John Ledkov]

On Thu, 10 Oct 2019 at 16:49, Mantas Mikulėnas  wrote:
>
> On Thu, Oct 10, 2019 at 6:23 PM Jonas Meurer  wrote:
>>
>> Hi Lennart, hi Tim,
>>
>> thanks a lot for your feedback, Lennart. It's much appreciated!
>>
>> Tim Dittler:
>> > On 09.10.19 19:26, Lennart Poettering wrote:
>> >> On Mi, 09.10.19 12:20, Jonas Meurer (jo...@freesources.org) wrote:
>> >>> We[1] are working on bringing luksSuspend for LUKS devices before system
>> >>> suspend to Debian. The basic idea is to remove the encryption keys of
>> >>> encrypted devices from RAM before suspending the system.
>> >>>
>> >>> While working on it, we figured out that systemd probably is the best
>> >>> place to implement this. Would you be willed to accept related patches
>> >>> into systemd? We're still early in the design process, but probably the
>> >>> relevant parts will be:
>> >>>
>> >>> [...]
>> >>>
>> >>> Lennart's talk[2] about systemd-homed mentions luksSuspend support for
>> >>> system suspend, but it's limited to home directories. The whole ramfs
>> >>> foo wouldn't be necessary to do that. So a direct question: would you
>> >>> still be ok with support for luksSuspending the encrypted root
>> >>> filesystem in systemd?
>> >>>
>> >>> Before spending days of work on implementing this in systemd only to get
>> >>> the patches rejected in the end, we thought it would be better to ask
>> >>> beforehands ;)
>> >>
>> >> The thing is, this is far from easy to implement, to the point I don't
>> >> think it's viable in the long run at all. I mean, in order to be able
>> >> to unlock the root disk after suspend you need the full input and
>> >> display stack to be up, i.e. wayland/x11/gnome in the general
>> >> case. And that's an awful lot to place in a ramdisk. You will end up
>> >> having another copy of the OS as a whole in there in the end...
>> >>
>> >> systemd-homed maintains only the home directory via LUKS encryption,
>> >> and leaves the OS itself unencrypted (under the assumption it's
>> >> protected differently, for example via verity – if immutable —  or via
>> >> encryption bound to the TPM), and uses the passphrase only for
>> >> home. THis means the whole UI stack to prompt the user is around
>> >> without problems, and the problem gets much much easier.
>> >>
>> >> So what's your story on the UI stack? Do you intend to actually copy
>> >> the full UI stack into the ramdisk? If not, what do you intend to do
>> >> instead?
>>
>> As Tim already wrote, the UI stack was not our focus so far. But I
>> agree, that it's a valid concern. My silent hope was to find a solution
>> for a simple passwort prompt that can be overlayed over whatever
>> graphical stack is running on the system. But we haven't looked into it
>> yet, so it might well be impossible to do something like this.
>>
>> But since the graphical interface is running already, I doubt that we
>> would have to copy the whole stack into the ramfs. We certainly need to
>> take care of all *new* dependencies that a password prompt application
>> pulls in, but the wayland/x11/gnome basics should just be there, as they
>> have been in use just before the suspend started, no?
>

Well, one can do what Mac OS X used to do. Take a screenshot, apply
blur, use as a background in a graphical plymouth to type unlock
password and slowly fade in as things are unfrozen.

Most desktop systems, already might include graphical plymouth already
(and like framebuffer / dri modules needed for it, among with
cryptsetup tooling but maybe not TPM one). Such that it should be
possible to "just use the initrd" one uses for boot anyway.

>
> They might not be 100% available from just memory. What happens if the DE 
> needs to load assets (fonts, .ui files) for the passphrase prompt from disk? 
> (Actually, do any GPU drivers need to load firmware from /lib on resume?)
>

In Ubuntu, casper component, we work around it by reading the files to
ensure they are in the fscache, and then if one force unmounts the
filesystem underneath them (cdrom eject) plymouth can still "read"
fonts and display late boot messages. So there are ways of doing this.

-- 
Regards,

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

[systemd-devel] /cdrom mounted from initrd is stopped on boot, possibly confused about device-bound

[Dimitri John Ledkov]

Ubuntu installer images use initrd, which has udevd but no systemd.

It mounts /dev/sr0 as /root/cdrom, then pivots to /root, meaning
/root/cdrom becomes just /cdrom and exec systemd as pid 1.

At this point cdrom.mount is stopped as it's bound to an inactive
dev-sr0.device. Then sometime later dev-sr0.device becomes active, but
nothing remounts /cdrom back in.

My question is why on startup, when processing cdrom.mount it
determines that dev-sr0 is inactive, when clearly it's fully
operational (it contains media, media is locked, and is mounted, and
is serving content).

I notice that SYSTEMD_MOUNT_DEVICE_BOUND is set to 1 on the udev
device, and it seems impossible to undo via mount unit.

I also wonder why, initially, /dev/sr0 is inactive, but later becomes
active - as in what causes it to become active, and what is missing in
the initrd.

Things appear to work if I specify in the 60-cdrom_id.rules
SYSTEMD_READY=1, then on boot there are no working messages that
cdrom.mount is bound to an inactive device.

Shouldn't 60-cdrom_id.rules set SYSTEMD_READY=1 if after importing
cdrom_id variables ID_CROM_MEDIA is not-empty? Such that
dev-sr0.device initial state is correct, if one booted with cdrom
media in place.

-- 
Regards,

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

[systemd-devel] Delegate v1 cgroup controller permissions

[John Lane]

I have a service which runs as an unprivileged user (User=foo) with
delegated cgroup (Delegate=true) that wants to use the "memory" and
"cpu" controllers. Systemd is using the hybrid mode with both v1 and v2
cgroups, and the controllers are assigned to the v1 groups.

Before I can use the "cpu" or "memory" cgroups I have to force the
permissions of them because the delegated permissions are only applied
in the unified hierarchy.

Doing this requires root which is a problem because we don't want to
give this service root permissions.

I have read https://systemd.io/CGROUP_DELEGATION and note that the
hybrid mode "is a stopgap" and "has no future" but I am forced to use it
because the distros that we have to use (fedora) are set up that way (I
have yet to see any system use the unified v2 mode exclusively). So I'm
having to bother with hybrid mode even though I don't have enough free
time ;)

I have read in the same article that delegation "won’t pass ownership of
the legacy controller hierarchies" and "think twice before delegating
cgroup v1 controllers to less privileged containers."

I get that it isn't the preferred mechanism with systemd but we just
want to manage access to resources (cpu and memory) allocated to
subtasks from within our application.

So is there a way to tell systemd (or some other way) to set the v1
cgroup permissions so they are usable by the delegated user without
having to give the user process root privileges ?


pEpkey.asc
Description: application/pgp-keys
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Allocating resource to achieve predictable run times

[John Lane]

I am trying to meet a requirement to have predictable execution of jobs.

I'm asking here because I need to do this in a systemd environment,
specifically a Fedora 26 server but this could get upgraded to a later
version as part of any solution.  Because this is a systemd server I
would like to achieve this in a systemd-friendly way.

I am trying to define multiple "containers" for jobs where we can have,
say, 5 jobs per cpu and expect a job's time to complete to be the same
whether one or many are run. The system may be able to allocate 32+ cpus
to such containers (e.g. 5*32 = 160 container capacity).

When I say "container" I mean "an environment with reserved resources".
I have been looking at using cgroups both directly and via systemd.

In a simplistic example, a process that takes n seconds to run without
restriction should take 5n seconds to run on a 20% cpu share regardless
of the load on the remainder of the system. That a job takes longer to
run isn't important; that it always takes the same time is: the job's
execution time must be predictable.

I have a "dispatcher" that launches jobs. It is a systemd service that
has "Delegate=True", "CPUAffinity" set to the processors the job may
run on and "CPUQuota" or directly setting "cpu.cfs_quota_us" to limit
them to 20% of a cpu.

Observations with a simple single-threaded test on one cpu:

* a single job takes 15 seconds when run on an otherwise idle system
with no other restrictions.

* a single job takes 35 seconds when run on a system otherwise running
at 100% cpu.

* 5 jobs run on one cpu (each job 20% of the cpu) with the rest of the
system idle takes (roughly) 75 seconds - five times the duration of one
unresticted job on the same idle system.

* 5 jobs run on one cpu (each job 20% of the cpu) with the rest of the
system busy takes (roughly) 175 seconds - five times the duration of one
unresticted job on the same busy system.

* runing one job on 20% of one CPU with the rest of the system idle
takes much longer (more than 270 seconds) than the duration when running
five jobs (this really does not make sense).

I have also tried "cpuset.cpus" - the dispatcher creates the cgroups
that systemd does not. I've tried using "taskset", "numactl",
"isolcpus", systemd settings and cgroup settings but I cannot get
predictable results: that 1 job or n jobs take the same amount of time.

Having read all the documentation that I can find, I'm not sure what
else to try...

Are there other provisions (in systemd, cgroups, or other) that can I
use to make a job always take (more-or-less) the same amount of time ?

Thanks and much appreciated.


(p.s. I initially wrote a much longer message but it was a bit too TL;DR
so this is the short(er) version. I can provide more detail as needed).


pEpkey.asc
Description: application/pgp-keys
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] On every 'sysctl enable/disable' Systemd Reload is happening

[Dimitri John Ledkov]

On Mon, 25 Feb 2019 at 19:05, Mahesh Mylarappa  wrote:
>
> Hi,
>
> I am working on Linux host which has old 219 systemd build. We are trying to 
> create/enable/start  multiple service instances at same time. Basically we 
> create 15 to 20 unit files in /etc/systemd/system directory and call 
> 'systemctl enable' on each one of them. There is only 30 to 50ms gap between 
> each enable commands and  i could see few of those taking 10s of seconds to 
> complete. If i put log level to debug, i could see that every time a new 
> 'sysctl enable' is fired for new service instance,  there is complete reload 
> happening and queued jobs are cancelled and reissued.
>
> I understand build 219 is very old, but wanted to know if there was a similar 
> issue which was fixed in later builds.
>

What you seem to be looking for is to execute enable command
"client-side" without communicating with systemd, to check if the
units exist and are valid, and simply operate on the [Install] stanzas
requirements on the filesystem alone.

There are a number of checks that are done to switch to client side,
please see 
https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl.c#L296

I don't know how old those are, but please try

1) systemctl --root=/ enable ...
2) SYSTEMCTL_INSTALL_CLIENT_SIDE=1 systemctl enable ...

I think --root=/ should be supported to switch to client-side/chroot
install mode even in 219. I have never used the undocumented
environmental variable, but maybe it is easier to use that for you, if
it works in v219.

-- 
Regards,

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

Re: [systemd-devel] GithHub / private repos

[Dimitri John Ledkov]

On Sat, 26 Jan 2019 at 12:43, Lennart Poettering  wrote:
>
> On Di, 15.01.19 21:21, Alex Dzyoba (a...@dzyoba.com) wrote:
>
> > When you create a new organization you can choose "Team For Open
> > Source" plan. Here is the link
> > https://github.com/account/organizations/new
> >
> > Though, I don't know if it's possible to upgrade the existing systemd
> > organization, sorry. Maybe it's possible to contact github support to
> > ask for this.
>
> So I had a closer look at this, and found this:
>
> https://help.github.com/articles/github-s-products/
>
> IIUC "GitHub Team for Open Source" doesn't actually add anything we
> need. Because what we need would actually be the ability for arbitrary
> people (i.e. not people who necessarily are members of our systemd
> team on github) to send us private PRs and issues in order to handle
> security issues.
>
> It appears to me that plan does not provide the core need we have:
> allow those random folks from the Internet to report security issues
> in privacy to us... Or what am I missing?
>

It doesn't seem to be exactly that.

Reading help, I guess one can create a secret issues-only repository
https://help.github.com/articles/creating-an-issues-only-repository/
The permissions look almost ok, but I fear that everyone will be able
to see all the issues. Whilst we would want to restrict issues to be
visible only by "author + write/admins". Ditto pull requests.

I guess we could create a private repository per issue. but that
will get messy quickly, although I would expect each one to be
short-lived for each individual CVE.

-- 
Regards,

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

Re: [systemd-devel] How to debug occasional hashmap corruption?

[John Reiser]

On 11/6/18 9:57 UTC, juice wrote:


During the past half year I have seen systemd dump core three times due
to what I suspect a hashmap corruption or race.
Each time it looks a bit different and is triggered by different things
but it somehow centers on hashmap operations.


Three intermittent hardware failures in one year on 10,000 boxes is normal.
Keep good records.  If the same box appears twice, then physically destroy it.

Meanwhile, log all events to a circular buffer that just keeps rotating:
date+time (32 bits, 1 microsecond precision), caller (return address),
argument summary (fixed format: string prefixes or hash).  Analyze the dump.

Lock each hashmap operation to insure single-threaded operation,t;
prevent even multiple [supposedly] read-only access.
Lock each signal handler: only one instance of a given signal at a time.

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

[systemd-devel] How to start a unit right after another unit terminates?

[John Ioannidis]

Assume I have a one-shot service, *phase1.service*, which runs for a while
and then terminates. I want to have a *phase2.service* start up when phase1
terminates.

I cannot change anything in phase1.service's systemd files or code or
anything, or I would not be asking this question!

A dirty workaround is to just have phase2 start before phase1 and run this
script (wait until phase1 starts up, then wait until it finishes, then do
its thing):

while ! systemctl status phase1.service > /dev/null
do
  sleep 10 # still waiting for phase1 to start up
done
while systemctl status phase1.service > /dev/null
do
  sleep 10 # still waiting for phase1 to finish
done
# now do the phase2 work

There has to be a better way of doing this, but I can't figure it out.
Google/Bing/SO searches return lots of other workarounds, mostly for user
sessions, which is not the case here.

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

[systemd-devel] trying to hook into the luks crypt function in initramfs

[Ratliff, John]

I'd like to be able to unlock my luks encrypted drive (lvm - including the root 
partition) with a USB key, but if the USB key is not present, still ask for a 
passphrase.

I'm not clear on how systemd does the unlock during boot, but it seems that 
Fedora 28 and CentOS/RHEL 7 both use systemd for this task. Where would I look 
to change the behavior to do what I'm looking for?

In Debian/Ubuntu, there is a keyscript file that gets put into the initramfs, 
but I don't think theirs is systemd based. Arch has a similar method with a 
hook, but I've only used it with the non-systemd initramfs. Fedora has a crypt 
module, but I have to disable systemd or it won't work. I'm not sure what 
systemd is doing in the initramfs, so I'm not sure if I want to disable that 
module or not. I'm hoping there's a better way to interact with systemd.

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

Re: [systemd-devel] How to set `InitRDTimestampMonotonic` from console?

[Dimitri John Ledkov]

Hi,

On 4 July 2018 at 10:22, Lennart Poettering  wrote:
> On Mi, 04.07.18 07:24, Paul Menzel (pmenzel+systemd-de...@molgen.mpg.de) 
> wrote:
>
>> Dear systemd folks,
>>
>>
>> Debian uses a shell script as `/init` in initrd, and I like to extend that,
>> to set the time stamps for the initrd execution.
>
> This is part of the data that is serialized during the transition from
> the systemd instance in the initrd to the systemd instance on the
> host. The serialization is internal to systemd, and this is unlikely
> to change, as it contains numerous bits of information that are
> fragile and sensitive as the serialization really contains the full
> service manager state with all its units and so on.
>
>> Is it possible to set that value from a shell script? If yes, could you
>> please tell me how?
>
> It's not, and quite frankly I am not enthusiastic about the idea to
> make this configurable...

At one point, I was considering to serialize just enough data to add
these in the initramfs-tools (and/or systemd) as Debian specific
patches to start supporting these measurements.
And have a distro patch in systemd to read these measurements from a
separately serialized file on boot-up.

Also, there are bootloader measurements, that I think we do not
receive either from grub.

-- 
Regards,

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

Re: [systemd-devel] [Install] section of symlinked unit file ignored if drop-in file is used

[John Gallagher]

I'm using v237, so that makes sense. Thanks for looking into this!

-John

On Sun, May 27, 2018 at 6:50 AM, 林自均  wrote:
> Hi John,
>
> I can reproduced your problem on systemd v236 to v238, but not v235. I think
> it's because from v236 to v238 contains the commit in
> https://github.com/systemd/systemd/pull/7158. However, it seems that the
> commit "d04a93864d" in the git repo fixes the issue. Therefore, you can
> expect that the next systemd version (v239) won't have the issue then.
>
> John Lin
>
> 林自均  於 2018年5月23日 週三 下午10:32寫道：
>>
>> Hi John,
>>
>> I'm not sure whether this issue is because of
>> https://github.com/systemd/systemd/pull/7158 or not. I will figure it out.
>> Thanks.
>>
>> John Lin
>>
>> John Gallagher  於 2018年5月24日 週四 上午8:07寫道：
>>>
>>> If I have a unit file for a service that lives off the unit file
>>> search path, I can link it, and then enable it using the service name
>>> instead of the full path of the unit file:
>>>
>>> $ cat foo.service
>>> [Service]
>>> Type=simple
>>> ExecStart=/bin/sleep 1
>>>
>>> [Install]
>>> WantedBy=multi-user.target
>>> $ sudo systemctl link ~/foo.service
>>> Created symlink /etc/systemd/system/foo.service →
>>> /export/home/delphix/foo.service.
>>> $ sudo systemctl enable foo
>>> Created symlink
>>> /etc/systemd/system/multi-user.target.wants/foo.service →
>>> /export/home/delphix/foo.service.
>>>
>>> If I add a drop-in file for the service though, enabling the service
>>> using the service name does not behave the same way:
>>>
>>> $ cat /etc/systemd/system/foo.service.d/env.conf
>>> [Service]
>>> Environment=FOO=bar
>>> $ sudo systemctl enable foo
>>> The unit files have no installation config (WantedBy, RequiredBy, Also,
>>> Alias
>>> settings in the [Install] section, and DefaultInstance for template
>>> units).
>>> This means they are not meant to be enabled using systemctl.
>>> Possible reasons for having this kind of units are:
>>> 1) A unit may be statically enabled by being symlinked from another
>>> unit's
>>>.wants/ or .requires/ directory.
>>> 2) A unit's purpose may be to act as a helper for some other unit which
>>> has
>>>a requirement dependency on it.
>>> 3) A unit may be started when needed via activation (socket, path, timer,
>>>D-Bus, udev, scripted systemctl call, ...).
>>> 4) In case of template units, the unit is meant to be enabled with some
>>>instance name specified.
>>>
>>> I get the warning above, and the expected link in
>>> /etc/systemd/system/multi-user.target.wants/ is not created. I can
>>> work around this behavior by doing the enable using the path of the
>>> unit file:
>>>
>>> $ sudo systemctl enable ~/foo.service
>>> Created symlink
>>> /etc/systemd/system/multi-user.target.wants/foo.service →
>>> /export/home/delphix/foo.service.
>>>
>>> The [Install] section of the unit file being ignored or respected
>>> based on the presence or absence of a drop-in file seems inconsistent
>>> to me, but I am fairly new to systemd, so I may be missing something.
>>> Is this behavior expected?
>>>
>>> Thanks,
>>> John
>>> ___
>>> 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

[systemd-devel] [Install] section of symlinked unit file ignored if drop-in file is used

[John Gallagher]

If I have a unit file for a service that lives off the unit file
search path, I can link it, and then enable it using the service name
instead of the full path of the unit file:

$ cat foo.service
[Service]
Type=simple
ExecStart=/bin/sleep 1

[Install]
WantedBy=multi-user.target
$ sudo systemctl link ~/foo.service
Created symlink /etc/systemd/system/foo.service →
/export/home/delphix/foo.service.
$ sudo systemctl enable foo
Created symlink
/etc/systemd/system/multi-user.target.wants/foo.service →
/export/home/delphix/foo.service.

If I add a drop-in file for the service though, enabling the service
using the service name does not behave the same way:

$ cat /etc/systemd/system/foo.service.d/env.conf
[Service]
Environment=FOO=bar
$ sudo systemctl enable foo
The unit files have no installation config (WantedBy, RequiredBy, Also, Alias
settings in the [Install] section, and DefaultInstance for template units).
This means they are not meant to be enabled using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
   .wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
   a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
   D-Bus, udev, scripted systemctl call, ...).
4) In case of template units, the unit is meant to be enabled with some
   instance name specified.

I get the warning above, and the expected link in
/etc/systemd/system/multi-user.target.wants/ is not created. I can
work around this behavior by doing the enable using the path of the
unit file:

$ sudo systemctl enable ~/foo.service
Created symlink
/etc/systemd/system/multi-user.target.wants/foo.service →
/export/home/delphix/foo.service.

The [Install] section of the unit file being ignored or respected
based on the presence or absence of a drop-in file seems inconsistent
to me, but I am fairly new to systemd, so I may be missing something.
Is this behavior expected?

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

Re: [systemd-devel] logging to a fifo pipe

[John Reiser]

I need to log to the journal with custom tags from a service that only
supports logging to syslog without any customization or logging to a
file.


On Linux if you know the ProcessID then use "/proc/$PID/fd/2" .

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

Re: [systemd-devel] how to make systemd ignore the memory cgroup controller and hierarchy

[john terragon]

 
  On Wednesday, May 9, 2018, 10:02:14 PM GMT+2, Simon McVittie 
 wrote: 

>I don't think this is supported. systemd behaves as though cgroups v2 is
>in use (single unified cgroup hierarchy) even if you are currently using
>cgroups v1 (one parallel hierarchy per controller).


According to this

https://github.com/systemd/systemd/issues/7624
they seemed to agree to change the behavior of DefaultMemoryAccounting so that, 
if set to "never", systemd should leave the memory controller alone. Did they 
implement it?

For my desktop (or laptop) system I need to implement this simple memory 
resource management:
1) there are two cgroups for the memory controller (globally): swappable, 
nonswappable.
2) in swappable, I have memory.swappiness=100
3) in nonswappable I have memory.swappiness=0 and the oom killer disabled
4) I use cgsendrules to classify 
 a) all the swappables (e.g. firefox) with specific rules
 b) all the unswappables with a last catch-all rule.

I don't know if anyone else has experienced this but in a normal desktop 
setting even with a decent amount of RAM, when the kernel starts to hit the 
swap it's going to try to swap pages from all the wrong processes, as far as 
desktop usage goes, like X, all the pieces of kde etc. Everything starts 
stuttering for seconds at a time in the best scenario and for minutes in the 
worst one (and with an SSD!). 
I've tested the simple scheme above and it completely solves all my issues, the 
memory hogs get their pages swapped and the rest of the processes stay in 
memory and everything is smooth as butter.

If this scheme could be implemented with systemd I'd be fine using it also for 
the memory controller. But otherwise I need to
implement it myself. But, as I said, sometimes systemd seems to move processes 
from my memory cgroups. 

John

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

[systemd-devel] how to make systemd ignore the memory cgroup controller and hierarchy

[john terragon]

Hi.

I have the memory cgroup controller configured in the kernel. I want to use it 
myself directly without interference from systemd. I tried setting 
DefaultMemoryAccounting=no in system.conf but systemd seems to still interfere 
with the hierarchy for the memory controller (e.g. systemctl daemon-reload for 
some reason removes all tasks from my subgroups in the memory hierarchy). Since 
none of the cgroup controllers are strictly needed by systemd (only the basic 
cgroup infrastructure in the kernel is neede. The single controllers could be 
disabled, if I'm not mistaken.) how do I get systemd to leave the memory 
controller and relative hierarchy alone?

Thanks

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

Re: [systemd-devel] `Found ordering cycle on _SERVICE_` loops due to `local-fs.target` with `Requires` instead of `Wants` for mounts generated from `/etc/fstab`

[John Florian]

On 2018-04-27 03:56, Jérémy Rosen wrote:

Ok, there are a couple of tools that have not be mentionned..

"systemd-analyze verify " will check all sorts of stuff on a 
service, including checking recursively the deps and finding ordering 
cycles



systemctl list-dependencies can show ordering/req dependencies, up or 
down, recursively or not


to be completely honest, I never use dot for cycles I sometime 
read/grep the .dot file itself, but I never generate the image...


systemd-analyze is my favorite tool for that sort of problems

On 27/04/2018 06:01, Andrei Borzenkov wrote:

Well, you could use "systemctl show -p Id -p After -p Before" but the
problem is to find the correct unit set. You really need something that
simulates transaction and evaluates dependencies like systemd does it.

Note that systemd should print offending cycle when it hits it:

апр 27 06:54:14 bor-Latitude-E5450 systemd[1582]: foo.service: Found
ordering cycle on foo.service/start
апр 27 06:54:14 bor-Latitude-E5450 systemd[1582]: foo.service: Found
dependency on bar.service/start
апр 27 06:54:14 bor-Latitude-E5450 systemd[1582]: foo.service: Found
dependency on baz.service/start
апр 27 06:54:14 bor-Latitude-E5450 systemd[1582]: foo.service: Found
dependency on foo.service/start
апр 27 06:54:14 bor-Latitude-E5450 systemd[1582]: foo.service: Breaking
ordering cycle by deleting job baz.service/start


Well these are good things to know.  I can't recall if I ever tried to 
use them when faced with a loop.  I'd guess that I tried 
`systemd-analyze verify` as it sort of jumps off the man page whereas 
`systemctl list-dependencies` is kind of buried in the details.



It would be helpful it if additionally printed kind of dependency (like
foo.service is After bar.service) because this is by far not obvious for
average user.


Maybe one really helpful immediate change would be to have systemd log 
some hints when it breaks a loop to suggest a few commands that might be 
run to help understand the situation more clearly.

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

Re: [systemd-devel] `Found ordering cycle on _SERVICE_` loops due to `local-fs.target` with `Requires` instead of `Wants` for mounts generated from `/etc/fstab`

[John Florian]

On 2018-04-26 16:04, John Florian wrote:

On 2018-04-25 04:53, Lennart Poettering wrote:

There have been requests in improving the cycle breaking algorithm,
but not much has been done in this area, since it's not clear what can
be done. Ultimately it's just polishing a broken situation, and
the better way out is to fix things properly, i.e. just correct the
cycle in the dependencies in the first place.


Having been the author of numerous custom services that are intended 
to wedge into those provided by systemd/Fedora I've faced resolving 
these several times and I've never felt all that competent at the 
task.  Lennart, you were immensely helpful on one occasion by pointing 
me to `systemctl show FOO` but even then hunting the problem down was 
far from simple (for me).  I've done the dot/graphviz thing and found 
it just as useless to me as when I've tried applying it to Puppet's 
ordering/dependency looping. I'm not blaming those tools (or systemd) 
because I'm well aware much of the problem is my inability to use them 
effectively.  The graphs always seem to be overly simple and revealing 
no problem or overly detailed and obscuring the problem.  Compound 
that with "an arrow pointing this way means what exactly?"


Is there anything else that could be done to make hunting these loops 
down easier?  Is there an example of any product that has a similar 
situation where they excel at helping the developer?  Or are we 
already there and I just need more practice?  I'm sure part of my 
struggle is just not encountering these very regularly and integrating 
into much that I'm only partly familiar with, but the result is the 
same, trepidation and loathing.


Since I hate to grumble w/o so much as offering any possible 
suggestions... It seems like it might be helpful to have something like 
`systemctl show` but only dumping the properties used for ordering and 
dependencies.  Ideally, only ordering OR dependencies as the case 
warrants and for all units involved, but only those units.

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

Re: [systemd-devel] `Found ordering cycle on _SERVICE_` loops due to `local-fs.target` with `Requires` instead of `Wants` for mounts generated from `/etc/fstab`

[John Florian]

On 2018-04-25 04:53, Lennart Poettering wrote:

There have been requests in improving the cycle breaking algorithm,
but not much has been done in this area, since it's not clear what can
be done. Ultimately it's just polishing a broken situation, and
the better way out is to fix things properly, i.e. just correct the
cycle in the dependencies in the first place.


Having been the author of numerous custom services that are intended to 
wedge into those provided by systemd/Fedora I've faced resolving these 
several times and I've never felt all that competent at the task.  
Lennart, you were immensely helpful on one occasion by pointing me to 
`systemctl show FOO` but even then hunting the problem down was far from 
simple (for me).  I've done the dot/graphviz thing and found it just as 
useless to me as when I've tried applying it to Puppet's 
ordering/dependency looping.  I'm not blaming those tools (or systemd) 
because I'm well aware much of the problem is my inability to use them 
effectively.  The graphs always seem to be overly simple and revealing 
no problem or overly detailed and obscuring the problem.  Compound that 
with "an arrow pointing this way means what exactly?"


Is there anything else that could be done to make hunting these loops 
down easier?  Is there an example of any product that has a similar 
situation where they excel at helping the developer?  Or are we already 
there and I just need more practice?  I'm sure part of my struggle is 
just not encountering these very regularly and integrating into much 
that I'm only partly familiar with, but the result is the same, 
trepidation and loathing.

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

Re: [systemd-devel] Changed ordering of systemd-resolved.service

[Dimitri John Ledkov]

On 16 April 2018 at 18:20, Paul Menzel
 wrote:
> Dear Dimitri,
>
>
> On 04/16/18 18:51, Dimitri John Ledkov wrote:
>
>> On 16 April 2018 at 14:25, Paul Menzel wrote:
>
>
>>> On 04/16/18 12:47, Dimitri John Ledkov wrote:
>>>>
>>>>
>>>> On 13 April 2018 at 16:40, Paul Menzel wrote:
>>>
>>>
>>>>> In commit 1f158013 (resolved.service: set DefaultDependencies=no) the
>>>>> ordering of systemd-resolved.service was changed. (How do I find the
>>>>> merge
>>>>> request to find possible discussion? Also the commit message
>>>>> description
>>>>> is
>>>>> too specific in my opinion, as it doesn’t give a clue that more is
>>>>> changed.)
>>>>
>>>>
>>>>
>>>> https://github.com/systemd/systemd/pull/7609
>>>
>>>
>>> Thank you, no idea, why I didn’t find it with `git log --oneline
>>> --graph`.
>>> Hmm, looks like, Lennart directly put that commit in master without
>>> merging
>>> the pull request.
>>>
>>>>> I like starting systemd-resolved earlier, but unfortunately ordering it
>>>>> before `network.target` adds a delay on systems wanting to start as
>>>>> fast
>>>>> as
>>>>> possible. But why did you change it from `network-online.target` to
>>>>> `network.target`? I’d say `network-online.target` is more correct.
>>>>>
>>>>> For my use case of a fast system start-up, this change delays it by at
>>>>> least
>>>>> 100 ms, as now it takes longer to reach the end of the network target.
>>>>
>>>>
>>>>
>>>> cloud-init initializes networking configuration by fetching,
>>>> potentially, remote sources to customize an instance on first boot.
>>>> Specifically it may dhcp any interface, to reach a metadata source,
>>>> download the real networking configuration, reconfigure networking to
>>>> match the final networking details (all interfaces / public ip
>>>> addresses / etc), and proceed to complete networking.target and
>>>> network-online.target.
>>>>
>>>> This means that resolved is required earlier in the boot cycle. Before
>>>> networking.target.
>>>
>>>
>>>
>>> Just to be sure, you mean *network.target*, right?
>>>
>>> Thank you for specifying the requirement. I agree, that it should be
>>> started
>>> as early as possible, but I disagree with the rest.
>>>
>>>> There are things that expect network to be up in
>>>> "network-online.target", which by some is implied to mean DNS
>>>> resolution too, unfortunately.
>>>
>>>
>>>
>>> Sorry for being ignorant, but could you please be specific, what these
>>> things are. If these units have that requirement order them after
>>> `network-online.target`.
>>>
>>>>> If your systems have problems with it, they have wrong dependencies,
>>>>> don’t
>>>>> they? Also, they should probably be able to deal with the situation,
>>>>> that
>>>>> DNS does not work, as that can happen during operation.
>>>>>
>>>>> So, I’d really like to rework that ordering change.
>>>>
>>>>
>>>>
>>>> Reworking that change will break certain public cloud providers
>>>> unfortunately because of public clouds metadata providers being odd.
>>>>
>>>> Note, we cannot use dbus activation in this case as dbus-daemon is not
>>>> up yet, and systemd-resolve command line client also does not work at
>>>> this point.
>>>>
>>>> If you want to make it an optional dependency that early, maybe it
>>>> will be possible to convert systemd-resolved to be socket activated on
>>>> tcp/udp?
>>>>
>>>> Alternatively, as a system integrator, you may want to change these
>>>> dependencies in your distro, especially if you do not configure
>>>> resolved _stub resolver_ as the default provider of /etc/resolv.conf
>>>> or for example to do not use the recommended default stub-provider
>>>> over 127.0.0.53 and instead use the nss module over dbus.
>>>>
>>>> The above dependencies are correct and recommend, for the default
>>>> setup of /etc/resolv.conf pointing at the

Re: [systemd-devel] Changed ordering of systemd-resolved.service

[Dimitri John Ledkov]

On 16 April 2018 at 14:25, Paul Menzel
 wrote:
> Dear Dimitri,
>
>
> Thank you for your quick response.
>
>
> On 04/16/18 12:47, Dimitri John Ledkov wrote:
>>
>> On 13 April 2018 at 16:40, Paul Menzel wrote:
>
>
>>> In commit 1f158013 (resolved.service: set DefaultDependencies=no) the
>>> ordering of systemd-resolved.service was changed. (How do I find the
>>> merge
>>> request to find possible discussion? Also the commit message description
>>> is
>>> too specific in my opinion, as it doesn’t give a clue that more is
>>> changed.)
>>
>>
>> https://github.com/systemd/systemd/pull/7609
>
>
> Thank you, no idea, why I didn’t find it with `git log --oneline --graph`.
> Hmm, looks like, Lennart directly put that commit in master without merging
> the pull request.
>
>>> I like starting systemd-resolved earlier, but unfortunately ordering it
>>> before `network.target` adds a delay on systems wanting to start as fast
>>> as
>>> possible. But why did you change it from `network-online.target` to
>>> `network.target`? I’d say `network-online.target` is more correct.
>>>
>>> For my use case of a fast system start-up, this change delays it by at
>>> least
>>> 100 ms, as now it takes longer to reach the end of the network target.
>>
>>
>> cloud-init initializes networking configuration by fetching,
>> potentially, remote sources to customize an instance on first boot.
>> Specifically it may dhcp any interface, to reach a metadata source,
>> download the real networking configuration, reconfigure networking to
>> match the final networking details (all interfaces / public ip
>> addresses / etc), and proceed to complete networking.target and
>> network-online.target.
>>
>> This means that resolved is required earlier in the boot cycle. Before
>> networking.target.
>
>
> Just to be sure, you mean *network.target*, right?
>
> Thank you for specifying the requirement. I agree, that it should be started
> as early as possible, but I disagree with the rest.
>
>> There are things that expect network to be up in
>> "network-online.target", which by some is implied to mean DNS
>> resolution too, unfortunately.
>
>
> Sorry for being ignorant, but could you please be specific, what these
> things are. If these units have that requirement order them after
> `network-online.target`.
>
>>> If your systems have problems with it, they have wrong dependencies,
>>> don’t
>>> they? Also, they should probably be able to deal with the situation, that
>>> DNS does not work, as that can happen during operation.
>>>
>>> So, I’d really like to rework that ordering change.
>>
>>
>> Reworking that change will break certain public cloud providers
>> unfortunately because of public clouds metadata providers being odd.
>>
>> Note, we cannot use dbus activation in this case as dbus-daemon is not
>> up yet, and systemd-resolve command line client also does not work at
>> this point.
>>
>> If you want to make it an optional dependency that early, maybe it
>> will be possible to convert systemd-resolved to be socket activated on
>> tcp/udp?
>>
>> Alternatively, as a system integrator, you may want to change these
>> dependencies in your distro, especially if you do not configure
>> resolved _stub resolver_ as the default provider of /etc/resolv.conf
>> or for example to do not use the recommended default stub-provider
>> over 127.0.0.53 and instead use the nss module over dbus.
>>
>> The above dependencies are correct and recommend, for the default
>> setup of /etc/resolv.conf pointing at the stub-resolv.conf as
>> generated by resolved at runtime.
>>
>> Specifically, the dependencies as is are "too-early" if one uses the
>> last two modes of the /etc/resolv.conf handling as described in the
>> man page -
>> https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html#/etc/resolv.conf
>
>
> First, I think, the terminology of *early* leads to misunderstandings. For
> you it includes ordering with `Before=`, for me it’s just about `After=`
> statements.
>

It's actually both. Cloud-init is a cross-distribution tool, and it
injects itself at multiple points during boot. It pre-empts networking
target, is between networking & network-online, and after
network-online target.

Without this upstream change, cloud-init was not able to pre-empt
network.target, was resulting in a dependency cycle, and systems
resulted booting degraded (du

Re: [systemd-devel] Changed ordering of systemd-resolved.service

[Dimitri John Ledkov]

On 13 April 2018 at 16:40, Paul Menzel
 wrote:
> Dear Dimitri, dear systemd folks,
>
>
> In commit 1f158013 (resolved.service: set DefaultDependencies=no) the
> ordering of systemd-resolved.service was changed. (How do I find the merge
> request to find possible discussion? Also the commit message description is
> too specific in my opinion, as it doesn’t give a clue that more is changed.)
>

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

>
> I like starting systemd-resolved earlier, but unfortunately ordering it
> before `network.target` adds a delay on systems wanting to start as fast as
> possible. But why did you change it from `network-online.target` to
> `network.target`? I’d say `network-online.target` is more correct.
>
> For my use case of a fast system start-up, this change delays it by at least
> 100 ms, as now it takes longer to reach the end of the network target.
>

cloud-init initializes networking configuration by fetching,
potentionally, remote sources to customize an instance on first boot.
Specifically it may dhcp any interface, to reach a metadata source,
download the real networking configuration, reconfigure networking to
match the final networking details (all interfaces / public ip
addresses / etc), and proceed to complete netwokring.target and
network-online.target.

This means that resolved is required earlier in the boot cycle. Before
networking.target.

There are things that expect network to be up in
"network-online.target", which by some is implied to mean DNS
resolution too, unfortunately.

>
> If your systems have problems with it, they have wrong dependencies, don’t
> they? Also, they should probably be able to deal with the situation, that
> DNS does not work, as that can happen during operation.
>
> So, I’d really like to rework that ordering change.
>

Reworking that change will break certain public cloud providers
unfortunately because of public clouds metadata providers being odd.

Note, we cannot use dbus activation in this case as dbus-daemon is not
up yet, and systemd-resolve command line client also does not work at
this point.

If you want to make it an optional dependency that early, maybe it
will be possible to convert systemd-resolved to be socket activated on
tcp/udp?

Alternatively, as a system integrator, you may want to change these
dependencies in your distro, especially if you do not configure
resolved _stub resolver_ as the default provider of /etc/resolv.conf
or for example to do not use the recommended default stub-provider
over 127.0.0.53 and instead use the nss module over dbus.

The above dependencies are correct and recommend, for the default
setup of /etc/resolv.conf pointing at the stub-resolv.conf as
generated by resolved at runtime.

Specifically, the dependencies as is are "too-early" if one uses the
last two modes of the /etc/resolv.conf handling as described in the
man page - 
https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html#/etc/resolv.conf

-- 
Regards,

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

[systemd-devel] How to change XDG_RUNTIME_DIR permissions

[john terragon]

Hi.
As far as I understand the XDG_RUNTIME_DIR (in debian it's /run/user/) is 
created by the logind service.I want to make the socket of the pulseaudio 
server of one particular user available to all the others. In debian that 
socket is in $XDG_RUNTIME_DIR/pulse/. The problem is that $XDG_RUNTIME_DIR is 
created with 700 and even if I change (after it's been created) the permissions 
to 711, they are automatically changed back to 700 after few seconds (security 
feature?). Is there a  way to specify to logind (if that is indeed the service 
responsible) the permissions with which  $XDG_RUNTIME_DIR should be created?
Thanks
John.


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

Re: [systemd-devel] systemd-networkd-wait-online should know if there is anything to wait for

[Dimitri John Ledkov]

On 27 March 2018 at 10:22, Colin Guthrie  wrote:
> Dimitri John Ledkov wrote on 26/03/18 11:34:
>> Hello,
>>
>> When systemd-networkd-wait-online was originally introduced, it was
>> the only tool that correctly waited and blocked the boot, until after
>> networking is configured.
>>
>> These days, however, all/most network configurations tools ship
>> appropriate wait-online integration. E.g. there is network-manager
>> wait online service and ifupdown wait online, on Debian/Ubuntu.
>>
>> These other helpers, seem to be slightly smarter than
>> systemd-networkd-wait-online. Specifically, all other helpers exit
>> straight away, if they have no devices configured / managed. Whilst
>> systemd-networkd-wait-online, doesn't appear to know if it expects any
>> devices / can manage any devices. Ideally, if no devices are
>> configured / no devices match .network files, maybe it should exit
>> straight away? Or for example, do so if no devices are found in
>> "configuring/pending/not yet processed by udev".
>>
>> (code wise, it is to change one_ready to true by default, and only
>> continue blocking the, if there is anything pending configuration).
>>
>> I'm considering doing this by default, or for-example, doing it if
>> there are no /run/systemd/network/*.network
>> /etc/systemd/network/*.network files.
>>
>> The use cases when it matters:
>>
>> - installer ISO booted without any NICs attached
>> (or NICs require special drivers / firmware loaded etc)
>>
>> - cloud-image booted and cloud-init failed to find network-config and
>> generate networkd stanzas
>
> But how do you differentiate a device which is not present vs. one which
> is slow to appear?
>
> If the system isn't online then surely any dependant units don't need to
> be started anyway. If the system requires being online to operate
> properly then all this behaviour is correct.
>
> If you don't use systemd-networkd then you possibly don't want
> systemd-networkd-wait-online either and thus it can be happily disabled.
>
> So I don't really appreciate why this is an issue. Unless, you're trying
> to use a kind of hybrid environment (e.g. using networkd for wired
> networks (perhaps USB dongles) and NetworkManager for wifi and you'd
> want networkd-wait-online to be a no-op when the USB dongle is not there?)
>
> I guess it's possible to know if networkd is configured to not manage
> any devices *at all*, but perhaps there isn't much point in enabling the
> networkd-wait-online service at all in that case anyway?
>
> Struggling to understand the "why" question here, but could easily be
> missing something! :-)
>

The problem is inability to inject systemd-networkd-wait-online into
the initial transaction when one determines that there are interfaces
managed by networkd and thus we should wait for them to be configured.

The inverse problem is - if systemd-networkd-wait-online is enabled,
it blocks boot for way too long, even though nothing is going to
happen - it already runs post udev coldplug/settle, and we shouldn't
be sitting around awaiting for hotplug interfaces to appear (that is
fragile, and they should be marked RequiredForOnline=False)

The system, normally, when fully configured will only use networkd.
But that's upon second boot, and later. On the inital boot, it may
figure out networking information or not. Specifically currently on
Ubuntu cloud images, cloud-init injects itself before the networking
targets and discovers metadata that may (or may not) specify
networking configuration data. Due to inability to inject
systemd-networkd-wait-online as part of the initial transaction, it is
enabled by default. If networking configuration is correctly
discovered - things are awesome, systemd-networkd-wait-online blocks
boot for a short period of time, until networkd is done, and things
are awesome.

If the metadata on the other hand did not contain networking
information the boot is blocked for 120s, and there is a lot of
console spew "Awaiting networking to be configured" stuff (which looks
horible on serial consoles) and one is prevented from continuing the
rest of the boot process / getting to the console for the sysadmin to
interactive configure the networking.

Hence I was thinking for systemd-networkd-wait-online to bail out
quicker, e.g. http://paste.ubuntu.com/p/gRBgfzGvSW/ (or see attached)
which quits the loop if there are no links managed by networkd, after
all links finished processing by udev/networkd, and none ended up
being managed by networkd & thus none are awaiting to move from
configured -> (failed, routable/degraded)

However, discussing this mo

[systemd-devel] systemd-networkd-wait-online should know if there is anything to wait for

[Dimitri John Ledkov]

Hello,

When systemd-networkd-wait-online was originally introduced, it was
the only tool that correctly waited and blocked the boot, until after
networking is configured.

These days, however, all/most network configurations tools ship
appropriate wait-online integration. E.g. there is network-manager
wait online service and ifupdown wait online, on Debian/Ubuntu.

These other helpers, seem to be slightly smarter than
systemd-networkd-wait-online. Specifically, all other helpers exit
straight away, if they have no devices configured / managed. Whilst
systemd-networkd-wait-online, doesn't appear to know if it expects any
devices / can manage any devices. Ideally, if no devices are
configured / no devices match .network files, maybe it should exit
straight away? Or for example, do so if no devices are found in
"configuring/pending/not yet processed by udev".

(code wise, it is to change one_ready to true by default, and only
continue blocking the, if there is anything pending configuration).

I'm considering doing this by default, or for-example, doing it if
there are no /run/systemd/network/*.network
/etc/systemd/network/*.network files.

The use cases when it matters:

- installer ISO booted without any NICs attached
(or NICs require special drivers / firmware loaded etc)

- cloud-image booted and cloud-init failed to find network-config and
generate networkd stanzas

-- 
Regards,

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

Re: [systemd-devel] About supporting relative values (e.g. 50%) in configuration

[John Florian]

On 2018-03-09 03:13, Zbigniew Jędrzejewski-Szmek wrote:

On Thu, Mar 08, 2018 at 03:48:54PM +0800, ChenQi wrote:

Hi All,

I'd like to know if systemd community thinks that adding support for
relative values in configuration is a good idea.

I found a related patch and discussion in 
https://lists.freedesktop.org/archives/systemd-devel/2015-May/032191.html.

Quoting from the comments:
"""

I'd always keep our basic structures as generic as possible, and as
close to the way CPUs work. Hence: store things as fixed-point
32bit/32bit internally, but make it configurable in percent as
user-pointing UI.

"""

According to the comments, it seems that adding such support is acceptable?

I' sending out this email because I want to check with the community
before I start to investigate more.

Hi,

yes, a patch to allow relative values would be very much welcome.


Indeed, very much!  Please see my bug[0] for some history on this.

[0] https://bugzilla.redhat.com/show_bug.cgi?id=874631
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How do I create/destroy instances dynamically when config files appear/disappear?

[John Ioannidis]

On Tue, Mar 20, 2018 at 8:47 AM, Andrei Borzenkov 
wrote:

> On Tue, Mar 20, 2018 at 12:52 AM, John Ioannidis 
> wrote:
>
>
> > I can get them to start the first time, but they do not stop when
> > configuration files change. If I systemctl daemon-reload, the links in
> > /run/systemd/system-generators get properly adjusted,
>
> generators are simply not the right tool for dynamic changes. There
> are path units for activating units when files appear but there are no
> corresponding mechanism to stop them.
>
>
>
Interesting... I didn't realize this. How about this as a workaround:

* letters-watcher.path watches /var/letters for any changes, and starts
(oneshot) letters-watcher.service

* letters-watcher.service scans the configuration file, determines what
instances it should kill and what it should create, and does so, either by
invoking systemctl or by talking to DBUS.

(I did a quick-and-dirty POC and it works, I'm wondering if this is the
right way, for some value of "right")

What I forgot to mention is that the files in the configuration directory
(/var/letters in the example) get pushed with sftp from a central location,
they are not created locally. What I'm trying to avoid is to replicate
existing systemd functionality, plus I'm looking at this as an opportunity
to learn more about systemd (greybeard and old-time systems engineer here,
but never too old to learn new stuff :) )

Many thanks,

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

[systemd-devel] RFE: diagnose when selinux context is not init_t

[John Reiser]

Hi,

If systemd is running as the init process on a system that uses selinux,
then mysterious bad things are likely to happen if the selinux context
is not init_t.  For instance:
   https://bugzilla.redhat.com/show_bug.cgi?id=1520580#c13

So, I'd like to see systemd diagnose this situation.  Please comment,
and give a hint about where and how to implement such an enhancement.

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

Re: [systemd-devel] How do I create/destroy instances dynamically when config files appear/disappear?

[John Ioannidis]

On Mon, Mar 19, 2018 at 5:52 PM, John Ioannidis 
wrote:

> I want to have a service with several instances, each of which has a
> configuration file; when configuration files appear and disappear, I want
> the corresponding instances to be created and started, and die,
> respectively, and in particular have the running processes corresponding to
> the removed units be killed.
>
> I can get them to start the first time, but they do not stop when
> configuration files change. If I systemctl daemon-reload, the links in
> /run/systemd/system-generators get properly adjusted, but I cannot figure
> out how to tell my service to kill the no-longer-needed processes. If I
> also systemctl reload the service, all existing processes are killed,
> which is absolutely not what I want.
>
> Here is what I've done: what am I doing wrong?
>
> I tried modelling this after what OpenVPN does:
>
> # *cat /etc/systemd/system/letters.service*
> [Unit]
> Description=Letters service
> After=network.target
>
> [Service]
> Type=oneshot
> RemainAfterExit=yes
> ExecStart=/bin/true
> ExecReload=/bin/true
> WorkingDirectory=/var/tmp/letters
>
> [Install]
> WantedBy=multi-user.target
>
> # *cat /etc/systemd/system/letters@.service*
> [Unit]
> Description=Letters for %i
> PartOf=letters.service
> ReloadPropagatedFrom=letters.service
> Before=systemd-user-sessions.service
> After=syslog.target network-online.target
> Wants=network-online.target
>
> [Service]
> Type=simple
> PrivateTmp=false
> WorkingDirectory=/var/tmp/letters
> ExecStart=/usr/local/bin/letter --daemon --pidfile /run/letters/%i.pid
> PIDFile=/run/letters/%i.pid
> ExecReload=/bin/kill -HUP $MAINPID
> DeviceAllow=/dev/null rw
> ProtectSystem=true
> ProtectHome=true
>
> [Install]
> WantedBy=multi-user.target
>
> # *cat /etc/systemd/system-generators/letters*
> #!/bin/sh
> exec 2>> /tmp/opg2
> set -eux
> GENDIR="$1"
> WANTDIR="$1/letters.service.wants"
> SERVICEFILE="/lib/systemd/system/letters@.service"
> CONFIG_DIR=/var/letters/
> mkdir -p "$WANTDIR"
> for CONFIG in `cd $CONFIG_DIR; ls *.conf 2> /dev/null`; do
>  NAME=${CONFIG%%.conf}
>  ln -s "$SERVICEFILE" "$WANTDIR/letters@$NAME.service"
> done
> exit 0
>
>
> Now for the fun:
>
> # *touch /var/letters/aleph.conf /var/letters/e.conf
> /var/letters/zeta.conf*
> # systemctl daemon-reload
> # ls -l /run/systemd/generator/letters.service.wants
> total 0
> lrwxrwxrwx 1 root root 36 Mar 19 17:37 letters@aleph.service ->
> /lib/systemd/system/letters@.service
> lrwxrwxrwx 1 root root 36 Mar 19 17:37 letters@e.service ->
> /lib/systemd/system/letters@.service
> lrwxrwxrwx 1 root root 36 Mar 19 17:37 letters@zeta.service ->
> /lib/systemd/system/letters@.service
> # *systemctl enable letters.service*
> Created symlink /etc/systemd/system/multi-user.target.wants/letters.service
> → /etc/systemd/system/letters.service.
> # *systemctl start letters.service*
> # *ps ax | grep lett*
> 22853 ?S  0:00 /usr/local/bin/letter --daemon --pidfile /run/
> letters/e.pid
> 22927 ?S  0:00 /usr/local/bin/letter --daemon --pidfile /run/
> letters/aleph.pid
> 22928 ?S  0:00 /usr/local/bin/letter --daemon --pidfile /run/
> letters/zeta.pid
>
> So far so good. This is working as expected. Even better:
>
> # *touch /var/letters/tcha.conf*
> # *systemctl daemon-reload*
> # *systemctl start letters.service*
> # *ps ax | grep lett*
> 22853 ?S  0:00 /usr/local/bin/letter --daemon --pidfile /run/
> letters/e.pid
> 22927 ?S  0:00 /usr/local/bin/letter --daemon --pidfile /run/
> letters/aleph.pid
> 22928 ?S  0:00 /usr/local/bin/letter --daemon --pidfile /run/
> letters/zeta.pid
> 23083 ?S  0:00 /usr/local/bin/letter --daemon --pidfile /run/
> letters/tcha.pid
>
> But now the trouble begins:
>
> # *rm /var/letters/e.conf*
> # *systemctl daemon-reload *
> # *ls -l /run/systemd/generator/letters.service.wants*
> total 0
> lrwxrwxrwx 1 root root 36 Mar 19 17:44 letters@aleph.service ->
> /lib/systemd/system/letters@.service
> lrwxrwxrwx 1 root root 36 Mar 19 17:44 letters@tcha.service ->
> /lib/systemd/system/letters@.service
> lrwxrwxrwx 1 root root 36 Mar 19 17:44 letters@zeta.service ->
> /lib/systemd/system/letters@.service
>
> The link letters@e.service has been correctly removed,  but the
> corresponding process still exists:
> # *ps ax | grep e.pid*
> 22853 ?S  0:00 /usr/local/bin/letter --daemon --pidfile
> /run/letters/e.pid
>
>
>
>
I also tried this with *requires *instead of *wants*, but the behavior is
the same.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How do I create/destroy instances dynamically when config files appear/disappear?

[John Ioannidis]

I want to have a service with several instances, each of which has a
configuration file; when configuration files appear and disappear, I want
the corresponding instances to be created and started, and die,
respectively, and in particular have the running processes corresponding to
the removed units be killed.

I can get them to start the first time, but they do not stop when
configuration files change. If I systemctl daemon-reload, the links in
/run/systemd/system-generators get properly adjusted, but I cannot figure
out how to tell my service to kill the no-longer-needed processes. If I
also systemctl reload the service, all existing processes are killed, which
is absolutely not what I want.

Here is what I've done: what am I doing wrong?

I tried modelling this after what OpenVPN does:

# *cat /etc/systemd/system/letters.service*
[Unit]
Description=Letters service
After=network.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
ExecReload=/bin/true
WorkingDirectory=/var/tmp/letters

[Install]
WantedBy=multi-user.target

# *cat /etc/systemd/system/letters@.service*
[Unit]
Description=Letters for %i
PartOf=letters.service
ReloadPropagatedFrom=letters.service
Before=systemd-user-sessions.service
After=syslog.target network-online.target
Wants=network-online.target

[Service]
Type=simple
PrivateTmp=false
WorkingDirectory=/var/tmp/letters
ExecStart=/usr/local/bin/letter --daemon --pidfile /run/letters/%i.pid
PIDFile=/run/letters/%i.pid
ExecReload=/bin/kill -HUP $MAINPID
DeviceAllow=/dev/null rw
ProtectSystem=true
ProtectHome=true

[Install]
WantedBy=multi-user.target

# *cat /etc/systemd/system-generators/letters*
#!/bin/sh
exec 2>> /tmp/opg2
set -eux
GENDIR="$1"
WANTDIR="$1/letters.service.wants"
SERVICEFILE="/lib/systemd/system/letters@.service"
CONFIG_DIR=/var/letters/
mkdir -p "$WANTDIR"
for CONFIG in `cd $CONFIG_DIR; ls *.conf 2> /dev/null`; do
 NAME=${CONFIG%%.conf}
 ln -s "$SERVICEFILE" "$WANTDIR/letters@$NAME.service"
done
exit 0


Now for the fun:

# *touch /var/letters/aleph.conf /var/letters/e.conf /var/letters/zeta.conf*
# systemctl daemon-reload
# ls -l /run/systemd/generator/letters.service.wants
total 0
lrwxrwxrwx 1 root root 36 Mar 19 17:37 letters@aleph.service ->
/lib/systemd/system/letters@.service
lrwxrwxrwx 1 root root 36 Mar 19 17:37 letters@e.service ->
/lib/systemd/system/letters@.service
lrwxrwxrwx 1 root root 36 Mar 19 17:37 letters@zeta.service ->
/lib/systemd/system/letters@.service
# *systemctl enable letters.service*
Created symlink /etc/systemd/system/multi-user.target.wants/letters.service
→ /etc/systemd/system/letters.service.
# *systemctl start letters.service*
# *ps ax | grep lett*
22853 ?S  0:00 /usr/local/bin/letter --daemon --pidfile /run/
letters/e.pid
22927 ?S  0:00 /usr/local/bin/letter --daemon --pidfile /run/
letters/aleph.pid
22928 ?S  0:00 /usr/local/bin/letter --daemon --pidfile /run/
letters/zeta.pid

So far so good. This is working as expected. Even better:

# *touch /var/letters/tcha.conf*
# *systemctl daemon-reload*
# *systemctl start letters.service*
# *ps ax | grep lett*
22853 ?S  0:00 /usr/local/bin/letter --daemon --pidfile /run/
letters/e.pid
22927 ?S  0:00 /usr/local/bin/letter --daemon --pidfile /run/
letters/aleph.pid
22928 ?S  0:00 /usr/local/bin/letter --daemon --pidfile /run/
letters/zeta.pid
23083 ?S  0:00 /usr/local/bin/letter --daemon --pidfile /run/
letters/tcha.pid

But now the trouble begins:

# *rm /var/letters/e.conf*
# *systemctl daemon-reload *
# *ls -l /run/systemd/generator/letters.service.wants*
total 0
lrwxrwxrwx 1 root root 36 Mar 19 17:44 letters@aleph.service ->
/lib/systemd/system/letters@.service
lrwxrwxrwx 1 root root 36 Mar 19 17:44 letters@tcha.service ->
/lib/systemd/system/letters@.service
lrwxrwxrwx 1 root root 36 Mar 19 17:44 letters@zeta.service ->
/lib/systemd/system/letters@.service

The link letters@e.service has been correctly removed,  but the
corresponding process still exists:
# *ps ax | grep e.pid*
22853 ?S  0:00 /usr/local/bin/letter --daemon --pidfile
/run/letters/e.pid
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] networkd dhcp client - serialize / run stand alone / inject or restart dhcp client

[Dimitri John Ledkov]

I have a request to start/stop/restart the dhcp lease client, and/or
run networkd dhcp client stand alone, or somehow serialize dhcpclient
lease and inject that for networkd-dhcp to pick that up and restart.

For example, Ubuntu initramfs currently does not have networkd in it,
but it can bring interfaces up with dhcp.

And i'm not sure if there is a way to pass/inject the dhcp lease to
networkd as a runtime state to pick up from there. Ideally without
re-acquiring the lease once again.

I'm currently pondering if I should be trying to get networkd running
in the initramfs (without systemd in the initramfs), or like generate
a runtime networkd config for post-pivot to root.

Ideally, it would be nice to ship a "one-shot" dhcp lease acquire
helper binary, that could be shipped in the initramfs, which does
everything using the internal networkd dhcp lease and serializes the
state in /run/. Such that post-pivot, the full networkd can notice
that lease file and start running the longterm dhcp client.

Think, something like $ ipconfig -c dhcp eth0 -> as shipped by klibc-utils

Would such a util, be in-scope, for systemd-networkd?

-- 
Regards,

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

Re: [systemd-devel] unit symlinks ignored (archlinux mkinitcpio)

[John Lane]

Archlinux uses a 'mkinitcpio' script to create the initramfs image file.
This copies files into a working directory which it then archives. The
problem with this is that files which were symlinks are not in the copy.

If the initramfs uses systemd then this is a potential problem.

This isn't a systemd problem but more of an archlinux one, so I've
raised it over there...
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] unit symlinks ignored

[John Lane]

On 05/09/17 17:23, John Lane wrote:
> Having checked the journal, I see complaints of the form:
> 
> systemd[1]: cryptsetup.target: Wants dependency dropin
> /etc/systemd/system/cryptsetup.target.wants/cryptsetup@sda.service is
> not a symlink, ignoring.
> 
> However it is most definitely a symlink:
> 

I think I know what the problem is. I bet it isn't a symlink inside my
initramfs. I need to check but just wanted to put this out there :)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] unit symlinks ignored

[John Lane]

I recently upgraded a box which caused systemd to update from 232 to
234. Now it drops into an emergency shell and won't boot without my help.

Having checked the journal, I see complaints of the form:

systemd[1]: cryptsetup.target: Wants dependency dropin
/etc/systemd/system/cryptsetup.target.wants/cryptsetup@sda.service is
not a symlink, ignoring.

However it is most definitely a symlink:

# ls -l
/etc/systemd/system/cryptsetup.target.wants/cryptsetup@sda.service
lrwxrwxrwx 1 root root 39 Jan 29  2016
/etc/systemd/system/cryptsetup.target.wants/cryptsetup@sda.service ->
/etc/systemd/system/cryptsetup@.service

# file !$
file /etc/systemd/system/cryptsetup.target.wants/cryptsetup@sda.service

/etc/systemd/system/cryptsetup.target.wants/cryptsetup@sda.service:
symbolic link to /etc/systemd/system/cryptsetup@.service
# stat
/etc/systemd/system/cryptsetup.target.wants/cryptsetup\@sda.service
  File:
/etc/systemd/system/cryptsetup.target.wants/cryptsetup@sda.service ->
/etc/systemd/system/cryptsetup@.service
  Size: 39  Blocks: 0  IO Block: 4096   symbolic
link
Device: fe02h/65026dInode: 263672  Links: 1

Access: (0777/lrwxrwxrwx)  Uid: (0/root)   Gid: (0/root)

Access: 2017-09-05 13:00:29.445469702 +0100
Modify: 2016-01-29 09:42:11.0 +
Change: 2016-01-29 12:35:58.866681978 +
 Birth: -
#

This changed in version 233, I think the related commit is 1f9e5cf
5/feb/17 to file src/core/load-dropin.c

The intervention I perform to allow the boot to continue is to
"systemctl start" the units that systemd chose to ignore. My current
workaround is to downgrade to systemd 232 which boots without intervention.

FYI the unit in question "cryptsetup@.service" is a custom unit that
mounts encrypted volumes using external luks headers and keys because
crypttab could not handle that (I don't know if that situation has
changed) but I don't think that's relevant to the issue at hand.

Please let me know if I can provide any more information. If this is a
bug then I can raise it on the Github issue tracker.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Samba

[John Winward]

Ok thanks





*From:* Mantas Mikulėnas [mailto:graw...@gmail.com]
*Sent:* 24 May 2017 08:25
*To:* John Winward 
*Cc:* Systemd 
*Subject:* Re: [systemd-devel] Samba



On Wed, May 24, 2017 at 10:21 AM, John Winward 
wrote:

Morning



I have just installed a CentOS 7 system and I hace install many CentOS
platgforms over the years



However, I cannot seem to get SAMBA running and have nenver had issues with
this before?



[root@d3server ~]£ systemctl start
smb

Job for smb.service failed because the control process exited with error
code. S

ee "systemctl status smb.service" and "journalctl -xe" for
details.

[root@d3server ~]£





[root@d3server ~]£ systemctl status
smb.service

 ùÅ smb.service - Samba SMB
Daemon

   Loaded: loaded (/usr/lib/systemd/system/smb.service; enabled; vendor
preset:

disabled)


   Active: failed (Result: exit-code) since Wed 2017-05-24 08:17:15 BST;
29s ago




  Process: 3731 ExecStart=/usr/sbin/smbd $SMBDOPTIONS (code=exited,
status=1/FAI

LURE)


 Main PID: 3731 (code=exited,
status=1/FAILURE)



May 24 08:17:15 d3server.scolaquip.co.uk systemd[1]: Starting Samba SMB
Daemo...




May 24 08:17:15 d3server.scolaquip.co.uk systemd[1]: smb.service: main
proces...




May 24 08:17:15 d3server.scolaquip.co.uk systemd[1]: Failed to start Samba
SM...




May 24 08:17:15 d3server.scolaquip.co.uk systemd[1]: Unit smb.service
entered...




May 24 08:17:15 d3server.scolaquip.co.uk systemd[1]: smb.service
failed.

Hint: Some lines were ellipsized, use -l to show in
full.

[root@d3server
~]£



It doesn't look like a systemd issue either way (although next time I'd
suggest providing the full, non-ellipsized output).



Please check /var/log/samba, verify your Samba configuration using
`testparm`, and/or contact Samba technical support.



-- 

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

[systemd-devel] Samba

[John Winward]

Morning



I have just installed a CentOS 7 system and I hace install many CentOS
platgforms over the years



However, I cannot seem to get SAMBA running and have nenver had issues with
this before?



[root@d3server ~]£ systemctl start
smb

Job for smb.service failed because the control process exited with error
code. S

ee "systemctl status smb.service" and "journalctl -xe" for
details.

[root@d3server ~]£





[root@d3server ~]£ systemctl status
smb.service

 ùÅ smb.service - Samba SMB
Daemon

   Loaded: loaded (/usr/lib/systemd/system/smb.service; enabled; vendor
preset:

disabled)


   Active: failed (Result: exit-code) since Wed 2017-05-24 08:17:15 BST;
29s ago




  Process: 3731 ExecStart=/usr/sbin/smbd $SMBDOPTIONS (code=exited,
status=1/FAI

LURE)


 Main PID: 3731 (code=exited,
status=1/FAILURE)



May 24 08:17:15 d3server.scolaquip.co.uk systemd[1]: Starting Samba SMB
Daemo...




May 24 08:17:15 d3server.scolaquip.co.uk systemd[1]: smb.service: main
proces...




May 24 08:17:15 d3server.scolaquip.co.uk systemd[1]: Failed to start Samba
SM...




May 24 08:17:15 d3server.scolaquip.co.uk systemd[1]: Unit smb.service
entered...




May 24 08:17:15 d3server.scolaquip.co.uk systemd[1]: smb.service
failed.

Hint: Some lines were ellipsized, use -l to show in
full.

[root@d3server
~]£







*Regards,*



*John Winward*

*[image: Description: Description: Description: LogoEmail]*



*Tel.: 01638 751172*

*Mob :   07887 944855*



*P* *please consider the environment before printing this e-mail*



**

Confidentiality: This e-mail and its attachments are intended for the above
named only and may be confidential. If they have come to you in error you
must take no action based on them, nor must you copy or show them to
anyone; please reply to this e-mail and highlight the error. Security
Warning: Please note that this e-mail has been created in the knowledge
that Internet e-mail is not a 100% secure communications medium. We advise
that you understand and observe this lack of security when e-mailing us.

***

Viruses: Although we have taken steps to ensure that this e-mail and
attachments are free from any virus, we advise that in keeping with good
computing practice the recipient should ensure they are actually virus free.



MRP Systems
Registered office: Keepers Cottage, 15 Dane Hill Road, Kennett, Newmarket,
Suffolk CB8 7QX, United Kingdom
Registration No. N/A   VAT Number 720 1210 11
--
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Retaining boot messages on (near-)stateless systems

[John Florian]

I maintain a derivative of Fedora Live (built using lorax) that gets
deployed on hundreds of systems, far more than my team has the man-
power to keep a watchful eye.  Occasionally we are notified of a
problematic node and often it would be helpful to see the full journal
for say, the first 15 minutes of run-time in which the node transforms
itself from a generic appliance to a specific role.  Unfortunately, in
many cases we are notified too late and journald has tail-trimmed the
logs we desire most.

Reviewing journald.conf(5) I don't see options to achieve what I want
directly so my thought is to create a service and timer with
OnBootSec=15m to duplicate the journal over to persistent storage,
which would then require non-standard techniques for viewing but at
least the availability would be guaranteed.

Is there a better way to achieve this?  If not, what's the best way to
duplicate the journal data?   Simply cp -a /var/log/journal/ ... or use
journalctl to dump or export it somehow?

I'll also add that I also wish to retain higher priority messages for a
longer period, though for the first ~15m I want everything, DEBUG
included.  That leads me to think about a 2nd logger (journald,
ideally) which had messages forwarded to it, but with different
retention characteristics.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] systemd integration

[John Doe]

Free and Open-Source (FOSS) operating systems
without systemd
http://without-systemd.org/wiki/index.php/Main_Page
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How do I easily resolve conflicting jobs in custom units?

[John Florian]

On Thu, 2017-03-30 at 16:04 +0200, Lennart Poettering wrote:
> On Thu, 30.03.17 09:53, John Florian (j...@doubledog.org) wrote:
> 
> > On Thu, 2017-03-30 at 15:32 +0200, Lennart Poettering wrote:
> > > On Wed, 22.03.17 16:47, John Florian (j...@doubledog.org) wrote:
> > > 
> > > > Mar 22 16:11:42 localhost systemd[1]: sshd.service: Looking at
> > > > job
> > > > sshd.service/start conflicted_by=no
> > > > Mar 22 16:11:42 localhost systemd[1]: sshd.service: Looking at
> > > > job
> > > > sshd.service/stop conflicted_by=yes
> > > > Mar 22 16:11:42 localhost systemd[1]: sshd.service: Fixing
> > > > conflicting
> > > > jobs sshd.service/start,sshd.service/stop by deleting job
> > > > sshd.service/start
> > > 
> > > So this suggests that you have both a job that pulls in
> > > sshd.service
> > > and one that conflicts with it in your initial transaction. Try
> > > figuring out what that is...
> > > 
> > > (hint: use "systemctl show sshd.service" for that, and look for
> > > Conflicts= and ConlictedBy=)
> > > 
> > 
> > That seems like a reasonable theory, but given the following I
> > can't
> > make any sense of it.
> > 
> > # journalctl -b | grep -i conflict
> > Mar 30 09:35:57 localhost systemd[1]: sshd.service: Looking at job
> > sshd.service/start conflicted_by=no
> > Mar 30 09:35:57 localhost systemd[1]: sshd.service: Looking at job
> > sshd.service/stop conflicted_by=yes
> > Mar 30 09:35:57 localhost systemd[1]: sshd.service: Fixing
> > conflicting
> > jobs sshd.service/start,sshd.service/stop by deleting job
> > sshd.service/start
> > Mar 30 09:35:57 localhost systemd[1]: sshd-keygen.target: Looking
> > at
> > job sshd-keygen.target/start conflicted_by=no
> > Mar 30 09:35:57 localhost systemd[1]: sshd-keygen.target: Looking
> > at
> > job sshd-keygen.target/stop conflicted_by=no
> > Mar 30 09:35:57 localhost systemd[1]: sshd-keygen.target: Fixing
> > conflicting jobs sshd-keygen.target/start,sshd-keygen.target/stop
> > by
> > deleting job sshd-keygen.target/stop
> > 
> > # systemctl show sshd.service | grep -i conflict
> > Conflicts=shutdown.target
> > ConflictedBy=sshd.socket
> 
> Note that you can use sshd on Fedora in socket-activated mode or
> non-socket-activated mode. In socket-activated mode, sshd.socket is
> started at boot, and for each connection one sshd@.service instance
> is
> created. sshd.service otoh is only used in the non-socket-activated
> mode, and in that case is the singleton service processing all
> connections...

Yup, I was aware of that of neat feature...

> My educated guess is that you somehow ended up pull in both
> sshd.service and sshd.socket, but you cannot really do that, you have
> to make a choice between them, as there's only one port 22, and it's
> either systemd that listens on it or sshd.

Bingo!  That was just what I needed to put my train of thought on a
different set of tracks.  systemctl status sshd.socket showed that it
was enabled and the vendor preset was also enabled.  Wait...
what   My package that contains the sshd-persist-keys.service and
sshd-restore-keys.service units also provides a file with unit presets
and in there I had "enabled sshd.*".  That was fine back in F21, but no
so with F25 so I replaced that with a "enable sshd.service" and
"disabled sshd.socket" and all is well now.   It's funny, the problem
seems so obvious now yet only an hour ago I was totally blind to the
problem.

Thank you so much for your time and wisdom.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How do I easily resolve conflicting jobs in custom units?

[John Florian]

On Thu, 2017-03-30 at 15:32 +0200, Lennart Poettering wrote:
> On Wed, 22.03.17 16:47, John Florian (j...@doubledog.org) wrote:
> 
> > Mar 22 16:11:42 localhost systemd[1]: sshd.service: Looking at job
> > sshd.service/start conflicted_by=no
> > Mar 22 16:11:42 localhost systemd[1]: sshd.service: Looking at job
> > sshd.service/stop conflicted_by=yes
> > Mar 22 16:11:42 localhost systemd[1]: sshd.service: Fixing
> > conflicting
> > jobs sshd.service/start,sshd.service/stop by deleting job
> > sshd.service/start
> 
> So this suggests that you have both a job that pulls in sshd.service
> and one that conflicts with it in your initial transaction. Try
> figuring out what that is...
> 
> (hint: use "systemctl show sshd.service" for that, and look for
> Conflicts= and ConlictedBy=)
> 

That seems like a reasonable theory, but given the following I can't
make any sense of it.

# journalctl -b | grep -i conflict
Mar 30 09:35:57 localhost systemd[1]: sshd.service: Looking at job
sshd.service/start conflicted_by=no
Mar 30 09:35:57 localhost systemd[1]: sshd.service: Looking at job
sshd.service/stop conflicted_by=yes
Mar 30 09:35:57 localhost systemd[1]: sshd.service: Fixing conflicting
jobs sshd.service/start,sshd.service/stop by deleting job
sshd.service/start
Mar 30 09:35:57 localhost systemd[1]: sshd-keygen.target: Looking at
job sshd-keygen.target/start conflicted_by=no
Mar 30 09:35:57 localhost systemd[1]: sshd-keygen.target: Looking at
job sshd-keygen.target/stop conflicted_by=no
Mar 30 09:35:57 localhost systemd[1]: sshd-keygen.target: Fixing
conflicting jobs sshd-keygen.target/start,sshd-keygen.target/stop by
deleting job sshd-keygen.target/stop

# systemctl show sshd.service | grep -i conflict
Conflicts=shutdown.target
ConflictedBy=sshd.socket


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

Re: [systemd-devel] How do I easily resolve conflicting jobs in custom units?

[John Florian]

On Thu, 2017-03-23 at 06:38 +0300, Andrei Borzenkov wrote:
> 22.03.2017 23:47, John Florian пишет:
> > I build an mostly-stateless appliance OS derived from Fedora (25
> > ATM)
> > and have several custom units to make it all possible.  My units
> > had
> > worked great with F21, but are now giving me problems with
> > F25.  One
> > pair of the custom units do some trickery to relocate sshd host
> > keys
> > from /etc/ssh to an alternate location that provides persistence:
> > 
> > 
> 
> Please make full log available as well as actual unit definitions
> that
> are not started.
> 

Okay, attached are a complete boot.log (journalctl > boot.log) as well
as the most relevant units. Please note that while I need a solution,
it's just as important I understand HOW to resolve this kind of issue.
I've struggled through similar problems in the past and I never feel
adept at the process, like I'm not using a fundamental tool for the job
and instead relying more on trial and error.

While there's no doubt a lot of change between F21 and F25, the one
thing that forced a change on my part was systemd transitioning from a
single sshd-keygen.service to a templated sshd-keygen@.service.  For me
that meant the following change:

diff --git lib/systemd/sshd-persist-keys.service lib/systemd/sshd-
persist-keys.service
index d3508a8..7500b68 100644
--- lib/systemd/sshd-persist-keys.service
+++ lib/systemd/sshd-persist-keys.service
@@ -1,8 +1,8 @@
 [Unit]
 Description=OpenSSH server - persist volatile keys for the AOS
-After=sshd-keygen.service
+After=sshd-keygen.target
 Before=sshd.service
-Wants=sshd-keygen.service
+Wants=sshd-keygen.target

 [Service]
 ExecStart=/usr/sbin/sshd-persist-keys
diff --git lib/systemd/sshd-restore-keys.service lib/systemd/sshd-
restore-keys.service
index 475cede..85ac3bc 100644
--- lib/systemd/sshd-restore-keys.service
+++ lib/systemd/sshd-restore-keys.service
@@ -1,7 +1,7 @@
 [Unit]
 Description=OpenSSH server - restore persisted keys for the AOS
 After=aos-storage-init.service
-Before=sshd-keygen.service
+Before=sshd-keygen@rsa.service sshd-keygen@ecdsa.service sshd-keygen@e
d25519.service

 [Service]
 ExecStart=/usr/sbin/sshd-restore-keys


I'd love to know of a better way for my sshd-restore-kes.service to be
coded such that it's unnecessary to list individual key types, but my
experience has led me to believe that targets only define a point in
time when a collection of units have completed and that there's no
equivalent to a point in time prior to any of them having begun.  Thus
I found I couldn't use Before=sshd-keygen.target because keys were
being generated and restored concurrently rather than serially
(restored if possible and then the missing generated as needed).

sshd-startup-failure.tar.gz
Description: application/compressed-tar
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] How do I easily resolve conflicting jobs in custom units?

[John Florian]

I build an mostly-stateless appliance OS derived from Fedora (25 ATM)
and have several custom units to make it all possible.  My units had
worked great with F21, but are now giving me problems with F25.  One
pair of the custom units do some trickery to relocate sshd host keys
from /etc/ssh to an alternate location that provides persistence:

$ systemctl cat sshd-persist-keys.service
# /usr/lib/systemd/system/sshd-persist-keys.service
[Unit]
Description=OpenSSH server - persist volatile keys for the AOS
After=sshd-keygen.target
Before=sshd.service
Wants=sshd-keygen.target

[Service]
ExecStart=/usr/sbin/sshd-persist-keys
Type=oneshot
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target


$ systemctl cat sshd-restore-keys.service
# /usr/lib/systemd/system/sshd-restore-keys.service
[Unit]
Description=OpenSSH server - restore persisted keys for the AOS
After=aos-storage-init.service
Before=sshd-keygen@rsa.service sshd-keygen@ecdsa.service sshd-keygen@ed
25519.service

[Service]
ExecStart=/usr/sbin/sshd-restore-keys
Type=oneshot
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target


I found that on some boots, sshd wasn't getting started.  With the help
of booting with systemd.log_level=debug I learned:

$ sudo journalctl | grep conflict
Mar 22 16:11:42 localhost systemd[1]: sshd.service: Looking at job
sshd.service/start conflicted_by=no
Mar 22 16:11:42 localhost systemd[1]: sshd.service: Looking at job
sshd.service/stop conflicted_by=yes
Mar 22 16:11:42 localhost systemd[1]: sshd.service: Fixing conflicting
jobs sshd.service/start,sshd.service/stop by deleting job
sshd.service/start
Mar 22 16:11:42 localhost systemd[1]: sshd.socket: Looking at job
sshd.socket/stop conflicted_by=no
Mar 22 16:11:42 localhost systemd[1]: sshd.socket: Looking at job
sshd.socket/start conflicted_by=no
Mar 22 16:11:42 localhost systemd[1]: sshd.socket: Fixing conflicting
jobs sshd.socket/stop,sshd.socket/start by deleting job
sshd.socket/stop
Mar 22 16:11:42 localhost systemd[1]: sshd-keygen.target: Looking at
job sshd-keygen.target/start conflicted_by=no
Mar 22 16:11:42 localhost systemd[1]: sshd-keygen.target: Looking at
job sshd-keygen.target/stop conflicted_by=no
Mar 22 16:11:42 localhost systemd[1]: sshd-keygen.target: Fixing
conflicting jobs sshd-keygen.target/start,sshd-keygen.target/stop by
deleting job sshd-keygen.target/stop


I'm sure systemd-analyze is my friend here, but I've not found an
effective way to grok the problem.  s-a dot either gives me too much to
comprehend or not enough to make evident the problem.  I've tried
feeding it different PATTERNS like: none at all, sshd.service, ssh-
keygen.target, sshd-{persist,restore}-keys.service and more.  I either
see a whole forest or just a few trees that seem to be getting along
happily together.

What advice can you suggest?___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Renew DHCP lease

[John Lane]

I've just switched a server to systemd-networkd dhcp client.

How do I renew a lease and/or force it to push a new hostname to the
dhcp server.

I have RTFM and get the impression it can't be done. Hopefully I have
that wrong...

Thanks and much appreciated.

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

Re: [systemd-devel] Emulate two cron tab entries to start/stop service unit natively?

[John]

>
> From: Kai Krakow 
>To: systemd-devel@lists.freedesktop.org 
>Sent: Tuesday, August 2, 2016 6:38 AM
>Subject: Re: [systemd-devel] Emulate two cron tab entries to start/stop 
>service unit natively?
> 
>
>Am Mon, 1 Aug 2016 23:59:13 + (UTC)
>schrieb John :
>
>> Is it possible to use a systemd timer unit to start and stop a
>> service unit according to set times of the day?  In my case,
>> openvpn.service is a forking type if that matters. I can do this
>> using cron, but am wondering if/how to do it with systemd natively.
>> 
>> In cron terms, one could do this like so:
>> # start at 7 AM
>> * 7 * * * systemctl start openvpn.service
>> 
>> 
>> # stop at 5 PM
>> * 17 * * * systemctl stop openvnp.service
>> 
>> The syntax of the timer with differential commands (ie start the
>> service at 7 AM and stop it at 5 PM) isn't clear to me even after
>> consulting `man systemd.time` and `man systemd.timer`.
>
>Create to additional services, openvpn-start.service and
>openvpn-stop.service, which each require openvpn.service to start or
>stop (Wants and Conflicts should work). Those two services should be of
>type one-shot, so they start once and quit without error. They contain
>no exec lines.
>
>Now create two timer units, openvpn-{start,stop}.timer with appropriate
>time definitions and enable those. All other units shouldn't be enabled.


Thank you for the detailed reply! Too bad there isn't a more simplistic 
solution (ie something native in a single timer unit).
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Emulate two cron tab entries to start/stop service unit natively?

[John]

Is it possible to use a systemd timer unit to start and stop a service unit 
according to set times of the day?  In my case, openvpn.service is a forking 
type if that matters. I can do this using cron, but am wondering if/how to do 
it with systemd natively.

In cron terms, one could do this like so:
# start at 7 AM
* 7 * * * systemctl start openvpn.service


# stop at 5 PM
* 17 * * * systemctl stop openvnp.service

The syntax of the timer with differential commands (ie start the service at 7 
AM and stop it at 5 PM) isn't clear to me even after consulting `man 
systemd.time` and `man systemd.timer`.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Input on a systemd service for kodi and strangeness with permissions on /dev/null (systemd 229)

[John]

> From: Mantas Mikulėnas 
>To: John  
>Cc: Systemd 
>Sent: Tuesday, March 29, 2016 1:22 AM
>Subject: Re: [systemd-devel] Input on a systemd service for kodi and 
>strangeness with permissions on /dev/null (systemd 229)
> 
>Those actually look like typical permissions that a /dev/tty* device would 
>have, so my guess would be that xinit (or something) first sets its stdout to 
>g-w (0600) on startup, to avoid being disturbed, and later tries to set it 
>back to g+w (0620) without actually checking whether its stdout is still a 
>tty...
>


If that is to be expected, perhaps I need a different ExecStop= line.  I am out 
of ideas.  

1) Anyone care to propose something to the existing service?[1]
2) If my service is not sane, I am open to hear from the experts 
modifications/total rewrite.

Thank you.

1. 
https://github.com/graysky2/kodi-standalone-service/blob/master/init/kodi.service
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Input on a systemd service for kodi and strangeness with permissions on /dev/null (systemd 229)

[John]

I am trying to write a service that will start and stop kodi[1] on Linux.  The 
best working draft I have so far is here[2] but it does not end in a clean 
state if I `systemctl stop kodi` so I am looking for a good way to use an 
ExecStop= statement or perhaps even rewrite the service entirely.

Attached is the output of a `systemctl stop kodi` to illustrate:

% journalctl -b -u kodi
-- Logs begin at Sun 2016-03-20 16:00:01 EDT, end at Mon 2016-03-28 10:47:39 
EDT. --
Mar 28 10:46:21 ruby systemd[1]: Started Starts instance of Kodi using xinit.
Mar 28 10:46:21 ruby systemd[572]: pam_unix(login:session): session opened for 
user kodi by (uid=0)
Mar 28 10:47:20 ruby systemd[1]: Stopping Starts instance of Kodi using xinit...
Mar 28 10:47:20 ruby systemd[733]: pam_unix(login:session): session opened for 
user kodi by (uid=0)
Mar 28 10:47:20 ruby systemd[733]: pam_systemd(login:session): Cannot create 
session: Already occupied by a session
Mar 28 10:47:20 ruby systemd[1]: kodi.service: Control process exited, 
code=exited status=1
Mar 28 10:47:21 ruby systemd[1]: kodi.service: Main process exited, 
code=exited, status=1/FAILURE
Mar 28 10:47:21 ruby systemd[1]: Stopped Starts instance of Kodi using xinit.
Mar 28 10:47:21 ruby systemd[1]: kodi.service: Unit entered failed state.
Mar 28 10:47:21 ruby systemd[1]: kodi.service: Failed with result 'exit-code'.

Interestingly, if I add the following line, the service does stop cleanly but 
the permissions on /dev/null gets screwed-up: ExecStop=/usr/bin/pkill kodi

Before I stop the service:
% ls -lh /dev/null
crw-rw-rw- 1 root root 1, 3 Mar 28 14:20 /dev/null

After I stop the service:
% ls -lh /dev/null
crw--w 1 kodi root 1, 3 Mar 28 14:20 /dev/null

Suggestions are welcomed.  Thank you in advance.

1. https://kodi.tv
2. 
https://github.com/graysky2/kodi-standalone-service/blob/master/init/kodi.service
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to prevent an initramfs service from being stopped at switch-root ?

[John Lane]

On 11/01/16 16:44, Lennart Poettering wrote:
> On Mon, 11.01.16 13:38, John Lane (syst...@jelmail.com) wrote:
>
>> On 11/01/16 13:09, Tomasz Torcz wrote:
>>> On Mon, Jan 11, 2016 at 12:39:10PM +, John Lane wrote:
>>>> I have some services in my initramfs that unlock some crypto volumes to
>>>> make the root and some other filesystems available.
>>>   This seems relevant:
>>> https://wiki.freedesktop.org/www/Software/systemd/RootStorageDaemons/
>>>
>> Yeah, I read that. But it doesn't explain how to configure a unit. I
>> read the bit about processes where the first character of the zeroth
>> command line argument is '@' are excluded from the killing spree, but
>> not sure how to do that from a unit specification file.
> This should be done by the daemons themselves. It's really nothing you
> can do properly from the outside.
>
> If daemons shall run from the initrd, they must be prepared for that,
> for example never access /var and not assume tmpfiles was run or
> suchlike. They must be able to deal with the root file directory being
> pivoted away and suchlike. hence: it's really not as easy as just
> taking a daemon and calling it slightly differently -- instead the
> daemon must be designed for this mode of operation, in which case it
> should implement the @ logic natively.
>
> Lennart
>
Let me explain my scenario to you, perhaps I am doing something wrong...

I have a "cryptsetup@.service" that is symlinked as
cryptsetup@some_disk.service that unlocks a crypto-disk containing the
root filesystem. Mounts then happen as they should, and everything works.

Then, when the switch root happens, systemd tries to kill the above
service. This fails because it is busy due to the underlying filesystem
being mounted. This leaves the unit in a failed state. After the switch
root, systemd tries to start the unit but this fails because the device
mapper is already assigned. The net result is the system's always
"degraded" with "cryptsetup@some_disk.service" in a failed state
(despite everything being fine).

I'm using a cryptsetup@.service unit instead of /etc/crypttab because I
needed to use cryptsetup options that the latter didn't support when I
implemented it.





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

Re: [systemd-devel] How to prevent an initramfs service from being stopped at switch-root ?

[John Lane]

On 11/01/16 13:09, Tomasz Torcz wrote:
> On Mon, Jan 11, 2016 at 12:39:10PM +0000, John Lane wrote:
>> I have some services in my initramfs that unlock some crypto volumes to
>> make the root and some other filesystems available.
>   This seems relevant:
> https://wiki.freedesktop.org/www/Software/systemd/RootStorageDaemons/
>
Yeah, I read that. But it doesn't explain how to configure a unit. I
read the bit about processes where the first character of the zeroth
command line argument is '@' are excluded from the killing spree, but
not sure how to do that from a unit specification file.

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

[systemd-devel] How to prevent an initramfs service from being stopped at switch-root ?

[John Lane]

I have some services in my initramfs that unlock some crypto volumes to
make the root and some other filesystems available.

Looking at the journal, I can see that the initramfs (at switch-root
time) tries to kill these services but this fails because the
filesystems are mounted by this point. I would like these services not
to be killed at switch-root time. How can I mark them such ?


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

[systemd-devel] libudev monitor sporadic fail

[John Ernberg]

Hi

I hope this is the correct mailing list in which to ask this, otherwise 
I apologize and please direct me to where I shall ask this question.

I have asked this on the oFono mailing list but it has gone unanswered, 
so I am trying my luck here, hoping that someone might be able to point 
me to what to do next.

I am running an embedded system with systemd 211 (and udev).
This system runs oFono which is started by systemd.
oFono uses libudev and creates an udev monitor from netlink to detect 
modems on for example USB.
The issue I am having is that sometimes the setup of this monitor fails, 
resulting in that oFono will not detect any modem.

The modems were enumerated in the kernel correctly, which means I could 
see them using for example 'lsusb', and could talk AT with them manually.
After some debugging I traced the problem to that the monitor setup 
failed in oFono.
It seems that the glib IOChannel wrap around the udev monitor fd 
receives some sort of error / HUP signal and shuts down.
I have not managed to figure out what's being received due to how 
sporadically this happens, but I would like to fix it.

When checking on google it seems that oFono's implementation of how to 
handle an udev monitor fd is correct, so I wonder what might be going on 
and where the cause is for this failure may reside.
Does anyone have any clue what I should be looking for in order to 
figure out why this happens?

I am not able to boot this system in a VM environment.

Thank you very much in advance and best regards // John Ernberg
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Keeping track of usage time

[Dimitri John Ledkov]

On 3 November 2015 at 06:27, Umut Tezduyar Lindskog  wrote:
> journalctl --list-boots seems great actually but wouldn't work for us.
> We cannot keep lots of logs in our products.
>

You shouldn't need to keep lots of logs, just a timer unit that would
query and store/transmit the bootids/deltas (possibly in a round-robin
fashion)

Regards,

Dimitri.


> Ultimately we are trying to answer the question of how long one of our
> product has been in use.
>
> We will implement it with a .timer/.service which periodically adds
> /proc/uptime to a file and the file gets preserved over reboot.
>
> Umut
>
> On Mon, Nov 2, 2015 at 7:00 PM, Lennart Poettering
>  wrote:
>> On Mon, 02.11.15 15:46, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote:
>>
>>> Hi,
>>>
>>> We would like to implement a feature to keep track of accumulated
>>> values of uptimes in our products. Tracked time will give us the total
>>> usage time of our product not just since last reboot (/proc/uptime).
>>>
>>> Is upstream interested in having such implementation?
>>
>> As Dimitri suggested: wouldn't a journalctl --list-boots invocation
>> suffice for this?
>>
>> Or do you need this per-service? (where the journal should be able to
>> provide you with the answer too, of course, but with a different line)
>>
>> Lennart
>>
>> --
>> Lennart Poettering, Red Hat
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
Regards,

Dimitri.
53 sleeps till Christmas, or less

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Keeping track of usage time

[Dimitri John Ledkov]

On 2 November 2015 at 14:46, Umut Tezduyar Lindskog  wrote:
> Hi,
>
> We would like to implement a feature to keep track of accumulated
> values of uptimes in our products. Tracked time will give us the total
> usage time of our product not just since last reboot (/proc/uptime).
>
> Is upstream interested in having such implementation?
>

Isn't that just the duration of each bootid from journal then?

Checkout output of:

$ journalctl --list-boots

-- 
Regards,

Dimitri.
63 sleeps till Christmas, or less

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] kernel and systemd boot sequence

[Dimitri John Ledkov]

Systemd is the init.

/etc/fstab is optional.

initramfs could be running systemd (e.g. dracut supports it), thus
systemd would be beofre switch_root.

However initramfs & switch_root are optional as well.

Hence the bootflow on a modern linux distribution like Clear Linux is:

kernel -> systemd -> user login.

On 29 October 2015 at 02:26, kennedy  wrote:
> the boot sequence is it right ?
> kernel --> initramfs --> switch_root --> systemd --> init & mount /etc/fstab
> --> user login
>
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>



-- 
Regards,

Dimitri.
63 sleeps till Christmas, or less

https://clearlinux.org
Open Source Technology Center
Intel Corporation (UK) Ltd. - Co. Reg. #1134945 - Pipers Way, Swindon SN3 1RJ.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Help writing a user service file that will exec a command upon system sleep

[John]

- Original Message -
> From: Simon McVittie 
> To: systemd-devel@lists.freedesktop.org
> Cc: 
> Sent: Thursday, October 29, 2015 3:27 PM
> Subject: Re: [systemd-devel] Help writing a user service file that will exec 
> a command upon system sleep
> 
> On 29/10/15 18:52, John wrote:
>>  This is an interesting idea but I would like to learn about user units and 
> sleep mode :)
> 
> I think the intention is that per-user code deals with sleep by having a
> service (daemon) that registers to inhibit suspend; when it is notified
> that systemd would like to suspend, it does what it needs to do, then
> releases the inhibit to allow suspend to continue.
> 
> Here's a working implementation (it also handles two flavours of network
> connectivity, but you can ignore those bits), which Telepathy uses to
> try to log out from IM services before suspending:
> http://cgit.freedesktop.org/telepathy/telepathy-mission-control/tree/src/connectivity-monitor.c


Hello Simon.  Thank you for the post.  I am not a programmer and cannot really 
read the code you referenced.  Can you point me to a particular line number or 
line numbers?  Since my tool is a bash script, I'm looking to distill out if 
possible the relevant sections and adapt to this use case.  Thank you.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Help writing a user service file that will exec a command upon system sleep

[John]

> From: David Timothy Strauss 
>To: John ; "systemd-devel@lists.freedesktop.org" 
> 
>Sent: Wednesday, October 28, 2015 7:54 PM
>Subject: Re: [systemd-devel] Help writing a user service file that will exec a 
>command upon system sleep
> 
>
>
>I read up on PSD, and I expect you're using it for performance/hardware 
>longevity. Correct me if I'm wrong about this.
>
>So, have you considered just mounting your home directory or a volume for 
>things like browser profile data with normally aggressive/unsafe options on a 
>normal file system? You can configure file systems like ext4 to only commit at 
>periodic intervals, and you can also configure your system to commit/sync all 
>file systems before going to sleep. They will buffer writes to memory until 
>committing, and reads will buffer into the kernel's page cache. This option is 
>not crash-safe, but neither is PSD.
>


This is an interesting idea but I would like to learn about user units and 
sleep mode :)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel