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

2019-05-15 Thread Ulrich Windl
>>> Trent Piepho  schrieb am 15.05.2019 um 18:54 in 
>>> Nachricht
<1557939250.4229.111.ca...@impinj.com>:
> On Wed, 2019-05-15 at 10:03 +, systemd-devel-
> requ...@lists.freedesktop.org wrote:
>> 
>> 
>> If you are looking for a generic converter of foreign stuff into
>> classic, persistent systemd unit files, then generators is not what
>> you should be using. Generators are life-cycle bound to systemd
>> release cycles, and their output ceases to exist on every reload
>> boundary, and when the system is offline. If we'd allow generated
>> units to be installed that clear life-cycle would be very much
>> blurred, as suddenly you'd have configuration that hooks them into the
>> system that is more persistant than the actual definitions of the
>> units themselves, and that's just borked...
>> 
>> I mean, if you want to persistently enable a unit that is converted
>> from something else, then please write your own converted, and write
>> something to /etc/systemd/system, there's no need whatsoever to bother
>> systemd itself with that, you shouldn't use generators for that.
>> 
> 
> As an embedded Linux developer, I think there is an interesting idea
> here.
> 
> There are no admins on an embedded system and everything must be done
> through some automatic piece of software.  As soon I see, "edit a file
> in /etc," I know there's a problem I'll need to find a solution for
> because the normal way isn't going to work.

There's an important point you faul to understand:
The file in /etc is there not because of the _frequency_ of change, but for 
_ease_ of configuration.
It's much easier to write one line of text than to create or adjust systemd 
unit files, not to talk about the link mess.

> 
> Embedded likes read-only root filesystems.  We also like it if software
> image we create is immutable.  So copying /etc out of a read-only
> filesystem into a writable one isn't really a solution to the problems
> posed by a read-only rootfs, as it largely defeats the purpose of
> making the rootfs read-only in the first place.
> 
> I want the device configuration to be transactional.  I want it to be
> safe from power cycles as it's updated.  There should be roll-backs to
> previous configs, exporting configuration, importing it, pushing
> changes to a fleet of devices, automatic migration forward and backward
> across software versions.
> 
> This is hard to do with a pile of text files in /etc all in different
> formats and parsed by different software.

It's all a matter of taste. Different things belong to different files. And any 
attempt to enforce one super process that does everything is simply wrong (and 
against the spirit of UNIX).

> 
> I think of all the ways one might configure services locally.  Edit
> environment files read by units, edit the service files, etc.

Well, you can, but you need not.

> 
> What if I dynamically generated service files?  There's a lot that
> could be done that way.
> 
> I can sort of dynamically enable units by starting them over dbus.  But
>  that really only works after most of the boot is done.  What if I want
> to dynamically alter the CapabilityBoundingSet based on what features
> of a service are enabled?
> ___
> 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] Stop systemd timer upon success script and restart the next day

2019-05-15 Thread Mantas Mikulėnas
On Wed, May 15, 2019 at 11:21 PM Jeffrey Walton  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?
>

I think you only do "every hour 6:00 to XX:00" through systemd.timer and
the rest through script logic – simply make the script exit if it finds
today's data already having been downloaded.

-- 
Mantas Mikulėnas
___
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

2019-05-15 Thread Andrei Borzenkov
15.05.2019 23:21, Jeffrey Walton пишет:
> 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?

You do not. Timers are not aware what services they start do, nor are
they aware of "download success".

How expensive starting of service is that you need to prevent it?

I was about to suggest transient timers to simulate "at" command - your
service could schedule next run if necessary. It almost works (i.e. next
service invocation is scheduled) but it results in permanent:

мая 16 08:31:34 bor-Latitude-E5450 systemd-run[12618]: Failed to start
transient timer unit: Unit test-service.timer already exists.

For a proof of concept

[Service]
ExecStart=/bin/echo I am started
ExecStopPost=/usr/bin/systemd-run --no-block --user
--unit=test-service.service --on-unit-inactive=+5


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

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

2019-05-15 Thread Jeffrey Walton
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?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2019-05-15 Thread Jeffrey Walton
Hi Everyone,

I have a systemd timer that fires early in the morning. The timer
starts a systemd service, and the service checks for updates using the
package manager. If updates are found then they are applied. The
service runs fine and is shown below.

The tail of the service schedules a reboot of the machine at +10
minutes when updates are applied. The reboot clears a UI widget that
confuses my users and loads the latest components upon reboot.

The reboot is not happening. When I inspected the systemd logs I see
that it was supposed to happen. When I check the user's desktop that
damn useless UI widget is present nagging about installing updates.

How do I schedule a reboot using systemd service file?

Thanks in advance.

=

$ cat /etc/systemd/system/system-update.service
[Unit]
Description=Update the system once a day without user prompts

[Service]
Type=oneshot
ExecStart=/usr/sbin/system-update
Wants=system-update.timer

[Install]
WantedBy=system-update.target

=

$ cat /usr/sbin/system-update
#!/usr/bin/env bash

PATH=/sbin:/usr/sbin:/bin:/usr/bin

# Update the package lists
if apt-get update &>/dev/null
then
echo "Updated package list"
else
echo "Failed to update package list"
[[ "$0" = "${BASH_SOURCE[0]}" ]] && exit 1 || return 1
fi

# If no packages are upgradeable, then the message is "Listing... Done".
# Otherwise a package name is listed as upgradeable.
COUNT=$(apt list --upgradable 2>/dev/null | grep -v 'Listing' | wc -l)

# Only update and reboot if packages are available
if [[ "$COUNT" -gt 0 ]]
then
if apt-get dist-upgrade -y &>/dev/null
then
echo "Upgraded system"
else
echo "Failed to upgrade system"
[[ "$0" = "${BASH_SOURCE[0]}" ]] && exit 1 || return 1
fi

echo "Purging old packages"
apt autoremove --purge &>/dev/null

NEEDS_REBOOT=1
fi

if [[ -f /var/run/reboot-required ]]
then
NEEDS_REBOOT=1
fi

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

[[ "$0" = "${BASH_SOURCE[0]}" ]] && exit 0 || return 0

=

$ systemctl status system-update.service
? system-update.service - Update the system once a day without user prompts
   Loaded: loaded (/etc/systemd/system/system-update.service; enabled; vendor pr
   Active: inactive (dead) since Wed 2019-05-15 05:03:59 EDT; 10h ago
  Process: 17218 ExecStart=/usr/sbin/system-update (code=exited, status=0/SUCCES
 Main PID: 17218 (code=exited, status=0/SUCCESS)

May 15 05:01:28 qotom systemd[1]: Starting Update the system once a day without
May 15 05:01:34 qotom system-update[17218]: Updated package list
May 15 05:03:58 qotom system-update[17218]: Upgraded system
May 15 05:03:58 qotom system-update[17218]: Purging old packages
May 15 05:03:59 qotom system-update[17218]: Scheduling reboot in 10 minutes
May 15 05:03:59 qotom systemd[1]: Started Update the system once a day without u
___
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?

2019-05-15 Thread Trent Piepho
On Wed, 2019-05-15 at 10:03 +, systemd-devel-
requ...@lists.freedesktop.org wrote:
> 
> 
> If you are looking for a generic converter of foreign stuff into
> classic, persistent systemd unit files, then generators is not what
> you should be using. Generators are life-cycle bound to systemd
> release cycles, and their output ceases to exist on every reload
> boundary, and when the system is offline. If we'd allow generated
> units to be installed that clear life-cycle would be very much
> blurred, as suddenly you'd have configuration that hooks them into the
> system that is more persistant than the actual definitions of the
> units themselves, and that's just borked...
> 
> I mean, if you want to persistently enable a unit that is converted
> from something else, then please write your own converted, and write
> something to /etc/systemd/system, there's no need whatsoever to bother
> systemd itself with that, you shouldn't use generators for that.
> 

As an embedded Linux developer, I think there is an interesting idea
here.

There are no admins on an embedded system and everything must be done
through some automatic piece of software.  As soon I see, "edit a file
in /etc," I know there's a problem I'll need to find a solution for
because the normal way isn't going to work.

Embedded likes read-only root filesystems.  We also like it if software
image we create is immutable.  So copying /etc out of a read-only
filesystem into a writable one isn't really a solution to the problems
posed by a read-only rootfs, as it largely defeats the purpose of
making the rootfs read-only in the first place.

I want the device configuration to be transactional.  I want it to be
safe from power cycles as it's updated.  There should be roll-backs to
previous configs, exporting configuration, importing it, pushing
changes to a fleet of devices, automatic migration forward and backward
across software versions.

This is hard to do with a pile of text files in /etc all in different
formats and parsed by different software.

I think of all the ways one might configure services locally.  Edit
environment files read by units, edit the service files, etc.

What if I dynamically generated service files?  There's a lot that
could be done that way.

I can sort of dynamically enable units by starting them over dbus.  But
 that really only works after most of the boot is done.  What if I want
to dynamically alter the CapabilityBoundingSet based on what features
of a service are enabled?
___
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?

2019-05-15 Thread Reindl Harald


Am 15.05.19 um 13:12 schrieb Ulrich Windl:
>> Well, there can always be more examples, but "generators" are
>> inherently an advanced concept: if you are writing a generator, then
>> you already should be pro enough to be able to consult the sources of
>> the various generators shipped with systemd.
>>
>> i.e. it's not a beginners topic, it's a very low-level, technicallly
>> advanced one.
> 
> But you can assume that someone reading the manual page about generators wants
> to ...well... read about generators.
> Otherwise you could shorten the manual page to "Go away! You are not supposed
> to read this."

don't get me wrong but as you are a beginner to systemd stuff why don't
you just start with ordinary unit files in /etc/systemd/system as
erevrybody else does so you can get warm with systemd, systemctl and so on?

i use systemd now for 7 years on all sort of setups from firewalls over
workstations to production servers and wrote a ton of systemd units and
targs but never had any need to even consider generators at all
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [system-journald error]

2019-05-15 Thread Kay One
Hello Folks,

I have enabled more debug logs & realized following 2 logs are continuously
being dump.
*Is it some known bug for systemd-journald for following version? I am
using Angstrom distribution of debian OS?*

root@arria10:~# uname -a
Linux arria10 4.9.78-ltsi #1 SMP Thu Dec 13 12:01:27 PST 2018 armv7l
GNU/Linux

root@arria10:~# systemctl --version
systemd 239
+PAM -AUDIT -SELINUX +IMA -APPARMOR +SMACK +SYSVINIT +UTMP -LIBCRYPTSETUP
+GCRYPT +GNUTLS +ACL +XZ +LZ4 -SECCOMP +BLKID -ELFUTILS +KMOD -IDN2 +IDN
-PCRE2 default-hierarchy=hybrid

LOG:
--
root@arria10:~#
*[ 2002.668599] systemd-journald[743]: Journal effective settings seal=yes
compress=yes compress_threshold_bytes=512B*
*[ 2002.679080] systemd-journald[743]: Failed to open system journal:
Invalid argument*
[ 2002.686750] systemd-journald[743]: Journal effective settings seal=yes
compress=yes compress_threshold_bytes=512B
[ 2002.697135] systemd-journald[743]: Failed to open system journal:
Invalid argument
[ 2002.705876] systemd-journald[743]: Journal effective settings seal=yes
compress=yes compress_threshold_bytes=512B
[ 2002.716317] systemd-journald[743]: Failed to open system journal:
Invalid argument
[ 2002.723999] systemd-journald[743]: Journal effective settings seal=yes
compress=yes compress_threshold_bytes=512B
[ 2002.734703] systemd-journald[743]: Failed to open system journal:
Invalid argument
[ 2002.742845] systemd-journald[743]: Journal effective settings seal=yes
compress=yes compress_threshold_bytes=512B
[ 2062.663137] systemd-journald[743]: Journal effective settings seal=yes
compress=yes compress_threshold_bytes=512B
[ 2062.673722] systemd-journald[743]: Failed to open system journal:
Invalid argument
[ 2062.681505] systemd-journald[743]: Journal effective settings seal=yes
compress=yes compress_threshold_bytes=512B
[ 2062.691980] systemd-journald[743]: Failed to open system journal:
Invalid argument
[ 2062.700808] systemd-journald[743]: Journal effective settings seal=yes
compress=yes compress_threshold_bytes=512B
[ 2062.711412] systemd-journald[743]: Failed to open system journal:
Invalid argument
[ 2062.719171] systemd-journald[743]: Journal effective settings seal=yes
compress=yes compress_threshold_bytes=512B
[ 2062.729639] systemd-journald[743]: Failed to open system journal:
Invalid argument
[ 2062.737827] systemd-journald[743]: Journal effective settings seal=yes
compress=yes compress_threshold_bytes=512B
[ 2062.748330] systemd-journald[743]: Failed to open system journal:
Invalid argument
[ 2112.662005] systemd-journald[743]: Sent WATCHDOG=1 notification.
[ 2112.669418] systemd-journald[743]: Journal effective settings seal=yes
compress=yes compress_threshold_bytes=512B
[ 2112.679851] systemd-journald[743]: Failed to open system journal:
Invalid argument
[ 2112.687503] systemd-journald[743]: Journal effective settings seal=yes
compress=yes compress_threshold_bytes=512B
[ 2112.697859] systemd-journald[743]: Failed to open system journal:
Invalid argument
[ 2112.706642] systemd-journald[743]: Journal effective settings seal=yes
compress=yes compress_threshold_bytes=512B
[ 2112.717098] systemd-journald[743]: Failed to open system journal:
Invalid argument
[ 2112.724776] systemd-journald[743]: Journal effective settings seal=yes
compress=yes compress_threshold_bytes=512B
[ 2112.735142] systemd-journald[743]: Failed to open system journal:
Invalid argument
[ 2112.743220] systemd-journald[743]: Journal effective settings seal=yes
compress=yes compress_threshold_bytes=512B
[ 2122.664190] systemd-journald[743]: Journal effective settings seal=yes
compress=yes compress_threshold_bytes=512B
[ 2122.674654] systemd-journald[743]: Failed to open system journal:
Invalid argument
[ 2122.682278] systemd-journald[743]: Journal effective settings seal=yes
compress=yes compress_threshold_bytes=512B
[ 2122.692638] systemd-journald[743]: Failed to open system journal:
Invalid argument
[ 2122.701584] systemd-journald[743]: Journal effective settings seal=yes
compress=yes compress_threshold_bytes=512B
[ 2122.712049] systemd-journald[743]: Failed to open system journal:
Invalid argument
[ 2122.719695] systemd-journald[743]: Journal effective settings seal=yes
compress=yes compress_threshold_bytes=512B
[ 2122.730205] systemd-journald[743]: Failed to open system journal:
Invalid argument
[ 2122.738354] systemd-journald[743]: Journal effective settings seal=yes
compress=yes compress_threshold_bytes=512B
[ 2122.748794] systemd-journald[743]: Failed to open system journal:
Invalid argument
[ 2128.913734] systemd-journald[743]: Journal effective settings seal=yes
compress=yes compress_threshold_bytes=512B
[ 2128.924461] systemd-journald[743]: Failed to open system journal:
Invalid argument
[ 2128.932107] systemd-journald[743]: Journal effective settings seal=yes
compress=yes compress_threshold_bytes=512B
[ 2128.942493] systemd-journald[743]: Failed to open system journal:
Invalid argument
[ 2128.951361] systemd-journald[743]: Journal 

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

2019-05-15 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 15.05.2019 um 12:20
in
Nachricht <20190515102024.GB23038@gardel-login>:
> On Mi, 15.05.19 12:12, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) 
> wrote:
> 
>> >>> Lennart Poettering  schrieb am 15.05.2019 um
12:04
>> in
>> Nachricht <20190515100400.GB22945@gardel-login>:
>> > On Mi, 15.05.19 12:01, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
>> wrote:
>> >
>> >> > Writing a generator is not a typical user would do. It's what a
>> >> > developer of a package would do, and yes, in that case, when you
write
>> >> > code you need a bit more understanding of the underpinnings and need
>> >> > to do more work.
>> >>
>> >> systemd.generator(7) could really need some (better/realistic)
examples.
>> >
>> > I think you assume generators are something they inherently are not.
>>
>> Even if so, a better example might clarify things. Just referring to a 
> binary
>> generator like systemd-fstab-generator is not really helpful to teach how
to
>> write a generator. You don't like scripts as generators, but I think still

> they
>> would make a good example what a generator is supposed to do and what not.
> 
> Well, there can always be more examples, but "generators" are
> inherently an advanced concept: if you are writing a generator, then
> you already should be pro enough to be able to consult the sources of
> the various generators shipped with systemd.
> 
> i.e. it's not a beginners topic, it's a very low-level, technicallly
> advanced one.

But you can assume that someone reading the manual page about generators wants
to ...well... read about generators.
Otherwise you could shorten the manual page to "Go away! You are not supposed
to read this."

Rehgards,
Ulrich

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

Re: [systemd-devel] Slice question

2019-05-15 Thread Andrei Borzenkov
On Wed, May 15, 2019 at 12:04 PM Ulrich Windl
 wrote:
>
> Hi!
>
> When I tried to put the instances of my service into a specific slice (by 
> only specifying the name), I just got an error message.
>
> I had:
> [Service]
> Slice=something
>
> in the service unit file.

Works here
___
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?

2019-05-15 Thread Lennart Poettering
On Mi, 15.05.19 12:12, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> >>> Lennart Poettering  schrieb am 15.05.2019 um 12:04
> in
> Nachricht <20190515100400.GB22945@gardel-login>:
> > On Mi, 15.05.19 12:01, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
> wrote:
> >
> >> > Writing a generator is not a typical user would do. It's what a
> >> > developer of a package would do, and yes, in that case, when you write
> >> > code you need a bit more understanding of the underpinnings and need
> >> > to do more work.
> >>
> >> systemd.generator(7) could really need some (better/realistic) examples.
> >
> > I think you assume generators are something they inherently are not.
>
> Even if so, a better example might clarify things. Just referring to a binary
> generator like systemd-fstab-generator is not really helpful to teach how to
> write a generator. You don't like scripts as generators, but I think still 
> they
> would make a good example what a generator is supposed to do and what not.

Well, there can always be more examples, but "generators" are
inherently an advanced concept: if you are writing a generator, then
you already should be pro enough to be able to consult the sources of
the various generators shipped with systemd.

i.e. it's not a beginners topic, it's a very low-level, technicallly
advanced one.

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?

2019-05-15 Thread Lennart Poettering
On Mi, 15.05.19 12:08, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> > I mean, if you want to persistently enable a unit that is converted
> > from something else, then please write your own converted, and write
> > something to /etc/systemd/system, there's no need whatsoever to bother
> > systemd itself with that, you shouldn't use generators for that.
>
> Sorry, I still don't get it: The only(?) difference is the path where they
> (units files) are found, and that the /run directory is volatile. Aren't the
> other differences not just "artificial"?

Please see:

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

i.e. generators are invoked whenever a reload cycle begins, and output
their units into a specific directories that are flushed our when the
reload cycle ends. i.e. everytime "systemctl daemon-reload" is invoked
the files generated on the current cycles are removed, and the
generators started again to generate a new set of files. Whateever
they generate has very clear, very volatile semantics: issue
"systemctl daemon-reload" and its all gone.

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?

2019-05-15 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 15.05.2019 um 12:04
in
Nachricht <20190515100400.GB22945@gardel-login>:
> On Mi, 15.05.19 12:01, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
wrote:
> 
>> > Writing a generator is not a typical user would do. It's what a
>> > developer of a package would do, and yes, in that case, when you write
>> > code you need a bit more understanding of the underpinnings and need
>> > to do more work.
>>
>> systemd.generator(7) could really need some (better/realistic) examples.
> 
> I think you assume generators are something they inherently are not.

Even if so, a better example might clarify things. Just referring to a binary
generator like systemd-fstab-generator is not really helpful to teach how to
write a generator. You don't like scripts as generators, but I think still they
would make a good example what a generator is supposed to do and what not.

Regards,
Ulrich

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

2019-05-15 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 15.05.2019 um 12:03
in
Nachricht <20190515100311.GA22945@gardel-login>:
> On Mi, 15.05.19 11:57, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
wrote:
> 
>> >> could call "systemctl add‑wants ‑‑transient" to do the job,
>> >> but at that point, that's more pedantic than practical. If you write a
>> >> generator, your systemd‑fu should be high enough to know and
>> >> understand systemd's symlink mechanisms...
>> >
>> > Precisely. if you write your own generator, then you need to know what
>> > you do, and need to know how to place your symlinks. You are
>> > essentially writing your own unit file installer that way and are
>> > expected to create your own symlinks then.
>>
>> I didn't see it that way: Generated units are just as units installed by 
> some
>> package manager, but specific to the local configuration. So why to make
>> differences?: A unit is a file that is found by systemd (after the 
> generators
>> finished)...
> 
> Nope, that's simply not how they are designed. They are a mechanism
> how to extend the systemd dependency tree and install additional
> nodes in that tree.
> 
> If you are looking for a generic converter of foreign stuff into
> classic, persistent systemd unit files, then generators is not what
> you should be using. Generators are life‑cycle bound to systemd
> release cycles, and their output ceases to exist on every reload
> boundary, and when the system is offline. If we'd allow generated
> units to be installed that clear life‑cycle would be very much
> blurred, as suddenly you'd have configuration that hooks them into the
> system that is more persistant than the actual definitions of the
> units themselves, and that's just borked...
> 
> I mean, if you want to persistently enable a unit that is converted
> from something else, then please write your own converted, and write
> something to /etc/systemd/system, there's no need whatsoever to bother
> systemd itself with that, you shouldn't use generators for that.

Sorry, I still don't get it: The only(?) difference is the path where they
(units files) are found, and that the /run directory is volatile. Aren't the
other differences not just "artificial"?

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

2019-05-15 Thread Lennart Poettering
On Mi, 15.05.19 12:01, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> > Writing a generator is not a typical user would do. It's what a
> > developer of a package would do, and yes, in that case, when you write
> > code you need a bit more understanding of the underpinnings and need
> > to do more work.
>
> systemd.generator(7) could really need some (better/realistic) examples.

I think you assume generators are something they inherently are not.

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?

2019-05-15 Thread Lennart Poettering
On Mi, 15.05.19 11:57, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> >> could call "systemctl add-wants --transient" to do the job,
> >> but at that point, that's more pedantic than practical. If you write a
> >> generator, your systemd-fu should be high enough to know and
> >> understand systemd's symlink mechanisms...
> >
> > Precisely. if you write your own generator, then you need to know what
> > you do, and need to know how to place your symlinks. You are
> > essentially writing your own unit file installer that way and are
> > expected to create your own symlinks then.
>
> I didn't see it that way: Generated units are just as units installed by some
> package manager, but specific to the local configuration. So why to make
> differences?: A unit is a file that is found by systemd (after the generators
> finished)...

Nope, that's simply not how they are designed. They are a mechanism
how to extend the systemd dependency tree and install additional
nodes in that tree.

If you are looking for a generic converter of foreign stuff into
classic, persistent systemd unit files, then generators is not what
you should be using. Generators are life-cycle bound to systemd
release cycles, and their output ceases to exist on every reload
boundary, and when the system is offline. If we'd allow generated
units to be installed that clear life-cycle would be very much
blurred, as suddenly you'd have configuration that hooks them into the
system that is more persistant than the actual definitions of the
units themselves, and that's just borked...

I mean, if you want to persistently enable a unit that is converted
from something else, then please write your own converted, and write
something to /etc/systemd/system, there's no need whatsoever to bother
systemd itself with that, you shouldn't use generators for that.

Lennart

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

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

2019-05-15 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 15.05.2019 um 11:54
in
Nachricht <20190515095443.GA22887@gardel-login>:
> On Mi, 15.05.19 12:47, Andrei Borzenkov (arvidj...@gmail.com) wrote:
> 
>> > > localhost:~ # systemctl enable usr‑local.mount
>> > > Failed to enable unit: Unit /run/systemd/generator/usr‑local.mount is
>> > > transient or generated.
>> > > localhost:~ # exit
>> >
>> > Hmm?
>> >
>> > No? Why?
>>
>> You just said that "You should never need to. [mess with symlinks].
>> For all relevant operations there are "systemctl"".
> 
> Yeah, for all user‑facing operations.
> 
> Writing a generator is not a typical user would do. It's what a
> developer of a package would do, and yes, in that case, when you write
> code you need a bit more understanding of the underpinnings and need
> to do more work.

systemd.generator(7) could really need some (better/realistic) examples.

> 
>> > generated units cannot be enabled, what am I missing?
>>
>> You are apparently missing context to which you replied. This
>> discussion *is* about enabling generated units. Of course, we now
>> again have problem that everyone implies different meaning of
>> "enabled". To avoid this word altogether ‑ generated unit can only be
>> included in initial transaction if it is dependency of some other unit
>> (already included in original transaction). You just claimed that to
>> establish such dependency one should use systemctl and I demonstrated
>> that this does not work. Either your claim is wrong, or the observed
>> behavior is a bug.
> 
> Again, generators are written by developers, not regular users doing
> day‑to‑day work. They assumed to be enabled as the developers intend
> them to, and that's orthogonal to the manual enable/disable scheme
> that applies to regular, package‑shipped, file‑based units...
> 
> Lennart
> 
> ‑‑
> Lennart Poettering, Berlin



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

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

2019-05-15 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 15.05.2019 um 11:31
in
Nachricht <20190515093135.GF22719@gardel-login>:
> On Mi, 15.05.19 11:29, Jérémy ROSEN (jeremy.ro...@smile.fr) wrote:
> 
>> well, in another thread, it was discussed why generated should never have
>> an install section and why enablement does not make sense for them...
>> so no it's not a bug.
>>
>> Arguably, yes, generators do need to care about symlinks, though, maybe
the
>> could call "systemctl add-wants --transient" to do the job,
>> but at that point, that's more pedantic than practical. If you write a
>> generator, your systemd-fu should be high enough to know and
>> understand systemd's symlink mechanisms...
> 
> Precisely. if you write your own generator, then you need to know what
> you do, and need to know how to place your symlinks. You are
> essentially writing your own unit file installer that way and are
> expected to create your own symlinks then.

I didn't see it that way: Generated units are just as units installed by some
package manager, but specific to the local configuration. So why to make
differences?: A unit is a file that is found by systemd (after the generators
finished)...

> 
> Lennart
> 
> --
> Lennart Poettering, Berlin
> ___
> 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] Antw: Re: Re: "bad" status for genersated target; why?

2019-05-15 Thread Lennart Poettering
On Mi, 15.05.19 12:47, Andrei Borzenkov (arvidj...@gmail.com) wrote:

> > > localhost:~ # systemctl enable usr-local.mount
> > > Failed to enable unit: Unit /run/systemd/generator/usr-local.mount is
> > > transient or generated.
> > > localhost:~ # exit
> >
> > Hmm?
> >
> > No? Why?
>
> You just said that "You should never need to. [mess with symlinks].
> For all relevant operations there are "systemctl"".

Yeah, for all user-facing operations.

Writing a generator is not a typical user would do. It's what a
developer of a package would do, and yes, in that case, when you write
code you need a bit more understanding of the underpinnings and need
to do more work.

> > generated units cannot be enabled, what am I missing?
>
> You are apparently missing context to which you replied. This
> discussion *is* about enabling generated units. Of course, we now
> again have problem that everyone implies different meaning of
> "enabled". To avoid this word altogether - generated unit can only be
> included in initial transaction if it is dependency of some other unit
> (already included in original transaction). You just claimed that to
> establish such dependency one should use systemctl and I demonstrated
> that this does not work. Either your claim is wrong, or the observed
> behavior is a bug.

Again, generators are written by developers, not regular users doing
day-to-day work. They assumed to be enabled as the developers intend
them to, and that's orthogonal to the manual enable/disable scheme
that applies to regular, package-shipped, file-based units...

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: Re: "bad" status for genersated target; why?

2019-05-15 Thread Andrei Borzenkov
On Wed, May 15, 2019 at 12:29 PM Lennart Poettering
 wrote:
>
> On Mi, 15.05.19 12:25, Andrei Borzenkov (arvidj...@gmail.com) wrote:
>
> > On Wed, May 15, 2019 at 12:17 PM Lennart Poettering
> >  wrote:
> > > >
> > > > To me it's the most horrible part of systemd: Messing with
> > > > symlinks...
> > >
> > > You should never need to. For all relevant operations there are
> > > "systemctl" verbs, i.e. "systemctl enable", "systemctl disable",
> > > "systemctl add-wants" and so on.
> > >
> >
> > So the following is a bug?
> >
> > localhost:~ # systemctl enable usr-local.mount
> > Failed to enable unit: Unit /run/systemd/generator/usr-local.mount is
> > transient or generated.
> > localhost:~ # exit
>
> Hmm?
>
> No? Why?

You just said that "You should never need to. [mess with symlinks].
For all relevant operations there are "systemctl"".

> generated units cannot be enabled, what am I missing?
>

You are apparently missing context to which you replied. This
discussion *is* about enabling generated units. Of course, we now
again have problem that everyone implies different meaning of
"enabled". To avoid this word altogether - generated unit can only be
included in initial transaction if it is dependency of some other unit
(already included in original transaction). You just claimed that to
establish such dependency one should use systemctl and I demonstrated
that this does not work. Either your claim is wrong, or the observed
behavior is a bug.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2019-05-15 Thread Lennart Poettering
On Mi, 15.05.19 11:29, Jérémy ROSEN (jeremy.ro...@smile.fr) wrote:

> well, in another thread, it was discussed why generated should never have
> an install section and why enablement does not make sense for them...
> so no it's not a bug.
>
> Arguably, yes, generators do need to care about symlinks, though, maybe the
> could call "systemctl add-wants --transient" to do the job,
> but at that point, that's more pedantic than practical. If you write a
> generator, your systemd-fu should be high enough to know and
> understand systemd's symlink mechanisms...

Precisely. if you write your own generator, then you need to know what
you do, and need to know how to place your symlinks. You are
essentially writing your own unit file installer that way and are
expected to create your own symlinks then.

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: Re: "bad" status for genersated target; why?

2019-05-15 Thread Reindl Harald


Am 15.05.19 um 11:25 schrieb Andrei Borzenkov:
> On Wed, May 15, 2019 at 12:17 PM Lennart Poettering
>  wrote:
>>>
>>> To me it's the most horrible part of systemd: Messing with
>>> symlinks...
>>
>> You should never need to. For all relevant operations there are
>> "systemctl" verbs, i.e. "systemctl enable", "systemctl disable",
>> "systemctl add-wants" and so on.
>>
> 
> So the following is a bug?
> 
> localhost:~ # systemctl enable usr-local.mount
> Failed to enable unit: Unit /run/systemd/generator/usr-local.mount is
> transient or generated.
> localhost:~ # exit

why should this be a bug?

it clearly tells you that it makes no sense enable/disable a generated
unit because it#s already active and won't exist after shutdown
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

2019-05-15 Thread Jérémy ROSEN
well, in another thread, it was discussed why generated should never have
an install section and why enablement does not make sense for them...
so no it's not a bug.

Arguably, yes, generators do need to care about symlinks, though, maybe the
could call "systemctl add-wants --transient" to do the job,
but at that point, that's more pedantic than practical. If you write a
generator, your systemd-fu should be high enough to know and
understand systemd's symlink mechanisms...

Le mer. 15 mai 2019 à 11:25, Andrei Borzenkov  a
écrit :

> On Wed, May 15, 2019 at 12:17 PM Lennart Poettering
>  wrote:
> > >
> > > To me it's the most horrible part of systemd: Messing with
> > > symlinks...
> >
> > You should never need to. For all relevant operations there are
> > "systemctl" verbs, i.e. "systemctl enable", "systemctl disable",
> > "systemctl add-wants" and so on.
> >
>
> So the following is a bug?
>
> localhost:~ # systemctl enable usr-local.mount
> Failed to enable unit: Unit /run/systemd/generator/usr-local.mount is
> transient or generated.
> localhost:~ # exit
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel



-- 
[image: SMILE]  

20 rue des Jardins
92600 Asnières-sur-Seine
*Jérémy ROSEN*
Architecte technique

[image: email] jeremy.ro...@smile.fr
[image: phone]  +33 6 88 25 87 42
[image: url] http://www.smile.eu

[image: Twitter]  [image: Facebook]
 [image: LinkedIn]
 [image: Github]


[image: Découvrez l’univers Smile, rendez-vous sur smile.eu]

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

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

2019-05-15 Thread Lennart Poettering
On Mi, 15.05.19 12:25, Andrei Borzenkov (arvidj...@gmail.com) wrote:

> On Wed, May 15, 2019 at 12:17 PM Lennart Poettering
>  wrote:
> > >
> > > To me it's the most horrible part of systemd: Messing with
> > > symlinks...
> >
> > You should never need to. For all relevant operations there are
> > "systemctl" verbs, i.e. "systemctl enable", "systemctl disable",
> > "systemctl add-wants" and so on.
> >
>
> So the following is a bug?
>
> localhost:~ # systemctl enable usr-local.mount
> Failed to enable unit: Unit /run/systemd/generator/usr-local.mount is
> transient or generated.
> localhost:~ # exit

Hmm?

No? Why? generated units cannot be enabled, what am I missing?

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: Re: "bad" status for genersated target; why?

2019-05-15 Thread Andrei Borzenkov
On Wed, May 15, 2019 at 12:17 PM Lennart Poettering
 wrote:
> >
> > To me it's the most horrible part of systemd: Messing with
> > symlinks...
>
> You should never need to. For all relevant operations there are
> "systemctl" verbs, i.e. "systemctl enable", "systemctl disable",
> "systemctl add-wants" and so on.
>

So the following is a bug?

localhost:~ # systemctl enable usr-local.mount
Failed to enable unit: Unit /run/systemd/generator/usr-local.mount is
transient or generated.
localhost:~ # exit
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: Re: Q: Reducing the output of systemctl status

2019-05-15 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 15.05.2019 um 11:04 
>>> in
Nachricht <20190515090447.GA22719@gardel-login>:

[...]
>> I just noticed: If you use a "argv[0] override" for your command, it's not
>> just that the command is started with that name, it's also displayed as
>> ExecStart here (not path shown).  I used it to shorten error messages using
>> argv[0].
> 
> I cannot parse this?

"@/var/run/iotwatch-LOC1/iotwatch-LOC1 iotwatch-LOC1 ..." is displayed as 
"iotwatch-LOC1 ...":
Process: 13950 ExecStart=iotwatch-LOC1 ...

> 
>> So I'd like a status output that simply displays:
>> Active: active (running) since Wed 2019-05-15 08:33:14 CEST; 2min 17s ago
> 
> I mean, I'd like a pony, too.

Real men want a death star, not a pony ;-)

> 
> It appears you want to use "systemctl is-active", not "systemctl status".

Right, but when you have --quiet already, why to apply it consistently?
Also it seems that "systemctl is-active" accepts any name (e.g. mis-spelled 
service names) without complaint, saying it's "inactive". Is that a bug?

Regards,
Ulrich




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

[systemd-devel] Slice question

2019-05-15 Thread Ulrich Windl
Hi!

When I tried to put the instances of my service into a specific slice (by only 
specifying the name), I just got an error message.

I had:
[Service]
Slice=something

in the service unit file. Amazingly systemd does put my instances in a slice 
when I removed that Slice line. The slice is named "system-.slice".

Three questions:
1) Is there a simple way to just rename the default slice?
2) Most services don't seem to have a slice associated (e.g. postfix.service, 
logd.service). What are the conditions that a slice is created?
3) Is there a useful example for slice settings? systemd.resource-control(5) is 
not really helpful (e.g. What is all that "accounting" useful for?)...

Regards,
Ulrich


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

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

2019-05-15 Thread Lennart Poettering
On Mi, 15.05.19 10:14, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> >> >> Why "bad"?
> >> >
> >> > Again - this has improved in current version which now tells you that
> >> > unit is generated.
> >>
> >> So there's nothing wrong with the unit?

The string shown on your version is a bug. Please ask your distro to
backport the fix for that, which has been merged upstream many years
ago.

> > It is exactly the opposite - symlinks are *the* official documented
> > method to configure unit dependencies; "systemctl enable" is just
> > convenience layer on top of it.
>
> To me it's the most horrible part of systemd: Messing with
> symlinks...

You should never need to. For all relevant operations there are
"systemctl" verbs, i.e. "systemctl enable", "systemctl disable",
"systemctl add-wants" and so on.

Note that the symlink stuff is inherited directly from sysvinit in
fact, where services where enabled/disabled via symlinks int
/etc/rc.d/ too.

But again, the fact that these are symlinks is something you can
ignore if you want to, just use the relevant systemctl commands
instead.

> My point was: Once  a generator generates a target, it should be "enabled"
> (see above), I don't see why I (or a program) should have to mess with 
> symbolic
> links.

It never has to. A generated unit is shown as "generated" in all
systemd versions from the last few years in fact. Please ask your
distro to backport this.

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: Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)

2019-05-15 Thread Lennart Poettering
On Mi, 15.05.19 07:48, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> >> Or more like this (in the user directory):?
> >> > systemd‑analyze verify systemd/iotwatch.target.in
> >> Failed to open /dev/tty0: Permission denied
> >> Failed to load systemd/iotwatch.target.in: Invalid argument
> >
> > That's not a valid unit file name. On systemd unit files are named in
> > a very strict fashion, and this is documented. A service unit file
> > name must be suffixed with ".service" and a target unit file name must
> > be suffixed with ".target". The suffix ".target.in" is not valid for a
> > unit file.
>
> So the type to check is deduced from the name? my "target.in" is the template
> used by the generator to create the real target

Yes, the unit type is derived from the unit file name. If a unit file
name ends in ".service" it means it may have a [Service] section in
it, with an ExecStart= line. otoh if it ends in ".mount" it instead
may have [Mount] section with an Option= line.

> Usually I wouldn't associate "Inavalid argument" with "syntax error". I'd
> prefer "unknown suffix" over "Invalid argument". There's less room for
> speculation then...

Please file an RFE issue, or even better prepare a patch!

Lennart

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

Re: [systemd-devel] Slice question

2019-05-15 Thread Lennart Poettering
On Mi, 15.05.19 11:04, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> Hi!
>
> When I tried to put the instances of my service into a specific slice (by 
> only specifying the name), I just got an error message.
>
> I had:
> [Service]
> Slice=something
>
> in the service unit file. Amazingly systemd does put my instances in a slice 
> when I removed that Slice line. The slice is named 
> "system-.slice".
>
> Three questions:
> 1) Is there a simple way to just rename the default slice?

No. The default slice for system services (system.slice) is built into systemd.

> 2) Most services don't seem to have a slice associated
> (e.g. postfix.service, logd.service). What are the conditions that a
> slice is created?

Services are by default placed in "system.slice". All services in
fact. That said, template services get their own subslice of that per
slice. For example if you have "foobar@.service", then it gets placed
into "system-foobar.slice", i.e. one slice further down the tree.

> 3) Is there a useful example for slice settings?
> systemd.resource-control(5) is not really helpful (e.g. What is all
> that "accounting" useful for?)...

Accounting turns on accounting of resources. You will then see
additional output in "systemctl status" and "systemctl show" about
resource usage. Moreover "systemd-cgtop" will actually show useful
columns if you turn on specific forms of accounting for your services.

Lennart

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

Re: [systemd-devel] Q: Reducing the output of systemctl status

2019-05-15 Thread Lennart Poettering
On Mi, 15.05.19 08:49, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> Hi!
>
> First, is it a well-known bug that "--quitet" seems to be ignored for
> "systemctl status"? It's the only command where --quiet makes sense IMHO, but
> it seems to have no effect in v228.

"systemctl status" is the human-friendly operation, i.e. when you want
to know everything about a service.

If you want the short, parsable version use "systemctl is-active", and
possibly add "-q".

> Also, considering this example output:
> ---
> ● iotwatch@LOC1.service - iotwatch I/O performance monitor instance "LOC1"
>Loaded: loaded (/run/systemd/generator.late/iotwatch@LOC1.service; bad;
> vendor preset: disabled)
>Active: active (running) since Wed 2019-05-15 08:33:14 CEST; 2min 17s ago
>  Docs: man:iotwatch(1)
>man:iotwatch@.service(8)
>   Process: 13962 ExecStartPost=/usr/bin/sleep 0.2 (code=exited,
> status=0/SUCCESS)
>   Process: 13950 ExecStart=iotwatch-LOC1 -l
> /var/log/iotwatch/LOC1/iotwatch-LOC1.log -m N
> -p/var/run/iotwatch-LOC1/iotwatch-LOC1.pid -d1 -a0.02 -b512 -i4 -sE -t2.0
> -TA=0.025:0.035,X=0.25:0.75 -OR
> -OS:T=F75,S:M=O52,N:3.29/40,Q:C=100,P:nagios.nagios=0664 /etc/passwd
> (code=exited, status=0/SUCCESS)
>   Process: 13929 ExecStartPre=/bin/sh -c [ -d "/var/log/iotwatch/LOC1" -o 1
> -eq 0 ] || mkdir "/var/log/iotwatch/LOC1" || exit 3 (code=exited,
> status=0/SUCCESS)
>   Process: 13913 ExecStartPre=/bin/sh -c [ -h
> "/var/run/iotwatch-LOC1/iotwatch-LOC1" ] || ln -s "/usr/bin/iotwatch"
> "/var/run/iotwatch-LOC1/iotwatch-LOC1" || exit 3 (code=exited,
> status=0/SUCCESS)
>   Process: 13903 ExecStartPre=/bin/sh -c [ -d "/var/run/iotwatch-LOC1" ] ||
> mkdir "/var/run/iotwatch-LOC1" || exit 3 (code=exited, status=0/SUCCESS)
>  Main PID: 13960 (iotwatch-LOC1)
> Tasks: 4 (limit: 512)
>CGroup: /system.slice/system-iotwatch.slice/iotwatch@LOC1.service
>└─13960 iotwatch-LOC1 -l /var/log/iotwatch/LOC1/iotwatch-LOC1.log
> ...
>
> May 15 08:33:14 rksapv04 systemd[1]: Starting iotwatch I/O performance
> moni.
> May 15 08:33:14 rksapv04 systemd[1]: Started iotwatch I/O performance
> monit...".
> ---
> I wonder if I could suppress the "lesser-important" output, like pre- and post
> start commands.

Quite frankly: this service should probably not embedd so much shell
in the ExecXYZ= command lines in the first place, that'd make
everything a lot more readable...

I mean, it's the price you pay: if your service doesn't do all
necessary checks and preparations on its own, and you push all that
into the service file, then yes, the output will look awful. But the
answer is: don't do that: either fix your daemon to not require
anything like that, or maybe add a wrapper script that does what you
are doing here and then ultimately does an "exec" on the actual
service binary.

Or to say this differently: ExecStartPre= and the other command lines
are supposed to be readable, and in most cases contain something brief
and readable and for those we include in the output and it's a good
thing. But in your case the service file is misused as a shell
replacement, and that's why it looks ugly, but the fix is not use a
shell where a shell is great for and not to break the status output
for everybody else, too.

> (Actually I had to add a manual sleep as the PID file is created by the child
> process after the parent exited, and systemd complained the PIDFile is not
> present yet.)

That looks like a bug in the service. PID files need to be written out
by the time the parent process of a forking daemon exits. That's not
just systemd that needs that, it's exactly the same on sysv too
because otherwise "/etc/init.d/foo start && /etc/init.rd/foo stop"
will always be racy.

> I just noticed: If you use a "argv[0] override" for your command, it's not
> just that the command is started with that name, it's also displayed as
> ExecStart here (not path shown).  I used it to shorten error messages using
> argv[0].

I cannot parse this?

> So I'd like a status output that simply displays:
> Active: active (running) since Wed 2019-05-15 08:33:14 CEST; 2min 17s ago

I mean, I'd like a pony, too.

It appears you want to use "systemctl is-active", not "systemctl status".

Lennart

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

[systemd-devel] resolved and dnssec

2019-05-15 Thread Ellis

Hi,
I have the following setup:

* home made router that I configured all on my own including 
compilation, running dnsmasq to provide everything from dhcp to slaac 
and dns.
* said dnsmasq has no dnssec support. It is neither compiled in the 
binary nor set up in the dnsmasq.conf file.
* systemd-resolved runs on my laptop connected to the router, and 
believes dnssec to be supported while it is not supported at all, 
leading to random and very annoying dnssec failures.
* if I disable resolved and create a manual /etc/resolved.conf, I have 
no such problems, which would tend to show that resolved wrongly thinks 
dnssec is supported.


The only workaround I've found is to intentionally add 'DNSSEC=false' to 
my .network files and also on new installation because timesyncd will 
silently fail syncing time with the dnssec failures. How can I debug 
this further ?

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

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

2019-05-15 Thread Ulrich Windl
>>> Andrei Borzenkov  schrieb am 15.05.2019 um 09:21 in
Nachricht
:
> On Wed, May 15, 2019 at 9:01 AM Ulrich Windl
>  wrote:
>>
>> >>> Andrei Borzenkov  schrieb am 14.05.2019 um 20:21
in
>> Nachricht :
>> > 14.05.2019 16:39, Ulrich Windl пишет:
>> >> Hi!
>> >>
>> >> Developing my first systemd service I have some problems I don't
>> understand:
>> >> After installation, I get this status:
>> >> # systemctl status iotwatch.target  ● iotwatch.target -
iotwatch
>> I/O
>> >> performance monitor
>> >>Loaded: loaded (/run/systemd/generator.late/iotwatch.target; bad;
>> vendor
>> >> preset: disabled)
>> >>Active: inactive (dead)
>> >>  Docs: man:iotwatch@.service(8)
>> >>man:iotwatch-generator(8)
>> >>
>> >> Why "bad"?
>> >
>> > Again - this has improved in current version which now tells you that
>> > unit is generated.
>>
>> So there's nothing wrong with the unit?
>>
>> >
>> >> # ll /run/systemd/generator.late/iotwatch.target
>> >> -rw-r--r-- 1 root root 281 May 14 15:24
>> >> /run/systemd/generator.late/iotwatch.target
>> >> # systemctl is-enabled iotwatch.target
>> >> Failed to get unit file state for iotwatch.target: No such file or
>> directory
>> >>
>> >> Here we are again: Where should the file be?
>> >> Aren't targets allowed to be generated?
>> >>
>> >
>> > Targets are allowed to be generated but generated units cannot be
>> > enabled/disabled. The rationale probably is that if you create unit file
>> > you can just as well create symlink to this unit file. Also "systemctl
>>
>> I think "Generated iotwatch.target cannot have a state" would be a much
>> improved error message then.
> 
> Define "state".

enabled|disabled

> 
>> So again there's nothing wrong with the unit
>> file?
>>
>> > dameon-reload" removes and re-creates all generated units, so any
>> > symlink to such unit outside of generated subdirectories potentially
>> > becomes invalid.
>>
>> I think all the symlink stuff should be an implementation detail that
>> shouldn't be part of the user interface; instead there should be some
>> higher-level commands to maipulate these.
>>
> 
> It is exactly the opposite - symlinks are *the* official documented
> method to configure unit dependencies; "systemctl enable" is just
> convenience layer on top of it.

To me it's the most horrible part of systemd: Messing with symlinks...

> 
>> >
>> > Documentation could be better indeed.
>>
>> Finally: If a generated unit cannot be enabled or disabled, isn't the
>> "vendor-preset: disabled" the wrong choice:
> 
> Neither is it printed in current systemd version.

OK, good.

> 
>> I specified nothing, and the logic
>> should be: If a generator created a unit it should be enabled; otherwise 
> sich a
>> unit shouldn't be enabled.
>>
> 
> You misinterpret "enabled" and "disabled" basing on their English
> meaning. Unit is "enabled" if links specified in [Install] sections
> are present. Nothing more nothing less. You apparently assume
> "enabled" means something different.

To me "enabled" means "it'll be started on boot" (or other events) and
"stopped on shutdown". "disabled" means the opposite. Quite simple.


> 
> Generators run immediately before systemd computes initial
> transaction; there is no point in time when user could perform
> "systemctl enable" on them - it is already too late, system is already
> booted using whatever configuration (including generated units) was
> present. So any required links really have to be created together with
> generated unit itself.

My point was: Once  a generator generates a target, it should be "enabled"
(see above), I don't see why I (or a program) should have to mess with symbolic
links.

> 
>> I couldn't find the relevant manual page that discusses this topic...
>>
> 
> Yes, the fact that generated units apparently cannot be
> enabled/disabled using systemctl is not documented anywhere. Still
> current systemd gives quite precise error message when you are trying
> to do it. But documentation could certainly be improved.

The problem is you don't know where to start reading, like finding your way in
those old dungeon adventures...

Regards,
Ulrich



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

Re: [systemd-devel] Antw: Re: Antw: Re: Arbitrary restrictions (e.g. for RuntimeDirectory)

2019-05-15 Thread Reindl Harald


Am 14.05.19 um 08:35 schrieb Ulrich Windl:
>> stop it - if you would have read IT news (golem/heise) the last 7 years
>> or so you would know about /run and why it is a top-directory
>>
>> https://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard 
>>
>> /run
>>
>> Run-time variable data: Information about the running system since last
>> boot, e.g., currently logged-in users and running daemons. Files under
>> this directory must be either removed or truncated at the beginning of
>> the boot process; but this is not necessary on systems that provide this
>> directory as a temporary filesystem (tmpfs).
> 
> I knew that. It doesn't answer _why_ /var/run is obsolete

because the runtime dirctory is needed at early boot and /var is not
available at that point of time when it's a seperate mount-point which
could even live on NFS and so comes up very late after network and friends?


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

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

2019-05-15 Thread Andrei Borzenkov
On Wed, May 15, 2019 at 9:01 AM Ulrich Windl
 wrote:
>
> >>> Andrei Borzenkov  schrieb am 14.05.2019 um 20:21 in
> Nachricht :
> > 14.05.2019 16:39, Ulrich Windl пишет:
> >> Hi!
> >>
> >> Developing my first systemd service I have some problems I don't
> understand:
> >> After installation, I get this status:
> >> # systemctl status iotwatch.target  ● iotwatch.target - iotwatch
> I/O
> >> performance monitor
> >>Loaded: loaded (/run/systemd/generator.late/iotwatch.target; bad;
> vendor
> >> preset: disabled)
> >>Active: inactive (dead)
> >>  Docs: man:iotwatch@.service(8)
> >>man:iotwatch-generator(8)
> >>
> >> Why "bad"?
> >
> > Again - this has improved in current version which now tells you that
> > unit is generated.
>
> So there's nothing wrong with the unit?
>
> >
> >> # ll /run/systemd/generator.late/iotwatch.target
> >> -rw-r--r-- 1 root root 281 May 14 15:24
> >> /run/systemd/generator.late/iotwatch.target
> >> # systemctl is-enabled iotwatch.target
> >> Failed to get unit file state for iotwatch.target: No such file or
> directory
> >>
> >> Here we are again: Where should the file be?
> >> Aren't targets allowed to be generated?
> >>
> >
> > Targets are allowed to be generated but generated units cannot be
> > enabled/disabled. The rationale probably is that if you create unit file
> > you can just as well create symlink to this unit file. Also "systemctl
>
> I think "Generated iotwatch.target cannot have a state" would be a much
> improved error message then.

Define "state".

> So again there's nothing wrong with the unit
> file?
>
> > dameon-reload" removes and re-creates all generated units, so any
> > symlink to such unit outside of generated subdirectories potentially
> > becomes invalid.
>
> I think all the symlink stuff should be an implementation detail that
> shouldn't be part of the user interface; instead there should be some
> higher-level commands to maipulate these.
>

It is exactly the opposite - symlinks are *the* official documented
method to configure unit dependencies; "systemctl enable" is just
convenience layer on top of it.

> >
> > Documentation could be better indeed.
>
> Finally: If a generated unit cannot be enabled or disabled, isn't the
> "vendor-preset: disabled" the wrong choice:

Neither is it printed in current systemd version.

> I specified nothing, and the logic
> should be: If a generator created a unit it should be enabled; otherwise sich 
> a
> unit shouldn't be enabled.
>

You misinterpret "enabled" and "disabled" basing on their English
meaning. Unit is "enabled" if links specified in [Install] sections
are present. Nothing more nothing less. You apparently assume
"enabled" means something different.

Generators run immediately before systemd computes initial
transaction; there is no point in time when user could perform
"systemctl enable" on them - it is already too late, system is already
booted using whatever configuration (including generated units) was
present. So any required links really have to be created together with
generated unit itself.

> I couldn't find the relevant manual page that discusses this topic...
>

Yes, the fact that generated units apparently cannot be
enabled/disabled using systemctl is not documented anywhere. Still
current systemd gives quite precise error message when you are trying
to do it. But documentation could certainly be improved.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Q: Reducing the output of systemctl status

2019-05-15 Thread Ulrich Windl
Hi!

First, is it a well-known bug that "--quitet" seems to be ignored for
"systemctl status"? It's the only command where --quiet makes sense IMHO, but
it seems to have no effect in v228.

Also, considering this example output:
---
● iotwatch@LOC1.service - iotwatch I/O performance monitor instance "LOC1"
   Loaded: loaded (/run/systemd/generator.late/iotwatch@LOC1.service; bad;
vendor preset: disabled)
   Active: active (running) since Wed 2019-05-15 08:33:14 CEST; 2min 17s ago
 Docs: man:iotwatch(1)
   man:iotwatch@.service(8)
  Process: 13962 ExecStartPost=/usr/bin/sleep 0.2 (code=exited,
status=0/SUCCESS)
  Process: 13950 ExecStart=iotwatch-LOC1 -l
/var/log/iotwatch/LOC1/iotwatch-LOC1.log -m N
-p/var/run/iotwatch-LOC1/iotwatch-LOC1.pid -d1 -a0.02 -b512 -i4 -sE -t2.0
-TA=0.025:0.035,X=0.25:0.75 -OR
-OS:T=F75,S:M=O52,N:3.29/40,Q:C=100,P:nagios.nagios=0664 /etc/passwd
(code=exited, status=0/SUCCESS)
  Process: 13929 ExecStartPre=/bin/sh -c [ -d "/var/log/iotwatch/LOC1" -o 1
-eq 0 ] || mkdir "/var/log/iotwatch/LOC1" || exit 3 (code=exited,
status=0/SUCCESS)
  Process: 13913 ExecStartPre=/bin/sh -c [ -h
"/var/run/iotwatch-LOC1/iotwatch-LOC1" ] || ln -s "/usr/bin/iotwatch"
"/var/run/iotwatch-LOC1/iotwatch-LOC1" || exit 3 (code=exited,
status=0/SUCCESS)
  Process: 13903 ExecStartPre=/bin/sh -c [ -d "/var/run/iotwatch-LOC1" ] ||
mkdir "/var/run/iotwatch-LOC1" || exit 3 (code=exited, status=0/SUCCESS)
 Main PID: 13960 (iotwatch-LOC1)
Tasks: 4 (limit: 512)
   CGroup: /system.slice/system-iotwatch.slice/iotwatch@LOC1.service 
   └─13960 iotwatch-LOC1 -l /var/log/iotwatch/LOC1/iotwatch-LOC1.log
...

May 15 08:33:14 rksapv04 systemd[1]: Starting iotwatch I/O performance
moni.
May 15 08:33:14 rksapv04 systemd[1]: Started iotwatch I/O performance
monit...".
---
I wonder if I could suppress the "lesser-important" output, like pre- and post
start commands.
(Actually I had to add a manual sleep as the PID file is created by the child
process after the parent exited, and systemd complained the PIDFile is not
present yet.)

I just noticed: If you use a "argv[0] override" for your command, it's not
just that the command is started with that name, it's also displayed as
ExecStart here (not path shown).  I used it to shorten error messages using
argv[0].

So I'd like a status output that simply displays:
Active: active (running) since Wed 2019-05-15 08:33:14 CEST; 2min 17s ago


Regards,
Ulrich


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

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

2019-05-15 Thread Ulrich Windl
>>> Andrei Borzenkov  schrieb am 14.05.2019 um 20:21 in
Nachricht :
> 14.05.2019 16:39, Ulrich Windl пишет:
>> Hi!
>> 
>> Developing my first systemd service I have some problems I don't
understand:
>> After installation, I get this status:
>> # systemctl status iotwatch.target  ● iotwatch.target - iotwatch
I/O
>> performance monitor
>>Loaded: loaded (/run/systemd/generator.late/iotwatch.target; bad;
vendor
>> preset: disabled)
>>Active: inactive (dead)
>>  Docs: man:iotwatch@.service(8)
>>man:iotwatch-generator(8)
>> 
>> Why "bad"? 
> 
> Again - this has improved in current version which now tells you that
> unit is generated.

So there's nothing wrong with the unit?

> 
>> # ll /run/systemd/generator.late/iotwatch.target
>> -rw-r--r-- 1 root root 281 May 14 15:24
>> /run/systemd/generator.late/iotwatch.target
>> # systemctl is-enabled iotwatch.target
>> Failed to get unit file state for iotwatch.target: No such file or
directory
>> 
>> Here we are again: Where should the file be?
>> Aren't targets allowed to be generated?
>> 
> 
> Targets are allowed to be generated but generated units cannot be
> enabled/disabled. The rationale probably is that if you create unit file
> you can just as well create symlink to this unit file. Also "systemctl

I think "Generated iotwatch.target cannot have a state" would be a much
improved error message then. So again there's nothing wrong with the unit
file?

> dameon-reload" removes and re-creates all generated units, so any
> symlink to such unit outside of generated subdirectories potentially
> becomes invalid.

I think all the symlink stuff should be an implementation detail that
shouldn't be part of the user interface; instead there should be some
higher-level commands to maipulate these.

> 
> Documentation could be better indeed.

Finally: If a generated unit cannot be enabled or disabled, isn't the
"vendor-preset: disabled" the wrong choice: I specified nothing, and the logic
should be: If a generator created a unit it should be enabled; otherwise sich a
unit shouldn't be enabled.

I couldn't find the relevant manual page that discusses this topic...

Regards,
Ulrich

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