[systemd-devel] Weston not launching Via Service file.

[Rajshekhar Sanda]

Hello,


We are working on Genivi14, in which we are trying to launch weston via service 
file. It is not working if iam giving Type=notify in service file.

my build configuration is as follows:



Build Configuration:
BB_VERSION   = "1.36.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "universal"
TARGET_SYS   = "aarch64-poky-linux"
MACHINE  = "h3ulcb"
DISTRO   = "poky-ivi-systemd"
DISTRO_VERSION   = "14.0.0"
TUNE_FEATURES= "aarch64 cortexa57-cortexa53"
TARGET_FPU   = ""
SOC_FAMILY   = "rcar-gen3:r8a7795"
meta
meta-poky
meta-yocto-bsp   = "rocko:5f660914cd7eec8117efccdf1eb29c466b4e74f7"
meta-oe
meta-filesystems
meta-multimedia  = "rocko:eae996301d9c097bcbeb8046f08041dc82bb62f8"
meta-rcar-gen3
meta-ivi
meta-ivi-bsp
meta-optee   = ":"
meta-networking
meta-python  = "rocko:eae996301d9c097bcbeb8046f08041dc82bb62f8"
meta-rtlwifi-master
meta-aac = ":"


***


weston service file is as follows:


[Unit]
Description= launch weston
Requires=  dbus-session.service dbus.service systemd-user-sessions.service
After= dbus-session.socket dbus.service  dbus-session.service 
systemd-user-sessions.service  session-c1.scope
ConditionPathExists=/dev/tty0

[Service]
Type=notify
User=root
Restart=on-failure
ExecStart=/usr/bin/weston
NotifyAccess=all
PAMName=login
StandardInput=tty-fail
TTYPath=/dev/tty7
TTYReset=yes
TTYVHangup=yes
TTYVTDisallocate=yes
UtmpIdentifier=tty7
UtmpMode=root
TimeoutStartSec=60
WatchdogSec=20
#ExecStart=/usr/bin/weston

[Install]
WantedBy=basic.target




weston.ini file is as follows:



[core]
shell=ivi-shell.so
modules=systemd-notify.so

[ivi-shell]
ivi-module=ivi-controller.so
ivi-input-module=ivi-input-controller.so
ivi-shell-user-interface=/usr/lib/weston/weston-ivi-shell-user-interface

#developermode=true

cursor-theme=default
cursor-size=32

base-layer-id=1000
base-layer-id-offset=1

workspace-background-layer-id=2000
workspace-layer-id=3000
application-layer-id=4000

transition-duration=300

background-image=/usr/share/weston/background.png
background-id=1001
panel-image=/usr/share/weston/panel.png
panel-id=1002
surface-id-offset=10
tiling-image=/usr/share/weston/tiling.png
tiling-id=1003
sidebyside-image=/usr/share/weston/sidebyside.png
sidebyside-id=1004
fullscreen-image=/usr/share/weston/fullscreen.png
fullscreen-id=1005
random-image=/usr/share/weston/random.png
random-id=1006
home-image=/usr/share/weston/home.png
home-id=1007
workspace-background-color=0x9900
workspace-background-id=2001

[input-method]
path=/usr/libexec/weston-keyboard

[ivi-launcher]
workspace-id=0
icon-id=4001
icon=/usr/share/weston/icon_ivi_flower.png
path=/usr/bin/weston-flower

[ivi-launcher]
workspace-id=0
icon-id=4002
icon=/usr/share/weston/icon_ivi_clickdot.png
path=/usr/bin/weston-clickdot

[ivi-launcher]
workspace-id=1
icon-id=4003
icon=/usr/share/weston/icon_ivi_simple-egl.png
path=/usr/bin/weston-simple-egl

[ivi-launcher]
workspace-id=1
icon-id=4004
icon=/usr/share/weston/icon_ivi_simple-shm.png
path=/usr/bin/weston-simple-shm

[ivi-launcher]
workspace-id=2
icon-id=4005
icon=/usr/share/weston/icon_ivi_smoke.png
path=/usr/bin/weston-smoke

[ivi-launcher]
workspace-id=3
icon-id=4006
icon=/usr/share/weston/icon_ivi_flower.png
path=/usr/bin/weston-flower

[ivi-launcher]
workspace-id=3
icon-id=4007
icon=/usr/share/weston/icon_ivi_clickdot.png
path=/usr/bin/weston-clickdot

[ivi-launcher]
workspace-id=3
icon-id=4008
icon=/usr/share/weston/icon_ivi_simple-egl.png
path=/usr/bin/weston-simple-egl

[ivi-launcher]
workspace-id=3
icon-id=4009
icon=/usr/share/weston/icon_ivi_simple-shm.png
path=/usr/bin/weston-simple-shm

[ivi-launcher]
workspace-id=3
icon-id=4010
icon=/usr/share/weston/icon_ivi_smoke.png
path=/usr/bin/weston-smoke

***

systemctl status launchWeston.service output is as follows:


â—� launchWeston.service - launch weston
   Loaded: loaded (/etc/systemd/system/launchWeston.service; disabled; vendor 
preset: enabled)
   Active: failed (Result: protocol) since Fri 2019-02-22 04:56:02 UTC; 3min 
12s ago
  Process: 3177 ExecStart=/usr/bin/weston (code=killed, signal=TERM)
 Main PID: 3177 (code=killed, signal=TERM)

Feb 22 04:56:01 h3ulcb systemd[1]: launchWeston.service: Unit entered failed 
state.
Feb 22 04:56:01 h3ulcb systemd[1]: launchWeston.service: Failed with result 
'protocol'.
Feb 22 04:56:02 h3ulcb systemd[1]: launchWeston.service: Service hold-off time 
over, scheduling restart.
Feb 22 04:56:02 h3ulcb systemd[1]: Stopped launch weston.
Feb 22 04:56:02 h3ulcb systemd[1]: launchWeston.service: Start request repeated 
too quickly.
Feb 22 04:56:02 h3ulcb systemd[1]: Failed to start launch weston.
Feb 22 04:

Re: [systemd-devel] [PATCH 0/6] pstore: Tool to archive contents of pstore upon boot/shutdown

[Eric DeVolder]

OK, will do!
eric

On 5/16/19 9:34 AM, Lennart Poettering wrote:

On Do, 16.05.19 09:28, Eric DeVolder (eric.devol...@oracle.com) wrote:

Could you please submit this via github as PR? Review is so much nicer
there, in particular for complex patch sets, and this qualifies as
complex I think. This also has the benefit that the code is
automatically analyzed by our CI tools.

https://github.com/systemd/systemd/pulls

Moreover, please make sure to to read our coding style guidelines
here:

https://systemd.io/CODING_STYLE

Form a very brief glance it appears the code doesn't follow formatting
rules for example.

Thanks!

Lennart

--
Lennart Poettering, Berlin


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

Re: [systemd-devel] interacting with logind to detect user idle time

[Germano Massullo]

To do practise I am using NetworkManager example [1]
All macros passed as arguments to functions
g_dbus_proxy_call_sync
g_dbus_proxy_new_for_bus_sync
are implemented at [2].
Is there an equivalent of [2] for logind? I made a quick search into
systemd repository [3] but I am getting too many results with the
search words I am using. I just need to figure out what parameters I
have to pass to the previous functions in order to retrieve
IdleSinceHint property

Thank you for your time

[1]: 
https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/examples/C/glib/list-connections-gdbus.c
[2]: 
https://github.com/NetworkManager/NetworkManager/blob/master/libnm-core/nm-dbus-interface.h
[3]: https://github.com/systemd/systemd
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 6/6] pstore: The new documentation for the pstore configuration file

[systemd github import bot]

Patchset imported to github.
To create a pull request, one of the main developers has to initiate one via:


--
Generated by https://github.com/haraldh/mail2git
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Schedule reboot in *.service file

[Mike Gilbert]

On Thu, May 16, 2019 at 4:50 AM Lennart Poettering
 wrote:
>
> On Mi, 15.05.19 15:53, Jeffrey Walton (noloa...@gmail.com) wrote:
>
> > if [[ "$NEEDS_REBOOT" -eq 1 ]]
> > then
> > echo "Scheduling reboot in 10 minutes"
> > reboot -r 10
>
> This syntax is not understood by systemd:
>
> https://www.freedesktop.org/software/systemd/man/reboot.html#
>
> If you want to schedule some command to be invoked at some future time, use:
>
> systemd-run --on-active=10s echo "Hello World"

Another option would be to use "shutdown -r +10", which systemctl does
understand. This will schedule a reboot via systemd-logind.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH 0/6] pstore: Tool to archive contents of pstore upon boot/shutdown

[Lennart Poettering]

On Do, 16.05.19 09:28, Eric DeVolder (eric.devol...@oracle.com) wrote:

Could you please submit this via github as PR? Review is so much nicer
there, in particular for complex patch sets, and this qualifies as
complex I think. This also has the benefit that the code is
automatically analyzed by our CI tools.

https://github.com/systemd/systemd/pulls

Moreover, please make sure to to read our coding style guidelines
here:

https://systemd.io/CODING_STYLE

Form a very brief glance it appears the code doesn't follow formatting
rules for example.

Thanks!

Lennart

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

[systemd-devel] [PATCH 0/6] pstore: Tool to archive contents of pstore upon boot/shutdown

[Eric DeVolder]

This patch introduces the systemd pstore service which will archive the
contents of the Linux persistent storage filesystem, pstore, to other storage,
thus preserving the existing information contained in the pstore, and clearing
pstore storage for future error events.

Linux provides a persistent storage file system, pstore[1], that can store
error records when the kernel dies (or reboots or powers-off). These records in
turn can be referenced to debug kernel problems (currently the kernel stuffs
the tail of the dmesg, which also contains a stack backtrace, into pstore).

The pstore file system supports a variety of backends that map onto persistent
storage, such as the ACPI ERST[2, Section 18.5 Error Serialization] and UEFI
variables[3 Appendix N Common Platform Error Record]. The pstore backends
typically offer a relatively small amount of persistent storage, e.g. 64KiB,
which can quickly fill up and thus prevent subsequent kernel crashes from
recording errors. Thus there is a need to monitor and extract the pstore
contents so that future kernel problems can also record information in the
pstore.

The pstore service is independent of the kdump service. In cloud environments
specifically, host and guest filesystems are on remote filesystems (eg. iSCSI
or NFS), thus kdump relies [implicitly and/or explicitly] upon proper operation
of networking software *and* hardware *and* infrastructure.  Thus it may not be
possible to capture a kernel coredump to a file since writes over the network
may not be possible.

The pstore backend, on the other hand, is completely local and provides a path
to store error records which will survive a reboot and aid in post-mortem
debugging.

Usage Notes:
To enable kernel recording of error records into pstore, one must either pass
crash_kexec_post_notifiers[4] to the kernel command line or enable via 'echo Y
> /sys/module/kernel/parameters/crash_kexec_post_notifiers'. This option
invokes the recording of errors into pstore *before* an attempt to kexec/kdump
on a kernel crash.

Optionally, to record reboots and shutdowns in the pstore, one can either pass
the printk.always_kmsg_dump[4] to the kernel command line or enable via 'echo Y 
>
/sys/module/printk/parameters/always_kmsg_dump'. This option enables code on the
shutdown path to record information via pstore.

This pstore service is a oneshot service. When run, the service invokes
systemd-pstore which is a tool that performs the following:
 - reads the pstore.conf configuration file
 - lists the files in the pstore (eg. /sys/fs/pstore)
 - for each file, locates a handler for the type of file (eg. dmesg, MCE, etc)
 - invokes the handler for the file (eg. the handler appends file to a list)
 - when the list of files is exhausted, all handlers are notified; in the case
   of the dmesg handler, final processing of the files occurs:
   - files sorted in reverse lexigraphical order to faciliate reconstruction
 of original dmesg
   - the filename is examined to determine which dmesg it is a part
   - the file is either moved to archive storage or recorded in the journal
   - the file is appended to the reconstructed dmesg

For example, the following pstore contents:

 root@vm356:~# ls -al /sys/fs/pstore
 total 0
 drwxr-x--- 2 root root0 May  9 09:50 .
 drwxr-xr-x 7 root root0 May  9 09:50 ..
 -r--r--r-- 1 root root 1610 May  9 09:49 dmesg-efi-155741337601001
 -r--r--r-- 1 root root 1778 May  9 09:49 dmesg-efi-155741337602001
 -r--r--r-- 1 root root 1726 May  9 09:49 dmesg-efi-155741337603001
 -r--r--r-- 1 root root 1746 May  9 09:49 dmesg-efi-155741337604001
 -r--r--r-- 1 root root 1686 May  9 09:49 dmesg-efi-155741337605001
 -r--r--r-- 1 root root 1690 May  9 09:49 dmesg-efi-155741337606001
 -r--r--r-- 1 root root 1775 May  9 09:49 dmesg-efi-155741337607001
 -r--r--r-- 1 root root 1811 May  9 09:49 dmesg-efi-155741337608001
 -r--r--r-- 1 root root 1817 May  9 09:49 dmesg-efi-155741337609001
 -r--r--r-- 1 root root 1795 May  9 09:49 dmesg-efi-155741337710001
 -r--r--r-- 1 root root 1770 May  9 09:49 dmesg-efi-155741337711001
 -r--r--r-- 1 root root 1796 May  9 09:49 dmesg-efi-155741337712001
 -r--r--r-- 1 root root 1787 May  9 09:49 dmesg-efi-155741337713001
 -r--r--r-- 1 root root 1808 May  9 09:49 dmesg-efi-155741337714001
 -r--r--r-- 1 root root 1754 May  9 09:49 dmesg-efi-155741337715001

results in the following:

 root@vm356:~# ls -al /var/lib/systemd/pstore/155741337/
 total 92
 drwxr-xr-x 2 root root  4096 May  9 09:50 .
 drwxr-xr-x 4 root root40 May  9 09:50 ..
 -rw-r--r-- 1 root root  1610 May  9 09:50 dmesg-efi-155741337601001
 -rw-r--r-- 1 root root  1778 May  9 09:50 dmesg-efi-155741337602001
 -rw-r--r-- 1 root root  1726 May  9 09:50 dmesg-efi-155741337603001
 -rw-r--r-- 1 root root  1746 May  9 09:50 dmesg-efi-155741337604001
 -rw-r--r-- 1 root root  1686 May  9 09:50 dmesg-efi-155741337605001
 -rw-r--r-- 1 root root  1690 May  9 09:50 dmesg-efi-155741337606001
 -rw-r--r-- 1 root root  1775 May  9 09:

[systemd-devel] [PATCH 4/6] pstore: The new configuration file for systemd-pstore tool

[Eric DeVolder]

The pstore.conf configuration file has four settings, described below.
 - Storage : one of "none", "archive", or "journal". With "none", this
   tool leaves the contents of pstore untouched. With "archive", the
   contents of the pstore are moved into the ArchiveDir. With "journal",
   the contents of the pstore are recorded in the systemd journal. The
   default is "archive".
 - SourceDir : contains a path to the pstore. The default is
   "/sys/fs/pstore".
 - ArchiveDir : contains a path to archive pstore contents. The default
   is "/var/lib/systemd/pstore".
 - AllowUnlink : is one of "yes" or "no". When "yes", the default, then
   files in the pstore are removed once processed. When "no", processing
   of the pstore occurs normally, but the pstore files remain.

Signed-off-by: Eric DeVolder 
---
 src/pstore/pstore.conf | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 src/pstore/pstore.conf

diff --git a/src/pstore/pstore.conf b/src/pstore/pstore.conf
new file mode 100644
index 000..985a953
--- /dev/null
+++ b/src/pstore/pstore.conf
@@ -0,0 +1,19 @@
+#  This file is part of systemd.
+#
+#  systemd is free software; you can redistribute it and/or modify it
+#  under the terms of the GNU Lesser General Public License as published by
+#  the Free Software Foundation; either version 2.1 of the License, or
+#  (at your option) any later version.
+#
+# Entries in this file show the compile time defaults.
+# You can change settings by editing this file.
+# Defaults can be restored by simply deleting this file.
+#
+# See pstore.conf(5) for details.
+
+[Pstore]
+#Storage=archive
+#SourceDir=/sys/fs/pstore
+#ArchiveDir=/var/lib/systemd/pstore
+#AllowUnlink=yes
+
-- 
2.7.4

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

[systemd-devel] [PATCH 3/6] pstore: The new systemd-pstore tool to archive pstore contents

[Eric DeVolder]

The systemd-pstore which is a tool that performs the following:
 - reads the pstore.conf configuration file
 - lists the files in the pstore (eg. /sys/fs/pstore)
 - for each file, locates a handler for the type of file (eg. dmesg, MCE, etc)
 - invokes the handler for the file (eg. the handler appends file to a list)
 - when the list of files is exhausted, all handlers are notified; in the case
   of the dmesg handler, final processing of the files occurs:
   - files sorted in reverse lexigraphical order to faciliate reconstruction
 of original dmesg
   - the filename is examined to determine which dmesg it is a part
   - the file is either moved to archive storage or recorded in the journal
   - the file is appended to the reconstructed dmesg

Signed-off-by: Eric DeVolder 
---
 src/pstore/pstore.c | 736 
 1 file changed, 736 insertions(+)
 create mode 100644 src/pstore/pstore.c

diff --git a/src/pstore/pstore.c b/src/pstore/pstore.c
new file mode 100644
index 000..f2e9845
--- /dev/null
+++ b/src/pstore/pstore.c
@@ -0,0 +1,736 @@
+/* SPDX-License-Identifier: LGPL-2.1+ */
+
+/*
+ * Generally speaking, the pstore contains a small number of files
+ * that in turn contain a small amount of data.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "sd-daemon.h"
+#include "sd-journal.h"
+#include "sd-login.h"
+#include "sd-messages.h"
+
+#include "acl-util.h"
+#include "alloc-util.h"
+#include "capability-util.h"
+#include "cgroup-util.h"
+#include "compress.h"
+#include "conf-parser.h"
+#include "copy.h"
+#include "dirent-util.h"
+#include "escape.h"
+#include "fd-util.h"
+#include "fileio.h"
+#include "fs-util.h"
+#include "io-util.h"
+#include "journal-importer.h"
+#include "log.h"
+#include "macro.h"
+#include "main-func.h"
+#include "missing.h"
+#include "mkdir.h"
+#include "parse-util.h"
+#include "process-util.h"
+#include "signal-util.h"
+#include "socket-util.h"
+#include "special.h"
+#include "string-table.h"
+#include "string-util.h"
+#include "strv.h"
+#include "tmpfile-util.h"
+#include "user-util.h"
+#include "util.h"
+
+#define ARRAY_SIZE(ARRAY) (sizeof(ARRAY)/sizeof(ARRAY[0]))
+
+#define PATHSZ 1024
+#define ARG_SOURCEDIR_DEFAULT "/sys/fs/pstore"
+#define ARG_ARCHIVEDIR_DEFAULT "/var/lib/systemd/pstore"
+
+/*
+ * Command line argument handling
+ */
+typedef enum PstoreStorage {
+PSTORE_STORAGE_NONE,
+PSTORE_STORAGE_ARCHIVE,
+PSTORE_STORAGE_JOURNAL,
+_PSTORE_STORAGE_MAX,
+_PSTORE_STORAGE_INVALID = -1
+} PstoreStorage;
+
+static const char* const pstore_storage_table[_PSTORE_STORAGE_MAX] = {
+[PSTORE_STORAGE_NONE] = "none",
+[PSTORE_STORAGE_ARCHIVE] = "archive",
+[PSTORE_STORAGE_JOURNAL] = "journal",
+};
+
+DEFINE_PRIVATE_STRING_TABLE_LOOKUP(pstore_storage, PstoreStorage);
+static DEFINE_CONFIG_PARSE_ENUM(config_parse_pstore_storage, pstore_storage, 
PstoreStorage, "Failed to parse storage setting");
+
+static PstoreStorage arg_storage = PSTORE_STORAGE_ARCHIVE;
+
+static bool arg_allowunlink = true;
+static char *arg_sourcedir = NULL;
+static char *arg_archivedir = NULL;
+STATIC_DESTRUCTOR_REGISTER(arg_sourcedir, freep);
+STATIC_DESTRUCTOR_REGISTER(arg_archivedir, freep);
+
+static int parse_config(void) {
+int rc;
+static const ConfigTableItem items[] = {
+{ "Pstore", "AllowUnlink",  config_parse_bool,  0, 
&arg_allowunlink },
+{ "Pstore", "Storage",  config_parse_pstore_storage,0, 
&arg_storage },
+{ "Pstore", "SourceDir",config_parse_path,  0, 
&arg_sourcedir   },
+{ "Pstore", "ArchiveDir",   config_parse_path,  0, 
&arg_archivedir  },
+{}
+};
+
+rc = config_parse_many_nulstr(PKGSYSCONFDIR "/pstore.conf",
+CONF_PATHS_NULSTR("systemd/pstore.conf.d"),
+"Pstore\0",
+config_item_table_lookup, items,
+CONFIG_PARSE_WARN, NULL);
+if (NULL == arg_sourcedir)
+{
+arg_sourcedir = (char *)malloc(sizeof(ARG_SOURCEDIR_DEFAULT)+1);
+if (NULL != arg_sourcedir)
+strcpy(arg_sourcedir, ARG_SOURCEDIR_DEFAULT);
+}
+if (NULL == arg_archivedir)
+{
+arg_archivedir = (char *)malloc(sizeof(ARG_ARCHIVEDIR_DEFAULT)+1);
+if (NULL != arg_archivedir)
+strcpy(arg_archivedir, ARG_ARCHIVEDIR_DEFAULT);
+}
+return rc;
+}
+
+/*
+ * File list handling
+ */
+typedef struct dirent_cs
+{
+struct dirent de;
+struct stat statbuf;
+int is_binary;
+char *contents;
+struct dirent_cs *next;
+struct dirent_cs *prev;
+} dirent_ct;
+
+#define END_OF_DIRENT_LIST(LIST, DC) ((DC)->next == (LIST))
+#define START_OF_DIRENT_LIST(LIST, DC) ((DC) == (LIST))
+
+#define FOR_EACH_DIRENT_IN_LIST(LIST, VAR) \
+for

[systemd-devel] [PATCH 2/6] pstore: Add new pstore tool/service to the build

[Eric DeVolder]

This new file is invoked by the build system to build pstore.

Signed-off-by: Eric DeVolder 
---
 src/pstore/meson.build | 21 +
 1 file changed, 21 insertions(+)
 create mode 100644 src/pstore/meson.build

diff --git a/src/pstore/meson.build b/src/pstore/meson.build
new file mode 100644
index 000..911eb0f
--- /dev/null
+++ b/src/pstore/meson.build
@@ -0,0 +1,21 @@
+# SPDX-License-Identifier: LGPL-2.1+
+
+systemd_pstore_sources = files('''
+pstore.c
+'''.split())
+
+#pstorectl_sources = files('pstorectl.c')
+
+if conf.get('ENABLE_PSTORE') == 1
+install_data('pstore.conf',
+ install_dir : pkgsysconfdir)
+endif
+
+#tests += [
+#[['src/pstore/test-pstore.c',
+#  'src/pstore/pstore.c',
+#  'src/pstore/pstore.h'],
+# [],
+# [],
+# 'ENABLE_PSTORE', 'manual'],
+#]
-- 
2.7.4

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

[systemd-devel] [PATCH 6/6] pstore: The new documentation for the pstore configuration file

[Eric DeVolder]

The xml file for the systemd pstore tool configuration file.

Signed-off-by: Eric DeVolder 
---
 man/pstore.conf.xml | 100 
 1 file changed, 100 insertions(+)
 create mode 100644 man/pstore.conf.xml

diff --git a/man/pstore.conf.xml b/man/pstore.conf.xml
new file mode 100644
index 000..307727a
--- /dev/null
+++ b/man/pstore.conf.xml
@@ -0,0 +1,100 @@
+
+http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd";>
+
+
+http://www.w3.org/2001/XInclude";>
+  
+pstore.conf
+systemd
+  
+
+  
+pstore.conf
+5
+  
+
+  
+pstore.conf
+Pstore configuration file
+  
+
+  
+/etc/systemd/pstore.conf
+  
+
+  
+Description
+
+This file configures the behavior of
+
systemd-pstore8,
+a handler for archiving the contents of the persistent storage filesystem, 
pstore.
+
+  
+
+  
+
+  
+Options
+
+All options are configured in the
+[Pstore] section:
+
+
+
+  
+Storage=
+
+Controls where to archive files in the pstore 
filesystem. One of none,
+archive, and journal. When
+none, the files in pstore are untouched. When 
archive (the
+default), files are archived in 
/var/lib/systemd/pstore/.
+When journal, pstore file contents are recorded in 
the journal.
+
+
+  
+
+  
+SourceDir=
+
+Specifies the path to the persistent storage 
filesystem.
+The default location is /sys/fs/pstore.
+
+  
+
+  
+ArchiveDir=
+
+Specifies the path where pstore files are to be 
archived, when
+Storage is archive.
+
+  
+
+  
+AllowUnlink=
+
+Controls whether or not pstore files are removed. One 
of
+yes or no. When 
yes,
+a pstore file is removed from the pstore once it has been archived 
(either to
+disk or into the journal). When no, processing of 
pstore files
+occurs normally, but the files remain in the pstore.
+The default is yes in order to maintain the pstore 
in a
+nearly empty state, so that it has storage available for the next 
kernel error event.
+
+  
+
+
+The defaults for all values are listed as comments in the
+template /etc/systemd/pstore.conf file that
+is installed by default.
+  
+
+  
+See Also
+
+  
systemd-journald.service8,
+
+  
+
+
-- 
2.7.4

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

[systemd-devel] [PATCH 5/6] pstore: The new pstore archive service file

[Eric DeVolder]

The necessary systemd service file which invokes the pstore
archival tool upon boot as well as shutdown (poweroff, reboot).

Signed-off-by: Eric DeVolder 
---
 units/systemd-pstore.service.in | 32 
 1 file changed, 32 insertions(+)
 create mode 100644 units/systemd-pstore.service.in

diff --git a/units/systemd-pstore.service.in b/units/systemd-pstore.service.in
new file mode 100644
index 000..4672d81
--- /dev/null
+++ b/units/systemd-pstore.service.in
@@ -0,0 +1,32 @@
+#  SPDX-License-Identifier: LGPL-2.1+
+#
+#  This file is part of systemd.
+#
+#  systemd is free software; you can redistribute it and/or modify it
+#  under the terms of the GNU Lesser General Public License as published by
+#  the Free Software Foundation; either version 2.1 of the License, or
+#  (at your option) any later version.
+
+[Unit]
+Description=Pstore archive service
+#Documentation=man:systemd-pstore(8)
+#DefaultDependencies=no
+#Conflicts=shutdown.target
+#After=systemd-remount-fs.service systemd-journald.socket
+#Requires=systemd-journald.socket
+#Before=shutdown.target
+Wants=network-online.target local-fs.target remote-fs.target
+After=network-online.target local-fs.target
+
+[Service]
+Type=oneshot
+StandardOutput=syslog+console
+#EnvironmentFile=/etc/default/kdump-tools
+ExecStart=/usr/lib/systemd/systemd-pstore start
+ExecStop=/usr/lib/systemd/systemd-pstore stop
+RemainAfterExit=no
+
+[Install]
+#WantedBy=multi-user.target
+WantedBy=local-fs.target
+
-- 
2.7.4

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

[systemd-devel] [PATCH 1/6] pstore: Add new pstore tool/service to the build

[Eric DeVolder]

This change adds the src/pstore directory to the build files.

Signed-off-by: Eric DeVolder 
---
 meson.build   | 29 +
 meson_options.txt |  2 ++
 units/meson.build |  1 +
 3 files changed, 32 insertions(+)

diff --git a/meson.build b/meson.build
index eaf0edd..4a9ebc1 100644
--- a/meson.build
+++ b/meson.build
@@ -1258,6 +1258,7 @@ foreach term : ['utmp',
 'environment-d',
 'binfmt',
 'coredump',
+'pstore',
 'resolve',
 'logind',
 'hostnamed',
@@ -1469,6 +1470,7 @@ subdir('src/network')
 subdir('src/analyze')
 subdir('src/journal-remote')
 subdir('src/coredump')
+subdir('src/pstore')
 subdir('src/hostname')
 subdir('src/import')
 subdir('src/kernel-install')
@@ -2240,6 +2242,32 @@ if conf.get('ENABLE_COREDUMP') == 1
 public_programs += exe
 endif
 
+if conf.get('ENABLE_PSTORE') == 1
+executable('systemd-pstore',
+   systemd_pstore_sources,
+   include_directories : includes,
+   link_with : [libshared],
+   dependencies : [threads,
+   libacl,
+   libdw,
+   libxz,
+   liblz4],
+   install_rpath : rootlibexecdir,
+   install : true,
+   install_dir : rootlibexecdir)
+
+#   exe = executable('pstorectl',
+#pstorectl_sources,
+#include_directories : includes,
+#link_with : [libshared],
+#dependencies : [threads,
+#libxz,
+#liblz4],
+#install_rpath : rootlibexecdir,
+#install : true)
+public_programs += exe
+endif
+
 if conf.get('ENABLE_BINFMT') == 1
 exe = executable('systemd-binfmt',
  'src/binfmt/binfmt.c',
@@ -3143,6 +3171,7 @@ foreach tuple : [
 ['DNS-over-TLS(gnutls)',  conf.get('DNS_OVER_TLS_USE_GNUTLS') == 1],
 ['DNS-over-TLS(openssl)', conf.get('DNS_OVER_TLS_USE_OPENSSL') == 1],
 ['coredump'],
+['pstore'],
 ['polkit'],
 ['legacy pkla',  install_polkit_pkla],
 ['efi'],
diff --git a/meson_options.txt b/meson_options.txt
index c1cb461..564250a 100644
--- a/meson_options.txt
+++ b/meson_options.txt
@@ -79,6 +79,8 @@ option('binfmt', type : 'boolean',
description : 'support for custom binary formats')
 option('coredump', type : 'boolean',
description : 'install the coredump handler')
+option('pstore', type : 'boolean',
+   description : 'install the pstore handler')
 option('logind', type : 'boolean',
description : 'install the systemd-logind stack')
 option('hostnamed', type : 'boolean',
diff --git a/units/meson.build b/units/meson.build
index a561050..3365e8d 100644
--- a/units/meson.build
+++ b/units/meson.build
@@ -136,6 +136,7 @@ in_units = [
 ['systemd-bless-boot.service',   'ENABLE_EFI HAVE_BLKID'],
 ['systemd-boot-check-no-failures.service', ''],
 ['systemd-coredump@.service','ENABLE_COREDUMP'],
+['systemd-pstore.service',   'ENABLE_PSTORE'],
 ['systemd-firstboot.service','ENABLE_FIRSTBOOT',
  'sysinit.target.wants/'],
 ['systemd-fsck-root.service',''],
-- 
2.7.4

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

Re: [systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?

[Lennart Poettering]

On Do, 16.05.19 12:04, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> > This is explained in the documentation btw:
> > https://www.freedesktop.org/software/systemd/man/systemd.generator.html
> >
> > Long story short: it's about unit file precedence.
>
> Sorry I don't get it: So the idea is to have different generators, depending
> on the precedence?

No. As explained in the documentation: sometimes you want to generate
dynamic unit files that override the regular unit files (think:
overriding the boot target the system shall boot into). Sometimes you
want that regular unit files override the dynamic ones (think: you
automaticlly convert sysv scripts to native unit files, but if a
regular unit file already exists for a service you want that to take
precedence, since native should be better than converted).

All generators are run at the same time btw, there's no ordering
between them.

> >> How should it know? Wouldn't it be easier to provide one path and
> >> adjust that as necessary? (My generator just uses the first path)
> >
> > It's up to the generator to decide whether it wants to override native
> > unit files already in place, or whether it wants those to override
> > whatever it generates.
>
> OK, so different generators.

Nope, please read the documentation. it's very clearly explained
there. It's about precendence relative to installed regular unit files.

> > Please read up on the documentation.
>
> Actually I have read it multiple times, but still is's not very
> helpful.

Sorry, but it doesn't appear like you did...

> Is calling the generators logged (and maybe finishing the last generator,
> too)? After boot I could not find a journal message regarding that.

Turn on debug logging, and it is. i.e. add systemd.log_level=debug to
the kernel command line.

> > Doing "systemctl daemon‑reload" in clean codepaths is possible but not
> > good style. It's slow and problematic since Linux doesn't really have
> > a transactional fs, and thus you never know in which precise state the
> > fs is when systemd reloads things in case multiple programs make
> > modifications to the unit files at the same time.
>
> So what is the preferred method when some package install adds new
> unit files?  systemctl daemon-reload?

Yes. That's the command to invoke whenever you remove or drop in unit
files into the directories in /usr/lib/systemd/system or
/etc/systemd/system or similar.

> >> What makes your generators special? That they have no explicitly
> >> settable dependencies, or that they are called with three directory
> >> arguments?
> >
> > I am not sure how to parse that.
>
> You claim the generators are very special, but I don't get
> it. Sorry.

They run in an early boot environment outside of any service
management, snce they generate service definitions. That makes them
kinda special. See the long list of dos/donts in the documentation.

https://www.freedesktop.org/software/systemd/man/systemd.generator.html

> > As I mentioned before: you appear to think that generators are
> > something they are clearly not.
>
> And you seem unable to explain why they are not what I thing they
> are.

I am sorry, but this gets on my nerves. Yes, our documentation is not
perfect (which documentation is?) but you appear unable to read even
the most basic parts of it, since most of what you are asking is
actually documented in the various linked docs.

Please, when you are new to systemd, start with the simple things
first, and as you grokked them continue with the more complex
stuff. You are jumping to the advanced stuff from zero apparently,
without understanding the basic concepts the advanced stuff builds
on. Of course things are going to be frustrating if you do that, but
maybe the fix to that is starting to reading up on the basics first!

You receieved an awful lot of free help here even though when you came
onto the mailing list you started out with telling evreyone how awful
systemd is. You are using up all my patience slowly but surely, and if
you continue like that you'll notice the responses you get will be
fewer and fewer.

> And what creates those dependency links and when? It's OK to point me to the
> correct manual page.

For units installed via packages in /usr/lib/systemd/system or by the
user in /etc/systemd/system these links are created by "systemctl
enable". You can also create them maualy if you like, that's fine.

That maps 1:1: how tools such as update-rc.d or chkconfig did things
on the various distros back in sysvinit times.

If you write a generator then its the generator that creates the
symlinks. But again, generators are an advanced topic, and you
shouldn't use them unless you really really know what you are doing.

https://www.freedesktop.org/software/systemd/man/systemctl.html#enable%20UNIT%E2%80%A6

> > the right places. systemctl can't guess that. I mean, if a service
>
> So "link messing"; it's the ugly part of systemd.

What's so hard about using "systemctl enable"? I mea

Re: [systemd-devel] Antw: Re: Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?

[Reindl Harald]

Am 16.05.19 um 12:41 schrieb Ulrich Windl:
>> Please, this is just wasting everyone's time. Take the advice that
>> Reindl gave you: generators are an advanced tool that you don't need
>> when staring with systemd.
> 
> Yes systemd is for you developers, not for developers like me. Your're the
> geniuses, and I'm the fool... I'll stop this thread here, because it's also
> wasting MY time.

when you start using systemd and take the most complexest things as your
start before you even understand everything else around it and then
expect that you just have to write enough emails saving you all the
years from expierience others something goes wrong

generators AFAIK where implemented years after we used systemd in
production or at least the transition of /etc/fstab to a generated unit
was done at that time in point

So what is the preferred method when some package install adds new  unit
files? systemctl daemon-reload?
on sane distributions solved years ago like
https://bugzilla.redhat.com/show_bug.cgi?id=850355 and in the meatime a
ton of rpm scriptlets are replaced with file-triggers at least on Fedora


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

[systemd-devel] Antw: Re: Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?

[Ulrich Windl]

>>> Zbigniew Jedrzejewski-Szmek  schrieb am 16.05.2019 um
12:13
in Nachricht <20190516101348.gn9...@in.waw.pl>:
> On Thu, May 16, 2019 at 12:04:28PM +0200, Ulrich Windl wrote:
>> >>> Lennart Poettering  schrieb am 16.05.2019 um
10:29
>> in
>> Nachricht <20190516082910.GA24042@gardel-login>:
>> > On Do, 16.05.19 08:55, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
>> wrote:
>> > 
>> >> Hi!
>> >>
>> >> After having read the page again, it's not more clear than
>> >> before. Even I have some more questions:
>> >>
>> >> Why do generators receive three directory paths: Should the
>> >> generator decide where at those three paths to add a unit?
>> > 
>> > Yes.
>> > 
>> > This is explained in the documentation btw:
>> > https://www.freedesktop.org/software/systemd/man/systemd.generator.html 
>> > 
>> > Long story short: it's about unit file precedence.
>> 
>> Sorry I don't get it: So the idea is to have different generators,
depending
>> on the precedence?
> 
> Please, this is just wasting everyone's time. Take the advice that
> Reindl gave you: generators are an advanced tool that you don't need
> when staring with systemd.

Yes systemd is for you developers, not for developers like me. Your're the
geniuses, and I'm the fool... I'll stop this thread here, because it's also
wasting MY time.

> 
> Zbyszek



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

Re: [systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?

[Zbigniew Jędrzejewski-Szmek]

On Thu, May 16, 2019 at 12:04:28PM +0200, Ulrich Windl wrote:
> >>> Lennart Poettering  schrieb am 16.05.2019 um 10:29
> in
> Nachricht <20190516082910.GA24042@gardel-login>:
> > On Do, 16.05.19 08:55, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
> wrote:
> > 
> >> Hi!
> >>
> >> After having read the page again, it's not more clear than
> >> before. Even I have some more questions:
> >>
> >> Why do generators receive three directory paths: Should the
> >> generator decide where at those three paths to add a unit?
> > 
> > Yes.
> > 
> > This is explained in the documentation btw:
> > https://www.freedesktop.org/software/systemd/man/systemd.generator.html 
> > 
> > Long story short: it's about unit file precedence.
> 
> Sorry I don't get it: So the idea is to have different generators, depending
> on the precedence?

Please, this is just wasting everyone's time. Take the advice that
Reindl gave you: generators are an advanced tool that you don't need
when staring with systemd.

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

Re: [systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?

[Ulrich Windl]

>>> Lennart Poettering  schrieb am 16.05.2019 um 10:29
in
Nachricht <20190516082910.GA24042@gardel-login>:
> On Do, 16.05.19 08:55, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
wrote:
> 
>> Hi!
>>
>> After having read the page again, it's not more clear than
>> before. Even I have some more questions:
>>
>> Why do generators receive three directory paths: Should the
>> generator decide where at those three paths to add a unit?
> 
> Yes.
> 
> This is explained in the documentation btw:
> https://www.freedesktop.org/software/systemd/man/systemd.generator.html 
> 
> Long story short: it's about unit file precedence.

Sorry I don't get it: So the idea is to have different generators, depending
on the precedence?

> 
>> How should it know? Wouldn't it be easier to provide one path and
>> adjust that as necessary? (My generator just uses the first path)
> 
> It's up to the generator to decide whether it wants to override native
> unit files already in place, or whether it wants those to override
> whatever it generates.

OK, so different generators.

> 
> Please read up on the documentation.

Actually I have read it multiple times, but still is's not very helpful.

> 
>> Also: the only thing that might prevent using a generator for
>> dynamic configuration is that it is called early during boot.
> 
> Generators follow the reload cycle, and the reload cycle is how the
> reload cycle is.

Is calling the generators logged (and maybe finishing the last generator,
too)? After boot I could not find a journal message regarding that.

> 
>> So I could have a generator that just saved the three paths
>> somewhere, and a unit that calls "another generator" that is not
>> detected as a systemd generator using the paths saved before to
>> generate the unit files and do a "systemctl reload‑daemon" (watching
>> out for possible indirect recursion). But why the dance?
> 
> Doing "systemctl daemon‑reload" in clean codepaths is possible but not
> good style. It's slow and problematic since Linux doesn't really have
> a transactional fs, and thus you never know in which precise state the
> fs is when systemd reloads things in case multiple programs make
> modifications to the unit files at the same time.

So what is the preferred method when some package install adds new unit files?
systemctl daemon-reload?

> 
>> What makes your generators special? That they have no explicitly
>> settable dependencies, or that they are called with three directory
>> arguments?
> 
> I am not sure how to parse that.

You claim the generators are very special, but I don't get it. Sorry.

> 
> As I mentioned before: you appear to think that generators are
> something they are clearly not.

And you seem unable to explain why they are not what I thing they are.

> 
>> And what about the "link stuff": Doesn't reload‑daemon create those
>> as needed from the unit files? Why should the generator have to mess
>> with those? It's all not clear from the manual page. The only thing
>> I can imagine is that those "link messing" is needed to provide
>> functionality the systemd actually lacks.
> 
> daemon‑reload just reloads configuation, it does not create or remove
> any symlinks.

And what creates those dependency links and when? It's OK to point me to the
correct manual page.

> 
> It's your generator's job to hook the units it might generate into
> the right places. systemctl can't guess that. I mean, if a service

So "link messing"; it's the ugly part of systemd.

> shall be started during regular boot, or if it shall be hooked into
> getty.target or when bluetooth hw is plugged in is nothing systemd can
> guess for you.

Isn't it sufficient when a generated unit contains "Wants=" or similar? If I
have to mess with links, why does "Wants=" exist at all? Maybe its all
historical, I don't know.

Regards,
Ulrich Windl

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

Re: [systemd-devel] Stop systemd timer upon success script and restart the next day

[Lennart Poettering]

On Mi, 15.05.19 16:21, Jeffrey Walton (noloa...@gmail.com) wrote:

> I have a systemd timer that starts a service, and the service executes
> a script that downloads data files once a day. Once the data files are
> retrieved I don't need the timer for the remainder of the day.
> However, I need the time again the next day.
>
> Here are the two docs I found on scheduling a timer, but I was not
> able to parse out the info I needed.
> https://www.freedesktop.org/software/systemd/man/systemd.timer.html
> and https://www.freedesktop.org/software/systemd/man/systemd.time.html
>
> How do I specify a timer that starts 6:00 AM every morning, fires once
> an hour, and then stops for the day upon success of the download?

define two timer units and one service:

1. six-o-clock.timer with contents like this:

[Timer]
OnCalendar=6:00
Unit=myapp.service

[Install]
WantedBy=timers.target

2. every-hour.timer with contents like this:

[Timer]
OnUnitActive=1h
Unit=myapp.service

[Install]
Also=six-o-clock.timer

3. myapp.service with contents like this:

[Unit]
Wants=every-hour.timer
After=every-hour.timer

[Service]
ExecStart=/path/to/my/script.sh

[Install]
Also=six-o-clock.timer

4. Inside your script script.sh you should then do your downloads. If
   anything fails you just let the script abort, knowing that
   every-hour.timer will start it again after one hour. On success
   however, you invoke "systemctl stop every-hour.timer" to shut down
   this timer again, leaving only "six-o-clock.timer" running.

By using two separate timer units you can schedule the service based
on two separate expressions that you can turn off and on individually
just by starting or stopping the timer.

six-o-clock.timer is the timer started during boot (since after
enablement is pulled in by timers.target which is the generic target
timers should be plugged into if they shall be started at boot). Then,
every-hour.timer is pulled in together with myapp.service the instant
it is requested to ensure that from that point on the every hour thing
applies, until its turned off again because the timer is stopped by
your script.

Lennart

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

Re: [systemd-devel] Schedule reboot in *.service file

[Lennart Poettering]

On Mi, 15.05.19 15:53, Jeffrey Walton (noloa...@gmail.com) wrote:

> if [[ "$NEEDS_REBOOT" -eq 1 ]]
> then
> echo "Scheduling reboot in 10 minutes"
> reboot -r 10

This syntax is not understood by systemd:

https://www.freedesktop.org/software/systemd/man/reboot.html#

If you want to schedule some command to be invoked at some future time, use:

systemd-run --on-active=10s echo "Hello World"

Lennart

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

Re: [systemd-devel] Antw: Re: Antw: Re: Re: "bad" status for genersated target; why?

[Lennart Poettering]

On Do, 16.05.19 08:55, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> Hi!
>
> After having read the page again, it's not more clear than
> before. Even I have some more questions:
>
> Why do generators receive three directory paths: Should the
> generator decide where at those three paths to add a unit?

Yes.

This is explained in the documentation btw:
https://www.freedesktop.org/software/systemd/man/systemd.generator.html

Long story short: it's about unit file precedence.

> How should it know? Wouldn't it be easier to provide one path and
> adjust that as necessary? (My generator just uses the first path)

It's up to the generator to decide whether it wants to override native
unit files already in place, or whether it wants those to override
whatever it generates.

Please read up on the documentation.

> Also: the only thing that might prevent using a generator for
> dynamic configuration is that it is called early during boot.

Generators follow the reload cycle, and the reload cycle is how the
reload cycle is.

> So I could have a generator that just saved the three paths
> somewhere, and a unit that calls "another generator" that is not
> detected as a systemd generator using the paths saved before to
> generate the unit files and do a "systemctl reload-daemon" (watching
> out for possible indirect recursion). But why the dance?

Doing "systemctl daemon-reload" in clean codepaths is possible but not
good style. It's slow and problematic since Linux doesn't really have
a transactional fs, and thus you never know in which precise state the
fs is when systemd reloads things in case multiple programs make
modifications to the unit files at the same time.

> What makes your generators special? That they have no explicitly
> settable dependencies, or that they are called with three directory
> arguments?

I am not sure how to parse that.

As I mentioned before: you appear to think that generators are
something they are clearly not.

> And what about the "link stuff": Doesn't reload-daemon create those
> as needed from the unit files? Why should the generator have to mess
> with those? It's all not clear from the manual page. The only thing
> I can imagine is that those "link messing" is needed to provide
> functionality the systemd actually lacks.

daemon-reload just reloads configuation, it does not create or remove
any symlinks.

It's your generator's job to hook the units it might generate into
the right places. systemctl can't guess that. I mean, if a service
shall be started during regular boot, or if it shall be hooked into
getty.target or when bluetooth hw is plugged in is nothing systemd can
guess for you.

Lennart

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