[systemd-devel] Nonstandard port for systemd-resolved DNS forwarded queries

2019-07-03 Thread jimc

Version: systemd-242-2.2.x86_64, dnsmasq-2.80-4.1.x86_64,
bind-9.11.2-44.3.x86_64, avahi-0.7-7.3.x86_64 from OpenSuSE Tumbleweed.

Here's my use case: There's a master directory server, two slaves, and a
bunch of leaf nodes.  All support IPv4 and IPv6.  All the Linux boxes
run systemd and systemd-resolved; the latter synthesizes DNS RR's from
/etc/hosts (which is kept up to date by the same script that maintains
our DNS zone files).  The master has dnsmasq with DHCP service for nodes
with centrally assigned fixed IPs, and for aleatory guest nodes. Dnsmasq
also sends out DNS RR's from /etc/hosts and /etc/ethers (RFC 4862
addresses).  Multicast DNS (by Avahi) on each node provides $HOST.local
(but this is not used heavily).  The master and the slaves have Berkeley
Bind ("named"), which is authoritative for my internal domain and which
provides recursive service to internal clients, to forward queries to
offsite DNS servers.

In the present setup, a leaf node's app calls gethostinfo from glibc,
which obeys /etc/nsswitch.conf and (not finding info in /etc/hosts) uses
the D-Bus API to contact systemd-resolved, which forwards the offsite
query to the master's port 53 (dnsmasq), which forwards it to the
master's "named" running on nonstandard port 4253.  The slave dirsvrs'
"named" shares port 53 on all interfaces, competing with
systemd-resolved and causing a race condition at startup
(systemd-resolved will die if "named" has already opened the port) plus
other odd behavior.

I would like to move the slaves' "named" to port 4253 same as on the
master, but I see no simple and non-kludgey way to get systemd-resolved
to query a nameserver (local or remote) on a nonstandard port.  My next
kludge is going to be to write a forwarder that listens on 127.0.0.253
port 53/udp and forwards to one of the dirsvrs on port 4253, failing
over to different ones during system downtime.

What do you guys recommends for this use case?

What I would really like to see, which I'm going to implement in my
kludge, is syntax in /etc/systemd/resolved.conf where you could say
something like
DNS=192.9.200.193#53 (192.9.200.194#4253 192.9.200.195#4253)
meaning: Try the master, but if it's down use whichever slave is
responding.  And speculatively retry the master occasionally, reverting
to it when it's up again.  For me it's important to go through the
master's dnsmasq on port 53, to get hosts which have names but which
have non-fixed IPs from the DhCP pool or RFC 4862 addresses.  But of
course the slaves have no dnsmasq (I wish that were possible).

By the way, the dirsvrs' IP addresses all are in /etc/hosts...

--
James F. Carter   Email: j...@jfcarter.net
Web: http://www.math.ucla.edu/~jimc (q.v. for PGP key)



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Logged timestamps for service do not report correct times

2019-07-03 Thread Sam Gilson
Thank you for the response! I don't think I did a great job asking an actual 
question in my last email, so let me clarify.

What I am currently trying to understand is what the differences between how  
and when the different timestamps for each service are logged. The confusion 
comes from the fact that ExecMainStartTimestamp, according to the name, should 
be the timestamp for when the Main of my service gets run, but that doesn't 
seem to be the case. Our service emits its own timestamp when the main is run, 
but ExecMainStartTimestamp doesn't reflect that timestamp like it should.

My hypothesis is that is that our service loops for a long time (30 min 
usually) while waiting for a new DHCP lease to come in, and once that is 
completed, a time sync w/NTP occurs which causes the ExecMainStartTimestamp to 
be rewritten. Why I think this is the case is that InactiveExitTimestamp and 
ExecMainStartTimestamp are always off by the time spent in our loop (i.e 
InactiveTimestamp = X, loop takes 30 min, ExecMainStartTimestamp = X + 30). The 
same problem also occurs with the ActiveStartTimestamp. However, I might be 
completely incorrect about my hypothesis and that's why I am asking here.

Any help would be appreciated!

Best Regards,
Sam Gilson

-Original Message-
From: Lennart Poettering  
Sent: Wednesday, July 3, 2019 2:30 AM
To: Sam Gilson 
Cc: systemd-devel@lists.freedesktop.org
Subject: Re: [systemd-devel] Logged timestamps for service do not report 
correct times

On Mi, 26.06.19 16:30, Sam Gilson (t-sag...@microsoft.com) wrote:

> Hey everyone, I've got a quick question about how the timestamps that 
> are gathered by systemctl are emitted by systemd. My organization has 
> a service that runs fairly early in boot (timestamp X ), it has DHCP 
> to an internal network (no Internet)and stays in a polling loop for 
> about 30 minutes. At some point later it finishes polling and obtain a 
> new DHCP lease and at this time it has access to the Internet 
> (X+30min). Once the service finished we queried the following 
> monotonic timestamps: InactiveExitTimestampMonotonic, 
> ActiveEnterTimestampMonotonic, ExecMainStartTimestampMonotonic. The 
> InactiveExit timestamp indicates the unit was started around Timestamp 
> X, which is as expected. However, ActiveEnter and ExecMainStart seems 
> to put it at X + 30min, despite the unit already started ways back at 
> X + x (we know because this service emits its own log when it starts 
> up). We are trying to figure out how each of these timestamps are 
> logged, as when we disable the internal DHCP loop, all these 
> timestamps have very similar values. This indicates to me that our 
> DHCP loop apparently runs between when InactiveExit and ActiveEnter 
> are logged, which accounts for that extra 30 minutes added to the 
> ActiveEnterTimestamp. The problem that we have is that we need the 
> ActiveEnterTimestampMonotonic to be reported accurately when the 
> internal DHCP loop runs.

I am not sure I grok the question fully, but do note that services can be 
restarted, at which time the InactiveExitTimestampMonotonic field is of course 
reset. i.e. if you issue "systemctl show" after boot completed you'll just see 
the data of the most recent instance started.

The clock is directly in Linux' CLOCK_MONOTONIC timestamp, which should be 
fully monotonic on each boot, and will pause when the system is suspended.

Note that the journal always logs the boot ID (which is a uuid the kernel 
assigns to each boot iteration) along with the monotonic clock value. When the 
boot id changes you cannot really compare the monotonic timestamps anymore, of 
course.

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: Startup single step

2019-07-03 Thread Reindl Harald


Am 03.07.19 um 11:59 schrieb Ulrich Windl:
> Well an actual fact: I upgraded a system yesterday, and I spend about eight
> reboots and about 5 hours just to find out WHY systemd booted into an 
> emergency
> shell. Compared to the old init I would have found and fixed that in one boot 
> I
> guess.

would you mind the problem?

i mean i run fedora with systemd on 40 setups, systemd was introdued
with F15 which means 40x14 (currently on F29) *560 dist-upgrades* on
systemd based systems without a single time face the emergency shell or
a really systemd related problem preventing boot

the emergency shell i knwo only from testing vms when i fucked up
somthing on my own coming up give nme the chance to fix it wout boot
from an ISO image
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: systemd-devel listed as support confuses users (was: connection failure)

2019-07-03 Thread Reindl Harald


Am 03.07.19 um 11:53 schrieb Ulrich Windl:
> I agree that the major problem with systemd was that distributions switched 3
> or 5 years too early to it.

guess where you would be now without them solving most fo the problems
over the past years for people coming like you late to the party

guess where you could be if your distribution would use a recent vesion
instead pacth it like theere would be no tomorrow
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Antw: Re: systemd-devel listed as support confuses users (was: connection failure)

2019-07-03 Thread Reindl Harald


Am 03.07.19 um 08:37 schrieb Ulrich Windl:
> The really annoying thing with systemd is that if SOMETHING fails during boot,
> the complete boot is aborted and you are put into an emergency shell.

this is not true

there are very rare cases where you end in the emergency shell

> with the fact that the user sees nothing while systemd waits for something
> (like 3 minutes) the user does not know (because he does not see anything on
> the console) gives the impression that the system "hangs". This is true at
> least for SLES 12.

this is also not true for many years

as like for many of our problems blame SUSE

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

Re: [systemd-devel] Antw: Re: systemd-devel listed as support confuses users (was: connection failure)

2019-07-03 Thread Lennart Poettering
On Mi, 03.07.19 08:37, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> >> I agree here. While we do have `support-url` which distros can
> >> override, Apparently not all of them do.
> >> We could probably change our build system, that `support-url` needs to
> >> be set explicitly and if unset, no Support URL is printed in the
> >> journal output.
> >
> > This, or since the URL leads to [0], it would be also useful to extend
> > the "About systemd-devel" section to provide some kind of warning that
> > this ML is mainly/only for upstream systemd, not for systemd shipped by
> > distributions.
> >
> > [0] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
> The really annoying thing with systemd is that if SOMETHING fails during boot,
> the complete boot is aborted and you are put into an emergency
> shell.

This is not really the case. Only stuff that has a Requires=
dependency from basic.targe/sysinit.target/local-fs.target will cause
the boot to fail. Most services except the most essential are not
marked with Requires=, but use Wants=.

systemd gives you precise control what is required and what just shall
be started through this. If your distro or your admin use that
incorrectly, pleas work with them to fix that.

> Combined
> with the fact that the user sees nothing while systemd waits for something
> (like 3 minutes) the user does not know (because he does not see
> anything on

That's not true. You see the "eye of ceylon" animation on the console
with info what is being waited for. Maybe you use a bootsplash that
turns that off? Talk to you distro. And the eye of ceylong animation
has been in place since a long long time.

> the console) gives the impression that the system "hangs". This is true at
> least for SLES 12.

Hm, isn't SLES 12 like 5 years old by now? Maybe upgrade to something
less archaic?

> To make systemd better, you really have to listen to the users' problems and
> actually MAKE IT BETTER.

Maybe it is already a lot better, but we can't change your five year
old distro as upstream project?

Lennart

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

Re: [systemd-devel] Startup single step

2019-07-03 Thread Lennart Poettering
On Di, 02.07.19 12:30, Jay Burger (jay.bur...@us.fujitsu.com) wrote:

> Hi,
>
> I am curious if there is a way to single step through the systemd startup
> of services?

So this exists, in theory in systemd.confirm_spawn= on the kernel
cmdline. But it's not without pitfalls. In particular, some distros
like to forcibly bind some service's stdio to the tty, which then
interferes with the asking the user stuff. More importantly though,
systemd implements a parallel boot, and a boot that cannot necessarily
be linearized (for exampe: a service X that connects to a service Y
via socket activation or bus activation necessarily means that X' and
Y' start-up need to happen in parallel), and this makes the the
interactive boot-up quite complicated to follow. Moreover lots of
software tends to apply timeouts to stuff (including systemd), and if
we interactively ask the user each time for everything these time-puts
are hit easily. For example dbus clients generally wait for 45s at
most for connection attempts and method calls, and since things add up
these are hit quickly.

hence, yes you can do this, but it's not particular fun, and falls
apart quickly on complex systems, as such interactive boot-ups tend to
behave quite differently from regular ones.

Usually it's better to just turn on debug logging, and try to figure
out things from the logs, when they happen in the same (non-)order and
(rougly) the same timing behaviour as the regular boots.

> I don't find any such feature and am curious what others would think
> of it. We had a similar feature in a previous life, different OS,
> and developers seemed to like it. I personally think it was a handy
> tool to have in the arsenal, probably not a "use it all the time"
> kind of thing.
>
> It could be triggered via a kernel command line option and in it's
> simplest form, systemd would start a service and prompt the user
> before continuing to the next. I know this would change timing and
> dependencies may have issues but just throwing out the idea.
>
> This could possibly even be used to single step through the shutdown
> of 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] Antw: Re: Antw: Startup single step

2019-07-03 Thread Lennart Poettering
On Mi, 03.07.19 11:59, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> > Thank you for understanding,
>
> OK, I'll write a positive message about systemd: "Great, it made me spend
> several hours to find and fix boot problems, where without systemd I would had
> just idle time. A great improvement!"

You are now on moderation.

Lennart

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

[systemd-devel] Problem in understanding container permissions

2019-07-03 Thread Kai Bojens
Ubuntu 18.04, HWE kernel 4.18.0-25-generic, systemd 237-3ubuntu10.23

I have created a nspawn container with a minimal Ubuntu and booted the container
without any problems. There were no problems and I used the default settings.
Now I see some strange permission errors which I can't explain:

 Inside the container:

root@container:/var/log# ls -alt
total 356
-rw-r--r--  1 root   root203203 Jul  3 09:17 dpkg.log
drwxr-xr-x  1 root   root60 Jul  3 09:17 apt
-rw-r--r--  1 root   root  9046 Jul  2 15:04 alternatives.log
-rw---  1 root   root  6784 Jul  2 15:04 tallylog
-rw-r--r--  1 root   root  3392 Jul  2 15:04 faillog
-rw-r-  1 nobody nogroup  40658 Jul  2 10:14 syslog
-rw-rw-r--  1 nobody nogroup  16128 Jul  2 10:14 wtmp
-rw-r-  1 nobody nogroup   6234 Jul  2 10:14 auth.log
-rw-rw-r--  1 nobody nogroup  30660 Jul  2 10:06 lastlog
-rw-rw  1 nobody nogroup384 Jul  1 14:02 btmp
drwxrwxr-x  1 nobody nogroup182 Jul  1 14:02 .
drwxr-sr-x+ 1 nobody nogroup 64 Jul  1 14:02 journal
-rw-r--r--  1 root   root 60952 Jul  1 13:59 bootstrap.log
drwxr-xr-x  1 root   root90 Jul  1 13:56 ..
root@container:/var/log# whoami
root
root@container:/var/log# tail syslog
tail: cannot open 'syslog' for reading: Permission denied


 Outside the container:

root@container:/var/lib/machines/xy-test/var/log# ls -alt
total 356
-rw-r--r--  1 198180864   198180864 203203 Jul  3 09:17 dpkg.log
drwxr-xr-x  1 198180864   198180864 60 Jul  3 09:17 apt
-rw-r--r--  1 198180864   198180864   9046 Jul  2 15:04 alternatives.log
-rw---  1 198180864   198180864   6784 Jul  2 15:04 tallylog
-rw-r--r--  1 198180864   198180864   3392 Jul  2 15:04 faillog
-rw-r-  1 syslogadm  40658 Jul  2 10:14 syslog
-rw-rw-r--  1 root  utmp 16128 Jul  2 10:14 wtmp
-rw-r-  1 syslogadm   6234 Jul  2 10:14 auth.log
-rw-rw-r--  1 root  utmp 30660 Jul  2 10:06 lastlog
-rw-rw  1 root  utmp   384 Jul  1 14:02 btmp
drwxrwxr-x  1 root  syslog 182 Jul  1 14:02 .
drwxr-sr-x+ 1 root  systemd-journal 64 Jul  1 14:02 journal
-rw-r--r--  1 198180864   198180864  60952 Jul  1 13:59 bootstrap.log
drwxr-xr-x  1 198180864   198180864 90 Jul  1 13:56 ..

I have not touched any of these files from outside of the container. Is there
anything obvious I have failed to see? Why would the ownership of these file
change?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] Antw: Re: Antw: Startup single step

2019-07-03 Thread Ulrich Windl
>>> Lennart Poettering  schrieb am 03.07.2019 um 11:01
in
Nachricht <20190703090130.GB12011@gardel-login>:
> On Mi, 03.07.19 08:42, Ulrich Windl (ulrich.wi...@rz.uni‑regensburg.de)
wrote:
> 
>> >>> Jay Burger  schrieb am 02.07.2019 um 19:30
in
>> Nachricht :
>> > Hi,
>> >
>> > I am curious if there is a way to single step through the systemd
startup
>> > of services? I don't find any such feature and am curious what others
would
>> > think of it. We had a similar feature in a previous life, different OS,
and
>> > developers seemed
>> > to like it. I personally think it was a handy tool to have in the
arsenal,
>> > probably not
>> > a "use it all the time" kind of thing.
>>
>> My guess is that you actually do not want to single‑step systemd,
>> but instead you want to see what goes wrong and maybe ignore some of
>> such failures and continue as if there was no error. Most useful
>> during boots. See my previous message about user frustration and
>> systemd's bad reputation...
> 
> Ulrich, please vent your frustration elsewhere. This is not OK.
> 
> You maybe have noticed people have been very helpful to you on this
> mailing list, and answered many of your questions in a lot of detail
> for free. Yet, you still jump in all the time and complain all the
> time. If you want people to help you, best thing is to be nice. If you
> are not people will just start to ignore you and eventually block
> you.
> 
> Messages like the one above are entirely unnecessary. Just don't do

Actually you mix up messages with a single sentence. The last sentence may be
personal opinion, but not the lines before.

> this. You are not helping anyone, just annoying the very people you
> yourself expect help from.
> 
> One more time and I'll put you on moderation on this mailing list.

Well an actual fact: I upgraded a system yesterday, and I spend about eight
reboots and about 5 hours just to find out WHY systemd booted into an emergency
shell. Compared to the old init I would have found and fixed that in one boot I
guess.

I didn't send my frustration on this to the list, but as you mention it...

> 
> Thank you for understanding,

OK, I'll write a positive message about systemd: "Great, it made me spend
several hours to find and fix boot problems, where without systemd I would had
just idle time. A great improvement!"

> 
> 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: systemd-devel listed as support confuses users (was: connection failure)

2019-07-03 Thread Ulrich Windl
>>> František Šumšal  schrieb am 03.07.2019 um 11:01 in
Nachricht :

[...]
> Honestly, I'm kind of impressed you stamp the "bad bad systemd" phrase all 
> over
> the place several times in your emails, yet you still expect people to be 
> able
> to (willingly) help you.

I may have an opinion, just as you are allowed to have one. That's the good
thing.

> 
>> To make systemd better, you really have to listen to the users' problems
and
>> actually MAKE IT BETTER.
> 
> I know this might surprise you, but that's how systemd got where it is now.

> We
> just need to filter out problems which have been already fixed, so we can 
> focus
> on solving the outstanding ones (instead of going through hundreds of bug 
> reports).

I agree that the major problem with systemd was that distributions switched 3
or 5 years too early to it.

Regards,
Ulrich

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

Re: [systemd-devel] Antw: Re: Anybody care to fix the list processor?

2019-07-03 Thread Lennart Poettering
On Mo, 01.07.19 17:03, syst...@howorth.org.uk (syst...@howorth.org.uk) wrote:

> On Mon, 01 Jul 2019 08:20:23 +0200
> "Ulrich Windl"  wrote:
> > >>> Simon McVittie  schrieb am 11.06.2019 um
> > >>> 16:29 in Nachricht
> > <20190611142939.GA6676@horizon>:
> > > On Tue, 11 Jun 2019 at 15:44:07 +0200, Ulrich Windl wrote:
> > >> Does anybody running the list care to fix the list-processor.
> > >
> > > I don't think the members of this list
> > > control its infrastructure, but I've opened
> > > .
> >
> > I agree, but they might care that the list they are using is
> > operational.
>
> Is this problem being worked on?
> It seems quite serious; it apparently prevents people from subscribing
> to the list as well as changing permissions.

The info page of the ML now tries to make it very clear that
subscription-by-mail doesn't work, and you have to subscribe via the
web interface:

https://lists.freedesktop.org/mailman/listinfo/systemd-devel

I hope people have a look there.

Lennart

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

Re: [systemd-devel] Logged timestamps for service do not report correct times

2019-07-03 Thread Lennart Poettering
On Mi, 26.06.19 16:30, Sam Gilson (t-sag...@microsoft.com) wrote:

> Hey everyone, I've got a quick question about how the timestamps
> that are gathered by systemctl are emitted by systemd. My
> organization has a service that runs fairly early in boot (timestamp
> X ), it has DHCP to an internal network (no Internet)and stays in a
> polling loop for about 30 minutes. At some point later it finishes
> polling and obtain a new DHCP lease and at this time it has access
> to the Internet (X+30min). Once the service finished we queried the
> following monotonic timestamps: InactiveExitTimestampMonotonic,
> ActiveEnterTimestampMonotonic, ExecMainStartTimestampMonotonic. The
> InactiveExit timestamp indicates the unit was started around
> Timestamp X, which is as expected. However, ActiveEnter and
> ExecMainStart seems to put it at X + 30min, despite the unit already
> started ways back at X + x (we know because this service emits its
> own log when it starts up). We are trying to figure out how each of
> these timestamps are logged, as when we disable the internal DHCP
> loop, all these timestamps have very similar values. This indicates
> to me that our DHCP loop apparently runs between when InactiveExit
> and ActiveEnter are logged, which accounts for that extra 30 minutes
> added to the ActiveEnterTimestamp. The problem that we have is that
> we need the ActiveEnterTimestampMonotonic to be reported accurately
> when the internal DHCP loop runs.

I am not sure I grok the question fully, but do note that services can
be restarted, at which time the InactiveExitTimestampMonotonic field
is of course reset. i.e. if you issue "systemctl show" after boot
completed you'll just see the data of the most recent instance
started.

The clock is directly in Linux' CLOCK_MONOTONIC timestamp, which
should be fully monotonic on each boot, and will pause when the system
is suspended.

Note that the journal always logs the boot ID (which is a uuid the
kernel assigns to each boot iteration) along with the monotonic clock
value. When the boot id changes you cannot really compare the
monotonic timestamps anymore, of course.

Lennart

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

Re: [systemd-devel] systemd-devel listed as support confuses users (was: connection failure)

2019-07-03 Thread Lennart Poettering
On Di, 02.07.19 18:51, František Šumšal (franti...@sumsal.cz) wrote:

>
>
> On 7/2/19 4:36 PM, Michael Biebl wrote:
> > Am Di., 2. Juli 2019 um 16:16 Uhr schrieb Paul Menzel
> > :
> >> Reading the output above, I can see, why the people contact this mailing
> >> list.
> >
> > I agree here. While we do have `support-url` which distros can
> > override, Apparently not all of them do.
> > We could probably change our build system, that `support-url` needs to
> > be set explicitly and if unset, no Support URL is printed in the
> > journal output.
>
> This, or since the URL leads to [0], it would be also useful to extend
> the "About systemd-devel" section to provide some kind of warning that
> this ML is mainly/only for upstream systemd, not for systemd shipped by
> distributions.
>
> [0] https://lists.freedesktop.org/mailman/listinfo/systemd-devel

I added a paragraph there now that attempts to clear this up. I hope
people actually look there, though.

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: Startup single step

2019-07-03 Thread Lennart Poettering
On Mi, 03.07.19 08:42, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> >>> Jay Burger  schrieb am 02.07.2019 um 19:30 in
> Nachricht :
> > Hi,
> >
> > I am curious if there is a way to single step through the systemd startup
> > of services? I don't find any such feature and am curious what others would
> > think of it. We had a similar feature in a previous life, different OS, and
> > developers seemed
> > to like it. I personally think it was a handy tool to have in the arsenal,
> > probably not
> > a "use it all the time" kind of thing.
>
> My guess is that you actually do not want to single-step systemd,
> but instead you want to see what goes wrong and maybe ignore some of
> such failures and continue as if there was no error. Most useful
> during boots. See my previous message about user frustration and
> systemd's bad reputation...

Ulrich, please vent your frustration elsewhere. This is not OK.

You maybe have noticed people have been very helpful to you on this
mailing list, and answered many of your questions in a lot of detail
for free. Yet, you still jump in all the time and complain all the
time. If you want people to help you, best thing is to be nice. If you
are not people will just start to ignore you and eventually block
you.

Messages like the one above are entirely unnecessary. Just don't do
this. You are not helping anyone, just annoying the very people you
yourself expect help from.

One more time and I'll put you on moderation on this mailing list.

Thank you for understanding,

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: systemd-devel listed as support confuses users (was: connection failure)

2019-07-03 Thread František Šumšal
On 7/3/19 8:37 AM, Ulrich Windl wrote:
 František Šumšal  schrieb am 02.07.2019 um 18:51 in
> Nachricht :
> 
>>
>> On 7/2/19 4:36 PM, Michael Biebl wrote:
>>> Am Di., 2. Juli 2019 um 16:16 Uhr schrieb Paul Menzel
>>> :
 Reading the output above, I can see, why the people contact this mailing
 list.
>>>
>>> I agree here. While we do have `support-url` which distros can
>>> override, Apparently not all of them do.
>>> We could probably change our build system, that `support-url` needs to
>>> be set explicitly and if unset, no Support URL is printed in the
>>> journal output.
>>
>> This, or since the URL leads to [0], it would be also useful to extend
>> the "About systemd-devel" section to provide some kind of warning that
>> this ML is mainly/only for upstream systemd, not for systemd shipped by
>> distributions.
>>
>> [0] https://lists.freedesktop.org/mailman/listinfo/systemd-devel 
> 
> The really annoying thing with systemd is that if SOMETHING fails during boot,
> the complete boot is aborted and you are put into an emergency shell.

I, too, like my systems to be booted up only a half way with half of the 
services
being in an unknown/inconsistent state.

> Combined
> with the fact that the user sees nothing while systemd waits for something
> (like 3 minutes) the user does not know (because he does not see anything on
> the console) gives the impression that the system "hangs". This is true at
> least for SLES 12.

Well, you see the service it's waiting for. Then there are several things
which should help you when things go south:

1) If the service fails and it's crucial to the boot process, you'll end up
   in the (apparently pretty despised by you) emergency shell, where you can
   go through all necessary logs to see what went wrong
2) By adding a simple "debug" to the kernel command line, or making use of
   systemd.log_level and systemd.log_target kernel cmdline options you can
   dump the entire boot process logic to the console. You can't do this by
   default, as it unnecessarily over-saturates the console line, which leads
   to a significant slow down of the entire boot process. Also, as everything
   is logged (as would any sane person expect), it would, again - unnecessarily,
   bloat the system journal

You can't simply blame systemd that it refuses to boot when there's a service,
marked as the system administrator as crucial, yet which is apparently broken
in some way.

> While the individual cause of such failures may not be systemd, the overall
> effect of user frustration is very much due to systemd, giving it its bad
> reputation.
> So don't worry if people come to complain about many things here.

The main issue is not about people complaining (that's actually something we
want/need to), but in the version many of these users use. The systemd has
come a long way for the past few years, and there's been thousands of changes
to make things smooth and painless. But, of course, not all distributions
use the bleeding-edge version of systemd, which then introduces certain 
problems:

1) An user complains about something which has been already fixed, yet not
   backported to their distro
2) Some distributions (like RHEL) base their systemd package on a certain 
version
   (like 219 in RHEL 7) and then backport only some patches from the upstream. 
Thus,
   upstream developers shouldn't/can't be expected to know what mixture of 
patches the
   user uses.

In both cases, the downstream bug tracker is way to go. The downstream 
maintainers
know their systemd package much better and can tell you, if it's an 
downstream-only
issue, and a backport is necessary, or if it's indeed an upstream issue and they
can guide you here (or they'd do that on your behalf).

> Removing or changing the support URL might help to reduce the traffic here,
> but it definitely wouldn't help against the bad reputation of systemd.

Honestly, I'm kind of impressed you stamp the "bad bad systemd" phrase all over
the place several times in your emails, yet you still expect people to be able
to (willingly) help you.

> To make systemd better, you really have to listen to the users' problems and
> actually MAKE IT BETTER.

I know this might surprise you, but that's how systemd got where it is now. We
just need to filter out problems which have been already fixed, so we can focus
on solving the outstanding ones (instead of going through hundreds of bug 
reports).

>>
>>> Just an idea...
>>>
>>>
>>> Michael
>>>
>>
>> -- 
>> PGP Key ID: 0xFB738CE27B634E4B
> 
> 
> 


-- 
Frantisek Sumsal
GPG key ID: 0xFB738CE27B634E4B



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-tmpfiles-setup.service: ... Unknown user '1019'

2019-07-03 Thread Lennart Poettering
On Mi, 03.07.19 09:07, Ulrich Windl (ulrich.wi...@rz.uni-regensburg.de) wrote:

> Hi!
>
> I'm having a problem created by systemd: A temporary directory is to
> be created that is owned by a user found in LDAP.  However as all
> temporary directories are created way before networking is
> available, I cannot user the user name, nor can systemd delay
> creating that directory after networking/LDAP is available.  So I
> tried specifying the numeric UID/GID instead, but contrary to the
> manual page, it does not work:

This is explicitly not supported. System users need to be resolvable
at any time. This is explicitly documented for systemd:

https://systemd.io/UIDS-GIDS.html#notes-on-resolvability-of-user-and-group-names

> systemd-tmpfiles[19305]: [/usr/lib/tmpfiles.d/nrpe.conf:1] Unknown user 
> '1019'.
>
> The only line in file /usr/lib/tmpfiles.d/nrpe.conf is:
> d /run/nrpe 0755 1019 nagios
>
> From the manual page:
>UID, GID
>The user and group to use for this file or directory. This may either 
> be a numeric user/group ID or a
>user or group name. If omitted or when set to "-", the default 0 
> (root) is used. For z and Z lines, when
> ...

Update to a newer systemd version, or ask your distro to backport
commit fafff8f1ffdf24517921d7779c2a9eb89766df30 (and its dependencies).

Before that commit the code insisted that users specified by numeric
UID had to exist, after that commit this is no longer required.

> Any clever ideas?  My guess is to split creating all the temporary
> files at early boott time into multiple phases so that name service
> can be used for use rresolution. If the service needs the name
> resolution, the temporary directory for the service can be delayes
> just before the service will be started...

Just add system users to /etc/passwd, otherwise you'll be in constant
pain, and you have to deal with the fall-out yourself.

Lennart

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

[systemd-devel] systemd-tmpfiles-setup.service: ... Unknown user '1019'

2019-07-03 Thread Ulrich Windl
Hi!

I'm having a problem created by systemd: A temporary directory is to be created 
that is owned by a user found in LDAP.
However as all temporary directories are created way before networking is 
available, I cannot user the user name, nor can systemd delay creating that 
directory after networking/LDAP is available.
So I tried specifying the numeric UID/GID instead, but contrary to the manual 
page, it does not work:

systemd-tmpfiles[19305]: [/usr/lib/tmpfiles.d/nrpe.conf:1] Unknown user '1019'.

The only line in file /usr/lib/tmpfiles.d/nrpe.conf is:
d /run/nrpe 0755 1019 nagios

From the manual page:
   UID, GID
   The user and group to use for this file or directory. This may either be 
a numeric user/group ID or a
   user or group name. If omitted or when set to "-", the default 0 (root) 
is used. For z and Z lines, when
...

Any clever ideas?
My guess is to split creating all the temporary files at early boott time into 
multiple phases so that name service can be used for use rresolution. If the 
service needs the name resolution, the temporary directory for the service can 
be delayes just before the service will be started...

Regards,
Ulrich


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

[systemd-devel] Antw: Startup single step

2019-07-03 Thread Ulrich Windl
>>> Jay Burger  schrieb am 02.07.2019 um 19:30 in
Nachricht :
> Hi,
> 
> I am curious if there is a way to single step through the systemd startup
> of services? I don't find any such feature and am curious what others would
> think of it. We had a similar feature in a previous life, different OS, and 
> developers seemed
> to like it. I personally think it was a handy tool to have in the arsenal, 
> probably not
> a "use it all the time" kind of thing.

My guess is that you actually do not want to single-step systemd, but instead 
you want to see what goes wrong and maybe ignore some of such failures and 
continue as if there was no error. Most useful during boots. See my previous 
message about user frustration and systemd's bad reputation...

> 
> It could be triggered via a kernel command line option and in it's simplest 
> form, systemd
> would start a service and prompt the user before continuing to the next. I 
> know 
> this would
> change timing and dependencies may have issues but just throwing out the 
> idea.
> 
> This could possibly even be used to single step through the shutdown of 
> services.
> 
> Thanks in advance for your attention,
> 
> -Jay
> ___
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org 
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel 




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

[systemd-devel] Antw: Re: systemd-devel listed as support confuses users (was: connection failure)

2019-07-03 Thread Ulrich Windl
>>> František Šumšal  schrieb am 02.07.2019 um 18:51 in
Nachricht :

> 
> On 7/2/19 4:36 PM, Michael Biebl wrote:
>> Am Di., 2. Juli 2019 um 16:16 Uhr schrieb Paul Menzel
>> :
>>> Reading the output above, I can see, why the people contact this mailing
>>> list.
>> 
>> I agree here. While we do have `support-url` which distros can
>> override, Apparently not all of them do.
>> We could probably change our build system, that `support-url` needs to
>> be set explicitly and if unset, no Support URL is printed in the
>> journal output.
> 
> This, or since the URL leads to [0], it would be also useful to extend
> the "About systemd-devel" section to provide some kind of warning that
> this ML is mainly/only for upstream systemd, not for systemd shipped by
> distributions.
> 
> [0] https://lists.freedesktop.org/mailman/listinfo/systemd-devel 

The really annoying thing with systemd is that if SOMETHING fails during boot,
the complete boot is aborted and you are put into an emergency shell. Combined
with the fact that the user sees nothing while systemd waits for something
(like 3 minutes) the user does not know (because he does not see anything on
the console) gives the impression that the system "hangs". This is true at
least for SLES 12.

While the individual cause of such failures may not be systemd, the overall
effect of user frustration is very much due to systemd, giving it its bad
reputation.
So don't worry if people come to complain about many things here.

Removing or changing the support URL might help to reduce the traffic here,
but it definitely wouldn't help against the bad reputation of systemd.

To make systemd better, you really have to listen to the users' problems and
actually MAKE IT BETTER.

> 
>> Just an idea...
>> 
>> 
>> Michael
>> 
> 
> -- 
> PGP Key ID: 0xFB738CE27B634E4B



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